642-637 Cisco - Press.SNRS - StudentGuide.v2.0.Vol3

SNRS
Securing Networks
with Cisco Routers
and Switches
Volume 3
Version 2.0
Student Guide
Editorial, Production, and Web Services: 02.06.07
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED AS IS. CISCO MAKES AND YOU RECEIVE NO WARRANTIES IN
CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY OR IN ANY OTHER PROVISION OF
THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO SPECIFICALLY DISCLAIMS ALL IMPLIED
WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR
PURPOSE, OR ARISING FROM A COURSE OF DEALING, USAGE OR TRADE PRACTICE. This learning product may contain early release
content, and while Cisco believes it to be accurate, it falls subject to the disclaimer above.
The PDF files and any printed representation for this material are the property of Cisco Systems, Inc.,
for the sole use by Cisco employees for personal study. The files or printed representations may not be
used in commercial training, and may not be distributed for purposes other than individual self-study.
Table of Contents
Volume 3
Adaptive Threat Defense
Overview
Module Objectives
Configuring Cisco IOS Firewall

Overview
Objectives
Firewalls
Cisco IOS as a Firewall
Cisco IOS Firewall Feature Set
Standard ACLs and Static Extended ACLS
Lock-and-Key (Dynamic ACLs)
Reflexive ACLs
TCP Intercept
Port-to-Application Mapping
Network Address Translation
Security Server Support
User Authentication and Authorization
Cisco IOS Classic Firewall
Cisco IOS Authentication Proxy
Authentication Proxy
Cisco IOS IPS
Cisco IOS IPS
Summary
References
Configuring Cisco IOS Classic Firewall

Overview
Objectives
Traffic Filtering
Traffic Inspection
Alerts and Audit Trails
What Cisco IOS Classic Firewall Does Not Do
Cisco IOS Classic Firewall Process
SPI or CBAC?
How Cisco IOS Classic Firewall Works
Firewall ACL Bypass
Access List Configuration
Packet Inspection
State Tables
UDP Session Approximation
When and Where to Configure Cisco IOS Classic Firewall
Supported Protocols
RTSP and H.323 Support for Multimedia Applications
Cisco IOS Classic Firewall Restrictions
Cisco IOS Classic Firewall Configuration Tasks
Configuring IP ACLs for Cisco IOS Classic Firewall
Basic ACL Configuration
External Interface ACL
Internal Interface ACL
Defining Inspection Rules
Configuring DoS Protection using Global Timeouts and Thresholds
Half-Open Sessions
Generic TCP and UDP Inspection
Application Layer Protocol Inspection
5-1
5-1
5-1
5-3
5-3
5-3
5-4
5-5
5-6
5-6
5-7
5-7
5-7
5-7
5-7
5-8
5-8
5-9
5-9
5-11
5-11
5-12
5-12
5-13
5-13
5-15
5-15
5-15
5-16
5-16
5-17
5-18
5-18
5-19
5-19
5-21
5-22
5-22
5-23
5-25
5-25
5-25
5-26
5-27
5-29
5-30
5-31
5-32
5-33
5-34
5-34
5-35
5-36
5-39
5-44
5-45
Java Blocking
IP Packet Fragmentation Inspection
Example Configurations
Application Firewall Policy
Application Policy for HTTP
Next Step
Application Firewall Policy for Instant Messaging (IM)
Verifying Application Firewall Configuration
Granular Protocol Inspection
System-Defined Port Mapping
User-Defined Port Mapping
Verifying PAM Configuration
Applying the Inspection Rule to an Interface
Audit Trails and Logging
Verifying Cisco IOS Classic Firewall
Removing Cisco IOS Classic Firewall
Summary
References
5-49
5-50
5-51
5-57
5-58
5-64
5-65
5-70
5-71
5-71
5-73
5-76
5-77
5-79
5-81
5-83
5-84
5-85
Configuring Cisco IOS Zoned-Based Policy Firewall
5-87
Overview
Objectives
Legacy Stateful Inspection
Cisco IOS Zone-Based Policy Firewall Overview
Configuration Model
General Rules
Basic Topology
DMZ Topology
Zones
Security Zones
Zoning Rules
Zone Pairs
Security Zone Firewall Policies
Class Maps for Cisco IOS Zone-Based Policy Firewalls
Policy Maps for Cisco IOS Zone-Based Policy Firewalls
Hierarchical Policy Maps
Parameter Maps
Configuring a Cisco IOS Zoned-Based Policy Firewall
Creating Security Zones and Zone Pairs
Configuring a Class Map for a Layer 3 and Layer 4 Firewall Policy
Creating a Policy Map for a Layer 3 and Layer 4 Firewall Policy
Configuring Cisco IOS Zone-Based Policy Firewall Parameter Maps
Attaching a Policy Map to a Zone Pair
Configuration Examples
Verifying Cisco IOS Zone-Based Policy Firewall
Summary
References
Configuring Cisco IOS Firewall Authentication Proxy

Overview
Objectives
Cisco IOS Firewall Authentication Proxy
Applying the Authentication Proxy
AAA Server Configuration
Cisco IOS Firewall Authentication Proxy Configuration
AAA Configuration
Configure the HTTP Server
Cisco IOS Firewall Authentication Proxy Rule Configuration
Applying Auth-prox to an Interface
Example
Router 2 Configuration Example
ii
Securing Networks with Cisco Routers and Switches (SNRS) v2.0
5-87
5-87
5-88
5-89
5-91
5-91
5-93
5-94
5-96
5-96
5-98
5-100
5-102
5-104
5-109
5-112
5-113
5-115
5-116
5-118
5-120
5-121
5-122
5-123
5-130
5-131
5-131
5-133
5-133
5-133
5-134
5-139
5-140
5-144
5-145
5-150
5-151
5-153
5-156
5-157
2007 Cisco Systems, Inc.
Test and Verify

Summary
References
5-159
5-162
5-162
Configuring Cisco IOS IPS
5-163
Overview
Objectives
Cisco IOS IPS
Features and Benefits
Origin of Cisco IOS Firewall IPS
Signature Micro-Engines
Signatures and SDFs
Built-in Signatures
Signature Actions
Signature Definition Files
Deploying IOS IPS
Cisco IOS Firewall IPS Configuration
Installing the Cisco IOS IPS Signatures
Merging Built-In Signatures with the 128MB.sdf File
Attaching a Policy to a Signature
Creating IPS Rules
Applying an IPS Rule at an Interface
IP Virtual Reassembly
Example
Configure Logging via Syslog or SDEE
SDEE Overview
Storing SDEE Events in the Buffer
Upgrading to the Latest SDF
Verifying IPS Configuration
clear Commands
debug Commands
Summary
References
Examining Company ABC Secured
5-207
Overview
Objectives
Company ABC Secured
Summary
Module Summary
References
5-163
5-163
5-164
5-166
5-167
5-168
5-172
5-173
5-174
5-177
5-179
5-182
5-183
5-185
5-188
5-190
5-192
5-193
5-194
5-195
5-196
5-197
5-199
5-200
5-204
5-205
5-206
5-206
5-207
5-207
5-208
5-210
5-211
5-211
iii
iv
Module 5

Overview
Adaptive Threat Defense (ATD) helps to minimize network security risks by dynamically
addressing threats at multiple layers, enabling tighter control of network traffic, endpoints,
users, and applications. The key components of ATD include better coordinated threat
mitigation through anti-X defenses, application security, and network control and containment.
In this module, you will be introduced to some of these key components of the Cisco IOS
Firewall feature set, which includes Cisco IOS Classic Firewall, zone-based policy firewall,
Cisco IOS Firewall authentication proxy, and Cisco IOS Intrusion Prevention System (IPS).
Module Objectives
Upon completing this module, you will be able to install, configure, and troubleshoot Cisco
IOS Firewall features, including Cisco IOS Classic Firewall Cisco IOS Firewall authentication
proxy, Zone-based Policy Firewall, and Cisco IOS IPS on a Cisco router. This ability includes
being able to meet these objectives:
Describe the main features of the Cisco IOS Firewall feature set
Configure Cisco IOS classic firewall, GPI, and an application policy firewall
Describe how to configure Cisco IOS Firewall authentication proxy
Describe how to configure Cisco IOS IPS
Describe the security features you have implemented to protect a network
5-2
Lesson 1

Overview
When you configure the Cisco IOS Firewall on your Cisco router, you turn your router into an
effective, robust firewall. To create a firewall customized to fit the security policy of your
organization, you should determine which Cisco IOS Firewall features are appropriate and
configure those features. This lesson introduces the Cisco IOS Firewall feature set and
describes some of its main features.
Objectives
Upon completing this lesson, you will be able to describe the main features of the Cisco IOS
Firewall feature set. This ability includes being able to meet these objectives:
Describe the basic functions of a firewall
Describe where to use the Cisco IOS Firewall in a production network
Describe the Cisco IOS Firewall feature set
Describe Cisco IOS classic firewall
Describe Cisco IOS Firewall authentication proxy
Describe Cisco IOS IPS
Firewalls
This topic describes the basic functions of a firewall.
Firewalls
Branch
Office
Corporate
Headquarters
Router with
Firewall
DMZ
Corporate
Resources
Research and
Development
Partner
2006 Cisco Systems, Inc. All rights reserved.
SNRS v2.05-2
Firewalls are networking devices that control access to the network assets of your organization.
Firewalls are positioned at the entrance points into your network. If your network has multiple
entrance points, you must position a firewall at each point to provide effective network access
control.
Firewalls are often placed in between the internal network and an external network such as the
Internet. With a firewall between your network and the Internet, all traffic coming from the
Internet must pass through the firewall before entering your network.
Firewalls can also be used to control access to a specific part of your network. For example,
you can position firewalls at all of the entry points into a research and development network to
prevent unauthorized access to proprietary information.
The most basic function of a firewall is to monitor and filter traffic. Firewalls can be simple or
elaborate, depending on your network requirements. Simple firewalls are usually easier to
configure and manage. However, you might require the flexibility of a more elaborate firewall.
Cisco IOS Software provides an extensive set of security features, allowing you to configure a
simple or elaborate firewall, according to your particular requirements. You can configure a
Cisco device as a firewall if the device is positioned appropriately at a network entry point.
5-4
Cisco IOS as a Firewall

This topic describes where to use the Cisco IOS Firewall in a production network.
IOS Firewall
Deploy:
As an Internet Firewall
Between groups on internal network
As a VPN end point from branches
Between partner network and corporate
Features:
Cisco IOS Software Stateful Packet Inspection
Protection Against Attack
Support for NAT and Port-to-Application Mapping (PAM)
SNRS v2.05-3
The Cisco IOS Firewall feature set combines existing Cisco IOS Firewall technology and the
Cisco IOS classic firewall. When you configure the Cisco IOS Firewall on your Cisco router,
you turn your router into an effective, robust firewall.
The Cisco IOS Firewall features are designed to prevent unauthorized external individuals from
gaining access to your internal network and to block attacks on your network, while at the same
time allowing authorized users to access network resources.
You can use the Cisco IOS Firewall features to configure your Cisco IOS router as one of the
following:
An Internet firewall or part of an Internet firewall
A firewall between groups in your internal network
A firewall providing secure connections to or from branch offices
A firewall between your company network and the networks of your company partners
The Cisco IOS Firewall features provide the following benefits:
Protection of internal networks from attacks and intrusion
Monitoring of traffic through network perimeters
Enabling of network commerce via the World Wide Web
5-5

This topic describes the Cisco IOS Firewall feature set.
Classic firewall
Authentication proxy
Cisco IOS IPS
ACLs
Standard and extended
Lock-and-key (Dynamic ACLs)
Reflexive
TCP Intercept
PAM
NAT
Security server support
RADIUS, TACACS+, Kerberos
User authentication and authorization
SNRS v2.05-4
The Cisco IOS Firewall is a security-specific option for Cisco IOS Software. It integrates
robust firewall functionality, authentication proxy, and intrusion prevention for every network
perimeter, and enriches existing Cisco IOS security capabilities. It adds greater depth and
flexibility to existing Cisco IOS security solutions, such as authentication, encryption, and
failover, by delivering state-of-the-art security features, such as stateful, application-based
filtering; dynamic per-user authentication and authorization; defense against network attacks;
Java blocking; and real-time alerts. When combined with Cisco IOS IP Security (IPsec)
software and other Cisco IOS Software-based technologies, such as Layer 2 Tunneling Protocol
(L2TP) tunneling and quality of service (QoS), the Cisco IOS Firewall provides a complete,
integrated virtual private network (VPN) solution.
To create a firewall customized to fit the security policy of your organization, you should
determine which Cisco IOS Firewall features are appropriate, and configure those features. At a
minimum, you must configure basic traffic filtering to provide a basic firewall. The sections
that follow examine Cisco IOS classic firewall, Cisco IOS Firewall authentication proxy, and
Cisco IOS IPS, but you can also configure your Cisco networking device to function as a
firewall by using the Cisco IOS Firewall features discussed next.
Standard ACLs and Static Extended ACLS

Standard and static extended access control lists (ACLs) provide basic traffic filtering
capabilities. You configure criteria that describe which packets should be forwarded and which
packets should be dropped at an interface, based on the network layer information of each
packet. For example, you can block all User Datagram Protocol (UDP) packets from a specific
source IP address or address range. Some extended ACLs can also examine transport layer
information to determine whether to block or forward packets.
5-6
To configure a basic firewall, you should at a minimum configure basic traffic filtering. You
should configure basic ACLs for all network protocols that will be routed through your
firewall, such as IP, Internetwork Packet Exchange (IPX), AppleTalk, and so forth.
Lock-and-Key (Dynamic ACLs)

Lock-and-key provides traffic filtering with the ability to allow temporary access through the
firewall for certain individuals. These individuals must first be authenticated (by a username
and password mechanism) before the firewall allows their traffic through the firewall.
Afterward, the firewall closes the temporary opening. This provides tighter control over traffic
at the firewall than with standard or static extended ACLs.
Reflexive ACLs
Reflexive ACLs filter IP traffic so that TCP or UDP session traffic is only permitted through
the firewall if the session originated from within the internal network.
Note
You would only configure reflexive ACLs when not using Context-Based Access Control
(CBAC).
TCP Intercept
TCP Intercept protects TCP servers within your network from TCP SYN-flooding attacks, a
type of denial of service (DoS) attack.
Note
You would only configure TCP Intercept when not using CBAC.
Port-to-Application Mapping
Port-to-Application Mapping (PAM) is a feature of Cisco IOS Firewall. PAM allows you to
customize TCP or UDP port numbers for network services or applications. PAM uses this
information to support network environments that run services using ports that are different
from the registered or well-known ports associated with an application. The information in the
PAM table enables Cisco IOS classic firewall supported services to run on nonstandard ports.
Network Address Translation

You can use Network Address Translation (NAT) to hide internal IP network addresses from
the world outside the firewall.
NAT was designed to provide IP address conservation and for internal IP networks that have
unregistered (not globally unique) IP addresses. NAT translates these unregistered IP addresses
into legal addresses at the firewall. NAT can also be configured to advertise only one address
for the entire internal network to the outside world. This provides security by effectively hiding
the entire internal network from the world.
NAT gives you limited spoof protection because internal addresses are hidden. Additionally,
NAT removes all of your internal services from the external name space.
5-7
Some applications use embedded IP addresses in such a way that it is impractical for a NAT
device to translate them. These applications may not work transparently or at all through a
NAT device. NAT does not work with the application layer protocols, such as remote
procedure call (RPC), VDOLive, or SQL*Net redirected. (NAT does work with SQL*Net
bequeathed.) Do not configure NAT on networks that will carry traffic for these incompatible
protocols.
Security Server Support

The Cisco IOS Firewall feature set can be configured as a client of the following supported
security servers:
TACACS+
RADIUS
Kerberos
You can use any of these security servers to store a database of user profiles. To gain access
into your firewall or to gain access through the firewall into another network, users must enter
authentication information (such as a username and password), which is matched against the
information on the security server. When users pass authentication, they are granted access
according to their specified privileges.
User Authentication and Authorization

Authentication and authorization help protect your network from access by unauthorized users.
5-8

This topic describes the Cisco IOS classic firewall.

TCP
UDP
Internet
Packets are inspected entering the firewall by Cisco IOS classic

firewall if they are not specifically denied by an ACL.
Cisco IOS classic firewall permits or denies specified TCP and UDP
traffic through a firewall.
A state table is maintained with session information.
ACLs are dynamically created or deleted.
Cisco IOS classic firewall protects against DoS attacks.
SNRS v2.05-5

The Cisco IOS classic firewall engine provides secure, per-application access control across
network perimeters. Cisco IOS classic firewall enhances security for TCP and UDP
applications that use well-known ports, such as FTP and e-mail traffic, by scrutinizing source
and destination addresses. Cisco IOS classic firewall allows network administrators to
implement firewall intelligence as part of an integrated, single-box solution.
Cisco IOS classic firewall examines not only network layer and transport layer information, but
also examines the application layer protocol information (such as FTP information) to learn
about the state of TCP and UDP connections. Cisco IOS classic firewall maintains connection
state information for individual connections. This state information is used to make intelligent
decisions about whether packets should be permitted or denied, and dynamically creates and
deletes temporary openings in the firewall.
Cisco IOS classic firewall also generates real-time alerts and audit trails. Enhanced audit trail
features use syslog to track all network transactions. Real-time alerts send syslog error
messages to central management consoles upon detecting suspicious activity. Using Cisco IOS
classic firewall inspection rules, you can configure alerts and audit trail information on a perapplication protocol basis.
5-9
Cisco IOS classic firewall intelligently filters TCP and UDP packets based on application layer
protocol session information. It can inspect traffic for sessions that originate on any interface of
the router. Cisco IOS classic firewall 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 ACLs of the firewall to allow return traffic and
additional data connections for permissible sessions.
A new feature introduced in Cisco IOS Release 12.3(4)T is the Firewall ACL Bypass feature,
which allows a packet to avoid redundant ACL checks by allowing the firewall to permit the
packet on the basis of existing inspection sessions instead of dynamic ACLs. Thus, input and
output dynamic ACL searches are eliminated, improving the overall throughput performance of
the base engine. After the firewall is configured for inspection, ACL bypassing is performed by
default
Inspecting packets at the application layer and maintaining TCP and UDP session information
provides Cisco IOS classic firewall with the ability to detect and prevent certain types of
network attacks, such as TCP SYN-flooding attacks. Cisco IOS classic firewall also inspects
packet sequence numbers in TCP connections to see if they are within expected rangesCisco
IOS classic firewall drops any suspicious packets. Additionally, Cisco IOS classic firewall can
detect unusually high rates of new connections and issue alert messages. Cisco IOS classic
firewall inspection can help protect against certain DoS attacks involving fragmented IP
packets.
5-10
Cisco IOS Authentication Proxy

This topic describes Cisco IOS Firewall authentication proxy.
HTTP, HTTPS, FTP, and Telnet authentication

Provides dynamic, per-user authentication and authorization via
TACACS+ and RADIUS protocols
SNRS v2.05-6
The Cisco IOS Firewall authentication proxy feature allows network administrators to apply
specific security policies on a per-user basis. Previously, user identity and related authorized
access was associated with a user IP address, or a single security policy had to be applied to an
entire user group or subnetwork. Now, users can be identified and authorized on the basis of
their per-user policy, and access privileges tailored on an individual basis are possible, as
opposed to a general policy applied across multiple users. Per-user policies can be downloaded
dynamically to the router from a TACACS+ or RADIUS authentication server using Cisco IOS
software authentication, authorization, and accounting (AAA) services.
Users can log into the network or access the Internet via HTTP, secure HTTP (HTTPS), FTP,
and Telnet, and their specific access profiles will automatically be downloaded. Appropriate
dynamic individual access privileges are available as required, protecting the network against
more general policies applied across multiple users. Authentication and authorization can be
applied to the router interface in either direction to secure inbound or outbound extranet,
intranet, and Internet usage.
The authentication proxy is compatible with other Cisco IOS security features, such as NAT,
IPsec encryption, and VPN client software.
5-11
Cisco IOS IPS

This topic describes Cisco IOS IPS.
Cisco IOS IPS

TCP
UDP
Internet
Acts as an in-line Cisco IOS intrusion prevention sensor

When a packet or packets match a signature, it can perform any of the
following configurable actions:
Alarm: Send an alarm to a security device manager or syslog server
Drop: Drop the packet
Reset: Send TCP resets to terminate the session
Identifies 1500-plus common attacks
SNRS v2.05-7
Cisco IOS IPS

The Cisco IOS IPS acts as an in-line intrusion prevention sensor, watching packets and
sessions as they flow through the router and scanning each packet to match any of the
Cisco IOS IPS signatures. When Cisco IOS IPS detects suspicious activity, it responds before
network security can be compromised and logs the event through Cisco IOS syslog messages or
Security Device Event Exchange (SDEE). The network administrator can configure Cisco IOS
IPS to choose the appropriate response to various threats. When packets in a session match a
signature, Cisco IOS IPS can take any of the following actions, as appropriate:
5-12
Send an alarm to a syslog server or a centralized management interface
Drop the packet
Reset the connection
Deny traffic from the source IP address of the attacker for a specified amount of time
Deny traffic on the connection for which the signature was seen for a specified amount of
time
Summary
This topic summarizes the key points that were discussed in this lesson.
Summary
Firewalls are networking devices that control access to network
assets of your organization.
The Cisco IOS Firewall feature set combines existing Cisco IOS
Firewall technology and Cisco IOS Classic Firewall.
The Cisco IOS Firewall is a security-specific option for Cisco IOS
Software.
Cisco IOS classic firewall intelligently filters TCP and UDP
packets based on applicationlayer protocol session information.
The Cisco IOS Firewall authentication proxy feature allows
network administrators to apply specific security policies on a peruser basis.
The Cisco IOS IPS acts as an in-line intrusion detection sensor.
SNRS v2.05-8
References
For additional information, refer to this resource:
Cisco Systems, Inc. Cisco IOS Security Configuration Guide, Release 12.4
http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_book091
86a008043360a.html
5-13
5-14
Lesson 2
Configuring Cisco IOS Classic

Firewall
Overview
One of the main features of the Cisco IOS Firewall feature set is Cisco IOS Classic Firewall
formerly know as Context-Based Access Control (CBAC). In this lesson, you will learn how to
configure Cisco IOS classic firewall, including how to configure Granular Protocol Inspection
(GPI) and application firewall.
Objectives
Upon completing this lesson, you will be able to configure Cisco IOS classic firewall), GPI,
and an application policy firewall. This ability includes being able to meet these objectives:
Describe Cisco IOS classic firewall
Describe how Cisco IOS classic firewall works
List the tasks required to configure Cisco IOS classic firewall
Describe how to configure IP ACLs for Cisco IOS classic firewall
Describe how to create inspection rules
Describe example firewall configurations for two different topologies
Describe how to configure an application firewall policy for HTTP and IM
Describe how to configure GPI
Describe how to apply inspection rules to router interfaces
Describe how to configure audit trails and logging for Cisco IOS classic firewall
List the commands used to verify and troubleshoot Cisco IOS classic firewall configuration
and operation
Describe how to remove Cisco IOS classic firewall

This topic describes Cisco IOS classic firewall.
Cisco IOS Classic Firewall Overview

Traffic Filtering
Traffic Inspection
SNRS v2.05-2
Cisco IOS classic firewall works to provide network protection on multiple levels using the
following functions:
Traffic filtering
Traffic inspection
Alerts and audit trails
Intrusion prevention
Traffic Filtering
Cisco IOS classic firewall intelligently filters TCP and User Datagram Protocol (UDP) packets
based on application layer protocol session information. You can configure Cisco IOS classic
firewall to permit specified TCP and UDP traffic through a firewall only when the connection
is initiated from within the network that you want to protect. Cisco IOS classic firewall can
inspect traffic for sessions that originate from either side of the firewall, and Cisco IOS classic
firewall can be used for intranet, extranet, and Internet perimeters of your network.
Without Cisco IOS classic firewall, traffic filtering is limited to access control list (ACL)
implementations that examine packets at the network layer, or at most, the transport layer.
However, Cisco IOS classic firewall 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 for the support of
protocols that involve multiple channels created as a result of negotiations in the control
channel. Most of the multimedia protocols and some other protocols (such as FTP, RPC, and
SQL*Net) involve multiple channels.
5-16
Using Cisco IOS classic firewall, 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 Cisco IOS classic firewall inspection rule to filter Java applets at the firewall. This
allows users to download only applets residing within the firewall and trusted applets from
outside the firewall. For extensive content filtering of Java, ActiveX, or virus scanning, you
might want to consider purchasing a dedicated content filtering product.
Traffic Inspection
Cisco IOS classic firewall 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 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 Cisco IOS classic firewall with the ability to detect and prevent certain types of
network attacks such as TCP SYN-flooding attacks. A TCP SYN-flooding 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.
Cisco IOS classic firewall helps to protect against DoS attacks in other ways. Cisco IOS classic
firewall inspects packet sequence numbers in TCP connections to see if they are within
expected rangesCisco IOS classic firewall drops any suspicious packets. You can also
configure Cisco IOS classic firewall to drop half-open connections, which require firewall
processing and memory resources to maintain. Additionally, Cisco IOS classic firewall can
detect unusually high rates of new connections and issue alert messages.
Cisco IOS classic firewall 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.
An attacker can overwrite the fragment offset in the noninitial IP fragment packets. When the
firewall reassembles the IP fragments, it might create wrong IP packets, causing the memory to
overflow or your system to crash.
An attacker can also make the fragment size small enough to force Layer 4 (TCP and UDP)
header fields into the second fragment. Thus, the ACL rules that have been configured for those
fields will not match.
In addition, an attacker can continuously send a large number of incomplete IP fragments,
causing the firewall to lose CPU processing power and memory while trying to reassemble the
bad packets.
5-17

Cisco IOS classic firewall 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, sessionbased reporting. Real-time alerts send syslog error messages to central management consoles
upon detecting suspicious activity. Using Cisco IOS classic firewall 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 Cisco
IOS classic firewall rule covering HTTP inspection.
What Cisco IOS Classic Firewall Does Not Do

Cisco IOS classic firewall 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 Cisco IOS classic
firewall, the existing ACLs will determine how that protocol is filtered. No temporary openings
will be created for protocols not specified for Cisco IOS classic firewall inspection.
Cisco IOS classic firewall 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. Cisco IOS classic firewall only detects and protects against attacks that travel
through the firewall. This is a scenario in which you might want to deploy Cisco IOS classic
firewall on an intranet-based router.
Cisco IOS classic firewall protects against certain types of attacks, but not every type of attack.
Cisco IOS classic firewall 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, Cisco IOS classic firewall detects and prevents most of the popular
attacks on your network.
5-18
Cisco IOS Classic Firewall Process

This topic describes how Cisco IOS classic firewall works.
How Classic Firewall Works

4
2
1
UserX initiates a HTTP

session.
Classic Firewall uses ACL Bypass

to bypass multiple ACL checks
Traffic inspected after passing

ACLs
ACL
10.0.6.12
5
ACL
Port
3575
ACL
7
Fa0/0
Port
80
6
S0
10.0.1.12
router(config)# ip access-list 104 deny ip any any
router(config)# ip access-list 103 permit http any any
router(config)# ip inspect name FWRULE tcp
router(config)# interface S0
router(config-if)# ip access-group 103 out
router(config-if)# ip access-group 104 in
router(config-if)# ip inspect FWRULE out
router# show ip inspect sessions
Established Sessions
Session 641721A8 (10.0.1.12:3575)=>(10.0.6.12:80) http SIS_OPEN
Attacker
SNRS v2.05-3
Cisco IOS Classic Firewall uses Stateful Packet Inspection (SPI) to inspect traffic and create
temporary openings 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 Cisco IOS classic firewall when exiting
through the firewall.
SPI or CBAC?
SPI was originally introduced as a feature called Context-Based Access Control (CBAC). Prior
to CBAC, Cisco IOS Software's only packet-filtering mechanism was the access control list
(ACL). CBAC greatly enhanced the packet filtering capability of ACLs by introducing stateful
filtering capability. The early Cisco IOS Firewall capability was occasionally perceived as a
"glorified" ACL. This misconception is partly due to the fact that ACL monitoring commands
were used to monitor CBAC activity, as well as the fact that inspection used (and still uses)
ACLs to filter traffic, permitting desired traffic, while blocking unwanted, potentially harmful
traffic. However, CBAC substantially augments an ACL's capability for restricting traffic.
CBAC monitors several attributes in TCP connections, UDP sessions, and Internet Control
Message Protocol (ICMP) dialogue to ensure that the only traffic allowed through a firewall
ACL is the return traffic for dialogue that was originated on the private side of the firewall.
5-19
Cisco IOS SPI can be described as a mechanism to discover "good" connections that originate
on the secure (trusted) side of the firewall, and watch for and allow the return traffic that
correlates with these connections. Connections originating on the unsecure (untrusted) side of
the firewall are not allowed to reach the secure network, as controlled by an ACL facing the
unsecure network as shown in the figure above.
Many changes have been made to CBAC to enhance its capability and increase performance.
Inspection of some protocols has been enhanced to ensure protocol compliance or offer
application-level service filtering. Beginning in Cisco IOS Software Release 12.3(4)T, the ACL
Bypass feature introduced substantial improvements in performance and significant changes to
the stateful inspection architecture. CBAC had outgrown its original, basic function and was
renamed Cisco IOS Stateful Packet Inspection to more accurately reflect the feature's
capability. CBAC is frequently still used synonymously with Stateful Packet Inspection, but the
CBAC name does not reflect the full feature set offered by Cisco IOS SPI.
SPI inspects the packet after it passes the inbound ACL of an input interface if the ip inspect
in command is applied, or after the outbound ACL of the output interface if the ip inspect
out command is used. Therefore, outbound traffic must be permitted by input ACLs facing the
source and outbound ACLs facing the destination.
Old Verification Method

The mechanism for anticipating and allowing the return traffic changed slightly as Cisco IOS
Firewall changed from CBAC to SPI. Prior to Cisco IOS Software Release 12.3(4)T, CBAC
placed dynamic access control entries (ACEs) in ACLs in the return path for internally
originated connections, as indicated in "show access-list" for a simple "deny all" ACL:
router# show ip access-list
Extended IP access list 104
permit tcp host 10.0.1.12 eq 3575 host 10.0.6.12 eq 80 (57 matches)
10 deny ip any any (1028 matches)
New Verification Method

When Cisco IOS Software Release 12.3(4)T was introduced, the ACL Bypass feature modified
SPI's infrastructure so that dynamic ACEs are no longer used. Instead, SPI maintains a session
table listing all of the firewall's active sessions. The contents of the session table can be viewed
with the show ip inspect sessions command as shown in the following examples:
router# show ip inspect sessions
router# show ip inspect sessions detail

Created 00:00:13, Last heard 00:00:12
Bytes sent (initiator:responder) [1291:659]
In
5-20
SID 10.0.6.12[80:80]=>10.0.1.12[3575:3575] on ACL 104
(5 matches)
ACL Bypass improves firewall performance for two reasons. SPI is able to maintain a more
efficient list to track active sessions, reducing the time required for session setup and
verification. Also, return traffic is not subjected to ACLs on the return path, so when return
traffic finds a matching entry in the session table, it is shunted past the ACLs in the packet path,
reducing the CPU overhead the packet incurs as it moves through the router's processing.
How Cisco IOS Classic Firewall Works

This section describes a sample sequence of events that occurs when Cisco IOS classic firewall
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 external interface of the
firewall. The TCP packet is the first packet of a HTTP session, and TCP is configured for Cisco
IOS classic firewall inspection.
1. User X initiates a HTTP session and the packet reaches the external interface of the
firewall.
2. The packet is evaluated against the internal interfaces inbound or external interface's
existing outbound access list, and the packet is permitted.
Note
A denied packet would be dropped at this point.
3. The packet is inspected by Cisco IOS classic firewall to determine and record information
about the state of the packet connection. This information is recorded in a new state table
entry created for the new connection.
Note
If the packet application (HTTP) was not configured for Cisco IOS classic firewall inspection,
the packet would simply be forwarded out the external interface at this point without being
inspected by Cisco IOS classic firewall.
4. The Firewall ACL Bypass feature allows a packet to avoid redundant access control list
(ACL) checks by allowing the firewall to permit the packet on the basis of existing
inspection sessions instead of dynamic ACLs. Because a matching inspection session is
often found in the beginning of IP processing, the input and output dynamic ACL searches
are no longer necessary and can be eliminated.
5. The outbound packet is forwarded out of the interface.
6. Later, an inbound return packet reaches the interface. This packet is part of the same HTTP
connection previously established with the outbound packet and is permitted
7. The permitted inbound packet is inspected by Cisco IOS Classic Firewall, and the
connection's state table entry is updated as necessary.
8. Any additional inbound or outbound packets that belong to the connection are inspected to
update the state table entry and they are forwarded through the interface.
9. When the connection terminates or times out, the connection's state table entry is deleted.
Cisco IOS Firewall inspects packets after input and output ACL checks. When inspecting, the
advanced firewall engine may insert or remove the ACL items associated with a session,
depending upon its state and context.
5-21
Firewall ACL Bypass

