Icon
Icon
Icon
Icon
Icon
Icon
1:15 AM
0 comments


Chapter 5. Troubleshooting an IOS Firewall

In addition to its primary role of routing, a router can provide security to the perimeter of the network. And depending on how you deploy it, a router can provide security to an intranet between different departments, or to an extranet between partners.
Routers provide several security services, which are commonly known as the IOS firewall feature set. The most important component of the IOS Firewall feature set is the Advanced Firewall Engine called Context-Based Access Control (CBAC), which turns a router into an effective enterprise-class firewall (FW). So, the primary focus of this chapter is CBAC, and how it interoperates with other security features such as auth-proxy, Network Address Translation (NAT), Port to Application Mapping (PAM), and so on. Cisco IOS Intrusion Prevention System (IPS), another important security feature of Cisco IOS firewall feature set that works in conjunction with CBAC, is discussed in greater detail in Chapter 16, "Troubleshooting Cisco IDS Network Module (NM-CIDS)," and is therefore not discussed here. The Case Study section looks into a rarely used IOS firewall feature called auth-proxy, which can work in conjunction with CBAC to provide user authentication of the traffic going through the firewall (the user-based firewall feature). This chapter covers all aspects of troubleshooting tools and techniques that are required to troubleshoot any issues pertaining to CBAC, followed by the Common Problems and Resolutions. The chapter concludes with best practices for implementing CBAC.

Overview of IOS Firewall (CBAC)

Because you can filter traffic using an access control list (ACL) on the router, you may wonder why CBAC is necessary. What shortcoming is CBAC addressing for the traditional ACL? That deserves an answer before we proceed any further with the CBAC discussion.
ACL has many limitations that keep it from being an effective firewall mechanism. The most important limitation is that ACL is a packet filtering mechanism based on Open System Interconnection (OSI) network and transport layer information. On the other hand, CBAC is a stateful firewall just like Private Internet Exchange (PIX), which filters traffic based on state information rather than just on network or transport layer information.
For example, assume there is an inside and outside network with a dotted line as the perimeter, and there is a firewall router with an Ethernet 0 interface going to the protected network (inside) and an interface Serial 0 going to the unprotected network (Internet) as shown in Figure 5-1.
For the router to protect the inside network, two conditions must be met:
  • Allow connections to initiate from the protected (inside) network.
  • Deny connections initiated from the Internet (unsafe) network from entering the inside network.
To fulfill the second requirement, configure an ACL 101 on the serial 0 interface that denies all traffic from outside. This effectively sets up a wall to block outside traffic. Then, take a look at the first requirement, that is, to allow traffic from the protected network to the Internet. As shown in Figure 5-2, when Telnet is initiated from the inside to the outside, being a Transmission Control Protocol (TCP), the synchronize (SYN) packet from the inside makes it to the outside. This is because there is no access list applied in this example on the inside interface towards the direction of the initial packet. It is a good security practice, however, to configure ACL on the inside interface facing towards the protected network to stop anti-spoofing. You should, however, watch carefully that the reply SYN-ACK packet from outside is blocked by the ACL that you have applied on the serial 0 interface and the connection fails to set up. The result will be the same for the User Datagram Protocol (UDP) reply packet. So, as you can see with the static ACL, if this connection needs to be successful, you need to create an Access Control Entry (ACE) entry on ACL 101 that is applied earlier on the serial 0 interface with a source port 23 and destination port greater than 1023. Doing so opens up several holes to your network, because anyone from outside can also initiate connections using those ports). This is where CBAC plays an important role.
How can CBAC solve this problem? To turn on CBAC, create and apply a simple CBAC rule: inspect only TCP traffic for this example. This rule is turned on for the Ethernet 0 interface towards the direction of SYN packet (inspection must always be applied in the direction of the traffic initiation) as shown in Figure 5-2.
As before, if the Telnet connection is initiated from inside the host to outside, once the SYN packet goes through the router after ACL checking (in this example there is no ACL configured in the traffic initiation direction), the CBAC inspects it. The CBAC inspects it because the initiation packet is moving in the same direction in which the inspection rule is applied (on the Ethernet 0 interface as inbound). CBAC performs the following functions:
  • It extracts transport layer information such as source and destination address and port from the packet.
  • It determines the input and output interfaces.
  • It adds a dynamic entry in the ACLs (after swapping the addresses) for return traffic to allow traffic back for this connection.
