Chapter 5. Cisco IOS Firewall

Security is no longer a straightforward product or technology enabler, but a core system in a network design. The innovative flagship Cisco IOS Software provides an array of security solutions including the flagship IOS Firewall feature set. This set provides integrated firewall and intrusion detection technology for the Cisco IOS Software. The Cisco IOS Firewall feature is a stateful-inspection software component of Cisco IOS Software.

The Cisco IOS Firewall feature set provides a single point of protection at the network perimeter, making security policy enforcement an inherent component of the network.

Cisco IOS Firewall consists of several major subsystems: an advanced firewall engine for stateful-packet inspection (SPI), Context-Based Access Control (CBAC), Zone-Based Policy Firewall (ZFW), Intrusion Prevention Systems (IPS), Authentication Proxy, Port-to-Application Mapping (PAM), Multi-VRF firewall, Transparent firewall, and several others.

This chapter focuses mainly on the SPI and Classic Firewall CBAC, illustrating fundamental concepts and functions of how stateful inspection works and a step-by-step process to configure the Cisco IOS Firewall in the classical CBAC format.

The chapter also highlights some of the Advanced IOS Firewall features introduced in the newer IOS Software versions.

The chapter also covers the new Zone-Based Policy Firewall (ZFW) model, providing an overview of the new zone-based concept and a configuration example that uses the new Cisco Policy Language (CPL) commands.

Router-Based Firewall Solution

The Cisco IOS Firewall feature set provides network security with integrated, inline security solutions. The IOS Firewall feature set is a suite of security services provisioning a single point of protection at the network perimeter. In addition, the IOS Firewall feature is widely available on a range of IOS software-based devices, thereby offering sophisticated security and policy enforcement for network connections.

The Cisco IOS Firewall feature is a stateful-inspection firewall engine with application-level intelligence. This provides dynamic control to permit or deny traffic flow, thereby providing enhanced security. In the simplest form, the principal function of a firewall is to monitor and filter traffic. Cisco routers can be configured with the IOS Firewall feature in one of the following deployment scenarios:

• A firewall router facing the Internet.

• A firewall router to protect the internal network from the external network. An external network can be any network outside the organization (for example, a customer or a partner network).

• A firewall router between groups of networks in the internal network.

• A firewall router that provides secure connections to or from remote or branch offices.

Cisco IOS Software provides an extensive set of security features to design customized firewall solutions to fit an organization’s security policy. A Cisco networking device running Cisco IOS Software can be configured to function as a firewall by using several solutions available in the IOS Firewall feature set.

The Cisco IOS Firewall consists of several major subsystems:

• Cisco IOS Firewall stateful packet inspection (SPI): SPI provides true firewall capabilities to protect networks against unauthorized traffic and to control legitimate business-critical data.

• Context-Based Access Control (CBAC): CBAC (now known as Classic Firewall) is a stateful-inspection firewall engine that provides dynamic traffic filtering functionality.

• Intrusion Prevention System (IOS IPS) (formerly known as IOS IDS): Cisco IOS IPS offers integrated IPS functionality as part of the Cisco IOS Software. From IOS Version 12.3T, Cisco IOS IPS replaces the previous IOS IDS functionality by implementing a large part of classic sensor functionality as part of the IOS-based device. IOS IPS is an inline intrusion detection sensor that scans packets and sessions flowing through the router to identify any of the Cisco IOS IPS signatures that protect the network from internal and external threats.

• Authentication proxy: The authentication proxy feature (also known as Proxy Authentication) allows security policy enforcement on a per-user basis. Earlier, user access and policy enforcement was associated with a user’s IP address or a single global policy applied to an entire user group. With the authentication proxy feature, users can now be authenticated and authorized on a per-user policy with access control customized to an individual level.

• Port-to-Application Mapping (PAM): PAM allows you to customize TCP or User Datagram Protocol (UDP) port numbers for network services or applications to nonstandard ports (for example, HTTP service using TCP port 8080 instead of the default port 80). CBAC inspection leverages this information to examine nonstandard application-layer protocols.

• Network Address Translation (NAT): NAT hides internal IP addresses from networks that are external to the firewall. NAT was designed to provide IP address conservation and for internal IP networks that use the unregistered private address space per RFC 1918. NAT translates these private IP addresses into legal registered addresses as packets traverse through the NAT device. This provides a basic low-level security by effectively hiding the internal network from the outside world.

