-
Cisco IOS Security Configuration Guide, Release 12.1
-
About the Cisco IOS Software Documentation
-
Using Cisco IOS Software
-
Security Overview
- Part 1: Authentication, Authorization, and Accounting (AAA)
- Part 2: Security Server Protocols
-
Part 3: Traffic Filtering and Firewalls
-
Access Control Lists: Overview and Guidelines
-
Cisco IOS Firewall Overview
-
Configuring Lock-and-Key Security (Dynamic Access Lists)
-
Configuring IP Session Filtering (Reflexive Access Lists)
-
Configuring TCP Intercept (Preventing Denial-of-Service Attacks)
-
Configuring Context-Based Access Control
-
Configuring Cisco IOS Firewall Intrusion Detection System
-
Configuring Authentication Proxy
-
Configuring Port to Application Mapping
-
-
Index
-
Table Of Contents
Configuring Context-Based Access Control
When and Where to Configure CBAC
RTSP and H.323 Protocol Support for Multimedia Applications
Picking an Interface: Internal or External
Configuring IP Access Lists at the Interface
Configuring Global Timeouts and Thresholds
Configuring Application-Layer Protocol Inspection
Configuring Generic TCP and UDP Inspection
Applying the Inspection Rule to an Interface
Configuring Logging and Audit Trail
Other Guidelines for Configuring a Firewall
RTSP with TCP Only (Interleaved Mode)
Monitoring and Maintaining CBAC
Debugging Context-Based Access Control
Transport Level Debug Commands
Application Protocol Debug Commands
Interpreting Syslog and Console Messages Generated by CBAC
Denial-of-Service Attack Detection Error Messages
SMTP Attack Detection Error Messages
Ethernet Interface Configuration Example
ATM Interface Configuration Example
Remote Office to ISP Configuration Example
Remote Office to Branch Office Configuration Example
Two-Interface Branch Office Configuration Example
Multiple-Interface Branch Office Configuration Example
Configuring Context-Based Access Control
This chapter describes how to configure Context-based Access Control (CBAC). CBAC provides advanced traffic filtering functionality and can be used as an integral part of your network's firewall. For more information regarding firewalls, refer to the chapter "Cisco IOS Firewall Overview."
For a complete description of the CBAC commands used in this chapter, refer to the "Context-Based Access Control Commands" chapter in the Cisco IOS Security Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
In This Chapter
This chapter has the following sections:
•
Monitoring and Maintaining CBAC
CBAC Overview
This section describes CBAC features and functions:
•
•
What CBAC Does
CBAC works to provide network protection on multiple levels using the following functions:
Traffic Filtering
CBAC intelligently filters TCP and UDP packets based on application-layer protocol session information. You can configure CBAC to permit specified TCP and UDP traffic through a firewall only when the connection is initiated from within the network you want to protect. CBAC can inspect traffic for sessions that originate from either side of the firewall, and CBAC can be used for intranet, extranet, and Internet perimeters of your network.
Without CBAC, traffic filtering is limited to access list implementations that examine packets at the network layer, or at most, the transport layer. However, CBAC examines not only network layer and transport layer information but also examines the application-layer protocol information (such as FTP connection information) to learn about the state of the session. This allows support of protocols that involve multiple channels created as a result of negotiations in the control channel. Most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) involve multiple channels.
Using CBAC, Java blocking can be configured to filter HTTP traffic based on the server address or to completely deny access to Java applets that are not embedded in an archived or compressed file. With Java, you must protect against the risk of users inadvertently downloading destructive applets into your network. To protect against this risk, you could require all users to disable Java in their browser. If this is not an acceptable solution, you can create a CBAC inspection rule to filter Java applets at the firewall, which allows users to download only applets residing within the firewall and trusted applets from outside the firewall. For extensive content filtering of Java, Active-X, or virus scanning, you might want to consider purchasing a dedicated content filtering product.
Traffic Inspection
CBAC inspects traffic that travels through the firewall to discover and manage state information for TCP and UDP sessions. This state information is used to create temporary openings in the firewall's access lists to allow return traffic and additional data connections for permissible sessions.
Inspecting packets at the application layer, and maintaining TCP and UDP session information, provides CBAC 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.
CBAC helps to protect against DoS attacks in other ways. CBAC inspects packet sequence numbers in TCP connections to see if they are within expected ranges—CBAC drops any suspicious packets. You can also configure CBAC to drop half-open connections, which require firewall processing and memory resources to maintain. Additionally, CBAC can detect unusually high rates of new connections and issue alert messages.
CBAC can 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.
Alerts and Audit Trails
CBAC also generates real-time alerts and audit trails. Enhanced audit trail features use SYSLOG to track all network transactions; recording time stamps, source host, destination host, ports used, and the total number of transmitted bytes, for advanced, session-based reporting. Real-time alerts send SYSLOG error messages to central management consoles upon detecting suspicious activity. Using CBAC inspection rules, you can configure alerts and audit trail information on a per-application protocol basis. For example, if you want to generate audit trail information for HTTP traffic, you can specify that in the CBAC rule covering HTTP inspection.
Intrusion Detection
CBAC provides a limited amount of intrusion detection to protect against specific SMTP attacks. With intrusion detection, SYSLOG messages are reviewed and monitored for specific "attack signatures." Certain types of network attacks have specific characteristics, or signatures. When CBAC detects an attacks, it resets the offending connections and sends SYSLOG information to the SYSLOG server. Refer to "Interpreting Syslog and Console Messages Generated by CBAC" for a list of supported signatures.
In addition to the limited intrusion detection offered by CBAC, the Cisco IOS Firewall feature set offers intrusion detection technology for mid-range and high-end router platforms using the Cisco IOS Firewall Intrusion Detection System (IDS). It is ideal for any network perimeter, and especially for locations in which a router is being deployed and additional security between network segments is required. It also can protect intranet and extranet connections where additional security is mandated, and branch-office sites connecting to the corporate office or Internet.
The Cisco IOS Firewall IDS identifies 59 of the most common attacks using signatures to detect patterns of misuse in network traffic. The intrusion-detection signatures available in the new release of the Cisco IOS Firewall feature set were chosen from a broad cross-section of intrusion-detection signatures. The signatures represent severe breaches of security and the most common network attacks and information-gathering scans.
For more information about Cisco IOS Firewall IDS, refer to the chapter "Configuring Cisco IOS Firewall Intrusion Detection."
What CBAC Does Not Do
CBAC does not provide intelligent filtering for all protocols; it only works for the protocols that you specify. If you do not specify a certain protocol for CBAC, the existing access lists will determine how that protocol is filtered. No temporary openings will be created for protocols not specified for CBAC inspection.
CBAC does not protect against attacks originating from within the protected network unless that traffic travels through a router that has the Cisco IOS Firewall feature set deployed on it. CBAC only detects and protects against attacks that travel through the firewall. This is a scenario in which you might want to deploy CBAC on an intranet-based router.
CBAC protects against certain types of attacks, but not every type of attack. CBAC should not be considered a perfect, impenetrable defense. Determined, skilled attackers might be able to launch effective attacks. While there is no such thing as a perfect defense, CBAC detects and prevents most of the popular attacks on your network.
How CBAC Works
You should understand the material in this section before you configure CBAC. If you do not understand how CBAC works, you might inadvertently introduce security risks by configuring CBAC inappropriately. This section contains the following sections:
How CBAC Works—Overview
CBAC creates temporary openings in access lists at firewall interfaces. These openings are created when specified 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 CBAC when exiting through the firewall.
Throughout this chapter, the terms "inbound" and "outbound" are used to describe the direction of traffic relative to the router interface on which CBAC is applied. For example, if a CBAC rule is applied inbound on interface E0, then packets entering interface E0 from the network will be inspected. If a CBAC rule is applied outbound on interface E0, then packets leaving interface E0 to the network will be inspected. This is similar to the way ACLs work.
For example, consider a CBAC inspection rule named hqusers, and suppose that rule is applied inbound at interface E0:
router (config-if)# ip inspect hqusers inThis command causes CBAC to inspect the packets coming into this interface from the network. If a packet is attempting to initiate a session, CBAC will then determine if this protocol is allowed, create a CBAC session, add the appropriate ACLs to allow return traffic and do any needed content inspection on any future packets for this session.
The terms "input" and "output" are used to describe the interfaces at which network traffic enters or exits the firewall router. A packet enters the firewall router via the input interface, is inspected by the firewall software and then exits the router via the output interface.
In Figure 11, the inbound access lists at S0 and S1 are configured to block Telnet traffic, and there is no outbound access list configured at E0. When the connection request for User1's Telnet session passes through the firewall, CBAC creates a temporary opening in the inbound access list at S0 to permit returning Telnet traffic for User1's Telnet session. (If the same access list is applied to both S0 and S1, the same opening would appear at both interfaces.) If necessary, CBAC would also have created a similar opening in an outbound access list at E0 to permit return traffic.
Figure 11 CBAC Opens Temporary Holes in Firewall Access Lists
How CBAC Works—Details
This section describes how CBAC inspects packets and maintains state information about sessions to provide intelligent filtering.
Packets Are Inspected
With CBAC, you specify which protocols you want to be inspected, and you specify an interface and interface direction (in or out) where inspection originates. Only specified protocols will be inspected by CBAC.
Packets entering the firewall are inspected by CBAC only if they first pass the inbound access list at the input interface and outbound access list at the output interface. If a packet is denied by the access list, the packet is simply dropped and not inspected by CBAC.
CBAC inspection tracks sequence numbers in all TCP packets, and drops those packets with sequence numbers that are not within expected ranges.
CBAC inspection recognizes application-specific commands (such as illegal SMTP commands) in the control channel, and detects and prevents certain application-level attacks.
When CBAC suspects an attack, the DoS feature can take several actions:
•
•
•
CBAC uses timeout and threshold values to manage session state information, helping to determine when to drop sessions that do not become fully established. Setting timeout values for network sessions helps prevent DoS attacks by freeing up system resources, dropping sessions after a specified amount of time. Setting threshold values for network sessions helps prevent DoS attacks by controlling the number of half-open sessions, which limits the amount of system resources applied to half-open sessions. When a session is dropped, CBAC sends a reset message to the devices at both end points (source and destination) of the session. When the system under DoS attack receives a reset command, it releases, or frees up, processes and resources related to that incomplete session.
CBAC provides three thresholds against DoS attacks:
•
•
•
If a threshold is exceeded, CBAC has two options:
•
•
DoS detection and prevention requires that you create a CBAC inspection rule and apply that rule on an interface. The inspection rule must include the protocols that you want to monitor against DoS attacks. For example, if you have TCP inspection enabled on the inspection rule, then CBAC can track all TCP connections to watch for DoS attacks. If the inspection rule includes FTP protocol inspection but not TCP inspection, CBAC tracks only FTP connections for DoS attacks.
For detailed information about setting timeout and threshold values in CBAC to detect and prevent DoS attacks, refer in the "Configuring Global Timeouts and Thresholds" section.
A State Table Maintains Session State Information
Whenever a packet is inspected, a state table is updated to include information about the state of the session.
Return traffic will only be permitted back through the firewall if the state table contains information indicating that the packet belongs to a permissible session. CBAC controls the traffic that belongs to a valid session. When return traffic is inspected, the state table information is updated as necessary.
UDP "Sessions" Are Approximated
With UDP—a connectionless service—there are no actual sessions, 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, same source/destination addresses and port numbers) and if the packet was detected soon after another similar UDP packet. "Soon" means within the configurable UDP idle timeout period.
Access List Entries Are Dynamically Created and Deleted to Permit Return Traffic and Additional Data Connections
CBAC dynamically creates and deletes access list entries at the firewall interfaces, according to the information maintained in the state tables. These access list entries are applied to the interfaces to examine traffic flowing back into the internal network. These entries create temporary openings in the firewall to permit only traffic that is part of a permissible session.
The temporary access list entries are never saved to NVRAM.
When and Where to Configure CBAC
Configure CBAC at firewalls protecting internal networks. Such firewalls should be Cisco routers with the Cisco IOS Firewall feature set configured as described previously in the section "Cisco Secure Integrated Software."
Use CBAC when the firewall will be passing traffic such as:
•
•
•
Use CBAC for these applications if you want the application's traffic to be permitted through the firewall only when the traffic session is initiated from a particular side of the firewall (usually from the protected internal network).
In many cases, you will configure CBAC 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 CBAC in two directions at one or more interfaces. CBAC is configured 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 firewall is situated between two partner companies' networks, you might wish to restrict traffic in one direction for certain applications, and restrict traffic in the opposite direction for other applications.
The CBAC Process
This section describes a sample sequence of events that occurs when CBAC is configured at an external interface that connects to an external network such as the Internet.
In this example, a TCP packet exits the internal network through the firewall's external interface. The TCP packet is the first packet of a Telnet session, and TCP is configured for CBAC inspection.
1.
2.
3.
(If the packet's application—Telnet—was not configured for CBAC inspection, the packet would simply be forwarded out the interface at this point without being inspected by CBAC. See the section "Define an Inspection Rule" for configuring CBAC inspection information.)
4.
5.
6.
7.
8.
9.
In the sample process just described, the firewall access lists are configured as follows:
•
•
If the inbound access list had been configured to permit all traffic, CBAC would be creating pointless openings in the firewall for packets that would be permitted anyway.
Supported Protocols
This section provides a list of CBAC supported protocols and includes a more detailed look at support for multimedia applications, specifically RTSP and H.323.
CBAC Supported Protocols
You can configure CBAC to inspect the following types of sessions:
•
•
You can also configure CBAC to specifically inspect certain application-layer protocols. The following application-layer protocols can all be configured for CBAC:
•
•
•
•
•
•
•
•
•
•
Note
To determine whether a mail-server is doing SMTP or ESMTP, contact your mail-server software vendor, or telnet to the mail-server port 25 and observe the banner to see if it reports SMTP or ESMTP.•
•
•
•
When a protocol is configured for CBAC, that protocol traffic is inspected, state information is maintained, and in general, packets are allowed back through the firewall only if they belong to a permissible session.
RTSP and H.323 Protocol Support for Multimedia Applications
CBAC supports a number of protocols for multimedia applications that require delivery of data with real-time properties such as audio and video conferencing. This support includes the following g multimedia application protocols:
•
•
RTSP and H.323 V2 inspection allows clients on a protected network to receive data associated with a multimedia session from a server on an unprotected network.
RTSP Support
RTSP is the IETF standards-based protocol (RFC 2326) for control over the delivery of data with real-time properties such as audio and video streams. It is useful for large-scale broadcasts and audio or video on demand streaming, and is supported by a variety of vendor products of streaming audio and video multimedia, including Cisco IP/TV, RealNetworks RealAudio G2 Player, and Apple QuickTime 4 software.
RFC 2326 allows RTSP to run over either UDP or TCP, though CBAC currently supports only TCP-based RTSP. RTSP establishes a TCP-based control connection, or channel, between the multimedia client and server. RTSP uses this channel to control commands such as "play" and "pause" between the client and server. These control commands and responses are text-based and are similar to HTTP.
RTSP typically relies on a UDP-based data transport protocol such as standard Real-Time Transport Protocol (RTP) to open separate channels for data and for RTP Control Protocol (RTCP) messages. RTP and RTCP channels occur in pairs, with RTP being an even numbered port and RTCP being the next consecutive port. Understanding the relationship of RTP and RTCP is important for verifying session information using CBAC show commands.
The RTSP client uses TCP port 554 or 8554 to open a multimedia connection with a server. The data channel or data control channel (using RTCP) between the client and the server is dynamically negotiated between the client and the server using any of the high UDP ports (1024 to 65536).
CBAC uses this port information along with connection information from the client to create dynamic access control list (ACL) entries in the firewall. As TCP or UDP connections are terminated, CBAC removes these dynamic entries from the appropriate ACLs.
CBAC support for RTSP includes the following data transport modes:
•
RTP is an IETF standard (RFC 1889) supporting delivery of real-time data such as audio and video. RTP uses the RTP Control Protocol (RTCP) for managing the delivery of the multimedia data stream. This is the normal mode of operation for Cisco IP/TV and Apple QuickTime 4 software.
•
RDT is a proprietary protocol developed by RealNetworks for data transport. This mode uses RTSP for communication control and uses RDT for the data connection and retransmission of lost packets. This is the normal mode of operation for the RealServer G2 from RealNetworks.
•
In this mode, RTSP uses the control channel to tunnel RTP or RDT traffic.
•
SMIL is a layout language that enables the creation of multimedia presentations consisting of multiple elements of music, voice, images, text, video and graphics. This involves multiple RTSP control and data streams between the player and the servers. This mode is available only using RTSP and RDT. SMIL is a proposed specification of the World Wide Web Consortium (W3C). The RealNetworks RealServer and RealServer G2 provide support for SMIL—Cisco IP/TV and Apple QuickTime 4 do not.
H.323 Support
CBAC support for H.323 inspection includes H.323 Version 2 and H.323 Version 1. H.323 V2 provides additional options over H.323 V1, including a "fast start" option. The fast start option minimizes the delay between the time that a user initiates a connection and the time that the user gets the data (voice, video). H.323 V2 inspection is backward compatible with H.323 V1.
With H.323 V1, after a TCP connection is established between the client and server (H.225 Channel), a separate channel for media control (H.245 Channel) is opened through which multimedia channels for audit and video are further negotiated.
The H.323 V2 client opens a connection to server which is listening on port 1720. The data channel between the client and the server is dynamically negotiated using any of the high UDP ports (1024 to 65536).
CBAC uses this port information along with connection information from the client to create dynamic access control list (ACL) entries in the firewall. As TCP or UDP connections are terminated, CBAC removes these dynamic entries from the appropriate ACLs.
Restrictions
CBAC has the following restrictions:
•
•
•
•
•
You can use CBAC together with all the other firewall features mentioned previously in the "Cisco Secure Integrated Software Firewall Overview" chapter.
CBAC works with fast switching and process switching.
This section also discusses restrictions concerning:
FTP Traffic and CBAC
•
•
•
IPSec and CBAC Compatibility
When CBAC and IPSec are enabled on the same router, and the firewall router is an endpoint for IPSec for the particular flow, then IPSec is compatible with CBAC (that is, CBAC can do its normal inspection processing on the flow).
If the router is not an IPSec endpoint, but the packet is an IPSec packet, then CBAC will not inspect the packets because the protocol number in the IP header of the IPSec packet is not TCP or UDP. CBAC only inspects UDP and TCP packets.
Memory and Performance Impact
CBAC uses less than approximately 600 bytes of memory per connection. Because of the memory usage, you should use CBAC only when you need to. There is also a slight amount of additional processing that occurs whenever packets are inspected.
Sometimes CBAC must evaluate long access lists, which might have presented a negative impact to performance. However, this impact is avoided, because CBAC evaluates access lists using an accelerated method (CBAC hashes access lists and evaluates the hash).
CBAC Configuration Task List
To configure CBAC, perform the tasks described in the following sections. The tasks in the first seven sections are required; the task of verifying the CBAC configuration is optional.
•
•
•
•
•
•
•
•
Following CBAC configuration, you can monitor and maintain CBAC using the information in this section.
Note
Note
For CBAC configuration examples, refer to the "CBAC Configuration Examples" section at the end of this chapter.
Picking an Interface: Internal or External
You must decide whether to configure CBAC on an internal or external interface of your firewall.
"Internal" refers to the side where sessions must originate for their traffic to be permitted through the firewall. "External" refers to the side where sessions cannot originate (sessions originating from the external side will be blocked).
If you will be configuring CBAC in two directions, you should configure CBAC in one direction first, using the appropriate "internal" and "external" interface designations. When you configure CBAC in the other direction, the interface designations will be swapped. (CBAC can be configured in two directions at one or more interfaces. Configure CBAC in two directions when the networks on both sides of the firewall require protection, such as with extranet or intranet configurations, and for protection against DoS attacks.)
The firewall is most commonly used with one of two basic network topologies. Determining which of these topologies is most like your own can help you decide whether to configure CBAC on an internal interface or on an external interface.
The first topology is shown in Figure 12. In this simple topology, CBAC is configured for the external interface Serial 1. This prevents specified protocol traffic from entering the firewall and the internal network, unless the traffic is part of a session initiated from within the internal network.
Figure 12 Simple Topology—CBAC Configured at the External Interface
The second topology is shown in Figure 13. In this topology, CBAC is configured for the internal interface Ethernet 0. This allows external traffic to access the services in the Demilitarized Zone (DMZ), such as DNS services, but prevents specified protocol traffic from entering your internal network—unless the traffic is part of a session initiated from within the internal network.
Figure 13 DMZ Topology—CBAC Configured at the Internal Interface
Using these two sample topologies, decide whether to configure CBAC on an internal or external interface.
To view various firewall configuration scenarios, see the "CBAC Configuration Examples" section at the end of this chapter.
Configuring IP Access Lists at the Interface
For CBAC to work properly, you need to make sure that you have IP access lists configured appropriately at the interface.
Follow these three general rules when evaluating your IP access lists at the firewall:
•
If you try to configure access lists without a good understanding of how access lists work, you might inadvertently introduce security risks to the firewall and to the protected network. You should be sure you understand what access lists do before you configure your firewall. For more information about access control lists, refer to the "Access Control Lists: Overview and Guidelines" chapter.
A basic initial configuration allows all network traffic to flow from the protected networks to the unprotected networks, while blocking network traffic from any unprotected networks.
•
All access lists that evaluate traffic leaving the protected network should permit traffic that will be inspected by CBAC. For example, if Telnet will be inspected by CBAC, then Telnet traffic should be permitted on all access lists that apply to traffic leaving the network.
•
For temporary openings to be created in an access list, the access list must be an extended access list. So wherever you have access lists that will be applied to returning traffic, you must use extended access lists. The access lists should deny CBAC return traffic because CBAC will open up temporary holes in the access lists. (You want traffic to be normally blocked when it enters your network.)
Note
This section contains the following sections:
Basic Configuration
The first time you configure the Cisco Secure Integrated Software, it is helpful to start with a basic access list configuration that makes the operation of the firewall easy to understand without compromising security. The basic configuration allows all network traffic from the protected networks access to the unprotected networks, while blocking all network traffic (with some exceptions) from the unprotected networks to the protected networks.
Any firewall configuration depends on your site security policy. If the basic configuration does not meet your initial site security requirements, configure the firewall to meet your policy. If you are unfamiliar with that policy or need help with the configuration, contact your network administration group for assistance. For additional guidelines on configuring a firewall, refer to the "Other Guidelines for Configuring a Firewall" section in this chapter.
Use the following guidelines for configuring the initial firewall access lists:
•
This helps to simplify firewall management by reducing the number of access lists applied at the interfaces. Of course this assumes a high level of trust for the users on the protected networks, and it assumes there are no malicious users on the protected networks who might launch attacks from the "inside." You can fine tune network access for users on the protected networks as you gain experience with access list configuration and the operation of the firewall.
•
While an access list that denies all IP traffic not part of a connection inspected by CBAC seems most secure, it is not practical for normal operation of the router. The router expects to see ICMP traffic from other routers in the network. Additionally, ICMP traffic is not inspected by CBAC, meaning specific entries are needed in the access list to permit return traffic for ICMP commands. For example, a user on a protected network uses the ping command to get the status of a host on an unprotected network; without entries in the access list that permit echo reply messages, the user on the protected network gets no response to the ping command.
Include access list entries to permit the following ICMP messages:
•
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.
•
This entry helps to prevent broadcast attacks.
•
Although this is the default setting, this final deny statement is not shown by default in an access list. Optionally, you can add an entry to the access list denying IP traffic with any source or destination address with no undesired effects.
For complete information about how to configure IP access lists, refer to the "Configuring IP Services" chapter of the Cisco IOS IP and IP Routing Configuration Guide.
For tips on applying access lists at an external or internal interface, review the sections "External Interface" and "Internal Interface" in this chapter.
External Interface
Here are some tips for your access lists when you will be configuring CBAC on an external interface:
•
•
•
Internal Interface
Here are some tips for your access lists when you will be configuring CBAC on an internal interface:
•
•
•
Configuring Global Timeouts and Thresholds
CBAC uses timeouts and thresholds to determine how long to manage state information for a session, and to determine when to drop sessions that do not become fully established. These timeouts and thresholds apply globally to all sessions.
You can use the default timeout and threshold values, or you can change to values more suitable to your security requirements. You should make any changes to the timeout and threshold values before you continue configuring CBAC.
Note
All the available CBAC timeouts and thresholds are listed in Table 17, along with the corresponding command and default value. To change a global timeout or threshold listed in the "Timeout of Threshold Value to Change" column, use the global configuration command in the "Command" column:
Table 17 Timeout and Threshold Values
The length of time the software waits for a TCP session to reach the established state before dropping the session.
ip inspect tcp synwait-time seconds
30 seconds
The length of time a TCP session will still be managed after the firewall detects a FIN-exchange.
ip inspect tcp finwait-time seconds
5 seconds
The length of time a TCP session will still be managed after no activity (the TCP idle timeout).1
ip inspect tcp idle-time seconds
3600 seconds (1 hour)
The length of time a UDP session will still be managed after no activity (the UDP idle timeout).1
ip inspect udp idle-time seconds
30 seconds
The length of time a DNS name lookup session will still be managed after no activity.
ip inspect dns-timeout seconds
5 seconds
The number of existing half-open sessions that will cause the software to start deleting half-open sessions.2
ip inspect max-incomplete high number
500 existing half-open sessions
The number of existing half-open sessions that will cause the software to stop deleting half-open sessions.2
ip inspect max-incomplete low number
400 existing half-open sessions
The rate of new sessions that will cause the software to start deleting half-open sessions.2
ip inspect one-minute high number
500 half-open sessions per minute
The rate of new sessions that will cause the software to stop deleting half-open sessions.2
ip inspect one-minute low number
400 half-open sessions per minute
The number of existing half-open TCP sessions with the same destination host address that will cause the software to start dropping half-open sessions to the same destination host address.3
ip inspect tcp max-incomplete host number block-time minutes
50 existing half-open TCP sessions; 0 minutes
1 The global TCP and UDP idle timeouts can be overridden for specified application-layer protocols' sessions as described in the ip inspect name (global configuration) command description, found in the "Context-Based Access Control Commands" chapter.
2 See the following section, "Half-Open Sessions," for more information.
3 Whenever the max-incomplete host threshold is exceeded, the software will drop half-open sessions differently depending on whether the block-time timeout is zero or a positive non-zero number. If the block-time timeout is zero, the software will delete the oldest existing half-open session for the host for every new connection request to the host and will let the SYN packet through. If the block-time timeout is greater than zero, the software will delete all existing half-open sessions for the host, and then block all new connection requests to the host. The software will continue to block all new connection requests until the block-time expires.
To reset any threshold or timeout to the default value, use the no form of the command in Table 17.
Half-Open Sessions
An unusually high number of half-open sessions (either absolute or measured as the arrival rate) could indicate that a denial-of-service attack is occurring. For TCP, "half-open" means that the session has not reached the established state—the TCP three-way handshake has not yet been completed. For UDP, "half-open" means that the firewall has detected no return traffic.
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. Rate measurements are made several times per minute.
When the number of existing half-open sessions rises above a threshold (the max-incomplete high number), the software will delete half-open sessions as required to accommodate new connection requests. The software will continue to delete half-open requests as necessary, until the number of existing half-open sessions drops below another threshold (the max-incomplete low number).
When the rate of new connection attempts rises above a threshold (the one-minute high number), the software will delete half-open sessions as required to accommodate new connection attempts. The software will continue to delete half-open sessions as necessary, until the rate of new connection attempts drops below another threshold (the one-minute low number). The rate thresholds are measured as the number of new session connection attempts detected in the last one-minute sample period.
Defining an Inspection Rule
After you configure global timeouts and thresholds, you must define an inspection rule. This rule specifies what IP traffic (which application-layer protocols) will be inspected by CBAC at an interface.
Normally, you define only one inspection rule. The only exception might occur if you want to enable CBAC in two directions as described earlier in the section "When and Where to Configure CBAC." For CBAC configured in both directions at a single firewall interface, you should configure two rules, one for each direction.
An inspection rule should specify each desired application-layer protocol as well as generic TCP or generic UDP if desired. The inspection rule consists of a series of statements each listing a protocol and specifying the same inspection rule name.
Inspection rules include options for controlling alert and audit trail messages and for checking IP packet fragmentation.
To define an inspection rule, follow the instructions in the following sections:
•
•
Configuring Application-Layer Protocol Inspection
This section provides instructions for configuring CBAC with the following inspection information:
•
•
Note
Configuring Application-Layer Protocols
To configure CBAC inspection for an application-layer protocol, use one or both of the following commands in global configuration mode:
Router(config)# ip inspect name inspection-name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Configures CBAC inspection for an application-layer protocol (except for RPC and Java). Use one of the protocol keywords defined in Table 18.
Repeat this command for each desired protocol. Use the same inspection-name to create a single inspection rule.
Router(config)# ip inspect name inspection-name rpc program-number number [wait-time minutes] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Enables CBAC inspection for the RPC application-layer protocol.
You can specify multiple RPC program numbers by repeating this command for each program number.
Use the same inspection-name to create a single inspection rule.
Refer to the description of the ip inspect name global configuration command in the "Context-Based Access Control Commands" chapter of the Cisco IOS Security Command Reference for more information about how the command works with each application-layer protocol.
To enable CBAC inspection for Java blocking, see the following section, "Configuring Java Blocking."
Table 18 identifies application protocol keywords for the ip inspect name command.
Configuring Java Blocking
Java applet filtering distinguishes between trusted and untrusted applets by relying on a list of external sites that you designate as "friendly." If an applet is from a friendly site, the firewall allows the applet through. If the applet is not from a friendly site, the applet will be blocked. (Alternately, you could permit applets from all external sites except for those you specifically designate as hostile.)
Note
To block all Java applets except for applets from friendly locations, use the following commands in global configuration mode:
Caution
Configuring IP Packet Fragmentation Inspection
CBAC inspection rules can help protect hosts against certain DoS attacks involving fragmented IP packets.
Using fragmentation inspection, the firewall maintains an interfragment state (structure) for IP traffic. Non-initial fragments are discarded unless the corresponding initial fragment was permitted to pass through the firewall. Non-initial fragments received before the corresponding initial fragments are discarded.
Note
Because routers running Cisco IOS software are used in a large variety of networks, and because the CBAC feature is often used to isolate parts of internal networks from one another, the fragmentation inspection feature is disabled by default. Fragmentation detection must be explicitly enabled for an inspection rule using the ip inspect name command. Unfragmented traffic is never discarded because it lacks a fragment state. Even when the system is under heavy attack with fragmented packets, legitimate fragmented traffic, if any, gets some fraction of the firewall's fragment state resources, and legitimate, unfragmented traffic can flow through the firewall unimpeded.
Configuring Generic TCP and UDP Inspection
You can configure TCP and UDP inspection to permit TCP and UDP packets to enter the internal network through the firewall, even if the application-layer protocol is not configured to be inspected. However, 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.
Any application-layer protocol that is inspected will take precedence over the TCP or UDP packet inspection. For example, if inspection is configured for FTP, all control channel information will be recorded in the state table, and all FTP traffic will be permitted back through the firewall if the control channel information is valid for the state of the FTP session. The fact that TCP inspection is configured is irrelevant to the FTP state information.
With TCP and UDP inspection, packets entering the network must exactly match the corresponding packet that previously exited the network. The entering packets must have the same source/destination addresses and source/destination port numbers as the exiting packet (but reversed); otherwise, the entering packets will be blocked at the interface. Also, all TCP packets with a sequence number outside of the window are dropped.
With UDP inspection configured, replies will only be permitted back in through the firewall if they are received within a configurable time after the last request was sent out. (This time is configured with the ip inspect udp idle-time command.)
To configure CBAC inspection for TCP or UDP packets, use one or both of the following commands in global configuration mode:
Applying the Inspection Rule to an Interface
After you define an inspection rule, you apply this rule to an interface.
Normally, you apply only one inspection rule to one interface. The only exception might occur if you want to enable CBAC in two directions as described earlier in the section "When and Where to Configure CBAC." For CBAC configured in both directions at a single firewall interface, you should apply two rules, one for each direction.
If you are configuring CBAC on an external interface, apply the rule to outbound traffic.
If you are configuring CBAC on an internal interface, apply the rule to inbound traffic.
To apply an inspection rule to an interface, use the following command in interface configuration mode:
Router(config-if)# ip inspect inspection-name
{in | out}Applies an inspection rule to an interface.
Configuring Logging and Audit Trail
Turn on logging and audit trail to provide a record of network access through the firewall, including illegitimate access attempts, and inbound and outbound services. To configure logging and audit trail functions, enter the following commands in global configuration mode:
For information on how to interpret the syslog and audit trail messages, refer to the "Interpreting Syslog and Console Messages Generated by CBAC" section.
To configure audit trail functions on a per-application basis, refer to the "Defining an Inspection Rule" section for more information.
For complete information about how to configure logging, refer to the "Troubleshooting the Router" chapter of the Cisco IOS Configuration Fundamentals Configuration Guide.
Other Guidelines for Configuring a Firewall
As with all networking devices, you should always protect access into the firewall by configuring passwords as described in the "Configuring Passwords and Privileges" chapter. You should also consider configuring user authentication, authorization, and accounting as described in the "Authentication, Authorization, and Accounting (AAA)" part of this guide.
You should also consider the following recommendations:
•
•
•