This, in effect, creates a tiny hole in the ACL, which is specific to this connection only. As a result, the reply SYN-ACK packet makes it through this hole and reaches the inside end host. The inside end host then replies with the final ACK, and the connection is established. As a result, the first requirement is also met (remember, the first requirement is to allow connections to initiate from the protected network). Once the connection is established, CBAC examines traffic in both directions for this particular connection. CBAC recognizes when the end hosts close connection using FIN (Finish) Exchange or RST (Reset), and the CBAC removes the dynamic ACL entries accordingly. So CBAC not only resolves the issue of creating ACL statically, it also opens up a very specific hole in the ACL that is required, and closes it when finished.
So far we have seen how CBAC helps with single-channel protocol by creating a dynamic ACL. With static ACL, to accomplish this result, leave the outside interface ACL wide open and thereby permit everything. Permitting everything, of course, defeats the purpose of configuring the ACL on the router in the first place. To address this security issue, you may be able to configure the established keyword on the ACL applied on the serial 0 interface. The established keyword filters TCP packets based on whether the ACK or RST bits are set. The setting of ACK or RST bits indicates that the packet is not the first in the session, and therefore, that the packet belongs to an established session. Although this effectively blocks the SYN packet (that is, packet initiation from outside to inside is blocked) for TCP traffic, it works only with TCP and filters based on only the TCP flag, and is therefore vulnerable to a spoof attack.
Reflexive ACL is a better solution than using an established keyword in static ACL, as it works with UDP as well, and creates the dynamic ACL based on source and destination IP addresses and ports. Therefore the traffic is filtered not only by the flag, as in static ACL with the established option, but by source and destination addresses and ports in addition to flags. The biggest drawback, however, with Reflexive ACL is that it does not work with a multi-channel protocol, because the additional channels (other than the first control channel) are built up using the port negotiation that occurs when using the control channel, and Reflexive ACL is unable to learn about this negotiation. Therefore, Reflexive ACL is unable to create dynamic ACE in the ACL for the data channel in the case of a multi-channel protocol. This failure is one of the serious shortcomings of Reflexive ACL. The following section examines how CBAC is better able to handle this multi-channel issue.
To understand how CBAC addresses the shortcoming of Reflexive ACL with multi-channel protocol, examine how CBAC works with multi-channel protocols such as File Transfer Protocol (FTP), H323, Session Initiation Protocol (SIP), and so on. As the name implies, multi-channel typically creates more than one connection for transferring data. Typically, the first connection acts as a control connection. The address and port information for the secondary connections (also known as data connection) are dynamically negotiated by end hosts over this control connection. To illustrate this, study an example of a two-channel protocol, Active FTP with CBAC as shown in Figure 5-3.
Just as before, the ACL 101 is on the outside interface (serial 0), and CBAC is configured on the inside interface (Ethernet 0). An inside host initiates the connection for the control channel by sending a SYN, and CBAC creates a dynamic hole for the return traffic, which allows the reply SYN-ACK packet through the hole. After the client sends the ACK, the connection completes as before.
Now, the inside host negotiates the address and port information for the second channel (data channel) by sending the PORT A: 5560 command. This means that the inside host listens on the source address A and on source port 5560. Hence, the FTP server should try to connect to the client to create the data channel. Note that the FTP client can use the port command to offer an address other than A to create a data connection from the FTP server, which is on the outside.
Even though the data channel is initiated from the FTP server sitting on the outside, the CBAC should allow this connection. Otherwise FTP application functionality will fail. CBAC does this by extracting the PORT A:5560 data from the packet (note that this information lies in the packet's Layer 7 payload and not in the Layer 4 header). After extracting this information, CBAC creates another dynamic ACL entry. The destination address/port in the ACL entry are set to A:5560, whereas the source address/port are set to "any" because CBAC does not know what address/port the outside host will use to initiate the data connection.
This creates another hole in the ACL, which is sometimes known as a wide hole because the src address/port are set to "any". When the outside host actually sends the SYN packet to initiate the connection, CBAC extracts the src information from this packet as B:20. It then uses this information to update the second dynamic ACL and changes the src address/port info from "any" to B:20, thus narrowing the hole to match only this connection. Now the rest of the three-way handshake completes successfully, and the second connection also succeeds. The first connection from A:5550 to B:21 is known as the control connection, and the second connection from B:20 to A:5560 is known as the data connection. Without CBAC, if you configure reflexive or static ACL, you must permit everything from outside to inside for the data connection. In summary, CBAC understands more than Layer 3 and Layer 4 of the OSI model; CBAC understands up to Layer 7. And because of its intelligence of application, CBAC can dynamically open and close the ports needed by the applications using dynamic ACLs.
The discussion in the preceding paragraph focuses primarily on how CBAC handles Active FTP connection, where data connection is initiated by the FTP server sitting on the outside. In passive FTP mode, both the control and data connections are initiated from inside to outside if the FTP clients are located on the inside. More details on Active and Passive FTP can be found in the following location: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac199/about_cisco_ipj_archive_article09186a00800c85a7.html
Details on how CBAC handles Passive FTP can be found in the following location: http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_qanda_item09186a008009464d.shtml#qa5
Being a stateful firewall, CBAC provides several security services to your network. The most important are discussed in the sections that follow.

Single Channel Protocol Inspection

As discussed in the preceding section, for single channel protocols (Telnet, Hypertext Transfer Protocol [HTTP], Simple Mail Transfer Protocol [SMTP], etc.) you need to inspect only the Transport Layer protocolTCP, UDP, and Internet Control Message Protocol (ICMP). For instance, to pass TELNET traffic, the router needs to perform just TCP inspection. There is no need to inspect Telnet, and in fact that option is not available.
As we learned earlier based on Figure 5-2, we can use CBAC to create a session and based on that, create a dynamic ACL, so that the return traffic can come back. Before you go though the discussion of some of the security features provided by CBAC for the single channel TCP protocol, it is worth reviewing how CBAC handles UDP and ICMP protocol. In the preceding section, we have seen how CBAC handles TCP-based protocol both for single- and multi-channel protocol. The following discussion focuses on how CBAC handles UDP and ICMP protocols.
UDP and CBAC
Unlike TCP, UDP is a connectionless protocol. Hence, CBAC's generic UDP inspection cannot detect when a client connection request is satisfied. Therefore, generic UDP inspection simply creates a channel when it recognizes the first request packet from the client, and keeps that channel open until no traffic has been detected between the client and the server for a set time. This approximates session maintenance. To turn on UDP inspection, use the ip inspect myfw UDP command in the global configuration mode (myfw is the name of the inspection rule). Although approximation of UDP connections works most of the time, it may fail in one of the two following ways:
  • It can keep the channel open for too long, which may use the router's memory unnecessarily.
  • It may close the channel too soon. If the client and server do not communicate for a long time, and UDP timeout value elapses, CBAC closes the channel, even though the application may not be finished with the conversation.
ICMP and CBAC
Stateful inspection of ICMP protocol was introduced in version 12.2(11)YU, and integrated in IOS version 12.2(15)T. Before this version, to allow the ping, you had to allow the ECHO for the ping request traffic and ECHO-REPLY for ping reply traffic. With the introduction of stateful inspection in the ICMP protocol, static ACL does not have to be created for the ICMP Packet Types shown in Table 5-1.

Table 5-1. ICMP Packet Types Supported by CBAC
ICMP Packet Types
Name
Description
0
Echo Reply
Reply to Echo Request (Type 8)
3
Destination Unreachable
Possible reply to any request
8
Echo Request
Ping or traceroute request
11
Time Exceeded
Reply to any request if the time to live (TTL) packet is 0
13
Timestamp Request
Request
14
Timestamp Reply
Reply to Timestamp Request (type 13)

A more detailed description of stateful inspection of ICMP protocol can be found at: http://www.cisco.com/en/US/products/sw/iosswrel/ps5012/products_feature_guide09186a0080146558.html
Application Layer Protocol (TCP-based) and CBAC
Because CBAC can parse commands for some TCP-based application layer protocols, and has intelligence built in concerning these protocols, it can provide the security features outlined in the sections that follow.
Preventing from Invalid Command Execution
As mentioned previously, CBAC can parse commands of some TCP-based application layer protocols. SMTP and Extended Simple Mail Transfer Protocol (ESMTP) fall into this category. Although it is sufficient to inspect TCP for SMTP/ESMTP connections, you must inspect SMTP/ESMTP to ensure protocol conformation as per Request For Comment (RFC) through the CBAC router. To block the illegal commands execution by users using SMTP/ESMTP, you need to inspect SMTP/EMTP using the following commands:
ip inspect myfw smtp
ip inspect myfw esmtp

For SMTP inspection, CBAC effectively checks for command violation based on RFC 821 and issues alerts when it detects an SMTP attack (there is more on alerts in a later section). The RFC 821 commands allowed are HELO MAIL, RCPT, DATA, RSET, NOOP, and QUIT by CBAC when SMTP is inspected.
For ESMTP inspection, CBAC inspects the commands defined in RFC 1869, which are AUTH, DATA, EHLO, ETRN, HELO, HELP, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SEND, SOML and VRFY. All others are considered illegal, and when CBAC encounters others it generates alerts.
The CBAC router detects a limited number of SMTP attack signatures. A signature in a SYSLOG message indicates a possible attack against the protected network, such as the detection of illegal SMTP commands in a packet. Whenever a signature is detected, the connection is reset.
There are 11 "IDS Sensor" attack signatures. Five have always been integrated into the Cisco IOS Firewall SMTP implementation, which is shown in Table 5-2.

Table 5-2. Signatures Available in CBAC
Signature
Description
Mail: bad rcpt
Triggers on any mail message with a "pipe" ( | ) symbol in the recipient field.
Mail: bad from
Triggers on any mail message with a "pipe" (|) symbol in the "From:" field.
Mail: old attack
Triggers when "wiz" or "debug" commands are sent to the SMTP port.
Mail: decode
Triggers on any mail message with a ": decode@" in the header.
Majordomo
A bug in the Majordomo program allows remote users to execute arbitrary commands at the privilege level of the server.

Protection from Malicious Java Applets
With the rapid increase of Java applets on the Internet, protecting networks from malicious Java applets has become a major concern for every network administrator. Java blocking can be configured to intelligently filter or completely deny access to Java applets that are not embedded in archives or compressed files. If Java applets are embedded in archives or compressed files, they are not inspected by CBAC. When Java blocking is enabled on an interface, the firewall monitors contents of HTTP packets from HTTP servers, and when a Java applet is identified in the connection, the firewall immediately resets the connection to block that Java applet, preventing it from crossing the firewall.
While configuring CBAC, as soon as you turn on HTTP inspection (as shown in the commands that follow), it blocks the Java applet by default.
ip inspect name  http [java-list ] [audit <on | off>] [alert ]
  [timeout ]
access-list  <deny | permit>  wildcard>

Some of the important points to note here are:
  • Inspecting TCP traffic is sufficient for HTTP unless Java applet blocking is needed. If Java applet is required, then you must inspect HTTP.
  • If you trust some sites with Java applets and want to allow applets to be downloaded to the users' stations from these trusted sites, you need to configure a standard ACL (not an extended ACL) to permit these sites. Then apply the ACL to HTTP inspection with the Java-list option to trigger this. For instance, if you trust Java applets from server 20.1.1.1, then you need to configure CBAC as shown in Example 5-1.
    Example 5-1. Sample of Allowing Java Applet from only Site 20.1.1.1

    Router(config)#access-list 10 permit host 20.1.1.1
    Router(config)#ip inspect myfw java-list 10
    

  • If Java-list is not configured, java blocking is ON by default.
URL Filtering
In addition to Java applet filtering, IOS Firewall can also be configured to filter the web traffic based on other criteria such as address, userid, group, and so on to websites on the internet. This feature is called URL Filtering or Destination URL Policy Management and is introduced in versions 12.2(11) YU and 12.2(15) T and above.
Now look at the details of how URL filtering works with CBAC. The following sequence of events occurs when a CBAC router is configured with URL filtering as shown in Figure 5-4:
Step 1.
The CBAC router configured with URL filtering receives an HTTP request from a user wanting to go to a specific website.

Step 2.
The router simultaneously forwards the request to the destination websites and a query to the URL filter server. The query contains the requested URL destination Domain Name System (DNS) or Internet Protocol (IP) address.

Step 3.
The server replies with a permit or denial of access to the router that is based on the policy setup on the server.

Step 4.
The router either allows or denies (when it denies, the URL server redirects the users to information that indicates which category the user is denied) based on the response from the URL server.
 Step2
needs little more elaboration. Before the router queries the server (if configured) it goes through two local tables on the router that contain the URLs of the destination web servers. Based on the tables, either all users are always permitted or always denied. If no entries or matches are found, the router checks its local cache to determine if the request has been made at an earlier time. If so, it studies the results. To improve the performance, this caching is enabled by default, and does not need to be explicitly configured. By default, the cache table can hold 5000 IP addresses. This can be modified with the following command:
ip urlfilter cache size

Caching enriches the URL filtering by minimizing the number of URL query requests that are sent to the filter server. It is interesting to note that the filter server makes decisions about caching an IP address. When the filter server receives a query request from Cisco IOS Software, it checks whether the request needs to be cached. If it does, the filter server sets a bit map in the response, which indicates that the IP address needs to be cached.
The URL server is a large detailed knowledge base of the Internet and has categorized many URLs into one of the more 80 categories including gaming, pornography, MP3s, freeware, shareware, and so on. You can define the policy based on one of the following categories:
  • Allowable URL categories
  • Users and groups that can access the content
  • Timeframes in which access to content is allowed
  • Additional content restrictions (that is, content is permitted by a time-based quota, with a warning message)
  • Indication of whether the filtering is enforced or content is just monitored and stored in a database
Any degradation of network traffic performance due to URL filtering is not noticed by the user. For performance reasons, the GET request is forwarded to the desired URL destination if nothing triggers the local mechanisms, and to the URL server simultaneously. If the router has not received permission or denial by the time the destination URL replies with a web page, the router does not forward it, but instead holds it in its buffer until the reply comes from the URL server. If the URL server permits, the router allows the connection and maintains that URL in the cache. If the URL server denies, the router drops the connection, redirects the users, and gives them the reason the connection was denied. This cache improves the performance dramatically.
The commands for turning on URL filtering on the CBAC router follow:
[no] ip urlfilter server vendor websense/n2h2  [port ] [timeout ] 
[retrans ]
[no] ip urlfilter exclv-domain 

Example 5-2 shows an example of how to turn on URL filtering. The url-cache is by default 5000.
Example 5-2. Turning on URL Filtering

router(config)# ip inspect name firewall http urlfilter
router(config)# interface e1
router(config-int)# ip inspect firewall in


One final and important point on IP URL filtering: User-based restriction is not possible with N2H2. However, it is possible with Websense because Websense has a mechanism for getting the username to correspond to an IP address. In addition to recognizing the users based on IP, Websense also can redirect the users for authentication before permitting the access to the website.
This concludes the discussion on security services that are provided by the CBAC for the single channel protocols. In the following sections, you will learn some of the security features that are applicable for both single- and multi-channel protocols. But before that, it is important to re-visit the discussion of multi-channel protocols.

Multi-Channel Protocol Inspection

Unlike the single-channel protocols discussed earlier, multi-channel protocols require you to configure for inspection on the application layer protocol. For example, if you inspect only TCP for FTP connection, the control channel becomes built up, because FTP is a TCP protocol. However, the data channel may not become built up because it depends on the port negotiation using the control channel, and if only TCP is inspected, CBAC does not watch the payload of the packet to gain knowledge of this port negotiation.
Hence, the TCP engine will not have any knowledge about the port and IP address information negotiated and agreed upon by the FTP client and server to build up the data channel. Consequently, CBAC does not open any hole on the ACL. So, if the data connection is initiated from outside, it will be dropped. Therefore, to inspect the payload and get all the necessary information for the data channel, you need to inspect the application layer protocol, which is in this case ip inspect name myfw FTP. Note that application inspection takes precedence over Layer 4 protocol inspection. In the example, because you inspect FTP protocol, you do not need inspection for TCP protocol. However if you inspect both TCP and FTP, only the FTP inspection engine is used, not TCP.
The section that follows discusses some of the important security services available for both single- and multi-channel protocols.

NAT/PAT and CBAC

CBAC interoperates with both static and dynamic NAT (source and destination). Static and Dynamic NAT with CBAC turns Cisco IOS Router into a very powerful enterprise class firewall. Here are a couple of the benefits NAT adds to CBAC:
  • Hides your internal addresses from the outside world.
  • Helps stop spontaneous attacks from the Internet because no traffic is allowed (static translation is an exception). Dynamic NAT allocates addresses only for nodes that have actually sent traffic through the router.

Port Application Mapping (PAM) and CBAC

Port Application Mapping (PAM) allows you to change the standard application port on the router. This is important for hiding well-known port numbers for different applications such as TCP/80 for the HTTP protocol. By default, PAM generates a table of information that identifies specific applications with specific TCP or UDP port information. The PAM table initially is populated with system-defined mapping information, when the firewall router first starts. Example 5-3 shows the output of the default port to application. CBAC works well with this standard port and creates session information based on this.
Example 5-3. Output of System Defined Port CBAC Works With

Router#show ip port-map
Default mapping: dns              port 53                    system defined
Default mapping: vdolive          port 7000                  system defined
Default mapping: sunrpc           port 111                   system defined
Default mapping: netshow          port 1755                  system defined
Default mapping: cuseeme          port 7648                  system defined
Default mapping: tftp             port 69                    system defined
Default mapping: rtsp             port 8554                  system defined
Default mapping: realmedia        port 7070                  system defined
Default mapping: streamworks      port 1558                  system defined
Default mapping: ftp              port 21                    system defined
Default mapping: telnet           port 23                    system defined
Default mapping: rtsp             port 554                   system defined
Default mapping: h323             port 1720                  system defined
Default mapping: sip              port 5060                  system defined
Default mapping: smtp             port 25                    system defined
Default mapping: http             port 80                    system defined
Default mapping: msrpc            port 135                   system defined
Default mapping: exec             port 512                   system defined
Default mapping: login            port 513                   system defined
Default mapping: sql-net          port 1521                  system defined
Default mapping: shell            port 514                   system defined
Default mapping: mgcp             port 2427                  system defined

However, you may change the default port for an application to something different. For example if you want to change the Telnet port from 23 to 1025, you need to use the following command:
ip port-map telnet port 1025

Without PAM, the firewall is limited to inspecting traffic using only the well-known or registered ports associated with an application. PAM enables you to customize network access control for specific applications and services.
PAM supports host- or subnet-specific port mapping, which allows PAM to be applied to a single host or subnet using ACL. Host- or subnet-specific port mapping is done using standard ACLs. Example 5-4 shows how to change the default port for FTP.
Example 5-4. Sample Configuration Required to Change the Port

! Following command shows the default port used for telnet
Router#show ip port-map ftp
Default mapping: ftp           port 21                  system defined

Router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
! Following access-list will be used to use a different FTP port for host IP address
  20.1.1.1
Router(config)#access-list 10 permit host 20.1.1.1
! Following command configure port 1022 for FTP connection based on ACL just created.
Router(config)#ip port-map ftp port 1022 list 10
Router(config)#end
! Following command verifies the FTP port just defined for the access-list 10
Router#show ip port-map ftp
Host specific:   ftp              port 1022   in list 10   user defined
Default mapping: ftp              port 21                  system defined

Router#

Note that with PAM, if you need to define multiple ports for an application, you need to define them with multiple commands.

Denial of Service (DoS) Detection And Prevention

DoS attack may be launched against a network in many different ways. Some of the most common DoS attacks that can be mitigated by CBAC are discussed in the sections that follow.
TCP Syn Flood and DoS Attack Launched by UDP
For a normal TCP connection to be considered established, TCP three-way handshakes must be completed (SYN, SYN-ACK, and ACK). For UDP, you need both REQUEST and REPLY packets to establish the connection. While waiting for the ACK to the SYN ACK, a connection queue of finite size on the destination host keeps track of connections waiting to be completed. The TCP SYN attack exploits this design by having an attacking source host generate TCP SYN packets with random source addresses toward a victim host. The victim destination host sends a SYN ACK back to the random source address and adds an entry to the connection queue. Because the SYN ACK is destined for an incorrect or non-existent host, the last part of the "three-way handshake" is never completed, and the entry remains in the connection queue until a timer expires. By generating invalid TCP SYN packets from random IP addresses at a rapid rate, it is possible to fill up the connection queue and deny TCP services (such as e-mail, file transfer, or WWW) to legitimate users. This affects the router's performance, which can result in the slowness of legitimate traffic and sometimes packet drops due to shortage of memory and high CPU utilization. It is not very easy to mitigate these types of attack. However, CBAC has a couple mechanisms to deal with these types of attacks:
  • Timeout values CBAC has different timeout values to clear up the unnecessary sessions that use up a lot of memory and buffer. To choose timeout values carefully, you must baseline your network under normal conditions. Selecting appropriate timeouts can help to mitigate the stress on the router and on the victim hosts from DoS attacks. Here are the timeout values available on the CBAC router:
    ip inspect tcp idle-time seconds
    ip inspect udp idle-time seconds
    ip inspect dns-timeout seconds
    ip inspect tcp synwait-time seconds
    ip inspect tcp finwait-time seconds
    
  • Threshold Values Along with selecting appropriate timeouts, CBAC has the following options to define threshold values to mitigate the DOS attack.
    ip inspect max-incomplete high number
    ip inspect max-incomplete low number
    ip inspect one-minute high number
    ip inspect one-minute low number
    ip inspect tcp max-incomplete host number block-time minutes
    
    The first and second lines define the max incomplete high and max incomplete low thresholds. If the high threshold is crossed, the oldest half of the open session is deleted to make way for each new coming session, until half of the open count falls under the low threshold. The third and fourth lines define the high and low threshold per minute. This means that when the half-open connection reaches the high mark, the router goes into aggressive mode, sends alerts to syslog, and starts deleting the oldest half-open connection until it reaches to the low mark. Max-incomplete and one-minute apply to both TCP and UDP half-open sessions. A one-minute value is calculated by taking a reading every 15 seconds (4 times a minute) of the connection attempts to the router. The fifth line, TCP max-incomplete, works on a per host basis and is restricted only to TCP traffic. This means that the fifth line does not count UDP traffic. TCP max-incomplete replaces sessions if block-time is not specified or zero. If a value is specified, CBAC deletes all sessions and blocks the connection for the specified amount of time.
Example 5-5 shows that the CBAC router has detected a DoS attack, going to aggressive mode, and then calming down:
Example 5-5. Sample Alert Output of a DoS Attack

%FW-4-ALERT_ON: getting aggressive, count (550/500) current 1-min rate: 250
%FW-4-ALERT_OFF: calming down, count (0/400) current 1-min rate: 0

A combination of %FW-4-ALERT_ON and %FW-4-ALERT_OFF error messages indicates a single attack. Example 5-5 shows a single DoS attack.
Example 5-6 shows that a sample output of a denial-of-service attack has occurred on a specific TCP host:
Example 5-6. Sample Output of a DoS Attack Against a Single TCP Host

%FW-4-HOST_TCP_ALERT_ON: Max tcp half-open connections (50) exceeded for host 172.21.127.242.
%FW-4-BLOCK_HOST: Blocking new TCP connections to host 172.21.127.242 for 2 minutes 
(half-open count 50 exceeded)
%FW-4-UNBLOCK_HOST: New TCP connections to host 172.21.127.242 no longer blocked

Fragmentation
Fragmentation of IP packets is handled differently depending on the version of the IOS you are running on the router. The following discusses two options available on an IOS Firewall for handling fragmented packets:
  • Without Virtual Reassembly Option Before version 12.3(8) T, this Virtual Reassembly of fragmented packets was not available. The router maintains a table of fragmented IP packets. It protects aggressively by dropping secondary fragments unless the first fragment is seen. It also drops fragments that make total IP length greater than 65535. If there are fewer than 32 entries free in the table, configured timeout value is internally halved, and if there are fewer than 16 entries free in the table, timeout is set to 1 second. Fragmented packets are not inspected for L4 and L7 inspection.
  • With Virtual Reassembly Option As discussed earlier, before version 12.3(8) T, CBAC could not identify the contents of the IP fragments nor could it gather port information from the fragment. These inabilities allowed the fragments to pass through the network without being examined, or without dynamic access control list (ACL) creation. From version 12.3(8) T and above, virtual fragmentation reassembly (VFR) enables the Cisco IOS Firewall to create the appropriate dynamic ACLs, thereby protecting the network from various fragmentation attacks. VFR is on by default when NAT is configured on an interface. Otherwise, you can turn it on/off with the following commands under the interface.
    ip virtual-reassembly [max-reassemblies number] [max-fragments number]
      [timeout seconds] [drop-fragments]
    
    A more detailed discussion of this feature can be found at:
Note
Keep in mind that after you apply the CBAC rule in an interface to a specific direction, DoS prevention is on by default only for that interface and for that direction.

Real-Time Alerts and Audit Trails

Alerts identify suspicious activities such as protocol violation, DoS attack, and so on. Alerts is on by default, and the alerts are by default sent to the console. If syslog is configured, alerts can also be sent to a syslog server.
The following commands can be used to turn off the global alert and can be turned on/off per protocol basis.
ip inspect alert-off
ip inspect name  protocol [alert <on | off>]

Note that alert configuration per protocol configuration gets higher priority than the global alert. Global alert configuration is on by default, so if you want to turn off alert configuration for a specific protocol, you need to execute the second line shown in the previous code sample. Example 5-7 shows the alerts of various protocols:
Example 5-7. Sample Output of Alerts by Different Protocols

! Sample HTTP (Java Block) alert
%FW-3-HTTP_JAVA_BLOCK: JAVA applet is blocked from (172.21.127.218:80) to
(171.69.57.30:44673)
! Sample FTP alerts
%FW-3-FTP_SESSION_NOT_AUTHENTICATED: Command issued before the session is
authenticated -- FTP client 30.0.0.1
%FW-3-FTP_PRIV_PORT: Privileged port 1000 used in PORT command -- FTP client
30.0.0.1 FTP server 40.0.0.1
%FW-3-FTP_NON_MATCHING_IP_ADDR: Non-matching address 92.92.92.92 used in PASV
response -- FTP client 171.69.63.26 FTP server172.21.127.195
! Connection is reset for all of the above alerts except FW-! 3-
FTP_SESSION_NOT_AUTHENTICATED
! Sample SMTP alerts
%FW-4-TCP_SENDMAIL_BAD_FROM_SIG: Sig:3102:Sendmail Invalid Sender -192.168.1.13 to
192.168.101.14
%FW-4-TCP_SENDMAIL_BAD_TO_SIG: Sig:3101:Sendmail Invalid Recipient -192.168.1.13 to
192.168.101.14
%FW-4-TCP_SENDMAIL_OLD_SIG: Sig:3104:Archaic Sendmail Attacks -192.168.18.215 to
192.168.118.216
%FW-4-TCP_SENDMAIL_DECODE: Sig:3105:Sendmail Decode Alias - 192.168.18.215 to
192.168.118.216
%FW-4-TCP_MAJORDOMO_EXEC_BUG: Sig:3107:Majordomo Execute Attack -192.168.18.215 to
192.168.118.216
%FW-3-SMTP_INVALID_COMMAND: Invalid SMTP command (ABCD\r\n)(total 6 chars) from
initiator (192.168.22.5:32952)
! Connection is reset for all of the above alerts

An audit trail is generated every time a session closes (gracefully or by timeout) with the following information:
  • Source and destination IP addresses and ports
  • Number of bytes exchanged in each direction
Unlike alerts, the audit trail is not on by default. You need to turn it on either in the global configuration or per protocol basis with the following commands.
ip inspect audit-trail
ip inspect name  protocol [audit ]

Example 5-8 shows how to turn on syslog on a Cisco router:
Example 5-8. Sample of How To Turn on Audit-Trail with Syslog on Router

Router(config)#logging on
Router(config)#logging 192.168.1.11
! To enable audit-trail of Firewall messages.
FWRouter(config)#ip inspect audit-trail

Just as with alerts, audit configuration per protocol receives higher priority than the global configuration.
Example 5-9 shows a sample output of audit trail:
Example 5-9. Sample Output of an Audit Trail

%FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.1.13:33192) sent 22 bytes
-- responder (192.168.129.11:25) sent 208 bytes
%FW-6-SESS_AUDIT_TRAIL: http session initiator (172.16.57.30:44673) sent 1599 bytes
-- responder (172.21.127.218:80) sent 93124 bytes