• Zone-Based Policy Firewall (ZFW): ZFW is a new enhanced security tool available in the Cisco IOS Software-based firewall feature set. ZFW offers a completely revamped configuration syntax that offers network protection that uses intuitive policies and increased granularity to control unauthorized network access.

Several other security solutions are available on Cisco IOS. These include Lock-and-Key, Reflexive access list, TCP Intercept, IPsec, and AAA support. This chapter focuses primarily on the CBAC and ZFW solutions available in the IOS Firewall feature set.

Context-Based Access Control (CBAC)

CBAC is the Cisco IOS Firewall feature set—an advanced firewall engine that provides traffic-filtering functionality and can be used as an integral part of the network. The main features of CBAC include the following:

• CBAC protects internal networks from external intrusion.

• CBAC provides denial of service (DoS) protection.

• CBAC provides a per-application control mechanism across network perimeters.

• CBAC examines the transport layer, network layer, and upper-layer application-protocol information, keeping track of the flows and the state of each session (for example, HTTP, Simple Mail Transfer Protocol (SMTP), and FTP).

• CBAC maintains state information for every connection passing through the firewall in a session table (also called the state table). The connection information from the state table is used to make intelligent decisions about whether packets should be permitted or denied, thereby dynamically creating temporary openings in the firewall.

• CBAC generates real-time event alerts and audit trails. Alerts and audit trail information can be configured on a per-application protocol basis.

• Upon detecting suspicious activity, the real-time event alert feature sends SYSLOG error messages to central management consoles for notification.

• Enhanced audit trail features use SYSLOG to track all network transactions used for advance analysis and reporting.

---

---

CBAC Functions

CBAC provides networkwide protection by using the following functions:

• Traffic filtering

• Traffic inspection

• Alerts and audit trails

Traffic Filtering

CBAC is a software-based firewall feature that offers dynamic traffic filtering capabilities to filter TCP and UDP packets based on upper-layer application protocols such as HTTP, SMTP, and FTP to name a few. For CBAC to function, the network must be divided in two logical segments: “trusted or protected” and “untrusted or unprotected.” The principal of CBAC traffic filtering is to allow any traffic that originates from the trusted network and goes out to the untrusted network through the firewall.

Traffic Inspection

CBAC inspects traffic that traverses through the firewall and manages state information for all the TCP and UDP sessions. This state information is used to create temporary openings through the firewall to allow return traffic and additional data connections for permissible sessions.

With the application-level awareness, CBAC maintains TCP and UDP connections, which provide all the necessary information to perform deep packet inspection in the data payload for any malicious activity. For example, as shown in Figure 5-1, an intruder could craft a malicious, unauthorized, non-SMTP activity packet encapsulated in an SMTP packet destined on TCP port 25. In conventional access list filtering, this packet would be allowed because it would check only the Layer 3 and Layer 4 information in the packet. With CBAC packet inspection, the packet is further examined for known SMTP operations as per RFC standards, and any noncompliance operation (illegal commands) in the payload is blocked.

Figure 5-1. Application-Aware Traffic Inspection

Based on this inspection method, several types of network attacks that use the embedding technique to pass malicious traffic encapsulating in known application protocol packets can be prevented.

Alerts and Audit Trails

In addition to traffic inspection, CBAC can generate real-time event alerts and audit trails for all the session information maintained in the state table. The enhanced audit trail feature uses SYSLOG to track all network transactions, recording information such as source/destination host addresses, ports used, and the total number of transmitted bytes with time stamps. This information can be valuable for advanced session-based reporting, anomaly identification, or the charting of network baselines. For any suspicious activity, CBAC can send real-time event alerts using SYSLOG notification messages to a management console. CBAC inspection rules can be configured for reporting event alerts and audit trail information on a per-application-protocol basis.

How CBAC Works

The following sections highlight the fundamental concepts of how CBAC inspects packets and maintains state information for all the connections, thereby providing intelligent filtering.

Packet Inspection

CBAC performs per-protocol inspection. Each protocol that requires inspection is individually enabled, and an interface and interface direction (in or out) is specified where inspection originates. Only the specified protocols will be inspected by CBAC. All other protocols continue uninterrupted, subject to other router processes—for example, NAT, routing, and ACL.

Packets entering the firewall are subject to inspection 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 without CBAC inspection performed.

For TCP protocol inspection, CBAC keeps track of sequence numbers in all TCP packets. Packets with sequence numbers that are not within the expected ranges are dropped.

Timeout and Threshold Values