The Firewall ACL Bypass feature allows a packet to avoid redundant access control list (ACL)
checks by allowing the firewall to permit the packet on the basis of existing inspection sessions
instead of dynamic ACLs. Thus, input and output dynamic ACLs searches are eliminated,
improving the overall throughput performance of the base engine.
Note
After the firewall is configured for inspection, ACL bypassing is performed by default
Because input and output dynamic ACLs are no longer necessary, the need for IOS Classic
Firewall to create dynamic ACLs on the interface is eliminated. Following are some benefits of
this feature:
Improved connections per second performance of the firewall
Reduced run-time memory consumption of the firewall
Before ACL bypassing was implemented, a packet could be subjected to as many as three
redundant searches. Specifically:
an input ACL search
an output ACL search
an inspection session search.
Each dynamic ACL that IOS Classic Firewall creates corresponds to a single inspection
session. Thus, a matching dynamic ACL entry for a given packet implies that a matching
inspection session exists and that the packet should be permitted through the ACL. Because a
matching inspection session is often found in the beginning of IP processing, the input and
output dynamic ACL searches are no longer necessary and can be eliminated.
ACL bypassing subjects the packet to one search (the inspection session search) during its
processing path through the router. When a packet is subjected to a single inspection session
search before the ACL checks, the packet is matched against the list of session identifiers that
already exist on the interface. Session identifiers (SIDs) keep track of the source and
destination IP addresses and ports of the packets and on which interface the packet arrived.
Since ACL bypassing is performed by default. You should configure inspection as you would
normally.
Access List Configuration

In the sample process just described, the firewall ACLs are configured as follows:
An outbound IP access list (standard or extended) is applied to the external interface.
OR
An inbound IP access list (standard or extended) is applied to the internal interface.
This access list permits all packets that you want to allow to exit the network, including packets
you want to be inspected by IOS Classic Firewall. In the example, HTTP packets were
permitted.
5-22
An inbound extended IP access list is applied to the external interface. This access list
denies any traffic to be inspected by IOS Classic Firewall. When IOS Classic Firewall is
triggered with an outbound packet it checks the state table to see if the traffic is part of a
valid existing session.
Caution
If the inbound ACL on the external interface had been configured to permit all traffic, Cisco
IOS classic firewall would be creating pointless openings in the firewall for packets that
would be permitted anyway.
Throughout this lesson, the terms inbound and outbound are used to describe the direction
of traffic relative to the router interface on which Cisco IOS classic firewall is applied. For
example, if a Cisco IOS classic firewall inspection rule is applied inbound on interface E0,
packets entering interface E0 from the network will be inspected. If a Cisco IOS classic firewall
inspection rule is applied outbound on interface E0, packets leaving interface E0 to the network
will be inspected. This is similar to the way ACLs work.
For example, consider a Cisco IOS classic firewall inspection rule named FWRULE, and
suppose that rule is applied inbound at interface E0 with the following commands:
router(config)# interface Fa0/0
router(config-if)# ip inspect FWRULE in
This command causes Cisco IOS classic firewall to inspect the packets coming into this
interface from the network. If a packet is attempting to initiate a session, Cisco IOS classic
firewall will then determine if this protocol is allowed, create a Cisco IOS classic firewall
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 the figure, the inbound ACL at S0 is configured to block HTTP traffic, and there is no
outbound ACL configured at E0. When the connection request for the HTTP session of user X
passes through the firewall, Cisco IOS classic firewall creates a temporary opening in the
inbound ACL at S0 to permit returning HTTP traffic for the HTTP session of user X.
Packet Inspection
With Cisco IOS classic firewall, 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 Cisco IOS classic firewall.
Packets entering the firewall are inspected by Cisco IOS classic firewall only if they first pass
the inbound ACL at the input interface or the outbound ACL at the output interface, or both. If
a packet is denied by the ACL, the packet is simply dropped and not inspected by Cisco IOS
classic firewall.
Cisco IOS classic firewall inspection tracks sequence numbers in all TCP packets, and drops
those packets with sequence numbers that are not within expected ranges.
Cisco IOS classic firewall inspection recognizes application-specific commands (such as illegal
SMTP commands) in the control channel, and detects and prevents certain application-level
attacks.
5-23
When Cisco IOS classic firewall suspects an attack, the DoS feature can take several actions:
Generate alert messages
Protect system resources that could impede performance
Block packets from suspected attackers
Cisco IOS classic firewall 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 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-opened sessions,
which limits the amount of system resources applied to half-opened sessions. When a session is
dropped, Cisco IOS classic firewall sends a reset message to the devices at both endpoints
(source and destination) of the session. When the system under DoS attack receives a reset
command, it releases, or frees, processes and resources related to that incomplete session.
Cisco IOS classic firewall provides three thresholds against DoS attacks:
The total number of half-opened TCP or UDP sessions
The number of half-opened sessions based on time
The number of half-opened TCP-only sessions per host
If a threshold is exceeded, Cisco IOS classic firewall has two options:
It can send a reset message to the endpoints of the oldest half-opened session, making
resources available to service newly arriving synchronization (SYN) packets.
In the case of half-opened TCP-only sessions, Cisco IOS classic firewall blocks all SYN
packets temporarily for the duration configured by the threshold value. When the router
blocks a SYN packet, the TCP three-way handshake is never initiated, which prevents the
router from using memory and processing resources needed for valid connections.
DoS detection and prevention requires that you create a Cisco IOS classic firewall 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, Cisco IOS classic firewall can track all TCP connections to watch for DoS
attacks. If the inspection rule includes FTP protocol inspection but not TCP inspection, Cisco
IOS classic firewall tracks only FTP connections for DoS attacks.
5-24
State Tables
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 packet connection. Return traffic will be
permitted back through the firewall only if the state table contains information indicating that
the packet belongs to a permissible session. Inspection controls the traffic that belongs to a
valid session and forwards the traffic it does not know. When return traffic is inspected, the
state table information is updated as necessary.
UDP Session Approximation

UDP sessions are approximated. With UDP 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, similar source or 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.
When and Where to Configure Cisco IOS Classic Firewall

Configure Cisco IOS classic firewall at firewalls protecting internal networks. Such firewalls
should be Cisco routers with the Cisco IOS Firewall feature set.
Use Cisco IOS classic firewall when the firewall will be passing traffic such as the following:
Standard TCP and UDP Internet applications
Multimedia applications
Oracle support
Use Cisco IOS classic firewall for these applications if you want the application 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 Cisco IOS classic firewall 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 Cisco IOS classic firewall in two directions at one or more interfaces.
Cisco IOS classic firewall 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 the networks of two
partner companies, you might wish to restrict traffic in one direction for certain applications,
and restrict traffic in the opposite direction for other applications.
5-25
Supported Protocols
This section lists the protocols supported by Cisco IOS classic firewall.
Supported Protocols
TCP
SQL*Net
UDP
RTSP (such as Real Networks)
RPC
FTP
H.323 (such as NetMeeting,

ProShare)
TFTP
CUseeMe
UNIX r commands (such as

rlogin, rexec, and rsh)
Other multimedia
Microsoft NetShow
SMTP
StreamWorks
HTTP (Java blocking)
VDOLive
SNRS v2.05-4
You can configure Cisco IOS classic firewall to inspect the following types of sessions:
All TCP sessions, regardless of the application layer protocol (sometimes called singlechannel or generic TCP inspection)
All UDP sessions, regardless of the application layer protocol (sometimes called singlechannel or generic UDP inspection)
You can also configure Cisco IOS classic firewall to specifically inspect certain application
layer protocols. The following application layer protocols can all be configured for Cisco IOS
classic firewall:
RPC (Sun RPC, not distributed computing environment RPC)
FTP
TFTP
UNIX r commands (such as rlogin, rexec, and rsh)
SMTP
Extended Simple Mail Transfer Protocol (ESMTP)

Cisco IOS Release 12.3(7)T ESMTP support for the Cisco IOS Firewall feature enhances
the Cisco IOS Firewall to support ESMTP, allowing customers who install mail servers
behind Cisco IOS Firewalls to install their servers on the basis of ESMTP (instead of
SMTP).
5-26
HTTP (Java blocking)
Internet Control Message Protocol (ICMP)
SQL*Net
CUseeMe [only the White Pine version]
Microsoft NetShow
StreamWorks
VDOLive
Session initiation protocol (SIP)
Refer to the latest Cisco IOS documentation for the latest list of supported protocols.
When a protocol is configured for Cisco IOS classic firewall, 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 Support for Multimedia Applications

Cisco IOS classic firewall 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 multimedia application protocols:
Real-Time Streaming Protocol (RTSP) (for example, RealNetworks)
H.323 version 2 (H.323v2) (for example, Microsoft Windows NetMeeting (NetMeeting),

Intel ProShare)
RTSP and H.323v2 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 Internet Engineering Task Force (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 for 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 Cisco IOS classic firewall
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 Cisco IOS classic firewall show
commands.
5-27
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).
Cisco IOS classic firewall uses this port information along with connection information from
the client to create dynamic ACL entries in the firewall. As TCP or UDP connections are
terminated, Cisco IOS classic firewall removes these dynamic entries from the appropriate
ACLs.
Cisco IOS classic firewall support for RTSP includes the following data transport modes:
Standard RTP: RTP is an IETF standard (RFC 1889) supporting delivery of real-time data
such as audio and video. RTP uses the 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.
RealNetworks Data Transport (RDT): 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.
Interleaved (tunnel mode): In this mode, RTSP uses the control channel to tunnel RTP or
RDT traffic.
Synchronized Multimedia Integration Language (SMIL): 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 SMILCisco IP/TV
and Apple QuickTime 4 do not.
H.323 Support
Cisco IOS classic firewall support for H.323 inspection includes H.323v2 and H.323 version 1
(H.323v1). H.323v2 provides additional options over H.323v1, 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.323v2 inspection is backward-compatible
with H.323v1.
With H.323v1, 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.323v2 client opens a connection to the server that 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).
Cisco IOS classic firewall uses this port information along with connection information from
the client to create dynamic ACL entries in the firewall. As TCP or UDP connections are
terminated, Cisco IOS classic firewall removes these dynamic entries from the appropriate
ACLs.
5-28
Cisco IOS Classic Firewall Restrictions

Cisco IOS classic firewall has the following restrictions:
Cisco IOS classic firewall is available only for IP traffic. Only TCP and UDP packets are
inspected. (Other IP traffic, such as ICMP, cannot be inspected with Cisco IOS classic
firewall and should be filtered with basic ACLs instead.)
If you reconfigure your ACLs when you configure Cisco IOS classic firewall, be aware that
if your ACLs block TFTP traffic into an interface, you will not be able to netboot over that
interface.
Note
This is not a Cisco IOS classic firewall-specific limitation, but is part of existing ACL
functionality.
Packets with the firewall as the source or destination address are not inspected by Cisco
IOS classic firewall.
Cisco IOS classic firewall ignores ICMP unreachable messages.
H.323v2 and RTSP protocol inspection supports only the following multimedia clientserver applications:
Cisco IP/TV
RealNetworks RealAudio G2 Player
Apple QuickTime 4
FTP Traffic
Following are some restrictions to be noted when configuring for FTP inspection:
With FTP, Cisco IOS classic firewall does not allow third-party connections (three-way
FTP transfer).
When Cisco IOS classic firewall inspects FTP traffic, it only allows data channels with the
destination port in the range of 1024 to 65535.
Cisco IOS classic firewall will not open a data channel if the FTP client-server
authentication fails.
IPsec and Cisco IOS Classic Firewall

When Cisco IOS classic firewall and IPsec are enabled on the same router, and the firewall
router is an endpoint for IPsec for the particular flow, IPsec is compatible with Cisco IOS
classic firewall (that is, Cisco IOS classic firewall can do its normal inspection processing on
the flow).
If the router is not an IPsec endpoint, but the packet is an IPsec packet, Cisco IOS classic
firewall will not inspect the packets because the protocol number in the IP header of the IPsec
packet is not TCP or UDP. Cisco IOS classic firewall only inspects UDP and TCP packets.
5-29

This topic covers alerts and audit trails.

Cisco IOS classic firewall generates real-time alerts and audit
trails.
Audit trail features use syslog to track all network transactions.
With Cisco IOS classic firewall inspection rules, you can configure
alerts and audit trail information on a
per-application protocol basis.
SNRS v2.05-5
Cisco IOS classic firewall also generates real-time alerts and audit trails based on events
tracked by the firewall. 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 Cisco IOS classic firewall 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 Cisco IOS classic
firewall rule covering HTTP inspection.
5-30
Cisco IOS Classic Firewall Configuration Tasks

This topic lists the tasks required to configure Cisco IOS classic firewall.
IOS Classic Firewall Configuration

Identify traffic that will be allowed out through the firewall.
Be sure ACLs permit legitimate traffic from the secure network to the unsecure
network.
Configure ACLs to block traffic from the unsecure network.
Create inspection rules.
Set global timeouts and thresholds
DoS Protection
Define inspection rules
Generic TCP and UDP
Application Layer Inspection
Granular Protocol Inspection (GPI)
Java Blocking
IP Packet Fragmentation
Application Firewall
For HTTP
For IM
Apply the rule inbound to the inside interface or outbound to the outside interface.
Configure audit trails and logging.
SNRS v2.05-6
Configuring Cisco IOS classic firewall can be simple or as complex as the security
requirements of the network requires. There are several basic tasks required to configure IOS
classic firewall.
To configure Cisco IOS classic firewall, you must perform the following tasks:
1. Determine the internal, external, and demilitarized zone (DMZ) interface (or interfaces).
2. Identify traffic allowed out of the network.
3. Configure ACLs on the interface (or interfaces).
4. Define the inspection rules.
5. Apply the inspection rule to an interface.
6. Configure logging and audit trails.
One configuration is the least complex, offering the easiest configuration, requiring little
knowledge of network usage patterns, but offering little network use control. The other
configuration is the preferred application of Cisco IOS SPI, offering better network policy
control and tighter security, but requiring a better grasp of network protocol usage. These tasks
will be examined in the following sections.
5-31
Configuring IP ACLs for Cisco IOS Classic

Firewall
This topic describes how to configure IP ACLs for Cisco IOS classic firewall.
Configuring IP Access Lists

Start with a basic configuration
Permit Cisco IOS classic firewall traffic to leave the network
Use extended ACLs to deny Cisco IOS classic firewall return
traffic entering the network
SNRS v2.05-7
For Cisco IOS classic firewall to work properly, you need to make sure that you have IP ACLs
configured appropriately and applied at the appropriate interfaces.
Follow these three general rules when evaluating your IP ACLs at the firewall:
Start with a basic configuration: 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.
Permit Cisco IOS classic firewall traffic to leave the network through the firewall: All
ACLs that evaluate traffic leaving the protected network should permit traffic that will be
inspected by Cisco IOS classic firewall. For example, if HTTP will be inspected by Cisco
IOS classic firewall, HTTP traffic should be permitted on all ACLs that apply to traffic
leaving the network.
Use extended ACLs to deny Cisco IOS classic firewall return traffic entering the
network through the firewall: For temporary openings to be created in an ACL, the ACL
must be an extended ACL. So wherever you have ACLs that will be applied to returning
traffic, you must use extended ACLs. The ACLs should deny Cisco IOS classic firewall
return traffic because Cisco IOS classic firewall will open up temporary holes in the ACLs.
(You want traffic to be normally blocked when it enters your network.)
Note
5-32
If your firewall only has two connections, one to the internal network and one to the external
network, using all inbound ACLs on the external interface works well. This is because
packets are stopped before they get a chance to affect the router itself.
Basic ACL Configuration

The first time you configure the Cisco IOS Firewall, it is helpful to start with a basic ACL
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.
Note
Any firewall configuration depends on your company security policy.
Use the following guidelines for configuring the initial firewall ACLs:
Do not configure an ACL for traffic from the protected networks to the unprotected
networks (meaning that all traffic from the protected networks can flow through the
interface).
This helps to simplify firewall management by reducing the number of ACLs 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 ACL configuration and the operation of the firewall.
Configure an ACL that includes entries permitting certain ICMP traffic from unprotected
networks.
While an ACL that denies all IP traffic not part of a connection inspected by Cisco IOS
classic firewall 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, if ICMP
traffic is not inspected by Cisco IOS classic firewall (meaning specific entries are needed in
the ACL 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 ACL that permit echo-reply messages, the user on the protected
network gets no response to the ping command.
Include ACL entries to permit the following ICMP messages:
Echo reply: Outgoing ping commands require echo-reply messages to come back.
Time-exceeded: Outgoing traceroute commands require time-exceeded messages

to come back.
Packet-too-big: Path maximum transmission unit (MTU) discovery requires packettoo-big messages to come back.
Traceroute: An ICMP traceroute message allows an incoming traceroute.
Unreachable: ICMP unreachable messages permit all unreachable messages to

come back. If a router cannot forward or deliver a datagram, it sends an ICMP
unreachable message back to the source and drops the datagram.
Add an ACL entry denying any network traffic from a source address matching an address
on the protected network.
Note
This is known as antispoofing protection because it prevents traffic from an unprotected

network from assuming the identity of a device on the protected network.
5-33
Add an entry denying broadcast messages with a source address of 255.255.255.255. This
entry helps to prevent broadcast attacks.
By default, the last entry in an extended ACL is an implicit denial of all IP traffic not
specifically allowed by other entries in the ACL.
External Interface ACL

Follow these guidelines for your ACLs when you will be configuring Cisco IOS classic firewall
on an external interface:
If you have an outbound IP ACL at the external interface, the ACL can be a standard or
extended ACL. This outbound ACL should permit traffic that you want to be inspected by
Cisco IOS classic firewall. If traffic is not permitted, it will not be inspected by Cisco IOS
classic firewall, but will be simply dropped.
The inbound IP ACL at the external interface must be an extended ACL. This inbound
ACL should deny traffic that you want to be inspected by Cisco IOS classic firewall. (Cisco
IOS classic firewall will create temporary openings in this inbound ACL as appropriate to
permit only return traffic that is part of a valid, existing session.)
Internal Interface ACL

Follow these guidelines for your ACLs when you will be configuring Cisco IOS classic firewall
on an internal interface:
5-34
If you have an inbound IP access list at the internal interface (or an outbound IP access list
at external interface(s), these access lists can be either a standard or extended access list.
These access lists should permit traffic that you want to be inspected by IOS Classic
Firewall. If traffic is not permitted, it will not be inspected by IOS Classic Firewall, but will
be simply dropped.
The outbound IP access list at the internal interface (or an inbound IP access list at the
external interface) must be extended access lists. These access lists should deny traffic that
you want to be inspected by IOS Classic Firewall. IOS Classic Firewall will create
temporary openings in these outbound access lists as appropriate to permit only return
traffic that is part of a valid, existing session.) You do not necessarily need to configure an
extended access list at both the outbound internal interface and the inbound external
interface, but at least one is necessary to restrict traffic flowing through the firewall into the
internal protected network.

This topic describes how to create inspection rules.

Global Timeouts and Thresholds
Configure Generic TCP and UDP Inspection
Configure application layer protocol inspection
Configure Java blocking
Configure IP packet fragmentation inspection
SNRS v2.05-8
After you configure global timeouts and thresholds, you must define an inspection rule. The
inspection rule specifies which IP traffic (which application layer protocols) will be inspected
by Cisco IOS classic firewall at an interface.
Normally, you define only one inspection rule. The only exception might occur if you want to
enable Cisco IOS classic firewall in two directions as described earlier in the When and Where
to Configure Cisco IOS Classic Firewall subtopic. For Cisco IOS classic firewall configured
in both directions at a single firewall interface, you should configure two inspection rules, one
for each direction.
An inspection rule should specify each desired application layer protocol and 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.
5-35
Configuring DoS Protection using Global Timeouts and

Thresholds
This section describes how to configure global timeouts and thresholds as a mitigation
technique for denial-of-service attacks.
Tuning DoS Protection
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
ip
ip
ip
ip
ip
ip
ip
ip
ip
inspect
inspect
inspect
inspect
inspect
inspect
inspect
inspect
inspect
max-incomplete high 300

max-incomplete low 50
one-minute high number
one-minute low number
tcp synwait-time 60
tcp finwait-time 60
tcp idle-time 360
udp idle-time 360
dns-timeout 300
SNRS v2.05-9
Cisco IOS Stateful Packet Inspection maintains counters of the number of "half-open" TCP
connections, as well as the total connection rate through the firewall and IPS software. These
half-open connections are TCP connections that have not completed the SYN-SYN/ACK-ACK
handshake that is always used by TCP peers to negotiate the parameters of their mutual
connection. Cisco IOS Firewall also regards UDP sessions with traffic in only one direction as
"half-open", as nearly all applications that use UDP for transport will acknowledge reception of
data. UDP sessions without acknowledgement are likely indicative of DoS activity, or attempts
to connect between two hosts where one of the hosts has become unresponsive. Some malicious
individuals write worms or viruses that infect multiple hosts on the Internet, then attempt to
overwhelm specific Internet servers with a SYN attack, in which large numbers of SYN
connections are sent to a server by multiple hosts on the public Internet or within an
organization's private network. SYN attacks represent a hazard to Internet servers, as servers'
connection table can be loaded with "bogus" SYN connection attempts that arrive faster than
the server can deal with the new connections. This is called a "Denial-of-Service" attack, as the
large number of connections in the victim server's TCP connection list prevents legitimate users
from gaining access to the victim Internet servers.
Cisco IOS Stateful Packet Inspection provides protection from DoS attack as a default when an
inspection rule is applied. The DoS protection is enabled on the interface, in the direction in
which the firewall is applied, for the protocols that the firewall policy is configured to inspect.
DoS protection is only enabled on network traffic if the traffic enters or leaves an interface with
inspection applied in the same direction of the traffic's initial movement. Cisco IOS Firewall
inspection provides several adjustable values to protect against DoS attacks. These settings
5-36
have default values that may interfere with proper network operation if they are not configured
for the appropriate level of network activity in networks where connection rates will exceed the
defaults:
ip inspect max-incomplete high value (default 500)
ip inspect max-incomplete low value (default 400)
ip inspect one-minute high value (default 500)
ip inspect one-minute low value (default 400)
ip inspect tcp max-incomplete host value (default 50) [block-time minutes (default 0)]
These parameters allow you to configure the points at which your firewall router's DoS
protection begins to take effect. When your router's DoS counters exceed the default or
configured values, the router will reset one old half-open connection for every new connection
that exceeds the configured max-incomplete or one-minute high values, until the number of
half-open sessions drops below the max-incomplete low values. The router will send a syslog
message if logging is enabled, and if Intrusion Protection System (IPS) is configured on the
router, the firewall router will send a DoS signature message via SDEE. If the DoS parameters
are not adjusted to your network's normal behavior, normal network activity may trigger the
DoS protection mechanism, causing application failures, poor network performance, and high
CPU utilization on the Cisco IOS Firewall router.
While you cannot "disable" your firewall's DoS protection, you can adjust the DoS protection
so that it will not take effect unless a very large number of half-open connections are present in
your firewall router's Stateful Inspection session table.
This topic also discusses how to configure the following global timeouts and thresholds:
TCP SYN and FIN wait times
TCP, UDP, and DNS idle times
TCP SYN flood DoS protection
Cisco IOS classic firewall 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 Cisco IOS classic firewall.
Use the ip inspect tcp synwait-time global configuration command to define how long the
software will wait for a TCP session to reach the established state before dropping the session.
Use the no form of this command to reset the timeout to the default.
The syntax of the ip inspect tcp synwait-time command is as follows:
ip inspect tcp synwait-time seconds
5-37
Syntax Description
seconds
Specifies how long the software will wait for a TCP session to
reach the established state before dropping the session; the
default is 30 seconds.
Use the ip inspect tcp finwait-time global configuration command to define how long a TCP
session will continue to be managed after the firewall detects a FIN exchange. Use the no form
of this command to reset the timeout to default.
The syntax of the ip inspect tcp finwait-time command is as follows:
ip inspect tcp finwait-time seconds
Syntax Description
seconds
Specifies how long a TCP session will be managed after the

firewall detects a FIN exchange; the default is 5 seconds.
Use the ip inspect tcp idle-time global configuration command to specify the TCP idle timeout
(the length of time that a TCP session will continue to be managed when there is no activity).
Use the no form of this command to reset the timeout to the default.
Use the ip inspect udp idle-time global configuration command to specify the UDP idle
timeout (the length of time that a UDP session will continue be managed when there is no
activity). Use the no form of this command to reset the timeout to the default.
The syntax for the ip inspect {tcp | udp} idle-time commands is as follows:
ip inspect {tcp | udp} idle-time seconds
Syntax Description
seconds
Specifies the length of time that a TDP or a UDP session will

continue to be managed when there is no activity; for TCP
sessions, the default is 3600 seconds (1 hour); for UDP sessions,
the default is 30 seconds.
Use the ip inspect dns-timeout global configuration command to specify the DNS idle timeout
(the length of time that a DNS name lookup session will still be managed after no activity). Use
the no form of this command to reset the timeout to the default.
The syntax for the ip inspect dns-timeout command is as follows:
router(config)# ip inspect dns-timeout seconds
Syntax Description
seconds
5-38
Specifies the length of time that a DNS name lookup session will
continue to be managed when there is no activity; the default is 5
seconds.
Half-Open Sessions
An unusually high number of half-opened sessions (either absolute or measured as the arrival
rate) could indicate that a DoS attack is occurring. For TCP, half-opened means that the session
has not reached the established statethe TCP three-way handshake has not yet been
completed. For UDP, half-opened means that the firewall has detected no return traffic.
Cisco IOS classic firewall measures both the total number of existing half-opened sessions and
the rate of session establishment attempts. Both TCP and UDP half-opened sessions are
counted in the total number and rate measurements. Measurements are made once a minute.
When the number of existing half-opened sessions rises above a threshold (set by the maxincomplete high number command), Cisco IOS classic firewall will go into aggressive mode
and delete half-opened sessions as required to accommodate new connection requests. The
software continues to delete half-opened requests as necessary, until the number of existing
half-opened sessions drops below another threshold (set by the max-incomplete low number
command).
Use the ip inspect max-incomplete high command in global configuration mode to define the
number of existing half-opened sessions that will cause the software to start deleting halfopened sessions. Use the no form of this command to reset the threshold to the default.
The syntax for the ip inspect max-incomplete high command is as follows:
ip inspect max-incomplete high number
Syntax Description
high number
Specifies the number of existing half-opened sessions that will

cause the software to start deleting half-opened sessions; the
default is 500 half-opened sessions.
Use the ip inspect max-incomplete low command in global configuration mode to define the
number of existing half-opened sessions that will cause the software to stop deleting halfopened sessions. Use the no form of this command to reset the threshold to the default.
The syntax for the ip inspect max-incomplete low command is as follows:
ip inspect max-incomplete low number
Syntax Description
low number

cause the software to stop deleting half-opened sessions; the
When the rate of new connection attempts rises above a threshold (set by the one-minute high
number command), the software will delete half-opened sessions as required to accommodate
new connection attempts. The software continues to delete half-opened sessions as necessary,
until the rate of new connection attempts drops below another threshold (set by the one-minute
low number command). The rate thresholds are measured as the number of new session
connection attempts detected in the most recent one-minute sample period. The firewall router
reviews the one-minute rate on an ongoing basis. This means that the router reviews the rate
more frequently than once a minute and that it does not keep deleting half-opened sessions for
1 minute after a DoS attack has stoppedit will be less time.
5-39
Use the ip inspect one-minute high command in global configuration mode to define the rate
of new unestablished sessions that will cause the software to start deleting half-opened
sessions. Use the no form of this command to reset the threshold to the default.
The syntax for the ip inspect one-minute high command is as follows:
ip ip inspect one-minute high number [vrf vrf-name]
Syntax Description
high number
Specifies the rate of new unestablished TCP sessions that will

cause the software to start deleting half-opened sessions; the
Use the ip inspect one-minute low command in global configuration mode to define the rate of
the new unestablished TCP sessions that will cause the software to stop deleting half-opened
sessions. Use the no form of this command to reset the threshold to the default.
The syntax for the ip inspect one-minute low command is as follows:
ip inspect one-minute low number
Syntax Description
low number
5-40

cause the software to stop deleting half-opened sessions; the
Half-Opened Connection Limits by Host

router(config)#
ip inspect tcp max-incomplete host number block-time

minutes
This command defines the number of half-opened TCP sessions with the
same host destination address that can exist at a time before the Cisco
IOS classic firewall starts deleting half-open sessions to the host.
After the number of half-opened connections to a given host is exceeded,
the software deletes half-opened sessions on that host in the following
manner:
If the block time is 0, the oldest half-opened session is deleted, per
new connection request, to allow new connections.
If the block time is greater than 0, all half-opened sessions are
deleted, and new connections to the host are not allowed during the
specified block time.
SNRS v2.05-10
An unusually high number of half-opened sessions with the same destination host address could
indicate that a DoS attack is being launched against the host. Whenever the number of halfopened sessions with the same destination host address rises above a threshold (set by the maxincomplete host number command), the software will delete half-opened sessions according to
one of the following methods:
If the timeout set by the block-time minutes command is 0 (the default), the software
deletes the oldest existing half-opened session for the host for every new connection
request to the host. This process ensures that the number of half-opened sessions to a given
host will never exceed the threshold.
If the timeout set by the block-time minutes command is greater than 0, the software
deletes all existing half-opened sessions for the host and then blocks all new connection
requests to the host. The software will continue to block all new connection requests until
the block time expires.
The software also sends syslog messages whenever the value specified by the max-incomplete
host number command is exceeded, and when blocking of connection initiations to a host starts
or ends.
The global values specified for the threshold and blocking time apply to all TCP connections
inspected by Cisco IOS classic firewall.
Use the ip inspect tcp max-incomplete host global configuration command to specify
threshold and blocking time values for TCP host-specific DoS detection and prevention. Use
the no form of this command to reset the threshold and blocking time to the default values.
5-41
The syntax for the ip inspect tcp max-incomplete host command is as follows:
ip inspect tcp max-incomplete host number block-time minutes
Syntax Description
host number
Specifies how many half-opened TCP sessions with the same

host destination address can exist at a time before the
software starts deleting half-opened sessions to the host; use
a number from 1 to 250 (the default is 50 half-opened
sessions).
block-time minutes
Specifies how long the software will continue to delete new

connection requests to the host; the default is 0 minutes.
All the available Cisco IOS classic firewall timeouts and thresholds are listed in Timeout and
Threshold Values table, along with the corresponding command and default value.
5-42
Timeout and Threshold Values

Command
Timeout or Threshold Value
Default Value
ip inspect tcp synwait-time seconds
The length of time that the software

waits for a TCP session to reach the
established state before dropping
the session
30 seconds
ip inspect tcp finwait-time seconds
The length of time that a TCP

session will still be managed after
the firewall detects a FIN exchange
5 seconds
ip inspect tcp idle-time seconds
The length of time that a TCP

session will still be managed after no
1
activity (the TCP idle timeout)
3600 seconds (1
hour)
ip inspect udp idle-time seconds
The length of time that a UDP

session will still be managed after no
1
activity (the UDP idle timeout)
30 seconds
ip inspect dns-timeout seconds
The length of time that a DNS name

lookup session will still be managed
after no activity
5 seconds
ip inspect max-incomplete high

number
The number of existing half-open

sessions that will cause the software
2
to start deleting half-open sessions
500 existing halfopen sessions
ip inspect max-incomplete low

number

sessions that will cause the software
to stop deleting half-open sessions2
400 existing halfopen sessions
ip inspect one-minute high number
The rate of new sessions that will

cause the software to start deleting
half-open sessions2
500 half-open
sessions per minute
ip inspect one-minute low number
The rate of new sessions that will

cause the software to stop deleting
2
half-open sessions
400 half-open
sessions per minute
ip inspect tcp max-incomplete host

number block-time minutes

TCP sessions with the same
destination host address that will
cause the software to start dropping
half-open sessions to the same
destination host address3
50 existing half-open
TCP sessions; 0
minutes
1 The global TCP and UDP idle timeouts can be overridden for the sessions of specified application layer protocols'.
2 See the section on half-open sessions in this lesson.
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 nonzero 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.
5-43
Inspection Rules for Generic TCP and

UDP Inspection
router(config)# ip inspect name FWRULE tcp alert on audit-trail on

timeout 300
router(config)# ip inspect name FWRULE udp alert on audit-trail on
timeout 300
SNRS v2.05-11
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 from the previous exiting packet.
Generic TCP and UDP Inspection

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.
With TCP and UDP inspection, packets entering the network must exactly match an existing
session: the entering packets must have the same source or destination addresses and source or
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.)
GPI allows you to specify TCP or UDP ports by using the PAM table. This eliminates having
to inspect all applications running under TCP or UDP and the need for multiple ACLs to filter
the traffic.
Using the PAM table, you simply pick an existing application or define a new one for
inspection thereby simplifying ACL configuration.
5-44
Use the ip inspect inspection-name TCP|UDP command to do general TCP and UDP
inspection.
ip inspect name inspection-name {TCP | UDP} [alert {on | off}] [audittrail {on | off}][router-traffic][timeout seconds]
Syntax Description
router-traffic
(Optional) Enables inspection of traffic destined to or originating from a

router
This enables the firewall to perform generic TCP and UDP inspection without getting too
granular with the inspection rule.
One of the most beneficial features of Cisco IOS classic firewall is that it can do layer 7
application layer inspection.
Application Layer Protocol Inspection

To define a set of inspection rules, enter the ip inspect name command for each protocol that
you want the Cisco IOS classic firewall to inspect, using the same inspection name. Give each
set of inspection rules a unique inspection name, which should not exceed the 16-character
limit. Define either one or two sets of rules per interfaceyou can define one set to examine
both inbound and outbound traffic, or you can define two sets: one for outbound traffic and one
for inbound traffic.
To define a single set of inspection rules, configure inspection for all the desired application
layer protocols, and for ICMP, TCP, and UDP, or as desired. This combination of TCP, UDP,
and application layer protocols join together to form a single set of inspection rules with a
unique name. (There are no application layer protocols associated with ICMP.) For HTTP
inspection, you can also optionally configure Java applet blocking.
Cisco IOS classic firewall 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. Noninitial fragments are discarded unless the
corresponding initial fragment was permitted to pass through the firewall. Noninitial fragments
received before the corresponding initial fragments are discarded.
To remove the inspection rule for a protocol, use the no form of this command with the
specified inspection name and protocol; to remove the entire set of inspection rules, use the no
form of this command only; that is, do not list any inspection names or protocols.
5-45
The syntax for the ip inspect name command is as follows:

ip inspect name inspection-name [parameter max-sessions number]
protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Syntax Description
This argument names the set of inspection rules. If you want to
add a protocol to an existing set of rules, use the same
inspection name as the existing set of rules.
inspection-name
The inspection name cannot exceed 16 characters; otherwise,

the name will be truncated to the 16-character limit.
parameter max-sessions
number
(Optional) This command limits the number of established

firewall sessions that a firewall rule creates. The default is that
there is no limit to the number of firewall sessions.
protocol
This is the protocol to inspect (listed in the Application Layer

Protocol Keyword Examples table).
alert {on | off}
(Optional) For each inspected protocol, the generation of alert

messages can be set to on or off. If no option is selected,
alerts are generated on the basis of the setting of the ip
inspect alert-off command.
audit-trail {on | off}
(Optional) For each inspected protocol, the audit-trail option

can be set to on or off. If no option is selected, audit trail
messages are generated based on the setting of the ip inspect
audit trail command.
timeout seconds
Optional) To override the global TCP or UDP, or ICMP idle

timeouts for the specified protocol, specify the number of
seconds for a different idle timeout.
This timeout overrides the global TCP, UDP, or ICMP timeouts
but will not override the global DNS timeout.
In general, if you configure inspection for an application layer protocol, packets for that
protocol should be permitted to exit the firewall (by configuring the correct ACL), and packets
for that protocol will only be allowed back in through the firewall if they belong to a valid
existing session. Each protocol packet is inspected to maintain information about the session
state.
Following are the protocol keywords for application-layer protocols.
Application Layer Protocol Keyword Examples
5-46
Keyword
Protocol
appfw
Application firewall
cuseeme
CUseeMe
smtp | esmtp
SMTP or ESMTP
ftp
FTP
imap
Internet Message Access Protocol (IMAP)
http
Java
h323
H.323
netshow
Microsoft NetShow
pop3
Post Office Protocol version 3 (POP3)
realaudio
RealAudio
rpc
RPC
sip
SIP
Smtp | esmtp
SMTP or ESMTP
skinny
Skinny Client Control Protocol (SCCP)
streamworks
StreamWorks
sqlnet
SQL*Net
tftp
TFTP
rcmd
UNIX r commands (rlogin, rexec, rsh)
vdolive
VDOLive
user-10
Represents a user-defined application in the port-to-application

mapping (PAM) table of the ip port-map command.
Note
All applications that appear under the show ip port-map command are supported.
HTTP Inspection Syntax

Use this syntax for HTTP inspection configuration.
ip inspect name inspection-name http [java-list access-list]
[urlfilter] [alert {on | off}] [audit-trail {on | off}] [timeout
seconds]
Syntax Description
http
Specifies the HTTP protocol for Java applet blocking
java-list access-list
(Optional) Specifies the numbered standard ACL to use to

determine "friendly" sites
This keyword is available only for the HTTP protocol, for Java
applet blocking. Java blocking only works with numbered
standard ACLs.
urlfilter
(Optional) Associates URL filtering with HTTP inspection
SMTP and ESMTP Inspection Syntax

Use this syntax for SMTP and ESMTP inspection configuration.
ip inspect name inspection-name {smtp | esmtp} [alert {on | off}]
[audit-trail {on | off}] [max-data number] [timeout seconds]
Syntax Description
smtp | esmtp
Specifies the protocol being used to inspect the traffic
max-data number
(Optional) Specifies the maximum number of bytes (data) that

can be transferred in a single SMTP session
After the maximum value is exceeded, the firewall logs an alert
message and closes the session. The default value is 20 MB.
5-47
Fragment Inspection Syntax

Use this syntax for fragment inspection.
fragment [max number timeout seconds]
Syntax Description
fragment
This keyword specifies fragment inspection for the named rule.
max number
(Optional) This command specifies the maximum number of

unassembled packets for which state information (structures) is
allocated by Cisco IOS Software. Unassembled packets are
packets that arrive at the router interface before the initial
packet for a session. The acceptable range is 50 through
10,000. The default is 256 state entries.
Memory is allocated for the state structures, and setting this
value to a larger number may cause memory resources to be
exhausted.
timeout seconds
(fragmentation)
(Optional) This command configures the number of seconds

that a packet state structure remains active. When the timeout
value expires, the router drops the unassembled packet,
freeing that structure for use by another packet. The default
timeout value is 1 second.
If this number is set to a value greater that 1 second, it is
automatically adjusted by the Cisco IOS Software when the
number of free state structures goes below certain thresholds.
When the number of free states is fewer than 32, the timeout is
divided by 2. When the number of free states is fewer than 16,
the timeout is set to 1 second.
Session Limiting Syntax

Use this syntax for to limit maximum firewall sessions.
Syntax Description
parameter max-sessions
number
(Optional) Limits the number of established firewall sessions

that a firewall rule creates
The default is that there is no limit to the number of firewall
sessions.
User-Defined Application Syntax

Use this syntax to point to a user defined application in the PAM table.
ip inspect name inspection-name user-10 [alert {on | off}] [audittrail {on | off}] [timeout seconds}
Syntax Description
user-10
5-48
Represents a user-defined application in the Port-to-Application

Mapping (PAM) table of the ip port-map command
Java Blocking
This section covers Java blocking.
Inspection Rules for Java

Router(config)#
ip inspect name inspection-name http java-list
acl-num [alert {on|off}] [audit-trail {on|off}]
[timeout seconds]
Controls Java blocking with a standard ACL
Router(config)# ip access-list 10 deny 172.26.26.0
0.0.0.255
Router(config)# ip access-list 10 permit 172.27.27.0
0.0.0.255
Router(config)# ip inspect name FWRULE http java-list
10 alert on audit-trail on timeout 300
SNRS v2.05-14
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.)
To block all Java applets except for applets from friendly locations, use the following
commands in global configuration mode:
Step 1
Create a standard ACL of permitted or restricted sites.

access-list access-list-number {deny | permit} protocol source
[source-wildcard]eq protocol destination [destinationwildcard]
Step 2
Apply the Java blocking rule.

ip inspect name inspection-name http [java-list access-list]
[alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Note
Cisco IOS classic firewall does not detect or block encapsulated Java applets. Therefore,
Java applets that are wrapped or encapsulated, such as applets in .zip or .jar format, are not
blocked at the firewall. Cisco IOS classic firewall also does not detect or block applets
loaded from FTP, Gopher, HTTP on a nonstandard port, and so forth.
5-49
Note
Java blocking forces a strict order on TCP packets. To properly verify that Java applets are
not in the response, a firewall will drop any TCP packet that is out of order. Because the
networknot the firewalldetermines how packets are routed, the firewall cannot control
the order of the packets; the firewall can only drop and retransmit all TCP packets that are
not in order.
IP Packet Fragmentation Inspection

Cisco IOS classic firewall 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. Noninitial fragments are discarded unless the corresponding initial fragment was
permitted to pass through the firewall. Noninitial fragments received before the corresponding
initial fragments are discarded.
Because routers running Cisco IOS Software are used in a large variety of networks, and
because the Cisco IOS classic firewall 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 fragment state resources of the firewall, and legitimate,
unfragmented traffic can flow through the firewall unimpeded.
5-50
Example Configurations
This topic describes example firewall configurations for two different topologies.
Basic Topology
Internal
Network
External
Network
E0
S0
Internet
Traffic Entering
Traffic
Exiting
SNRS v2.05-15
The complexity of configurations depend on the topology and security requirements of the
network. Topologies range from simple two interface networks to multiple interfaces with a
DMZ and extranets to remote partners and branch offices. The firewall is most commonly used
with one of two basic network topologies.
If you will be configuring IOS Classic Firewall in two directions, you should configure IOS
Classic Firewall in one direction first, using the appropriate "internal" and "external" interface
designations. When you configure IOS Classic Firewall in the other direction, the interface
designations will be swapped.
"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).
Note
IOS Classic Firewall can be configured in two directions at one or more interfaces. Configure
IOS Classic Firewall 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.
Use the sample topologies in this section to decide whether to configure IOS Classic Firewall
on an internal or external interface.
In the figure above, IOS Classic Firewall would be configured for the external interface Serial
0. 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.
5-51
Simple Two Interface Configuation

R1(config)# access-list 101 deny ip any any
R1(config)# ip inspect name SNRSFW tcp
R1(config)# ip inspect name SNRSFW udp
R1(config)# ip inspect name SNRSFW icmp
Apply ACL to Outside interface.
R1(config)# interface fastEthernet 0/1
R1(config-if)# ip access-group 101 in
Apply rule:
Outbound to the Outside interface
R1(config-if)# ip inspect SNRSFW out
OR
Inbound to the Inside interface.
R1(config-if)# ip inspect SNRSFW in
Deny all traffic from

outside network
Inspect TCP,
UDP, and ICMP
SNRS v2.05-16
This is an example of the simplest configuration for a two interface firewall. Notice that there is
no ACL controlling what traffic exits the network.
This least complex SPI configuration uses a "deny any" ACL facing the unsecure network, and
offers limited capability to restrict network usage to a limited application list. This prevents
hosts on the unsecure network from sending traffic to the secure network, but also blocks return
traffic on legitimate, internally originated connections. To facilitate the return of legitimate
traffic, you will need to configure a simple inspection set and apply it to inbound traffic on the
internal interface, or to the outbound traffic on the external interface.
Most Internet traffic can be inspected by "inspect tcp", "inspect udp", and "inspect icmp". This
permits the most common Internet traffic, including Web browsing, e-mail applications, file
transfer, remote-console and remote-desktop applications, instant messaging, and peer-to-peer
file transfer applications. Certain applications that use a secondary data channel, such as voice
applications or streaming media applications, may require that you configure the protocolspecific inspection for that particular service, such as "inspect ftp", "inspect skinny", or "inspect
h.323". If you set up Cisco IOS Stateful Inspection and find that one of your network
applications that must traverse the firewall stops working, you should consult the product's
documentation or knowledgebase and determine if the software vendor offers documentation
specific to setting up a Cisco IOS Firewall.
5-52
Topology with DMZ

Internal
Network
External
Network
Internet
E0
S0
Traffic Entering
Access Allowed to DMZ
DMZ
Traffic Exiting
DNS
Server
Web
Server
SNRS v2.05-17
In this figure and in the examples below, IOS Classic Firewall is configured for the internal
interface Ethernet 0, a DMZ interface E1, and an external interface (S1). This allows external
traffic to access the services in the DMZ, such as HTTP or DNS services, but prevents
specified protocol traffic from entering the internal network - unless the traffic is part of a
session initiated from within the internal network.

5-53
Three Interface Configuration with DMZ

router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
inspect
inspect
inspect
inspect
inspect
inspect
inspect
inspect
inspect
inspect
inspect
inspect
name
name
name
name
name
name
name
name
name
name
name
name
IN_to_OUT
IN_to_OUT
IN_to_OUT
IN_to_OUT
IN_to_OUT
IN_to_OUT
IN_to_OUT
OUT_to_IN
OUT_to_IN
OUT_to_IN
OUT_to_IN
OUT_to_IN
smtp
ftp
tcp
udp
sqlnet
realaudio
h323
tcp
ftp
vdolive
netshow
h323
IN_to_OUT is configured for traffic destined for the internet or the DMZ.
Inspection is configured inbound on the inside interface (Fa0/0)
OUT_to_IN is setup for traffic heading from the internet. This traffic can
go ONLY to the DMZ. Inspection is configured inbound on the outside
interface (S0)
SNRS v2.05-18
The example above specifies the protocols to be inspected using two different inspection rules
that will be applied to two interfaces.
The IN_to_OUT inspection rule instructs the firewall to inspect smtp, ftp, tcp, usdp, sqlnet,
realausdio, and H323 coming from the internal network that is exiting.
The OUT_to_IN inspection rule will inspect traffic coming from the Internet and bound for the
DMZ.
5-54
Three Interface Configuration with DMZ (Cont.)

router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
101
111
112
112
112
112
112
121
121
121
121
121
deny ip any any

permit udp host 192.168.1.11 any
permit tcp any host 192.168.1.12
eq
eq
eq
eq
eq
eq
eq
eq
eq
eq
eq
domain
www
ftp
smtp
1755
1720
www
ftp
smtp
1755
1720
ACL 101 locks down traffic heading to the inside.

ACL 111 permits DNS requests from the DNS server on the DMZ.
ACL 112 permits internet traffic inspected by the firewall destined
to the DMZ.
ACL 121 corresponds to acl 112. it allows internet traffic inspected
by the firewall to the server on the DMZ.
SNRS v2.05-19
The example above defines the access lists that will be applied to the appropriate interfaces to
control access in and out of the network.
Note the following:
ACL 101 is usually called the lock down ACL because it should deny all traffic that is
not being inspected to enter the network. ACL 101 will be applied to the internal interface
in the outbound direction in this case.
ACL 111 is applied to the DMZ interface in the inbound direction. ACL 111 allows DNS
traffic from the web server in the DMZ to the Internet.
ACL 112 is applied to the DMZ interface in the outbound direction. ACL 112 allows traffic
from the Internet to the DMZ.
ACL 121 is applied to inbound traffic on the outside interface (s0/0). ACL 121 corresponds
to acl 112, it allows internet traffic inspected by the firewall to the server on the DMZ.

5-55
Three Interface Configuration with DMZ (Cont.)

Fa0/0 is the inside interface to the Corp network.
router(config)# interface fastEthernet0/0
router(config-if)# ip address 10.0.1.2 255.255.255.0
router(config-if)# ip inspect IN_to_OUT in
Lock-down
ACL
firewall inspection
for internally
generated traffic
S0/0 is the interface closest to the internet. The outside

interface.
router(config)# interface Serial0
router(config-if)# ip address 172.30.1.2 255.255.255.0 allows internet
initiated traffic
router(config-if)# ip inspect OUT_to_IN in
firewall inspection for traffic
coming from the internet
Fa0/1 is the DMZ interface.

DNS traffic
allows specific traffic to

the DMZ server.
SNRS v2.05-20
The two inspection rules and all of the ACLs are applied to the appropriate interfaces in the
example above.
Note the following:
5-56
Interface Fa0/0 (the inside interface) has ACL 101 applied outbound and the inspection rule
applied inbound.
Interface Serial 0 (the outside interface) has ACL 121 applied inbound from Internet and
the inspection rule also applied inbound.
Interface Fa0/1 (the DMZ interface) has no inspection rule applied but has two ACLs
applied both inbound and outbound to restrict access to and from the Internet and the DMZ.
Application Firewall Policy

This topic describes how to configure an application firewall policy.
Application Firewall
router(config)# appfw policy-name <policy-name>
router(cfg-appfw-policy)# application [http | im {aol|yahoo|msb}]
SNRS v2.05-21
The application firewall uses static signatures to detect security violations. A static signature is
a collection of parameters that specifies which protocol conditions must be met before an action
is taken. (For example, a signature may specify that an HTTP data stream containing the
power-on self-test [POST] method must reset the connection.) These protocol conditions and
reactions are defined by the end user via a command-line interface (CLI) to form an application
firewall policy (also known as a security policy).

5-57
Application Policy for HTTP

This section covers application policy for HHTP.
Application Firewall Policy for HTTP

router(config)# appfw policy-name HTTP-Policy
router(cfg-appfw-policy)# application http
router(cfg-appfw-policy-http)# strict-http action allow alarm
router(cfg-appfw-policy-http)# content-length maximum 1 action allow alarm
router(cfg-appfw-policy-http)# content-type-verification match-req-rsp action
allow alarm
router(cfg-appfw-policy-http)# max-header-length request 1 response 1 action
allow alarm
router(cfg-appfw-policy-http)# max-uri-length 1 action allow alarm
router(cfg-appfw-policy-http)# port-misuse default action allow alarm
router(cfg-appfw-policy-http)# request-method rfc default action allow alarm
router(cfg-appfw-policy-http)# request-method extension default action allow
alarm
router(cfg-appfw-policy-http)# transfer-encoding type default action allow
alarm
router(config)# ip inspect name FW appfw HTTP-Policy
router(config)# ip inspect name FW http
router(config)# interface FastEthernet0/0
router(config-if)# ip inspect firewall in
SNRS v2.05-22
This example shows how to define the HTTP application firewall policy "mypolicy." This
policy includes all supported HTTP policy rules. After the policy is defined, it is applied to the
inspection rule "firewall," which will inspect all HTTP traffic entering the FastEthernet0/0
interface.
HTTP uses port 80 to transport Internet web services that are commonly used on the network
and rarely challenged with regard to their legitimacy and conformance to standards. Because
port 80 traffic is typically allowed through the network without being challenged, many
application developers are leveraging HTTP traffic as an alternative transport protocol in which
to enable their application to travel through or even bypass the firewall.
Most firewalls provide only packet filtering capabilities that simply permit or deny port 80
traffic without inspecting the data stream; the Cisco IOS application firewall for HTTP
performs packet inspection as follows:
Detects HTTP connections that are not authorized within the scope of the security policy
configuration
Detects users who are tunneling other applications through port 80
If the packet is not in compliance with the HTTP protocol, it will be dropped, the connection
will be reset, and a syslog message will be generated, as appropriate.
5-58
HTTP Inspection Engine

The HTTP Inspection Engine feature allows users to configure their Cisco IOS Firewall to
detect and prohibit HTTP connectionssuch as tunneling over port 80, unauthorized request
methods, and non-HTTP compliant file transfersthat are not authorized within the scope of
the security policy configuration. Tunneling unauthorized protocols through port 80 and over
HTTP exposes a network to significant security risks.
The Cisco IOS Firewall can now be configured with a security policy that adheres to the
following tasks:
Allowing specific traffic targeted for port 80 to traverse the firewall: The traffic is
inspected for protocol conformance and for the types of HTTP commands that are allowed
or disallowed.
Denying specific traffic targeted for port 80 that does not comply with HTTP traffic
standards: The firewall is enabled to drop the packet, reset the connection, and send a
syslog message, as appropriate.
HTTP-Specific Inspection Commands

After you issue the application http command and enter the appfw-policy-http configuration
mode, begin configuring inspection parameters for HTTP traffic by issuing any of the
following commands:
audit-trail
content-length
content-type-verification
max-header-length
max-uri-length
port-misuse
request-method
strict-http
timeout
transfer-encoding
Define and Apply an HTTP Application Policy to a Firewall for Inspection

First you must define an HTTP application policy and then you can apply it to a firewall to
inspect traffic.
Defining an HTTP Application Policy

Follow these steps to create an HTTP application firewall policy:
Step 1
Define an application firewall policy and put the router in application firewall policy
configuration mode.
router(config)# appfw policy-name policy-name

5-59
Step 2
Put the router in application firewall protocol configuration and begin configuring
HTTP inspection parameters.
router(cfg-appfw-policy)# application protocol
Syntax Description
protocol
Protocol-specific traffic will be inspected.

One of the following protocols (keywords) can be specified:
Step 3
http: HTTP traffic will be inspected.
im {aol | yahoo | msn}: Traffic for the specified instant messenger application will
be inspected.
Allow HTTP messages to pass through the firewall or to reset the TCP connection or
to generate an alarm when HTTP noncompliant traffic is detected.
router(cfg-appfw-policy-http)# strict-http action {reset |
allow} [alarm]
Syntax Description
action
HTTP messages are subject to the specified action (reset or allow).
reset
This keyword sends a TCP reset notification to the client or server if the HTTP
message fails the mode inspection.
allow
This keyword forwards the packet through the firewall.
alarm
(Optional) This keyword generates system logging (syslog) messages for the
given action.
Step 4
Permit or deny HTTP traffic through the firewall on the basis of message size.
router(cfg-appfw-policy-http)# content-length {min bytes max
bytes | min bytes | max bytes} action {reset | allow} [alarm]
Syntax Description
min bytes
This sets the minimum content length, in bytes, allowed per message. (Number of
bytes range: 0 to 65,535.)
max bytes
This sets the maximum content length, in bytes, allowed per message. (Number
of bytes range: 0 to 65,535.)
action
Messages whose size do not meet the minimum or exceed the maximum number
of bytes are subject to the specified action (reset or allow).
reset
This keyword sends a TCP reset notification to the client or server if the HTTP
message fails the mode inspection.
allow
alarm
given action.
If this command is not enabled, message size is not considered when permitting or denying
HTTP messages.
All messages exceeding the specified content-length range will be subjected to the configured
action (reset or allow).
5-60
Step 5
Permit or deny HTTP traffic through the firewall on the basis of content message
type.
router(cfg-appfw-policy-http)# content-type-verification
[match-req-resp] action {reset | allow} [alarm]
Syntax Description
match-req-resp
(Optional) This command verifies the content type of the HTTP

response against the accept field of the HTTP request.
action
Messages that match the specified content type are subject to the
specified action (reset or allow).
reset
This keyword sends a TCP reset notification to the client or server if

the HTTP message fails the mode inspection.
allow
alarm
(Optional) This keyword generates system logging (syslog)

messages for the given action.
If this command is not issued, all traffic will be allowed.

After the content-type-verification command is issued, all HTTP messages are subjected to
the following inspections:
Step 6
Verify that the content type of the message header is listed as a supported
content type
Verify that the content type of the header matches the content of the message
data or entity body portion of the message
Permit or deny HTTP traffic on the basis of the message header length.
router(cfg-appfw-policy-http)# max-header-length request bytes
response bytes action {reset | allow} [alarm]
Syntax Description
request bytes
This sets the maximum header length, in bytes, allowed in the

request message. (Number of bytes range: 0 to 65,535.)
response bytes
This sets the maximum header length, in bytes, allowed in the

response message. (Number of bytes range: 0 to 65,535.)
action
Messages that exceed the maximum size are subject to the specified
reset
This keyword sends a TCP reset notification to the client or server if

the HTTP message fails the mode inspection.
allow
alarm
(Optional) This keyword generates system logging (syslog)

messages for the given action.
All message header lengths exceeding the configured maximum size will be subjected to the
specified action (reset or allow).
Step 7
Permit or deny HTTP traffic on the basis of the uniform resource identifier (URI)
length in the request message.
router(cfg-appfw-policy-http)# max-uri-length bytes action
{reset | allow} [alarm]

5-61
Syntax Description
bytes
This sets the number of bytes ranging from 0 to 65,535.
action
Messages that exceed the maximum URI length are subject to the specified
reset
This keyword sends a TCP reset notification to the client or server if the
HTTP message fails the mode inspection.
allow
alarm
given action.
If this command is not issued, all traffic is permitted.

All URI lengths exceeding the configured value will be subjected to the specified action (reset
or allow).
Step 8
Permit or deny HTTP traffic according to either the request methods or the extension
methods.
router(cfg-appfw-policy-http)# request-method {rfc rfc-method
| extension extension-method} action {reset | allow} [alarm]
Syntax Description
rfc
This keyword specifies that the supported methods of RFC 2616, Hypertext
Transfer ProtocolHTTP/1.1, are to be used for traffic inspection.
rfc-method
Any one of the following RFC 2616 methods can be specified: connect,
default, delete, get, head, options, post, put, trace.
extension
This keyword specifies that the extension methods are to be used for traffic
inspection.
extension-method
Any one of the following extension methods can be specified: copy, default,
edit, getattribute, getproperties, index, lock, mkdir, move, revadd,
revlabel, revlog, save, setattribute, startrev, stoprev, unedit, unlock.
action
Methods and extension methods outside of the specified method are subject
to the specified action (reset or allow).
reset
allow
alarm
given action.
If a given method is not specified, all methods and extension methods are supported with the
reset alarm action.
Only methods configured by the request-method command are allowed thorough the firewall;
all other HTTP traffic is subjected to the specified action (reset or allow).
Step 9
Permit or deny HTTP traffic through the firewall on the basis of specified
applications in the HTTP message.
router(cfg-appfw-policy-http)# port-misuse {p2p | tunneling |
im | default} action {reset | allow}[alarm]
5-62
Syntax Description
p2p
This keyword sets the following peer-to-peer protocol applications that are
subject to inspection: Kazaa and Gnutella.
tunneling
This keyword sets the following tunneling applications that are subject to
inspection: HTTPPort/HTTPHost, GNU HTTP tunnel, GoToMyPC, FireThru,
Http-tunnel.com Client.
im
This keyword sets the following IM protocol application subject to inspection:

Yahoo Messenger.
default
All applications are subject to inspection.
action
Applications detected within the HTTP messages that are outside of the
specified application are subject to the specified action (reset or allow).
reset
allow
alarm
(Optional) This keyword generates system logging (syslog) messages for

the given action.
If this command is not enabled, HTTP messages are permitted through the firewall if any of the
applications are detected within the message.
Step 10
Permit or deny HTTP traffic according to the specified transfer encoding of the
message.
router(cfg-appfw-policy-http)# transfer-encoding type {chunked
| compress | deflate | gzip | identity | default} action
{reset | allow} [alarm]
Syntax Description
chunked
Encoding format (specified in RFC 2616, Hypertext Transfer ProtocolHTTP/1)

in which the body of the message is transferred in a series of chunks (each chunk
contains its own size indicator)
compress
Encoding format produced by the UNIX compress utility
deflate
ZLIB format defined in RFC 1950, ZLIB Compressed Data Format Specification
version 3.3, combined with the deflate compression mechanism described in RFC
1951, DEFLATE Compressed Data Format Specification version 1.3
gzip
Encoding format produced by the gzip (GNU zip) program
identity
Default encoding (which indicates that no encoding has been performed)
default
All of the transfer encoding types
action
Encoding types outside of the specified type are subject to the specified action
(reset or allow)
reset
Sends a TCP reset notification to the client or server if the HTTP message fails
the mode inspection
allow
Forwards the packet through the firewall
alarm
(Optional) Generates system logging (syslog) messages for the given action
If a given type is not specified, all transfer-encoding types are supported with the reset alarm
action.
Step 11
Specify the elapsed length of time before an inactive connection is torn down. (This
command overrides the global TCP idle timeout value for HTTP traffic).

5-63
router(cfg-appfw-policy-http)# timeout seconds
Syntax Description
seconds
Idle timeout value

The available range is 5 to 43,200 minutes (12 hours).
If this command is not issued, the default value specified via the ip inspect tcp idle-time
command will be used.
Step 12
Turn audit trail messages on or off.
Next Step
After you have successfully defined an application policy for HTTP traffic inspection, you
must apply the policy to an inspection rule. After that, the inspection rule must be applied to an
interface.
Applying an HTTP Application Policy to a Firewall for Inspection

To apply an HTTP application policy to an inspection rule, use the following procedure
followed by applying the inspection rule to an interface:
Step 1
Define a set of inspection rules for the application policy.

router(config)# ip inspect name inspection-name appfw policyname
Syntax Description
appfw
Specifies application firewall provisioning
policy-name
Application firewall policy name

Note: This name must match the name specified via the appfw policy-name
command.
Step 2
Define a set of inspection rules that is to be applied to all HTTP traffic.

router(config)# ip inspect name inspection-name http [alert
{on | off}] [audit-trail {on | off}] [timeout seconds]
After applying the HTTP application policy to an inspection rule, you can apply the rule to an
interface.
5-64
Application Firewall Policy for Instant Messaging (IM)

This section covers application policy for Instant Messaging.
Application Firewall Policy for Instant

Messaging (IM)
router(config)# appfw policy-name IM-Policy
router(cfg-appfw-policy)# application im yahoo
router(cfg-appfw-policy-ymsgr)# server permit name scs.msg.yahoo.com
router(cfg-appfw-policy-ymsgr)# server permit name scsa.msg.yahoo.com
router(cfg-appfw-policy-ymsgr)# server permit name scsb.msg.yahoo.com
router(cfg-appfw-policy-ymsgr)# server permit name scsc.msg.yahoo.com
router(cfg-appfw-policy-ymsgr)# service text-chat action allow
router(cfg-appfw-policy-ymsgr)# service default action reset
router(cfg-appfw-policy-ymsgr)# exit
router(cfg-appfw-policy)# application im aol
router(cfg-appfw-policy-aim)# server deny name login.oscar.aol.com
router(cfg-appfw-policy-aim)# exit
router(cfg-appfw-policy)# application im msn
router(cfg-appfw-policy-msnmsgr)# server deny name
messenger.hotmail.com
router(config)# ip inspect name FW appfw IM-POLICY
router(config-if)# ip inspect FW in
SNRS v2.05-23
This example shows how to configure the application firewall policy "my-im-policy," which
allows text-chat for Yahoo! instant messenger users and blocks instant messenger traffic for all
other users.
The Application Firewall for Instant Message Traffic Enforcement feature enables users to
define and enforce a policy that specifies which instant messaging (IM) traffic types are
allowed into the network. Thus, the following additional functionality can also be enforced:
Configuration of firewall inspection rules
Deep packet inspection of the payload, looking for services such as text chat
Cisco IOS application firewall has been enhanced to support instant native messenger
application policies. Thus, the Cisco IOS Firewall can now detect and prohibit user connections
to IM servers for the AOL Instant Messenger (AIM), Yahoo! Messenger, and MSN Messenger
IM services. This functionality controls all connections for supported services, including text,
voice, video, and file transfer capabilities. The three applications can be individually denied or
permitted. Each service may be individually controlled so that text chat service is allowed, and
voice, file transfer, video, and other services are restricted. This functionality augments existing
application inspection capability to control IM application traffic that has been disguised as
HTTP (web) traffic.
Define and Apply an IM Application Policy to a Firewall for Inspection

First you must define an IM application policy and then you can apply it to a firewall to inspect
traffic.

5-65
Prerequisites
Before defining and enabling an application policy for IM traffic, you must have already
properly configured your router with a DNS server IP address via the ip domain lookup
command and the ip name-server command.
The IP address of the DNS server configured on the Cisco IOS router must be the same as that
configured on all PCs connecting to the IM servers from behind the Cisco IOS Firewall.
Note
If at least one DNS name was not specified for resolution under any of the application
policies for IM protocols (AOL, Yahoo!, or MSN), you do not need to configure the DNS
server IP address in the Cisco IOS router.
Instant Messenger-Specific Inspection Commands

After you issue the application im command and specify an instant messenger application
(AOL, Yahoo, or MSN), you can begin configuring inspection parameters for IM traffic by
issuing any of the following commands:
alert
audit trail
server
service
timeout
Defining an IM Application Policy

Follow these steps to create an HTTP application firewall policy:
Step 1
Define an application firewall policy and put the router in application firewall policy
configuration mode.
router(config)# appfw policy-name policy-name
Step 2
Put the router in application firewall protocol configuration mode and begin
configuring IM inspection parameters.
router(cfg-appfw-policy)# application protocol
Syntax Description
protocol
Protocol-specific traffic will be inspected.

One of the following protocols (keywords) can be specified:
http: HTTP traffic will be inspected.
im {aol | yahoo | msn}: Traffic for the specified IM application will be inspected.
This command puts the router in application firewall protocol configuration mode.
Step 3
Enable message logging for established or torn-down connections.

router(cfg-appfw-policy-aim)# audit-trail {on | off}
If this command is not issued, the default value specified via the ip inspect audit-trail
5-66
Step 4
Specify the access policy to IM servers.

router(cfg-appfw-policy-aim)# server permit name
login.oscar.aol.com
router(cfg-appfw-policy-aim)# server {permit | deny} {name
string | ip-address {ip-address | range ip-address-start ipaddress-end}
Syntax Description
permit
This keyword inspects all traffic destined for a specified server,

and the applicable policy is enforced.
deny
This keyword blocks all traffic destined for a specified, denied

server. TCP connections are denied by dropping all packets
bound to the specified server.
name string
This is the name of DNS server for which traffic will be permitted
(and inspected) or denied.
The same server name cannot appear under two different IM
applications; however, the same name can appear under two
different policies within the same IM application. Each entry will
accept only one DNS name.
ip-address
This command indicates that at least one IP address will be listed.
ip-address
This is the IP address of the DNS server for which traffic will be
permitted (and inspected) or denied.
range ip-address-start
ip-address-end
This is the range of DNS server IP addresses for which traffic will
be permitted (and inspected) or denied.
Note
If this command is not issued, IM application polices cannot be enforced.
The server command helps the IM application engine to recognize the port-hopping IM traffic
and to enforce the security policy for that IM application; thus, if this command is not issued,
the security policy cannot be enforced if IM applications use port-hopping techniques.
To deploy IM traffic enforcement policies effectively, it is recommended that you issue the
appropriate server command.
Note
If a router cannot identify a packet as belonging to a particular IM policy, the corresponding

policy cannot be enforced.
To configure more than one set of servers, you can issue the server command multiple times
within an IM application policy. Multiple entries are treated cumulatively.
The server command (with the name keyword) internally resolves the DNS name of the server.
This command sends DNS queries multiple times to gather all possible IP addresses for the IM
servers, which return different IP addresses at different times in response to DNS queries of the
same names. It uses the Time to Live (TTL) field found in DNS responses to refresh its cache.
After a certain period, the DNS cache in IM applications stabilize.
Note
It is recommended that you allow a couple of minutes for the DNS cache to populate with
the IM server IP addresses before the IM traffic reaches the Cisco IOS Firewall.

5-67
All existing IM application connections are not subjected to IM policy enforcement.
Denying Access to a Particular IM Application

You can deny traffic to a particular IM application in one of the following ways:
Issue the server deny command and list all the server names and IP addresses to which you
want to deny access.
Issue the server permit command and list all the server names and IP addresses that you
want inspected; thereafter, issue the service default reset command, which will deny
access to all services.
Issue the server deny command to block access to any site given its DNS name. For
example, to block all access to a gambling site, you can configure server deny name
www.noaccess.com.
Note
Step 5
The first option is the preferred method because it performs slightly better than the second
option.
(Optional) Specify the elapsed length of time before an inactive connection is torn
down.
router(cfg-appfw-policy-aim)# timeout seconds
Syntax Description
Available timeout range: 5 to 43,200 (12 hours)
seconds
If this command is not issued, the default value specified via the ip inspect tcp idle-time
Note
Step 6
Some IM applications continue to send keepalive-like packets that effectively prevent

