Context-Based Access Control (CBAC) is a per-application control mechanism that adds advanced traffic filtering functionality to firewalls that isn’t limited, as are access lists, to examining packets at the network or transport layer. While CBAC examines both of these layers, it also examines the application-layer protocol data to monitor the state of a given TCP or UDP session. This means, as multiple channels are created or used by applications such as SQL*Net, FTP, and RPC, CBAC can respond by creating temporary openings in the firewall access lists to allow return traffic and additional data connections for specified sessions that originated from within the protected network. This application-layer awareness and capability to evolve with the traffic is beyond the capabilities of access list technologies.
Before continuing with CBAC, it’s important to be clear about how standard and extended ACLs work. By definition, standard ACLs filter only on source network addresses and are, therefore, limited to Layer 3 capabilities. Extended ACLs are able to filter on port numbers extending their reach into Layer 4. In both cases, any ACL allowing traffic to enter a network is, in fact, a hole in the firewall or perimeter security that can possibly be exploited by others.
The preceding chapter introduced reflexive ACLs as an alternative to creating permanent holes through the network security. Temporary ACL statements can be created for inbound traffic based on outbound traffic reducing risk of exploitation. Unfortunately, reflexive ACLs are limited to Layer 4 filters, like any other extended ACL. Furthermore, reflexive ACLs can’t deal with changes in port designations by the outside host, such as FTP. The outbound address/port combinations for the source and destination are “mirrored” to create the inbound openings. Another limitation of reflexive ACLs is that they’re limited to single channel applications.
Understanding CBAC might be made easier if you think of it as reflexive ACLs without the limitations. CBAC adds inspection intelligence to ACL capabilities by reading the entire packet for application status information, which is stored in the state table. Like reflexive ACLS, CBAC watches outbound traffic to determine what packets to let in; but unlike reflexive ACLs, CBAC can make decisions based on how the application behaves, not only the addresses and port number it uses.
CBAC can open any additional inbound channels required for returning data that were negotiated by the outgoing data for a particular application.
When a session times out or ends, the state table and ACL entries are deleted, and the opening closes to additional traffic.
CBAC can be configured to inspect and filter the following IP sessions and application-layer protocols:
All TCP sessions, regardless of the application-layer protocol (sometimes called single-channel or generic TCP inspection).
All UDP sessions, regardless of the application-layer protocol (sometimes called single-channel or generic UDP inspection).
CU-SeeMe (White Pine version only), an Internet videoconferencing program developed as freeware by Cornell University. WhitePine, Inc., sells an enhanced commercial version.
FTP doesn’t support third-party connections (three-way FTP transfer). Allows data channels with the destination ports 1024 to 65535. CBAC won’t open a data channel if the FTP client-server authentication fails.
HTTP (Java blocking).
Microsoft NetShow.
UNIX R-commands, such as rlogin, rexec, and rsh.
RealAudio.
H.323, such as NetMeeting and ProShare
Real-Time Streaming Protocol (RTSP): CBAC supports the following RTSP data transport modes.
Standard Real-Time Transport Protocol (RTP) IETF standard (RFC 1889) for real-time audio and video applications, such as Cisco IP/TV and Apple QuickTime 4 software. RTP uses the RTP Control Protocol (RTCP) to manage the multimedia data stream.
RealNetworks Real Data Transport (RDT) Proprietary protocol developed by RealNetworks used for RealServer G2. Uses RTSP for communication control and RDT for the data connection and retransmission of lost packets.
Interleaved (Tunnel Mode) Uses the control channel to tunnel RTP or RDT traffic.
Synchronized Multimedia Integration Language (SMIL) Layout language that allows the creation of multimedia presentations made up of music, voice, image, text, video, and graphics elements. Uses multiple RTSP control and data streams between the player and the servers. Currently available only for RTSP and RDT, but SMIL is a proposed specification of the World Wide Web Consortium (W3C). RealNetworks RealServer and RealServer G2 support SMIL, while Cisco IP/TV and Apple QuickTime 4 don’t.
RPC Sun RPC, but not DCE RPC.
Simple Mail Transport Protocol (SMTP) CBAC can inspect SMTP, but not Extended Simple Mail Transport Protocol (ESMTP).
SQL*Net
StreamWorks
TFTP
VDOLive
As with all things that seem too good to be true, some limitations must be recognized and worked around:
Only IP TCP and UDP traffic is inspected by CBAC, so ICMP traffic and any other Layer 3 protocols need to be filtered using extended ACLs.
Any traffic where the router is the source or destination won’t be inspected. CBAC will filter traffic passing through, but not traffic originating or terminating on that device.
Because CBAC only detects and protects against attacks that travel through the firewall, it doesn’t normally protect against attacks originating from within the protected network. Deploying CBAC on an intranet-based router is possible.
CBAC can’t inspect in-transit IPSec traffic. Because the IPSec traffic is encrypted, CBAC can’t interpret it and, therefore, drops it. CBAC and IPSec can only work together at tunnel endpoint by applying IPSec to the external interface and CBAC on the internal interface.
You need to consider two issues when determining which model of router to use for CBAC and how much memory to install.
CBAC uses about 600 bytes of memory per connection established.
A slight amount of additional CPU processing is used to inspect packets. While evaluating long access lists can negatively impact performance, CBAC mitigates this by hashing ACLs, and then evaluates the hash.
The following steps describe the sequence of events for CBAC configured on an external interface connected to the Internet. The example starts with an outbound packet, which is the first of a new TCP session configured for CBAC inspection.
The outbound packet reaches the firewall’s external interface.
The packet is checked against the interface’s existing outbound ACL, and the packet is permitted. A denied packet would be discarded at this point and couldn’t be evaluated by CBAC to allow inbound traffic. With no outbound traffic, there shouldn’t be returning traffic.
If the packet’s application is configured for CBAC inspection, CBAC inspects the packet to determine and record the state information of the connection. As a new session, a new state table entry is created for the new connection. If the application isn’t configured for CBAC inspection, it would go directly to Step 5.
Using the state information, CBAC creates a temporary entry inserted at the beginning interface’s inbound extended ACL. This temporary entry is designed to allow inbound packets that are part of the same session.
The outbound packet is forwarded out the interface.
When an inbound packet from the just-established session reaches the interface, it’s evaluated against the inbound ACL and permitted by the temporary entry created in Step 4.
The packet permitted in Step 6 is then inspected by CBAC, and the connection’s state table entry is updated as necessary. Based on this updated state information, the inbound extended ACL temporary entries can be modified to permit only packets that are valid for the current state of the connection.
Additional inbound and outbound packets from the connection are inspected to update the state table and the temporary inbound ACL entries as needed. The packets are forwarded through the interface.
When the connection terminates or times out, the related entries in the state table and the inbound ACL are deleted.
To configure CBAC, perform the following tasks. Each task is described in the following sections.
Set Audit Trails and Alerts
Set Global Timeouts and Thresholds
Define Port-to-Application Mapping (PAM)
Define Inspection Rules
Apply Inspection Rules and ACLs to an interface
Test and Verify
Real-time alerts send syslog error messages to central management consoles upon detecting suspicious activity, allowing network managers to respond immediately to intrusions. Enhanced audit-trail features use syslog to track all transactions, recording time stamps, source host, destination host, ports used, session duration, and the total number of transmitted bytes for advanced, session-based reporting.
Cisco IOS Firewall alerts and audit-trail features are now configurable, enabling more flexible reporting and error tracking. The configurable audit-trail features support mod- ular tracking of specific CBAC-supported applications and Java blocking. Both the real-time alerts and the audit-trail features are supported by a variety of third-party reporting tools.
Use the Global Configuration Mode command ip inspect audit-trail to turn on CBAC audit-trail messages. The messages are displayed on the console after each CBAC session closes. Use the no form of the command to turn off the feature. The syntax is
Rtr1(config)#ip inspect audit-trail
Rtr1(config)#no ip inspect audit-trail
This command has no arguments or keywords. By default, the audit-trail messages aren’t displayed. This command was introduced in IOS 11.2 P.
The following messages are two examples of audit-trail messages. To determine which protocol was inspected, refer to the responder’s port number following the responder’s IP address.
%FW-6-SESS_AUDIT_TRAIL: tcp session initiator (192.168.1.13:33192) ????sent 22 bytes -- responder (192.168.129.11:25) sent 208 bytes %FW-6-SESS_AUDIT_TRAIL: ftp session initiator 192.168.1.13:33194) ????sent 336 bytes -- responder (192.168.129.11:21) sent 325 bytes
CBAC alert messages are displayed on the console by default. Use the Global Configuration Mode command ip inspect alert-off to disable these messages. To reenable CBAC alert messages, use the no form of the command. The syntax is
Rtr1(config)#ip inspect alert-off Rtr1(config)#no ip inspect alert-off
This command has no arguments or keywords. This command was introduced in IOS 12.0(5)T.
While it isn’t a CBAC feature, make sure logging is enabled and a syslog server is specified, so any incidents are properly logged for future reference.
Rtr1(config)#service timestamps log datetime Rtr1(config)#logging host Rtr1(config)#logging facility facility-type Rtr1(config)#logging trap level
The commands,—in order,—do the following:
Adds the date and time to syslog and audit-trail messages.
Defines the host name or IP address of the host to send syslog messages to.
Configures the syslog facility in which error messages are sent.
(Optional) Limits messages logged to the syslog servers based on severity. The default is level 7 (informational).
This section looks at configuring the following global timeouts and thresholds used by CBAC.
TCP SYN and FIN wait times
TCP, UDP, and DNS idle timers
TCP flooding thresholds (DoS indicators)
These are global default settings used by CBAC to determine how long to maintain state table entries and as indicators of possible DoS attacks. Each command has a default value and, therefore, needs to be set only to change the default to implement a security policy better.
Use the Global Configuration Mode command ip inspect tcp synwait-time to define the number of seconds the software will wait for a TCP session to reach the established state before dropping the session. The session is considered to have reached the established state after the session’s first SYN bit is detected. Use the no form of this command to reset the timeout to the default of 30 seconds. The syntax is
Rtr1(config)#ip inspect tcp synwait-time seconds
Rtr1(config)#no ip inspect tcp synwait-time
This command was introduced in IOS 11.2 P. The default is 30 seconds.
The value specified for this timeout applies to all TCP sessions inspected by CBAC.
Use the Global Configuration Mode command ip inspect tcp finwait-time to define how many seconds a TCP session will still be managed after the firewall detects a FIN-exchange. The FIN-exchange occurs when the TCP session is ready to close. Use the no form of the command to reset the timeout to the default of five seconds. The syntax is
Rtr1(config)#ip inspect tcp finwait-time seconds
Rtr1(config)#no ip inspect tcp finwait-time
This command was introduced in IOS 11.2 P. The default is five seconds.
The timeout set with this command is referred to as the finwait timeout. It applies to all CBAC-inspected TCP sessions.
Use the Global Configuration Mode command ip inspect tcp idle-time to specify the TCP idle timeout—the number of seconds a TCP session will still be managed after no activity. Use the no form of the command to reset the timeout to the default of 3,600 seconds (one hour). The syntax is
Rtr1(config)#ip inspect tcp idle-time seconds
Rtr1(config)#no ip inspect tcp idle-time
This command was introduced in IOS 11.2 P. The default is 3,600 seconds (one hour).
When CBAC detects a valid TCP packet that’s the first in a session for a protocol CBAC is inspecting, the software creates a new state table entry with the information. If no TCP packets for a particular session are detected for the time defined by the TCP idle timeout, the software drops that session entry from the state table and ACL.
This global value can be overridden for specific interfaces by defining a set of inspection rules with the Global Configuration Mode command ip inspect name. This command only applies the new timeout to any new or existing inspection rules that don’t have an explicitly defined timeout.
Use the Global Configuration Mode command ip inspect udp idle-time to specify the UDP idle timeout, the number of seconds a UDP “session” will still be managed after no activity. Use the no form of the command to reset the timeout to the default of 30 seconds. The syntax is
Rtr1(config)#ip inspect udp idle-time seconds Rtr1(config)#no ip inspect udp idle-time
This command was introduced in IOS 11.2 P. The default is 30 seconds.
When CBAC detects a valid UDP packet that’s the first in a session for a protocol CBAC is inspecting, the software creates a new state table entry with the information. Because UDP is a connectionless service, no actual sessions exist, so the software approximates sessions by examining the information in the packet and determining if the packet is similar to other UDP packets (for example, similar source/destination addresses) and if the packet was detected soon after another similar UDP packet.
Because UDP is a connectionless service, no actual sessions exist as with TCP, so CBAC approximates sessions. It does this by examining the packets and determining if they’re similar (source/destination addresses and ports) to other UDP packets. If no UDP packets for a particular session are detected for the time defined by the UDP idle timeout, the software drops those session entries from the state table and ACL.
This global value can be overridden for specific interfaces when you define a set of inspection rules with the Global Configuration Mode command ip inspect name. This command only applies the new timeout to any new or existing inspection rules that don’t have an explicitly defined timeout.
Use the Global Configuration Mode command ip inspect dns-timeout to specify the DNS idle timeout, the length of time a DNS-name lookup session will still be managed after no activity. Use the no form of the command to reset the timeout to the default of five seconds. The syntax is
Rtr1(config)#ip inspect dns-timeout seconds
Rtr1(config)#no ip inspect dns-timeout
This command was introduced in IOS 11.2 P. The default is five seconds.
When CBAC detects a valid UDP packet for a new DNS-name lookup session for a protocol CBAC is inspecting, the software creates a new state table entry with the information. If the software detects no packets for the DNS session for a time period defined by the DNS idle timeout, the software then drops that session entry from the state table and ACL.
The DNS idle timeout applies to all DNS-name lookup sessions inspected by CBAC and overrides the global UDP timeout. The DNS idle timeout value also enters Aggressive mode and overrides any timeouts specified for specific interfaces when you define a set of inspection rules with the ip inspect name command.
An unusually high number of half-open sessions can indicate a DoS attack is occurring. For TCP, half-open means that the session hasn’t reached the established state. For UDP, half-open means that the firewall has detected traffic from one direction only.
CBAC measures both the total number of existing half-open sessions and the rate of session establishment attempts. Both TCP and UDP half-open sessions are counted in the total number and rate measurements. Measurements are made once a minute.
When the number of existing half-open sessions rises above the threshold set by the ip inspect max-incomplete high command, the software then deletes half-open sessions until the number of existing half-open sessions drops below the threshold set by the ip inspect max-incomplete low command.
The global value specified for this threshold applies to all TCP and UDP connections inspected by CBAC.
Use the Global Configuration Mode command ip inspect max-incomplete high to define the number of existing half-open sessions that will cause the software to start deleting half-open sessions. Use the no form of the command to reset the threshold to the default of 500. The syntax is
Rtr1(config)#ip inspect max-incomplete high number
Rtr1(config)#no ip inspect max-incomplete high
This command was introduced in IOS 11.2 P. The default is 500 half-open sessions.
Use the Global Configuration Mode command ip inspect max-incomplete low to define the number of existing half-open sessions that will cause the software to stop deleting half-open sessions. Use the no form of the command to reset the threshold to the default of 400 half-open sessions. The syntax is
Rtr1(config)#ip inspect max-incomplete low number
Rtr1(config)#no ip inspect max-incomplete low
This command was introduced in IOS 11.2 P. The default is 400 half-open sessions.
The following example causes the CBAC to start deleting half-open sessions when the number of half-open sessions rises above 800 and to stop when the number drops below 500.
Rtr1(config)#ip inspect max-incomplete high 800
Rtr1(config)#ip inspect max-incomplete low 500
This is an extension of the preceding threshold, accelerating the process to respond to a rapid increase in incomplete sessions. These rate thresholds are measured as the number of new session connection attempts detected in the last one-minute sample period.
The global value specified for this threshold applies to all TCP and UDP connections inspected by CBAC.
Use the Global Configuration Mode command ip inspect one-minute high to define the number of new unestablished sessions that will cause the software to start deleting half-open sessions. Use the no form of the command to reset the threshold to the default of 500. The syntax is
Rtr1(config)#ip inspect one-minute high number
Rtr1(config)#no ip inspect one-minute high
This command was introduced in IOS 11.2 P. The default is 500 half-open sessions.
Use the Global Configuration Mode command ip inspect one-minute low to define the rate of new unestablished TCP sessions that will cause the software to stop deleting half-open sessions. Use the no form of this command to reset the threshold to the default of 400. The syntax is
Rtr1(config)#ip inspect one-minute low number
Rtr1(config)#no ip inspect one-minute low
This command was introduced in IOS 11.2 P. The default is 400 half-open sessions.
The following example causes the software to start deleting half-open sessions when more than 1,000 session establishment attempts are detected in the last minute and to stop when fewer than 750 sessions are detected in the last minute:
Rtr1(config)#ip inspect one-minute high 1000
Rtr1(config)#ip inspect one-minute low 750
An unusually high number of half-open sessions with the same destination host address can indicate that a DoS attack is being launched against the host. Use the Global Configuration Mode command ip inspect tcp max-incomplete host to specify threshold and blocking time values for TCP host–specific DoS detection and prevention. Use the no form of the command to reset the threshold and blocking time to the default values. The syntax is
Rtr1(config)#ip inspect tcp max-incomplete host number block-time seconds
Rtr1(config)#no ip inspect tcp max-incomplete host
number |
Specifies how many half-open TCP sessions with the same host destination address can exist at a time, before the software starts deleting half-open sessions to the host. Use a number from 1 to 250. |
block-time |
Specifies blocking of connection initiation to a host. |
seconds |
Specifies how long the software will continue to delete new connection requests to the host. |
This command was introduced in IOS 11.2 P. The default is 50 half-open sessions and 0 minutes.
When the numbers of half-open sessions with the same destination host address rises above this threshold, CBAC will delete half-open sessions choosing a method based on the block-time seconds setting. If the timeout is
0 (the default) |
CBAC will delete the oldest half-open session for the host for every new connection request to the host. This ensures the number of half-open sessions to a given host will never exceed the threshold. |
Greater than 0 |
CBAC will delete all existing half-open sessions for the host, and then block all new connection requests to the host until the block-time expires. |
The software also sends syslog messages whenever the max-incomplete host number is exceeded and when blocking of connection initiations to a host starts or ends.
The global values specified for the threshold and blocking time apply to all TCP connections inspected by CBAC.
The following example changes the max-incomplete host number to 70 half-open sessions and changes the block-time timeout to 90 seconds.
Rtr1(config)#ip inspect tcp max-incomplete host 70 block-time 90
Flexible, per-application port mapping allows CBAC-supported applications to be run on nonstandard TCP and UDP ports. PAM allows network administrators to customize access control for specific applications and services to meet the distinct needs of their networks.
The ip port-map command associates TCP or UDP port numbers with applications or services, establishing a table of default port mapping information at the firewall. This information is used to support network environments that run services using ports that are different from the registered or well-known ports associated with a service or application. PAM also supports port mapping for specific host(s) or subnet(s) by using standard ACLs.
The port mapping information in the PAM table is one of three types:
System defined
User defined
Host specific
Initially, PAM creates a set of system-defined entries in the mapping table using well-known or registered port mapping information set up during the system startup. The Cisco IOS Firewall CBAC feature requires the system-defined mapping information to function properly. The system-defined mapping information can’t be deleted or changed. It isn’t possible to assign an application to an existing system-defined mapping, such as attempting to map HTTP services to port 25 (SMTP). The following table shows the well-known or registered port mapping information.
Application Name |
Registered Port Number |
Protocol Description |
---|---|---|
Cuseeme |
7648 |
CU-SeeMe Protocol |
Exec |
512 |
Remote process execution |
ftp |
21 |
File Transfer Protocol (control port) |
http |
80 |
Hypertext Transfer Protocol |
h323 |
1720 |
H.323 Protocol (such as MS NetMeeting and Intel Video Phone) |
login |
513 |
Remote login |
msrpc |
135 |
Microsoft Remote Procedure Call |
netshow |
1755 |
Microsoft NetShow |
real-audio-video |
7070 |
RealAudio and RealVideo |
smtp |
25 |
Simple Mail Transfer Protocol |
sql-net |
1521 |
SQL-NET |
streamworks |
1558 |
StreamWorks Protocol |
sunrpc |
111 |
SUN Remote Procedure Call |
tftp |
69 |
Trivial File Transfer Protocol |
vdolive |
7000 |
VDOLive Protocol |
Network applications that use nonstandard ports require user-defined entries in the mapping table. Use the Global Configuration Mode command ip port-map to create user-defined entries ports to application mapping. Use the no form of the command to delete user-defined PAM entries. The command can’t be used to change system-defined port mappings. The syntax is
Rtr1(config)#ip port-map appl-name port port-num [list acl#]
Rtr1(config)#no ip port-map appl-name port port-num [list acl#]
appl-name |
The name of the application with which to apply the port mapping |
port |
Indicates a port number maps to the application |
port-num |
Port number (1 to 65535) |
list |
The port mapping information applies to a specific host or subnet |
acl# |
Standard ACL number used to identify the host(s) or subnet(s) |
This command was introduced in IOS 12.0(5)T. No default values.
This example shows PAM entries that define a range of nonstandard ports for HTTP services.
Rtr1(config)#ip port-map http port 8000 Rtr1(config)#ip port-map http port 8001 Rtr1(config)#ip port-map http port 8002
User-defined entries in the mapping table can include host-specific mapping, which establishes port mapping information for specific hosts or subnets. In some situations, it might be necessary to override the default port mapping information for a specific host or subnet, including a system-defined default port mapping information. Use the list option for the ip port-map command to specify an ACL for a host or subnet that uses PAM.
In this example, a specific host uses port 8000 for FTP services. ACL 1 identifies the server address (192.168.0.100), while port 8000 is mapped with FTP services:
Rtr1(config)#access-list 1 permit 192.168.0.100 Rtr1(config)#ip port-map ftp port 8000 list 1
In the next example, the same port number is required by different services running on different hosts. Port 8000 is required for FTP services by host 192.168.0.100, while port 8000 is required for HTTP services by host 192.168.0.175. ACL 10 and ACL 2 identify the specific hosts, while PAM maps the ports with the services for each ACL.
Rtr1(config)#access-list 1 permit 192.168.0.100 Rtr1(config)#access-list 2 permit 192.168.0.175 Rtr1(config)#ip port-map ftp port 8000 list 1 Rtr1(config)#ip port-map http port 8000 list 2
This example shows a failed attempt to assign the RealAudio application to port 21, which is normally reserved for FTP services. Following that is the correct method to define the host using ACL 1. With this configuration, host(s) in List 1 won’t recognize FTP activity on port 21.
Rtr1(config)#ip port-map realaudio port 21 Rtr1(config)#Command fail: the port 21 has already been defined for ????????ftp by the system. ????????No change can be made to the system defined port mappings. Rtr1(config)#access-list 1 permit 192.168.0.100 Rtr1(config)#ip port-map realaudio port 21 list 1
Use the Privileged EXEC Mode command show ip port-map to display the Port to Application Mapping (PAM) information. This command displays the port mapping information at the firewall, including the system-defined and user-defined information. Include the application name to display only the entries for that application. Include the port number to display only the entries for that port. The syntax is
Rtr1#show ip port-map [appl-name | port port-num]
This command was introduced in IOS 12.0(5)T.
The following example shows the port mapping information for FTP services:
Rtr1#show ip port-map ftp Default mapping: ftp ?????????????port 21 ?????????????????system defined Host specific: ??ftp ?????????????port 1250 ??in list 1 ???user defined
To define a set of inspection rules, use the ip inspect name command with the same inspection name for each protocol you want CBAC to inspect. Each set of inspection rules must have a unique inspection name, which shouldn’t exceed the 16-character limit. Typically, if inspection is configured for a protocol, return traffic entering the internal network is only permitted if the packets are part of a valid, existing session for which state information is being maintained.
Define either one or two sets of rules per interface. A single set can be used to examine both inbound and outbound traffic, or you can define two sets: one for outbound traffic and one for inbound traffic. To define a single set of inspection rules, configure inspection for all the desired application-layer protocols and for TCP or UDP, as desired. This combination of TCP, UDP, and application-layer protocols join together to form a single set of inspection rules with a unique name.
In general, to configure CBAC inspection for a protocol, packets for that protocol should be permitted to exit the firewall by configuring the appropriate ACL if necessary. Packets for that protocol will only be allowed back in through the firewall if they belong to a valid existing session. Without outbound packets, there can be no existing session. Each protocol packet is inspected to maintain information about the session state.
Use the Global Configuration Mode command ip inspect name to define a set of inspection rules. Use the no form of this command to remove the inspection rule for a protocol or to remove the entire set of inspection rules. The syntax is
Rtr1(config)#ip inspect name inspection-name protocol [alert {on | off}] [audit-trail
{on | off}] [timeout seconds]
Rtr1(config)#no ip inspect name inspection-name protocol (removes a protocol inspection rule)
Rtr1(config)#no ip inspect name (removes the entire set of inspection rules)
inspection-name |
Name of inspection rules set. Up to 16 characters. To add a protocol to an existing set of rules, use the same inspection-name. |
protocol |
Application protocol name is supported by CBAC. |
alert {on | off} |
(Optional) Each inspected protocol can override the default settings created by the global ip inspect alert-off command. |
audit-trail {on | off} |
(Optional) Each inspected protocol can override the default settings created by the global ip inspect audit-trail command. |
timeout seconds |
(Optional) Each inspected protocol can override the default global TCP or UDP idle timeouts, but won’t override the global DNS timeout. |
This command was introduced in IOS 11.2P. Configurable alert and audit-trail, IP fragmentation checking, and NetShow protocol support were added in 12.0(5)T.
Configuring TCP and UDP inspection will permit any TCP and UDP packets to enter the internal network through the firewall, even if the application-layer protocol isn’t configured to be inspected. TCP and UDP inspection doesn’t recognize application-specific commands or processes and might not permit all returning packets for that application. Any returning application packets with port numbers different than the exiting packet will be blocked.
Application-layer protocol inspection takes precedence over the TCP or UDP packet inspection. For example, with FTP inspection, all control channel information will be recorded in the state table, and all FTP traffic is permitted back through the firewall if the control channel information is valid for the state of the FTP session. Any TCP inspection in this case becomes irrelevant.
Generic TCP and UDP inspection is much like reflexive ACLs, in that the packets entering the network must exactly match an existing session. This match is based on having the same source/destination addresses and source/destination port numbers as the existing packet, except reversed. Otherwise, the inbound packets are blocked at the interface.
The following example causes the software to inspect TCP sessions and UDP sessions, and to specifically allow FTP and Real Audio traffic back through the firewall for existing sessions only. UDP traffic has the audit-trail feature on, while the FTP timeout is changed to three minutes.
Rtr1(config)#ip inspect name letusin tcp Rtr1(config)#ip inspect name letusin udp audit-trail on Rtr1(config)#ip inspect name letusin ftp timeout 180 Rtr1(config)#ip inspect name letusin realaudio-video
If you want CBAC inspection to work with Microsoft NetMeeting 2.0 traffic, an H.323 application-layer protocol, it’s necessary also to configure inspection for TCP because NetMeeting 2.0 uses an additional TCP channel not defined in the H.323 specification. No special configuration options exist for H.323
To add Microsoft NetMeeting 2.0 inspection, it’s necessary to add only the following entry because TCP inspection is on in the initial example:
Rtr1(config)#ip inspect name letusin h323
With the proliferation of Java applets available on the Internet, protecting networks from malicious applets has become a major concern to network managers. The Java blocking feature can be configured either to filter or to completely deny access to Java applets.
Java inspection enables Java applet filtering at the firewall. Java applet filtering distinguishes between trusted and untrusted applets by relying on a list of external sites you designate as “friendly.” If an applet is from a friendly site, the firewall allows the applet through. If the applet isn’t from a friendly site, the applet is blocked. Alternatively, you could permit applets from all sites, except sites specifically designated as “hostile.”
Java blocking uses only numbered standard access lists to define friendly and hostile external sites. ACL “permit” statements define traffic from friendly sites, while ACL “deny statements” define traffic from hostile sites. If Java blocking is defined using an ACL number and no matching ACL exists, all Java applets will be blocked.
Note? |
CBAC can’t detect or block encapsulated or “zipped” Java applets. Applets in .zip or .jar format aren’t blocked at the firewall. CBAC also doesn’t detect or block applets loaded via FTP, gopher, or HTTP on a nonstandard port. |
Use the no form of the command to remove Java blocking from the inspection set. The syntax is
Rtr1(config)#ip inspect name inspection-name [http [java-list acl#]] [alert {on | off}]
[audit-trail {on | off}] [timeout seconds]
Rtr1(config)#no ip inspect name inspection-name http
http |
Specifies Java applet blocking |
java-list acl# |
A “numbered standard” ACL used to define friendly sites. |
The next example would add blocking of all Java applets to the inspection set.
Rtr1(config)#ip inspect name letusin http
If the next example was used instead, all Java applets would be blocked except those originating from the server 192.168.0.10.
Rtr1(config)#access-list 15 permit 192.168.0.10 Rtr1(config)#ip inspect name letusin http java-list 15
RPC inspection allows the specification based on program numbers. To define multiple program numbers, create multiple entries for RPC inspection, each with a different program number. If a program number is specified, all traffic for that program number is permitted. Any program number that isn’t specified will have all traffic for that program number blocked.
Use the no form of the command to remove RPC inspection from the inspection set. The syntax is
Rtr1(config)#ip inspect name inspection-name [rpc program-number number [wait-time
minutes]] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]Rtr1(config)#no ip inspect name inspection-name rpc
rpc program-number number |
The RPC program number to permit. |
wait-time minutes |
(Optional) Number of minutes to keep a small hole in the firewall to allow subsequent RPC connections from the same source address, and to the same destination address and port. Default is zero minutes. |
The following example adds two RPC program numbers to the inspection set.
Rtr1(config)#ip inspect name letusin rpc program-number 100002 Rtr1(config)#ip inspect name letusin rpc program-number 100010
CBAC inspection rules can help protect hosts against DoS attacks involving fragmented IP packets. Even if the firewall prevents an attacker from completing a connection to a protected host, the attacker might still be able to disrupt services provided by that host in two ways: by sending a large number of “noninitial” IP fragments or by sending a complete set of fragmented packets through a router that has an ACL that filters out the first fragment of the packet. Either way, the remaining fragments can tie up host resources as it tries in vain to reassemble the incomplete packets.
Using fragmentation inspection, the CBAC maintains an interfragment state for IP traffic. Noninitial fragments are discarded unless the corresponding initial fragment has already been permitted to pass through the firewall. Noninitial fragments received before the corresponding initial fragments are discarded. Because many circumstances exist that can cause out-of-order delivery of legitimate fragments, fragmentation inspection can have a severe performance implications. For this reason, fragment inspection is off by default.
Use the no form of the command to remove fragment inspection from the inspection set. The syntax is
Rtr1(config)#ip inspect name inspection-name fragment [max number timeout seconds]
Rtr1(config)#no ip inspect name inspection-name fragment
fragment |
Specifies fragment inspection for the named inspection set. |
max number |
This is the maximum number of unassembled packets for which state structure information memory space is allocated by the IOS. Unassembled packets are those arriving before the initial packet for a session. Range is 50 through 10,000 entries, with 256 being the default. Because memory is allocated for these state structures, the larger the number, the more memory is reserved, possibly causing memory resources to be exhausted. |
timeout seconds (fragmentation) |
The number of seconds a packet state structure remains active. When the timeout value expires, the router drops the unassembled packet, freeing that structure for use by another packet. The default timeout value is one second. If timeout is set to more than one second, it’s automatically adjusted by the IOS if the number of “free” state structures dips below certain thresholds. If the number of free states is less than 32, the timeout is divided by 2. If the number of free states is less than 16, the timeout is set to one second. |
Even if the system is under heavy attack from fragmented packets, legitimate fragmented traffic, if any, will still get some fraction of the firewall’s fragment state resources and, more important, regular unfragmented traffic can pass through the firewall unimpeded.
The following example adds fragment checking to that software inspection set. The firewall will allocate 100 state structures, meaning 100 initial fragments for 100 different packets sent through the router can be stored before new ones must be discarded. The timeout value for dropping unassembled packets is set to four seconds.
Rtr1(config)#ip inspect name letusin fragment max 100 timeout 4
SMTP inspection searches SMTP commands for illegal commands. Packets with illegal commands are dropped, and the SMTP session will hang and eventually time out. An illegal command is any command except for the following legal commands: DATA, EXPN, HELO, HELP, MAIL, NOOP, QUIT, RCPT, RSET, SAML, SEND, SOML, and VRFY.
Use the no form of the command to remove fragment inspection from the inspection set. The syntax is
Rtr1(config)#ip inspect name inspection-name smtp [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Rtr1(config)#no ip inspect name inspection-name smtp
The following example adds SMTP inspection with default audit-trail and alert setting.
Rtr1(config)#ip inspect name letusin smtp
It’s time to apply the inspection set to a router interface. If the interface connects to the external network, apply the inspection rules to outbound traffic. If the interface connects to the internal network, apply the inspection rules to inbound traffic. By applying the rules to outbound traffic, then returning inbound packets will be permitted if they belong to a valid connection with existing state information. This connection state must be initiated with an outbound packet.
Normally, you apply only one inspection rule per interface. The only exception is if you want to enable CBAC in two directions between two departments or partner networks. To configure CBAC in both directions on a single firewall interface, apply two rules, one for each direction.
Use the interface configuration ip inspect command to apply a set of inspection rules to an interface. Use the no form of the command to remove the set of rules from the interface. The syntax is
Rtr1(config-if)#ip inspect inspection-name {in | out} Rtr1(config-if)#no ip inspect inspection-name {in | out}
in |
Applies the inspection rules to inbound traffic (relative to the router) |
out |
Applies the inspection rules to outbound traffic (relative to the router) |
This command was introduced in IOS 11.2.
This example applies a set of inspection rules named letusin to an external interface’s outbound traffic. The inspection set is the one created in the example and isn’t repeated here. Inbound IP traffic