CBAC uses several timeout and threshold values to manage session state information. These values help determine when to drop sessions that do not become fully established. This also helps to free up system resources, dropping sessions after a specified amount of idle time. CBAC sends a reset message for all dropped sessions to both sides (source and destination) of the session. The system receiving the reset message releases the incomplete connection from its process, thereby clearing the resource allocation table.

CBAC monitors the thresholds in the following three ways:

• The total number of half-open TCP or UDP sessions

• The number of half-open sessions based on time

• The number of per-host half-open TCP sessions

The Session State Table

CBAC maintains a session state table with connection information, such as the source/destination IP addresses, source/destination port numbers, and the application protocol information. For every incoming packet that CBAC inspects, the state table is updated with all the information. This information is used to punch a dynamic hole in the firewall access list for the return traffic. Return traffic will be permitted back through the firewall only if an entry in the state table indicates that the packet belongs to a permissible session. Example 5-1 shows sample session state table information, and Example 5-2 shows the dynamic ACL entry that corresponds to the information in this state table.

Example 5-1. Connection Information in the State Table

---

Router# show ip inspect session
Established Sessions                                         
 Session 25A4E53 (10.1.1.1:11006)=>(20.1.1.1:23) tcp SIS_OPEN

---

UDP Connections

UDP is a connectionless transport-layer protocol; hence, there is no state information available to track the flow of the connections. CBAC deals with UDP sessions by examining the information in the packet and determining whether the packet is similar to the UDP packet exited earlier. Returning UDP packets are checked within the idle timeout period to ensure that they have the corresponding source/destination IP addresses and port numbers.

Dynamic ACL Entries

As discussed earlier, CBAC uses the connection information from the session table to open dynamic holes in the firewall access list for the returning traffic (that would normally be blocked). CBAC dynamically adds and removes access list entries at the firewall interfaces. These temporary openings are created in accordance with the state table for all inspected traffic that originates from an internal (protected) network outbound toward the unprotected zone through the firewall. The purpose of these access list entries is 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. Example 5-2 shows a dynamic ACL entry (corresponding to Example 5-1) that permits returning Telnet traffic initiated by a host from the internal network.

Example 5-2. Dynamic ACL Entry Corresponding to the State Table

---

Router# show ip access-lists
Extended IP access list 101
    permit tcp host 20.1.1.1 eq telnet host 10.1.1.1 eq 11006 (16 matches)
    permit tcp any host WebServer eq http
    deny ip any any (12 matches)

---

---

---

Embryonic (Half-Open) Sessions

CBAC provides DoS detection and prevention. An excessive number of half-open sessions (either absolute or measured as the arrival rate) could indicate the possible occurrence of a denial-of-service attack. Traffic patterns can be established for a TCP SYN-flood type attack. TCP is a connection-oriented transport protocol that requires completing a three-way handshake mechanism. Incomplete (half-open) connections mean that the session has not completed the TCP three-way handshake; hence, the session is not established. Because UDP is a connectionless protocol, there is no handshake mechanism; incomplete sessions (half-open) in UDP context indicate that the firewall has detected no return traffic.

CBAC monitors the total number of half-open connections and the rate of session establishment attempts for both TCP and UDP half-open connections. CBAC monitors these values several times per minute. Adjusting threshold values for network connections helps prevent DoS attacks by controlling the number of half-open sessions, thereby freeing up system resources occupied by half-open sessions.

Example 5-3 shows a CBAC session table with few half-open (incomplete) TCP connections.

Example 5-3. Sample Half-Open Connections

---

Router# show ip inspect session
Half-open Sessions                                                 
 Session 63938D28 (10.1.1.2:11000)=>(20.1.1.2:23) tcp SIS_OPENING
 Session 63938EB8 (10.1.1.2:11001)=>(20.1.1.2:25) tcp SIS_OPENING
 Session 639C2343 (10.1.1.20:11012)=>(20.0.0.20:23) tcp SIS_OPENING
 Session 63976A22 (10.1.1.20:11013)=>(20.0.0.20:80) tcp SIS_OPENING

---

When the number of half-open connections exceeds the specified threshold (using the ip inspect max-incomplete high or ip inspect one-minute high number), CBAC will delete subsequent half-open sessions as required to accommodate new incoming connections. CBAC continues to delete the half-open connection requests as required until the number of existing half-open sessions drops below another specified threshold (using the ip inspect max-incomplete low or ip inspect one-minute low number). See Table 5-1 for more details on these commands and threshold values.