timeouts even when the user is idle.
(Optional) Specify an action when a specific service is detected in the IM traffic.

router(cfg-appfw-policy-aim)# service {default | text-chat}
action {allow [alarm] | reset [alarm] | alarm}
Syntax Description
default
Matches all services that are not explicitly configured under the application
Note: It is recommended that when an IM application is allowed, always specify the
default option for the IM application.
text-chat
Controls the text chat service that is provided by IM applications
action
Indicates that a specific action is to follow
allow
Allows a specific service
reset
Blocks the service specified in the configuration

If the default option is being used, only services for which a specific action has been
identified are allowed; all other services are denied.
alarm
5-68
Generates an alarm message when the specified service is encountered over the
connection
If the command is not configured, the default is service default action reset.
If the service default command is not specified for an application, the action is considered
reset by the system.
When the reset keyword is used, the connection is reset if TCP is used, and the packet is
dropped if UDP is used. When dropping a packet from a UDP connection, the session will not
be immediately deleted; instead, the session will time out to prevent additional sessions from
being immediately created.
The alarm keyword can be specified alone or with the allow or reset keywords; however, the
allow or reset keywords are mutually exclusive.
Step 7
(Optional) Enable message logging when events, such as the start of a text chat, begin.
router(cfg-appfw-policy-aim)# alert on
router(cfg-appfw-policy-aim)# alert {on | off}
Syntax Description
on
Enables message logging for IM application policy events
off
Disables message logging for IM application policy events
If this parameter is not configured, the global setting for the ip inspect alert-off command will
take effect.
Next Step
After you have successfully defined an application policy for IM traffic inspection, you must
apply the policy to an inspection rule. After that, the inspection rule must be applied to an
interface.
Applying an IM Traffic Application Policy to a Firewall for Inspection
To apply an HTTP application policy to an inspection rule, use the following procedure
followed by applying the inspection rule to an interface:
Step 1
Define a set of inspection rules for the application policy.

router(config)# ip inspect name inspection-name appfw policyname
Syntax Description
appfw
Specifies application firewall provisioning
policy-name
Application firewall policy name

Note: This name must match the name specified via the appfw policy-name
command.
After applying the IM application policy to an inspection rule, you can apply the rule to an
interface.

5-69
Verifying Application Firewall Configuration

This section describes some commands used to verify your application firewall configuration.
Verifying Application Firewall
router# show appfw configuration

router# show appfw dns cache
router# show appfw policy HTTP-Policy
Displays application firewall policy information
SNRS v2.05-24
Use the following command to display application firewall policy configuration information:
show appfw {configuration | dns cache} [policy policy-name]
Syntax Description
configuration
Displays configuration information for configured policies
dns cache
Displays the IP addresses resolved by the DNS server of the applicable IM

application
policy policy-name
(Optional) Displays information only for the specified policy

If you do not indicate a specific policy via the policy policy-name option, IP
addresses gathered for all DNS names for all policies are displayed.
If no policies are specified, information for all policies is shown.
5-70

This topic describes how to configure GPI.

GPI allows you to configure any port number for an application
protocol.
Cisco IOS classic firewall uses PAM to determine the application
configured for a port.
SNRS v2.05-25
The Cisco IOS Firewall performs inspections for TCP and UDP traffic. For example, TCP
inspections include Telnet traffic (port 23, by default) and all other applications on TCP such as
HTTP, e-mail, M chatter, and so on. Therefore, there is no easy way to inspect Telnet traffic
alone and deny all other TCP traffic.
The GPI feature allows you to specify TCP or UDP ports using the PAM table. As a result, the
Cisco IOS Firewall can restrict traffic inspections to specific applications, thereby permitting a
higher degree of granularity in selecting which protocols are to be permitted and denied.
The ip port-map command associates TCP or UDP port numbers with applications or services,
establishing a table of default port mapping information at the firewall. This information is used
to support network environments that run services using ports that are different from the
registered or well-known ports associated with a service or application.
The port mapping information in the PAM table is of one of three types:
System-defined
User-defined
Host-specific
System-Defined Port Mapping

Initially, PAM creates a set of system-defined entries in the mapping table using well-known or
registered port mapping information set up during the system startup. The Cisco IOS Firewall
CBAC (Cisco IOS classic firewall) feature requires the system-defined port mapping
information to function properly.
5-71
You can delete or modify system-defined port mapping information. Use the no form of the
command for deletion and the regular form of the command to remap information to another
application.
You can also add new port numbers to system-defined applications. However, for some systemdefined applications such as HTTP and SMTP, in which the firewall inspects deeper into
packets, their protocol (UDP or TCP) cannot be changed from that defined in the system. In
those instances, error messages display.
System-Defined Port Mapping Examples
Application Name
Well-Known or
Registered Port
Number
Protocol Description
cuseeme
7648
CUseeMe
exec
512
Remote process execution
ftp
21
FTP (control port)
h323
1720
H.323 (for example, NetMeeting, Intel Video

Phone)
http
80
HTTP
rlogin
513
Remote login
msrpc
135
Microsoft RPC
netshow
1755
Microsoft NetShow
real-audio-video
7070
RealAudio and RealVideo
sccp
2000
SCCP
smtp
25
SMTP
sql-net
1521
SQL*NET
streamworks
1558
StreamWorks
sunrpc
111
SUN RPC
tftp
69
TFTP
vdolive
7000
VDOLive
Note
5-72
You can override system-defined entries for a specific host or subnet using the list acl-num
option in the ip port-map command.
User-Defined Port Mapping

This section describes user-defined port mapping.
Port to Application Mapping

router(config)# ip port-map http port 8080
Maps a port number to an application
router(config)# access-list 110 permit 10.0.1.12

router(config)# ip port-map http port 8080 list 110
Maps a port number to an application for a given host
Host 10.0.1.12 uses port 8080 for http services
router(config)# access-list 110 permit 10.0.1.0 0.0.0.255

router(config)# ip port-map http port 8080 list 110
Maps a port number to an application for a given network
SNRS v2.05-26
Network applications that use nonstandard ports require user-defined entries in the mapping
table. You will use the ip port-map command to create default user-defined entries in the PAM
table.
Note
These entries automatically appear as an option for the ip inspect name command to
facilitate the creation of inspection rules.
You can specify up to five separate port numbers for each port map in a single entry. You can
also specify a port range in a single entry. However, you may not specify both single port
numbers and port ranges in the same entry.
Caution
If you try to map an application to a system-defined port, a message appears warning you of
a mapping conflict. Delete the system-defined entry before mapping it to another application.
Deleted system-defined mappings appear in the running-configuration in their no ip portmap form.
Use the no form of the ip port-map command to delete user-defined entries from the PAM
table. To remove a single mapping, use the no form of the command with all its parameters.

5-73
Here are some guidelines:
To overwrite an existing user-defined port mapping, use the ip port-map command to

associate another service or application with the specific port.
Multiple commands for the same application name are cumulative.
If you assign the same port number to a new application, the new entry replaces the
existing entry and it no longer appears in the running configuration. You receive a message
about the remapping.
You cannot specify a port number that is in a range assigned to another application;
however, you can specify a range that takes over one singly allocated port or that fully
overlaps another range.
You cannot specify overlapping port ranges.
Host-Specific Port Mapping

User-defined entries in the mapping table can include host-specific mapping information,
which establishes port mapping information for specific hosts or subnets. In some
environments, it might be necessary to override the default port mapping information for a
specific host or subnet, including a system-defined default port mapping information. Use the
list acl-num option for the ip port-map command to specify an ACL for a host or subnet that
uses PAM.
Configuring PAM
Use the ip port-map command to map a port to an application.
ip port-map appl-name port [tcp | udp] [port_num | from begin_port_num
to end_port_num] [list acl-num] [description description_string]
Syntax Description
appl-name
Specifies the name of the application with which to apply the port
mapping
An application name can contain an underscore (_) or a hyphen (-).
An application can also be system-defined or user-defined.
However, a user-defined application must have the prefix user- in it;
for example, user-payroll, user-sales, or user-10. Otherwise, the
following error message appears: "Unable to add port-map entry.
Names for user-defined applications must start with 'user-'."
port
Indicates that a port number maps to the application

Note: You can specify up to five port numbers for each port.
tcp | udp
(Optional) Specifies the protocol for the application

For well-known applications (and those existing already under
PAM), you can omit these keywords and the system assumes the
standard protocol for that application. However, for user-defined
applications, you must specify either tcp or udp.
port_num
(Optional) Identifies a port number in the range 1 to 65,535
from begin_port_num to
end_port_num
(Optional) Specifies a range of port numbers

You must use the from and to keywords together.
5-74
list acl-num
(Optional) Indicates that the port mapping information applies to a

specific host or subnet by associating it to an ACL number used with
PAM
description
description_string
(Optional) Specifies a description of up to 40 characters

Format: "C description_string C," where "C" is a delimiting character

5-75

This section describes how to verify PAM.

router# show ip port-map
Default mapping:
snmp
udp port 161
system defined
Default mapping:
echo
tcp port 7
system defined
Default mapping:
echo
udp port 7
system defined
Default mapping:
telnet
tcp port 23
system defined
Default mapping:
wins
tcp port 1512
system defined
Shows all port mapping information
router# show ip port-map ftp

Default mapping: ftp port 21
system defined
Host specific:
ftp
port 1000 in list 10 user
Shows port mapping information for a given application
SNRS v2.05-27
Use the show ip port-map command to view PAM information.

show ip port-map [appl-name | port port-num [detail]]
Syntax Description
appl-name
(Optional) Specifies the name of the application to which to apply the port
mapping
port port-num
(Optional) Specifies the alternative port number that maps to the

application
detail
(Optional) Shows the port or application details
The example shows that ftp is mapped to port 21 by the system, but it has been remapped to
port 1000 for a specific host.
5-76
Applying the Inspection Rule to an Interface

This topic describes how to apply inspection rules to router interfaces.
Apply an Inspection Rule to an Interface

router(config-if)# ip inspect FWRULE in
Applies the inspection rule to interface e0/0 in

inward direction
SNRS v2.05-28
After you define an inspection rule, you apply that rule to an interface.
Normally, you apply only one inspection rule to one interface. The only exception might occur
if you want to enable Cisco IOS classic firewall in two directions as described earlier. For
Cisco IOS classic firewall configured in both directions at a single firewall interface, you
should apply two rules, one for each direction.
If you are configuring Cisco IOS classic firewall on an external interface, apply the rule to
outbound traffic.
If you are configuring Cisco IOS classic firewall on an internal interface, apply the rule to
inbound traffic.
Use the ip inspect interface configuration command to apply a set of inspection rules to an
interface. Use the no form of this command to remove the set of rules from the interface.
The syntax for the ip inspect command is as follows:
ip inspect inspection-name {in | out }

5-77
Syntax Description
5-78
inspection-name
Names the set of inspection rules
in
Applies the inspection rules to inbound traffic
out
Applies the inspection rules to outbound traffic
Audit Trails and Logging

This topic describes how to configure audit trails and logging for Cisco IOS classic firewall.
Enable Audit Trails and Alerts

router(config)#
router(config)#
router(config)#
router(config)#
router(config)#
service timestamps log datetime

logging 10.0.0.3
logging facility syslog
logging trap 7
ip inspect audit-trail
SNRS v2.05-29
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.
Follow this procedure to configure logging and audit trail functions:
Step 1
Add the date and time to syslog and audit trail messages.
router(config)# service timestamps log datetime
Step 2
Specify the hostname or IP address of the host where you want to send syslog
messages.
router(config)# logging ip-address
Step 3
Configure the syslog facility in which error messages are sent.

router(config)# logging facility facility-type
Step 4
(Optional) Limit messages logged to the syslog servers based on severity. The
default is level 7 (informational).
router(config)# logging trap level
Step 5
Turn on Cisco IOS classic firewall audit trail messages.

router(config)# ip inspect audit-trail

5-79
Disabling Alerts
To disable IOS classic firewall alert messages, use the ip inspect alert-off command in global
configuration mode. To enable IOS classic firewall alert messages, use the no form of this
command.
5-80
Verifying Cisco IOS Classic Firewall

This topic lists the commands used to verify and troubleshoot Cisco IOS classic firewall
configuration and operation.
show Commands
Router#
show
show
show
show
show
ip
ip
ip
ip
ip
inspect
inspect
inspect
inspect
inspect
name inspection-name
config
interfaces
session [detail]
all
Displays Classic Firewall configurations, interface configurations,

and sessions
Router# sh ip inspect session
Session 6155930C (10.0.0.3:35009)=>(172.30.0.50:34233)
tcp SIS_OPEN
Session 6156F0CC (10.0.0.3:35011)=>(172.30.0.50:34234)
tcp SIS_OPEN
Session 6156AF74 (10.0.0.3:35010)=>(172.30.0.50:5002) tcp
SIS_OPEN
SNRS v2.05-30
You can view and verify Cisco IOS classic firewall configuration, status, statistics, and session
information by using one or more of the following commands
show ip access-lists: Displays the contents of all current IP ACLs
show ip inspect name inspection-name: Shows a particular configured inspection rule
show ip inspect config: Shows the complete Cisco IOS classic firewall inspection
configuration
show ip inspect interfaces: Shows interface configuration with regard to applied

inspection rules and ACLs
show ip inspect session [detail]: Shows existing sessions that are currently being tracked
and inspected by Cisco IOS classic firewall
show ip inspect all: Shows all Cisco IOS classic firewall configuration and all existing
sessions that are currently being tracked and inspected by Cisco IOS classic firewall
In most cases, you can tell whether Cisco IOS classic firewall is inspecting network traffic
properly because network applications are working as expected. In some cases, however, you
might want to verify Cisco IOS classic firewall operation. For example, to verify RTSP or
H.323 inspection, initiate an RTSP-based application or H.323-based application through the
firewall. Use the show ip inspect session and show ip access lists commands to verify Cisco
IOS classic firewall operation. These commands display the dynamic ACL entries and the
established connections for a multimedia session.

5-81
debug Commands
Router#
debug
debug
debug
debug
debug
ip
ip
ip
ip
ip
inspect
inspect
inspect
inspect
inspect
function-trace
object-creation
object-deletion
events
timers
General debug commands

router(config)#
debug ip inspect protocol
Protocol-specific debug
SNRS v2.05-31
Use the debug ip inspect command in EXEC mode to display messages about Cisco IOS
classic firewall events. The no form of this command disables debugging output.
The syntax for the debug ip inspect command is as follows:
debug ip inspect {function-trace | object-creation | object-deletion |
events | timers | protocol | detailed}
Syntax Description
5-82
function-trace
This command displays messages about software functions called

by Cisco IOS classic firewall.
object-creation
This command displays messages about software objects being

created by Cisco IOS classic firewall. Object creation corresponds to
the beginning of Cisco IOS classic firewall-inspected sessions.
object-deletion
This command displays messages about software objects being

deleted by Cisco IOS classic firewall. Object deletion corresponds to
the closing of Cisco IOS classic firewall-inspected sessions.
events
This keyword displays messages about Cisco IOS classic firewall

software events, including information about Cisco IOS classic
firewall packet processing.
timers
This keyword displays messages about Cisco IOS classic firewall

timer events, such as when a Cisco IOS classic firewall idle timeout
is reached.
protocol
This argument displays messages about Cisco IOS classic firewallinspected protocol events, including details about the protocol
packets.
detailed
Use this form of the command in conjunction with other Cisco IOS
classic firewall debugging commands. It displays detailed
information for all other enabled Cisco IOS classic firewall
debugging.
Removing Cisco IOS Classic Firewall

This topic describes how to remove Cisco IOS classic firewall.
Remove Classic Firewall Configuration

router(config)# no ip inspect
Removes entire Classic Firewall configuration

Resets all global timeouts and thresholds to
the defaults
Deletes all existing sessions
SNRS v2.05-32
Use the no ip inspect command to remove the entire Cisco IOS classic firewall configuration,
to reset all global timeouts and thresholds to their defaults, to delete all existing sessions, and to
remove all associated dynamic ACLs. This command has no other arguments, keywords,
default behavior, or values.

5-83
Summary
Summary
Cisco IOS classic firewall works to provide network protection on
multiple levels.
Cisco IOS classic firewall uses SPI to inspect traffic and create
temporary openings at firewall interfaces.
There are several basic tasks required to configure Cisco IOS
classic firewall.
For classic firewall to work properly, you need to make sure that
you have IP ACLs configured appropriately and applied at the
appropriate interfaces.
An inspection rule specifies what IP traffic will be inspected by
Cisco IOS Classic Firewall.
The complexity of configurations depend on the topology and
security requirements of the network.
SNRS v2.05-33
Summary (Cont.)
The application firewall uses static signatures to detect security
violations.
GPI allows you to specify TCP or UDP ports using the PAM table.
After you define an inspection rule, you apply this rule to an
interface.
Turn on logging and audit trail to provide a record of network
access through the firewall.
You can view and verify Cisco IOS classic firewall configuration,
status, statistics, and session information.
Use the no ip inspect command to remove the Cisco IOS classic
firewall configuration.
5-84
SNRS v2.05-34
References
For additional information, refer to these resources:
Cisco Systems, Inc. Cisco IOS Security Configuration Guide, Release 12.4.:
http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_book
09186a008043360a.html
Cisco Systems, Inc. Cisco IOS Security Command Reference, Release 12.4T:
09186a008049e249.html
Cisco IOS Firewall Design Guide:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_implementation_desig
n_guide09186a00800fd670.html

5-85
5-86
Lesson 3
Configuring Cisco IOS ZonedBased Policy Firewall

Overview
This lesson describes the Cisco IOS unidirectional firewall policy between groups of interfaces
known as zones. Previously, Cisco IOS Firewalls were configured as an inspection rule only on
interfaces. In this lesson, you will learn how to configure a Cisco IOS zone-based policy
firewall.
Objectives
Upon completing this lesson, you will be able to configure a Cisco IOS zone-based policy
firewall on a Cisco router. This ability includes being able to meet these objectives:
Describe some problems with the older stateful inspection process
Describe the general features of a Cisco IOS zone-based policy firewall
Describe security zones and zone pairs
Describe security zone firewall policies
Describe how to configure a Cisco IOS zone-based policy firewall
Describe Cisco IOS zone-based policy firewall monitoring commands
Legacy Stateful Inspection

This topic describes some problems with the old legacy Cisco IOS stateful inspection process.
Legacy Cisco IOS Stateful Inspection

Multiple inspection policies and ACLs on several interfaces in a
router make it difficult to correlate the policies that will be applied
to traffic between multiple interfaces.
Very little inspection policy granularity:
Policies could not be tied to a host group or subnet with an
ACL. All traffic through a given interface was subject to the
same inspection.
Classical stateful inspection relies too heavily on ACLs.
SNRS v2.05-2
The older Cisco IOS stateful inspection process suffered from some limitations, including the
following:
Multiple inspection policies were required and applied to several interfaces.
There was little inspection granularity.
It relied to heavily on access control lists (ACLs).
Traditional Cisco IOS Firewall stateful inspection employed an interface-based configuration

model, in which a stateful inspection policy was applied to an interface. All traffic passing
through that interface received the same inspection policy. This configuration model limited the
granularity of the firewall policies and caused confusion of the proper application of firewall
policies, particularly in scenarios when firewall policies must be applied between multiple
interfaces.
5-88
Cisco IOS Zone-Based Policy Firewall Overview

This topic describes the general features of a Cisco IOS zone-based policy firewall.
Cisco IOS Zone-Based Policy Firewall

Cisco IOS zone-based policy introduces
a new firewall configuration model.
Policies are applied to traffic moving
between zones, not interfaces.
Private
DMZ DMZ Policy
Private
Policy
Public DMZ
Policy
Default policy for interzone traffic is

deny all.
Untrusted
DMZ
Policies are configured with the Cisco

Policy Language.
Internet
PrivatePublic
Policy
These are Subnet- and host-specific policies.

It offers functionality similar to Cisco PIX object groups:
Service lists can be combined with network and host address lists.
Firewall policies can be more clearly understood:
Only policy from zone A to zone B impacts traffic
There is no interference between multiple inspection policies or ACLs.
SNRS v2.05-3
Cisco IOS Release 12.4(6)T introduced a new configuration model for the Cisco IOS Firewall
feature set. This new Cisco IOS zone-based policy firewall offers intuitive policies for multiple
interface routers, increased granularity of firewall policy application, and a default deny-all
policy that prohibits traffic between firewall zones until an explicit policy is applied to allow
desirable traffic.
Nearly all firewall features implemented prior to Cisco IOS Release 12.4(6)T are supported in
the new zone-based policy inspection interface, including the following:
Stateful packet inspection
Application inspection
Virtual private network (VPN) routing and forwarding (VRF)-aware Cisco IOS Firewall
URL filtering
Denial of service (DoS) mitigation
The new capabilities and characteristics include the following:
Policies are applied between zones.
There is a default deny-all policy.
Subnet and host specific policies
Service lists can be combined with network and host address lists.
Firewall policies are more clearly understood.
5-89
Zone-Based Policy Firewall (Cont.)

Unidirectional policy is applied between zones:
A zone is a collection of interfaces.
Multiple traffic classes and actions can be applied per zone pair.
Connection parameters are global unless zone pair-specific
parameters are applied.
Policies can define
combinations of:
DMZ Private
Policy
Private DMZ
Policy
Public DMZ
Policy
IP address/subnet/ACL
TCP/UDP/ICMP
DMZ
Trusted
Internet
Application service
Application-specific
policy
Untrusted
Private Public
Policy
SNRS v2.05-4
There is a unidirectional policy between zones.
Multiple traffic classes and actions are applied per zone pair.
Connection parameters are global unless a parameter map is specified.
Policies can include combinations of the following:
IP addresses or subnets using ACLs
Protocols
TCP, User Datagram Protocol (UDP), Internet Control Message Protocol

(ICMP), and so on
Application services
Application-specific policies
Cisco IOS zone-based policy firewall generally improves Cisco IOS performance for most
firewall inspection activities.
Cisco IOS zone-based policy firewall changes the firewall from the older interface-based model
to a more flexible, more easily understood zone-based configuration model. Interfaces are
assigned to zones, and an inspection policy is applied to traffic moving between the zones.
Interzone policies offer considerable flexibility and granularity, so different inspection policies
can be applied to multiple host groups connected to the same router interface.
Firewall policies are configured with the Cisco Policy Language, which employs a hierarchical
structure to define inspection for network protocols and the groups of hosts to which the
inspection will be applied.
5-90
Configuration Model
Cisco IOS zone-based policy firewall completely changes the way you configure a Cisco IOS
Firewall.
The first major change to the firewall configuration is the introduction of zone-based
configuration. Cisco IOS Firewall is the first Cisco IOS Software threat defense feature to
implement a zone configuration model. Other features might adopt the zone model over time.
The classical Cisco IOS Firewall stateful inspection and Context-Based Access Control
(CBAC) interface-based configuration model employing the ip inspect command set will be
maintained for a period of time, but few, if any, new features will be configurable with the
classic command-line interface (CLI). The Cisco IOS zone-based policy firewall does not use
the stateful inspection or CBAC commands.
Note
The two configuration models can be used concurrently on routers, but not combined on
interfaces; an interface cannot be configured as a security zone member and configured for
IP inspection simultaneously.
Zones establish the security borders of your network. A zone defines a boundary where traffic
is subjected to policy restrictions as it crosses to another region of your network. The Cisco IOS
zone-based policy firewall default policy between zones is deny all. If no policy is explicitly
configured, all traffic moving between zones is blocked. This is a significant departure from the
stateful inspection model, in which traffic was implicitly allowed until explicitly blocked with
an ACL.
The second major change is the introduction of a new configuration policy language known as
Cisco Policy Language. Users familiar with the Cisco IOS Software Modular quality of service
(QoS) CLI (MQC) might recognize the format being similar to the use of class maps by QoS to
specify which traffic will be affected by the action applied in a policy map.
General Rules
The membership of router network interfaces in zones is subject to several rules governing
interface behavior, as is the traffic moving between zone member interfaces.
A zone must be configured before interfaces can be assigned to the zone.
An interface can be assigned to only one security zone.
All traffic to and from a given interface is implicitly blocked when the interface is assigned
to a zone, excepting traffic to and from other interfaces in the same zone, and traffic to any
interface on the router.
Traffic is implicitly allowed to flow by default among interfaces that are members of the
same zone.
To permit traffic to and from a zone member interface, a policy allowing or inspecting
traffic must be configured between that zone and any other zone.
The self zone is the only exception to the default deny-all policy. All traffic to any router
interface is allowed until traffic is explicitly denied.
Traffic cannot flow between a zone member interface and any interface that is not a zone
member. Pass, inspect, and drop actions can only be applied between two zones.
5-91
5-92
Interfaces that have not been assigned to a zone function as classical router ports and might
still use classical stateful inspection or CBAC configuration.
If it is required that an interface on the box not be part of the zoning or firewall policy, it
might still be necessary to put that interface in a zone and configure a pass all policy (sort
of a dummy policy) between that zone and any other zone to which traffic flow is desired.
From the preceding it follows that, if traffic is to flow among all of the interfaces in a
router, all the interfaces must be part of the zoning model (each interface must be a member
of one zone or another).
The only exception to the preceding deny-by-default approach is the traffic to and from the
router, which will be permitted by default. An explicit policy can be configured to restrict
such traffic.
Basic Topology
This section describes a basic topology using Cisco IOS zone-based policy firewall.
Basic Firewall
The private zone must reach the Internet, with access to HTTP,
SMTP, and DNS services.
The Internet should not have any inbound access.
HTTP
SMTP
DNS
Untrusted
Trusted
VLAN
1
Fa0
Internet
No
Access
SNRS v2.05-5
This is an example of a basic two-interface topology.

A security zone should be configured for each region of relative security within the network, so
that all interfaces that are assigned to the same zone will be protected with a similar level of
security. For example, consider the access router with two interfaces shown in the figure.
This access router has the following two interfaces:
One interface connected to the public Internet
One interface connected to a private LAN that must be able to reach the public Internet
Each interface in this network will be assigned to its own zone.

In the example in the figure, each zone holds only one interface. If an additional interface is
added to the private zone, the hosts connected to the new interface in the zone would be able to
pass traffic to all hosts on the existing interface in the same zone. Additionally, the traffic of
local hosts to hosts in other zones would be similarly affected by existing policies.
Typically, the network will have two main policies:
1. Private zone connectivity to the Internet
2. Internet zone connectivity to the private zone
5-93
DMZ Topology
This section describes the basic demilitarized zone (DMZ) topology using Cisco IOS zonebased policy firewall.
DMZ Topology
Network consists of three zones:
Internet zone: Internet
DMZ zone: 64.96.112.0/24
Private zone: Private network, 10.0.1.0/24
HTTP Server
64.96.112.55
DMZ Private Private DMZ

Policy
Policy
Public DMZ
Policy
DMZ
Internet
e1
Private
Internet
e0
Internal Network 10.0.1.0/24
s0
Private Internet
Policy
SNRS v2.05-6
This is an example of a basic three-interface firewall with a DMZ.

This firewall has the following interfaces:
One interface connected to the public Internet
One interface connected to a private LAN that must not be accessible from the public
Internet
One interface connected to an Internet service DMZ, where a web server, Domain Name
System (DNS) server, and e-mail server must be accessible to the public Internet
Each interface in this network will be assigned to its own zone, although you might want to
allow varying access from the public Internet to specific hosts in the DMZ and varying
application use policies for hosts in the protected LAN.
In the example, each zone holds only one interface. If an additional interface is added to the
private zone, the hosts connected to the new interface in the zone would be able to pass traffic
to all hosts on the existing interface in the same zone. Additionally, the traffic of local hosts to
hosts in other zones would be similarly affected by existing policies.
5-94
Typically, the network will have three main policies:

1. Private zone connectivity to the Internet
2. Private zone connectivity to DMZ hosts
3. Internet zone connectivity to DMZ hosts
Because the DMZ is exposed to the public Internet, the DMZ hosts might be subjected to
undesired activity from malicious individuals who might succeed at compromising one or more
DMZ hosts. If no access policy is provided for DMZ hosts to reach either private zone hosts or
Internet zone hosts, the individuals who compromised the DMZ hosts would not be able to use
the DMZ hosts to carry out further attacks against private or Internet hosts. Cisco IOS zonebased policy firewall imposes a prohibitive default security posture; thus, unless the DMZ hosts
are specifically provided access to other networks, other networks are safeguarded against any
connections from the DMZ hosts. Similarly, no access is provided for Internet hosts to access
the private zone hosts; therefore, private zone hosts are safe from unwanted access by Internet
hosts.
5-95
Zones
This topic describes zones, security zones, and zone pairs.
Security Zones
E2
Not in Any
Security
Zones
S4
E0
Zone Z1
Zone Z2
S3
E1
Security
Zones
SNRS v2.05-7
A security zone is a group of interfaces that have similar functions or features. Security zones
provide a way for you to specify where a Cisco IOS Firewall is applied.
For example, on a router, interfaces Ethernet 0 and Ethernet 1 may be connected to the local
LAN. These two interfaces are similar because they represent the internal network, so they can
be grouped into a zone for firewall configurations.
Traffic between interfaces in the same zone is not be subjected to any policy. The traffic passes
freely.
Note
Firewall zones are used for security features.
Security Zones
A security zone is a group of interfaces to which a policy can be applied.
Grouping interfaces into zones involves two steps:
5-96
Creating a zone so that interfaces can be attached to it
Configuring an interface to be a member of a given zone
When an interface is a member of a security zone, all traffic to and from that interface (except
traffic going to the router or initiated by the router) is dropped. To permit traffic to and from a
zone member interface, you must make that zone part of a zone pair and then apply a policy to
that zone pair. If the policy permits traffic (via inspect or pass actions), traffic can flow
through the interface.
By default, traffic flows among interfaces that are members of the same zone.
For traffic to flow among all the interfaces in a router, all the interfaces must be a member of
one security zone or another.
Note
It is not necessary for all router interfaces to be members of security zones.
Refer to the Security Zones figure and note the following:
Interfaces E0 and E1 are members of security zone Z1.
Interface S3 is a member of security zone Z2.
Interfaces E2 and S4 not members of any security zone.
The following statements apply to the figure:
Traffic flows freely between interfaces E0 and E1 because they are members of the same
security zone (Z1).
If no policies are configured, traffic will not flow between any other interfaces (for
example, E0 and S3, E1 and S3).
Traffic can flow between E0 or E1 and S3 only when an explicit policy permitting traffic is
configured between zone Z1 and zone Z2.
Traffic can never flow between E2 and E0, E1, or S3 because E2 is not part of any security
zone.

5-97
Zoning Rules
This section summarizes the zoning rules.
Zoning Rules Summary

If two interfaces are not in zones, traffic flows freely between
them.
If one interface is in a zone, and another interface is not in a zone,
traffic may never flow between them.
If two interfaces are in two different zones, traffic will not flow
between the interfaces until a policy is defined to allow the traffic.
SNRS v2.05-8
Zoning rules may be summarized as follows:
Traffic flows freely between interfaces that are not in a zone.
If one interface is in a zone, and another interface is not in a zone, traffic may never flow
between them.
Traffic will not flow between two interfaces until a policy is defined to allow the traffic, if
the two interfaces are in two different zones.
Zones and Inspection

Zone-based policy firewalls examine the source and destination zones from the ingress and
egress interfaces for a firewall policy. It is not necessary that all traffic flowing to or from an
interface be inspected; you can designate that individual flows in a zone pair be inspected
through the policy map that you apply across the zone pair. The policy map will contain class
maps that specify the individual flows.
For example, you can specify a policy map that performs HTTP URL filtering for hosts on
192.168.1.0/24 (engineers), but only does plain HTTP inspection for 192.168.2.0/24
(managers) for your inside-to-outside traffic.
This results in two flows (192.168.1.0/24 to any, 192.168.2.0/24 to any), and you can apply
different inspection parameters to the flows to configure the desired different behaviors. Zonebased policy firewalls allow inside-to-Internet traffic (the source zone inside and the destination
zone outside).
5-98
Security Zone Restrictions

Here are some security zone restrictions:
An interface cannot be part of a zone and legacy inspection policy at the same time.
An interface can be a member of only one security zone.
When an interface is a member of a security zone, all traffic to and from that interface is
blocked unless you configure an explicit interzone policy on a zone pair involving that
zone.
Traffic cannot flow between an interface that is a member of a security zone and an
interface that is not a member of a security zone, because a policy can be applied only
between two zones.
For traffic to flow among all the interfaces on a router, all the interfaces must be members
of one security zone or another. This is particularly important because after you make an
interface a member of a security zone, a policy action (such as inspect or pass) must
explicitly allow packets. Otherwise, packets are dropped.
If an interface on a router cannot be part of a security zone or firewall policy, you may have
to put that interface in a security zone and configure a pass all policy (that is, a dummy
policy) between that zone and other zones to which a traffic flow is desired.
You cannot apply an ACL between security zones or on a zone pair.
An ACL cannot be applied between security zones and zone pairs. Include the ACL
configuration in a class map, and use policy maps to drop traffic.
An ACL on an interface that is a zone member should not be restrictive (strict).
All interfaces in a security zone must belong to the same VRF.
You can configure policies between security zones whose member interfaces are in
separate VRFs. However, traffic may not flow between these VRFs if the configuration
does not allow it.
If traffic does not flow between VRFs (because route leaking between VRFs is not
configured), the policy across the VRFs is not executed. This is a misconfiguration on the
routing side, not on the policy side.
Traffic between interfaces in the same security zone is not subjected to any policy; the
traffic passes freely.
The source and the destination zones in a zone pair must be a member of a security zone.
The same zone cannot be defined as both the source and the destination.

5-99
Zone Pairs
This section covers zone pairs.
Security Zone Pairs
E2
Not in Any
Security
Zones
S4
E0
Zone Z1
Zone Z2
S3
E1
Security Zone Pair

