Because you can filter traffic using an access control list (ACL) on the router, you may wonder why CBAC is necessary. What shortcoming is CBAC addressing for the traditional ACL? That deserves an answer before we proceed any further with the CBAC discussion.
ACL has many limitations that keep it from being an effective firewall mechanism. The most important limitation is that ACL is a packet filtering mechanism based on Open System Interconnection (OSI) network and transport layer information. On the other hand, CBAC is a stateful firewall just like Private Internet Exchange (PIX), which filters traffic based on state information rather than just on network or transport layer information.
For example, assume there is an inside and outside network with a dotted line as the perimeter, and there is a firewall router with an Ethernet 0 interface going to the protected network (inside) and an interface Serial 0 going to the unprotected network (Internet) as shown in Figure 5-1.
Figure 5-1. Limitation of Static ACL
For the router to protect the inside network, two conditions must be met:
To fulfill the second requirement, configure an ACL 101 on the serial 0 interface that denies all traffic from outside. This effectively sets up a wall to block outside traffic. Then, take a look at the first requirement, that is, to allow traffic from the protected network to the Internet. As shown in Figure 5-2, when Telnet is initiated from the inside to the outside, being a Transmission Control Protocol (TCP), the synchronize (SYN) packet from the inside makes it to the outside. This is because there is no access list applied in this example on the inside interface towards the direction of the initial packet. It is a good security practice, however, to configure ACL on the inside interface facing towards the protected network to stop anti-spoofing. You should, however, watch carefully that the reply SYN-ACK packet from outside is blocked by the ACL that you have applied on the serial 0 interface and the connection fails to set up. The result will be the same for the User Datagram Protocol (UDP) reply packet. So, as you can see with the static ACL, if this connection needs to be successful, you need to create an Access Control Entry (ACE) entry on ACL 101 that is applied earlier on the serial 0 interface with a source port 23 and destination port greater than 1023. Doing so opens up several holes to your network, because anyone from outside can also initiate connections using those ports). This is where CBAC plays an important role.
Figure 5-2. An Example of CBAC Implementation for Telnet
How can CBAC solve this problem? To turn on CBAC, create and apply a simple CBAC rule: inspect only TCP traffic for this example. This rule is turned on for the Ethernet 0 interface towards the direction of SYN packet (inspection must always be applied in the direction of the traffic initiation) as shown in Figure 5-2.
As before, if the Telnet connection is initiated from inside the host to outside, once the SYN packet goes through the router after ACL checking (in this example there is no ACL configured in the traffic initiation direction), the CBAC inspects it. The CBAC inspects it because the initiation packet is moving in the same direction in which the inspection rule is applied (on the Ethernet 0 interface as inbound). CBAC performs the following functions:
This, in effect, creates a tiny hole in the ACL, which is specific to this connection only. As a result, the reply SYN-ACK packet makes it through this hole and reaches the inside end host. The inside end host then replies with the final ACK, and the connection is established. As a result, the first requirement is also met (remember, the first requirement is to allow connections to initiate from the protected network). Once the connection is established, CBAC examines traffic in both directions for this particular connection. CBAC recognizes when the end hosts close connection using FIN (Finish) Exchange or RST (Reset), and the CBAC removes the dynamic ACL entries accordingly. So CBAC not only resolves the issue of creating ACL statically, it also opens up a very specific hole in the ACL that is required, and closes it when finished.
So far we have seen how CBAC helps with single-channel protocol by creating a dynamic ACL. With static ACL, to accomplish this result, leave the outside interface ACL wide open and thereby permit everything. Permitting everything, of course, defeats the purpose of configuring the ACL on the router in the first place. To address this security issue, you may be able to configure the established keyword on the ACL applied on the serial 0 interface. The established keyword filters TCP packets based on whether the ACK or RST bits are set. The setting of ACK or RST bits indicates that the packet is not the first in the session, and therefore, that the packet belongs to an established session. Although this effectively blocks the SYN packet (that is, packet initiation from outside to inside is blocked) for TCP traffic, it works only with TCP and filters based on only the TCP flag, and is therefore vulnerable to a spoof attack.
Reflexive ACL is a better solution than using an established keyword in static ACL, as it works with UDP as well, and creates the dynamic ACL based on source and destination IP addresses and ports. Therefore the traffic is filtered not only by the flag, as in static ACL with the established option, but by source and destination addresses and ports in addition to flags. The biggest drawback, however, with Reflexive ACL is that it does not work with a multi-channel protocol, because the additional channels (other than the first control channel) are built up using the port negotiation that occurs when using the control channel, and Reflexive ACL is unable to learn about this negotiation. Therefore, Reflexive ACL is unable to create dynamic ACE in the ACL for the data channel in the case of a multi-channel protocol. This failure is one of the serious shortcomings of Reflexive ACL. The following section examines how CBAC is better able to handle this multi-channel issue.
To understand how CBAC addresses the shortcoming of Reflexive ACL with multi-channel protocol, examine how CBAC works with multi-channel protocols such as File Transfer Protocol (FTP), H323, Session Initiation Protocol (SIP), and so on. As the name implies, multi-channel typically creates more than one connection for transferring data. Typically, the first connection acts as a control connection. The address and port information for the secondary connections (also known as data connection) are dynamically negotiated by end hosts over this control connection. To illustrate this, study an example of a two-channel protocol, Active FTP with CBAC as shown in Figure 5-3.
Figure 5-3. An Example of CBAC Implementation for FTP
Just as before, the ACL 101 is on the outside interface (serial 0), and CBAC is configured on the inside interface (Ethernet 0). An inside host initiates the connection for the control channel by sending a SYN, and CBAC creates a dynamic hole for the return traffic, which allows the reply SYN-ACK packet through the hole. After the client sends the ACK, the connection completes as before.
Now, the inside host negotiates the address and port information for the second channel (data channel) by sending the PORT A: 5560 command. This means that the inside host listens on the source address A and on source port 5560. Hence, the FTP server should try to connect to the client to create the data channel. Note that the FTP client can use the port command to offer an address other than A to create a data connection from the FTP server, which is on the outside.
Even though the data channel is initiated from the FTP server sitting on the outside, the CBAC should allow this connection. Otherwise FTP application functionality will fail. CBAC does this by extracting the PORT A:5560 data from the packet (note that this information lies in the packet's Layer 7 payload and not in the Layer 4 header). After extracting this information, CBAC creates another dynamic ACL entry. The destination address/port in the ACL entry are set to A:5560, whereas the source address/port are set to "any" because CBAC does not know what address/port the outside host will use to initiate the data connection.
This creates another hole in the ACL, which is sometimes known as a wide hole because the src address/port are set to "any". When the outside host actually sends the SYN packet to initiate the connection, CBAC extracts the src information from this packet as B:20. It then uses this information to update the second dynamic ACL and changes the src address/port info from "any" to B:20, thus narrowing the hole to match only this connection. Now the rest of the three-way handshake completes successfully, and the second connection also succeeds. The first connection from A:5550 to B:21 is known as the control connection, and the second connection from B:20 to A:5560 is known as the data connection. Without CBAC, if you configure reflexive or static ACL, you must permit everything from outside to inside for the data connection. In summary, CBAC understands more than Layer 3 and Layer 4 of the OSI model; CBAC understands up to Layer 7. And because of its intelligence of application, CBAC can dynamically open and close the ports needed by the applications using dynamic ACLs.
The discussion in the preceding paragraph focuses primarily on how CBAC handles Active FTP connection, where data connection is initiated by the FTP server sitting on the outside. In passive FTP mode, both the control and data connections are initiated from inside to outside if the FTP clients are located on the inside. More details on Active and Passive FTP can be found in the following location: http://www.cisco.com/en/US/about/ac123/ac147/ac174/ac199/about_cisco_ipj_archive_article09186a00800c85a7.html
Details on how CBAC handles Passive FTP can be found in the following location: http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_qanda_item09186a008009464d.shtml#qa5
Being a stateful firewall, CBAC provides several security services to your network. The most important are discussed in the sections that follow.
Single Channel Protocol Inspection
As discussed in the preceding section, for single channel protocols (Telnet, Hypertext Transfer Protocol [HTTP], Simple Mail Transfer Protocol [SMTP], etc.) you need to inspect only the Transport Layer protocolTCP, UDP, and Internet Control Message Protocol (ICMP). For instance, to pass TELNET traffic, the router needs to perform just TCP inspection. There is no need to inspect Telnet, and in fact that option is not available.
As we learned earlier based on Figure 5-2, we can use CBAC to create a session and based on that, create a dynamic ACL, so that the return traffic can come back. Before you go though the discussion of some of the security features provided by CBAC for the single channel TCP protocol, it is worth reviewing how CBAC handles UDP and ICMP protocol. In the preceding section, we have seen how CBAC handles TCP-based protocol both for single- and multi-channel protocol. The following discussion focuses on how CBAC handles UDP and ICMP protocols.
UDP and CBAC
Unlike TCP, UDP is a connectionless protocol. Hence, CBAC's generic UDP inspection cannot detect when a client connection request is satisfied. Therefore, generic UDP inspection simply creates a channel when it recognizes the first request packet from the client, and keeps that channel open until no traffic has been detected between the client and the server for a set time. This approximates session maintenance. To turn on UDP inspection, use the ip inspect myfw UDP command in the global configuration mode (myfw is the name of the inspection rule). Although approximation of UDP connections works most of the time, it may fail in one of the two following ways:
ICMP and CBAC
Stateful inspection of ICMP protocol was introduced in version 12.2(11)YU, and integrated in IOS version 12.2(15)T. Before this version, to allow the ping, you had to allow the ECHO for the ping request traffic and ECHO-REPLY for ping reply traffic. With the introduction of stateful inspection in the ICMP protocol, static ACL does not have to be created for the ICMP Packet Types shown in Table 5-1.
A more detailed description of stateful inspection of ICMP protocol can be found at: http://www.cisco.com/en/US/products/sw/iosswrel/ps5012/products_feature_guide09186a0080146558.html
Application Layer Protocol (TCP-based) and CBAC
Because CBAC can parse commands for some TCP-based application layer protocols, and has intelligence built in concerning these protocols, it can provide the security features outlined in the sections that follow.
Preventing from Invalid Command Execution
As mentioned previously, CBAC can parse commands of some TCP-based application layer protocols. SMTP and Extended Simple Mail Transfer Protocol (ESMTP) fall into this category. Although it is sufficient to inspect TCP for SMTP/ESMTP connections, you must inspect SMTP/ESMTP to ensure protocol conformation as per Request For Comment (RFC) through the CBAC router. To block the illegal commands execution by users using SMTP/ESMTP, you need to inspect SMTP/EMTP using the following commands:
ip inspect myfw smtp ip inspect myfw esmtp
For SMTP inspection, CBAC effectively checks for command violation based on RFC 821 and issues alerts when it detects an SMTP attack (there is more on alerts in a later section). The RFC 821 commands allowed are HELO MAIL, RCPT, DATA, RSET, NOOP, and QUIT by CBAC when SMTP is inspected.
For ESMTP inspection, CBAC inspects the commands defined in RFC 1869, which are AUTH, DATA, EHLO, ETRN, HELO, HELP, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SEND, SOML and VRFY. All others are considered illegal, and when CBAC encounters others it generates alerts.
The CBAC router detects a limited number of SMTP attack signatures. A signature in a SYSLOG message indicates a possible attack against the protected network, such as the detection of illegal SMTP commands in a packet. Whenever a signature is detected, the connection is reset.
There are 11 "IDS Sensor" attack signatures. Five have always been integrated into the Cisco IOS Firewall SMTP implementation, which is shown in Table 5-2.
Protection from Malicious Java Applets
With the rapid increase of Java applets on the Internet, protecting networks from malicious Java applets has become a major concern for every network administrator. Java blocking can be configured to intelligently filter or completely deny access to Java applets that are not embedded in archives or compressed files. If Java applets are embedded in archives or compressed files, they are not inspected by CBAC. When Java blocking is enabled on an interface, the firewall monitors contents of HTTP packets from HTTP servers, and when a Java applet is identified in the connection, the firewall immediately resets the connection to block that Java applet, preventing it from crossing the firewall.
While configuring CBAC, as soon as you turn on HTTP inspection (as shown in the commands that follow), it blocks the Java applet by default.
ip inspect name <rule> http [java-list <num>] [audit <on | off>] [alert <on | off>] [timeout <sec>] access-list <num> <deny | permit> <src-addr> <src-wildcard>
Some of the important points to note here are:
In addition to Java applet filtering, IOS Firewall can also be configured to filter the web traffic based on other criteria such as address, userid, group, and so on to websites on the internet. This feature is called URL Filtering or Destination URL Policy Management and is introduced in versions 12.2(11) YU and 12.2(15) T and above.
Now look at the details of how URL filtering works with CBAC. The following sequence of events occurs when a CBAC router is configured with URL filtering as shown in Figure 5-4:
Figure 5-4. Limiting a Static ACL
Step 2 needs little more elaboration. Before the router queries the server (if configured) it goes through two local tables on the router that contain the URLs of the destination web servers. Based on the tables, either all users are always permitted or always denied. If no entries or matches are found, the router checks its local cache to determine if the request has been made at an earlier time. If so, it studies the results. To improve the performance, this caching is enabled by default, and does not need to be explicitly configured. By default, the cache table can hold 5000 IP addresses. This can be modified with the following command:
ip urlfilter cache size
Caching enriches the URL filtering by minimizing the number of URL query requests that are sent to the filter server. It is interesting to note that the filter server makes decisions about caching an IP address. When the filter server receives a query request from Cisco IOS Software, it checks whether the request needs to be cached. If it does, the filter server sets a bit map in the response, which indicates that the IP address needs to be cached.
The URL server is a large detailed knowledge base of the Internet and has categorized many URLs into one of the more 80 categories including gaming, pornography, MP3s, freeware, shareware, and so on. You can define the policy based on one of the following categories:
Any degradation of network traffic performance due to URL filtering is not noticed by the user. For performance reasons, the GET request is forwarded to the desired URL destination if nothing triggers the local mechanisms, and to the URL server simultaneously. If the router has not received permission or denial by the time the destination URL replies with a web page, the router does not forward it, but instead holds it in its buffer until the reply comes from the URL server. If the URL server permits, the router allows the connection and maintains that URL in the cache. If the URL server denies, the router drops the connection, redirects the users, and gives them the reason the connection was denied. This cache improves the performance dramatically.
The commands for turning on URL filtering on the CBAC router follow:
Example 5-2 shows an example of how to turn on URL filtering. The url-cache is by default 5000.
Example 5-2. Turning on URL Filtering
A more detailed discussion on URL filtering is beyond the scope of this chapter. For more details, refer to the following URLs:
One final and important point on IP URL filtering: User-based restriction is not possible with N2H2. However, it is possible with Websense because Websense has a mechanism for getting the username to correspond to an IP address. In addition to recognizing the users based on IP, Websense also can redirect the users for authentication before permitting the access to the website.
This concludes the discussion on security services that are provided by the CBAC for the single channel protocols. In the following sections, you will learn some of the security features that are applicable for both single- and multi-channel protocols. But before that, it is important to re-visit the discussion of multi-channel protocols.
Multi-Channel Protocol Inspection
Unlike the single-channel protocols discussed earlier, multi-channel protocols require you to configure for inspection on the application layer protocol. For example, if you inspect only TCP for FTP connection, the control channel becomes built up, because FTP is a TCP protocol. However, the data channel may not become built up because it depends on the port negotiation using the control channel, and if only TCP is inspected, CBAC does not watch the payload of the packet to gain knowledge of this port negotiation.
Hence, the TCP engine will not have any knowledge about the port and IP address information negotiated and agreed upon by the FTP client and server to build up the data channel. Consequently, CBAC does not open any hole on the ACL. So, if the data connection is initiated from outside, it will be dropped. Therefore, to inspect the payload and get all the necessary information for the data channel, you need to inspect the application layer protocol, which is in this case ip inspect name myfw FTP. Note that application inspection takes precedence over Layer 4 protocol inspection. In the example, because you inspect FTP protocol, you do not need inspection for TCP protocol. However if you inspect both TCP and FTP, only the FTP inspection engine is used, not TCP.
The section that follows discusses some of the important security services available for both single- and multi-channel protocols.
NAT/PAT and CBAC
CBAC interoperates with both static and dynamic NAT (source and destination). Static and Dynamic NAT with CBAC turns Cisco IOS Router into a very powerful enterprise class firewall. Here are a couple of the benefits NAT adds to CBAC:
Port Application Mapping (PAM) and CBAC
Port Application Mapping (PAM) allows you to change the standard application port on the router. This is important for hiding well-known port numbers for different applications such as TCP/80 for the HTTP protocol. By default, PAM generates a table of information that identifies specific applications with specific TCP or UDP port information. The PAM table initially is populated with system-defined mapping information, when the firewall router first starts. Example 5-3 shows the output of the default port to application. CBAC works well with this standard port and creates session information based on this.
Example 5-3. Output of System Defined Port CBAC Works With
However, you may change the default port for an application to something different. For example if you want to change the Telnet port from 23 to 1025, you need to use the following command:
ip port-map telnet port 1025
Without PAM, the firewall is limited to inspecting traffic using only the well-known or registered ports associated with an application. PAM enables you to customize network access control for specific applications and services.
PAM supports host- or subnet-specific port mapping, which allows PAM to be applied to a single host or subnet using ACL. Host- or subnet-specific port mapping is done using standard ACLs. Example 5-4 shows how to change the default port for FTP.
Example 5-4. Sample Configuration Required to Change the Port
Note that with PAM, if you need to define multiple ports for an application, you need to define them with multiple commands.
Denial of Service (DoS) Detection And Prevention
DoS attack may be launched against a network in many different ways. Some of the most common DoS attacks that can be mitigated by CBAC are discussed in the sections that follow.
TCP Syn Flood and DoS Attack Launched by UDP
For a normal TCP connection to be considered established, TCP three-way handshakes must be completed (SYN, SYN-ACK, and ACK). For UDP, you need both REQUEST and REPLY packets to establish the connection. While waiting for the ACK to the SYN ACK, a connection queue of finite size on the destination host keeps track of connections waiting to be completed. The TCP SYN attack exploits this design by having an attacking source host generate TCP SYN packets with random source addresses toward a victim host. The victim destination host sends a SYN ACK back to the random source address and adds an entry to the connection queue. Because the SYN ACK is destined for an incorrect or non-existent host, the last part of the "three-way handshake" is never completed, and the entry remains in the connection queue until a timer expires. By generating invalid TCP SYN packets from random IP addresses at a rapid rate, it is possible to fill up the connection queue and deny TCP services (such as e-mail, file transfer, or WWW) to legitimate users. This affects the router's performance, which can result in the slowness of legitimate traffic and sometimes packet drops due to shortage of memory and high CPU utilization. It is not very easy to mitigate these types of attack. However, CBAC has a couple mechanisms to deal with these types of attacks:
Example 5-5 shows that the CBAC router has detected a DoS attack, going to aggressive mode, and then calming down:
Example 5-5. Sample Alert Output of a DoS Attack
A combination of %FW-4-ALERT_ON and %FW-4-ALERT_OFF error messages indicates a single attack. Example 5-5 shows a single DoS attack.
Example 5-6 shows that a sample output of a denial-of-service attack has occurred on a specific TCP host:
Example 5-6. Sample Output of a DoS Attack Against a Single TCP Host
Fragmentation of IP packets is handled differently depending on the version of the IOS you are running on the router. The following discusses two options available on an IOS Firewall for handling fragmented packets:
Keep in mind that after you apply the CBAC rule in an interface to a specific direction, DoS prevention is on by default only for that interface and for that direction.
Real-Time Alerts and Audit Trails
Alerts identify suspicious activities such as protocol violation, DoS attack, and so on. Alerts is on by default, and the alerts are by default sent to the console. If syslog is configured, alerts can also be sent to a syslog server.
The following commands can be used to turn off the global alert and can be turned on/off per protocol basis.
ip inspect alert-off ip inspect name <rule> protocol [alert <on | off>]
Note that alert configuration per protocol configuration gets higher priority than the global alert. Global alert configuration is on by default, so if you want to turn off alert configuration for a specific protocol, you need to execute the second line shown in the previous code sample. Example 5-7 shows the alerts of various protocols:
Example 5-7. Sample Output of Alerts by Different Protocols
An audit trail is generated every time a session closes (gracefully or by timeout) with the following information:
Unlike alerts, the audit trail is not on by default. You need to turn it on either in the global configuration or per protocol basis with the following commands.
ip inspect audit-trail ip inspect name <rule> protocol [audit <on | off>]
Example 5-8 shows how to turn on syslog on a Cisco router:
Example 5-8. Sample of How To Turn on Audit-Trail with Syslog on Router
Just as with alerts, audit configuration per protocol receives higher priority than the global configuration.
Example 5-9 shows a sample output of audit trail:
Example 5-9. Sample Output of an Audit Trail
Interaction of CBAC with IPsec
Cisco IOS Firewall does not inspect IPsec (Internet Protocol Security) traffic that traverses it. You need to allow AHP, ESP and UDP/500 to allow from unprotected to protected network for the IPsec tunnel to be built up and process data across CBAC. Example 5-10 shows an ACL that allows all the ports/protocols needed to build up IPsec tunnel between 10.1.1.1 and 188.8.131.52 peers:
Example 5-10. Sample Output Of Configuration To Allow IPSEC
Although CBAC does not inspect IPsec going through it, it works well with IPsec end devices. So, if you configure CBAC on the peer routers, CBAC inspects the tunneled traffic before encryption and after decryption.
Transparent Cisco IOS Firewall
The transparent firewall works on Layer 2 information, not Layer 3 of the OSI model. From version 12.3(8) T, IOS Firewall is designed to simultaneously interoperate in both Layer 2 and Layer 3 modes.
You can configure a transparent firewall just like the current L3 firewall using the ip inspect command. The inspect in/out command can be configured on any of the bridged interfaces for Layer 2 protection while also being configured on any LAN or serial interfaces to provide traditional Layer 3 protection. The transparent firewall operates on the bridged packets, and the Layer 3 firewall continues to operate on the routed packets.
To understand the CBAC fully, you must be knowledgeable about all the commands and tools available to troubleshoot the CBAC issues. The section that follows leads you through a discussion of the tools and commands available to troubleshoot CBAC effectively and efficiently.