Table 5-1. Global Timeout and Threshold Values

Per-Host DoS Prevention

CBAC provides a more aggressive TCP-based host-specific DoS prevention. CBAC monitors the total number of half-open connections initiated to the same destination host address. When the number of incomplete (half-open) TCP connections exceeds the configured threshold, CBAC blocks all subsequent connections to the host for the specified block-time, thereby preventing the flood. To configure per-host CBAC monitoring, use the ip inspect tcp max-incomplete host command. Refer to Table 5-1 for more details on this command.

Example 5-4 shows how to change the max-incomplete host to 100 half-open sessions, with block-time timeout to 5 minutes.

Example 5-4. Per-Host CBAC Monitoring for DoS Prevention

---

Router(config)# ip inspect tcp max-incomplete host 100 block-time 5

---

CBAC-Supported Protocols

CBAC can be enabled to inspect all TCP and UDP sessions, regardless of the application-layer protocol. This method is called single-channel, or generic, TCP/UDP inspection. For TCP/UDP generic inspection to work, the return traffic must have the same source/destination IP address and port numbers. It must also be within the sequence number window. If the port number changes, the packet will be dropped.

In addition, CBAC can specifically inspect individual application-layer protocols to maintain the connection information for each session. Application-layer protocol inspection takes precedence over the TCP or UDP protocol inspection. The following application-layer protocols are supported and can be configured for CBAC inspection:

• CU-SeeMe

• FTP

• H.323 (such as NetMeeting)

• HTTP (Java blocking)

• ICMP

• Microsoft NetShow

• RealAudio

• RTSP (Real-Time Streaming Protocol)

• RPC (Sun RPC, not DCE RPC)

• SMTP (Simple Mail Transport Protocol)

• ESMTP (Extended Simple Mail Transport Protocol)

• SQL*Net

• StreamWorks

• TFTP

• UNIX R-commands (such as rlogin, rexec, and rsh)

• VDOLive

Configuring CBAC

To configure CBAC, perform the following steps:

Step 1.   Select an interface: internal or external.

Step 2.   Configure an IP access list.

Step 3.   Define an inspection rule.

Step 4.   Configure global timeouts and thresholds (optional).

Step 5.   Apply the access list and the inspection rule to an interface.

Step 6.   Verify and monitor CBAC.

Step 1—Select an Interface: Internal or External

CBAC can be configured either on an internal or external interface of the firewall.

• Internal refers to the trusted/protected side where sessions must originate for traffic to be permitted through the firewall.

• External refers to the untrusted/unprotected side where sessions cannot originate. Sessions originating from the external side will be blocked.

Figure 5-2. Internal Versus External Interface

Although CBAC is recommended to be configured in one direction per interface, it can be configured in two directions (also known as bidirectional CBAC) at one or more interfaces when the networks on both sides of the firewall require protection, such as with extranet or intranet configurations, and for protection against DoS attacks.

Step 2—Configure an IP Access List

For CBAC to work, an IP access list is configured to create temporary openings through the firewall to allow return traffic. It is important to remember that the access list must be an extended access list.

There is no basic template for configuring the access list. Configuration depends on the security policy of an organization. The access list should be kept simple, starting with a basic initial configuration. Making the access list complex and cluttered could unintentionally introduce security risks by allowing unwanted traffic through the firewall, thereby putting the protected network at risk. It is essential to understand and verify the access list before applying it in a production environment.

Follow these general guidelines to create an access list:

• Explicitly block all network traffic that originates from the unprotected zone and moves to the protected zone, unless required. For example, when hosting a web server in the protected zone, it is explicitly required to permit HTTP (TCP port 80) that originates from the unprotected zone.

Step 3—Define an Inspection Rule

CBAC requires defining an inspection rule to specify which IP traffic (application-layer protocols) will be inspected by the firewall engine.

An inspection rule should specify each desired application-layer protocol as well as the generic TCP or UDP if required. The inspection rule consists of a series of statements, each listing a protocol that specifies the same inspection rule name, as shown in Example 5-5. Inspection rule statements can include other options, such as controlling alert and audit trail messages and checking IP packet fragmentation.

Use the ip inspect name global configuration command to create a CBAC inspection rule set for the required application-layer protocol. Example 5-5 shows how to enable inspection for HTTP, FTP, SMTP, and generic TCP and UDP protocols. Other application protocols (not defined here) can be enabled as required.

Example 5-5. Define CBAC Inspection Rules

---