Source = Z1
Destination = Z2
SNRS v2.05-9
A zone pair allows you to specify a unidirectional firewall policy between two security zones.
To define a zone pair, use the zone-pair security command. The direction of the traffic is
specified by specifying a source and destination zone. The source and destination zones of a
zone pair must be security zones. The same zone cannot be defined as both the source and the
destination.
When an interface is configured to be a zone member, the hosts connected to the interface are
included in the zone, but traffic flowing to and from the router interfaces is not controlled by
the zone policies. Instead, all of the IP interfaces on the router are automatically made part of
the self zone when the Cisco IOS zone-based policy firewall is configured. To control IP traffic
moving to the router interfaces from the various zones on a router, policies must be applied to
block or allow and inspect traffic between the zone and the router self zone, and vice versa.
If desired, you can select the default self zone as either the source or the destination zone. The
self zone is a system-defined zone. It does not have any interfaces as members. A zone pair that
includes the self zone, along with the associated policy, applies to traffic directed to the router
or traffic generated by the router. It does not apply to traffic through the router.
The most common usage of firewalls is to apply them to traffic through a router, therefore, you
usually need at least two zones (that is, you cannot use the self zone).
To permit traffic between zone member interfaces, you must configure a policy permitting (or
inspecting) traffic between that zone and another zone.
To attach a firewall policy map to the target zone pair, use the service-policy type inspect
command.
5-100
The Security Zone Pairs figure shows the application of a firewall policy to traffic flowing
from zone Z1 to zone Z2, which means that the ingress interface for the traffic is a member of
zone Z1 and the egress interface is a member of zone Z2.
If there are two zones and you require policies for traffic going in both directions (from Z1 to
Z2 and Z2 to Z1), you must configure two zone pairs (one for each direction).
If a policy is not configured between a pair of zones, traffic is dropped. However, it is not
necessary to configure a zone pair and a service policy solely for return traffic. Return traffic is
allowed, by default, if a service policy permits the traffic in the forward direction. In the
example, it is not mandatory that you configure a zone pair source Z2 destination Z1 solely for
allowing return traffic from Z2 to Z1. The service policy on the Z1-Z2 zone pair takes care of
this.

5-101
Security Zone Firewall Policies

This topic describes security zone firewall policies.
Specifying Policy
Applies Cisco Policy Language framework
Based on existing MQC framework in Cisco IOS Software
Only three constructs:
Class-map specifies interesting traffic via match conditions.
Policy-map associates actions with the above-specified traffic.
Parameter-map specifies operating parameters for the
classification and action application.
SNRS v2.05-10
You will use the Cisco Policy Language framework to build Cisco IOS zone-based policy
firewall policies.
There are three main constructs involved when dictating Cisco IOS zone-based policy firewall
policies:
Class-map: A class is a way of identifying a set of packets based on its contents using
match conditions. Normally, you define a class so that you can apply an action on the
identified traffic that reflects a policy. A class is designated via class maps.
The class-map command creates a class map to be used for matching packets to a specified
class. Packets arriving at the targets (such as the input interface, output interface, or zone
pair), determined by how the service-policy command is configured, are checked against
the match criteria configured for a class map to determine if the packet belongs to that
class.
Policy-map: Policy maps associate actions with traffic classified by class maps. An action
is a specific functionality. It typically is associated with a traffic class. For example,
inspect, drop, and pass, are actions.
The policy-map command creates or modifies a policy map that can be attached to one or
more targets to specify a service policy. Use the policy-map command to specify the name
of the policy map to be created, added to, or modified before you can configure policies for
classes whose match criteria are defined in a class map.
5-102
Parameter-map: Parameter maps specify parameters to be applied to classified traffic.
The parameter-map type command allows you to specify parameters that control the behavior
of actions and match criteria specified under a policy map and a class map, respectively.
There are currently three types of parameter maps:
Inspect parameter map
An inspect parameter map is optional. If you do not configure a parameter map, the software
uses default parameters. Parameters associated with the inspect action apply to all nested
actions (if any). If parameters are specified in both the top and lower levels, those in the lower
levels override those in the top levels.
URL filter parameter map
A parameter map is required for URL filtering (via the url filter action in a Layer 3 or Layer 4
policy map and the url filter parameter map).
Protocol-specific parameter map
A parameter map is required for an IM application (Layer 7) policy map.

5-103
Class Maps for Cisco IOS Zone-Based Policy Firewalls

This section describes how class maps are used to define traffic.
The inspect type class-map

Applies logical qualifiers match-all and match-any. Determines the
way a packet is matched against filters in a class map
Applies three types of match statements (filters)
match protocol <protocol-name>
match access-group <number | name>
match class <class-map-name>
SNRS v2.05-11
MQC class maps have numerous match criteria; firewalls have fewer match criteria. Firewall
class maps have the type of inspect; this information controls what shows up under firewall
class maps.
Class maps define the traffic that the firewall selects for policy application. Layer 4 class maps
sort the traffic based on criteria.
A class map uses the match-any or match-all logical qualifiers to determine how a packet is
matched against the filters in the class map.
You will use three types of filters:
5-104
match <protocol-name>: The Layer 4 protocols (TCP, UDP, and ICMP) and application
services such as HTTP, Simple Mail Transfer Protocol (SMTP), DNS, and so on; any wellknown or user-defined service known to Port-to-Application Mapping (PAM) may be
specified.
match access-group <number|name>: A standard, extended, or named ACL can filter

traffic based on source and destination IP address and source and destination port.
match <class-map-name>: A subordinate class map providing additional match criteria

can be nested inside another class map.
Class-maps can apply match-any or match-all operators to determine how to apply the
match criteria. If match-any is specified, traffic must meet only one of the match criteria in
the class map. If match-all is specified, traffic must match all of the class map criteria to
belong to that particular class.
If traffic might meet multiple criteria, match criteria must be applied in order from more
specific to less specific. For example, consider the following class map:
class-map type inspect match-any my-test-cmap
match protocol http
match protocol tcp
HTTP traffic must encounter the match protocol http statement first to be sure that the traffic
will be handled by the service-specific capabilities of HTTP inspection. If the match lines
were reversed so that traffic encountered the match protocol tcp statement before it were
compared to the match protocol http statement, the traffic would simply be classified as TCP
traffic and inspected according to the capabilities of the TCP inspection component of the
firewall. This would be a problem for certain services such as FTP, TFTP, and several
multimedia and voice signaling services such as H.323, session initiation protocol (SIP),
Skinny, Real-Time Streaming Protocol (RTSP), and others. These services require additional
inspection capabilities to recognize the more complex activities of these services.
Class maps can apply an ACL as one of the match criteria for policy application. If the only
match criteria of a class map is an ACL and the class map is associated with a policy map
applying the inspect action, the router will apply inspection for all known services (according
to the show ip port-map command). Thus, the ACL must apply the restriction to limit traffic to
specific desired types. Note that the PAM list only includes application services such as HTTP,
NetBIOS, H.323, DNS, and so on. If a service is not known to PAM, it will not be inspected.
The PAM list tends to include more services with each passing Cisco ISO Software release;
therefore check the port map list to be certain that your services are known to the firewall
software.

5-105
class-map type inspect

Specifies web traffic that also matches ACL 101
R1(config)# class-map type inspect match-all c1
R1(config-cmap)# match protocol http
R1(config-cmap)# match access-group 101
Specifies traffic that is bound for any of the three protocols listed
R1(config)# class-map type inspect match-any c2
R1(config-cmap)# match protocol ftp
R1(config-cmap)# match protocol smtp
Specifies traffic that is bound for any of the three protocols in c2 and that
also matches ACL 199
R1(config)# class-map type inspect match-all c3
R1(config-cmap)# match class c2
SNRS v2.05-12
Layer 3 and Layer 4 Class Maps

Layer 3 and Layer 4 class maps are used to identify traffic streams on which different actions
should be performed.
Note
A Layer 3 or Layer 4 policy map is sufficient for the basic inspection of traffic.
The example shows how to configure three class maps with various match criteria.
After creating your class maps, you might create an inspect policy map to specify that packets
will be inspected. Here is an example:
router(config)# policy-map type inspect policy-map-name
router(config-pmap)# class type inspect class-map-name
router(config-pmap-c)# inspect
5-106
Layer 7 class-map type inspect

Command
Layer 7 Traffic
Class
Examines SMTP traffic for large packets

R1(config)# class-map type inspect smtp huge-mails
Match criteria for
R1(config-cmap)# match data-length gt 100000
Layer 7
R1(config-cmap)# exit
R1(config)# policy-map type inspect smtp mysmtp-policy
R1(config-pmap)# class type inspect smtp huge-mails
R1(config-pmap-c)# reset
Layer 7 Policy
R1(config-pmap-c)# exit
Must Match
R1(config-pmap)# exit
Protocol in
R1(config)# class-map type inspect c1
Layer 7 Policy
R1(config-cmap)# exit
Layer 3/ Layer 4
R1(config)# policy-map type inspect mypolicy
Top-level Policy
R1(config-pmap)# class type inspect c1
R1(config-pmap-c)# inspect
R1(config-pmap-c)# service-policy smtp mysmtp-policy
SNRS v2.05-13
Layer 7 Class Maps

Layer 7 class maps can be used in inspect policy maps for deep packet inspection.
To create a Layer 7 class map, use the class-map type inspect <protocol>command for the
desired protocol. For example, for SMTP, you would enter the class-map type inspect smtp
<class-map-name> command. If you do not specify a protocol name (for example, you use the
policy-map type inspect command), you will be creating a Layer 3 or Layer 4 policy map,
which can only be an inspect type policy map.
The type of class map (for example, HTTP) determines the match criteria that you can use. For
example, if you want to specify HTTP traffic that contains Java applets, you must specify a
match response body java statement in the context of an inspect HTTP class map.
Layer 7 Supported Protocols

The following protocols are available for you to create Layer 7 class maps and policy maps:
AOL Instant Messenger (AIM) protocol
eDonkey point-to-point protocol
FastTrack traffic point-to-point protocol
Gnutella version 2 traffic P2P protocol
HTTP
Internet Message Access Protocol (IMAP)
Kazaa version 2 point-to-point protocol
MSN Messenger IM protocol
Post Office Protocol version 3 (POP3)
SMTP

5-107
Sun Remote Procedure Call (RPC)
Yahoo! Messenger IM protocol
Class Default Class Map

In addition to user-defined classes, there is a system-defined class map named class-default
that represents all packets that do not match any of the user-defined classes in a policy. It
always is the last class in a policy map.
You can define explicit actions for this group of packets. If you do not configure any actions
for the class-default class in an inspect policy, the default action is drop.
The following example shows how to use class-default in a policy map. In this example, HTTP
traffic is dropped, and the remaining traffic is inspected. Class map class1 is defined for
HTTP traffic, and the class-default command is used for a policy map policy1.
Step 1
Define the class map.
router(config)# class-map type inspect match-all class1

router(config-cmap)# match protocol http
Step 2
Define the policy map.
router(config)# policy-map type inspect policy1

router(config-pmap)# class type inspect class1
router(config-pmap-c)# drop
router(config-pmap-c)# exit
router(config-pmap)# class class-default
router(config-pmap-c)# inspect
5-108
Policy Maps for Cisco IOS Zone-Based Policy Firewalls

This section describes how policy maps are used to define actions to be taken on specified
traffic.
ZBF Policy Actions

Drop
Pass
Requires manually-configured ACL for reflexive policy
No stateful capability
Inspect
Monitor outbound traffic according to permit or deny policy
Anticipate return traffic according to session table entries
Drop any traffic that is not specifically inspected
(class-default traffic)
SNRS v2.05-14
A policy is an association of traffic classes and actions. It specifies what actions should be
performed on the defined traffic classes. An action is a specific function, and it is typically
associated with a traffic class. For example, inspect, pass, and drop are actions.
Cisco IOS zone-based policy firewall provides three actions for traversing traffic from one zone
to another:
Drop: This is the default action for all traffic. Also, a policy map can be configured to drop
unwanted traffic. Traffic that is assigned to the drop action is blocked by the Cisco IOS
zone-based policy firewall, and an ICMP host unreachable message is returned to the
host that sent the dropped traffic.
Pass: This action allows the router to forward traffic from one zone to another. The pass
action does not track the state of connections or sessions within the traffic; pass only allows
the traffic in one direction. A corresponding policy must be applied to allow return traffic
to pass in the opposite direction. The pass action is useful for protocols such as IP Security
(IPsec) Encapsulating Security Payload (ESP), IPsec Authentication Header (AH), Internet
Security Association and Key Management Protocol (ISAKMP), and other inherently
secure protocols with predictable behavior, but most application traffic is better handled in
the Cisco IOS zone-based policy firewall with the inspect action.
Inspect: The inspect action offers state-based traffic control. If, for example, traffic from
the private zone to the Internet zone in the earlier sample network is inspected, the router
will maintain the connection or session information for TCP and UDP traffic; therefore, the
router will permit return traffic sent from Internet zone hosts in reply to private zone
connection requests. The inspect action also offers the capability to provide application
inspection and control for certain service protocols that might carry vulnerable or sensitive
application traffic.

5-109
Layers 3, 4, and 7 Policy Types

Layer 3/Layer 4 policy is a top level policy-which is attached to the
zone pair. Aggregate traffic using match protocol/ACLs selections,
apply high-level actions like drop, inspect, urlfilter and deepinspection.
Layer 7 or application policy is optional and is typically applied to
control the finer details of an application (e.g., HTTP, SMTP etc).
It is contained in a Layer 3/Layer 4 policy and cannot be directly
attached to a target.
Layer 3/Layer 4 policy suffices for basic inspection. Finer
application-level inspection calls for creation of an Layer 7 policy
which is nested (hierarchical) in the Layer 3/Layer 4 policy.
SNRS v2.05-15
Policy types used for Cisco IOS zone-based policy firewall include Layer 3, Layer 4, and Layer
7 policies. Your choice of Layer 3, Layer 4, and Layer 7 policy will depend on the network
security policies.
In general, please note the following:
5-110
A Layer 3 and Layer 4 policy is called a top-level policy, which can be attached to a zone
pair.
A Layer 7 policy map provides application-level inspection of traffic. It is usually used for
more granular control of application layer protocols such as HTTP, SMTP, and others.
A Layer 3 and 4 policy is sufficient for basic inspection. A Layer 7 policy is sufficient for a
more granular control of application layer protocols; however it must be nested with a
Layer 3/Layer 4 top-level policy.
Layers 3, 4, and 7 Policy Types (Cont.)

Layer 7 class/policy-maps are protocol specific. The options
appearing under them depend on the protocol and the capabilities
of the existing application inspection module.
As of now, Layer 7 policies can be configured for the following
protocols: HTTP, SMTP, POP3, IMAP, and RPC.
The Layer 7 policy map is attached to the top-level policy using
the service-policy inspect <http | smtp | > <policy-name>
command.
The class in the top-level policy for which an Layer 7 policy-map
is configured must have a match protocol filter. This protocol and
the Layer 7 Policy map protocol must be the same. If only match
access-group filters are present in the class map, a Layer 7 policy
cannot be configured for that class.
A single Layer 7 policy map may be used in multiple
classes/policies.
SNRS v2.05-16
Here are some general rules regarding Layer 7 policy maps:
A Layer 7 policy map is more protocol specific. The options depend on the protocol.
Currently, Layer 7 policies can be configured for the following protocols: HTTP, SMTP,
POP3, IMAP, and RPC
The Layer 7 policy cannot be directly attached to a zone pair. It must be attached to the toplevel policy using the service-policy command.
The class map in the top-level policy must have a match protocol filter and it must match
the protocol in the Layer 7 policy map.
One Layer 7 policy map may be used with multiple classes and policies.

5-111
Hierarchy
L7
HTTP sessions
with URL length
>500
class-map type inspect http long-urls
HTTP
match request uri length gt 500
policy
policy-map type inspect http http-policy

class type inspect http long-urls
Layer 7 policy
action: Reset
reset
class-map type inspect match-all http-traffic
L3/L4
top
level
policy
match protocol http
Aggregate HTTP
traffic matching ACL
199 at top level
match access-group 199

policy-map type inspect mypolicy
class type inspect http-traffic
inspect
Specify deep-packet
HTTP inspection
service-policy inspect http http-policy

zone-pair security in-out source in-zone dest out-zone
service-policy type inspect mypolicy
Apply top level
policy on target
SNRS v2.05-17
To create a Layer 7 policy map, specify the protocol in the applicable policy-map type inspect
command. For example, to create a Layer 7 HTTP policy map, use the policy-map type
inspect http command.
If you do not specify a protocol name (for example, you use the policy-map type inspect
command), you will be creating a Layer 3 or Layer 4 policy map, which can only be an inspect
type policy map.
Hierarchical Policy Maps

A policy can be nested within another policy. A policy that contains a nested policy is called a
hierarchical policy.
To create a hierarchical policy, attach a policy directly to a class of traffic. A hierarchical
policy contains a child and a parent policy. The child policy is the previously defined policy
that is associated with the new policy through the use of the service-policy command. The new
policy using the pre-existing policy is the parent policy.
Note
There can be a maximum of two levels in a hierarchical inspect service policy.
A Layer 7 policy map must be contained in a Layer 3 or Layer 4 policy map; it cannot be
attached directly to a target. To attach a Layer 7 policy map to a top-level policy map, use the
service policy inspect command and specify the application name (that is, HTTP, IMAP,
POP3, SMTP, or Sun RPC). The parent class for a Layer 7 policy should have an explicit
match criterion that matched only one Layer 7 protocol before the policy is attached. The
policy map can include class maps only of the same type.
If the Layer 7 policy map is in a lower level, you must specify the inspect action at the parent
level for a Layer 7 policy map.
5-112
Parameter Maps
Specify parameters such as old inspect cli
R1(config)# parameter-map type inspect myparams
R1(config-profile)# alert on
R1(config-profile)# audit-trail on
R1(config-profile)# max-incomplete high 1000
R1(config-profile)# tcp idle-time 360
R1(config-profile)# exit
-------- Then apply to policy map ------------R1(config)# policy-map type inspect mypolicy
R1(config-pmap)# class type inspect c1
R1(config-pmap-c)# inspect myparams
R1(config-pmap-c)# end
SNRS v2.05-18
Parameter Maps
A parameter map allows you to specify parameters that control the behavior of actions and
match criteria specified under a policy map and a class map, respectively.
The four current types of parameter maps are as follows:
Inspect parameter map: An inspect parameter map is optional. If you do not configure a
parameter map, the software uses default parameters. Parameters associated with the
inspect action apply to all nested actions (if any). If parameters are specified in both the top
and lower levels, those in the lower levels override those in the top levels.
URL filter parameter map: A parameter map is required for URL filtering (via the URL
filter action in a Layer 3 or Layer 4 policy map and the URL filter parameter map).
Mitigation parameter map: A parameter map is required for an instant messaging (IM)
application (Layer 7) policy map.
TMS (TIDP Based Mitigation Services ) parameter map: The TMS type parameter map
is a container for TMS protocol-specific configuration parameters.
After you enter the parameter-map type inspect command, you can enter the following
subcommands:
alert {on | off}: Turns on Cisco IOS stateful packet inspection alert messages
audit-trail {on | off}: Turns audit trail messages on or off
dns-timeout seconds: Specifies the DNS idle timeout
icmp idle-timeout seconds: Configures the timeout for ICMP sessions
max-incomplete {low number-of-connections | high number-of-connections}: Defines the

number of existing half-open sessions that will cause the software to start and stop deleting
half-open sessions

5-113
5-114
one-minute {low number-of-connections | high number-of-connections}: Defines the

number of new unestablished sessions that will cause the system to start deleting half-open
sessions and stop deleting half-open sessions
tcp finwait-time seconds: Specifies how long a TCP session will be managed after the
Cisco IOS Firewall detects a FIN exchange
tcp idle-time seconds: Configures the timeout for TCP sessions
tcp max-incomplete host threshold [block-time minutes}: Specifies the threshold and
blocking time values for TCP host-specific DoS detection and prevention
tcp synwait-time seconds: Specifies how long the software will wait for a TCP session to
reach the established state before dropping the session
udp idle-time seconds: Configures the timeout of UDP sessions going through the firewall
Configuring a Cisco IOS Zoned-Based Policy

Firewall
This topic describes how to configure a Cisco IOS zone-based policy firewall.
Configuring a Cisco IOS Zone-Based

Policy Firewall
1. Identify interfaces that share the same function security and group
them into the same security zones.
2. Determine the required traffic flow between zones in both directions.
3. Set up zones.
4. Set up zone pairs for any policy other than deny all.
5. Define class maps to describe traffic between zones.
6. Associate class maps with policy maps to define actions applied to
specific policies.
7. Assign policy maps to zone pairs.
Fa
0/1
Ser
0/0
Fa
0/0
SNRS v2.05-19
There are several steps required to configure a Cisco IOS zone-based policy firewall. The
following procedure can be used to configure a Cisco IOS zone-based policy firewall. The
sequence of steps is not important, but some events must be completed in order. For instance,
you must configure a class map before you assign a class map to a policy map. Similarly, you
cannot assign a policy map to a zone pair until you have configured the policy. If you try to
configure a section that relies on another portion of the configuration that you have not
configured, the router will respond with an error message.
To set up a Cisco IOS zone-based policy firewall, follow these steps:
Step 1
Identify the interfaces to include in security zones. Identify interfaces that face the
Internet, the corporate LAN, and the DMZ. Interfaces that share the same function
should be grouped into the same security zones.
Step 2
Determine the flow of traffic needed between zones. Determine what traffic is
necessary and in which direction.
Step 3
Create zones and zone members.
Step 4
Create zone pairs.
Step 5
Classify traffic using class maps.
Step 6
Create policy maps to define actions to be taken on filtered traffic.
Step 7
Apply policies to zone pairs per network security policy.

5-115
Security Zone Configuration

Configure the security zones
R1(config)# zone security private
R1(config-sec-zone)# exit
R1(config)# zone security internet
R1(config-sec-zone)# exit
R1(config)# int fa0/1
R1(config-if)# zone-member security internet
R1(config-if)# exit
R1(config)# int fa0/0
R1(config-if)# zone-member security private
R1(config-if)# end
Configure the zone pair

R1(config)# zone-pair security priv-to-internet source
private destination internet
SNRS v2.05-20
Creating Security Zones and Zone Pairs

You need two security zones to create a zone pair. However, you can also create only one
security zone and use a system-defined security zone called self.
Note
If you select a self zone, you cannot configure inspect policing.
Complete the following tasks:

1. Create at least one security zone.
2. Assign interfaces to security zones.
3. Define zone pairs.
Before you create zones, think about what should constitute the zones. The general guideline is
that you should group together interfaces that are similar when they are viewed from a security
perspective.
Follow these steps to create a security zone, assign an interface to a security zone, and define a
zone-pair.
Step 1
Create a security zone to which interfaces can be assigned.

router(config)# zone security zone-name
5-116
Syntax Description
zone-name
Name of the security zone

You can enter up to 256 alphanumeric characters.
It is recommended that you create at least two security zones so that you can create a zone pair.
If you create only one zone, you can use the default system-defined self zone. The self zone
cannot be used for traffic going through a router.
Assign an Interface to a Security Zone

Follow this procedure to assign an interface to a security zone.
Step 2
Assign an interface to the security zone (as discussed here). You now need to assign
an interface to a security zone that belongs to a zone pair.
Follow these substeps:

Specify an interface for configuration and enter interface configuration mode.
router(config)# interface interface-id
Assign the interface to a specified security zone.

router(config-if)# zone-member security zone-name
Syntax Description
zone-name
Name of the security zone to which an interface is attached
The zone-member security command puts an interface into a security zone. When an interface
is in a security zone, all traffic to and from that interface (except traffic going to the router or
initiated by the router) is dropped by default. To permit traffic through an interface that is a
zone member, you must make that zone part of a zone pair to which you apply a policy. If the
policy permits traffic (via inspect or pass actions), traffic can flow through the interface.
Creating Zone Pairs

Follow this procedure to configure zone pairs from the security zones you created in the
previous steps:
Step 3
Create a zone pair.

router(config)# zone-pair security zone-pair-name {source
source-zone-name | self} destination [self | destination-zonename]
Syntax Description
zone-pair-name
Name of the zone being attached to an interface
source source-zonename
Name of the router from which traffic is originating
destination
destination-zone-name
Name of the router from which traffic is bound
self
System-defined zone; indicates whether traffic will be going to or from a router

5-117
This command creates a zone pair, which permits a unidirectional firewall policy between a
pair of security zones.
If you created only one zone, you can use the system-defined default zone (self) as part of a
zone pair. Such a zone pair and its associated policy apply to traffic directed to the router or
generated by the router. It does not affect traffic through the router.
You can specify the self keyword for the source or destination, but not for both. You cannot
modify or unconfigure the self zone.
Class Map Configuration

Classify traffic
R1(config)# class-map type inspect match-any myprotocols
R1(config-cmap)# match protocol dns
SNRS v2.05-21
Configuring a Class Map for a Layer 3 and Layer 4 Firewall

Policy
Follow these steps to configure a class map for classifying network traffic:
Step 1
Create a Layer 3 or Layer 4 inspect type class map and enter class map configuration
mode.
router(config)# class-map type inspect [match-any | match-all]
class-map-name
Syntax Description
match-any |
match-all
(Optional) Determines how packets are evaluated when multiple match criteria exist
Packets must meet one of the match criteria (match-any) or all of the match criteria (matchall) to be considered a member of the class.
Note: The match-all keyword is available only with Layer 3, Layer 4, and HTTP type class
maps.
class-map-name
Name of the class map

The name can be a maximum of 40 alphanumeric characters. The class map name is used
for the class map and to configure policy for the class in the policy map.
5-118
You can configure a top-level (Layer 3 or Layer 4) class map, which allows you to identify the
traffic stream at a high level, by issuing the match access-group and match protocol
commands. These class maps cannot be used to classify traffic at the application level (the
Layer 7 level).
Step 2
Configure the match criteria for a class map based on the ACL name or number.
router(config-cmap)# match access-group {access-group | name
access-group-name}
Syntax Description
access-group
Numbered ACL whose contents are used as the match criteria against which
packets are checked to determine if they belong to this class
An ACL number can be a number from 1 to 2699.
name accessgroup-name
Named ACL whose contents are used as the match criteria against which packets
are checked to determine if they belong to this class
The name can be a maximum of 40 alphanumeric characters.
The match access-group command specifies a numbered or named ACL whose contents are
used as the match criteria against which packets are checked to determine if they belong to the
class specified by the class map.
Step 3
Configure the match criteria for a class map on the basis of a specified protocol.
router(config-cmap)# match protocol protocol-name
Syntax Description
protocolname
Name of the protocol used as a matching criterion

Note: All of the protocols listed in the PAM table are available for matching. Issue a
show ip port-map command to view this list.
The match protocol command specifies the name of a protocol to be used as the match criteria
against which packets are checked to determine if they belong to the class specified by the class
map.
If you enter the match protocol (zone) command under the class-map type inspect command,
the PAMs are honored when the protocol field in the packet is matched against this command.
All the port mappings configured in PAM appear under this.
Step 4
(Optional) Specify a previously defined class as the match criteria for a class map.
router(config-cmap)# match class-map class-map-name
Syntax Description
class-map-name
Name of the traffic class to use as a match criterion
The only method of including both match-any and match-all characteristics in a single traffic
class is to use the match class-map command. To combine match-any and match-all
characteristics into a single class, a traffic class created with the match-any instruction must
use a class configured with the match-all instruction as a match criterion (through the match
class-map command), or vice versa.

5-119
You can also use the match class-map command to nest traffic classes within one another,
saving users the overhead of re-creating a new traffic class when most of the information exists
in a previously configured traffic class.
Policy Map Configuration

Create traffic policy
R1(config)# policy-map type inspect snrsfwpolicy
R1(config-pmap)# class type inspect snrsprotocols
R1(config-pmap-c)# inspect
SNRS v2.05-22
Creating a Policy Map for a Layer 3 and Layer 4 Firewall Policy

Follow these steps to create a policy map for a Layer 3 and Layer 4 firewall policy that will be
attached to zone pairs.
Note
Step 1
If you are creating an inspect type policy map, note that only the following actions are
allowed: drop, inspect, police, pass, service-policy, and urlfilter.
Create a Layer 3 and Layer 4 inspect type policy map and enter policy map
configuration mode.
router(config)# policy-map type inspect policy-map-name
Step 2
Specify the traffic (class) on which an action is to be performed.

router(config-pmap)# class type inspect class-name
Step 3
Enable Cisco IOS stateful packet inspection.

router(config-pmap-c)# inspect parameter-map-name
5-120
Parameter Map Configuration

Modify inspection parameters
R1(config)# parameter-map type inspect myparams
R1(config-profile)# alert on
R1(config-profile)# audit-trail on
R1(config-profile)# max-incomplete high 1000
R1(config-profile)# tcp idle-time 360
SNRS v2.05-23
Configuring Cisco IOS Zone-Based Policy Firewall Parameter

Maps
Inspect type parameter maps are used to configure connecting thresholds, timeouts, and other
parameters pertaining to the inspect action.
Parameter maps specify inspection behavior for Cisco IOS zone-based policy firewall, for
parameters such as DoS protection, session and connection timers, and logging settings.
Depending on your policy, you can configure one of four types of parameter maps. If you are
configuring a URL filter type or protocol-specific type policy, you must configure a parameter
map, as appropriate. However, a parameter map is optional if you are using an inspect type
policy.
The four types of parameter maps are as follows:
An inspect parameter map
A URL filter parameter map
A mitigation parameter map
A TMS parameter map
To configure a parameter map, complete these steps:

Step 1
Create a parameter map of type inspect and enter configuration mode.
Step 2
router(config)# parameter-map type inspect parameter-map-name
Step 3
Assign the parameters.
Step 4
router(config-profile)# parameter

5-121
Attaching a Policy Map to a Zone Pair

To attach a policy map to a zone pair, follow these steps.
Step 1
Enter zone pair configuration mode.

router(config)# zone-pair security zone-pair-name source zone1
destination zone2
Step 2
Attach a firewall policy map to the zone pair.

router(config-sec-zone-pair)# service-policy type inspect
policy-map-name
Syntax Description
policy-map-name
Name of the policy map

The name can be a maximum of 40 alphanumeric characters.
Use the service-policy type inspect command to attach a policy map and its associated actions
to a zone pair. Enter this command after entering the zone-pair security command.
5-122
Configuration Examples
This section shows some examples of Cisco IOS zone-based policy firewall configurations.
Two-Interface Cisco IOS Zone-Based

Policy Firewall Configuration
List of
services
class-map type inspect match-any snrsprotocols
defined in the
match protocol http
firewall policy
match protocol smtp
match protocol dns
match access group 101
!
policy-map type inspect snrsfwpolicy
Apply action (inspect =
class type inspect snrsprotocols
stateful inspection)
inspect
!
zone security private
Zones created
zone security internet
!
interface fastethernet 0/0
Interfaces assigned to
zone-member security private
zones
!
interface fastethernet 0/1
zone-member security internet
!
zone-pair security priv-to-internet source private destination internet
service-policy type inspect snrsfwpolicy
Inspection applied
!
from private to
public zones
SNRS v2.05-24
This is an example of a basic two-interface configuration using default inspection parameters.

5-123
Drop Specific Traffic

Drop all traffic originated by 192.168.1.13 going from zone
private to zone internet
!
Specify interesting trafficAll
access-list 199 permit ip host 192.168.1.13 any
traffic that matches ACL 199
!
class-map type inspect bad-host
Specify the traffic (class) on
which an action is to be
!
performed
policy-map type inspect snrspolicy
class type inspect bad-host
The drop action, performed on
drop
traffic specified by class bad-host
!
zone-pair security priv-to-internet source private destination internet
service-policy type inspect snrspolicy
!
SNRS v2.05-25
This example shows how to drop specific trafficfor example, from a compromised host.
5-124
Traffic Inspection Options

!
class-map type inspect match-all inspect-traffic
Specifies all
match protocol tcp
TCP traffic
!
parameter-map type inspect snrsparams
audit-trail on
Optional
tcp synwait-time 10
parameters for
inspection
!
Inspect action with
class type inspect inspect-traffic
specified optional
inspect snrsparams
parameters
!
zone-pair security in-out source in-zone dest out-zone
service-policy type inspect snrspolicy
!
SNRS v2.05-26
This example shows how to adjust some of the inspection parameters using a parameter map.

5-125
Private-Internet-DMZ
!
class-map type inspect insp-traffic
match protocol http
match protocol icmp
match protocol tcp
class-map type inspect match-all myhttp
match protocol http
!
policy-map type inspect p-inout
class type inspect insp-traffic
inspect
policy-map type inspect webtraffic
class type inspect myhttp
inspect
!
zone-pair security priv-internet source private destination internet
service-policy type inspect p-inout
zone-pair security internet-dmz source internet destination dmz
service-policy type inspect webtraffic
!
access-list 199 permit tcp any host 172.16.1.10
SNRS v2.05-27
This example shows a basic DMZ configuration. It shows policies for the inside-to-Internet and
the Internet-to-DMZ traffic flows.
5-126
SMTP InspectionBasic
!
class-map type inspect c1
match protocol smtp
!
policy-map type inspect mypolicy
class type inspect c1
inspect
Can include other

match
protocol/accessgroup statements
SNRS v2.05-28
This example shows a basic SMTP inspection policy. This model exhibits the same behavior as
the old ip inspect name command and holds true for all protocols in the PAM table.