Interaction of CBAC with IPsec

Cisco IOS Firewall does not inspect IPsec (Internet Protocol Security) traffic that traverses it. You need to allow AHP, ESP and UDP/500 to allow from unprotected to protected network for the IPsec tunnel to be built up and process data across CBAC. Example 5-10 shows an ACL that allows all the ports/protocols needed to build up IPsec tunnel between 10.1.1.1 and 20.1.1.1 peers:
Example 5-10. Sample Output Of Configuration To Allow IPSEC

Router(config)#access-list 100 permit ahp host 10.1.1.1 host 20.1.1.1
Router(config)#access-list 100 permit esp host 10.1.1.1 host 20.1.1.1
Router(config)#access-list 100 permit udp host 10.1.1.1 host 20.1.1.1 eq isakmp

Although CBAC does not inspect IPsec going through it, it works well with IPsec end devices. So, if you configure CBAC on the peer routers, CBAC inspects the tunneled traffic before encryption and after decryption.

Transparent Cisco IOS Firewall

The transparent firewall works on Layer 2 information, not Layer 3 of the OSI model. From version 12.3(8) T, IOS Firewall is designed to simultaneously interoperate in both Layer 2 and Layer 3 modes.
You can configure a transparent firewall just like the current L3 firewall using the ip inspect command. The inspect in/out command can be configured on any of the bridged interfaces for Layer 2 protection while also being configured on any LAN or serial interfaces to provide traditional Layer 3 protection. The transparent firewall operates on the bridged packets, and the Layer 3 firewall continues to operate on the routed packets.
To understand the CBAC fully, you must be knowledgeable about all the commands and tools available to troubleshoot the CBAC issues. The section that follows leads you through a discussion of the tools and commands available to troubleshoot CBAC effectively and efficiently.

If You Enjoyed This Post Please Take a Second To Share It.

You Might Also Like

Stay Connected With Free Updates

Subscribe via Email

teaser