Router(config)# ip inspect name myfw http
Router(config)# ip inspect name myfw ftp
Router(config)# ip inspect name myfw smtp
Router(config)# ip inspect name myfw tcp
Router(config)# ip inspect name myfw udp

---

Step 4—Configure Global Timeouts and Thresholds

CBAC uses several timeout and threshold values to determine the state of the session and the duration for which it is maintained. At times, connections are continually maintained for abruptly terminated sessions that occupy unnecessary resources. Incomplete sessions, idle (unused) sessions, or abruptly terminated sessions can be cleared using the timeout and threshold values.

The timeout and threshold values can be used either with default values or can be tuned to suit the network requirement. Table 5-1 shows the available CBAC timeout and threshold commands and their default values. Use the commands listed in the table to modify global timeout or threshold values as required.

Step 5—Apply the Access List and the Inspection Rule to an Interface

For CBAC to take effect, the access list and the inspection rules configured earlier need to be applied to the interface.

Deciding where CBAC should be configured (internal or external interface) is subjective. As shown in Figure 5-3, CBAC inspection can be configured on either internal or external interfaces—a decision that depends entirely on the security policy. When making that decision, consider which segment is required to be protected:

• Apply CBAC inspection to the external (outbound) interface when configuring CBAC for outbound traffic.

• Apply CBAC inspection to the internal (inbound) interface when configuring CBAC for inbound traffic.

Figure 5-3. Applying ACL and CBAC Inspection

To apply an inspection rule to an interface, use the ip inspect inspection-name {in | out} command in interface configuration mode.

Step 6—Verifying and Monitoring CBAC

Use the show ip inspect [config | interface] command or the show ip inspect all command to verify CBAC configuration settings. To view the statistics and session information table with all the established and half-open connections for all session flow through the firewall, use the show ip inspect session [detail] command. In addition, use the show ip access lists command to verify the dynamic access list entries populated in the firewall access list, as shown in Example 5-1 and Example 5-2.

Putting It All Together

Figure 5-4 depicts a simple CBAC scenario for protecting a web server in the internal network. CBAC inspection can be applied on internal or external interfaces. Access list 101 shows that HTTP traffic that originates from an external network that is external to the web server is permitted. All other traffic is explicitly denied. Traffic originating from the internal network (protected zone) will pass through. Maintaining session table and a corresponding dynamic ACL entry will be punched in ACL 101 to allow all returning traffic.

Figure 5-4. Putting It All Together

IOS Firewall Advanced Features

Several new enhancements and advanced capabilities have been added in the IOS Firewall feature set in IOS Software 12.3T and 12.4 mainline versions. The following section highlights some of the commonly used advanced features.

HTTP Inspection Engine

The HTTP inspection engine in the IOS Firewall has been enhanced with the introduction of Advanced Application Inspection and Control. For HTTP port 80 web traffic passing through the conventional firewalls, there is a possibility that non-HTTP traffic can be embedded or tunneled in the HTTP traffic (for example, Instant Messaging (IM) or any malicious traffic), thereby bypassing the firewall. Using this embedding technique, malformed packets can be crafted to carry viruses, worms, Trojans, or any other malicious activity. With deep packet inspection, IOS Firewall inspects the data streams to ensure that traffic that is assumed to be HTTP is legitimate web browsing and not IM or illegitimate traffic that is trying to gain unauthorized access through the firewall.

As shown in Figure 5-5, the HTTP Inspection Engine gives IOS Firewall engine more granular control and the intelligence to block non-HTTP traffic by challenging its legitimacy and conformance to standards. The HTTP inspection performs packet inspection to detect whether any applications are being tunneled through port 80.

Figure 5-5. HTTP Inspection Engine with Advanced Application Inspection

Packets not conforming to the standards in HTTP protocol are dropped. A reset message is sent out, and a SYSLOG message is generated accordingly.

This feature was introduced in IOS Version 12.3(14)T.

---

---

E-Mail Inspection Engine

Similar to the SMTP protocol, the ESMTP protocol provides a basic method for exchanging e-mail messages. ESMTP specifies service extensions to the original SMTP protocol for sending e-mail messages that support graphics, audio, and video files, and text in various national languages. Although an ESMTP session is similar to SMTP, there is one difference—the EHLO command. An ESMTP client supporting ESMTP protocol starts a connection by issuing the EHLO command instead of the HELO command used in standard SMTP. (Refer to RFC 1869, “SMTP Service Extensions,” for further details.)