5-127
SMTPwith parameter map
!
match protocol smtp
!
parameter-map type inspect snrsparams
alert on
audit-trail on
tcp idle-time 360
!
inspect snrsparams
!
SNRS v2.05-29
This example shows how to inspect SMTP and adjust some of the parameters for SMTP
inspection. The audit-trail, alert, and timeout keywords are part of the parameter-map (type
inspect) command.
5-128
SMTPwith DPI
!
class-map type inspect smtp huge-mails
match data-length gt 100000
!
Layer 7
policy-map type inspect smtp snrssmtp-policy
Policy
class type inspect smtp huge-mails
reset
!
match protocol smtp
!
Layer
3/Layer 4
Policy
inspect
Basic
inspection
service-policy inspect smtp snrssmtp-policy
!
More application-level
control (via Layer 7/DPI
policy-map)
SNRS v2.05-30
This example shows how to apply DPI using a Layer 7 policy map nested with a top-level
Layer 3/Layer 4 policy.

5-129
Verifying Cisco IOS Zone-Based Policy Firewall

This topic describes some commands used to verify Cisco IOS zone-based policy firewall
Verification Commands
show zone security
show zone-pair security
show policy-map type inspect
show policy-map type inspect zone-pair sessions
Examines the firewall state table
show class-map type inspect
SNRS v2.05-31
Cisco IOS zone-based policy firewall introduces new commands to view policy configuration
and monitor firewall activity.
Display zone descriptions and the interfaces contained in a specified zone using the show zone
security [<zone-name>] command.
When the zone name is not included, the command displays the information of all the zones
configured.
To display the source zone, destination zone, and policy attached to the zone pair, use the
show zone-pair security [source <source-zone-name>] [destination <destination-zonename>] command.
When no source or destination is specified, all the zone pairs with source, destination, and the
associated policy are displayed. When only the source or destination zone is mentioned, all the
zone pairs that contain this zone as the source or destination are displayed.
To display a specified policy map, use the show policy-map type inspect [<policy-map-name>
[class <class-map-name>]] command.
When the name of a policy map is not specified, it displays all policy maps of type inspect
(including Layer 7 policy maps that contain a subtype).
5-130
Summary
Summary
The older Cisco IOS stateful inspection process suffered from some
limitations.
The new Cisco IOS Zone-based policy firewall offers intuitive policies for
multiple-interface routers, increased granularity of firewall policy
application, and a default deny-all policy.
A security zone is a group of interfaces that have similar functions or
features and a zone-pair allows you to specify a unidirectional firewall
policy between two security zones.
Policies are defined using:
Class maps to specify traffic
Policy maps to define actions
There are several steps required to configure a Cisco IOS zone-based
policy firewall.
Cisco IOS based policy zone firewall introduces new commands to view
policy configuration and monitor firewall activity.
SNRS v2.05-32
References
Cisco Systems, Inc. Cisco IOS Software Releases 12.4 T: Zone-Based Policy Firewall.
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a008060f6dd.h
tml.
Cisco Systems, Inc. Cisco IOS Software Releases 12.4 Mainline: Zone-Based Policy
Firewall Design Guide.
http://www.cisco.com/en/US/products/ps6350/products_feature_guide09186a008072c6e3.
html#wp1066679

5-131
5-132
Lesson 4

Overview
This lesson describes the Cisco IOS Firewall Authentication Proxy (auth-prox) feature as part
of the Cisco IOS Firewall. Cisco IOS Firewall authentication proxy provides dynamic, per-user
authentication and authorization, authenticating users against industry standard TACACS+ and
RADIUS authentication protocols. Authenticating and authorizing connections by users
provides more robust protection against network attacks. You will learn how to configure a
Cisco router to authenticate using Cisco IOS Firewall authentication proxy.
Objectives
Upon completing this lesson, you will be able to configure Cisco IOS Firewall authentication
proxy on a Cisco router. This ability includes being able to meet these objectives:
Describe how system administrators can use Cisco IOS Firewall authentication proxy to
allow specific security policies on a per-user basis for TACACS+ and RADIUS servers
Describe how to provide authentication and authorization for the Cisco IOS Firewall
authentication proxy using Cisco Secure ACS for Windows
Describe how to configure authentication proxy on a Cisco IOS router

This topic describes the features of the Cisco IOS Firewall authentication proxy.
What Is the Authentication Proxy?

HTTP, HTTPS, FTP, and Telnet authentication
Provides dynamic, per-user authentication and authorization via
TACACS+ and RADIUS protocols
Once authenticated, all types of application traffic can be
authorized
Works on any interface type for inbound or outbound traffic
SNRS v2.05-2
The Cisco IOS Firewall authentication proxy feature enables network administrators to apply
specific security policies on a per-user basis. Authentication proxy provides dynamic, per-user
authentication and authorization, authenticating users with industry standard TACACS+ and
RADIUS authentication protocols. Previously, user identity and related authorized access were
associated with a user IP address, or a single security policy had to be applied to an entire user
group or subnet. Now, users can be identified and authorized on the basis of their per-user
policy, and access privileges can be tailored on an individual basis, as opposed to a general
policy applied across multiple users. Authenticating and authorizing connections by users
provides more robust protection against network attacks.
Auth-prox can provide authentication and authorization for the following protocols.
HTTP
HTTPS
FTP
Telnet
Auth-prox can be applied on any interface.
5-134
Using Cisco IOS Firewall Authentication

Proxy
AAA
Server
Web
Server
Client
Host
Internet
FTP
Server
Telnet
Server
Client
Host
SNRS v2.05-3
With the authentication proxy feature, users can log in to the network or access the Internet via
HTTP, secure HTTP (HTTPS), FTP, or Telnet, and their specific access profiles are
automatically retrieved and applied from a Cisco Secure Access Control Server (ACS) or other
RADIUS or TACACS+ authentication server. The user profiles are active only when there is
active traffic from the authenticated users.
The Cisco IOS Firewall authentication proxy is compatible with other Cisco IOS security
features such as Network Address Translation (NAT), Context-Based Access Control (CBAC),
IP Security (IPsec) encryption, and Cisco Virtual Private Network (VPN) Client.
5-135
Login screen
SNRS v2.05-4
When a user initiates an HTTP, HTTPS, FTP, or Telnet session through the firewall, it triggers
the Cisco IOS Firewall authentication proxy. The Cisco IOS Firewall authentication proxy first
checks to see whether the user has been authenticated. If a valid authentication entry exists for
the user, the session is allowed and no further intervention is required by the Cisco IOS
Firewall authentication proxy. If no entry exists, the Cisco IOS Firewall authentication proxy
responds to the connection request by prompting the user for a username and password.
Users must successfully authenticate with the authentication server by entering a valid
username and password. If the authentication succeeds, the user authorization profile is
retrieved from the authentication, authorization, and accounting (AAA) server. The Cisco IOS
Firewall authentication proxy uses the information in this profile to create dynamic access
control entries (ACEs) and add them to the inbound (input) access control list (ACL) of an
input interface, and to the outbound (output) ACL of an output interface if an output ACL
exists at the interface. By doing this, the firewall allows authenticated users access to the
network as permitted by the authorization profile.
If the authentication fails, the authentication proxy reports the failure to the user and prompts
the user for a configurable number of retries. If the user fails to authenticate after five attempts,
the user must wait two minutes and initiate another HTTP session to trigger authentication
proxy.
The login page is refreshed each time the user makes requests to access information from a web
server.
The authentication proxy customizes each of the access list entries in the user profile by
replacing the source IP addresses in the downloaded access list with the source IP address of
the authenticated host.
At the same time that dynamic ACEs are added to the interface configuration, the
authentication proxy sends a message to the user confirming that the login was successful.
5-136
The authentication proxy sets up an inactivity (idle) timer for each user profile. As long as there
is activity through the firewall, new traffic initiated from the user host does not trigger the
Cisco IOS Firewall authentication proxy, and all authorized user traffic is permitted access
through the firewall.
If the idle timer expires, the Cisco IOS Firewall authentication proxy removes the user profile
information and dynamic ACL entries. When this happens, traffic from the client host is
blocked. The user must initiate another HTTP, HTTPS, FTP, or Telnet connection to trigger the
Cisco IOS Firewall authentication proxy.

5-137
Supported AAA Servers
TACACS+
Cisco Secure
ACS for Windows
NT/2000
Cisco Secure
ACS UNIX
RADIUS
Cisco Secure
ACS for Windows
NT/2000
TACACS+
Freeware
Cisco Secure
ACS UNIX
Lucent
SNRS v2.05-5
The Cisco IOS Firewall authentication proxy supports the following AAA protocols and
servers:
5-138
TACACS+
Cisco Secure ACS for Windows
Cisco Secure ACS for UNIX
TACACS+ freeware
RADIUS
Cisco Secure ACS for Windows
Cisco Secure ACS for UNIX
Other standard RADIUS servers
Applying the Authentication Proxy

This section describes where to apply the authentication proxy.
Cisco IOS Firewall Applying

For inbound proxy
authentication, add an
ACL to
block inward traffic from
the outside.
Outside
For outbound proxy

authentication, add an
ACL to block inward
traffic from the inside,
except from the AAA
server.
Inside
Web,
FTP, or
Telnet
Server
User
User
For inbound proxy

authentication, enable the
Cisco IOS Firewall
authentication proxy to
intercept inward HTTP,
HTTPS, FTP, or Telnet
traffic from the outside.
For outbound proxy

authentication, enable
the Cisco IOS Firewall
authentication proxy to
intercept inward HTTP,
HTTPS, FTP, or Telnet
traffic from the inside.
AAA
Server
SNRS v2.05-6
Apply the Cisco IOS Firewall authentication proxy in the inward direction at any interface on
the router where you want per-user authentication and authorization. Applying the Cisco IOS
Firewall authentication proxy inward at an interface causes it to intercept the initial connection
request from a user before that request is subjected to any other processing by the firewall. If
the user fails to authenticate with the AAA server, the connection request is dropped.
How you apply the Cisco IOS Firewall authentication proxy depends on your security policy.
For example, you can block all traffic through an interface and enable the Cisco IOS Firewall
authentication proxy feature to require authentication and authorization for all user-initiated
HTTP, HTTPS, FTP, or Telnet connections. Users are authorized for services only after
successful authentication with the AAA server. The Cisco IOS Firewall authentication proxy
feature also enables you to use standard ACLs to specify a host or group of hosts whose initial
HTTP, HTTPS, FTP, or Telnet traffic triggers the proxy.
The figure shows two cases:
The outbound Cisco IOS Firewall authentication proxy applied at the inside interface
The inbound Cisco IOS Firewall authentication proxy applied at the outside interface

5-139
AAA Server Configuration

This topic describes how to configure the Cisco Secure ACS to provide authentication and
authorization for the Cisco IOS Firewall authentication proxy.
Create auth-proxy Service in the Cisco

Secure ACS
Enter the new

service:
auth-proxy.
SNRS v2.05-7
To support the Cisco IOS Firewall authentication proxy, configure the AAA authorization
auth-proxy service on the Cisco Secure ACS for Windows AAA server. This action creates a
new section in the Group Setup window in which user profiles can be created. It does not
interfere with other types of services that the AAA server may have.
This lesson uses the Cisco Secure ACS for Windows (using the TACACS+ protocol) as an
example of how to configure the AAA server.
Complete the following steps to add authorization rules for specific services in the Cisco
Secure ACS for Windows:
5-140
Step 1
In the menu bar, click Interface Configuration. The Interface Configuration

window opens.
Step 2
Click TACACS+ (Cisco IOS).
Step 3
Scroll down in the TACACS+ Services window until you find the New Services
group box.
Step 4
Note
Check the check box closest to the service field.

Depending on which options your Cisco Secure ACS is running, there may be one or two
check boxes in front of the service fields. The presence of two check boxes indicates
support for both user and group settings. Making check box selections simply indicates
where the configuration of this feature can be performed; in other words, it can be done at
the group or user level or at both levels. If there is only one check box, check it (as shown in
the figure).
Step 5
Enter auth-proxy in the first empty Service field next to the check box that you just
checked and click Submit. For HTTP or HTTPS authentication, the corresponding
Protocol field should be empty. For FTP and Telnet authentication, enter ip in the
Protocol field.
Step 6
Scroll down to Advanced Configuration Options and check the Advanced

TACACS+ Features check box, if it is not already checked.
Step 7
Click Submit when finished.

5-141
Create a User Authorization Profile in the

Cisco Secure ACS
Check the
auth-proxy.
Check the
Custom attributes
checkbox.
proxyacl#1=permit tcp any any

priv-lvl=15
Enter ACLs to apply

after the user
authenticates.
Enter the privilege
level of the user; it
must be 15 for all
users.
5-142
SNRS v2.05-8
Step 8
In the navigation bar, click Group Setup. The Group Setup window opens.
Step 9
Choose your group from the drop-down menu and click Edit Settings.
Step 10
Scroll down in the Group Setup window until you find the newly created auth-proxy
service.
Step 11
Check the auth-proxy check box.
Step 12
Check the Custom Attributes check box.
Step 13
Using the proxyacl#n format described in the discussion that follows, enter ACLs in
the field below the Custom Attributes check box. These ACLs will be applied after
the user authenticates.
Step 14
Enter the privilege level of the user (must be 15 for all users) using the format
shown in the discussion that follows.
Step 15
Click Submit + Restart when finished.
User Authorization Profiles

proxyacl#1=permit
proxyacl#2=permit
proxyacl#3=permit
proxyacl#4=permit
proxyacl#5=permit
priv-lvl=15
tcp
icmp
tcp
tcp
tcp
any
any
any
any
any
any eq 443
host 172.30.0.50
any eq ftp
any eq smtp
any eq telnet
HTTPS
Defines the allowable protocols, services, and

destination addresses.
The source address is always any and is
replaced in the router with the IP address of
host making the request.
Privilege level must be set to 15 for all users.
SNRS v2.05-9
Use the proxyacl#n attribute when configuring the ACLs in the profile. The proxyacl#n
attribute is for both RADIUS and TACACS+ attribute-value pairs. The ACLs in the user profile
on the AAA server must have permit access commands only. Set the source address to any in
each of the user profile ACL entries. The source address in the ACLs is replaced with the
source IP address of the host making the authentication proxy request when the user profile is
downloaded to the firewall.
The syntax of the ACLs to enter in the Custom Attributes field is as follows:
proxyacl#n=permit protocol any {any | host ip_addr | ip_addr
wildcard_mask} [eq auth_service]
protocol
Keyword indicating the protocol to allow users to access: TCP, User

Datagram Protocol (UDP), or Internet Control Message Protocol
(ICMP)
any
Indicates any hosts

The first any keyword after the protocol is mandatory. This indicates
any source IP address, which is actually replaced with the IP address
of the user that requests authorization in the ACL applied in the router.
host ip_addr
IP address of a specific host that users can access
ip_addr wildcard
mask
IP address and wildcard mask for a network that users can access
eq auth_service
Specific service that users are allowed to access
Use the priv-lvl=15 command to configure the privilege level of the authenticated user. The
privilege level must be set to 15 for all users.

5-143

Configuration
This topic describes how to configure Cisco IOS Firewall authentication proxy on a Cisco IOS
router.
Authentication Proxy Configuration

Configure AAA
Configure the HTTP server
Create the authentication proxy rule
Apply the Cisco IOS Firewall authentication proxy rule to an
interface
Verify the Cisco IOS Firewall authentication proxy
SNRS v2.05-10
There are several tasks required to configure Cisco IOS Firewall authentication proxy.
To configure the Cisco IOS Firewall authentication proxy feature, perform the following tasks:
5-144
Configure AAA
Configure the HTTP server
Configure the Cisco IOS Firewall authentication proxy
Verify the Cisco IOS Firewall authentication proxy
AAA Configuration
This section describes how to configure the Cisco IOS Firewall to work with a AAA server .
Enable AAA
router(config)# aaa new-model
router(config)# aaa authentication login default group tacacs+
router(config)# aaa authorization auth-proxy default group tacacs+
Enables AAA functionality on the router
SNRS v2.05-11
To configure the router to communicate with the Cisco Secure ACS server, you must configure
AAA and specify the TACCAS+ or RADIUS server addresses and key used for communication
with the Cisco Secure ACS server.
Use the aaa new-model global configuration command to enable the AAA access control
system. Use the no form of this command to disable the AAA access control model.
Note
After you have enabled AAA, TACACS and extended TACACS commands are no longer
available. If you initialize AAA functionality and later decide to use TACACS or extended
TACACS, issue the no version of this command and then enable the version of TACACS
that you want to use.
The syntax of the aaa new-model command is as follows:

aaa new-model
This command has no arguments and by default, the aaa new-model command is not enabled.
To set AAA authentication, use the aaa authentication login global configuration command.
Use the no form of this command to disable AAA authentication.
The syntax of the aaa authentication login command is as follows:
aaa authentication login default method1 [method2]

5-145
Syntax Description
method1, method2
The following are the authentication protocols to use: group

TACACS+, group RADIUS, or both.
To set AAA authorization, use the aaa authorization auth-proxy global configuration
command. Use the no form of this command to disable AAA authorization.
The syntax of the aaa authorization auth-proxy command is as follows:
aaa authorization auth-proxy default method1 [method2]
Syntax Description
method1, method2
5-146
The following are the authorization protocols to use: group

TACACS+, group RADIUS, or both.
Define a TACACS+ Server and Its Key

router(config)# tacacs-server host 10.0.0.3
router(config)# tacacs-server key secretkey
Specifies the TACACS+ server IP address

Specifies the TACACS+ server key
SNRS v2.05-12
To specify the IP address of a TACACS+ server, use the tacacs-server host global
configuration command. Use the no form of this command to delete the specified IP address.
You can use multiple tacacs-server host commands to specify additional servers. The Cisco
IOS Firewall software searches for servers in the order in which you specify them.
The syntax of the tacacs-server host command is as follows:
tacacs-server host ip_addr
Syntax Description
ip_addr
IP address of the TACACS+ server
To set the authentication encryption key used for all TACACS+ communications between the
Cisco IOS Firewall router and the AAA server, use the tacacs-server key global configuration
command. Use the no form of this command to disable the key.
Note
The key entered must match the key used on the AAA server. All leading spaces are
ignored; spaces within and at the end of the key are not. If you use spaces in your key, do
not enclose the key in quotation marks unless the quotation marks themselves are part of
the key.
The syntax of the tacacs-server key command is as follows:

tacacs-server key string
Syntax Description
string
Key used for authentication and encryption

5-147
Define a RADIUS Server and Its Key

router(config)# radius-server host 10.0.0.3
router(config)# radius-server key secretkey
Specifies the RADIUS server IP address

Specifies the RADIUS server key
SNRS v2.05-13
To specify the IP address of a RADIUS server, use the radius-server host global configuration
command. Use the no form of this command to delete the specified IP address. You can use
multiple radius-server host commands to specify additional servers. The Cisco IOS Firewall
software searches for servers in the order in which you specify them.
The syntax of the radius-server host command is as follows:
radius-server host ip_addr
Syntax Description
ip_addr
IP address of the RADIUS server
To set the authentication encryption key used for all RADIUS communications between the
Cisco IOS Firewall router and the AAA server, use the radius-server key global configuration
command. Use the no form of this command to disable the key.
Note
The key entered must match the key used on the AAA server. All leading spaces are
ignored; spaces within and at the end of the key are not. If you use spaces in your key, do
not enclose the key in quotation marks unless the quotation marks themselves are part of
the key.
The syntax of the radius-server key command is as follows:

radius-server key string
Syntax Description
string
5-148
Key used for authentication and encryption
Allow AAA Traffic to the Router
AAA Server
router(config)# access-list 111 permit tcp host 10.0.1.12 eq tacacs

host 10.0.1.2
Router interface
router(config)# access-list 111 permit icmp any any
router(config)# access-list 111 deny ip any any
Create an ACL to permit TACACS+ traffic from the AAA server to

the firewall
Source address = AAA server
Destination address = interface where the AAA server resides
May want to permit ICMP

Deny all other traffic
Apply the ACL to the interface on the side where the AAA server
resides
SNRS v2.05-14
All traffic requiring authentication and authorization should be denied by the router using
extended ACLs. Upon successful authentication, dynamic ACEs will be inserted into the ACLs
to permit only the traffic authorized by the user profile. The Cisco IOS Firewall authentication
proxy customizes each of the ACEs in the user profile by replacing the source IP addresses in
the downloaded ACL with the source IP address of the authenticated host.
An extended ACL should be applied to the inbound direction of the interface that is configured
for proxy authentication. All other ACLs that restrict traffic in the direction of authenticated
traffic flow should be extended ACLs so that proxy authentication can dynamically update the
ACEs as necessary to permit authorized traffic to pass.
Note
Proxy authentication does not update ACLs blocking the return traffic. If traffic in the
opposite direction must be restricted, use static ACLs to manually permit return traffic for
authorized traffic. Preferably, use CBAC to dynamically create ACLs to securely permit
return traffic for proxy-authenticated sessions.
If the AAA server resides on the same interface where proxy authentication is configured, you
need to configure and apply an ACL to permit TACACS+ or RADIUS traffic from the AAA
server to the Cisco IOS Firewall.
Use the following guidelines when writing the extended ACL:
To permit AAA server communication, create an ACE where the source address is the
AAA server and the destination address is the interface where the AAA server resides.
You may want to permit some traffic without requiring authentication, such as ICMP or
routing updates.
Deny all other traffic.
Apply the extended ACL to the inbound direction of the interface where proxy
authentication is configured.

5-149
Configure the HTTP Server

This section describes how to configure the HTTP server on the router to work with
authentication proxy.
Enable the Router HTTP or HTTPS

Server for AAA
router(config)# ip http server
router(config)# ip http secure-server
router(config)# ip http authentication aaa
Enables the HTTP server on the router

Proxy uses HTTP server for communication with a
client
Enables the HTTPS server on the router
Sets the HTTP server authentication method to AAA
SNRS v2.05-15
To use the Cisco IOS Firewall authentication proxy with HTTP and HTTPS, use the ip http
server and ip http secure-server commands to enable the HTTP servers on the router and the
ip http authentication aaa command to make the HTTP server use AAA for authentication.
The syntax of the ip http server command is as follows:
ip http server
This command has no arguments.

The syntax of the ip http authentication aaa command is as follows:
ip http authentication aaa
This command has no arguments.

The HTTPS feature requires a Cisco IOS crypto image. Enabling this feature supports these
options:
HTTP-initiated sessions normally exchange the username and password in cleartext; this
exchange is encrypted when using HTTPS.
HTTPS-initiated sessions are proxy-authenticated.
To use the Cisco IOS Firewall authentication proxy with HTTPS, use the ip http secure-server
command to enable the HTTP server on the router and the ip http authentication aaa
command to make the HTTP server use AAA for authentication.
The syntax of the ip http secure-server command is as follows:
5-150
ip http secure-server
This command has no arguments or keywords.
Cisco IOS Firewall Authentication Proxy Rule Configuration

This section describes how to create a Cisco IOS Firewall authentication proxy rule and apply
the rule to an interface.
Set Global Timers

router(config)# ip auth-proxy inactivity-timer 120
router(config)# ip auth-proxy name APRULE http
router(config-if)# ip auth-proxy aprule
Authentication inactivity timer in minutes (default = 60

minutes)
Creates an authorization proxy rule
Applies an authorization proxy rule to an interface
For outbound authentication, apply to inside interface
For inbound authentication, apply to outside interface
SNRS v2.05-16
Here are some of the tasks to configure the Cisco IOS Firewall authentication proxy parameters
on the router:
Set global timers
Define auth-prox rules
Apply auth-prox rule to an interface
To set the Cisco IOS Firewall authentication proxy inactivity timeout value (the length of time
that an authentication cache entry, along with its associated dynamic user ACL, is managed
after a period of inactivity), use the ip auth-proxy inactivity-timer global configuration
command. To set the default value, use the no form of this command. The inactivity-timer
keyword replaces the auth-cache-time command in earlier Cisco IOS Software releases; some
versions support both commands. Use this command to set the global idle timeout value for the
Cisco IOS Firewall authentication proxy. You must set the value of the inactivity-timer min
option to a higher value than the idle timeout of any CBAC protocols. Otherwise, when the
Cisco IOS Firewall authentication proxy removes the user profile along with the associated
dynamic user ACLs, there might be some idle connections monitored by CBAC. Removing
these user-specific ACLs could cause those idle connections to stop responding. If the CBAC
idle timeout value is shorter, CBAC resets these connections when the CBAC idle timeout
expires, which is before the Cisco IOS Firewall authentication proxy removes the user profile.

5-151
The absolute-timer min option allows users to configure a window during which the Cisco
IOS Firewall authentication proxy on the enabled interface is active. Once the absolute timer
expires, the Cisco IOS Firewall authentication proxy will be disabled regardless of any activity.
The global absolute timeout value can be overridden by the local (per protocol) value, which is
enabled via the ip auth-proxy name command. The absolute timer is turned off by default, and
the Cisco IOS Firewall authentication proxy is enabled indefinitely.
The syntax of the ip auth-proxy command is as follows:
ip auth-proxy {inactivity-timer min | absolute-timer min}
Syntax Description
inactivity-timer min
This command specifies the length of time in minutes that an

authentication cache entry, along with its associated dynamic user
ACL, is managed after a period of inactivity. Enter a value in the
range of 1 to 35,791. The default value is 60 minutes.
absolute-timer min
This command specifies a window in which the authentication

proxy on the enabled interface is active. Enter a value in the range
of 1 to 35,791 minutes (45 and a half days). The default value is 0
minutes.
To create a Cisco IOS Firewall authentication proxy rule, use the ip auth-proxy name global
configuration command.
This command creates a named authentication proxy rule, and it allows you to associate that
rule with an access control list (ACL), providing control over which hosts use the
authentication proxy. The rule is applied to an interface on a router using the ip auth-proxy
command.
Use the inactivity-timer min option to override the global the authentication proxy cache timer.
This option provides control over timeout values for specific authentication proxy rules. The
authentication proxy cache timer monitors the length of time (in minutes) that an authentication
cache entry, along with its associated dynamic user access control list, is managed after a
period of inactivity. When that period of inactivity (idle time) expires, the authentication entry
and the associated dynamic access lists are deleted.
Use the list option to associate a set of specific IP addresses or a named ACL with the ip authproxy name command.
Use the no form of this command with a rule name to remove the authentication proxy rules. If
no rule is specified, the no form of this command removes all the authentication rules on the
router, and disables the proxy at all interfaces.
Note
5-152
You must use the aaa authorization auth-proxy command together with the ip auth-proxy
name command. Together these commands set up the authorization policy to be retrieved
by the firewall.
The syntax of the ip auth-proxy name command is as follows:

ip auth-proxy name auth-proxy-name {ftp | http | telnet} [inactivitytimer min] [absolute-timer min] [list {acl | acl-name}] [servicepolicy type tag {service-policy-name}]
Syntax Description
auth-proxy-name
This argument associates a name with a Cisco IOS Firewall authentication

proxy rule. Enter a name of up to 16 alphanumeric characters.
ftp
This command specifies FTP to trigger the authentication proxy.
http
This command specifies HTTP to trigger the authentication proxy.
telnet
This command specifies Telnet to trigger the authentication proxy.
inactivity-timer
min
(Optional) This command overrides the global authentication proxy cache

timer for a specific authentication proxy name, offering more control over
timeout values. Enter a value in the range of 1 to 2,147,483,647. The default
value is equal to the value set with the ip auth-proxy command. This
command replaces the auth-cache-time command in earlier Cisco IOS
Software releases; some versions support both commands.
absolute-timer
min
(Optional) This command specifies a window in which the Cisco IOS

Firewall authentication proxy on the enabled interface is active. Enter a
value in the range of 1 to 65,535 minutes (45 and a half days). The default
value is 0 minutes.
list {acl | aclname}
(Optional) This command specifies a standard (199), extended (1199), or

named IP ACL to use with the Cisco IOS Firewall authentication proxy. With
this option, the Cisco IOS Firewall authentication proxy is applied only to
those hosts in the ACL. If no list is specified, all connections initiating HTTP,
FTP, or Telnet traffic arriving at the interface are subject to authentication.
service-policy
type tag
(Optional) This command specifies that a control plane service policy is to

be configured.
service-policyname
(Optional) This is the name of the control plane tag service policy that is
configured using the policy-map type control tag {policy-map-name}
command, keyword, and argument. This policy map is used to apply the
actions on the host when a tag is received.
Applying Auth-prox to an Interface

Use the ip auth-proxy command to enable the named authentication proxy rule at the firewall
interface. Traffic passing through the interface from hosts with an IP address matching the
standard access list and protocol type (HTTP, FTP, or Telnet) is intercepted for authentication
if no corresponding authentication cache entry exists. If no access list is defined, the
authentication proxy intercepts traffic from all hosts whose connection initiating packets are
received at the configured interface.
Use the no form of this command with a rule name to disable the authentication proxy for a
given rule on a specific interface. If a rule is not specified, the no form of this command
disables the authentication proxy on the interface.
The syntax of the ip auth-proxy command is as follows:
ip auth-proxy auth-proxy-name
Syntax Description
auth-proxy-name
This argument specifies the name of the authentication proxy rule to apply to

5-153
the interface configuration. The authentication proxy rule is established with

the authentication proxy name command.
Note
5-154
A proxy authentication rule can consist of multiple statements, each specifying a different
authentication type (HTTP, FTP, or Telnet). This configuration supports proxy authentication
for multiple applications (HTTP, HTTPS, FTP, and Telnet) at the same time.
Authentication Proxy Rules with ACLs
router(config)# access-list 10 permit 10.0.0.0 0.0.0.255

router(config)# ip auth-proxy name aprule http list 10
router(config-if)# ip auth-proxy APRULE
Creates an authorization proxy rule with an ACL
SNRS v2.05-17
You can associate a Cisco IOS Firewall authentication proxy rule with an ACL, providing
control over which hosts use the Cisco IOS Firewall authentication proxy. To create a Cisco
IOS Firewall authentication proxy rule with ACLs, use the ip auth-proxy name global
configuration command with the list acl option. To remove the authentication proxy rules, use
the no form of this command.
The syntax of the ip auth-proxy name with ACLs command is as follows:
ip auth-proxy name auth-proxy-name http list {acl-num | acl-name}
Syntax Description
auth-proxyname
This argument associates a name with a Cisco IOS Firewall authentication proxy
rule. Enter a name of up to 16 alphanumeric characters.
list acl-num
| acl-name
(Optional) This command specifies a standard (199), extended (1199), or

named IP ACL to use with the Cisco IOS Firewall authentication proxy. With this
option, the Cisco IOS Firewall authentication proxy is applied only to those hosts
in the ACL. If no list is specified, all connections initiating HTTP, FTP, or Telnet
traffic arriving at the interface are subject to authentication.

5-155
Example
This topic examines an example of an auth-proxy configuration..
Example
Apply ACL 102 to
block all inbound
traffic except from
the AAA server
Apply auth-prox,
ACL 105, and IOS
Classic Firewall
Host A
10.0.1.12
S0
E0
WWW
10.0.6.10
Internet
R1
S0
E0
R2
(Firewall)
AAA
10.0.6.12
SNRS v2.05-18
This figure shows an example of an Authentication Proxy and CBAC configuration.

In this example, host A initiates an HTTP connection with the web server (WWW). The HTTP
traffic between router 1 and router 2 is encrypted using IPsec. The Cisco IOS Firewall
authentication proxy and Cisco IOS classic firewall are configured at interface Serial0 on router
2, which is acting as the firewall. ACL 105 blocks all traffic at interface Serial0. ACL 102 is
applied at interface Ethernet0 on router 2 to block all traffic on that interface except traffic from
the AAA server.
When host A initiates an HTTP connection with the web server, the Cisco IOS Firewall
authentication proxy prompts the user at host A for a username and password. These credentials
are verified with the AAA server for authentication and authorization. If authentication is
successful, the per-user ACLs are downloaded to the firewall to permit services.
The following example provides the router 2 configuration for completeness:
5-156
Router 2 Configuration
Configure AAA for the
authentication proxy
R2(config)# aaa new-model

R2(config)# aaa authentication login default group tacacs
R2(config)# aaa authorization auth-proxy default group
tacacs+
R2(config)# aaa accounting auth-proxy default start-stop
group tacacs+
R2(config)# tacacs-server host 10.0.6.12
R2(config)# tacacs-server key cisco
Create the classic
R2(config)# radius-server host 172.31.54.143 firewall
inspection rule
R2(config)# radius-server key cisco
SNRS
R2(config)# ip inspect name SNRS http
R2(config)# ip inspect name SNRS tcp
R2(config)# ip inspect name SNRS ftp
R2(config)# ip inspect name SNRS smtp
R2(config)# ip auth-proxy auth-cache-time 60
R2(config)# ip auth-proxy name SNRS-Proxy http
R2(config)# ip http server
R2(config)# ip http authentication aaa
Name auth-prox rule

and Set the global
authentication proxy
timeout value
SNRS v2.05-19
The example above is for the firewall router. In this example, the firewall router is router 2.
Router 2 Configuration Example

The following tasks are required to configure auth-prox and classic firewall on router R2.
Configure AAA for auth-prox
Create the classic firewall inspection rule SNRS
Create the authentication proxy rule SNRS-Proxy
Configure the HTTP server and set the HTTP server authentication method to AAA.

5-157
Router 2 Configuration (Cont.)

R2(config)# access-list 102 permit tcp host 10.0.6.12
host 10.0.6.2
R2(config)# access-list 102 deny tcp any any
R2(config)# access-list 102 deny
udp any any
R2(config)# access-list 102 permit ip any any
tcp any any
udp any any
R2(config)# access-list 105 permit ip any any
R2(config)# interface Serial0
R2(config-if)# ip address 172.30.6.2 255.255.255.0
R2(config-if)# ip inspect SNRS in
R2(config-if)# ip auth-proxy SNRS-Proxy
R2(config)# interface Ethernet0
R2(config-if)# ip address 10.0.6.2 255.255.255.0
eq tacacs
Create ACL 102 to
block all traffic
inbound on interface
E0 except for traffic
from the AAA
server.
Create ACL 105 to
block all traffic inbound
on interface Serial0.
Permit only IP protocol
traffic
SNRS v2.05-20
The example above involves the following tasks.
5-158
Create access lists to:
Block outside traffic
Allow TACACS+ and RADIUS communication between the AAA servers and the
router.
Apply the classic firewall inspection rule, the appropriate ACL, and the authentication
proxy rule at interface Serial0
Apply the appropriate ACL at interface Ethernet0
Test and Verify

