How Context-Based Access Control (CBAC) Works
Context-based Access Control (CBAC) was designed for use with multiple port protocols that are unable to be processed with reflexive access lists. Since standard and extended access lists work at the network (Layer 3) or transport (Layer 4) layers of the OSI model, their ability to work with some applications is limited. CBAC loosens these limitations by filtering packets based on the application (Layer 7) layer of the OSI model. Version 11.2 of the firewall feature set IOS includes CBAC for 1600 and 2500 series routers. IOS Version 12.0 expands the covered routers to include 1700, 2600, and 3600 series routers.
The major additional features enabled through the use of CBAC are as follows:
Application-layer filtering— CBAC filters TCP and UDP packets based on application-layer protocol session information. CBAC can be configured to inspect traffic for sessions that originate from either inside or outside of the corporate network. By watching not only Layers 3 and 4, but also Layer 7, CBAC learns the state of connection sessions and filters based upon that state. When a protocol, such as RPC or SQL*NET, requires negotiation of multiple channels, CBAC is still able to filter effectively where a standard or extended access list could not.
IP packet fragmentation prevention and DoS defenses— CBAC can detect and prevent certain types of network attacks, such as SYN-flooding. SYN-flooding is a type of DoS attack where multiple sync requests are sent to a router. The router holds these connections open until they time out or are completed. CBAC watches the packet sequence numbers for all connections and drops those that are of a suspicious origin. Suspicious packets are those outside of the expected range of sequence numbers. Additionally, CBAC detects and sends alert messages when an inordinately high number of new connections are seen.
Administrative alerts and audit trails— CBAC creates audit trails and real-time alerts based on the events tracked by the firewall. Audit trails use syslog to track network transactions. The data included in this tracking contains source and destination address, source and destination port, and time stamps. Real-time alerts occur by sending syslog error messages to central management consoles.
Support for the Cisco IOS Intrusion Detection System (IDS)— The Cisco IOS Firewall's Intrusion Detection System (Cisco IOS IDS) identifies a total of 59 of the most common attacks using the distinctive signatures of these attacks to detect patterns. CBAC has the ability to send data directly to a Cisco IDS component.
CBAC Operation
CBAC works in much the same manner as reflexive access lists. Both create temporary openings in access lists based on traffic traversing the external interface outbound from the router. These openings allow the returning traffic to enter the internal network back through the firewall. This traffic, normally blocked, is then allowed back through the router. In CBAC, only data from the same session that originally triggered the opening is allowed back through.
CBAC inspects traffic traveling through the router in order to discover and manage information about the state of TCP and UDP sessions. This information is used to create a temporary opening in access lists, allowing return traffic and additional data connections. These temporary access entries are never saved to NVRAM.
CBAC is limited in its ability to work with certain protocols. Not all protocols are supported, only those specified. If a protocol is not specified, no CBAC inspection will occur. As with all security methods, complete security cannot be guaranteed. CBAC excels in the detection and prevention of the most popular forms of attack.
CBAC is usable only with IP protocol traffic, and only TCP and UDP packets are inspected. ICMP is not inspected with CBAC. Use standard or extended access lists instead of CBAC for ICMP. CBAC also ignores ICMP Unreachable messages.
Figure 5-5 shows an example of CBAC in action. When the user on the host initiates a connection to another host on the opposite side of the router, an opening is created on the outside of the router to allow the responding packets for this connection to travel through the router. Once this session has ended, this newly created opening will again be closed.
Figure 5-5. CBAC Creating a Temporary Opening Through the Firewall Router
The administrator must specify which protocols are to be inspected, as well as the interfaces and direction on which the inspection of these protocols occurs. Only the protocols specified will be inspected. The selected protocols will be inspected in both directions as they traverse the interface.
The inspection of the control channel allows CBAC to detect and prevent certain types of application-based attacks. Packets are inspected by the access list first. CBAC then inspects and monitors the control channels of the connections. For example, when using FTP, CBAC parses the FTP commands and responses to those commands, but the actual data being transferred within the FTP program is not inspected. This is an important point, because only the control channels are monitored for state changes, not the data channels. Sequence numbers are tracked, and packets without the expected sequence number are dropped. CBAC has knowledge of application-specific commands and will detect and prevent some forms of attacks based on the nuances of applications. On detection of an attack, the DoS feature built into CBAC responds in one of three ways:
Protect system resources
Block packets from the source of the suspected attack
Generate alert messages
This feature protects system resources by determining when to drop sessions that have not become fully established. Timeout values for network sessions are set in order to free up system resources by dropping sessions after the specified time. Threshold values for network sessions are set in order to prevent DoS attacks by controlling the number of half-open sessions. CBAC drops a session to reduce resource usage, and a reset message is sent to both the source and destination for that session. There are three thresholds used by CBAC in relation to DoS attacks:
The total number of half-open sessions
The number of half-open session per given amount of time
The number of half-open TCP session per host
When a threshold is exceeded, CBAC acts in one of two ways:
Sends a reset message to source and destination of the oldest half-open session and drops the session.
Blocks all SYN packets for the time specified with the threshold value. This is only used on TCP sessions.
To activate DoS prevention and detection, an inspection rule must be created and applied to an interface. This inspection rule needs to include the protocols you wish to monitor regarding DoS attacks.
As packets traverse the interface, a state table is maintained. Returning traffic is compared to this table to ensure that the packet belongs to a current session.
UDP is a connectionless service. Therefore, no session information is carried in UDP packets. CBAC uses a method of approximation to ensure reasonable care is used when allowing UDP packets through an interface. Each UDP packet is compared to previous UDP packets to see whether the source and destination addresses match, the port numbers match, and so on. Additionally, inbound UDP packets must be received after an outbound UDP packet within the time specified by the udp idle timeout command.
Sequence of CBAC Events
CBAC follows a defined flow of events when dealing with packets. Figure 5-6 shows the logical flow for these events. Take a few moments to view this logical flowchart before moving through the supported protocols.
Figure 5-6. Sequence of CBAC Events
Protocol Sessions Supported by CBAC
CBAC can be configured to support the protocol sessions outlined in Table 5-2.
| Protocol | Notes |
|---|---|
| TCP | Handles all types of TCP session |
| UDP | Handles all types of UDP sessions |
| CU-SeeMe | White Pine version only |
| FTP | CBAC does not allow third-party connections. Data channels must have the destination port in the range of 1024 to 65,535 only |
| H.323 | Microsoft NetMeeting and ProShare use H.323 |
| HTTP | Java blocking |
| Microsoft NetShow | |
| Java | Protects against unidentified, malicious Java applets |
| UNIX R commands | rsh, rexec, rlogin, and so on |
| RealAudio | |
| SUN RPC | SUN compliant RPC, does not handle DCE RPC |
| Microsoft RPC | |
| SMTP | Any packet not on the following list is considered illegal: DATA, EHLO, EXPN, HELO, HELP, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SEND, SOML, VRFY |
| SQL*Net | |
| StreamWorks | |
| TFTP | |
| VDOLive | |
The term supported means that when a protocol is configured for CBAC, that protocol traffic is inspected, state information is maintained, and packets are allowed back through the firewall only if they belong to a permissible session (with the exception of connectionless protocols, such as UDP).
Compatibility with Cisco Encryption Technology (CET) and IPSec
When three routers are connected, the middle router is using CBAC, and the outside routers are running encryption, the results might not be what you expect. The reason is that CBAC cannot accurately inspect payloads that have been encrypted. This should be an expected occurrence, because encryption is specifically designed to prevent any but the end routers from being able to decipher the data. This situation is presented in Figure 5-7.
Figure 5-7. Compatibility with CET
Additionally, configuring both CBAC and encryption on the same router causes CBAC to stop working with some protocols. CBAC will still work with single-channel TCP and UDP, with the exception of Java and SMTP. CBAC will not work with any multiple channel protocols, except StreamWorks and CU-SeeMe. Therefore, when configuring both encryption and CBAC on the same router, configure Generic TCP, Generic UDP, CU-SeeMe, and StreamWorks as the only protocols.
CBAC is compatible with IPSec under limited circumstances. If the router running CBAC is the endpoint of an IPSec connection, there are no known compatibility issues. However, if the router running CBAC is not the endpoint of an IPSec connection, the same problem as with encryption occurs. For CBAC to run properly, the data within individual packets must be examined. Any time that this data is encrypted, CBAC will not work. Additionally, IPSec packets are not IP or UDP packets, which are the only types of packets CBAC is able to process.