The enhanced SMTP inspection engine adds support for ESMTP, Post Office Protocol 3 (POP3), and Internet Message Access Protocol (IMAP) in addition to the standard SMTP protocol. Advanced application inspection prevents protocol masquerading and enforcing strict RFC compliance.

To configure SMTP/ESMTP inspection, use the ip inspect name inspection-name {smtp | esmtp} command from the global configuration mode along with other required parameters. (Refer to steps defined earlier in the section “Configuring CBAC.”) This feature was introduced in IOS Version 12.3(14)T.

Firewall ACL Bypass

Before the implementation of the Firewall ACL Bypass feature, a packet was subject to processing for three searches (inbound ACL, outbound ACL, and the session table of the firewall). As discussed earlier, the dynamic ACL entry is a result of the corresponding connection information found in the session table that validates the session as being legitimate; therefore, checking the packet against the inbound and outbound ACL entries was deemed redundant and no longer necessary. The extra checks can be eliminated to save CPU cycles. Bypassing the ACL check enhancement subjects the packet to one search only (the session table) during the packet processing path through the router. Figure 5-6 shows how this works. The primary benefit in this feature is that the performance of the packet throughput is improved by approximately 10%.

Figure 5-6. Firewall ACL Bypass—Order of Packet Processing

Because the firewall ACL bypassing is performed by default, you can configure CBAC inspection as normal. This feature is transparent to the user, and no additional commands are required to enable or disable it.

This feature was introduced in IOS Version 12.3(4)T.

Transparent IOS Firewall (Layer 2)

The transparent IOS Firewall feature (also known as Layer 2 firewall) acts as a Layer 2 transparent bridge with CBAC inspection configured on the Bridged Virtual Interface (BVI).

A Layer 3 IOS Firewall implementation requires two logical zones—trusted and untrusted—both on different IP subnets (existing subnets). A network implementation not designed to accommodate this subnetted architecture would require the redesign of IP subnets to accommodate the firewall. Placing a Layer 3 firewall would be difficult in such scenarios and is considered resource intensive and could be unfeasible for most deployment scenarios.

Traditional firewalls operate in either a Layer 3 or Layer 2 (transparent) mode. The Cisco IOS Firewall is designed to simultaneously interoperate in both modes, providing scalability and ease of integration. This enhanced functionality allows a Cisco IOS Firewall to be implemented concurrently for both the Layer 2 transparent firewall operating on the bridged packets and a Layer 3 firewall operating on routed packets on the same device.

The transparent firewall configuration is no different from the Layer 3 firewall using the ip inspect command from the global configuration mode. The CBAC inspection rule ip inspect in/out command is applied to the bridged interfaces for Layer 2 protection, whereas other routed interfaces are configured for Layer 3 protection.

This feature was introduced in IOS Version 12.3(7)T.

Virtual Fragmentation Reassembly (VFR)

Before the implementation of the Virtual Fragmentation Reassembly (VFR) feature, the IOS Firewall (CBAC) could not identify the contents of the IP fragments or gather any port information from the fragmented packets. This shortcoming allowed all fragmented packets to bypass the firewall checks and get through the network without being inspected.

Before the VFR feature was available, several known fragment-type attacks could succeed. (Examples include Tiny Fragment attack, Overlapping Fragment attack, and the Buffer Overflow attack that sends a large number of incomplete IP fragments to thwart the firewall.) The VFR feature provides the capability to scan into the fragmented packets to check the connection information and create the corresponding dynamic ACL entries, hence protecting the network from various fragmentation attacks.

To enable VFR, use the ip virtual-reassembly command from the interface configuration mode. Example 5-6 shows how to configure VFR with a maximum number of 100 IP datagrams to be reassembled at any given time and a maximum number of 20 fragments allowed per IP datagram (fragment set). The timeout of 5 seconds specifies that if all the fragment packets are not received within the specified time, the IP datagram and all its fragments will be dropped.

This feature was introduced in IOS Version 12.3(8)T.

Example 5-6. Virtual Fragmentation Reassembly (VFR) Configuration Example

---

interface Fastethernet0/0
 ip inspect <name> in | out
 ip virtual-reassembly max-reassemblies 100 max-fragments 20 timeout 5
!

---

VRF-Aware IOS Firewall