This section describes the procedures for testing and verifying the Cisco IOS Firewall
authentication proxy configuration.
Verifying Authentication Proxy
router# show ip auth-proxy cache

router# show ip auth-proxy configuration
router# show ip auth-proxy watch list
Displays statistics, configurations, and cache

entries of authentication proxy subsystems
SNRS v2.05-21
Several commands are available to verify and test Cisco IOS Firewall authentication proxy
Use the show ip auth-proxy command to display the authentication proxy entries, the running
Cisco IOS Firewall authentication proxy configuration, or the Cisco IOS Firewall
authentication proxy statistics.
The syntax of the show ip auth-proxy command is as follows:
show ip auth-proxy {cache | configuration | statistics}
Syntax Description
cache
This keyword lists the host IP address, the source port number, the timeout value
for the Cisco IOS Firewall authentication proxy, and the state for connections
using the Cisco IOS Firewall authentication proxy. If the authentication proxy
state is HTTP_ESTAB, the user authentication was successful.
configuration
This keyword displays all of the Cisco IOS Firewall authentication proxy rules
configured on the router.
statistics
This keyword displays all of the router statistics related to the Cisco IOS Firewall

5-159
debug Commands
router(config)#
debug ip auth-proxy ftp
debug ip auth-proxy function-trace
debug ip auth-proxy http
debug ip auth-proxy object-creation
debug ip auth-proxy object-deletion
debug ip auth-proxy tcp
debug ip auth-proxy telnet
debug ip auth-proxy timer
SNRS v2.05-22
There are several debug commands useful in troubleshooting the Cisco IOS Firewall
The syntax of the debug ip auth-proxy command is as follows:
debug ip auth-proxy {ftp | function-trace | http | object-creation |
object-deletion | tcp | telnet | timer}
Syntax Description
5-160
ftp
Displays FTP events related to the Cisco IOS Firewall authentication proxy
function-trace
Displays the Cisco IOS Firewall authentication proxy functions
http
Displays HTTP events related to the Cisco IOS Firewall authentication proxy
object-creation
Displays additional entries to the Cisco IOS Firewall authentication proxy

cache
object-deletion
Displays deletion of cache entries for the Cisco IOS Firewall authentication
proxy
tcp
Displays TCP events related to the Cisco IOS Firewall authentication proxy
telnet
Displays Telnet-related Cisco IOS Firewall authentication proxy events
timer
Displays Cisco IOS Firewall authentication proxy timer-related events
Clear the Cisco IOS Firewall

Authentication Proxy Cache
router#
clear ip auth-proxy cache {* | ip_addr}
Clears authentication proxy entries from the router
SNRS v2.05-23
The clear command is also used when troubleshooting auth-prox.

The syntax of the clear ip auth-proxy cache command is as follows:
clear ip auth-proxy cache {* | ip_addr}
Syntax Description
*
Clears all Cisco IOS Firewall authentication proxy entries, including user profiles and
dynamic ACLs
ip_addr
Clears the Cisco IOS Firewall authentication proxy entries, including user profiles and
dynamic ACLs, for the specified IP address

5-161
Summary
Summary
The Cisco IOS Firewall authentication proxy feature enables
network administrators to apply specific security policies on
a per-user basis for TACACS+ and RADIUS servers.
To support the authentication proxy, configure the AAA
authorization auth-proxy service on the Cisco Secure
ACS for Windows.
To configure authentication proxy, you must:
Configure AAA support
Create an authentication proxy rule
Apply the rule to an interface
SNRS v2.05-24
References
For additional information, refer to this resource:
5-162
Cisco Systems, Inc. Cisco IOS Security Configuration Guide, Release 12.4:
09186a008043360a.html
Configuring Authentication Proxy:

http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_chapt
er09186a00804ad9bc.html
Lesson 5
Configuring Cisco IOS IPS

Overview
This lesson covers the Cisco IOS Intrusion Prevention System (IPS). IPSs provide a level of
protection beyond the firewall by protecting the network from internal and external attacks and
threats. Cisco IOS Firewall IPS technology enhances perimeter firewall protection by taking
appropriate action on packets and flows that violates the security policy or represents malicious
network activity. You will learn how to configure a Cisco router for intrusion prevention,
including enabling IPS, working with signatures, and monitoring with syslog or Security
Device Event Exchange (SDEE).
Objectives
Upon completing this lesson, you will be able to configure Cisco IOS IPS on a Cisco router.
This ability includes being able to meet these objectives:
Describe the features, functions, limitations, and applications of Cisco IOS IPS
Describe signature micro engines
Describe signatures and signature definition files
Describe IOS IPS deployment options
Describe how to configure Cisco IOS Firewall IPS on a router
Describe how to configure logging for IPS
Describe the steps to upgrade to the latest SDF
Describe how to test and verify Cisco IOS IPS configuration and operation
Cisco IOS IPS

This topic describes the Cisco IOS IPS feature for Cisco routers.
Cisco IOS Intrusion Prevention System
Attack
Alarm
2
Network Management
Console
Reset Connection
Drop Packet
SNRS v2.05-2
In today's business environment, network intruders and attackers can come from both outside
and inside the network. They can launch denial-of-service (DoS) attacks or distributed denialof-service (DDoS) attacks; attack Internet connections; and exploit network and host
vulnerabilities. At the same time, Internet worms and viruses can spread across the world in a
matter of minutes. There is often no time to wait for human intervention-the network itself must
possess the intelligence to instantaneously recognize and mitigate these attacks, threats,
exploits, worms, and viruses.
Cisco IOS IPS, with in-line intrusion prevention capabilities, is the first in the industry to
provide an in-line, deep packet inspection-based IPS solution that helps enable Cisco routers to
effectively mitigate a wide range of network attacks without compromising traffic forwarding
performance. Armed with the intelligence to accurately identify, classify, and stop malicious or
damaging traffic in real time, Cisco IOS IPS is a core component of the Cisco Self-Defending
Network, enabling the network to protect itself. This technology uses Cisco IPS Sensor
Software and signatures. Because Cisco IOS IPS is in line, it can drop traffic, send an alarm, or
reset a connection, enabling the router to respond immediately to security threats.
Cisco IOS IPS capabilities include the ability to dynamically load and enable selected IPS
signatures in real time, support for more than 1500 signatures supported by Cisco IPS Sensor
platforms, and the ability for a user to modify an existing signature or create a new signature to
address newly discovered threats.
5-164
The Cisco IOS IPS acts as an in-line intrusion prevention sensor. It watches packets and
sessions as they flow through the router, scanning each packet to match any of the IPS
signatures. When it detects suspicious activity, it responds before network security can be
compromised and logs the event through Cisco IOS syslog or SDEE. The network
administrator can configure Cisco IOS IPS to choose the appropriate response to various
threats.
When packets in a session match a signature, the Cisco IOS IPS can take any of the following
actions, as appropriate:
Drop the packet
Deny traffic for a particular source address
Deny traffic for a particular connection (session)
Cisco developed its Cisco IOS Software-based intrusion prevention capabilities with flexibility
in mind, so that individual signatures could be disabled in case of false positives. Generally, it
is preferable to enable both the Cisco IOS Firewall and Cisco IOS IPS to support network
security policies. However, each of these features can be enabled independently and on
different router interfaces.
5-165
Features
Uses the underlying routing infrastructure
Ubiquitous protection of network assets
Inline deep packet inspection
Software based inline intrusion prevention sensor
IPS signature support
Signature based packet scanning, uses same set of signatures as
IDS Sensor platform
Dynamic signature update (no need to update IOS Image)
Customized signature support
Variety of event actions configurable per-signature basis
Parallel signature scanning
Named and numbered extended ACL support
SNRS v2.05-3
This discussion covers some of the features and benefits of Cisco IOS IPS.
Features and Benefits

Cisco IOS IPS includes the following features:
Uses the underlying routing infrastructure: This feature provides an additional layer of
security with investment protection.
Ubiquitous protection of network assets: Cisco IOS IPS is supported on a broad range of
Cisco routers, enabling the user to protect network users and assets deep into the network
architecture. The router is a security enforcer.
In-line deep packet inspection: Cisco IOS IPS enables users to stop known network
attacks. By alerting the router to an event, Cisco IOS IPS will intercept intrusion attempts
to traverse the router. Cisco IOS IPS utilizes deep packet inspection to get into the payload
of a packet and uncover the known malicious activity.
IPS signature support: Cisco IOS IPS can now be enabled with any of the 1600 or more
IPS signatures supported by the Cisco IPS Sensors to mitigate known network attacks. As
attacks are identified in the Internet, these signatures are updated and posted to Cisco.com
so that they can be downloaded to the Cisco router. Refer to the latest Cisco IPS
documentation for the current list of signatures.
Customized signature support: Cisco IOS IPS can now customize existing signatures
while also creating new ones. This day one attack prevention capability mitigates attacks
that try to capitalize on slight deviations of known or newly discovered attacks.
Parallel signature scanning: Cisco IOS IPS uses a parallel signature scanning engine to
scan for multiple patterns within a signature micro-engine (SME) at any given time. IPS
signatures are no longer scanned on a serial basis.
5-166
Named and numbered extended access control list (ACL) support: In Cisco IOS
Software releases earlier than Cisco IOS Release 12.3(8)T, only standard, numbered ACLs
were supported. Cisco IOS IPS now supports both named and numbered extended ACLs by
using either the ip ips ips-name list acl command or the ip ips signature signature-id list
acl-list command.
Origin of Cisco IOS Firewall IPS

Cisco IOS IPS restructures the existing Cisco IOS Software-based intrusion detection system
(IDS). The primary difference between Cisco IOS Software-based IDS and the new, enhanced
Cisco IOS IPS is that an IDS monitors traffic and sends an alert when suspicious patterns are
detected, while an IPS can drop traffic, send an alarm, or reset the connection, enabling the
router to mitigate and protect against threats in real time. Cisco IOS IPS inherited the built-in
132 signatures from Cisco IOS Software-based IDS technology; with the introduction of in-line
IPS capability, new signatures can be added by downloading a signature definition file (SDF) to
the router flash memory, or users can specify the location of the SDF in the Cisco IOS IPS
configuration on the router.
5-167
Signature Micro-Engines
This topic describes signature micro-engines.
Signature Micro Engines

An SME is a component of IOS IPS that supports signatures
in a certain category.
Each engine is customized for the protocol and fields it is
designed to inspect, and defines a set of legal parameters
that have allowable ranges or sets of values.
The SMEs look for malicious activity in a specific protocol.
All the signatures in a given micro-engine are scanned in
parallel fashion rather than serially.
15 SMEs in 12.4(4) T or later
OTHER engine has hard-coded signatures
SNRS v2.05-4
An SME is a component of Cisco IOS IPS that supports signatures in a certain category.
Customized for the protocol and fields it is designed to inspect, each engine defines a set of
legal parameters that have allowable ranges or sets of values. The SMEs look for malicious
activity in a specific protocol. Signatures can be defined for any of the supported SMEs using
the parameters offered by those microengines. Packets are scanned by the microengines that
understand the protocols contained in the packet.
A regular expression is a systematic way to specify a search for a pattern in a series of bytes.
When a signature engine is built (building refers to loading an SME on the router when Cisco
IOS IPS is enabled on the interface), it may compile one or more regular expressions.
Compiling a regular expression requires more memory than the final storage of the regular
expression-important information to know when considering loading and merging new
signatures.
Cisco IOS IPS also introduces the concept of parallel scanning. All the signatures in a given
microengine are scanned in parallel, rather than serially. Each SME extracts values from the
packet and passes portions of the packet to the regular expression engine. The regular
expression engine can search for multiple patterns at the same time (in parallel). To facilitate
this parallel scanning, after loading a new SDF, Cisco IOS IPS builds the SMEs by compiling
all the signatures in each SME for parallel scanning. Parallel scanning increases efficiency,
resulting in higher throughput.
5-168
Each engine categorizes a group of signatures, and each signature detects patterns of misuse in
network traffic. For example, all HTTP signatures are grouped under the HTTP engine.
Signatures contained within the SDF are handled by a variety of SMEs. The SDF typically
contains signature definitions for multiple engines. The SME typically corresponds to the
protocol in which the signature occurs and looks for malicious activity in that protocol.
A packet is processed by several SMEs. Each SME scans for various conditions that can lead to
a signature pattern match. When an SME scans the packets, it extracts certain values, searching
for patterns within the packet via the regular expression engine.
Here is a table of SMEs that are supported by Cisco IOS IPS.
SMEs Supported by Cisco IOS IPS
SME
Description
ATOMIC.L3.IP
Provides simple Layer 3 IP alarms
ATOMIC.ICMP
Provides simple Internet Control Message Protocol (ICMP) alarms

based on the following parameters: type, code, sequence, and ID
ATOMIC.IPOPTIONS
Provides simple alarms based on the decoding of Layer 3 options
ATOMIC.UDP
Provides simple User Datagram Protocol (UDP) packet alarms

based on the following parameters: port, direction, and data length
ATOMIC.TCP
Provides simple TCP packet alarms based on the following

parameters: port, destination, and flags
SERVICE.DNS
Analyzes the Domain Name System (DNS) service
SERVICE.RPC
Analyzes the remote-procedure call (RPC) service
SERVICE.SMTP
Inspects Simple Mail Transfer Protocol (SMTP)
SERVICE.HTTP
Provides HTTP protocol decode-based string engine that includes

antievasive URL de-obfuscation
SERVICE.FTP
Provides FTP service special decode alarms
STRING.TCP
Offers TCP regular expression-based pattern inspection engine

services
STRING.UDP
Offers UDP regular expression-based pattern inspection engine

services
STRING.ICMP
Provides ICMP regular expression-based pattern inspection engine

services
MULTI-STRING
Supports flexible pattern matching and supports Trend Labs

signatures
OTHER
Provides internal engine to handle miscellaneous signatures
Following is a brief discussion on signature engines.
Atomic Engines
Atomic engines do not store persistent data across packets; instead, they can fire an alarm from
the analysis of a single packet. Therefore, the basic features of these engines do not require
attachment to a nonglobal StorageKey-they use the StorageKey xxxx. Because atomic engines
have no storage, they are essentially 1:1 signatures. Each atomic engine has discriminators
specialized to its protocol.
5-169
ATOMIC.L3.IP is a general-purpose Layer 3 inspector. It can handle data length and protocol
number comparisons, and it has some hooks for fragment and partial Internet Control Message
Protocol (ICMP) comparisons.
ATOMIC.ICMP is specialized to Layer 4. It has many parameters, some with both a single
value and a minimum and maximum for the boundaries. All the single parameters can be used
together in a signature, but it is not practical. It does not have any required parameters.
ATOMIC.UDP is specialized to Layer 4. It is a simple engine with basic capabilities to
interrogate ports and packet lengths. It does not have required parameters.
ATOMIC.IPOPTIONS is a simple engine that decodes Layer 3 options.
ATOMIC.TCP specializes in Layer 4 TCP packets and has basic TcpFlags/Mask comparisons
along with port filters and the SinglePacketRegex.
Service Engines
Service engines analyze Layer 5+ traffic between two hosts. These signatures are 1:1 signatures
that track persistent data on the stream (AaBb) for TCP or QUAD (AaBb) for User Datagram
Protocol (UDP). The engines decode and interpret the Layer 5+ payload in a manner similar to
that for the live service. A full-service-like decode may not be necessary if the partial decode
provides adequate information to inspect the signatures. The engines decode enough of the data
to make the signature determinations but do not decode more than is needed, minimizing CPU
and memory load.
Service engines have common characteristics, such as using the output from the stream
processor, but each engine has specific knowledge of the service that it is inspecting. Service
engines supplement the capabilities of the generic string engine, specializing in algorithms
where using the string engine is inadequate or undesirable.
The purpose of the service decode is to mimic the interpretation of the live server of the Layer
5+ payload. These interpretations are used primarily in the determination of signatures, as the
decoded fields are compared to the signature parameters.
As the engine is decoding, errors with bad payloads can occur. These error conditions are
linked to different kinds of signatures, known as protocol violations or error traps, which occur
when the engine is decoding the payload and an error occurs because of a malformation in the
payload that violates the rules of the service protocol. An error trap handles this malfunction in
the analysis code. Specifying the trap conditions that map to signatures is done by using the
normal parameters, such as the SERVICE.FTP with BadPort. In some cases, these trap
conditions can be combined to form a signature that results when multiple trap conditions are
encountered. However, in most cases, the trap conditions have a 1:1 mapping to the trap
signatures.
5-170
String Engines
The string engine is a generic-based pattern-matching inspection engine for ICMP, TCP, and
UDP. The string engine uses a regular expression engine that can combine multiple patterns
into a single pattern-matching table, allowing for a single search through the data. There are
three string engines: STRING.ICMP, STRING.TCP, and STRING.UDP.
Multi-String Engine
The multi-string engine inspects Layer 4 protocol packets in a flexible manner. This engine also
supports Trend Labs network virus signatures normally deployed to Cisco IOS IPS through the
Cisco Incident Control System (ICS).
5-171
Signatures and SDFs

This topic describes signatures and signature definition files.
Built-in Signatures
135 Signatures
Built-in signatures is the last resort when router loads signatures.
Can be turned off using CLI no ip ips sdf builtin
Cisco recommend to use pre-tuned SDF files attack-drop.sdf,
128MB.sdf and 256MB.sdf.
Built-in signatures will NOT be supported in 12.4(PI5)T when IOS
IPS supports 5.x format.
SNRS v2.05-5
A signature detects patterns of misuse in network traffic.

IPS signatures are released in the form of "S-files", which are lists of signatures and their
characteristics. Cisco S-files contain signatures for all Cisco IPS platforms: Cisco IPS 42xx
sensors, Cisco ASA 55xx appliances, intrusion detection system (IDS) modules for Cisco
Catalyst 6500 Series switches, and Cisco IOS IPS. As Cisco creates new signatures, it
updates the S-files and increments the file name (e.g. S250 as of July 2006). Cisco IOS IPS
supports most, but not all, of the signatures in the S-files. This is because the other platforms
(e.g. 42xx sensors) support additional "IPS inspection engines" that Cisco IOS IPS currently
does not. Future Cisco IOS IPS releases may add support for these inspection engines.
Note
The total number of signatures supported by Cisco IOS IPS routers depends on the Cisco
IOS Software release and the signature distribution package version.
In Cisco IOS Software Release 12.3(14)T, Cisco IOS IPS added support for three STRING
engines-STRING.TCP, STRING.UDP, and STRING.ICMP. Adding these engines resulted in a
large number of new signatures being supported on Cisco IOS IPS routers. As of signature
package IOS-S250.zip, the total number of signatures supported by Cisco IOS Software
Release 12.3(14)T or later is 1685 (out of a total of 1972 signatures in the S250 file). Because
of this and other IPS enhancements, Cisco recommends running Cisco IOS Software Release
12.4(4)T or later when using Cisco IOS IPS.
5-172
Cisco IOS IPS can also scan the contents of IP fragments, thereby protecting the network from
fragmented attacks. The solution detects both atomic signatures in a single packet and
composite signatures spread into a sequence of packets. Detection of most composite signatures
requires stateful inspection of multiple packets (keeping state information across packets of a
particular session between a source-destination pair). Both Cisco IOS IPS and Cisco IOS
Firewall use the same session table. For example, if an HTTP request is initiated from the
corporate network to the Internet, the return traffic may be compromised, so Cisco IOS IPS
maintains the state of the entire session.
Currently, Cisco IOS IPS supports more than 1600 signatures. These signatures are part of the
common set of signatures that Cisco IPS Sensors support, helping to ensure that all Cisco
products use a common resource and are available for download from Cisco.com. Additionally,
Cisco IOS IPS has the ability to download IPS signatures without the need for a Cisco IOS
software image update. Typically, new signatures are released every two weeks, with
emergency signature updates posted as needed. The signatures are posted to Cisco.com at:
http://www.cisco.com/cgi-bin/tablebuild.pl/ios-sigup.
Built-in Signatures
Cisco IOS IPS has 135 built-in signatures available in the Cisco IOS software image. The builtin signatures are hard-coded into the Cisco IOS software image for backward compatibility.
Each signature can be set to send an alarm, drop the connection, or reset the connection.
As shown in the example below, built-in signatures are loaded if no location has been
configured for the signature definition files. You can disable built-in signatures using the no ip
ips sdf builtin command.
5-173
Signature Actions
This section describes the actions that are taken in response to a matched signature.
Signature Actions
Alarm
Send alarm via Syslog and SDEE
Reset
Applys to TCP connection. Send reset to both peers
Drop
Drops the packet
DenyAttackerInline
Blocks the attackers source IP address completely.
No connection can be established from the attacker to the
router until the shun time expires (this is set by the user).
DenyFlowInline
Blocks the appropriate TCP flow from the attacker. Other
connections from the attacker can be established to the router
SNRS v2.05-6
The Cisco IOS IPS acts as an inline sensor, watching packets as they traverse the router
interfaces and acting upon them in a definable fashion. When a packet matches a signature, or a
number of packets in a session match a signature, the Cisco IOS IPS may perform the following
configurable actions:
Drop the packet
Deny traffic from the source IP address of the attacker for a specified amount of time
Deny traffic on the connection for which the signature was seen for a specified amount of
time
Each action is enabled on a per-signature basis. Each signature has an action assigned by
default, based on the severity of the signature. Alarm sends a notification about the attack via
syslog or SDEE protocol. TCP reset is effective for TCP-based connections and sends a reset
to both the source and destination addresses. For example, in case of a half-open SYN attack,
Cisco IOS IPS can reset the TCP connections. Drop discards the packet without sending a
reset. By default, the 132 built-in signatures are set to alarm only.
5-174
Each signature can be set to send an alarm, drop the attack (offending) packets, deny the
attacker, deny the attack flow, or reset the connection. Each action is enabled on a per-signature
basis using Cisco SDM or the CiscoWorks Management Center for IPS Sensors-there is no CLI
command to tune signature parameters. Each signature has an action assigned by default, based
on the severity of the signature. "Alarm" sends a notification about the attack through syslog or
SDEE. "TCP reset" is effective for TCP-based connections and sends a reset to both the source
and destination addresses. For example, in case of a half-open SYN attack, Cisco IOS IPS can
reset the TCP connections. "Drop" discards the packet without sending a reset. By default, the
132 built-in signatures are set to "alarm" only. Cisco recommends using "drop and reset" in
conjunction with alarm. "DenyAttackerInline" blocks the attacker's source IP address
completely. No connection can be established from the attacker to the router until the shun time
expires (this time is set by the user). "DenyFlowInLine" blocks the appropriate TCP flow from
the attacker. Other connections from the attacker can be established to the router.
5-175
Signature Loading Process

IOS IPS goes through several steps when loading the SDF
START
Repeat through all

Configured Locations
No more locations
Built-in Enabled?
NO
NO
Fail
closed?
YES
Load SDF from next
available location
Load Built-in Sigs

(135)
Packet
passed unscanned
YES
Packet Dropped!
Success?
NO
YES
Build Sig Engines
Engine build
success?
YES
SDF load complete
NO
Previous engine
exist?
YES
NO
Put engine in
Inactive state
Use previous
engine sigs
SNRS v2.05-7
This figure shows the process followed when signatures are loaded. The process goes as
follows:
Step 1
The router looks for a location that was configured using the ip ips sdf location
command.
Step 2
It can do one of two things:
1. If it finds a SDF, it proceeds to build the signature engines.

1) If the engine build was a success, then the SDF load is complete.
2) If the engine build was not a success, then it checks for a previously used
engine.
3) If a previously used engine exists, then it uses those signatures, if not, it puts that
engine into an inactive state.
2. If it DOES NOT find a SDF, it will load the built-in signatures if they are enabled.
5-176
Signature Definition Files

This section describes the signature definition file.
Signature Definition File (SDF)

A SDF contains all or a subset of the signatures supported by
Cisco IPS.
An IPS loads the signatures contained in the SDF and scans
incoming traffic for matching signatures.
The IPS enforces the policy defined in the signature action.
Cisco IPS uses the SDF to populates internal tables with the
information necessary to detect each signature.
The SDF can be saved on the router flash memory.
SDFs are downloaded from cisco.com.
Two pre-built SDFs:
256MB.sdf
128MB.sdf
SNRS v2.05-8
The SDF is integral to Cisco IOS IPS. The SDF is an Extensible Markup Language (XML) file
with a definition of each signature along with relevant configurable actions. Cisco IOS Firewall
IPS reads in the SDF, parses the XML, and populates its internal tables with the information
necessary to detect each signature. The SDF contains the signature definition and configuration.
Actions such as alarm, drop, or reset can be selected for individual signatures within the SDF.
The SDF can be modified so that the router will detect only specific signatures; as a result, it
can contain all or a subset of the signatures supported in Cisco IOS IPS. The user specifies the
location of the SDF. The SDF can reside on the local flash file system (recommended) or on a
remote server. Remote servers can be accessed via TFTP, FTP, Secure Copy Protocol (SCP), or
Remote Copy Protocol (RCP).
An SDF contains definitions for each signature that it contains. The signatures are preset with
actions to mitigate the attack by dropping the packet and resetting the connection, if applicable.
After signatures are loaded and compiled onto a router running Cisco IOS IPS, IPS can begin
detecting the new signatures immediately.
If the Cisco IOS IPS-enabled router is configured to scan packets using the SDF, it gets
signature and engine information from the SDF. All or a subset of the routers in a network can
use the same SDF or a different SDF, depending on the requirements of the network. Some
routers may allow for activating more signatures than routers with less memory.
5-177
Cisco IOS IPS ships with one of two preconfigured SDFs: 128MB.sdf (340 sigs)or 256MB.sdf
(572 sigs). At least one of these files should be available in flash memory on all Cisco IOS IPSenabled routers. These SDFs contain the latest high-fidelity (low false positives) worm, virus,
instant messaging, and peer-to-peer blocking signatures for detecting security threats, allowing
easier deployment and signature management for the user. These two SDFs contain signatures
that are supported by the newly introduced string engines, namely, STRING.TCP,
STRING.UDP, and STRING.ICMP.
Users can append or modify signatures from the pre-built SDFs according to their needs. For
example, the Nimda virus can be detected by loading and enabling the following signatures
from the attack-drop.sdf SDF:
Signature ID: 5081:0 WWW WinNT cmd.exe access
Signature ID: 5114:2 WWW IIS Unicode attack
Signature ID: 5326:0 root.exe access
The number of signatures that can be loaded on a router is a function of the amount of memory
(DRAM) available on the router.
The SDF can then be loaded directly from flash memory into the Cisco IOS IPS. If flash
memory is erased, the SDF may also be erased. Thus, if you are copying a Cisco IOS image to
flash memory and are prompted to erase the contents of flash memory before copying the new
image, you might risk erasing the SDF. If this occurs, the router will refer to the built-in
signatures within the Cisco IOS image. The SDF can also be downloaded onto your router from
Cisco.com.
5-178
Deploying IOS IPS

This topic describes IOS IPS deployment options.
Cisco IOS Firewall IPS Network Visibility

Engineering
Sales
Offices
Finance
International
Sales Offices
Mainframe
WAN
Campus
Backbone
VPN
Suppliers
Accounting
Internet
Intranet Servers
SNRS v2.05-9
Cisco IOS IPS has two main deployment scenarios:

Protecting the Internet-facing (untrusted) interface
IPS within the internal (trusted) network
Protecting the Internet-Facing (Untrusted) Interface

The Internet is one of the major sources of attacks and exploits targeting today's corporate
networks. Applying Cisco IOS IPS on router interfaces connected to the Internet helps defend
the corporate network against such vulnerabilities. Even with a firewall enabled to restrict
access from the untrusted Internet, intruders can still potentially invade the perimeter router on
the telecommuter side and gain access to the corporate network. Common security attacks
include IP spoofing, man-in-the-middle attacks, and unauthorized access that may have slipped
through the firewall. Outgoing traffic from the telecommuter's end also poses a threat to the
internal network, if the telecommuter attempts to compromise the corporate network or the
Internet. Cisco IOS IPS can be applied at the incoming and outgoing interfaces of the perimeter
router to monitor and discard malicious activity.
In the network topology shown in the figure, the branch offices are the best places to enable
Cisco IOS IPS on both directions of the Internet-facing interface. A common scenario is when
split tunneling is enabled while running VPN tunnels to the corporate network. Cisco
recommends enabling Cisco IOS IPS on the Internet traffic to protect the network from attacks
and exploits that might come into the branch office or telecommuter personal computers, which
could in turn affect the corporate network.
5-179
IPS Within the Internal (Trusted) Network

In today's corporate network environment, network attacks and exploits come from not only the
Internet, but often from within the corporate network itself. These attacks or exploits could be
deliberate or inadvertent (for example, an infected laptop brought into the office and connected
to the corporate LAN). Deploying Cisco IOS IPS within the corporate network helps mitigate
attacks, and helps prevent exploits from spreading within the network.
Hub-and-spoke topologies are commonly used for networks. The figure above shows a typical
network topology. In this topology, deploying Cisco IOS IPS on the spoke routers (Cisco 2851,
1841, and 871) will provide distributed protection for the network-attacks and exploits from
one of the branch offices will not spread throughout the rest of the network. In addition, the hub
router does not have to process all attacks and exploits from all branch offices, thus leaving
more CPU power and memory for other tasks. Deploying Cisco IOS IPS as close to the entry
point into the network as possible will mitigate the attacks and exploits from their early stages
into the network.
By enabling Cisco IOS IPS together with IP Security (IPsec) VPN, NAC, and Cisco IOS
Firewall, a Cisco router can perform encryption, firewalling, and traffic inspection at the first
point of entry into the network-an industry first. This setup reduces the additional devices
needed to support the system, reduces operating and capital expenditures, and enhances
security.
The Cisco IOS IPS capabilities are ideal for providing additional visibility at intranet, extranet,
and branch office Internet perimeters. Network administrators now have more robust protection
against attacks on the network and can automatically respond to threats from internal or
external hosts. IPS signatures can be deployed alongside or independently of other Cisco IOS
Firewall features. Existing Cisco IOS IPS customers can deploy the Cisco IOS Software-based
IPS signatures to complement their current protection. This enables intrusion prevention to be
deployed to areas that may not be capable of supporting a Cisco IPS Sensor.
The Cisco IOS IPS is intended to satisfy the security goals of all Cisco customers and is
particularly appropriate for these customers:
Enterprise customers who are interested in a cost-effective method of extending their
perimeter security across all network boundaries, specifically branch office, intranet, and
extranet perimeters
Small- and medium-sized businesses that are looking for a cost-effective router that has an
integrated firewall with intrusion prevention capabilities
Service provider customers who want to set up managed services, providing firewall and
intrusion prevention to their customers, all housed within the necessary function of a router
5-180
Issues to Consider
Memory use and performance impact
Limited persistent storage
CPU-intensive
Updated signature coverage
More than 1500 common attacks
SNRS v2.05-10
The following are issues to consider when implementing Cisco IOS IPS:
Memory usage and performance impact: The performance impact of intrusion
prevention depends on the number of signatures enabled, the level of traffic on the router,
the router platform, and other individual features enabled on the router (for example,
encryption). Because this router is being used as a security device, no packet is allowed to
bypass the security mechanisms. The IPS process in the router sits directly in the packet
path and, therefore, searches each packet for signature matches. In some cases, the entire
packet needs to be searched, and state information and even application state and awareness
must be maintained by the router. With sufficient memory, Cisco IOS IPS supports more
than 1500 signatures, but one major remaining concern is how many signatures various
router platforms can actually support, given memory and platform constraints. The number
of signatures and engines supported depends only on the memory available. The prebuilt
SDFs have the optimum combination of signatures for all standard memory configurations,
providing a good starting point.
Updated signature coverage: The Cisco IOS IPS now identifies more than 1500 of the
most common attacks, using signatures to detect patterns of misuse in network traffic.
These intrusion prevention signatures were chosen from a broad cross section of intrusion
prevention signatures. The signatures represent severe breaches of security and the most
common network attacks and information-gathering scans.
5-181
Cisco IOS Firewall IPS Configuration

This topic describes how to configure Cisco IOS Firewall IPS on a router.
Configuration Tasks
Install Cisco IOS Firewall IPS on the router:
Specify location of SDF.
Create an IPS rule.
Attach a policy to a signature (optional).
Apply IPS rule at an interface.
Configure logging via syslog or SDEE.
Verify the configuration.
SNRS v2.05-11
Several tasks are required to configure Cisco IOS IPS on a router.

To configure the Cisco IOS IPS on a router and to have it report alarms to a syslog server or to
Cisco SDM, install Cisco IOS IPS on the router as follows:
5-182
Step 1
Specify the location of the SDF.
Step 2
Create an IPS rule.
Step 3
Attach a policy to a signature (optional).
Step 4
Apply the IPS rule at an interface.
Step 5
Configure logging via syslog or SDEE.
Step 6
Verify the configuration. This includes using the available show, clear, and debug
commands for the Cisco IOS IPS.
Installing the Cisco IOS IPS Signatures

This section describes the procedure to install the Cisco IOS IPS signatures.
Specify Location of SDF

router(config)# ip ips sdf location flash:128MB.sdf
(Optional) Specifies the location in which the router will

