Understanding Inspection Rules
Inspection rules configure Context-Based Access Control (CBAC) inspection commands. CBAC inspects traffic that travels through the device to discover and manage state information for TCP and UDP sessions. The device uses this state information to create temporary openings to allow return traffic and additional data connections for permissible sessions.
CBAC creates temporary openings in access lists at firewall interfaces. These openings are created when inspected traffic exits your internal network through the firewall. The openings allow returning traffic (that would normally be blocked) and additional data channels to enter your internal network back through the firewall. The traffic is allowed back through the firewall only if it is part of the same session as the original traffic that triggered inspection when exiting through the firewall.
Inspection rules are applied after your access rules, so any traffic that you deny in the access rule is not inspected. The traffic must be allowed by the access rules at both the input and output interfaces to be inspected. Whereas access rules allow you to control connections at layer 3 (network, IP) or 4 (transport, TCP or UDP protocol), you can use inspection rules to control traffic using application-layer protocol session information.
For all protocols, when you inspect the protocol, the device provides the following functions:
Automatically opens a return path for the traffic (reversing the source and destination addresses), so that you do not need to create an access rule to allow the return traffic. Each connection is considered a session, and the device maintains session state information and allows return traffic only for valid sessions. Protocols that use TCP contain explicit session information, whereas for UDP applications, the device models the equivalent of a session based on the source and destination addresses and the closeness in time of a sequence of UDP packets.
These temporary access lists are created dynamically and are removed at the end of a session.
Tracks sequence numbers in all TCP packets and drops those packets with sequence numbers that are not within expected ranges.
Uses timeout and threshold values to manage session state information, helping to determine when to drop sessions that do not become fully established. When a session is dropped, or reset, the device informs both the source and destination of the session to reset the connection, freeing up resources and helping to mitigate potential Denial of Service (DoS) attacks.
The following topics provide more information about inspection:
Choosing the Interfaces for Inspection Rules
Configure inspection on devices that protect internal networks. Use it with TCP, UDP, or more specific protocols. Inspect these applications if you want the application’s traffic to be permitted through the device only when the traffic session is initiated from a particular side of the device (usually from the protected internal network).
For IOS devices, you need to configure inspection explicitly, and you can identify the direction of traffic to be inspected. For ASA, PIX, and FWSM devices, you cannot identify the direction, and you need to configure inspection only if you do not want the inspection defaults. In the remaining discussion, statements concerning direction apply only to IOS devices. For ASA, PIX, and FWSM, simply configure inspection on the identified interface.
In many cases, you will configure inspection in one direction only at a single interface, which causes traffic to be permitted back into the internal network only if the traffic is part of a permissible (valid, existing) session. This is a typical configuration for protecting your internal networks from traffic that originates on the Internet.
You can also configure inspection in two directions at one or more interfaces. Configure inspection in two directions when the networks on both sides of the firewall should be protected, such as with extranet or intranet configurations, and to protect against DoS attacks. For example, if the device is situated between two partner companies’ networks, you might want to restrict traffic in one direction for certain applications, and restrict traffic in the opposite direction for other applications. If you are protecting a web server in the DMZ zone, you might want to configure deep inspection on HTTP traffic to identify and reset connections that have undesirable characteristics.
You might want to configure your inspection rules on the outbound interfaces of your network, those that connect to the Internet or another uncontrolled network, while allowing unfiltered connections within the trusted network. Thus, your devices use resources for inspection only on sessions that travel over unsecured and therefore potentially dangerous networks.
Selecting Which Protocols To Inspect
You can generically inspect TCP and UDP, which covers all applications that use these protocols. However, you can also inspect more specific protocols. In some cases, inspecting a specific protocol provides better service than generic TCP/UDP inspection. TCP and UDP inspection do not recognize application-specific commands, and therefore might not permit all return packets for an application, particularly if the return packets have a different port number than the previous exiting packet.
Some protocols allow you to configure deep inspection. Deep inspection allows you to configure more specific rules for a traffic stream. For example, you can drop HTTP connections where the content type of the request and response do not match. For information on deep inspection and your configuration options, see Configuring Protocols and Maps for Inspection.
Protocols that negotiate return channels, such as FTP, should be specifically inspected. If you use simple generic TCP inspection of FTP traffic, the negotiated channels are not opened, and the connection will fail. If you want to allow FTP, ensure that you create a specific inspection rule for it.
Multimedia protocols also negotiate return channels and should be specifically inspected. These include H.323, RTSP (Real Time Streaming Protocol), and other application-specific protocols. Some applications also use a generic TCP channel, so you might also need to configure generic TCP inspection. Any generic TCP inspection rule should appear below a more specific inspection rule in the table (that is, any rule that specifies TCP or UDP should appear at the end of the inspection rule table).
Understanding Access Rule Requirements for Inspection Rules
Access rules are applied before inspection rules. Therefore, you must ensure that your access rules do not prohibit traffic that you want inspected. Use the following guidelines:
Permit inspected traffic to leave the network through the firewall.
All access rules that evaluate traffic leaving the protected network should permit traffic that will be inspected. For example, if Telnet will be inspected, then Telnet traffic should be permitted on all access rules that apply to traffic leaving the network.
Deny inspected return traffic entering the network through the firewall.
For temporary openings to be created in an access list, the access list should deny inspected return traffic because the inspection engine will open up temporary holes in the access lists for this traffic. (You want traffic to be normally blocked when it enters your network.)
Permit or deny traffic that cannot be inspected, or that you do not want to inspect, as required by your network.
For example, if you do not want to inspect ICMP traffic, but you want to allow some ICMP traffic, configure your access rules to allow the traffic in both directions. Consider permitting at least these ICMP message types: echo reply (for ping commands), time-exceeded (for trace route), packet-too-big (for path MTU discovery), traceroute (for trace route), and unreachable (to notify that a host cannot be found).
Add an access rule entry denying any network traffic from a source address matching an address on the protected network.
This is known as anti-spoofing protection because it prevents traffic from an unprotected network from assuming the identity of a device on the protected network.
Add an entry denying broadcast messages with a source address of 255.255.255.255.
This entry helps to prevent broadcast attacks.
Using Inspection To Prevent Denial of Service (DoS) Attacks on IOS Devices
From version 4.17, though Cisco Security Manager continues to support PIX, FWSM, and IPS features/functionality, it does not support any enhancements.
Inspecting packets at the application layer, and maintaining TCP and UDP session information, provides a device with the ability to detect and prevent certain types of network attacks such as SYN-flooding. A SYN-flood attack occurs when a network attacker floods a server with a barrage of requests for connection and does not complete the connection. The resulting volume of half-open connections can overwhelm the server, causing it to deny service to valid requests. Network attacks that deny access to a network device are called denial-of-service (DoS) attacks.
Inspection helps to protect against DoS attacks in other ways. Inspection looks at packet sequence numbers in TCP connections to see if they are within expected ranges and drops any suspicious packets. You can also configure inspection to drop half-open connections, which require firewall processing and memory resources to maintain. Additionally, inspection can detect unusually high rates of new connections and issue alert messages.
For IOS devices, you can configure several inspection setting parameters to fine-tune your defenses against SYN flooding and half-open connections. Configure the Configuring Settings for Inspection Rules for IOS Devices.policy. For details about each setting, see
Inspection can also help by protecting against certain DoS attacks involving fragmented IP packets. Even though the firewall prevents an attacker from making actual connections to a given host, the attacker can disrupt services provided by that host. This is done by sending many non-initial IP fragments or by sending complete fragmented packets through a router with an ACL that filters the first fragment of a fragmented packet. These fragments can tie up resources on the target host as it tries to reassemble the incomplete packets. To fine-tune fragment inspection, configure an inspection rule for the fragment protocol and configure the maximum number of fragments you want to allow and a timeout value.