The Multiprotocol Label Switching Virtual Private Network (MPLS VPN) feature allows several sites to interconnect transparently through a service provider network. A service provider network can support several IP VPNs. Each of these appears as a separate private network. VRF is an IP routing table instance for connecting sites in a VPN network. Each VPN has its own set or sets of VRF instances, thereby allowing each site to send IP packets to any other site in the same VRF instance.

The Cisco IOS Firewall feature is enhanced to support inspection for VRF instances in a MPLS VPN network. CBAC can inspect packets on a per-VRF basis for packets sent and received within a VRF. VRF-aware CBAC implementation can include multiple firewall instances (with VRF instances) that are allocated to separate VPN customers. VRF-aware CBAC provides scalability and low-cost integration without the need for separate firewall devices for each VPN network. In effect, a single physical router running multiple virtual routing instances (emulating multiple routers) can now run multiple virtual IOS Firewalls in a single device.

This feature was introduced in IOS Version 12.3(14)T.

Inspection of Router-Generated Traffic

The Cisco IOS Firewall feature is enhanced to support inspection for traffic that was originated by or destined to the CBAC-configured device. Inspection of router-generated traffic augments CBAC functionality to inspect TCP, UDP, and H.323 connections that have the firewall as one of the connection endpoints. CBAC dynamically opens temporary holes for TCP, UDP, and H.323 control channel connections to and from the router, and for the data and media channels negotiated over the H.323 control channels. For example, CBAC can be configured to inspect a Telnet initiated from the CBAC-enabled router to a device in the unprotected zone, allowing return traffic dynamically without needing to explicitly permit in the access list.

To enable the Router-Generated Traffic inspection feature, use the router-traffic keyword in the ip inspect name command when configuring CBAC inspection rules. This option is available for H.323, TCP, and UDP protocols only.

This feature was introduced in IOS Version 12.3(14)T.

Zone-Based Policy Firewall (ZFW)

The new ZFW feature was introduced in Cisco IOS Software Release 12.4(6)T for the enhanced Cisco IOS Firewall feature set.

All features from prior to IOS Software Release 12.4(6)T are inclusive in this new implementation and are supported in the new zone-based inspection.

ZFW supports the following features:

• Stateful packet Inspection (SPI)

• VRF-aware Cisco IOS Firewall

• URL filtering

• Denial-of-service (DoS) mitigation

More ZFW features were added into Cisco IOS Software Release 12.4(9)T for per-class session/connection and throughput limits, as well as application inspection and control:

• HTTP

• Post Office Protocol (POP3)

• Internet Mail Access Protocol (IMAP)

• Simple Mail Transfer Protocol and Enhanced Simple Mail Transfer Protocol (SMTP/ESMTP)

• Sun Remote Procedure Call (RPC)

• Instant Messaging (IM) applications, including Microsoft Messenger (MSN), Yahoo Messenger, and AOL Instant Messenger

• Peer-to-peer (P2P) file sharing, including Bittorrent, KaZaA, Gnutella, and eDonkey

---

---

Zone-Based Policy Overview

Before the ZFW was introduced, the Cisco IOS Firewall offered stateful inspection using the CBAC feature. CBAC was covered in detail in the previous sections of this chapter.

In the recent releases of Cisco IOS Software from Version 12.4(6)T and later, the CBAC model is being replaced with the new configuration model that uses ZFW.

This new feature was added mainly to overcome the limitations of the CBAC that was employing stateful inspection policy on an interface-based model. To be specific, the limitation was that all traffic passing through the interface was subject to the same inspection policy, thereby limiting the granularity and policy enforcement, particularly in scenarios where multiple interfaces existed.

With ZFW, stateful inspection can now be applied on a zone-based model. Interfaces are assigned to zones, and policy inspection is applied to traffic moving between zones. This enhancement provides more granularity, flexibility, scalability, and an easy-to-use zone-based security approach. With a zone-based inspection model, varying interzone policies can be applied to multiple hosts or groups of hosts connected to the same interface.

---

---

Security Zones

Security Zones establish the security boundaries of the network where traffic is subjected to policy restrictions as it crosses to another region within the network.

As shown in Figure 5-7, a zone can have one or more interface(s) assigned to it. This example shows a Cisco IOS Firewall router with four interfaces and three zones:

• Interface #1 connected to the Public Internet zone

• Interfaces #2 and #3 connected to a Private zone connecting file servers and clients on a LAN (on separate physical interfaces, but in the same security zone), which must not be accessible from the public Internet

• Interface #4 connected to the DMZ zone, connecting a web server and Domain Name System (DNS) server, which must be accessible to the public Internet

