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.
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:
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.
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.
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 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.
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.
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.
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.
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 126.96.36.199 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 188.8.131.52, 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 (184.108.40.206), 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.
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.
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.
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.