load the SDF 128MB.sdf.
If this command is not issued, the router will load the
default, built-in signatures.
SNRS v2.05-12
This procedure allows you to load the default, built-in signatures or signatures from the SDF
(128MB.sdf or 256MB.sdf), but not both. If you want to merge the two signature files, you
must load the default, built-in signatures as described in this topic. Then, you can merge the
default signatures with the SDF.
Use the procedure given in this topic to install the latest Cisco IOS IPS signatures on a router
for the first time.
To specify a location for the SDF use the ip ips sdf location url command.
router(config)#
ip ips sdf location url [autosave]
Syntax Description
url
autosave
Location of the SDFAvailable URL options:
Local flash, such as flash:sig.xml
FTP server, such as ftp://myuser:mypass@ftp_server.sig.xml
RCP, such as rcp://myuser@rcp_server/sig.xml
TFTP server, such as tftp://tftp_server/sig.xml
(Optional) Specifies that the router will save a new SDF to the specified location
5-183
If there is no SDF location configured, by default, Cisco IOS IPS will try to load from built-in
signatures. When failed, it will go to a failed state. The traffic passing is controlled by the failclosed configuration in this state.
When you specify the ip ips sdf location command, the signatures are not loaded until the
router is rebooted or until the Cisco IOS IPS is applied to an interface (via the ip ips
command). If Cisco IOS IPS is already applied to an interface, the signatures are not loaded. If
Cisco IOS IPS cannot load the SDF, an error message is issued and the router uses the built-in
Cisco IOS IPS signatures.
You can also specify the copy ips-sdf command to load an SDF from a specified location.
Unlike the ip ips sdf location command, the signatures are loaded immediately after the copy
ips-sdf command is entered.
When you specify the autosave keyword, the router saves a new SDF to the specified location
when signatures are loaded using either the copy command or an external management
platform such as Cisco SDM, IPS Management Center (IPSMC) or Cisco Incident Control
Server (ICS). You can specify multiple autosave locations. The router will attempt to save to all
autosave locations. The URL must have proper write access permissions.
5-184
Merging Built-In Signatures with the 128MB.sdf File

This section describes how to merge signature files.
Merging Signatures
router# copy flash:128MB.sdf ips-sdf
router# copy ips-sdf flash:snrs-signatures.sdf
router# configure terminal
router(config)# ip ips sdf location flash:snrs-signatures.sdf
router(config)# interface fastEthernet 0/1
router(config-if)# no ip ips SNRS-IPS in
*Apr 8 14:05:38.243:%IPS-2-DISABLED:IPS removed from all interfaces - IPS
disabled
router(config-if)# ip ips SNRS-IPS in
SNRS v2.05-13
You may want to merge the built-in signatures with a new SDF in flash memory if the built-in
signatures are not providing your network with adequate protection from security threats by
using the copy command.
Issue the copy url ips-sdf command to load the SDF in the router from the location specified
via the url argument. When the new SDF is loaded, it is merged with the SDF that is already
loaded in the router, unless the /erase keyword is issued, which overwrites the current SDF
with the new SDF.
Cisco IOS Intrusion Prevention System (IPS) will attempt to retrieve the SDF from each
specified location in the order in which they were configured in the startup configuration. If
Cisco IOS IPS cannot retrieve the signatures from any of the specified locations, the built-in
signatures will be used.
If the no ip ips sdf built-in command is used, Cisco IOS IPS will fail to load. IPS will then rely
on the configuration of the ip ips fail command to either fail open or fail closed.
To merge signature files, complete these steps.
Step 1
Merge the flash-based SDF with the built-in signatures.

router# copy [/erase] url ips-sdf
5-185
Syntax Description
/erase
(Optional) Erases the current SDF in the

router before loading the new SDF.
Note This option is typically available only on platforms
with limited memory.
url
Description for the url argument is one of the

following options:
If you want to load the SDF in the router, the url

argument specifies the location in which to search
for the SDF.
If you are saving the SDF, the url argument
represents the location in which the SDF is saved
after it has been generated.
Regardless of what option the URL is used for,

available URL locations are as follows:
local flash, such as flash:sig.xml
FTP server, such as

ftp://myuser:mypass@ftp_server.sig.xml
rcp, such as rcp://myuser@rcp_server/sig.xml
The SDF will merge with the signatures that are already loaded in the router, unless the /erase
keyword is issued. The /erase keyword replaces the built-in signatures with the SDF.
Note
The SDF location is not saved in the configuration. The next time the router is reloaded, it
will refer to a previously specified SDF location in the configuration or it will load the built-in
signatures.
Whenever signatures are replaced or merged, the router prompt is suspended while the
signature engines for the newly added or merged signatures are being built. The router prompt
will be available again after the engines are built.
Depending on your platform and how many signatures are being loaded, building the engine
can take up to several seconds. It is recommended that you enable logging messages to monitor
the engine building status.
The ip sdf ips location command can also be used to load the SDF. However, unlike the copy
ips-sdf command, this command does not force and immediately load the signatures.
Signatures are not loaded until the router reboots or IPS is initially applied to an interface (via
the ip ips command).
Step 2
Save the newly merged signatures to a separate file.

router# copy ips-sdf url
5-186
Syntax Description
url
Description for the url argument is one of the following options:
If you want to load the SDF in the router, the url argument specifies the
location in which to search for the SDF.
If you are saving the SDF, the url argument represents the location in
which the SDF is saved after it has been generated.
Regardless of what option the URL is used for, available URL locations
are as follows:
local flash, such as flash:sig.xml
FTP server, such as ftp://myuser:mypass@ftp_server.sig.xml
rcp, such as rcp://myuser@rcp_server/sig.xml
This command saves the SDF that was loaded in the previous step to a specified location.
Note
Step 3
The SDF location will not be saved unless this command is issued.
Configure the router to load the new file the next time IPS is started.
router(config)# ip ips sdf location url
Step 4
Reinitialize the IPS by removing the IPS rule set and reapplying the rule set.
router(config)# interface interface-id
router(config-if)# no ip ips ips-name [ in | out ]
You should see the following:

*Apr 8 14:05:38.243:%IPS-2-DISABLED:IPS removed from all interfaces IPS disabled
Then you can reapply IPS to the interface.

router(config-if)# ip ips ips-name [ in | out ]
5-187
Attaching a Policy to a Signature

This section describes how to attach a policy to a signature.
Attach a Policy to a Given Signature (Optional)

router(config)# ip ips signature 6500 list 99
router(config)# ip ips signature 1000 disable
Associates an access list with a signature

Disables signature 1000 in the SDF
SNRS v2.05-14
To attach a policy to a signature, use the ip ips signature command in global configuration
mode. If the policy disabled a signature, use the no form of this command to re-enable the
signature. If the policy attached an ACL to the signature, use the no form of this command to
remove the ACL.
router(config)# ip ips signature signature-id {delete |
disable | list acl-list}
Syntax Description
signature-id
Signature within the SDF
delete
Deletes a specified signature
disable
Disables a specified signature
list acl-list
A named, standard, or extended ACL that is associated with the signature
This command allows you to set three policies to accomplish the following:
Delete a signature
Disable the audit of a signature
Qualify the audit of a signature with an ACL
If you are attaching an ACL to a signature, you also need to create an IPS rule with the ip ips
name command and apply it to an interface with the ip ips command.
5-188
Disabling a Signature
You may want to disable a signature (or set of signatures) if your deployment scenario deems
the signatures unnecessary.
To instruct the router to scan for a given signature but not take any action if the signature is
detected, use the ip ips signature command in global configuration mode. To re-enable a
signature, use the no form of this command.
router(config)# ip ips signature signature-id [sub-signatureid] disable [list acl- list]
Syntax Description
signature-id [sub-signatureid]
Signature that is disabled
list acl-list
(Optional) A named, standard, or extended ACL to filter

the traffic that will be scanned
If the packet is permitted by the ACL, the signature will be
scanned and reported; if the packet is denied by the ACL,
the signature is deemed disabled.
5-189
Creating IPS Rules

IPS rules are fairly easy to create. This section describes how to create an IPS rule.
Creating an IPS Rule

router(config)# ip ips name SNRS-IPS
Creates an IPS rule named MYIPS that will be

applied to an interface
SNRS v2.05-15
Specify an IPS rule using the ip ips name command. You will apply this rule to an interface
later.
Note
The IPS does not load the signatures until the rule is applied to an interface via the ip ips
command.
router(config)# ip ips name ips-name [list acl

ip ips name ips-name [list acl]
Syntax Description
ips-name
Name for IPS rule
list acl
(Optional) Specifies an extended or standard ACL to filter the traffic that will be
scanned.
Note: All traffic that is permitted by the ACL is subject to inspection by the IPS.
Traffic that is denied by the ACL is not inspected by the IPS.
5-190
Example
router(config)# ip ips fail closed
router(config-if)# ip virtual-reassembly
router(config-if)# end
*Jan 28 01:18:04.664: %IPS-6-SDF_LOAD_SUCCESS: SDF loaded
successfully from flash:128MB.sdf
. . . messages ommited ...........
*Jan 28 01:18:30.452: %IPS-6-ENGINE_BUILDING: ATOMIC.L3.IP - 5
signatures - 15 of 15 engines
SNRS v2.05-18
Normally, all signatures within the SDF are reported, if detected as in this slide. Note that
disabled signatures have a N in the On column.
5-191
Applying an IPS Rule at an Interface

This section describes how to apply an IPS rule to an interface.
Apply an IPS Rule at an Interface

router(config-if)#
ip ips ips-name {in | out}
Applies an IPS rule at an interface

router(config-if)# ip ips MYIPS in
SNRS v2.05-17
To apply an IPS rule to an interface, use the ip ips command in interface configuration mode.
To remove an IPS rule from an interface direction, use the no form of this command.
router(config-if)# ip ips ips-name {in | out}
Syntax Description
ips-name
Name of IPS rule
in
Applies IPS to inbound traffic
out
Applies IPS to outbound traffic
By default, IPS signatures are not applied to an interface or direction.

The ip ips command loads the SDF onto the router and builds the signature engines when IPS
is applied to the first interface.
Note
5-192
The router prompt disappears while the signatures are loading and the signature engines
are building. It will reappear after these tasks are complete. Depending on your platform and
how many signatures are being loaded, building the signature engine can take several
minutes. It is recommended that you enable logging messages so that you can monitor the
engine building status.
IP Virtual Reassembly
A buffer overflow attack can occur when an attacker continuously sends a large number of
incomplete IP fragments, causing the firewall to lose time and memory while trying to
reassemble the fake packets.
IP virtual reassembly is an interface feature that when turned on, will automatically reassemble
fragmented packets coming into the router through that interface. Cisco recommends that you
enable "ip virtual-assembly" on all interfaces where traffic comes into the router.
To enable virtual fragment reassembly (VFR) on an interface, use the ip virtual-reassembly
command in interface configuration mode. To disable VFR on an interface, use the no form of
this command.
router(config-if)# ip virtual-reassembly [max-reassemblies
number] [max-fragments number] [timeout seconds] [dropfragments]
Syntax Description
max-reassemblies
number
(Optional) Maximum number of IP datagrams that can be reassembled at any

given time. Default value: 16.
If the maximum value is reached, all fragments within the following fragment
set will be dropped and an alert message will be logged to the syslog server.
max-fragments
number
(Optional) Maximum number of fragments that are allowed per IP datagram

(fragment set). Default value: 32.
If an IP datagram that is being reassembled receives more than the maximum
allowed fragments, the IP datagram will be dropped and an alert message will
be logged to the syslog server.
timeout seconds
(Optional) Timeout value, in seconds, for an IP datagram that is being

reassembled. Default value: 3 seconds.
If an IP datagram does not receive all of the fragments within the specified
time, the IP datagram (and all of its fragments) will be dropped.
drop-fragments
(Optional) Enables the VFR to drop all fragments that arrive on the configured
interface. By default, this function is disabled.
The max-reassemblies number option and the max-fragments number option allow you to
configure maximum threshold values to avoid a buffer overflow attack and to control memory
usage.
In addition to configuring the maximum threshold values, each IP datagram is associated with a
managed timer. If the IP datagram does not receive all of the fragments within the specified
time (which can be configured via the timeout seconds option), the timer will expire and the IP
datagram (and all of its fragments) will be dropped.
Automatically Enabling or Disabling VFR

VFR is designed to work with any feature that requires fragment reassembly (such as Cisco
IOS Firewall and NAT). Currently, NAT enables and disables VFR internally; that is, when
NAT is enabled on an interface, VFR is automatically enabled on that interface.
If more than one feature attempts to automatically enable VFR on an interface, VFR will
maintain a reference count to keep track of the number of features that have enabled VFR.
When the reference count is reduced to zero, VFR is automatically disabled.
5-193
Example
This is an example of a completed basic configuration of IOS IPS.
Example
router(config)# ip ips fail closed
router(config-if)# ip virtual-reassembly
router(config-if)# end
*Jan 28 01:18:04.664: %IPS-6-SDF_LOAD_SUCCESS: SDF loaded
successfully from flash:128MB.sdf
. . . messages ommited ...........
*Jan 28 01:18:30.452: %IPS-6-ENGINE_BUILDING: ATOMIC.L3.IP - 5
signatures - 15 of 15 engines
SNRS v2.05-18
This example shows the basic configuration necessary to load the 128MB.sdf file onto a router
running Cisco IOS IPS. Note that the configuration is almost the same as when you load the
default signatures onto a router, except for the ip ips sdf location command, which specifies
the 128MB.sdf file. Cisco IOS IPS starts loading signatures when the very first IPS rule is
enabled on an interface.
5-194
Configure Logging via Syslog or SDEE

This topic describes how to configure logging for IPS.
Monitoring Cisco IOS Firewall IPS

Signatures
Network
Management
Console
Alarm
SDEE Protocol
Alert
Syslog
Syslog
Server
SNRS v2.05-19
As of Cisco IOS Release 12.3(11)T, Cisco IOS IPS provides two methods to report IPS
intrusion alerts: Cisco IOS logging (syslog) and SDEE. Use the procedure described in this
topic to enable SDEE to report IPS intrusion alerts.
Note
Effective as of Cisco IOS Release 12.3(11)T, the Post Office Protocol (POP) is no longer
supported.
Cisco IOS Software now supports the SDEE protocol. SDEE is a new standard that specifies
the format of messages and protocols used to communicate events generated by security
devices. SDEE is flexible, so that all vendors can support address compatibility. This allows
mixed IPS vendor environments to have one network management alert interface. TruSecure
Corporation (ICSA Labs) is currently proposing SDEE as the unified industry protocol format
for communicating with network management applications. SDEE uses a pull mechanism:
Requests come from the network management application, and the IPS appliance or IPS router
responds. SDEE utilizes HTTP and XML to provide a standardized interface. The Cisco IOS
IPS router will still send IPS alerts via syslog.
5-195
SDEE and Syslog

Cisco IOS Software now supports the SDEE protocol.
SDEE uses a pull mechanism: Requests come from the network
management application, and the IDS or IPS router responds.
SDEE will become the standard format for all vendors to
communicate events to a network management application.
The use of HTTP over SSL or HTTPS ensures that data is
secured as it traverses the network.
The Cisco IOS Firewall IPS router will still send IPS alerts via
syslog.
SNRS v2.05-20
SDEE Overview
SDEE is an application layer communication protocol that is used to exchange IPS messages
between IPS clients and IPS servers.
SDEE is always running, but it does not receive and process events from IPS unless SDEE
notification is enabled. If it is not enabled and a client sends a request, SDEE will respond with
a fault response message, indicating that notification is not enabled.
Benefits
Here are some of the benefits of SDEE:
Vendor interoperability: SDEE will become the standard format for all vendors to
communicate events to a network management application. This lowers the cost of
supporting proprietary vendor formats and potentially multiple network management
platforms.
Secured transport: The use of HTTP over Secure Sockets Layer (SSL) or secure (HTTPS)
ensures that data is secured as it traverses the network.
5-196
Storing SDEE Events in the Buffer

This section describes how to store SDDEE events in the router buffer.
Set Notification Type

router (config)#
ip ips notify [log | sdee]
Sets notification type

router(config)# ip ips notify sdee
router(config)# ip ips notify log
router (config)#
ip sdee events num_of_events
Sets the maximum number of SDEE events that can be stored

in the event buffer
SNRS v2.05-21
When SDEE notification is enabled (via the ip ips notify sdee command), 200 events can
automatically be stored in the buffer. When SDEE notification is disabled, all stored events are
lost. A new buffer is allocated when the notifications are re-enabled.
When specifying the size of an events buffer, note the following functionality:
It is circular. When the end of the buffer is reached, the buffer starts overwriting the earliest
stored events. (If overwritten events have not yet been reported, you receive a buffer
overflow notice.)
If a new, smaller buffer is requested, all events that are stored in the previous buffer are
lost.
If a new, larger buffer is requested, all existing events are saved.
Note
SDEE messages are transported over HTTP or HTTPS to communicate with management
applicationsCisco SDM, IPS. To use SDEE, the HTTP and HTTPS server must be
enabled (via the ip http server and the ip http secure-server command). If the HTTP and
HTTPS server is not enabled, the router cannot respond to the SDEE clients because it
cannot see the requests.
To specify the method of event notification, use the ip ips notify command in global
configuration mode. To disable event notification, use the no form of this command.
router(config)# ip ips notify [log | sdee]
5-197
Syntax Description
log
(Default) Sends messages in syslog format

Note: You need to set syslog level to 6 to get Cisco IOS IPS
messages
sdee
Note
5-198
(Optional) Sends messages in SDEE format
If an option is not specified, alert messages are sent in syslog format.
Upgrading to the Latest SDF

This topic describes how to upgrade to the latest SDF.
Upgrade to Latest SDF

router (config)#
ip ips name ips-name
Creates an IPS rule

router (config)#
no ip ips sdf builtin
Instructs the router not to load the built-in signatures

router (config)#
ip ips fail closed
Instructs the router to drop all packets until the signature engine is
built and ready to scan traffic
SNRS v2.05-22
An important part of IPS is keeping up with the latest attack signatures. This example creates
an IPS rule, instructs the router not to load the built-in signatures, and to drop all packets until
the signature engine is built and ready to scan traffic. Use the information in this topic to
replace the existing signatures in your router with the latest IPS signature file.
The latest SDF file can be found at http://www.cisco.com/cgi-bin/tablebuild.pl/ios-sigup.
Follow these steps to load the latest SDF:
Step 1
Download the latest SDF file from the link provided.
Step 2
Create an IPS rule.
Step 3
Specify the location where the router will load the SDF.
Step 4
By default, the built-in signatures are configured to be loaded. Optionally, they can
be turned off using the no ip ips sdf builtin command.
Step 5
(Optional) Instructs the router to drop all packets until the signature engine is built
and ready to scan traffic. By default, all packets are passed without being scanned
while the signature engine is being built or if the signature engine fails to build.
Step 6
Enter interface configuration mode.
Step 7
Apply the IPS rule at an interface.
The process is the same as installing IPS on a new router.
5-199
Verifying IPS Configuration

This topic describes the commands that allow you to verify the IPS configuration.
Verifying IPS
R1# show ip ips configuration
Configured SDF Locations:
flash:128MB.sdf
Builtin signatures are enabled but not loaded
Last successful SDF load time: 12:10:43 CST Oct 30 2006
IPS fail closed is disabled
Fastpath ips is enabled
Quick run mode is enabled
Event notification through syslog is enabled
Event notification through SDEE is enabled
Total Active Signatures: 303
Total Inactive Signatures: 0
Signature 50000:0 disable
IPS Rule Configuration
IPS name SNRS-IPS
Interface Configuration
Interface FastEthernet0/1
Inbound IPS rule is SNRS-IPS
Outgoing IPS rule is not set
Verifies that Cisco IOS IPS is properly configured

SNRS v2.05-23
There are several commands available to verify and troubleshoot IPS configuration and
operation. Commands used to verify and troubleshoot IPS include the show, clear, and debug
commands.
To display IPS information such as configured sessions and signatures, use the show ip ips
command.
router# show ip ips {[all] [configuration] [interfaces] [name
name] [statistics [reset]] [sessions [details]] [signatures
[details]]}
Syntax Description
all
Displays all available IPS information
configuration
Displays additional configuration information, including default values that may

not be displayed using the show running-config command
interfaces
Displays the interface configuration
Statistics [reset]
Displays information such as the number of packets audited and the number of
alarms sent
The optional reset keyword resets the sample output to reflect the latest
statistics.
name name
Displays information only for the specified IPS rule
Sessions [details]
Displays IPS session-related information

The optional details keyword shows detailed session information.
5-200
Use the show ip ips configuration command in EXEC mode to display additional
configuration information, including default values that may not be displayed using the show
running-config command.
Verifying IPS (Cont.)

R1# show ip ips signatures
Builtin signatures are configured
Signatures were last loaded from flash:128MB.sdf
Cisco SDF release version 128MB.sdf v2
Trend SDF release version V0.0
*=Marked for Deletion Action=(A)larm,(D)rop,(R)eset
Trait=AlarmTraits
MH=MinHits
AI=AlarmInterval
CT=ChokeThreshold
TI=ThrottleInterval
AT=AlarmThrottle
FA=FlipAddr
WF=WantFrag
Signature Micro-Engine: OTHER (4 sigs)
SigID:SubID On Action Sev Trait
MH
AI
CT
TI AT FA WF Version
----------- -- ------ ---- ----- ----- ----- ----- ----- -- -- -- ------1203:0
Y
A
HIGH
0
0
0
30
15 FA N N 2.2.1.5
1202:0
Y
A
HIGH
0
0
0
100
15 FA N N 2.2.1.5
3050:0
Y
A
HIGH
0
0
0
100
15 FA N
1.0
1201:0
Y
A
HIGH
0
0
0
30
15 FA N N 2.2.1.5
Signature Micro-Engine: STRING.ICMP (1 sigs)
MH
AI
CT
TI AT FA WF Version
----------- -- ------ ---- ----- ----- ----- ----- ----- -- -- -- ------2156:0
Y
A
MED
0
0
0
100
15 FA N
S54
Signature Micro-Engine: STRING.UDP (16 sigs)
MH
AI
CT
TI AT FA WF Version
----------- -- ------ ---- ----- ----- ----- ----- ----- -- -- -- ------11209:0
Y
A
INFO
0
0
0
100
15 FA N
S139
11208:0
Y
A
INFO
0
0
0
100
15 FA N
S139
4608:2
Y
A
HIGH
0
1
0
100
15 FA N
S30b
SNRS v2.05-24
This is an example of the show ip ips signatures command. It verifies signature configuration,
such as signatures that have been disabled.
5-201

R1# show ip ips interfaces
Interface Configuration
Interface FastEthernet0/1
Inbound IPS rule is SNRS-IPS
Outgoing IPS rule is not set
Displays the interface configuration
SNRS v2.05-25
Use the show ip ips interfaces command to display the interface configuration.
5-202

R1# show ip ips signatures
Builtin signatures are configured
Signatures were last loaded from flash:128MB.sdf
Cisco SDF release version 128MB.sdf v2
Trend SDF release version V0.0
*=Marked for Deletion Action=(A)larm,(D)rop,(R)eset
Trait=AlarmTraits
MH=MinHits
AI=AlarmInterval
CT=ChokeThreshold
TI=ThrottleInterval
AT=AlarmThrottle
FA=FlipAddr
WF=WantFrag
Signature Micro-Engine: OTHER (4 sigs)
MH
AI
CT
TI AT FA WF Version
----------- -- ------ ---- ----- ----- ----- ----- ----- -- -- -- ------1203:0
Y
A
HIGH
0
0
0
30
15 FA N N 2.2.1.5
1202:0
Y
A
HIGH
0
0
0
100
15 FA N N 2.2.1.5
3050:0
Y
A
HIGH
0
0
0
100
15 FA N
1.0
1201:0
Y
A
HIGH
0
0
0
30
15 FA N N 2.2.1.5
Signature Micro-Engine: STRING.ICMP (1 sigs)
MH
AI
CT
TI AT FA WF Version
----------- -- ------ ---- ----- ----- ----- ----- ----- -- -- -- ------2156:0
Y
A
MED
0
0
0
100
15 FA N
S54
Signature Micro-Engine: STRING.UDP (16 sigs)
MH
AI
CT
TI AT FA WF Version
----------- -- ------ ---- ----- ----- ----- ----- ----- -- -- -- ------11209:0
Y
A
INFO
0
0
0
100
15 FA N
S139
11208:0
Y
A
INFO
0
0
0
100
15 FA N
S139
4608:2
Y
A
HIGH
0
1
0
100
15 FA N
S30b
SNRS v2.05-24
You can also verify by checking any SDEE or SYSLOG messages.
5-203
clear Commands
This section describes the clear commands.
clear Commands
router#
clear ip ips configuration
Removes all intrusion prevention configuration entries and releases

dynamic resources
router#
clear ip ips statistics
Resets statistics on packets analyzed and alarms sent

router#
clear ip sdee {events | subscriptions}
Clears SDEE events or subscriptions
SNRS v2.05-27
To disable Cisco IOS IPS, remove all intrusion detection configuration entries, and release
dynamic resources, use the clear ip ips configuration command in EXEC mode.
router# clear ip ips configuration
To reset statistics on packets analyzed and alarms sent, use the clear ip ips statistics command
in privileged EXEC mode.
router# clear ip ips statistics
To clear SDEE events or subscriptions, use the clear ip sdee command in privileged EXEC
mode.
router# clear ip sdee {events | subscriptions}
Syntax Description
events
Clears SDEE events from the event buffer
subscriptions
Clears SDEE subscriptions
Because subscriptions are properly closed by the Cisco IOS IPS client, this command is
typically used only to help with error recovery.
5-204
debug Commands
This section covers IPS debug commands.
debug Commands
router#
router#
router#
router#
router#
router#
router#
router#
router#
router#
router#
router#
router#
router#
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
debug
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ips
ips
ips
ips
ips
ips
ips
ips
ips
ips
ips
ips
ips
ips
timers
object-creation
object-deletion
function trace
detailed
ftp-cmd
ftp-token
icmp
ip
rpc
smtp
tcp
tftp
udp
Instead of no, the undebug command may be used.

SNRS v2.05-28
There are numerous debug commands available to troubleshoot IPS operation.

Use the no form of the commands to disable debugging of a given option. Use the undebug all
command to cancel all debugging on the router.
The following is the list of available debug commands:
debug ip ips timers
debug ip ips object-creation
debug ip ips object-deletion
debug ip ips function trace
debug ip ips detailed
debug ip ips ftp-cmd
debug ip ips ftp-token
debug ip ips icmp
debug ip ips ip
debug ip ips rpc
debug ip ips smtp
debug ip ips tcp
debug ip ips tftp
debug ip ips udp
5-205
Summary
Summary
The Cisco IOS IPS acts as an inline intrusion prevention sensor.
An SME is a component of Cisco IOS IPS that supports
signatures in a certain category.
Cisco IOS IPS contains 135 built-in signatures but can be loaded
with over 1500 signatures from signature definition files.
Cisco IOS IPS has two main deployment scenarios.
Several tasks are required to configure Cisco IOS IPS on a router.
Alert logging for IOS IPS can be done with Syslog and SDEE.
An important part of IPS is keeping up with the latest attack
signatures.
There are several commands available to verify and troubleshoot
IPS configuration and operation.
SNRS v2.05-29
References
Cisco Systems, Inc. Configuring Cisco IOS Intrusion Prevention System (IPS).:
http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186
a00804a842f.html
Cisco Systems, Inc. Cisco IOS Security Configuration Guide, Release 12.4T:
09186a008049e249.html
Cisco Systems, Inc. Cisco IOS Security Command Reference, Release 12.4T.
http://cisco.com/en/US/products/ps6441/products_command_reference_book09186a00804
97056.html.
5-206
Lesson 6
Examining Company ABC

Secured
Overview
You have now secured the original unprotected network of Company ABC. This lesson will
give you a brief overview of the improvements that you have made.
Objectives
Upon completing this lesson, you will be able to describe the security features you have
implemented to protect a network. This ability includes being able to meet these objectives:
Describe the changes that you have made to the security of the network of Company ABC
Company ABC Secured

This topic describes the changes that you have made to the security of the network.
Company ABC Secured

Branch
Office
Headquarters
Access
Attacks
Remote traffic is
secure with
secured
connectivity.
Clients are
proper
DHCP
addresses,
thanks to
DHCP
snooping.
Reconnaissance
Attacks
DHCP
Spoofing
Attacks
PCs
Laptops
Telecommuters
No one is gaining
access to network
thanks to Cisco IBNS
DHCP, Domain
Name System,
Active Directory
Servers
Web
Servers
No exploits are
disrupting performance
thanks to Network
Foundation Protection
SNRS v2.05-2
The following technologies that you have implemented have secured the network of Company
ABC:
Layer 2 security
Port security
DHCP snooping
Cisco Identity-Based Networking Services (IBNS)
Cisco Secure Access Control Server (ACS)
IEEE 802.1x Port-based authentication
Network Foundation Protection
Management Plane Protection
Control Plane Protection (CPPr)
Data Plane Protection
Secured connectivity
Virtual private networks (VPNs)
5-208
Flexible Packet Matching
Site-to-site
Using pre-shared keys
Using PKI
Dynamic Multipoint VPN (DMVPN)
Secure Sockets Layer (SSL) VPN
Cisco Easy VPN
Generic routing encapsulation (GRE)
Adaptive Threat Defense (ATD)
Cisco IOS classic firewall
Cisco zone-based policy firewall
Cisco IOS Firewall authentication proxy
Cisco IOS Intrusion Prevention System (IPS)

5-209
Summary
Summary
Company ABC is now secured from the attacks that it was
undergoing.
5-210
SNRS v2.05-3
Module Summary
This topic summarizes the key points that were discussed in this module.
Module Summary
The Cisco IOS Firewall feature set combines existing
Cisco IOS Firewall technology and the Cisco IOS classic
firewall.
Cisco IOS classic firewall works to provide network protection
on multiple levels.
Cisco IOS zone-based policy firewall generally improves Cisco
IOS performance for most firewall inspection activities.
The Cisco IOS Firewall authentication proxy feature enables
network administrators to apply specific security policies on a
per-user basis.
The Cisco IOS IPS acts as an in-line intrusion prevention
sensor.
Company ABC is now secured from the attacks that it was
undergoing.
SNRS v2.05-1
The Cisco IOS Firewall feature set includes an extensive set of tools to secure a network. Some
of the features of Cisco IOS firewall that were discussed are:
IOS Classic Firewall
Zone-based Policy Firewall
Auth-prox
IOS IPS
References
Cisco Systems, Inc. Cisco IOS Security Configuration Guide, Release 12.4
09186a008043360a.html
Cisco Systems, Inc. Cisco IOS Security Command Reference, Release 12.4T:
09186a008049e249.html
Cisco IOS Firewall Design Guide:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_implementation_desig
n_guide09186a00800fd670.html
Cisco Systems, Inc. Cisco IOS Software Releases 12.4 T: Zone-Based Policy Firewall.
http://www.cisco.com/en/US/products/ps6441/products_feature_guide09186a008060f6dd.h
tml
5-211
5-212
Cisco Systems, Inc. Cisco IOS Software Releases 12.4 Mainline: Zone-Based Policy
Firewall Design Guide.
http://www.cisco.com/en/US/products/ps6350/products_feature_guide09186a008072c6e3.
html#wp1066679
Configuring Authentication Proxy:

http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_chapt
er09186a00804ad9bc.html
Cisco Systems, Inc. Configuring Cisco IOS Intrusion Prevention System (IPS).:
http://www.cisco.com/en/US/products/ps6441/products_configuration_guide_chapter09186
a00804a842f.html
Cisco Systems, Inc. Cisco IOS Security Command Reference, Release 12.4T.
http://cisco.com/en/US/products/ps6441/products_command_reference_book09186a00804
97056.html

642-637 Cisco - Press.SNRS - StudentGuide.v2.0.Vol3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

642-637 Cisco - Press.SNRS - StudentGuide.v2.0.Vol3

Uploaded by

Copyright:

Available Formats

SNRS

Configuring Cisco IOS Firewall

Configuring Cisco IOS Classic Firewall

Configuring Cisco IOS Zoned-Based Policy Firewall

Configuring Cisco IOS Firewall Authentication Proxy

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

Test and Verify

Configuring Cisco IOS IPS

Examining Company ABC Secured

2007 Cisco Systems, Inc.

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

2007 Cisco Systems, Inc.

Adaptive Threat Defense

Describe how to configure Cisco IOS Firewall authentication proxy

Describe how to configure Cisco IOS IPS

Describe the security features you have implemented to protect a network

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

2007 Cisco Systems, Inc.

Configuring Cisco IOS Firewall

Describe the basic functions of a firewall

Describe where to use the Cisco IOS Firewall in a production network

Describe the Cisco IOS Firewall feature set

Describe Cisco IOS classic firewall

Describe Cisco IOS Firewall authentication proxy

Describe Cisco IOS IPS

2006 Cisco Systems, Inc. All rights reserved.

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

2007 Cisco Systems, Inc.

Cisco IOS as a Firewall

2006 Cisco Systems, Inc. All rights reserved.

An Internet firewall or part of an Internet firewall

A firewall between groups in your internal network

A firewall providing secure connections to or from branch offices

The Cisco IOS Firewall features provide the following benefits:

Protection of internal networks from attacks and intrusion

Monitoring of traffic through network perimeters

Enabling of network commerce via the World Wide Web

2007 Cisco Systems, Inc.

Adaptive Threat Defense

Cisco IOS Firewall Feature Set

Cisco IOS Firewall Feature Set

2006 Cisco Systems, Inc. All rights reserved.

Standard ACLs and Static Extended ACLS

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

2007 Cisco Systems, Inc.

Lock-and-Key (Dynamic ACLs)

Network Address Translation

2007 Cisco Systems, Inc.

Adaptive Threat Defense

Security Server Support

User Authentication and Authorization

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

2007 Cisco Systems, Inc.

Cisco IOS Classic Firewall

Cisco IOS Classic Firewall

Packets are inspected entering the firewall by Cisco IOS classic

Cisco IOS Classic Firewall

2007 Cisco Systems, Inc.

Adaptive Threat Defense

Securing Networks with Cisco Routers and Switches (SNRS) v2.0

2007 Cisco Systems, Inc.

Cisco IOS Authentication Proxy