Figure 5-7. Basic Security Zone

In the example illustrated by Figure 5-7, the IOS Firewall will typically have three main security policies:

• Private zone connectivity to the Internet

• Private zone connectivity to DMZ

• Public zone connectivity to DMZ

Devices connected in the private zone would be able to pass traffic to all other devices between interface #2 and #3 because they are in the same Private zone. If an additional new interface is added to the Private zone, inter-interface and intra-interface traffic is allowed within the same zone. Additionally, the hosts’ traffic to hosts in other zones would be similarly affected by existing policies.

Configuring Zone-Based Policy Firewall

ZFW does not use the classical CBAC ip inspect command set. ZFW policies are configured with the new Cisco Policy Language (CPL), which employs a hierarchical structure to define inspection for network protocols and the groups of hosts to which the inspection will be applied. Note that the two configuration models (Classical CBAC and new ZFW) can be used concurrently on the same router; however, they cannot be combined on the same interface overlapping each other. An interface cannot be configured as a zone member and be configured for ip inspect simultaneously.

---

---

Configuring ZFW Using Cisco Policy Language (CPL)

ZFW is configured using the new command set of Cisco Policy Language (CPL). CPL is the new format to enable ZFW. The format is similar to the Modular QoS CLI (MQC) in using class-map to identify the traffic and the action applied in a policy map.

Several steps are required to complete the configuration. Although the sequence of tasks that follows is not important, some tasks depend on each other. For example, class-map must be configured before it can be used in the policy-map. Similarly, the policy-map cannot be assigned to a zone-pair before configuring the policy-map itself, and so on.

The following tasks are required to complete the ZFW configuration using the CPL:

• Define zones

• Define zone-pairs

• Define class-map(s) that identify the traffic that must have policy applied as it traverses a zone-pair

• Define a policy-map to apply action to the traffic in a class-map

• Apply a policy-map to a zone-pair

• Assign interface(s) to zones

---

---

Based on Figure 5-8, Example 5-7 shows a very basic ZFW configuration that uses the new CPL command set in two zones.

Figure 5-8. Basic ZFW for Two-Zone Setup

Example 5-7. Basic ZFW Configuration Using CPL

---

<omit>
class-map type inspect match-any myclass
 match protocol tcp
 match protocol udp
 match protocol icmp
!
policy-map type inspect mypolicy
 class type inspect myclass
  inspect
!
zone security private
zone security public
!
zone-pair security mypair source private destination public
 service-policy type inspect mypolicy
!
Interface FastEthernet0/0
 zone-member security private
!
interface FastEthernet0/1
 zone-member security public
!
<omit>

---

Application Inspection and Control (AIC)

In addition to the extensive ZFW features and capabilities, ZFW extends the function of application inspection and control (AIC) engine by providing additional capabilities to the ZFW. AIC policies are applied at Layer 7 of the OSI model, performing deep packet inspection at the application-protocol level.

ZFW offers application inspection and control for the following application services:

• HTTP

• SMTP

• POP3

• IMAP

• Sun remote procedure call

• Peer-to-peer application traffic

• Instant Messaging applications

---

---

Summary

This chapter discussed the router-based IOS Firewall technology and focused mainly on one of the several subsystems—the SPI technology that uses the classical firewall that in turn uses CBAC and the new ZFW structures. SPI is an advanced firewall engine for stateful inspection providing traffic-filtering functionality on a Cisco IOS–based device as a single point of protection.

The chapter described CBAC functions and how they work using step-by-step configuration processes with examples.

The chapter also covered the new ZFW concept using security zones and exemplified the required steps to configure the ZFW.

The chapter also provided an overview of some of the advanced IOS Firewall features introduced in the newer IOS Software versions.

References

www.cisco.com/en/US/products/ps6441/products_configuration_guide_book09186a008049e249.html

www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800ca7c5.html

www.cisco.com/en/US/products/sw/secursw/ps1018/products_implementation_design_guide09186a00800fd670.html

www.cisco.com/en/US/products/sw/iosswrel/ps5207/prod_bulletin09186a00801abfda.html

www.cisco.com/en/US/products/ps6441/prod_bulletin09186a00804a8728.html

www.cisco.com/en/US/products/ps6350/prod_bulletin09186a0080457a84.html

www.cisco.com/en/US/products/ps6350/products_feature_guide09186a008072c6e3.html

www.cisco.com/en/US/products/sw/secursw/ps1018/products_white_paper0900aecd806f31f9.shtml