Chapter 9. Context-Based Access Control
In the last chapter, you were introduced to one method of providing stateful filtering with the Cisco IOS: reflexive ACLs (RACLs). This chapter focuses on Context-based Access Control (CBAC), one of the key features in the Cisco IOS Firewall feature set. As you will see at the beginning of this chapter, CBAC has many more features and fewer limitations than RACLs. Cisco recommends that you use CBAC instead of RACLs; you will understand why by the end of this chapter.
CBAC is just one of many features of the Cisco IOS Firewall feature set. The Cisco IOS Firewall also supports other features, including authentication proxy (Chapter 14, “Authentication Proxy”) and an intrusion-detection system (Chapter 16, “Intrusion-Detection System”). This chapter focuses only on CBAC, which implements the Cisco IOS Firewall feature set’s stateful filtering. I begin by introducing some Cisco IOS Firewall features, and then I discuss features specific to CBAC and how to configure CBAC.
Cisco IOS Firewall Features
The Cisco IOS Firewall feature set is a Cisco IOS add-on that provides enhanced security functions for your Cisco IOS device. It provides more features than a standard stateful firewall, setting it apart from small- or home-office firewall appliances. Basically, the Cisco IOS Firewall feature set enhances the router’s security by including features in the Cisco IOS that allow it to perform the functions of an enterprise firewall, such as the Cisco PIX. Here are some of the features included in the Cisco IOS Firewall feature set:
• CBAC—Provides stateful application layer filtering, including support for unorthodox protocols and multimedia applications. It can examine supported connections for embedded NAT and PAT information and perform the necessary translations. In addition, it can open additional stateful connections for supported applications, such as FTP and H.323.
• Port mapping—Allows the mapping of ports so that CBAC can perform its application inspection correctly, such as assigning HTTP to port 8080 if your web server is processing traffic on this port.
• Filtering of Java applets—Filters embedded Java applets on HTTP connections, allowing you to block known malicious sites (this is discussed in Chapter 10, “Filtering Web and Application Traffic”).
• DoS protection—Detects and prevents Denial of Service (DoS) attacks by limiting the number of connections that a device can set up (this is discussed in Chapter 17, “DoS Protection”).
• Authentication proxy—Authenticates and authorizes connection requests before permitting the traffic to enter or leave the network by prompting a user for a username and password (this is discussed in Chapter 14).
• Intrusion-detection system—Detects and prevents, in real time, 100 of the most common kinds of attacks (this is discussed in Chapter 16).
• Logging and auditing—Logs TCP and UDP transactions, and can provide real-time alerts of attacks, including packet and segment header information (this is discussed in Chapter 18, “Logging Events”).
• ACL compatibility—Offers backward compatibility with other ACL technologies, such as standard, extended, lock-and-key, and timed ACLs.
Of all these features, this chapter focuses only on CBAC.
Supported router platforms of the Cisco IOS Firewall feature set include the SOHO70, SOHO90, 800, uBR900, 1600, 1700, 2500, 2600, 3200, 3600, 3700, 7100, 7200, 7300, 7400, 7500, and 7600 series of routers. Supported switch platforms include the Catalyst 4000, 5000, 6000, and 8850 series of switches.
CBAC Functions
CBAC provides four main functions:
• Filtering traffic
• Inspecting traffic
• Detecting intrusions
• Generating alerts and audits
Filtering Traffic
One of the main functions of CBAC is to filter traffic intelligently, specifically for TCP, UDP, and, recently, ICMP connections. As with RACLs, one of its functions is to allow returning traffic into your network; however, it can be used to filter traffic that originates on either side of your router—internal or external.
Unlike extended ACLs, which can filter only on Layers 3 and 4, and RACLs, which can filter on Layer 5 (session layer) information, CBAC supports application inspection, meaning that it can examine the contents of certain kinds of packets when making its filtering decision. For example, it can examine SMTP commands in an SMTP connection. It also can examine a connection’s messages to determine the state of a connection. For example, FTP uses two connections, a control and a data connection. CBAC can examine the control connection, determine that a data connection is being created, and add this connection to its state table. CBAC supports many multimedia, as well as other applications, that perform this function. Likewise, CBAC can examine HTTP connections for Java applets and filter them, if so desired.
Inspecting Traffic
Actually, I already mentioned this feature in the last section: CBAC can inspect application layer information and use this to maintain its stateful firewall function, even for applications that open multiple connections or embed NATed addressing or port information in applications.
This inspection process not only allows returning traffic back into your network, but it also can be used to prevent TCP SYN flood attacks: CBAC can examine the rate at which connections are being made to a service and can shut down these connections if a specified threshold is reached. It also can examine TCP connections to make sure that sequence numbers fall within a certain range, dropping any suspicious packets. Besides examining TCP connections, it can examine traffic for DoS fragment attacks.
Detecting Intrusions
As I mentioned in the last section, CBAC can inspect traffic to implement a stateful firewall, but it also can use this feature to detect certain kinds of DoS attacks. CBAC even can provide protection against SMTP e-mail attacks, limiting the type of SMTP commands that can be sent to your internal e-mail servers. All of these kinds of attacks can cause CBAC to generate logging information about the attack, as well as optionally resetting TCP connections or dropping malicious packets.
Generating Alerts and Audits
CBAC can generate real-time alerts of problems and detected attacks, as well as provide a detailed audit trail of connection requests. For example, you can log all network connection requests, including the IP addresses of the source and destination, the ports used in the connection, the number of bytes sent, and at what time the connection started and ended.
Operation of CBAC
CBAC was introduced in Cisco IOS 12.0(5)T. To keep track of connections that it is monitoring, it builds a state table that contains information about each connection. This table is similar to the state table that the Cisco PIX uses. CBAC monitors TCP, UDP, and ICMP connections and maintains information in the state table for them. CBAC then uses the state table to build dynamic ACL entries to allow returning traffic back through the perimeter router/firewall. This is somewhat similar to RACLs; however, CBAC can inspect application layer information, whereas RACLs cannot. CBAC uses the state table and dynamic ACL entries to detect and prevent certain kinds of DoS attacks, especially those that involve TCP connection flooding.
Basic Operation
Take a look at a simple example to see how CBAC functions. I use the network shown in Figure 9-1 to illustrate this example.
These steps occur in this example:
1. A user initiates an outbound connection, such as a Telnet. If an inbound ACL is applied, this is processed first before any inspection by CBAC. Based on your inspection rules for CBAC, the Cisco IOS might or might not be inspecting the connection. If it is not inspecting the connection, the Cisco IOS allows the packet through; otherwise, the Cisco IOS proceeds to Step 2.
2. The Cisco IOS compares this connection to the entries in its state table: If this connection does not exist, the entry is added; if it exists, the Cisco IOS resets the idle timer for the connection.
3. If this is a new entry, the Cisco IOS adds a dynamic ACL entry on the external interface in the inbound direction, to allow the returning traffic into the network. These dynamic ACL entries are not saved to NVRAM.
Actually, this process appears to be very similar to how RACLs are processed. As with RACLs, CBAC opens temporary openings in your ACLs to allow returning traffic. These entries are created as inspected traffic leaves your network and are removed whenever the connection terminates or the idle timeout period for the connection is reached. As with RACLs, you can specify which protocol or protocols you want to inspect, as well as on which interface and in which direction the inspection should occur.
A new feature was introduced in Cisco IOS 12.3(4)T, called Firewall ACL Bypass (FAB). This feature was developed to speed up the Cisco IOS processing of traffic returning to the network. With the FAB feature, the Cisco IOS does not create dynamic ACL entries to allow returning traffic into the network. Instead, the Cisco IOS examines the state table to determine which traffic should be allowed back into the network, which can be handled by fast switching processes such as Cisco Express Forwarding (CEF). If the Cisco IOS does not find a match in the state table, the Cisco IOS uses the ACL applied inbound on the returning interface to enforce policies. By using this process, the router does not have to create and manage dynamic ACL entries on the returning interface: instead, the router only has to check the state table that it maintains. Starting in Cisco IOS 12.3(4)T, the FAB feature automatically is used and cannot be disabled.
Note
One nice feature of CBAC is that it is flexible in its configuration, especially in what direction you want to inspect traffic. In the most typical setup, you use CBAC on your perimeter router/firewall to allow returning traffic into your network. However, you can configure CBAC to inspect traffic in two directions—in and out. You might need to do this if you want to protect two parts of your network. In this example, you want both sides to initiate certain connections and allow the returning traffic to reach its originator.
CBAC Enhancements over RACLs
Unlike with RACLs, however, many additional things can occur while the Cisco IOS, using CBAC, is inspecting the traffic on the connection or connections in the state table. I already mentioned one, FAB, in which dynamic ACL entries are no longer necessary to allow returning traffic. This section covers some other enhancements that CBAC has over RACLs.
TCP Traffic
TCP is handled in the same manner with CBAC as is done with RACLs. With TCP, CBAC inspects the connection and examines the control bits in the TCP segment header. If it sees a teardown process (FIN), the Cisco IOS waits 5 seconds for the connection to be torn down gracefully, and then the dynamic ACL entry (before FAB) is removed from the external ACL and the corresponding entry in the state table is removed. If a TCP session is idle longer than 1 hour, the Cisco IOS removes the entry. One unique thing about CBAC, versus RACLs, is that CBAC also monitors the setup of a connection. With CBAC, the Cisco IOS expects the connection to be set up within 30 seconds (this is user-configurable) of seeing the first SYN segment. If the connection is not established during this time period, the Cisco IOS removes the entry from its state table and ACL.
Another difference is that CBAC examines the sequence numbers in TCP connections to make sure that they fall within an expected range. If they do not fall within an expected range, CBAC drops these packets and assumes that a spoofing or DoS attack is occurring.
UDP Traffic
With TCP, it is easy to determine the state of the connection by examining the control bits in the TCP segment header. However, UDP is connectionless, making the inspection process more difficult. As with RACLs, CBAC approximates the life of a UDP connection. It assumes that if no traffic is seen on a UDP connection for more than 30 seconds (this is user-configurable), the connection must have completed; therefore, the Cisco IOS removes the entry in the state table (and the dynamic ACL entry). This is similar to RACLs, with the exception of the default timeout. However, CBAC has one UDP enhancement over RACLs: it also inspects DNS queries and replies. With this feature, CBAC expects that when an internal device generates a DNS query, the remote DNS server will respond with a DNS reply within 5 seconds (this is user-configurable). If a reply is not seen in 5 seconds, the DNS connection entry is removed, to prevent spoofing. Likewise, when the DNS reply is seen from the DNS server, the Cisco IOS immediately removes the entry from its state table (and the dynamic ACL entry). These two enhancements are used to prevent DNS spoofing and DoS attacks.
ICMP Traffic
Inspection of ICMP traffic was introduced in Cisco IOS 12.2(11)YU and was integrated into 12.2(15)T. Before this, CBAC could inspect only TCP and UDP traffic. With ICMP inspection, CBAC can inspect common ICMP message types, including echo request, echo reply, destination unreachable, time exceeded, timestamp request, and timestamp reply messages. CBAC does not inspect other ICMP message types. When inspecting ICMP traffic, the Cisco IOS expects replies to the supported ICMP message types within 10 seconds. If none is seen, the ICMP connection is removed from the state table and the dynamic ACL entry is removed. However, if a response is seen, only the supported message types are allowed (based on the request); other message types are dropped.
Extra Connections
Certain applications, such as FTP and multimedia, open additional connections to transfer information. As mentioned in the last chapter, RACLs either do not handle these connections very well or do not handle them at all. CBAC, on the other hand, supports many of these types of connections. CBAC can inspect the control connection for these applications to determine whether a data connection or other connection is being opened. When CBAC notices the addition of a new connection, it automatically adds this information to its state table (as well as a dynamic ACL entry before FAB) to permit the connection through the router.
Figure 9-2 illustrates how this process is performed with standard, or active, FTP. As you recall from the last chapter, FTP supports two modes: standard and passive. This example focuses only on the use of an internal client using standard FTP to connect to an external server. The client opens a standard FTP connection, with a source port of 10,000, to the FTP server (21). CBAC inspects this connection and adds the appropriate entries to the state table and ACL. Whenever the user needs to download information, the server must open a connection back to the client (with standard FTP only). The user’s client software sends the source port to be used for the download to the server on the port 21 connection. CBAC inspects this information, realizes that a new connection will occur, and adds the appropriate entries in the state table and ACL on the returning interface (before FAB). In this example, the client said to use TCP port 10,005 when the server makes the connection from port 20 to the client. CBAC handles this process dynamically, and the traffic for the connection is permitted. I discuss supported protocols for this connection-inspection feature later, in the “Supported Protocols for CBAC” section.
Embedded Addressing Information
With supported applications, CBAC can also inspect connections to see if there is embedded addressing information, such as IP addresses or port numbers, and change these based on information the Cisco IOS has in its address translation table. Let’s look at a simple example, shown in Figure 9-3, where the router is using CBAC and is also performing address translation.
In this example, I use an imaginary application that uses two connections: one from the client to the server, and one from the server to the client. The router has set up network address translation to statically assign a global (public) address of 192.1.1.2 to the internal client, which is using a private address of 192.168.1.1. When the client initially makes the connection to the server, the Cisco IOS, using CBAC, builds the appropriate entries for the application connection to port 98. Across this connection, the client sends the source port number (10,005) and IP address (192.168.1.1) that the server should use to build the second connection from port 99. Obviously, if the server used this information, the connection would fail because the connection needs to be sent to the public address of 192.1.1.2, not 192.168.1.1.
In the Cisco IOS with FAB, the state table is processed first, then the ACL on the returning interface is processed, and, finally, the address translation occurs (if necessary). CBAC can address this issue by changing the address in the payload on the connection from the client to the server. The server then can respond to the correct address (192.1.1.1), allowing it to connect to the client. In this example, CBAC also would have to use its inspection to dynamically add the second connection to its state table and a dynamic ACL entry to allow the second connection (before FAB). This is similar to what was done in the standard FTP example in the last section. Besides supporting NAT, CBAC can handle PAT. Two restrictions with this feature are as follows:
• The router must be performing the address translation so that CBAC knows how to manipulate the addressing information in the packet payload.
• Not all applications are supported for this feature; with some, only certain types of address translation are supported, such as NAT instead of PAT.
Application Inspection
CBAC even can inspect application layer information to limit the interaction between two devices. A good example of this is the inspection support for SMTP. SMTP is defined in RFC 821 and is the de facto standard for sending e-mail across the Internet. However, SMTP has been hacked in the past and is an insecure protocol. To limit the exposure to your e-mail system, CBAC can inspect the SMTP commands sent between the two e-mail servers on the control connection. This is used to prevent access attacks. This feature is very similar to the Mail Guard feature that the PIX supports. With this feature, CBAC allows only certain SMTP commands. If any other SMTP command is sent, it is denied. The Cisco IOS responds to the sender with an SMTP NOOP message in this instance.
Note
Some e-mail systems support Extended SMTP (ESMTP), which provides enhanced functionality between e-mail systems. However, CBAC can inspect only SMTP, not ESMTP, commands. Therefore, if you have an ESMTP server, and outside servers are trying to send ESMTP commands to you, CBAC will deny them. In many cases, the external ESMTP server automatically downgrades itself and uses SMTP commands instead; however, if it does not, the e-mail server will not be capable of sending e-mail to you. Typically, this is a problem not with servers, but with the clients that use SMTP to send or retrieve e-mail messages. If you are inspecting e-mail and experience this problem, disable this CBAC inspection feature. I have had to disable this feature quite often with Microsoft Exchange connections.
DoS Detection and Prevention
CBAC can detect certain kinds of DoS flood attacks. When an attack occurs, the Cisco IOS can take any of the following three actions:
• Block the offending packets
• Protect the internal resource from becoming overloaded with fake connections
• Generate an alert message
To detect DoS attacks, CBAC uses timeout and threshold values to inspect the setup of TCP connections. When TCP connections are being established, they usually do not take more than a second or two. Therefore, if a lot of TCP SYNs are seen from a single source, a threshold can be set to restrict the number of these sessions. In addition, if the connections are not completed within a specific time frame (30 seconds, by default), the Cisco IOS removes this information from its state table and notifies both the source and destination with a TCP RST message on the connection. This is used, especially for your internal resource, to free up these half-open (commonly called embryonic) connections. You can define three different thresholds to limit the number of half-open connections:
• Total number of half-open TCP or incomplete UDP sessions
• Total number of half-open TCP or incomplete sessions over a period of time
• Total number of half-open TCP sessions per host
When these thresholds are reached, the Cisco IOS can start dropping incomplete connections that have not been deleted, notify the source and destination that the connections have been torn down (TCP RST), generate an alert, and/or block TCP traffic from the offending device(s). I discuss this CBAC feature more in Chapter 17.
Supported Protocols for CBAC
CBAC can perform inspection for many protocols and applications; however, the depth of its inspection is not necessarily the same for each protocol or application. Here is a list of supported protocols and applications:
• All TCP and UDP sessions, including FTP, HTTP with Java, SMTP, TFTP, and the UNIX R commands, such as rexec, rlogin, and rsh
• ICMP sessions, including echo request, echo reply, destination unreachable, time exceeded, timestamp request, and timestamp reply ICMP messages
• Sun Remote Procedure Calls (RPCs)
• Oracle SQL*Net
• H.323 v1 and v2 applications, including White Pine CU-SeeMe, Netmeeting, and Proshare
• Real-Time Streaming Protocol (RSTP), including applications such as RealNetworks RealAudio G2 player, Cisco IP/TV, and Apple QuickTime 4 software
• Other multimedia applications, including StreamWorks, NetShow, and VDOLive
• Voice over IP (VoIP) protocols, including the Skinny Client Control Protocol (SCCP) and the Session Initiation Protocol (SIP)
All TCP and UDP sessions are supported for inspection, which includes putting a connection’s information in a state table and dynamically adding an ACL entry for it (before FAB). For certain applications, such as FTP and SMTP, CBAC can perform additional inspection by restricting the control commands that are executed, fix nontranslated embedded addressing information, and examine control connections to see if additional connections are being set up.
Multimedia applications represent the biggest problem with stateful firewalls because they open multiple connections and sometimes embed addressing information in messages on the control connection. The Cisco IOS CBAC can inspect many of these applications and deal with their quirks, to allow secure connectivity.
RTSP Applications
The Real-Time Streaming Protocol (RTSP), defined in RFC 2326, defines how real-time data streams, such as voice and video, are delivered between devices. It typically is used in applications that need to deploy a large-scale broadcast solution, such as audio and video streaming. Applications that use RTSP include the RealNetwork RealAudio G2 Player, Cisco IP/TV, and Apple QuickTime 4 software.
RTSP uses three types of connections:
• Control—Used as the main messaging connection between the client and server. It supports both TCP and UDP; however, CBAC performs inspection only for TCP.
• Multimedia—Used to deliver audio, video, or data. These are UDP connections. Either the Real-Time Transport Protocol (RTP) or the Real Data Transport Protocol (RDT) is used to set up and maintain these connections. The Cisco IP/TV and Apple QuickTime 4 products use RTP. RDT was developed by RealNetworks and is used to manage the data connections and retransmission of missing packets. The RealNetwork RealServer G2 product uses RDT.
• Error—Can be either a unidirectional or bidirectional UDP connection that the client uses to request missing information or to synchronize audio and/or video streams, to prevent jitter problems.
RTSP clients typically use TCP ports 554 or 8554 to connect to the multimedia server. The client and server then dynamically negotiate the UDP port numbers (1024 to 65,535) for the multimedia streams. Figure 9-4 shows an example of the different types of methods to establish RTSP connections. The top part of this figure shows a connection between a client and server using RTP, the middle part with a client and server using RDT, and the bottom part with a client and server using only a TCP connection for all functions (this typically is used only for small-bandwidth applications).
CBAC monitors the control connection to determine when it should add additional connections to its state table, as well as its inbound external ACL (before FAB), and remove the connections.
H.323 Applications
CBAC supports inspection for H.323 version 1 and 2 applications. H.323 defines how to deliver voice, video, and/or data between devices. Unlike RTSP, H.323 is much more complicated. First, either a terminal device can use a server, called a gateway, to find other terminal devices that have content, or it directly can access another terminal device. Second, many more connections are set up between the two terminals when sharing multimedia information.
If a terminal is connecting to a gateway, it opens a TCP connection to port 1720. The gateway then opens a connection back to the terminal, using a dynamically negotiated ports for this second connection that is used to pass control information. The terminal uses this connection to discover the location of other terminals. Based on where the terminal wants to connect, the gateway negotiates the UDP port numbers between the two terminals. The source terminal then initiates the UDP connections to the destination terminal. These UDP connections are used to transport voice, video, and other data payloads. For each of these feeds, there is a separate UDP connection.
Instead of using a gateway, a terminal can connect directly to another terminal, assuming that the destination terminal is configured for this. In this instance, the source terminal opens a TCP connection to port 1720 on the destination terminal, and the remaining UDP multimedia connections that need to be set up are negotiated dynamically, including the port numbers used for these connections. Figure 9-5 illustrates the connections set up directly between two terminals.
With CBAC, the Cisco IOS inspects the TCP 1720 command connection to determine what additional connections are being established between terminals or gateways. Then it adds the appropriate entry or entries in its state table and dynamically adds the necessary ACL statement(s), before FAB, to allow these additional connections. CBAC also monitors the command connection to determine when the primary or secondary connections no longer are needed, and removes them from the state table and the corresponding dynamic ACL (before FAB) from the inbound external ACL.
Skinny Support
Skinny is a Cisco-proprietary protocol that was developed to support Cisco VoIP phones and their connectivity. With Cisco IP phones, a server runs the CallManager (CM) software. CM has all the phone configurations, as well as their location information. Using DHCP, when a Cisco IP phone boots up, it acquires its IP addressing information as well as the IP address of the CM server.
Figure 9-6 illustrates the connections set up with Skinny. First, the IP phone registers itself with CM (by its IP address) and its identification information. It does this by setting up a TCP connection (port 2000) to CM. This connection remains up until the IP phone is rebooted. If the phone needs additional configuration, CM can function as a TFTP server, holding the phone’s configuration on its disk drive. The IP phone then can use TFTP to download its configuration file.
After it has registered with CM, an IP phone can make phone calls to other IP phones. When making a call, the IP phone contacts the CM and tells it the destination phone that it wants to connect to, as well as the source UDP port number that the phone will use. The CM contacts the destination IP phone and informs it of the new connection request. Assuming that the phone is in an on-hook state, the destination IP phone passes back the UDP port number that the source phone should use, which, in turn, the CM passes to the source phone. The source phone then establishes the connection to the destination.
CBAC supports inspection of Skinny connections as of Cisco IOS 12.3(1). With inspection, CBAC inspects the control packets exchanged between the client IP phone and CM. Based on this inspection, CBAC adds (and removes) the necessary entries in the state table and dynamic ACL entries (before FAB) to allow the voice connection to be set up (and torn down) directly between the two IP phones. Some restrictions with Skinny include the following:
• A music-on-hold server, if used, must be installed on the CM: it cannot reside on another device.
• The firewall router with CBAC cannot be the CM because CBAC inspection can inspect only connections going through the router, not connections that terminate on the router.
• The CM and the two IP phones making the connection cannot be on three different networks that are separated by the router/firewall with CBAC. Inspection works only if the three devices are connected to no more than two interfaces on the CBAC router.
SIP Support
SIP is a standards-based protocol that defines the interaction between a VoIP phone, VoIP gateway, and other VoIP phones; it is specified in RFC 2327. SIP defines how to establish, maintain, and tear down phone calls using VoIP.
Figure 9-7 illustrates the connections set up with SIP. First, the client sets up either a TCP or UDP connection to the VoIP gateway (destination port 5060). This is the signaling connection and is used to send call setup and teardown messages to the gateway. After establishing the signaling connection, the VoIP phone can make phone calls. It does this by using the signaling channel to initiate the connection through the gateway. The IP phone sends an unused UDP port greater than 1023 to the gateway, along with the identification of the device that it wants the call. The gateway then contacts the destination IP phone and requests the UDP port number on the destination that the source should use. The gateway passes both the destination IP address and the port number back to the source on the signaling channel. The source IP phone then establishes the phone connection directly to the destination phone. As you can see from this process, the call setup is very similar to that of Skinny.
CBAC supports the inspection of SIP connections as of Cisco IOS 12.2(11)YU and 12.2(15)T. CBAC inspects the control packets exchanged between the VoIP phone and VoIP gateway. Based on this inspection, CBAC adds (and removes) the necessary entries in the state table and dynamic ACL entries (before FAB), to allow the voice connection to be set up directly between the two IP phones. Some restrictions with SIP include the following:
• Although SIP supports connections based on DNS names and IP addresses, CBAC supports only connections that specify IP addresses for phone connections. Therefore, the gateway must pass back an IP address of the destination phone.
• SIP supports both TCP and UDP for the signaling connection. However, CBAC supports only UDP (port 5060, by default).
CBAC Performance
Given all of the inspection features that CBAC supports, this can put a large burden on your router, especially in a large network that has many simultaneous sessions that CBAC must maintain. For each session that the router must keep track of, an additional 600 bytes of memory are required to the entry in the state table. If your router must support thousands of connections, your router’s memory requirements will be high, as will the CPU cycles needed to handles all of these entries.
CBAC provides for three performance-improvement features, however, to help with reducing the overhead and load on your firewall router:
• Throughput improvement
• Connections per second improvement
• CPU utilization improvement
Throughput Improvement Feature
Throughput, from the CBAC perspective, is defined by the number of packets transferred from one interface to another interface over a 1-second interval. CBAC uses a hash table to perform the lookup process to determine what session a packet is associated with. The issue of using a hashed table is that multiple session entries might match to the same hash value, thereby slowing down the search function of CBAC. When more then one connection entry matches the same hash value, this is called a collision. The more collisions that occur, the longer it takes to find a match, and, thus, the lower your throughput becomes. This is especially true as your connection table becomes larger.
The throughput performance feature of CBAC enables you to dynamically change the size of the hash table that references the connections without having to reboot the router. This feature is new in Cisco IOS 12.2(8)T and is configured using the following command:
Router(config)# ip inspect hashtable hash_number
The hash number that you configure specifies the number of buckets that the hash table uses. A bucket is basically a reference to one or more sessions. The more buckets you have, the less likely it is that you will experience collisions. The default number of buckets is 1024; this can be changed to 2048, 4096, or 8192.
Tip
The hash table size should be approximately the same number as the total number of concurrent sessions that CBAC is maintaining. If you set the size to a larger size and then later determine that the average number of concurrent sessions is smaller, you dynamically can change the bucket size. Typically, when the number of concurrent sessions falls to below half of the current size, you should adjust the table size downward.
Connections Per Second Improvement Feature
CBAC measures the number of short-lived connections that are created or deleted over a 1-second interval. CBAC can measure only connection-oriented connections. Therefore, only TCP connections are counted; UDP and ICMP are not. Normally, CBAC would process-switch packets for the first few initial TCP packets in adding or removing a connection from the state table. Then packets would be switched normally using whatever switching method was enabled on the router or its interfaces, including CEF. However, the problem with this approach is that it affects the performance of the router, especially if it was hit with hundreds of simultaneous TCP setup or teardown requests.
A good example of this is if your users constantly access Internet web servers. With HTTP, a single downloaded page could include dozens of small HTTP connections, each lasting a second or two. With hundreds of people simultaneously trying to download pages from a website, this seriously could degrade the performance of your router as CBAC is adding and then immediately deleting these connections from the state table.
The connections per second improvement feature reduces the number of packets that have to be processed switched to 1: only the first packet in the session is processed-switched (all packets after that are processed normally). This feature provides a significant boost in performance when your router experiences many short-lived connections, such as HTTP. This feature is new in Cisco IOS 12.2(8)T.
CPU Utilization Improvement Feature
Maintaining a low CPU utilization is important for a router using CBAC, especially when it has to handle hundreds or thousands of sessions. Cisco recently rewrote the code for identifying new sessions and how they are added and removed from the state table, reducing the number of CPU cycles required to process the connection. As mentioned in the discussion of the first feature, Cisco allows you to dynamically change the size of the hash table to reduce the likelihood of collisions that occur when the Cisco IOS is performing a CBAC state table lookup. As mentioned in the last section, the Cisco IOS reduces the number of times that it must perform process switching by doing this only on the first packet of a session. All other packets are switched normally, which means that fewer CPU cycles are required per packet and session. The CPU utilization feature also was introduced in Cisco IOS 12.2(8)T.
CBAC Limitations
Even with all of its features and enhancements, CBAC is not an ultimate firewall solution. In other words, it has limitations and cannot protect you from all kinds of attacks. Actually, this is true of any firewall product. Understanding the limitations of CBAC and the Cisco IOS Firewall feature set will help you better understand whether this solution is a better fit for you network, whether this solution will complement the security solution in your network, and whether a different product would be better for your network.
Here are some of the limitations of CBAC:
• It inspects only the traffic that you specify. This is both an advantage and disadvantage. It enables you to control the overhead that CBAC places on your router, as well as the traffic that is allowed to return. To make it an all-encompassing product, however, you need to configure many inspect statements to fully cover all connection types.
• CBAC is not simple to understand and implement: it requires detailed knowledge of protocols and applications, as well as their operation.
• As with ACLs, the Cisco IOS cannot use CBAC to inspect traffic that the router itself originates.
• CBAC does not inspect packets sent to the router itself. Traffic must flow from one interface to another for inspection to occur.
• CBAC cannot inspect encrypted packets, such as IPSec. However, if the VPN connection terminates on the router, it can inspect traffic entering and leaving the VPN-encrypted tunnel.
• CBAC cannot inspect FTP three-way transfers: it can inspect only passive or standard two-way transfers.
• CBAC does not support inspection for all applications. For certain applications, you need to disable inspection for them to function correctly.
• CBAC supports only process, fast, flow, and CEF switching.
• CBAC ignores ICMP destination unreachable messages.
• The Cisco IOS does not support a stateful failover feature for the state table, as the Cisco PIX does. If a router fails, you can have a redundant router, but the state table is not duplicated between the two. In this instance, the state table must be rebuilt on the second router, causing some connections to fail and requiring users to rebuild those connections.
CBAC Configuration
This section covers the configuration of CBAC for stateful inspection and filtering. Unlike the configuration of RACLs, discussed in the last chapter, the configuration of CBAC is more complicated; there are many more commands with many more options that you either must or can configure.
Following this section, I cover some examples on how you would use CBAC to implement a stateful firewall. Note that this chapter focuses only on the use of CBAC for filtering. I discuss some of CBAC’s other inspection features, such as DoS detection and prevention, in Chapter 17.
To simplify the configuration process, I have divided the configuration process into seven simple steps:
Step 1 Determine which interfaces will be internal and external on your router.
Step 2 Create your normal IP ACLs to filter traffic entering and leaving your network. Make sure that you permit the traffic that is to be inspected as it is leaving your network.
Step 3 Change the global timeout values for connections. This is optional.
Step 4 Configure Port Application Mapping (PAM), which specifies the port numbers that CBAC should inspect if the application is using a nonstandard port number, such as HTTP with 8080. This is optional and is required only if your application is using a nonstandard port number.
Step 5 Define your inspection rules. These rules define what entries are added to the state table and what returning traffic is allowed back in. If outbound traffic does not match an inspection rule, the router does not inspect it and treats it as normal traffic.
Step 6 Activate the inspection rule or rules on your router’s interface(s). The router then will use CBAC to inspect traffic.
Step 7 Test your configuration by sending traffic through your CBAC router. Even though this is optional, I highly recommend it. The only way that you will find problems is by scrutinizing your configuration and implementation by sending test packets through the router.
Caution
Configuring CBAC is not simple. You need to have a very good understanding of how CBAC works, including the inspection process, if you want to reduce the likelihood that you will make configuration mistakes. Configuration mistakes on your part, whether they are inadvertent or the result of trying to get a specific application to work, could open your router and network to security threats. Therefore, take the appropriate amount of time to plan, configure, implement, and test your CBAC policies.
Step 1: Interface Selection
One of the first CBAC tasks that you need to accomplish is to determine which interface is internal and which is external. In this context, internal is where the connections originate, and external is where the returning traffic of these connections will be coming from.
Tip
If you will be configuring two-way CBAC—filtering traffic in two directions—I highly recommend that you first configure one-way CBAC and get this to function correctly before adding the second direction. Two-way configurations are common in intranet and extranet environments.
Step 2: ACL Configuration
In Step 2, you configure your ACLs to filter traffic entering and possibly leaving your network. These ACLs contain many of the filtering suggestions covered in Chapter 7, “Basic Access Lists,” such as bogon filtering.
Tip
My recommendation is first to create a basic ACL configuration that allows the necessary traffic into and out of your network, and then add the bogon and other filters for a more robust security solution. This simplifies your CBAC troubleshooting process. After you add your additional filters, continue by adding CBAC to your configuration. This ensures that you easily can narrow any connectivity issues to either your ACL or your CBAC configuration.
After you have configured your filtering ACLs, you need to activate them on your router’s interfaces. However, there is one restriction on the use of ACLs and their applications when using CBAC.
On the external interface inbound and the internal interface outbound, only an extended ACL can be applied. For any other situation, you can use either standard or extended ACLs. This means that, for the internal interface inbound and the external interface outbound, you can use either standard or extended ACLs applied in either direction—in or out. Figure 9-8 displays the appropriate use of ACLs.
Note
Unlike RACLs, CBAC’s ACLs can be either named or numbered.
Step 3: Global Timeouts
Optionally, you can change the timeout for connections in the state table (and the dynamic ACL entries, before FAB) with the following CBAC inspection commands:
Router(config)# ip inspect tcp synwait-time #_of_seconds
Router(config)# ip inspect tcp finwait-time #_of_seconds
Router(config)# ip inspect tcp idle-time #_of_seconds
Router(config)# ip inspect udp idle-time #_of_seconds
Router(config)# ip inspect dns-timeout #_of_seconds
The ip inspect tcp synwait-time command specifies how long the Cisco IOS waits for a specific TCP session to be established (to complete the three-way handshake). The default is 30 seconds. If the three-way handshake does not complete by the end of this timeout, the Cisco IOS removes the entry from its state table and the dynamic entry in the ACL (before FAB), and it notifies both parties that the connection has been terminated.
The ip inspect tcp finwait-time command specifies how long the Cisco IOS waits to remove an entry from its tables when the source or destination begins the teardown process of a TCP session. The default is 5 seconds. When the Cisco IOS sees that a connection is being torn down, it gives the two devices this time period to tear down the connection before removing the entry from the state table and the corresponding dynamic entry from the ACL (before FAB).
The ip inspect tcp idle-time command specifies how long the Cisco IOS maintains an idle TCP connection in its state table. An idle connection is one that is established but has no traffic traversing it. The default is 3600 seconds (1 hour). When the idle period expires, the Cisco IOS removes the entry from the state table and the corresponding dynamic entry from the ACL (before FAB).
The ip inspect udp idle-time command specifies how long the Cisco IOS maintains an idle UDP connection in its state table. The default is 30 seconds. After the idle period expires, the Cisco IOS removes the UDP entry from the state table and the corresponding dynamic entry from the ACL (before FAB).
The ip inspect dns-timeout command specifies how long the Cisco IOS maintains a DNS query connection in its state table. The default is 5 seconds. When this time period expires, the Cisco IOS removes the DNS query entry from the state table and the corresponding dynamic entry from the ACL (before FAB). This timer supercedes the UDP idle timer. This timer is used to prevent IP spoofing of DNS responses, providing a smaller window for a hacker to spoof DNS responses and, thereby, redirecting an internal device to the wrong service.
Note
It is important to point out that CBAC is stateful for TCP connections, but it must approximate UDP and ICMP connections. It does this for “connectionless” sessions by assigning an idle period to them. Also, there is no global timeout command for ICMP traffic; this is configured on an inspection-by-inspection basis and is discussed later.
Step 4: Port Application Mapping
CBAC uses PAM to determine what type of inspection should be performed on a connection. For example, the default application associated with port 25 is SMTP; therefore, CBAC understands, by default, that e-mail is used on this connection and, consequently, can inspect the connection for the appropriate SMTP commands. As another example, the control connection for FTP is TCP 21. Again, CBAC understands that this is used by FTP and performs the appropriate inspection on this connection.
PAM is used to remap ports to or associate additional ports with a specific application so that CBAC can perform the appropriate inspection on the connection. As an example, you might have a web server running on port 8080. By default, CBAC treats this as a normal TCP connection. To have CBAC inspect the connection and treat it as an HTTP connection, you need to associate port 8080 with HTTP.
PAM is the process used to map nonstandard ports to applications so that CBAC can perform the appropriate type of inspection. PAM can be used to associate either TCP or UDP ports to applications. PAM even enables you to assign ports on a host-by-host basis to a specific application. For example, you might have only one HTTP server running on port 8080. You can use PAM to associate only this port on this server for CBAC HTTP application inspection; any other TCP 8080 port on any other device would be treated as a normal TCP connection. With this feature, you greatly reduce the amount of inspection that CBAC has to perform by limiting it to just those devices using the nonstandard ports.
PAM Table
Port mappings are placed in the PAM table, and CBAC uses this table to perform the appropriate inspection on a connection. Three types of entries are used in this table:
• System-defined entries—These are the well-known port numbers of applications, such as TCP port 80 for HTTP. These entries cannot be deleted or changed. For example, you cannot assign SMTP port 25 to be inspected on port 80, or HTTP port 80 to 25; however, you can override the system-defined entries on a host-by-host basis (see the last point in this list). Table 9-1 lists the system-defined entries in the PAM table.
• User-defined entries—These are applications running on nonstandard port numbers, such as a web server running on ports 8000 or 8080. You easily can create these entries in the PAM table to accommodate all connections with the specified port number. You also can map ranges of ports to a specific application.
• Host-specific entries—These are a subset of user-defined entries, where the PAM mapping maps only a connection or connections for a specific host or hosts, but not all connections using the same port number. This enables you to limit the inspection that CBAC does for a specific application. For example, you might have two applications running on port 8080: a web server and a home-grown application. With PAM, you can put an entry in the table for port 8080 for just the web server. This causes CBAC to use HTTP inspection on port 8080 for the web server and normal TCP inspection for 8080 on all other devices.
PAM Configuration
Configuring PAM is necessary only if you are running an application on a nonstandard port and want CBAC to inspect this connection. The configuration is straightforward:
Router(config)# ip port-map application_name port port_# [list acl_#]
First, you must specify the name of the application (supported applications are listed in Table 9-1), followed by the port number. To remap more than one port to an application, repeat the command with the next port number. Optionally, you can associate a standard ACL with the PAM remapping. This standard ACL contains the IP addresses of devices that use the nonstandard port number. Put permit entries in the ACL to match on those devices that use the nonstandard port number and deny entries for those that do not; remember that there is an implicit deny at the end of this ACL. If you omit the ACL, CBAC assumes that any traffic on the specified port should be inspected per the configured application.
I have had issues in the past with different versions of the Cisco IOS when I have updated the PAM table and the Cisco IOS did not accept my changes until I saved my configuration and rebooted the router. If you experience this problem, repeat the process I performed.
PAM Verification
After you have configured your port mappings with PAM, you can view them with any of the following commands:
Router# show ip port-map
Router# show ip port-map application_name
Router# show ip port-map port port_number
Example 9-1 displays the contents of the PAM table.
Example 9-1 Viewing the PAM Table
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: cuseeme port 7648 system defined
Default mapping: tftp port 69 system defined
Default mapping: https port 443 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
<--output omitted-->
Example 9-1 shows a partial listing of the system-defined entries.
PAM Examples
Now you can take a look at an example where PAM is necessary, using the network shown in Figure 9-9.
Example 9-2 shows the configuration to set up PAM.
Example 9-2 Using PAM and ACLs to Restrict CBAC Inspection
Router(config)# ip port-map http port 8080 list 1
Router(config)# access-list 1 permit 192.1.1.2
Router(config)# ip port-map http port 8090 list 2
Router(config)# access-list 2 permit 192.1.1.3
In Example 9-2, 192.1.1.2 is running a web server on port 8080 and 192.1.1.3 is running a web server on port 8090. The first two commands associate port 8080 HTTP inspection with 192.1.1.2, and the last two commands associate port 8090 HTTP inspection with 192.1.1.3.
Step 5: Inspection Rules
The heart of CBAC is the inspection rules that you define. Inspection rules define what traffic CBAC should inspect. When inspecting traffic, new connections are placed in the state table, and dynamic ACL entries are created (before FAB) to allow for the return of traffic. Inspection can restrict commands executed on a connection, open secondary connections for an application, perform address translation of embedded addressing information, and prevent certain kinds of attacks.
Note
By default, there are no predefined inspection rules: You must create them manually. If you do not define an inspection rule for a particular connection, CBAC does not inspect it and this traffic is treated normally.
Inspection Rule Components
The general syntax of an inspection rule is as follows:
Router(config)# ip inspect name inspection_name protocol
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Inspection rules are created with the ip inspect name command. The syntax of the previous command is used for inspections of all types of traffic, with the exception of Java, URLs, and RPCs (I discuss these later in the following sections).
Rules are grouped with an inspection_name. This name is similar to the name or number used in an ACL: It associates statements with a particular grouping. Normally, you create one grouping of inspection rules because most companies are concerned about providing a stateful function for a two-interface perimeter router. However, if you need to filter traffic between two networks in an intranet or extranet, or if you have a three-interface router configuration, you typically need to create more than one rule set.
Following the name of the inspection is the name of the protocol or application that you want CBAC to inspect (protocol). For protocols and applications, you can specify the following: cuseeme, fragment, ftp, h323, http, icmp, netshow, rcmd (UNIX R commands), realaudio, rpc, rtsp, sip, skinny, smtp, sqlnet, streamworks, tcp, tftp, udp, and vdolive.
Optionally, you can enable or disable alerts and audits on a per-application or per-protocol basis with the alert and audit keywords. If you omit these parameters, CBAC uses the default configuration defined with the ip inspect alert and ip inspect audit-trail commands, respectively. These commands are discussed later in the “Alerts and Audits” section.
The last optional parameter is the timeout parameter. If you omit this, it defaults to the timeout value configured with the commands discussed previously in the “Step 3: Global Timeouts” section.
The following sections discuss some of the most important and most common inspection rules that you can configure with CBAC.
Generic TCP and UDP Inspection
You can configure generic TCP and UDP inspection of connections. With generic inspection, CBAC performs only connection inspection: It adds new connections to the state table and a dynamic ACL entry to the external ACL, and removes this information upon termination or timeout of the connection.
With generic inspection, CBAC does not monitor what actually is occurring on the connection, such as what commands are being executed or whether a secondary connection is being negotiated. However, you can configure specific inspection of an application. When you do this, the application inspection, such as FTP, takes precedence over generic TCP and UDP inspection.
Note
Basically, TCP and UDP inspection is used to allow returning traffic into your network. However, one additional function of generic TCP inspection is that CBAC examines the sequence numbers in returning segments to ensure that they fall within the configured window range.
Also, 99.9 percent of all traffic that a small company needs to pass through a router configured with CBAC can be accomplished with the inspection of generic TCP and UDP connections, as well as FTP, simplifying your CBAC configuration.
TCP and UDP inspection is done with the following two commands:
Router(config)# ip inspect name inspection_name tcp
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Router(config)# ip inspect name inspection_name udp
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
As you can see, setting up inspection for TCP and UDP is simple.
Note
Unlike RACLs, with ip inspect statements, you cannot control what traffic within a connection should or should not be inspected. CBAC inspects all traffic covered by an inspection statement.
Tip
If you are using NetMeeting, an H.323 application, you must enable generic TCP inspection as well as H.323 inspection. This is because NetMeeting went beyond the H.323 specification and uses an additional TCP connection that is not defined by H.323. Configuring generic TCP inspection enables CBAC to deal with this additional connection.
ICMP Inspection
As of Cisco IOS 12.2(11)YU and 12.2(15)T, CBAC can inspect ICMP connections. ICMP inspection allows the replies to internal ICMP messages to be returned to the internal device. This is useful when internal network administrators are trying to troubleshoot Layer 3 connectivity problems outside of their network, while still minimizing the exposure from different kinds of ICMP attacks.
Note
One limitation of ICMP inspection is that it cannot inspect traceroute implementations that use UDP; many UNIX implementations of traceroute use UDP. You can get around this problem by either enabling generic UDP inspection or specifying the ICMP option in the traceroute program, if this is supported.
Here is the general syntax for ICMP inspection:
Router(config)# ip inspect name inspection_name icmp
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
The default timeout for the return traffic in an ICMP connection is 10 seconds. You can change this by specifying a different value with the optional timeout parameter in the ip inspect name command. If multiple ICMP messages are sent for the test, the idle timeout starts after the last message.
HTTP Inspection
HTTP inspection can be used in any of the following circumstances:
• Your HTTP server(s) are running on a nonstandard port, such as 8080.
• You want to filter Java applets.
• You want to filter URLs.
To enable inspection for HTTP, use the following configuration:
Router(config)# ip inspect name inspection_name http
[urlfilter] [java-list standard_ACL_#] [alert {on | off}]
[audit-trail {on | off}] [timeout seconds]
The urlfilter parameter is used to inspect and filter URLs, and the java-list parameter is used to inspect and filter Java applets. I discuss these two options in much more depth in Chapter 10.
RPC Inspection
On a computer, a procedure is a software component running on a system. In Remote Procedure Calls (RPCs), your computer is accessing a procedure on a different computer. RPCs are popular in UNIX environments, with NFS being one of the most common. Even Microsoft uses some RPCs in its software applications.
CBAC can perform inspection on RPCs with the following command:
Router(config)# ip inspect name inspection_name rpc
program-number program_number [wait-time minutes]
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Unlike the inspection commands discussed so far, you need to enter the program number of the RPC that you want to inspect. Optionally, you can specify a wait period (wait-time), in minutes, that CBAC should use to keep the temporary entry in the state table. This is used to allow more connections from the source to the same destination and port number (but maybe a different RPC). The default is 0 minutes, meaning that the idle timer is used.
SMTP Inspection
CBAC supports application inspection of SMTP connections using the following command:
Router(config)# ip inspect name inspection_name smtp
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
With the activation of SMTP inspection, CBAC filters the SMTP commands on the e-mail connection. CBAC allows only the SMTP commands defined in IETF RFC 821, Section 4.5, through the router; any other SMTP commands are blocked. The allowed SMTP commands include DATA, EXPN, HELO, HELP, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SEND, SOML, and VRFY.
Note
SMTP inspection does not support ESMTP. Therefore, if you have enabled SMTP inspection, and your internal e-mail server uses ESMTP and is experiencing e-mail connection problems, you should disable SMTP application inspection for this connection.
Router(config)# ip inspect name inspection_name fragment
max number_of_fragments timeout seconds_to_reassemble
The max parameter specifies the maximum number of fragmented sessions. The default is 256, but you can change this to 50 to 10,000. In other words, this parameter controls the maximum number of sessions that can contain fragments. Setting this to a large value seriously can affect the performance of the router because it must store all the fragments for these sessions.
The timeout parameter specifies for how many seconds the Cisco IOS stores fragments for a session while trying to determine whether the fragments can be reassembled into a packet. The default is 1 second. If the router does not receive all the fragments for a reassembled packet within this time period, CBAC drops the fragments. The Cisco IOS automatically can adjust the timeout value during periods of heavy loads. It does this by examining the number of free connection entries specified by the maximum in the max parameter. If there are fewer than 32 connection states, the Cisco IOS divides the time period by half. If there are fewer than 16 connection states, the Cisco IOS automatically changes the time interval to 1 second.
Caution
CBAC expects a fragmented packet to arrive in order: The first fragment in the packet should arrive first. If the first fragment is not received first, the Cisco IOS drops the fragments. This can cause problems if an operating system, such as Linux, sends fragments out of order. In the Linux case, the fragments are sent in reverse order. In addition, if load balancing is used between the source and you, the fragments also might arrive out of order. Therefore, I recommend that you not use this inspection feature unless you are under a DoS fragmentation attack: Then enable it.
Skinny Inspection
Skinny inspection is needed only if you are using the Cisco VoIP solution with CM. You need to configure two possible commands:
Router(config)# ip inspect name inspection_name skinny
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Router(config)# ip inspect name inspection_name tftp
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
The first command (skinny parameter) is required: It causes CBAC to inspect TCP port 2000 Skinny connections. If you use a TFTP server to download configuration information to your IP phones, you also need to enable inspection for TFTP, which the second configuration command does.
There is a configured inactivity timeout for the connection between the IP phone and CM. It is important for the timeout value that you specify in your Skinny inspection to be greater than the IP phone–CM timeout period; otherwise, you inadvertently might disconnect an IP phone client. CBAC uses the default timeout for TCP connections for Skinny unless you override them with the timeout value parameter (3600 seconds). When CBAC closes a Skinny connection because of inactivity, it sends a TCP RST message to both ends, indicating that the session is being closed. Any phone connections that the IP phone has active will remain active; however, when the user hangs up the phone, the IP phone connection eventually times out after its idle period expires.
Step 6: Inspection Activation
After you have created your inspection rules, you must activate them on your router. As with ACLs, this is done on a router’s interface. The ip inspect command is used to activate the inspection rule:
Router(config)# interface type [slot_#]port_#
Router(config-if)# ip inspect inspection_name {in | out}
With the ip inspect command, you need to specify the name of the inspection rule grouping, as well as the direction in which you want CBAC to inspect traffic: in specifies that inspection of traffic is done as traffic enters the interface, and out specifies that it is done as traffic leaves an interface.
The most common implementation of inspection is to activate the inspection rules on the external interface in the outbound direction. This causes CBAC to build temporary ACL entries on the external interface’s inbound extended ACL (assuming that your Cisco IOS does not support FAB). If you apply the CBAC inspection rules on an internal interface, you first need to make sure that, for internal traffic, your internal ACL allows the inspected traffic into the router. Second, you activate the inspection rules in the inbound direction, which builds dynamic ACL entries for the extended ACL applied outbound on the outside interface (again, assuming that your Cisco IOS does not support FAB).
Typically, you activate your inspection rules on only one interface on your router. The exception to this is when you need to inspect traffic in two directions, such as in an intranet or extranet environment.
Step 7: Troubleshooting CBAC
After you have configured CBAC, you have three options for monitoring the CBAC inspection process and assisting you in troubleshooting problems:
• show commands
• debug commands
• Alerts and audits
The best way to test CBAC is to initiate a connection that you know CBAC has been configured to inspect, and then use these tools to verify the inspection process. The following three sections cover these three tools.
show commands
CBAC supports many show commands that you can use to view the temporary ACL entries created from the information in the state table, as well as the state table and the operation of CBAC. To view information about CBAC inspection information, use the show ip inspect command:
Router# show ip inspect [parameter]
Table 9-2 displays the optional parameters that you can include with this command.
To examine your ACLs, use the following commands:
• show ip interface
• show access-list
• show ip access-list
These commands were discussed in Chapter 7.
Note
The important thing to point out about displaying ACLs is that you see both the dynamic CBAC ACL entries (before FAB) and the static entries that you configured in the associated named or numbered extended ACL.
Now take a look at a couple of show ip inspect commands. Example 9-3 shows output from the show ip inspect name inspect_outbound command.
Example 9-3 Using the show ip inspect name Command
Router# show ip inspect name inspect_outbound
show ip inspect name inspect_outbound
Inspection name inspect_outbound
tcp alert is on audit-trail is off timeout 3600
udp alert is on audit-trail is off timeout 30
In the Example 9-3, you can see the inspection rules configured for the inspection rule set called inspect_outbound. With this rule set, TCP and UDP traffic is being inspected, both with their default idle timeouts.
To view the CBAC state table, use the command in Example 9-4.
Example 9-4 Viewing the CBAC State Table
Router# show ip inspect sessions
Established Sessions
Session 25A3378 (200.1.1.1:20)=>(192.1.1.2:32704) ftp-data SIS_OPEN
Session 25A5AC2 (192.1.1.2:32703)=>(200.1.1.1:21) ftp SIS_OPEN
In this example, there are two entries in the state table: 192.1.1.2 is inside the network, and 200.1.1.1 is outside. The second entry shows the internal device opening a connection to an external FTP server. The first connection displays the data connection that the FTP server opened back to the internal client. Example 9-5 shows the CBAC dynamic ACL entries created in the inbound extended ACL.
Example 9-5 Displaying CBAC Dynamic ACL Entries Before FAB
router# show ip access-list
Extended IP access list 100
permit tcp host 200.1.1.1 eq 21 host 192.1.1.2 eq 32703 (24 matches)
permit tcp host 200.1.1.1 eq 20 host 192.1.1.2 eq 32704 (88 matches)
<--output omitted-->
As you can see from this output, there are two reversed ACL entries to allow the traffic from the FTP server to be sent to the initiating FTP internal client.
Now look at an example of the same internal client opening an H.323v2 connection to an external H.323 server. Example 9-6 shows the entries in the state table on the router.
Example 9-6 Viewing the CBAC State Table for H.323v2
Router# show ip inspect session
Session 615E2688 (192.1.1.2:38509)=>(200.1.1.2:38509) H323-RTCP-audio SIS_OPEN
Session 615E2688 (192.1.1.2:38408)=>(200.1.1.2:38408) H323-RTP-audio SIS_OPEN
Session 615E2688 (192.1.1.2:38310)=>(200.1.1.2:38310) H323-RTP-video SIS_OPEN
Session 615E2688 (192.1.1.2:38511)=>(200.1.1.2:35611) H323-RTCP-video SIS_OPEN
Session 615E1640 (192.1.1.2:10001)=>(200.1.1.2:1720) H323 SIS_OPEN
In this example, you can see all of the H.323 connections set up to download the video and audio streams from the H.323 server application. Example 9-7 shows the ACL entries created from these entries in the state table with a Cisco IOS that does not support FAB.
Example 9-7 H.323 CBAC Dynamically Added Entries
Router# show ip access-lists
Extended IP access list 100
permit udp host 200.1.1.2 eq 43509 host 192.1.1.2 eq 39509 (12 matches)
permit udp host 200.1.1.2 eq 43408 host 192.1.1.2 eq 39408 (381 matches)
permit udp host 200.1.1.2 eq 43311 host 192.1.1.2 eq 39311 (16 matches)
permit udp host 200.1.1.2 eq 43510 host 192.1.1.2 eq 39510 (4938 matches)
permit tcp host 200.1.1.2 eq 1720 host 192.1.1.2 eq 10001 (39 matches)
<--output omitted-->
Tip
I like to use one other show command, but it is a hidden command (I do not know why). The show ip inspect stat command is great for checking out the current, maximum ever, and other counts for connections that CBAC has seen.
debug commands
For more detailed troubleshooting of CBAC, you can use debug commands. With debug commands, you can see, in real time, the operation of CBAC on your router. Here is the format of the debug command for inspection:
Router# debug ip inspect parameter
Table 9-3 lists the parameters for this debug command. Here is the list of application names that you can specify for inspection: cuseeme, dns, ftp-cmd, ftp-token, h323, http, netshow, rcmd, realaudio, rpc, rtsp, sip, skinny, smtp, sqlnet, streamworks, tftp, and vdolive.
Alerts and Audits
CBAC inspection supports two types of logging functions: alerts and audits. The following two subsections explain how these function and how they are configured.
Alerts
Alerts display messages concerning the operation of CBAC, such as insufficient router resources, DoS attacks, and other threats. Alerts are enabled by default and automatically display on the router’s console line. To globally disable alerts, use this command:
Router(config)# ip inspect alert-off
Remember that you also can disable and enable alerts per inspection rule.
Tip
I highly recommend that you leave alerts enabled. Alerts are useful because they can notify you of network attacks, such as an attack against your e-mail server.
Here is an example of someone trying to send an unapproved SMTP command to an e-mail server:
%FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator
(200.5.5.5:49387)
CBAC can detect a small number of SMTP attacks besides the use of invalid commands, including these:
• Someone trying to send a pipe (|) in the To or From fields of the e-mail message
• Someone trying to send :decode@ in the e-mail header
• Someone trying to use the old SMTP wiz or debug commands on the SMTP port
• Someone trying to execute arbitrary commands to exploit a bug in the Majordomo e-mail program
Here is an example of an alert being generated when a hacker tries to exploit the SMTP Majordomo bug:
02:04:55: %FW-4-TCP_MAJORDOMO_EXEC_BUG: Sig:3107:
Majordomo Execute Attack - from 200.5.5.5 to 192.1.1.1:
Audits
Auditing keeps track of the connections that CBAC inspects, including valid and invalid access attempts. For example, you can see messages when CBAC adds or removes an entry from the state table. The audit record gives some basic statistical information about the connection. Auditing is disabled by default but can be enabled with the following command:
Router(config)# ip inspect audit trail
Here is an example audit message from CBAC:
%FW-6-SESS_AUDIT_TRAIL: tcp session
initiator (192.1.1.2:32782) sent 22 bytes
responder (200.1.1.1:23) sent 200 bytes
In this example, an audit trail is being created from a Telnet connection initiated from 192.1.1.2.
Note
By default, when alerts and audits are enabled, they display messages on the console line. However, you can log this information to other locations, including the router’s internal buffer or an external syslog server. These logging concepts are discussed in Chapter 18.
CBAC Removal
If you no longer want to use CBAC on your router, remove it with the following configuration command:
Router(config)# no ip inspect
This command causes the Cisco IOS to remove all CBAC commands, remove the state table, and remove all temporary ACL entries created by CBAC. This command also resets all timeout and threshold values to their factory defaults.
Caution
Disabling CBAC causes all inspection processes to cease. When this is done, the Cisco IOS cannot detect certain kinds of attacks, such as some types of SMTP- and Java-based attacks.
CBAC Examples
DoS detection and prevention with CBAC is discussed in Chapter 17. Here I take a look at some examples of using CBAC for inspection and stateful filtering. Each example has four basic configuration components:
• Defining an extended ACL(s) to filter traffic
• Applying the extended ACL(s) on the appropriate interface(s)
• Defining an inspection rule(s) to allow returning traffic
• Applying the inspection rule(s) to the appropriate interface(s)
You need to configure many other things to secure the router in this example; however, these examples focus on only the previous four core elements in setting up stateful filtering.
Simple Example
Example 9-8 uses three simple inspection rules for TCP, UDP, and ICMP.
Example 9-8 Setting Up a Simple CBAC Inspection Configuration
Router(config)# ip access-list extended EXTERNAL-ACL
Router(config-ext-nacl)# deny tcp any any log
Router(config-ext-nacl)# deny udp any any log
Router(config-ext-nacl)# deny icmp any any log
Router(config-ext-nacl)# deny ip any any
Router(config)# ip inspect name CBAC-EXAMPLE tcp
Router(config)# ip inspect name CBAC-EXAMPLE udp
Router(config)# ip inspect name CBAC-EXAMPLE icmp
Router(config)# interface ethernet0
Router(config-if)# ip access-group EXTERNAL-ACL in
Router(config-if)# ip inspect CBAC-EXAMPLE out
In this example, EXTERNAL-ACL is an extended IP ACL that denies all IP traffic. I put in the specific deny statements to log the denied TCP, UDP, and ICMP packets. Also notice that there is no reference to CBAC in the ACL; this is not necessary because CBAC dynamically adds entries at the top of the ACL to allow returning traffic. This is true of a Cisco IOS before FAB; however, with FAB, the Cisco IOS uses the state table to process returning traffic and then the static ACL on the returning interface. Without CBAC, the ACL in this configuration would drop all traffic trying to enter the ethernet0 interface.
Below this are three inspection statements for the rule group called CBAC-EXAMPLE: All TCP, UDP, and ICMP traffic is inspected. Ethernet0 is the external interface, where the external ACL is applied inbound and the inspection rules are applied outbound. With this configuration, CBAC knows that inspected traffic leaving the router has dynamic ACL entries automatically added to the top of the applied inbound external ACL (again, before FAB).
Note
From my perspective, the configuration of CBAC is simpler than that of RACLs. With RACLs, you need two ACLs, and the placement of the reflect and evaluate entries in the internal and external ACL is critical. With CBAC, you need to worry about only one ACL, and you do not have to worry about where the temporary ACL entries are placed; CBAC takes care of this automatically before FAB or uses the state table only to allow returning traffic with FAB.
To illustrate this further, imagine that an internal user (192.168.1.100) Telnets to an external device (192.168.2.2). Example 9-9 shows the verification on the router of this process.
Example 9-9 State Table Example Using the Configuration in Example 9-8
Router# show ip inspect sessions
Established Sessions
Session 82040F2C (192.168.1.100:1289)=>(192.168.2.2:23) tcp SIS_OPEN
As you can see, an entry was added to the Cisco IOS state table for the Telnet connection. Example 9-10 shows the display of the ACL information.
Example 9-10 The ACL, Before FAB, Using the Configuration in Example 9-8
Router# show ip access-list
Extended IP access list EXTERNAL-ACL
permit tcp host 192.168.2.2 eq telnet host 192.168.1.100 eq 1289 (18 matches)
10 deny tcp any any log
20 deny udp any any log
30 deny icmp any any log
40 deny ip any any
As you can see, the very first line of the ACL is the dynamic Telnet entry that CBAC added from the state table.
Note
Before FAB, you see the dynamic ACL entries at the top of the ACL on the returning interface; however, with FAB, you see only the ACL entries that you have configured manually. With FAB, the router uses the state table to allow returning traffic and the ACL to filter other traffic. Even for me, this takes some time to get used to because I always am looking for the temporary dynamic ACL entries to verify the operation of CBAC. With FAB, you need to examine the CBAC state table to verify its operation.
Two-Interface CBAC Example
Figure 9-10 illustrates how to use CBAC in a router that has two interfaces. This example is the same one used in Chapter 8, “Reflexive Access Lists.” However, I configure CBAC instead of using RACLs to implement the stateful filtering.
In this example, the network has two policies: allow Internet traffic to the internal e-mail server, and allow users access to the Internet. To accomplish this, you need an ACL configuration, such as the following:
• Allow all internal users access to the Internet
• External ACL (apply inbound on E1):
— Allow returning traffic from the Internet to the internal users
— Allow Internet traffic to the e-mail server
— Deny all other traffic
Example 9-11 shows the configuration to enforce these policies.
Example 9-11 Using CBAC to Implement Policies on a Two-Interface Router
Router(config)# ip access-list extended external_ACL
Router(config-ext-nacl)# permit tcp any host 192.1.1.1 eq smtp
Router(config-ext-nacl)# deny ip any any
Router(config-ext-nacl)# exit
Router(config)# ip inspect name CBAC smtp
Router(config)# ip inspect name CBAC tftp
Router(config)# ip inspect name CBAC ftp
Router(config)# ip inspect name CBAC http
Router(config)# ip inspect name CBAC realaudio
Router(config)# ip inspect name CBAC tcp
Router(config)# ip inspect name CBAC udp
Router(config)# ip inspect name CBAC icmp
Router(config)# ip inspect tcp idle-time 300
Router(config)# interface ethernet1
Router(config-if)# ip inspect CBAC out
Router(config-if)# ip access-group external_ACL in
In this example, the external_ACL allows only e-mail traffic to be sent to the internal e-mail server (192.1.1.1). All other traffic, by default, is denied. Following the ACL are the inspection rules for the inspection group called CBAC. In this example, TCP, UDP, ICMP, SMTP, TFTP, FTP, HTTP, and RealAudio traffic is being inspected. Next, the TCP idle timer for idle TCP connection has been changed from 3600 seconds to 300 seconds (5 minutes). Finally, the ACL and CBAC are activated on the router’s external interface (ethernet1). As you can see from this example, the configuration is straightforward.
Three-Interface CBAC Example
Figure 9-11 illustrates how to use CBAC in a router that has three interfaces. This is the same three-interface example used in the last chapter, where RACLs were used to implement a stateful firewall filtering function. Here is a review of the policies discussed in the last chapter for this network:
• The Internet should be capable of accessing the DMZ e-mail server.
• The Internet should be capable of accessing the DMZ DNS server.
• The Internet should be capable of accessing the DMZ web server.
• The Internet should not be capable of accessing the internal network.
• The internal e-mail server should be capable of accessing only the DMZ e-mail server, nothing else.
• The DMZ e-mail server should be capable of accessing the internal e-mail server to forward mail.
• Internal users should be able to access the Internet and receive replies.
• Internal users should not be able to access the DMZ e-mail server or any external e-mail servers.
To accomplish these policies, you need three ACLs:
• Internal ACL (apply inbound on E0):
— Allow internal e-mail server to access DMZ e-mail server
— Deny internal users to access the DMZ e-mail server and other e-mail servers
— Deny internal e-mail server from accessing anything else
— Allow internal users to access all other services (DMZ and Internet)
— Examine outbound traffic and build the state table entries for new sessions to the DMZ (not a part of the ACL, but part of the CBAC inspection process)
— Examine outbound traffic and build the state table entries for new sessions to the Internet (not a part of the ACL, but part of the CBAC inspection process)
• DMZ ACL (apply inbound on E2). This restricts traffic from the DMZ to the internal network and the DMZ to the Internet:
— Allow the DMZ e-mail server to send e-mail to the internal server
— Allow the DMZ e-mail server to send e-mail to external e-mail servers
— Allow the DMZ DNS server to query other DNS servers
— Examine DMZ-related traffic to allow returning traffic from the DMZ to the internal and Internet users (not a part of the ACL, but part of the CBAC inspection process)
• External ACL (apply inbound on E1):
— Allow Internet users access to the DMZ e-mail server
— Allow Internet users access to the DMZ DNS server for DNS queries
— Allow Internet users access to the DMZ web server
— Examine the traffic sent from the internal network and the DMZ e-mail server to be returned (not a part of the ACL, but part of the CBAC inspection process)
As you can see from the previous list of policies, setup of the ACLs and CBAC is a lot more difficult than in the two-interface CBAC example:
• You need three ACLs: one to restrict traffic coming into the network, one to restrict traffic from the users to the DMZ, and one to restrict traffic from the DMZ to the Internet
• You need a minimum of one, and possibly three, inspection rules, depending on what must be inspected from which interface.
Example 9-12 shows the configuration to enforce these policies.
Example 9-12 Using CBAC to Implement Policies on a Three-Interface Router
Router(config)# ip access-list extended internal_ACL
Router(config-ext-nacl)# permit tcp host 192.1.1.1 (1)
host 192.1.2.1 eq smtp
Router(config-ext-nacl)# deny tcp any any eq pop (2)
Router(config-ext-nacl)# deny tcp any any eq smtp
Router(config-ext-nacl)# deny ip host 192.1.1.1 any (3)
Router(config-ext-nacl)# permit ip any any (4)
Router(config-ext-nacl)# exit
Router(config)#
Router(config)# ip inspect name internal_CBAC smtp audit-trail on (5)
Router(config)# ip inspect name internal_CBAC ftp
Router(config)# ip inspect name internal_CBAC http
Router(config)# ip inspect name internal_CBAC realaudio
Router(config)# ip inspect name internal_CBAC tcp
Router(config)# ip inspect name internal_CBAC udp
Router(config)# ip inspect name internal_CBAC icmp
Router(config)#
Router(config)# ip access-list extended DMZ_ACL
Router(config-ext-nacl)# permit tcp host 192.1.2.1 any eq smtp (6)
Router(config-ext-nacl)# permit udp host 192.1.2.2 any eq dns (7)
Router(config-ext-nacl)# exit
Router(config)#
Router(config)# ip inspect name DMZ_CBAC smtp audit-trail on (8)
Router(config)# ip inspect name DMZ_CBAC http
Router(config)# ip inspect name DMZ_CBAC tcp
Router(config)# ip inspect name DMZ_CBAC udp
Router(config)#
Router(config)# ip access-list extended external_ACL
Router(config-ext-nacl)# permit tcp any host 192.1.2.1 eq smtp (9)
Router(config-ext-nacl)# permit udp any host 192.1.2.2 eq dns
Router(config-ext-nacl)# permit tcp any host 192.1.2.3 eq http
Router(config-ext-nacl)# exit
Router(config)#
Router(config)# ip inspect name external_CBAC smtp (10)
audit-trail on
Router(config)# ip inspect name external_CBAC ftp
Router(config)# ip inspect name external_CBAC http
Router(config)# ip inspect name external_CBAC realaudio
Router(config)# ip inspect name external_CBAC tcp
Router(config)# ip inspect name external_CBAC udp
Router(config)# ip inspect name external_CBAC icmp
Router(config)#
Router(config)# interface ethernet0 (11)
Router(config-if)# description Internal Network
Router(config-if)# ip access-group internal_ACL in
Router(config-if)# ip inspect internal_CBAC in
Router(config-if)# exit
Router(config)# interface ethernet2 (12)
Router(config-if)# description DMZ
Router(config-if)# ip access-group DMZ_ACL in
Router(config-if)# ip inspect DMZ_CBAC in
Router(config-if)# exit
Router(config)# interface ethernet1 (13)
Router(config-if)# description Internet
Router(config-if)# ip access-group external_ACL in
Router(config-if)# exit
Router(config)# ip inspect tcp synwait-time 15 (14)
Router(config)# ip inspect tcp idle-time 120
Router(config)# ip inspect udp idle-time 20
The following is an explanation of Example 9-12, with reference to the numbering on the right side of the example:
1. internal_ACL is used to filter traffic from the internal segment (connected to ethernet0). The first statement in this ACL allows the internal e-mail server to send e-mail to the DMZ e-mail server.
2. This statement forces the internal clients to send e-mail through the internal e-mail server. In addition, the statement following this one prevents all e-mail connections, minus the e-mail connection listed in the first statement.
3. This statement prevents the internal e-mail server from accessing any other device.
4. All other access from the internal segment to other devices is allowed.
5. The internal_CBAC inspection rules are used to allow traffic for returning sessions to the internal users. In this example, the administrator has determined the protocols that internal people use and has configured the appropriate inspection statements. Notice that the audit trail function has been enabled for SMTP inspection. This is done to provide more information about SMTP connections and possible attacks.
6. The second ACL, DMZ_ACL, is used to filter traffic from the DMZ segment. By default, only two connections are allowed. In this first statement, the DMZ e-mail server is allowed to send e-mail to any e-mail server, including the internal e-mail server and Internet e-mail servers.
7. In the second ACL statement, the DMZ DNS server is allowed to forward DNS queries to other DNS servers.
8. In the second inspection rule set for CBAC, inspection is set up for traffic entering the DMZ segment, allowing for the return of traffic from the DMZ to the internal and Internet segments. Notice that the number of inspection statements is smaller because the applications running on the DMZ are limited.
9. This third ACL is used to filter traffic from the Internet that is trying to access internal resources. Only three statements are configured, allowing access to the DMZ e-mail server, the DMZ DNS server, and the DMZ web server.
10. The third set of CBAC inspection rules allows returning traffic that originally exited the Internet interface. Actually, you could have used the same inspection rule set that I did for the internal interface. However, this adds overhead because some of the traffic is internal to the DMZ, and you do not want these temporary ACL entries to show up on the external interface.
11. This interface is connected to the internal segment and has internal_ACL activated on it as well as the CBAC inspection rule for the internal traffic.
12. This interface is connected to the DMZ segment and has DMZ_ACL activated on it as well as the CBAC inspection rule for the DMZ traffic.
13. This interface is connected to the external (Internet) segment and has external_ACL activated on it.
14. The last set of three statements changes the default idle timeout for connections. The first statement reduces the TCP setup time from 30 to 15 seconds. The second statement reduces the TCP idle timeout from 3600 to 120 seconds (2 minutes). In the third statement, the UDP idle timer is reduced from 30 to 20 seconds.
If you compare this example to the three-interface example in Chapter 8, this example is much cleaner and easier to implement. This is one of the main reasons administrators prefer to use CBAC instead of RACLs.
Summary
This chapter showed you the basics of using CBAC to implement stateful filtering and inspection of traffic. Cisco recommends CBAC over RACLs when implementing stateful filtering because of the ease of its configuration as well as its enhanced features, including application inspection. With application inspection, CBAC can monitor connections to limit the commands executed on them, to prevent certain kinds of DoS attacks, to detect embedded nontranslated addressing information and translate this information, as well as many other things.
Next up is Chapter 10, which shows you how to filter Java applets and web information using external content filter servers, CBAC, and the Cisco IOS Network-Based Application Recognition (NBAR) feature.