Guest

Cisco Security Manager

Applying Zone-based Firewall Policies in Cisco Security Manager

  • Viewing Options

  • PDF (1.6 MB)
  • Feedback
Applying Zone-based Firewall Policies in Cisco Security Manager

Table Of Contents

Applying Zone-based Firewall Policies
in Cisco Security Manager

Introduction

Primary Differences Between Classic and Zone-based Firewall

Overview of Zone-based Firewall Configuration

Defining Security Zones

Zone Pairs and the Self Zone

Zones and Inspection

Zones and Access Rules

Zones and Transparent Firewalls

Zones and VRF Aware Firewall

IPSec VPN and Zone-based Firewall Policies

Zone-based Firewall Policy Restrictions

Designing Zone-based Network Security

Configuring Zone-based Firewall Rules in Security Manager

Creating Zones in Security Manager

Basic Zone-based Firewall Rule Creation in Security Manager

Ordering of Services

Zone-based Firewall Actions

Message Logging

Permit, Deny and Action

Class Maps, Parameter Maps, and Policy Maps

Class Maps

Parameter Maps

Tuning Denial-of-service Protection

Policy Maps

Configuration Examples

Example 1: A Basic Configuration

Defining the Zones and Assigning Interfaces

Configuring the Private-to-Internet Zone-based Firewall Policy

Configuring the Private-to-DMZ Zone-based Firewall Policy

Configuring the Internet-to-DMZ Zone-based Firewall Policy

Configuring the Private-zone Stateful Inspection Firewall Policy

The Completed Rules Table

Example 2: HTTP Application Inspection

About HTTP Application Inspection

Configuring the HTTP Inspection Examples

A Simple HTTP Inspection Example

A More-complex HTTP Inspection Example

Example 3: Instant Messaging and Peer-to-peer Application Control

Instant Messaging Application Inspection

Configuring Peer-to-peer Inspection

Content Filtering

Content Filtering Modes

White Lists, Black Lists, and Blocked Keyword Lists

Caching Recent Requests

Packet Buffering

Basic Content Filtering in Security Manager

About The Many Nested Dialog Boxes

Controlling Access to the Router

Self-zone Policy Limitations

Self-zone Policy Configuration

Configuration Commands From The Examples

CLI for Example 1

CLI for Example 2

Simple HTTP Inspection Example

The More-complex HTTP Inspection Example

CLI for Example 3


Applying Zone-based Firewall Policies
in Cisco Security Manager


First Published: March 2009
Revised: September 2009

The following sections outline the Zone-based Firewall model, and describe using Cisco Security Manager to implement zone-based firewall rules on IOS routers:


Note The information provided in this paper is based on version 3.3.1 of Cisco Security Manager. The appearance of dialog boxes and other aspects of implementation may change in later versions.
 
Also, this paper is based on Zone-Based Policy Firewall Design and Application Guide, which provides additional non-Security-Manager-related information that you may find useful.


Introduction

Cisco IOS® Classic Firewall (formerly known as Context-based Access Control, or CBAC) employed an interface-based configuration model, in which stateful inspection policies were applied to individual interfaces. All traffic passing through a given interface was subject to the same set of inspection rules and traffic entering or leaving a configured interface was inspected based on its direction. This model limited the granularity of the firewall policies and caused confusion regarding proper application of firewall policies, particularly in situations where specific firewall policies were to be applied across multiple interfaces.

Cisco IOS software release 12.4(6)T introduced Zone-based Policy Firewall, or simply Zone-based Firewall (ZBF), a new model for configuring the Cisco IOS Firewall function. This new configuration model provides unidirectional application of firewall policies between groups of interfaces known as "zones." That is, interfaces are assigned to zones, and specific inspection policies are applied to traffic moving between the zones.

Zones establish regions of similar security for your network. Each zone defines a boundary where traffic is subjected to specific restrictions as it crosses into another region of the network. The default ZBF policy between zones is deny all. That is, if no policy is explicitly configured, all traffic between two zones is blocked. This is a significant departure from the earlier model in which traffic was implicitly allowed until explicitly blocked with an access control list (ACL).


Note Traffic between interfaces in the same zone is automatically allowed, as is traffic to and from the router itself.


The zone-based firewall approach offers intuitive policies for multiple-interface routers, and increases the flexibility and granularity of firewall policy application, where different inspection policies can be applied to multiple host groups connected to the same router interface.

Primary Differences Between Classic and Zone-based Firewall

Conceptually, configuration of Classic Firewall and Zone-based Firewall differs in application. Classic Firewall applies static access-control list (ACL) rules on specific router interfaces to define the types of traffic allowed through those interfaces. Stateful packet inspection is applied with "ip inspect" policies that monitor network traffic to allow return packets originated by trusted hosts. Complex Classic Firewall policy extrapolation may be difficult in circumstances where multiple ACLs affect traffic flows, especially when ACLs are applied to both local router traffic, as well as traffic "transiting" the router (entering the router and leaving it through the same or a different interface).

Figure 1 Classic Firewall traffic

With Zone-based Firewalling, router interfaces are assigned to security zones, and firewall inspection rules are applied to traffic moving between the zones. Zone-based Firewall enforces a secure inter-zone policy by default, meaning a given interface cannot pass traffic to interfaces in other security zones until an explicit policy allowing that traffic is defined. Firewall policies define inspection for network protocols, and groups of hosts to which inspection will be applied. Inter-zone policies offer considerable flexibility and granularity, so different inspection policies can be applied to individual hosts, groups of hosts, or subnets connected to the same router interface.

Figure 2 Zone-based Firewall traffic

Each interface can be a member of only one security zone, but zones can include multiple interfaces. When an interface is assigned to a zone, traffic cannot pass between that interface and interfaces in other zones until an explicit policy is configured to allow desired traffic. That is, zone-based firewall enforces a default policy blocking traffic between zones, unless explicitly allowed.

Zone-based firewall rules are established by defining a traffic flow and then choosing an action—such as inspect, pass, or drop—to be applied to that traffic. Additional parameters can be applied to specify connection volumes or other actions such as URL filtering for HTTP traffic.

Overview of Zone-based Firewall Configuration

At its simplest, defining a zone-based firewall rule in Security Manager involves specifying these elements:

The zone from which traffic originates (the "From" zone), and the zone to which the traffic flows (the "To" zone). Together, these are sometimes referred to as a "zone-pair."

An Action to be applied to the defined traffic.

One or more Protocols to be matched.

Additional information can be provided to further refine the traffic definition, and its processing (including inspection or filtering).

Defining Security Zones

A "security zone" is simply a named group of interfaces that have similar functions or security requirements. Therefore, before defining a set of zones, consider the security requirements of each interface and of each zone, and group interfaces that are similar in terms of these requirements. For example, assume router interfaces Ethernet0/0 and Ethernet0/1 are connected to your LAN. These two interfaces are similar in that they represent the internal network, so they can be grouped together for the purposes of firewall configuration.


Note Traffic between interfaces in the same zone is not implicitly subject to any policy—traffic passes freely between interfaces that are members of the same zone until you apply rules to restrict it.


When an interface is assigned to a security zone, immediately the only traffic allowed on the interface is router traffic (traffic to the router or initiated by the router) and intra-zone traffic (traffic between interfaces that are members of the same zone). To permit traffic to or from an interface that is a member of another zone, you must apply one or more zone-based firewall rules that include that zone. If the rule permits traffic (via the Pass, Inspect, or Filtering actions), traffic can flow through the interface to the other zone.


Note It is not required that all router interfaces be members of security zones. However, traffic cannot flow between interfaces that are assigned to a zone and interfaces that are not.


The following illustration depicts a simple security-zone configuration:

Interfaces E0 and E1 are members of security zone Z1.

Interface E2 is a member of security zone Z2.

Interface E3 is not a member of any security zone.

Figure 3 A simple security-zone configuration

For this configuration, the following statements are true:

Traffic flows freely between interfaces E0 and E1 because they are members of the same security zone (Z1).

If no zone-based firewall rules are configured, traffic will not flow between any other interfaces (not E0 and E2, E1 and E2, E3 and E1, nor E3 and E2).

Traffic can flow between E0 and E2, or E1 and E2, only when an explicit zone-based firewall rule is defined permitting traffic between zones Z1 and Z2.

Traffic can never flow between E3 and any of the other three interfaces because E3 is not a member of a security zone.


Note Virtual interfaces can be members of a security zone.


Zone Pairs and the Self Zone

A "zone pair" is a logical construct that represents the two zones, From and To, between which a unidirectional firewall policy has been defined. Note that the same zone cannot serve as both the From and the To zone in a rule.

Each router includes a default, system-defined zone named "Self," which does not have any interfaces explicitly assigned as members. (In fact, all router interfaces are considered members of the Self zone.) The Self zone allows traffic to and from the router itself.

You can specify the Self zone as either the From or To zone in a zone-based firewall rule. This rule then applies to traffic directed to the router or traffic generated by the router; it does not apply to traffic through the router. Refer to "Controlling Access to the Router" on page 54 for additional information about the Self zone.


Note The Inspect action is not allowed in rules that include the Self zone.


Zones and Inspection

Zone-based firewall rules are applied to ingress and egress interfaces based on zone membership. To permit traffic between zones, you must configure rules that either pass, inspect, or filter traffic between two specific zones. The following figure depicts application of zone-based firewall rules 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.

Figure 4 Basic Zone-based Firewall

Zone-based firewall rules are unidirectional—if you require examination of traffic going in both directions (from Z1 to Z2 and from Z2 to Z1 in the previous figure), you must configure two distinct rules with two separate zone pairs, since zone pair Z1-Z2 is not the same as zone pair Z2-Z1.

However, if Inspect is the chosen Action, it is not necessary to configure a rule solely for return traffic. Return traffic is automatically allowed if an Inspect rule permits the traffic in one direction.

It is not necessary that all traffic flowing to or from an interface be inspected; you can designate individual traffic flows between zones to be passed or dropped. You also can define rules based on content filtering. For example, you can define a policy that performs HTTP URL filtering for hosts on 192.168.1.0/24, and another that does plain HTTP inspection for 192.168.2.0/24 hosts, both for inside-to-outside traffic.

This results in two flow definitions (192.168.1.0/24 to any host, and 192.168.2.0/24 to any host), and you can apply different policy parameters to each to configure the desired behaviors. You can also configure Inspect parameters like TCP thresholds and timeouts on a per-flow basis.

Zones and Access Rules

If access rules are applied to interfaces that are members of zones, the access rules are processed before the zone-based firewall rules. So, you must relax existing interface access rules when defining zone-based firewall rules on the device, to ensure the access rules do not interfere with the zone-based firewall rules.

Zones and Transparent Firewalls

Cisco IOS firewall software supports transparent firewalls where the interfaces are placed in bridging mode and IP firewalling is performed on the bridged traffic. A bridged interface can be a member of a zone. In a typical case, the Layer 2 domain is partitioned into zones and a firewall policy is applied the same manner as for Layer 3 interfaces. See "Example 1: A Basic Configuration" on page 16 for an example.

Transparent Firewall Restriction for P2P Inspection

A Cisco IOS firewall uses Network Based Application Recognition (NBAR) for peer-to-peer (P2P) protocol classification and policy enforcement. However, NBAR is not available for bridged packets; thus, P2P packet inspection is not supported for firewalls with transparent bridging. See "Configuring Peer-to-peer Inspection" on page 46 for more information.

Zones and VRF Aware Firewall

Cisco IOS firewall software is Virtual Routing and Forwarding (VRF) aware. It handles IP address overlap across different VRFs, separate thresholds and time-outs for VRFs, and so forth. All interfaces in a zone must belong to the same VRF.


Note 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.


You can define rules between two zones that contain different VRFs, as shown in the following figure.

Figure 5 Zones and VRF

When multiple VRFs are configured on a router and an interface provides common services to all the VRFs (for example, Internet access), you should place that interface in a separate zone. You can then define rules between the common zone and other zones. (There can be one or more zones per VRF.)

Referring to the previous illustration, the interface providing common services is a member of the zone "common." All of VRF A is in a single zone, vrf_A. VRF B, which has multiple interfaces, is partitioned into two zones, vrf_B_1 and vrf_B_2. Zone Z1 does not include any VRF interfaces. You can define policies between each of these zones and the common zone. Additionally, you can specify polices between each of the zones vrf_A, vrf_B_n and Z1 if VRF route export is configured and the traffic patterns make sense. You can configure a policy between zones vrf_A and vrf_B_1, but be sure that traffic can flow between them.

If traffic does not flow between VRFs (because route-leaking between VRFs is not configured), the zone-based firewall policy across the VRFs is not executed. This is a misconfiguration on the routing side, not on the policy side.

IPSec VPN and Zone-based Firewall Policies

Recent enhancements to the IP Security (IPsec) VPN implementation simplify firewall policy configuration for VPN connectivity. IPSec Virtual Tunnel Interface (VTI) and GRE+IPSec allow the confinement of VPN site-to-site and client connections to a specific security zone. Connections can be isolated in a VPN DMZ if connectivity must be limited by a specific policy. Or, if VPN connectivity is implicitly trusted, VPN connectivity can be placed in the same security zone as the trusted inside network.

To configure the router to use zone-based firewall rules with dynamic VPNs (those which dynamically create Tunnel/Loopback/Virtual interfaces):

1. Define a zone specifically for the VPN interfaces.

2. Provide the name of this zone in the VPN Zone field on the VPN tab of the Zone Based Firewall page (in Device View, select Firewall > Settings > Zone Based Firewall).

3. Create zone-based firewall rules to allow the VPN traffic, as appropriate.

If non-VTI IPsec is employed, you must exercise caution when you configure a zone-based firewall policy for VPN. The zone policy must specifically allow access to protected hosts by remote VPN hosts or clients if they are in a different zone than the ingress interface for encrypted VPN traffic. This access policy must be configured by including an access control list (ACL) enumerating the source IP addresses of the VPN clients, and the destination IP addresses of all protected hosts the VPN clients are allowed to reach. If the access policy is not properly configured, the policy could expose vulnerable hosts to hostile traffic. Refer to the paper, Using VPN with Zone-Based Policy Firewall, for further concept and configuration discussion.

Zone-based Firewall Policy Restrictions

The following restrictions apply to zones, member interfaces, and inter-zone traffic:

A zone must be defined before interfaces can be assigned to it.

Each interface can be assigned to only one security zone.

An interface cannot be part of a zone and a legacy inspection policy at the same time.

According to the default deny all policy, all traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone. The only exceptions to this rule are:

Traffic is allowed to flow between interfaces that are members of the same zone, until explicitly denied.

Management traffic is implicitly allowed to and from, and between, interfaces on the same router—that is, "Self" zone traffic—until explicitly denied.

To explicitly permit traffic to and from a zone-member interface, a set of rules (a policy) allowing or inspecting traffic must be configured between that zone and another zone.

Traffic cannot flow between an interface that is a zone member and any interface that is not a zone member. Pass, inspect, filter, and drop actions can only be applied between two zones.

The same zone cannot be specified as both the From and the To zone for a rule. (On Cisco Aggregation Services Routers, the From and To zones can be the same, because intra-zone traffic inspection is allowed on those devices.)

Interfaces that have not been assigned to a zone can operate as classic router ports, and may be configured to use classic stateful-inspection/CBAC policies.

All interfaces in a security zone must belong to the same virtual routing and forwarding (VRF) instance. See "Zones and VRF Aware Firewall" on page 6 for more information.


Note If you require that an interface on the router not be part of the overall zoning/firewall configuration, and yet you want traffic to flow between it and another zone-member interface, it may be necessary to assign that interface to a separate zone and configure a "pass-all" policy (sort of a dummy policy) between this separate zone and the other zone, since traffic cannot flow between zone-member interfaces and non-zone-member interfaces.


Designing Zone-based Network Security

A security zone should be configured for each region of relative security within the network, so that all interfaces assigned to the same zone will be protected with a similar level of security. For example, consider an access router with three 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 demilitarized zone (DMZ), where a Web server, Domain Name System (DNS) server, and e-mail server must be accessible to the public Internet.

Each router interface in this network will be assigned to its own zone, as shown in the following illustration, although in a real network you might allow varied levels of access from the public Internet to specific hosts in the DMZ, and varied application-use policies for hosts in the protected LAN.

Figure 6 Basic Security Zone Topology

In this example, each zone includes only one interface. However, if an additional interface were added to the Private zone, the hosts connected to the new interface in the zone could immediately pass traffic to all hosts on the original interface in that zone. Additionally, traffic through the additional interface to hosts in other zones would immediately be controlled by existing policies.

Typically, this example network will have three main zone-based firewall policies defining:

Private-zone connectivity to the Internet

Private-zone connectivity to DMZ hosts

Internet-zone connectivity to DMZ hosts

Configuring Zone-based Firewall Rules in Security Manager

The following information is specific to use of Cisco Security Manager to define zone-based firewall rules and policies on IOS routers.


Note The following sections and examples assume that the referenced routers have already been discovered, and are being configured and managed using Security Manager. We also assume that you are at least somewhat familiar with Security Manager; especially with selecting devices, opening dialog boxes, and selecting policy objects.


Creating Zones in Security Manager

Security Manager's Interface Role object has been adapted for use with zone-based firewall rules, and zones are based on interface names and naming patterns. For example, you might create a Interface Role object named DMZ that includes all interfaces beginning with "DMZ" (i.e., DMZ*).

To create a zone in Security Manager:


Step 1 Open the Add Interface Role dialog box.

You can either open the Policy Object Manager, select Interface Roles, and then click the New Object button to open this dialog box; or in any dialog box that provides a zone-specification field, you can click Select next to that field to open the Zones Selector dialog box, and then click the Create button in the Zones Selector dialog box.

Step 2 Provide a Name for the zone, enter one or more Interface Name Patterns, and then click OK to close the dialog box.

An interface name pattern can be a specific interface name, or a pattern that incorporates wildcards, such as the asterisk and question mark. Separate multiple entries with commas.


You also can create unreferenced or "empty" zones on the Zones tab of the Zone Based Firewall page (in Device View for the router, select Firewall > Settings > Zone Based Firewall). Unreferenced zones are zones without any associated interfaces, rules or policies; these zones are generally found and listed during device discovery.

Basic Zone-based Firewall Rule Creation in Security Manager

In Cisco Security Manager, zone-based firewall rule configuration is quite similar to configuring a standard firewall Access Rule, and the dialog boxes may seem familiar. The basic steps are as follows:


Step 1 If they do not yet exist, create the necessary zones, as described previously in the section "Creating Zones in Security Manager."

Referring to the Basic Security Zone Topology depicted earlier (Figure 6 on page 8), let's assume you have created three zones, Private, DMZ and Internet.

Step 2 Define a zone-based firewall rule for a specific traffic flow from Private to DMZ.

a. Open the Add Zone-based Firewall Rule dialog box:

For the selected router, navigate to the Firewall > Zone Based Firewall Rules page, and then click the Add Row button.

The Enable Rule checkbox is provided to let you enable or disable each rule without deleting the rule definition.

b. Choose a Match action, either Permit or Deny.

A particular traffic flow, as defined by the Source, Destination and Services fields, is either "permitted" or "denied." If permitted, the matching packets are processed according to the parameters given in the Action section of the dialog box. If the traffic is denied, it is exempt from this rule, meaning rules checking continues for these packets. Generally, we recommend using only Permit rules. Refer to "Permit, Deny and Action" on page 12 for additional discussion of Permit and Deny.

c. Define the specific Traffic flow:

Optionally, provide Source and Destination hosts and networks. The default traffic definition encompasses packets from any source to any destination, but you can use these fields to refine this base traffic definition by providing one or more source and destination hosts or networks. You can enter one or more IP addresses/netmasks, one or more Networks/Hosts objects, or a combination of both; separate all entries with commas.
Specify the protocol or Service that indicates the type of traffic; for example, IP, TCP, etc. You can provide more than one Service, unless you want to specify IP, which as the only Layer 3 protocol, must stand alone. Selecting IP replaces any existing Services in the list, while selecting any other Service will replace IP in the list. See the following section, " Ordering of Services," for information about ordering the specified Services.
Provide the From Zone; in this example, Private. For this rule, this is the only zone from which traffic can originate.
Provide the To Zone; in this example, DMZ. For this rule, this is the only zone to which traffic can flow. Together, the From Zone and the To Zone constitute the rule's "zone-pair."

d. Specify the processing to be applied to traffic matching this definition by choosing a base Action, and supplying additional parameters as necessary. For this example, we will choose Pass.

The base Actions are:
Drop - Matching traffic is silently dropped.
Drop and Log - Matching traffic is logged and dropped.
Pass - Traffic is forwarded. Remember, zone-based firewall rules are generally unidirectional; Pass allows traffic in only the specified direction.
Pass and Log - Traffic is logged and forwarded.
Inspect - This option offers state-based traffic control; Inspect can provide application inspection and control, based on Port to Application Mapping (PAM), and for certain protocols, a deep-inspection map can be applied.
Content Filter - Lets you configure HTTP content inspection based on a WebFilter parameter map, or a WebFilter policy map.

Note The Log options generate system-log messages; you must ensure that syslog logging is configured to capture these messages.


See "Zone-based Firewall Actions" on page 12 for additional information about the base Actions.

e. When finished, click OK to close the Add Zone-based Firewall Rule dialog box, saving the rule.


Since we used the default Sources (any), Destinations (any), and Services (IP) in the dialog box, this rule passes all IP traffic from Private interfaces to DMZ interfaces.

Ordering of Services

When multiple services are provided in a zone-based firewall rule definition, they must be in order of more specific to less specific. For example, with the services HTTP and TCP, HTTP must be listed first, to ensure HTTP inspection of the traffic occurs first. If the entries are reversed, with TCP inspection occurring first, the traffic is simply classified as TCP traffic, and inspected accordingly, without further processing.

This is a problem for certain services such as FTP, TFTP, and several multimedia and voice-signaling services such as H.323, SIP, Skinny, RTSP, and others. These services require additional inspection capabilities to recognize the more complex activities of these services.

Security Manager will ensure the services are ordered correctly when the configuration commands are transmitted to the device. Even so, to avoid confusion, we recommend entering services in the appropriate order when defining zone-based firewall rules.

Zone-based Firewall Actions

Zone-based firewall rules provide four base Actions for traffic travelling from one zone to another:

Drop - Traffic is silently dropped, meaning no notification is sent to the relevant end-host (as opposed to the ACL behavior of sending an ICMP "host unreachable" message to the source host). This is the default action for all traffic not explicitly allowed by a set of zone-based firewall rules.

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 allows traffic in only one direction; a corresponding policy must be applied to allow return traffic to pass in the opposite direction. Pass is useful for protocols such as IPSec ESP, IPSec AH, ISAKMP, and other inherently secure protocols with predictable behavior. However, most application traffic is better handled with the Inspect action.

Inspect - The Inspect action offers state-based traffic control. For example, if traffic from the Private zone to the Internet zone in our earlier example network is inspected, the router maintains connection or session information for TCP and User Datagram Protocol (UDP) traffic. Therefore, the router would automatically permit return traffic sent from Internet-zone hosts in reply to Private-zone connection requests. Also, Inspect can provide application inspection and control for certain service protocols that might carry vulnerable or sensitive application traffic. An audit trail can be set up to record connection/session start, stop, duration, data volume transferred, and source and destination addresses.

Content Filter - This action provides content filtering, to protect your network and users from malicious or inappropriate Web content. The router intercepts HTTP requests, performs deep packet inspection, and optionally contacts a third-party service to determine whether the requests should be allowed or blocked. You can provide a WebFilter parameter map, which defines filtering based on local URL lists, as well as information from an external SmartFilter (previously N2H2) or Websense server. Alternately, you can provide a WebFilter policy map that accesses Local, N2H2, Websense, or Trend Micro filtering data. Port application mapping (PAM) is also available for refinement of the HTTP traffic definition. See "Content Filtering" on page 47 for more information about content filtering.

Message Logging

The "and Log" actions (Drop and Log and Pass and Log) are the same as the related non-log actions, plus transmission of a syslog message each time the related action occurs. For example, if Drop and Log is specified for a particular zone-based firewall rule, every time packets matching the rule are dropped, a syslog message is generated. Note that syslog logging must be configured on the router to ensure these messages are captured.

Syslog and audit-trail logging is available for inspected and content-filtered traffic. Select Enable Alert and Enable Audit Trail, respectively, in the assigned Inspect Parameter Map. See "Parameter Maps" on page 14 for more information.

Permit, Deny and Action

When you create a zone-based firewall rule, you specify two execution-related settings: Permit/Deny and an Action (Drop, Pass, Inspect, or Content Filter). To obtain the results you want, you must understand the relationship between these two parameters:

Permit/Deny - The Permit/Deny setting seems to correspond to Permit/Deny in an access control list (ACL) entry. However, in zone-based firewall rules, unlike in standard access rules, these keywords do not expressly permit or deny traffic. Instead, they specify whether you want to apply the chosen Action to the traffic flow defined by the Source, Destination and Services fields, and they affect further processing of related class maps.

Permit - Applies the chosen Action to traffic that matches the Source, Destination, and Services fields. If protocols are listed in the Protocols table, the Action is further limited to those protocols.

Deny - Exempts the traffic defined by the Source, Destination, and Services fields. If protocols are listed in the Protocols table, the exemption is further limited to those protocols. The matched traffic is treated as if it does not match the rule, and subsequent class maps (which are not the same as zone rules) are evaluated. If no subsequent map applies to the traffic, the final, default rule is applied.

It is important to understand that there is not a one-to-one relationship between zone rules and their related class maps, and thus you cannot determine how zone-based rules will be converted to class maps just by looking at the rules table. You must preview the configuration to see which subsequent maps might be applied to traffic that matches your Deny rule. To preview the configuration, save your changes and choose Preview Configuration from the Tools menu.
However, essentially all of your zone-based rules should be Permit rules. This is the easiest configuration to understand—it means you are identifying the traffic to which you want the chosen Action applied.
For example, you might use a Deny rule to exempt a specific IP address within a subnet from a Permit rule you want to apply to the subnet in general; for example, exempting 10.100.10.1 from a rule applied to 10.100.10.0/24. But it would be much easier to create a Permit rule for the specific IP address and apply a desired Action, and ensure that this specific rule is listed above the general rule in the zone-based rules table.

Action - The Action parameters define what happens to traffic that matches a Permit rule. These parameters are ignored for Deny rules, except to determine the class map to which the rule is added.

When you create a Permit rule, traffic that matches the Source, Destination, Services, and Protocol fields is processed according to the Action you choose: drop the traffic (and optionally log it), pass the traffic (and optionally log it), inspect the traffic, or apply content filtering (for Web traffic only).
When you inspect traffic for some protocols, or perform content filtering, you have the option of specifying a policy map to use for deep inspection. The deep inspection policy map also specifies actions based on the deeper characteristics of the traffic. This additional inspection applies to packets that meet the requirements of the class map to which the assigned policy map refers. Packets that do not match the deep inspection class map are allowed. Thus, deep inspection might reset TCP connections if the policy map specifies that action.

Class Maps, Parameter Maps, and Policy Maps

Security Manager provides a number of "map" objects—reusable sets of values or specifications—that can be used as building blocks to simplify various aspects of network set-up and security configuration. Three of these objects in particular can be used to simplify development of zone-based firewall rules:

A class map (or "traffic class") defines a specific traffic flow based on packet contents. That is, each class map recognizes a particular type of packet based on a specific definition.

A policy map (or simply a "policy") defines a set of rules or actions to be applied to a particular traffic class.

A parameter map is a set of specific values or parameters that can be applied to an Inspect or Content Filter rule to refine traffic inspection.

All three of these type of maps can be created through Security Manager's Policy Object Manager (Tools > Policy Object Manager), or you can create class maps and parameter maps "on the fly" from zone-based rule-related dialog boxes.

Class Maps

Class maps define the traffic that the device selects for policy application. Layer 3/4 and Layer 7 class maps (and policy maps) are available. Layer 3/4 class maps identify traffic flows, and Layer 3/4 policy maps specify actions to be taken on them. Security Manager effectively hides simple Layer 3/4 map creation within the rules definition (Sources, Destination, Services, Action, and any related Protocol). However, as mentioned, application-specific Layer 7 maps are supported as reusable objects, requiring additional configuration.

An application-specific class map identifies traffic based on the attributes of a given protocol. All the match conditions in these class maps are specific to an application (for example, HTTP or SMTP). Inspect class maps can be configured to match the following types of Layer 7 traffic:

America Online (AOL) instant messaging

eDonkey peer-to-peer (P2P)

FastTrack P2P

Gnutella Version 2 P2P

H.323 - Packet-based multimedia communications system

HyperText Transport Protocol (HTTP)

"I seek you" (ICQ) instant messaging

Internet Message Access Protocol (IMAP) - Method of accessing e-mail or bulletin board messages kept on a shared mail server.

Kazaa Version 2 P2P

MSN Messenger IM

Post Office Protocol, version 3 (POP3) - Protocol that client e-mail applications use to retrieve mail from a mail server

Session Initiation Protocol (SIP)

Simple Mail Transfer Protocol (SMTP)

Sun RPC

Windows Messenger IM

Yahoo! Messenger IM

In addition, specific Web Filter class maps can be configured for Local, N2H2, Trend Micro, and Websense content-filtering definitions.

Parameter Maps

Parameter maps specify inspection behavior for parameters such as Denial of Service (DoS) protection, TCP connection/UDP session timers, and audit-trail logging. Parameter maps are also applied with Layer 7 class and policy maps to define application-specific behavior, such as HTTP objects, POP3 and IMAP authentication requirements, and other application-specific information.

There are two types of parameter map:

Inspect parameter map - Inspect parameter maps specify connection, time-out, audit, and other parameters applied by Layer 7 application-inspection policies. These parameter maps are optional. If you do not configure an Inspect parameter map, Security Manager uses default parameters. You can also configure Protocol Info parameter maps that list DNS servers for an Instant Messenger application policy.

Web Filter parameter map - A parameter map is required for URL filtering (and is selected as part of a Web Filter policy map). You can configure Local, N2H2, Trend Micro, URL Filter, URLF Glob, and Websense parameter maps.

Tuning Denial-of-service Protection

Cisco IOS Firewall maintains counters of the number of "half-open" TCP connections, as well as the total connection rate through the firewall and intrusion prevention software, in both Classic Firewall and Zone-based Firewall implementations. Half-open connections are TCP connections that have not completed the three-way 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 User Datagram Protocol (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—thus, UDP sessions without return traffic are either indicative of DoS activity, or of attempts to connect where one of the hosts has become unresponsive. Large numbers of half-open connections may be indicative of malicious activity such as DoS or distributed-denial-of-service (DDoS) attacks.

Prior to Cisco IOS release 12.4(11)T, Cisco IOS Firewall provided denial-of-service (DoS) attack protection when either Classic or Zone-Based Firewall was applied. Cisco IOS release 12.4(11)T modified the default DoS settings so protection is effectively disabled, but the connection activity counters are still active. These counters include Max Incomplete Low, Max Incomplete High, One Minute Low, One Minute High, and TCP Max Incomplete Hosts, and they can be adjusted as part of an Inspect Parameter map, which can be applied when Inspect or Content Filter is the chosen Action for a zone rule. Refer to the white paper, Tuning Cisco IOS Classic and Zone-Based Policy Firewall Denial-of-Service Protection for detailed information about these parameters.

Policy Maps

A policy map, or policy, is an association of traffic classes and actions. It specifies what actions should be performed on the defined traffic. An action is a specific function, and it is typically associated with a traffic class. The basic actions are allow, reset (which closes the TCP connection, dropping the connection), and log. With SMTP, there is an additional action, mask, which masks the identified element in the packet.


Note The action chosen for a policy map is unrelated to the Action chosen for a zone-based firewall rule in the Add or Edit Zone based Firewall dialog boxes.


Application-specific policy maps are used to define an inspection policy for a specific application protocol. For example, if you want to drop HTTP traffic with uniform resource identifier (URI) lengths exceeding 256 bytes, you must configure an HTTP policy map to do that. Security Manager's Policy Object Manager provides a number of Inspect-type policy maps, as well as a Web Filter policy map.

Configuration Examples

This section contains the following examples of zone-based firewall rule configuration in Security Manager:

"Example 1: A Basic Configuration" on page 16

"Example 2: HTTP Application Inspection" on page 30, which actually consists of two examples:

"Example 3: Instant Messaging and Peer-to-peer Application Control" on page 40

"Content Filtering" on page 47, discusses URL filtering in detail, but does not provide a set of steps defining a specific example

Please note that each successive example builds on the earlier examples, in that standard rule-related processes and procedures described once are not described in detail again in later examples. Those steps are simply referenced, presuming you remember them. So, if you are reading the examples out of order and the description of a certain step or process seems "thin," check the earlier examples for more detail.

Also, as mentioned, the following examples assume that the referenced routers have already been discovered, and are being configured and managed using Security Manager. We also assume that you are at least somewhat familiar with Security Manager; especially with selecting devices, opening dialog boxes, and selecting policy objects.

Example 1: A Basic Configuration

This example describes defining a specific set of zone-based firewall rules on a Cisco 1811 Integrated Services Router (ISR) that is managed by Cisco Security Manager. The example presents a basic configuration with IP connectivity, VLAN configuration, and transparent bridging between two private Ethernet LAN segments.

For the example, the router has four interfaces which are assigned to five zones:

The public Internet is connected to the interface FastEthernet0; this is labeled the "Internet" zone.

Two Internet services hosts are connected to FastEthernet1; this is the "DMZ" zone.

Two VLAN interfaces represent an internal local-area network (the "Private" zone). Each VLAN represents a separate sub-zone:

Individual workstations are connected to VLAN1; this is the "Client" zone.

Internal LAN support servers are connected to VLAN2; this is the "Server" zone.

The Client and Server zones are on the same subnet. A transparent firewall is applied between the two zones, so the inter-zone policies on those two interfaces will only affect traffic between the Client and Server zones.

The VLAN1 and VLAN2 interfaces communicate with other zones through the bridge virtual interface, "BVI1," which is assigned to the Private zone.

The following figure depicts this configuration.

Figure 7 Example 1: Zone Topology

The following zone-based firewall policies are defined on this router:

Hosts in Internet zone can access DNS, SMTP, and SSH services on one server in the DMZ. The other server will offer SMTP, HTTP, and HTTPS services. Access to the specific services will be restricted to the appropriate host. See "Configuring the Internet-to-DMZ Zone-based Firewall Policy" on page 24.

The DMZ hosts cannot connect to hosts in any other zone.

Hosts in the Client zone can connect to hosts in the Server zone for all TCP, UDP, and ICMP services. See "Configuring Clients-to-Servers traffic" on page 28.

Hosts in the Server zone cannot connect to hosts in the Client zone, except any UNIX-based application server can open an X Windows client session on an X Windows host in the Client zone, on ports 6900 to 6910. See "Configuring Servers-to-Clients traffic" on page 25.

All hosts in the Private zone (any host in the Client and Server sub-zones) can access hosts in the DMZ on SSH, FTP, POP, IMAP, ESMTP, and HTTP services. Private-zone hosts can also access the Internet zone via HTTP, HTTPS and DNS services, and ICMP. See "Configuring the Private-to-Internet Zone-based Firewall Policy" on page 20 and "Configuring the Private-to-DMZ Zone-based Firewall Policy" on page 22.

The following figure indicates the services permitted between the zones, as described above.

Figure 8 Example 1: Services available between the zones

We will describe configuring the firewall rules for this example in the following order:

1. Private to Internet - HTTP/HTTPS/DNS/ICMP, with HTTP application inspection

2. Private to DMZ - SSH/FTP/POP/IMAP/ESMTP/HTTP inspection

3. Internet to DMZ - SMTP/HTTP/DNS inspection restricted by host address

4. Servers to Clients - X Windows inspection with a specific port-application mapping

5. Clients to Servers - TCP/UDP/ICMP inspection


Note We recommend defining all of these rules before deploying them to the device. If you apply the rules one at a time, each affected network segment will lose connectivity to the other segments when it is assigned to a zone. For instance, if the Private-zone rules are configured and immediately deployed, hosts in the Private zone will lose connectivity to the DMZ and Internet zones until their respective rules are defined.


Defining the Zones and Assigning Interfaces

Before defining the zone-based firewall rules for this example, you must ensure the necessary interfaces are configured on the router, and define the appropriate zones. Note that you can define zones while configuring a zone-based rule, but for clarity, we present it as a separate step here.

Define the necessary interfaces and zones on the selected 1811 ISR in Security Manager:


Step 1 To create the interfaces, access the Interfaces page (Interfaces > Interfaces).

a. Define the FastEthernet0 interface; in the example, we use IP address 172.16.1.88, with 255.255.255.0 for the subnet mask.

b. Define the FastEthernet1 interface; use 172.16.2.1 and 255.255.255.0.

c. Define the VLAN1 interface; no address specified.

d. Define the VLAN2 interface; no address specified.

e. Define the BVI1 interface; use 192.168.1.254 and 255.255.255.0.


Note Descriptions of use of the Create Router Interface, Interface Auto Name Generator, and Add Bridge Group dialog boxes is beyond the scope of this document, and we assume you can accomplish these basic tasks. Refer to the Security Manager user guide or online Help for addtional information.


Step 2 Access the router's Bridging page (Platform > Device Admin > Bridging), create a bridge group numbered 1, and add VLAN1 and VLAN2. (The bridge group and related BVI must use the same number, and we created BVI1 in Step 1.)

Creating an IEEE Bridge group with two or more router interfaces provides Integrated Routing and Bridging (IRB) between the interfaces in the Bridge group, and routing to other subnets via a Bridge Virtual Interface (BVI). Transparent firewall inspection is applied for traffic "crossing the bridge," but not for traffic that leaves the Bridge group via the BVI. Therefore, in this example, the transparent firewall inspection will be applied only to traffic that moves between the Clients and Servers zones, which are nested inside the Private zone. The zone-based rules, defined between the Private zone and the Internet and DMZ zones, are applied only when traffic leaves the Bridge group via the BVI.

Step 3 Create the necessary zones, and add the appropriate interfaces to them:

a. Open the Policy Object Manager (Tools > Policy Object Manager) and select Interface Roles.

In Security Manager, zones are considered Interface Role objects.

b. Create an Interface Role (zone) named Private and enter BVI1 in the Interface Name Patterns field.

c. Repeat Steps 3a and 3b as follows:

· Create an Interface Role (zone) named Internet and enter FastEthernet0 in the Interface Name Patterns field.
· Create a zone named DMZ and add FastEthernet1 to the Interface Name Patterns field.
· Create a zone named Servers and enter VLAN2 in the Interface Name Patterns field.
· Create a zone named Clients and enter VLAN1 in the Interface Name Patterns field.

d. Close the Policy Object Manager.


Interface and zone configuration for the example is complete.

Configuring the Private-to-Internet Zone-based Firewall Policy

The Private-to-Internet zone policy applies Layer 4 inspection to HTTP, HTTPS, DNS, and ICMP traffic travelling from the Private zone to the Internet zone. This policy provides connections from the Private zone to the Internet zone, and allows return traffic for established connections.

Figure 9 Service inspection from the Private zone to the Internet zone

To define this Private-to-Internet zone-based firewall rule in Security Manager:


Step 1 Access the Zone Based Firewall Rules page for the selected router (Firewall > Zone Based Firewall Rules).

Step 2 Click the Add Row (+) button to open the Add Zone Based Firewall Rule dialog box.

a. In the From Zone field, enter or Select the Private zone.

b. In the To Zone field, enter or Select the Internet zone.

c. Choose Inspect from the Action menu.

d. Click Select next to the Protocol table to open the Protocol Selector dialog box.

e. One at a time, select HTTP, HTTPS, DNS, and ICMP in the Available Protocols list and click the >> button each time, adding them to the Selected Protocols list.

f. Click OK to close the Protocol Selector dialog box, adding the selected protocols to the table in the Add Zone Based Firewall Rule dialog box.

Step 3 Click OK to close the Add Zone Based Firewall Rule dialog box, adding the new zone-based firewall rule to the table on the Zone Based Firewall Rules page.


This completes configuration of the inspection rule for Private-to-Internet traffic to allow HTTP, HTTPS, DNS, and ICMP connections from the Clients and Servers zones. The illustration in "The Completed Rules Table" on page 29 presents the Zone Based Firewall Rules table listing all the rules configured during this example.

Configuring the Private-to-DMZ Zone-based Firewall Policy

The Private-to-DMZ zone policy adds complexity because it requires a better understanding of the network traffic between zones. This policy applies Layer 7 inspection from the Private zone to the DMZ, allowing connections from the Private zone to the DMZ, and allowing return traffic. Layer 7 protocols that are not specifically selected for inspection will not be allowed between the zones.

Figure 10 Service inspection from the Private zone to the DMZ

To create this Private-to-DMZ zone-based firewall traffic rule in Security Manager:


Step 1 If not displayed, access the Zone Based Firewall Rules page (Firewall > Zone Based Firewall Rules).

Step 2 Open the Add Zone Based Firewall Rule dialog box.

a. In the From Zone field, enter or Select the Private zone.

b. In the To Zone field, enter or Select the DMZ zone.

c. Choose Inspect from the Action menu.

d. Click Select next to the Protocol table to open the Protocol Selector dialog box.

e. One at a time, select SSH, FTP, POP, IMAP, ESMTP, and HTTP in the Available Protocols list and click the >> button each time, adding them to the Selected Protocols list.

f. Click OK to close the Protocol Selector dialog box, adding the selected protocols to the table in the Add Zone Based Firewall Rule dialog box.

Step 3 Click OK to close the Add Zone Based Firewall Rule dialog box, adding the new zone-based Firewall rule to the table on the Zone Based Firewall Rules page.


This completes configuration of the inspection rule for Private-to-DMZ traffic, providing an example of a simple policy to accommodate most application connections. The illustration in "The Completed Rules Table" on page 29 presents the Zone Based Firewall Rules table listing all the rules configured for this example.

Configuring the Internet-to-DMZ Zone-based Firewall Policy

The Internet-to-DMZ zone policy applies Layer 7 inspection to traffic from the Internet to the DMZ, allowing return traffic to the Internet hosts that originated the connection. This zone policy combines Layer 7 inspection with destination restrictions, allowing access to specific services on specific hosts. This is accomplished with two zone rules, both of which include specific Destination IP addresses.

Figure 11 Service inspection from the Internet zone to the DMZ

Differing access policies will be applied for the two different DMZ servers. Internet hosts are allowed DNS and HTTP connections to 172.16.2.2, and SMTP connections are allowed to 172.16.2.3.

To create these Internet-to-DMZ zone-based firewall traffic rules in Security Manager:


Step 1 If not displayed, access the Zone Based Firewall Rules page (Firewall > Zone Based Firewall Rules).

Step 2 Open the Add Zone Based Firewall Rule dialog box.

a. In the Destinations field, replace "any" with 172.16.2.2.

b. In the From Zone field, enter or Select the Internet zone.

c. In the To Zone field, enter or Select the DMZ zone.

d. Choose Inspect from the Action menu.

e. Click Select next to the Protocol table to open the Protocol Selector dialog box.

f. One at a time, select DNS and HTTP in the Available Protocols list and click the >> button each time, adding them to the Selected Protocols list.

g. Click OK to close the Protocol Selector dialog box, adding the selected protocols to the table in the Add Zone Based Firewall Rule dialog box.

Step 3 Click OK to close the Add Zone Based Firewall Rule dialog box, adding the new zone-based firewall rule to the table on the Zone Based Firewall Rules page.

Step 4 Open the Add Zone Based Firewall Rule dialog box again.

a. In the Destinations field, replace "any" with 172.16.2.3.

b. In the From Zone field, enter or Select the Internet zone.

c. In the To Zone field, enter or Select the DMZ zone.

d. Choose Inspect from the Action menu.

e. Click Select next to the Protocol table to open the Protocol Selector dialog box.

f. Select SMTP in the Available Protocols list and click the >> button to add it to the Selected Protocols list.

g. Click OK to close the Protocol Selector dialog box, adding the selected protocol to the table in the Add Zone Based Firewall Rule dialog box.

Step 5 Click OK to close the Add Zone Based Firewall Rule dialog box, adding the new zone-based firewall rule to the table on the Zone Based Firewall Rules page.


This completes configuration of the address-specific, Layer 7 inspection policy for traffic from the Internet to the DMZ. The illustration in "The Completed Rules Table" on page 29 presents the Zone Based Firewall Rules table listing all the rules configured for this example.

Configuring the Private-zone Stateful Inspection Firewall Policy

Configuring service inspection for traffic between the Servers and the Clients sub-zones is described in these sections: "Configuring Servers-to-Clients traffic" is described in the next section, while "Configuring Clients-to-Servers traffic" is described on page 28.

Both Private-zone interfaces are configured in an IEEE bridge group, representing the two sub-zones nested inside the Private zone, so the following firewall rules will apply transparent firewall inspection only to traffic crossing the bridge group.

Configuring Servers-to-Clients traffic

The Servers-to-Clients policy applies Layer 7 inspection using a user-defined service that allows X Windows connections over a specific port range, and allows return traffic. X Windows is not a natively supported protocol, so a user-configured Port Application Mapping (PAM) protocol must be defined.

Figure 12 Service inspection from Servers sub-zone to Clients sub-zone

This rule will apply firewall inspection to X Windows traffic "crossing the bridge" between the Servers and Clients sub-zones. To create the rule in Security Manager:


Step 1 If not displayed, access the Zone Based Firewall Rules page (Firewall > Zone Based Firewall Rules).

Step 2 Open the Add Zone Based Firewall Rule dialog box.

a. In the From Zone field, enter or Select the Servers zone.

b. In the To Zone field, enter or Select the Clients zone.

c. Choose Inspect from the Action menu.

d. Click Select next to the Protocol table to open the Protocol Selector dialog box.

e. Click the Create Protocol button below the Selected Protocols field to open the Configure Protocol dialog box.

f. Enter user-Xwindows as the Custom Protocol Name.

All custom protocol names must begin with user-.

g. Select TCP as the PAM Protocol.

h. Enter 6900-6910 in the Ports field.

With this protocol, X Windows servers will open connections to clients starting with port 6900. Each additional connection uses a successive port, so ten different sessions on one host will use the ports 6900 through 6909. Connection attempts on ports beyond 6909 will fail.

i. Click OK to close the Configure Protocol dialog box, adding the custom protocol to the Protocol table in the Add Zone Based Firewall Rule dialog box.

Step 3 Click OK to close the Add Zone Based Firewall Rule dialog box, adding the new zone-based firewall rule to the table on the Zone Based Firewall Rules page.


This completes configuration of the inspection policy allowing Servers-to-Clients X Windows connections. The illustration in "The Completed Rules Table" on page 29 presents the Zone Based Firewall Rules table listing all the rules configured for this example.

Configuring Clients-to-Servers traffic

The Client-to-Servers policy is less complex than the others in this example. Layer 4 inspection is applied to traffic traveling from the Clients sub-zone to the Servers sub-zone. This inspection policy allows TCP, UDP and ICMP connections from the Clients sub-zone to the Servers sub-zone, and allows return traffic.

Figure 13 Service inspection from Clients sub-zone to Servers sub-zone

Layer 4 inspection carries the advantage of simplicity for firewall configuration, in that only a few rules are required to allow most application traffic. However, Layer 4 inspection also has two major disadvantages:

Applications such as FTP and streaming-media services frequently negotiate an additional subordinate channel from the server to the client. This functionality is usually accommodated in a service "fix-up" that monitors the control channel and allows the subordinate channel. However, this capability is not available in Layer 4 inspection.

Layer 4 inspection allows nearly all application-layer traffic. If network use must be controlled so only a few applications are permitted through the firewall, an ACL must be configured on outbound traffic to limit the services allowed through the firewall.

To create a rule in Security Manager that provides inspection of traffic "crossing the bridge" between the Clients and Servers sub-zones:


Step 1 If not displayed, access the Zone Based Firewall Rules page (Firewall > Zone Based Firewall Rules).

Step 2 Open the Add Zone Based Firewall Rule dialog box.

a. In the From Zone field, enter or Select the Clients zone.

b. In the To Zone field, enter or Select the Servers zone.

c. Choose Inspect from the Action menu.

d. Click Select next to the Protocol table to open the Protocol Selector dialog box.

e. One at a time, select TCP, UDP and ICMP in the Available Protocols list and click the >> button each time, adding them to the Selected Protocols list.

f. Click OK to close the Protocol Selector dialog box, adding the selected protocols to the table in the Add Zone Based Firewall Rule dialog box.

Step 3 Click OK to close the Add Zone Based Firewall Rule dialog box, adding the new zone-based firewall rule to the table on the Zone Based Firewall Rules page.


This completes the configuration of the Layer 4 inspection policy for Clients-to-Servers traffic, allowing all TCP, UDP, and ICMP connections from the Client sub-zone to the Server sub-zone. This policy does not apply fix-up for subordinate channels, but provides an example of a simple policy to accommodate most application connections.

The illustration in "The Completed Rules Table" on page 29 presents the Zone Based Firewall Rules table listing all the rules configured for this example.

The Completed Rules Table

In this example, we created six zone-based firewall rules, defining inspection policies for traffic traveling between four zones and two sub-zones; return traffic is allowed in each case:

Private zone to Internet zone - Layer 4 inspection of HTTP, HTTPS, DNS, and ICMP traffic.

Private zone to DMZ - Layer 7 inspection of SSH, FTP, POP, IMAP, ESMTP, and HTTP traffic; no other protocols allowed.

Internet to DMZ - Two separate rules, providing different access policies for the two DMZ servers. Internet hosts are allowed DNS and HTTP connections to 172.16.2.2, and SMTP connections are allowed to 172.16.2.3.

Servers sub-zone to Clients sub-zone - Both Private-zone interfaces are configured in a bridge group. This rule applies Layer 7 inspection using a user-defined service that allows X Windows connections over a specific port range.

Clients sub-zone to Servers sub-zone - Layer 4 inspection allows TCP, UDP and ICMP connections between the two sub-zones.

The following illustration presents the resulting Zone Based Firewall Rules table in Security Manager.

Example 2: HTTP Application Inspection

Application-inspection policies are applied at Layer 7 of the OSI model, where user applications send and receive messages that allow the applications to provide useful functions. However, some applications may offer undesired or vulnerable functions, so the messages associated with these functions must be filtered to limit activities on the application services.

Application inspection varies according to service. For instance, HTTP inspection offers granular filtering on several types of application activity: you can limit transfer size, Web address lengths, and browser activity to enforce compliance with application-behavior standards, and to limit the types of content transferred over the service. Application inspection for SMTP can limit content length and enforce protocol compliance, while POP3 and IMAP inspection can help ensure that users are using secure authentication mechanisms to prevent compromise of user credentials.

HTTP application inspection (as well as other application-inspection policies) requires more complex configuration than basic Layer 4 configuration. You must configure Layer 7 traffic classification and policy maps to recognize specific traffic that you wish to control, and to apply the appropriate actions to desirable and undesirable traffic.

This section actually provides two examples of HTTP application inspection. The first applies application inspection to HTTP traffic to detect protocol violations and control unwanted use of the HTTP service port by applications (IM, P2P, and tunneling) that can redirect otherwise firewalled applications through TCP port 80. The second provides examples of several in-depth inspection capabilities, including detection of non-ASCII headers and content that exceeds 10 KB.

About HTTP Application Inspection

Cisco IOS software provides the following zone-based firewall HTTP inspection capabilities:

Ability to permit, deny, and monitor requests and responses based on header values. This is useful for blocking requests and responses that carry vulnerable header fields.

Ability to limit the size of different elements in the HTTP request and response headers, such as maximum URL length, maximum header length, maximum number of headers, maximum header-line length, etc. This is useful for preventing buffer overflows.

Ability to block requests and responses that carry multiple headers of the same type; for instance, a request with two content-length headers.

Ability to block requests and responses with non-ASCII headers. This is useful for preventing various attacks that use binary and other non-ASCII characters to deliver worms and other malicious content to Web servers.

Ability to group HTTP methods into user-specified categories, and the flexibility to block/allow/monitor each group. The HTTP RFC allows a restricted set of HTTP methods. Some of the standard methods are considered unsafe because they can be used to exploit vulnerabilities on a Web server, and many of the non-standard methods have a bad security record.

Ability to block specific URIs based on a user-configured regular expression. This feature allows blocking of custom URIs and queries.

Ability to spoof header types (especially server-header type) with customizable strings. This is useful in a case where an attacker analyzes Web server responses and learns as much information as possible, then launches an attack that exploits weaknesses in that particular Web server.

Ability to block or issue an alert on an HTTP connection if one or more HTTP parameter values match values entered as regular expressions. Some of the possible HTTP parameters include header, body, user name, password, user agent, request line, status line, and decoded CGI variables.

Configuring the HTTP Inspection Examples

This example involves a simple, two-zone network, configured on an 1811 router, as depicted in the following illustration. The Private zone is applied to the router's fixed switch ports, so all hosts on the switch ports are connected to VLAN1. The Public zone is applied on the interface FastEthernet0. Connectivity is provided from the Private zone to the Public zone. No connectivity is allowed from the Public zone to the Private zone.

Figure 14 Network configuration for the HTTP inspection examples

In both examples, the configured firewall policy will group traffic into two classes:

HTTP traffic

Other traffic: either SMTP, DNS, and FTP in the first case, or TCP, UDP, and ICMP in the second

The HTTP traffic is separated to allow specific inspection of Web traffic.

Both examples require these interfaces and zones to be defined:

A zone named "Private," to which VLAN1 is assigned.

A zone named "Public," to which FastEthernet0 is assigned.


Note Unlike the earlier "Basic Configuration Example" on page 16, these examples do not provide detailed instructions for defining zones, opening the Add Zone Based Firewall Rule dialog box, and the like. Rather we simply provide the parameters needed to define the necessary zone-based firewall rules, assuming you understand how to configure the rules. Refer to the earlier example if needed.


A Simple HTTP Inspection Example

In this example, we configure a class map that defines HTTP events that are not allowed; we define a policy map that applies this class map, with a reset-and-log action for matched traffic; and we create two zone-based firewall rules, one for inspection of HTTP traffic, and one for inspection of SMTP, DNS, and FTP traffic.

The following specific elements are configured in Security Manager:

A class map that matches any port-misuse request, or any request/response protocol violation.

1. Navigate to Class Maps > Inspect > HTTP (IOS) in the Policy Object Manager.

2. Click the New Object button to open the Add HTTP Class Map dialog box.

a. Provide a Name for this HTTP class map; this example uses HTTP_actions_not_permitted.

b. Be sure Match Any is the chosen Match Type.

c. Click the Add Row button to open the Add Match Criterion dialog box.

Choose Request Port-Misuse from the Criterion drop-down menu. Be sure Type is Matches and Port Misuse is any, and then click OK to close the Add Match Criterion dialog box.

d. Click the Add Row button to open the Add Match Criterion dialog box again.

Choose Request/Response Protocol Violation from the Criterion drop-down menu. Be sure Type is Matches, and then click OK to close the Add Match Criterion dialog box.

3. Click OK to close the Add HTTP Class Map dialog box.

An HTTP policy map used to apply a reset-and-log action to the HTTP_actions_not_permitted class map.

1. Navigate to Policy Maps > Inspect > HTTP (Zone based IOS) in the Policy Object Manager.

2. Click the New Object button to open the Add HTTP Map dialog box.

a. Provide a Name for this HTTP policy map; this example uses HTTP_not_permitted_policy.

b. Click the Add Row button to open the Add Match Condition and Action dialog box.

Click Select next to the Class Map field to open the Class Map Selector dialog box. Select the HTTP_actions_not_permitted class map, and then close the selector.

Choose Reset and Log from the Action drop-down menu, and then click OK to close the Add Match Condition and Action dialog box. This action will reset the connection and issue a syslog message; a syslog server must be configured to capture these messages.

3. Click OK to close the Add HTTP Map dialog box.

A zone-based firewall rule, with Private as the Source zone and Public as the Destination zone, that applies the policy map "HTTP_not_permitted_policy" to provide stateful inspection of HTTP traffic:

From Zone: Private
To Zone: Public
Action: Inspect
Protocol HTTP, with the policy map HTTP_not_permitted_policy applied for Deep Inspection:

1. In the Add Zone based Firewall Rule dialog box, click Select next to the Protocol table to open the Protocol Selector.

2. Locate and select HTTP in the Available Protocols list on the left side; click >> to add it to the Selected Protocols list on the right side.

3. Select HTTP in the Selected Protocols list, and then click the Edit button below that list to open the Configure Protocol dialog box.

4. Click Select next to the Deep Inspection field to open the Policy Map Selector.

5. Select HTTP_not_permitted_policy and click OK to close the selector.

6. Click OK to close the Configure Protocol dialog box.

7. Click OK to close the Protocol Selector dialog box.


Note Default values are used for any fields in the Add Zone Based Firewall Rule dialog box not explicitly mentioned.


A zone-based firewall rule, with Private as the Source zone and Public as the Destination zone, that provides inspection of SMTP, DNS, and FTP traffic:

From Zone: Private
To Zone: Public
Action: Inspect
Protocol table: SMTP, DNS, FTP

The following illustration presents the resulting Zone Based Firewall Rules table in Security Manager.

A More-complex HTTP Inspection Example

As presented in the previous simple HTTP example, you can use Layer 7 class maps to apply deep-packet inspection to specific traffic flows. This example provides further instances of using class and policy maps, and a custom regular expression, to apply deep-packet inspection to HTTP traffic:

We create a custom regular expression (regex) that defines a set of non-ASCII characters.

We configure a class map that defines several HTTP elements to be inspected, one of which incorporates the regular expression.

We define a policy map that applies this class map, with a reset-and-log action for matched traffic.

We create two zone-based firewall rules, one for stateful inspection of HTTP traffic, and one for inspection of TCP, UDP, and ICMP traffic.

The HTTP inspection is configured specifically for protocol violations (as in the earlier example), for non-ASCII headers, for unrecognized header content-types, and for content (message size) that exceeds 10 KB.

The following specific elements are configured in Security Manager:

A custom Regular Expression (regex) that defines a set of non-ASCII character codes.

1. Navigate to Maps > Regular Expressions in the Policy Object Manager.

2. Click the New Object button to open the Add Regular Expression dialog box.

a. Provide a Name for this Regular Expression; this example uses non_ASCII_characters.

b. In the Value field, provide [^\x00-\x80] as the desired expression pattern.

c. Click OK to close the dialog box and save the Regular Expression.

A class map that matches any request/response protocol violation, non-ASCII headers, unrecognized header content-type specifications, and messages with body size in excess of 10 KB.

In the Policy Object Manager, navigate to Maps > Class Maps > Inspect, and add an HTTP (IOS) Class Map with the following parameters:

A Name; this example uses HTTP_violations.

Match Any as the chosen Match Type.

These entries in the Criterion table; open the Add Match Criterion dialog box to define each:

Criterion: Request/Response Protocol Violation; Type: Matches

Criterion: Request/Response Header; Type: Matches; Regular Expression: non_ASCII_characters (as shown in the following illustration).

Criterion: Request/Response Header; Type: Matches; Header Option: content-type; Value: unknown (as shown in the following illustration)

Criterion: Request/Response Body Length; Value: Matches; Greater than Length: 10240

This is how the Add HTTP Class Map dialog box will look:

An HTTP policy map used to apply a reset-and-log action to the HTTP_violations class map.

In the Policy Object Manager, navigate to Maps > Policy Maps > Inspect > HTTP (Zone based IOS), and add an HTTP Policy Map with the following parameters:

A Name; this example uses HTTP_violations_policy.

Assign the HTTP_violations class map to this policy map, with Reset and Log as the Assigned action, by means of the Add Match Condition and Action dialog box.

A zone-based firewall rule, with Private as the Source zone and Public as the Destination zone, that uses the HTTP_violations_policy policy map to provide stateful inspection of HTTP traffic:

From Zone: Private
To Zone: Public
Action: Inspect
Protocol: HTTP, with the policy map HTTP_violations_policy applied for Deep Inspection.

1. Click Select next to the Protocol table to open the Protocol Selector.

2. Locate and select HTTP in the Available Protocols list on the left side; click >> to add it to the Selected Protocols list on the right side.

3. Select HTTP in the Selected Protocols list, and then click the Edit button below that list to open the Configure Protocol dialog box.

4. Click Select next to the Deep Inspection field to open the Policy Map Selector.

5. Select HTTP_violations_policy and click OK to close the selector.

6. Click OK to close the Configure Protocol dialog box.

7. Click OK to close the Protocol Selector dialog box.

A zone-based firewall rule, with Private as the Source zone and Public as the Destination zone, that provides inspection of TCP, UDP, and ICMP traffic:

From Zone: Private
To Zone: Public
Action: Inspect
Protocol table: TCP, UDP, ICMP

The following illustration presents the resulting Zone Based Firewall Rules table in Security Manager.

Example 3: Instant Messaging and Peer-to-peer Application Control

Cisco IOS Zone-based Firewall provides application inspection specifically for instant messaging (IM) and peer-to-peer (P2P) applications. Both IM and P2P inspection offer Layer 4 and Layer 7 policies for application traffic. This means zone-based firewall rules can provide basic stateful inspection to permit or deny the traffic, as well as granular Layer 7 control on specific activities by several of the protocols, so that certain application activities are allowed while others are denied.

Security Manager's zone-based firewall inspection encompasses the following IM and P2P protocols:

Instant Messaging

America Online (AOL)

"I seek you" (ICQ)

Instant Messenger

MSN Messenger

Windows Messenger

Yahoo! Messenger

Peer-to-peer

BitTorrent

eDonkey

FastTrack

Gnutella Version 2

Kazaa and Kazaa2

WinMX

Instant Messaging Application Inspection

Instant messaging inspection varies slightly between services, as IM inspection relies on controlling access to a specific group of hosts for each given service. Instant messaging services generally rely on a relatively permanent group of directory servers, which clients must be able to contact in order to access the IM service. Instant messaging applications tend to be very difficult to control from a protocol or service standpoint—the most effective way to control these applications is to limit access to the fixed IM servers.

Instant messaging inspection offers both Layer 4 Stateful Inspection and Layer 7 Application Control. Layer 4 inspection is configured similarly to other application services; that is, you create a zone-based firewall rule with one or more IM protocols (e.g., Aol, Winmsgr, Ymsgr, etc.) selected in the Protocol table, and Drop, Pass, or Inspect as the chosen Action.

Instant messaging applications can contact their servers on multiple ports to maintain their functionality. If you wish to allow a given IM service by applying the Inspect action, you might not need to define permitted access to the IM servers. However, configuring a class map that specifies a given IM service, such as Yahoo Messenger, and applying the Drop action in the zone-based firewall rule can cause the IM client to try and locate a different port where Internet connectivity is allowed.

Layer 7 (application) inspection augments Layer 4 inspection with the ability to recognize and apply service-specific actions, such as selectively blocking or allowing text-chat capabilities, while denying other service capabilities.

If you do not want to allow connectivity to a given service, or if you want to restrict the IM service to text-chat, you must define a specific server list so the zone-based firewall rules can identify traffic associated with the IM application. This server list is defined as a Protocol Info parameter map in the Policy Object Manager.


Note Instant messaging server names are fairly dynamic—you should periodically check that any defined IM server lists are complete and correct.


As an example, these are the steps you would follow in Security Manager to restrict Yahoo Messenger activity on the router to text-chat:

Define a Protocol Info parameter map that represents the Yahoo server list. The required server information for Yahoo Messenger is:

server name scs.msg.yahoo.com
server name scsd.msg.yahoo.com
server ip 66.77.88.99
server ip range 103.24.5.67 103.24.5.99
In Security Manager, you can define this Protocol Info parameter map as follows:

1. Navigate to Maps > Parameter Maps > Inspect > Protocol Info Parameters in the Policy Object Manager.

2. Click the New Object button to open the Add Protocol Info Parameter Map dialog box.

a. Provide a Name for this parameter map; this example uses YahooMessenger_server_list.

b. Click the Add Row button to open the Add DNS Server dialog box.

Be sure Name is the chosen DNS Server Type.
Enter scs.msg.yahoo.com in the Server Name field.
Click OK to close the Add DNS Server dialog box.

c. Repeat the previous step, entering scsd.msg.yahoo.com in the Server Name field.

d. Click the Add Row button again, opening the Add DNS Server dialog box.

Be sure IP Address is the chosen DNS Server Type.
Enter 66.77.88.99 in the IP Address field.
Click OK to close the Add DNS Server dialog box.

e. Click the Add Row button again, opening the Add DNS Server dialog box.

Be sure IP Range is the chosen DNS Server Type.
Enter 103.24.5.67 in the IP Address Start field.
Enter 103.24.5.99 in the IP Address End field.
Click OK to close the Add DNS Server dialog box.

3. Click OK to close the Add Protocol Info Parameter Map dialog box.

Two Yahoo Messenger class maps: one that matches any Yahoo traffic, and one that matches Yahoo text-chat only. These class maps are subsequently applied in an IM policy map. You can define these class maps "ahead of time" in the Policy Object Manager, or you can configure them as needed, when defining the IM policy map. In this example, we will define them in advance. Note that the two are defined separately so we can apply separate actions to each.

1. Navigate to Maps > Class Maps > Inspect > Yahoo Messenger in the Policy Object Manager.

2. Click the New Object button to open the Add Yahoo Messenger Class Map dialog box.

a. Provide a Name for this class map; this example uses YahooClassMap.

b. Click the Add Row button to open the Add Match Criterion dialog box.

Ensure that Service is the chosen Criterion, Matches is the chosen Type, and Any is the chosen Service, then click OK to close the Add Match Criterion dialog box.

c. Click OK to close the Add Yahoo Messenger Class Map dialog box.

3. Click the New Object button again to open the Add Yahoo Messenger Class Map dialog box.

a. Provide a Name for this class map; this example uses YahooTextOnly.

b. Click the Add Row button to open the Add Match Criterion dialog box.

Ensure that Service is the chosen Criterion, Matches is the chosen Type, and text-chat is the chosen Service, then click OK to close the Add Match Criterion dialog box.

c. Click OK to close the Add Yahoo Messenger Class Map dialog box.

An IM policy map, incorporating the two Yahoo class maps. Again, you can define this policy map "ahead of time," or as needed. In this example, we will define them in advance, in the Policy Object Manager.

1. Navigate to Maps > Policy Maps > Inspect > IM (Zone based IOS) in the Policy Object Manager.

2. Click the New Object button to open the Add IM Map dialog box.

a. Provide a Name for this policy map; this example uses IMmapYahoo.

b. Click the Add Row button to open the Add Match Condition and Action dialog box.

Select the Yahoo Messenger radio button; the Yahoo Messenger Class Map field is enabled. Click the Select button next to this field to open the Ymsgr Class Map Selector dialog box; select the YahooTextOnly class map, and click OK to close the selector.
Choose Allow and Log from the Action list, and then click OK to the Add Match Condition and Action dialog box.

c. Click the Add Row button to open the Add Match Condition and Action dialog box again.

Select the Yahoo Messenger radio button; the Yahoo Messenger Class Map field is enabled. Click the Select button next to this field to open the Ymsgr Class Map Selector dialog box; select the YahooClassMap class map, and click OK to close the selector.
Choose Reset and Log from the Action list, and then click OK to the Add Match Condition and Action dialog box.

d. Click OK to close the Add IM Map dialog box.

A zone-based firewall rule, with Private as the Source zone and Public as the Destination zone, that provides stateful inspection of Yahoo Messenger traffic, allowing text-chat and resetting the connection for any other traffic:

From Zone: Private
To Zone: Public
Action: Inspect
Protocol: Ymsgr, with the IM Map IMmapYahoo applied for Deep Inspection, and the Parameter Map YahooMessenger_server_list supplying additional Protocol Info.

1. Click Select next to the Protocol table to open the Protocol Selector.

2. Locate and select Ymsgr in the Available Protocols list on the left side; click >> to add it to the Selected Protocols list on the right side.

3. Select Ymsgr in the Selected Protocols list, and then click the Edit button below that list to open the Configure Protocol dialog box.

4. Click Select next to the Deep Inspection field to open the Policy Map Selector.

5. Select IMmapYahoo and click OK to close the selector.

6. Click Select next to the Protocol Info field to open the Parameter Map Selector.

7. Select YahooMessenger_server_list and click OK to close the selector.

8. Click OK to close the Configure Protocol dialog box.

9. Click OK to close the Protocol Selector dialog box.

10. Click OK to close the Add Zone Based Firewall Rule dialog box, adding the new rule to the Rules table.

Here is the rule listed in the Zone Based Firewall Rules table in Security Manager:

Configuring Peer-to-peer Inspection

As mentioned earlier, stateful (Layer 4) inspection is available for several peer-to-peer (P2P) applications, and Layer 7 deep inspection is also available for most of these applications. Layer 4 inspection is configured similarly to other application services, if inspection of the native application service ports will be adequate.

Security Manager supports zone-based firewall configuration for the following P2P protocols:

BitTorrent

eDonkey*

FastTrack*

Gnutella Version 2*

Kazaa and Kazaa2*

WinMX

* Signature-based classification and deep inspection are supported for these applications (includes Kazaa2 only).

Peer-to-peer applications can be difficult to detect, because of "port-hopping" behavior and other tricks used to avoid detection, and because of problems introduced by frequent changes and updates to the P2P applications which modify their behaviors. The disadvantage inherent in native service inspection is that it cannot maintain control over a P2P application if the application "hops" to a non-standard source and destination port, or if the application is updated to begin its action on an unrecognized port.

The standard P2P ports (as per the IOS 12.4(15)T Port Application Mapping list) are:

Application
Native Ports

BitTorrent

TCP 6881-6889

eDonkey

TCP 4662

FastTrack

TCP 1214

Gnutella

TCP 6346-6349

TCP 6355, 5634

UDP 6346-6348

Kazaa

Depends on Port Application Mapping (PAM)

WinMX

TCP 6699


To alleviate these difficulties, the traffic-recognition capabilities of the Network-based Application Recognition (NBAR) classification engine are combined with native firewall inspection to extend P2P application detection.

Leveraging NBAR provides heuristic-based application recognition for complex, difficult-to-detect behaviors, as well as an update mechanism that can keep the NBAR engine abreast of protocol updates and modifications.

Enabling the Signature option when configuring a P2P protocol for a zone-based firewall rule means NBAR heuristics will be applied to the traffic to detect "telltales" that indicate specific P2P application activity. These telltales includes port-hopping and other changes in application behavior to avoid traffic detection.


Note This level of traffic inspection comes at the price of increased CPU utilization and reduced network throughput capability. If the Signature option is not enabled, NBAR-based heuristic analysis will not be applied, and CPU utilization will not be affected to the same extent.


If you wish to inspect P2P traffic, additional configuration may be required. Some applications use multiple P2P networks, or implement specific behaviors that need to accommodated in your firewall configuration to allow the application to operate. For example:

BitTorrent clients usually communicate with "trackers" (peer directory servers) via HTTP running on some non-standard port. This is typically TCP 6969, but you may need to check the torrent-specific tracker port. If you wish to allow BitTorrent, the best method to accommodate the additional port is to configure HTTP as one of the match protocols (in addition to BitTorrent), and add TCP 6969 to the Port Application Mapping section of the HTTP protocol configuration.

eDonkey appears to initiate connections that are detected as both eDonkey and Gnutella.

Kazaa inspection is entirely dependent on NBAR-signature detection.

Peer-to-peer Layer 7 (application) inspection is similar to HTTP application inspection in that it provides the ability to recognize and apply service-specific actions; these include selectively blocking or allowing file-search, file-transfer, and text-chat capabilities. Service-specific capabilities vary by P2P service: eDonkey, FastTrack, Gnutella, and Kazaa2 all provide a criterion for matching file-transfer traffic; eDonkey also provides a criterion for matching text-chat traffic, and one for detecting searches for specific file names.

Here are the general steps for configuring a zone-based firewall rule in Security Manager that inspects a specific aspect of the selected P2P traffic:

Add the appropriate P2P class map(s), each of which is a list of one or more Match Criterion. As always, you can access the Policy Object Manager (Maps > Class Maps > Inspect > P2P_name) to accomplish this task before adding the zone-based firewall rule, or you can "drill down" in the successive dialog boxes while defining the rule.

Add the appropriate P2P policy map, which is a list of one or more Match Conditions (i.e., the related P2P class map) and Actions (e.g., Reset and Log). If you elect to do this in the Policy Object Manager, the path is Maps > Policy Maps > Inspect > P2P.

Add the zone-based firewall rule; choose Inspect as the Action. Open the Protocol Selector, select the desired P2P protocol(s) and add them to the Selected Protocols list.

To apply deep inspection, highlight a protocol in the list and click the Edit button to open the Configure Protocol dialog box. You can select Enable Signature to activate NBAR application recognition for this traffic. Click the Select button next to the Deep Inspection field to select the appropriate P2P policy map.
Note that the Configure Protocol dialog box is where you define custom Port Application Mappings.

Content Filtering

To protect your network and end users from malicious or inappropriate Web content, you can define zone-based firewall rules that implement Cisco IOS content filtering. Also known as URL filtering, this feature lets you block or restrict access to certain Websites, based on domain name, keyword, and content "filters." Filtering is applied as a policy action, similar to application inspection.

These filters can be specified locally on the router as lists of trusted domains (a "white" list), untrusted domains (a "black" list), and blocked keywords. Further, domain names can be forwarded to a third-party URL filtering server to verify allowed access. Cisco IOS supports the SmartFilter (previously N2H2), Websense, and Trend Micro filtering services.


Note To utilize one of these third-party services, you must purchase the necessary combination of hardware and software, or subscribe to hosted services from the appropriate company. With the Trend Micro option, you must register the router with Trend Micro and download a certificate. Note also that IOS supports only one active third-party URL filtering service at a time.


Content Filtering Modes

Cisco IOS content filtering provides three successive modes of operation: local filtering, third-party database filtering, and Allow mode. A content filtering rule first checks the router's local lists—the white list, the black list, and the blocked-keywords list—for a requested URL. If a match is not found, the request is forwarded to the URL filtering server specified in the rule. If no third-party service is defined, or the router cannot establish communications with the filtering server, the router enters Allow mode, as it is currently defined on the system.

The default setting for Allow mode is disabled, meaning that all URL requests which pass unmatched through local filtering are blocked. When Allow mode is enabled, all such HTTP requests are allowed.

About Third-party Filtering

Here is a basic outline of the URL filtering process when a third-party server is utilized:

1. A user sends an HTTP content request to an external Web server.

2. The router examines the request, and forwards it to the Web server.

3. Assuming no match with any local-list entry, the router also forwards the HTTP request to the third-party, content-filtering server to determine if the desired access is allowed. The forwarding of the request to both external servers occurs almost simultaneously.

4. The third-party server checks its database and sends a response to the router.

This response usually arrives before the Web server can respond to the content request. However, if the Web server does reply before the content filter server, the router can buffer the incoming HTTP response data.

5. Based on the response from the third-party server, the router permits or denies the request, allowing or dropping incoming/cached data.

In the case of the SmartFilter and Websense services, the router sends a URL look-up request to the appropriate database server, and the server responds with either a permit or deny message.

With the Trend Micro service, the router sends a URL category look-up request to Trend Micro; the response from Trend Micro is a category and reputation for that URL. Based on the policy set for that URL category and reputation, the HTTP request is allowed, denied, or logged. If a policy has not been configured for that URL category or reputation, the default behavior is to permit the HTTP response.


Note Content filtering can be quite processor-intensive. If you encounter router performance issues, check the filtering statistics to determine any sites that are being requested frequently. Add these sites to the white and black lists to reduce the number of queries to the third-party server.


White Lists, Black Lists, and Blocked Keyword Lists

To configure local filtering, you supply lists of trusted domain names (the white list), untrusted domain names (the black list), and URL keywords to be blocked (the blocked keyword list, provided as an URLF Glob parameter map).

When the domain name in a URL request matches an entry in the white list, the router allows the Web-access URL request and response without sending a look-up request to a third-party service. When the domain name in a URL request matches an entry in the black list, the Web-access request is blocked. You can specify complete and partial domain names in these lists.

Similarly, when a URL contains a keyword found in the blocked keyword list, the router blocks the URL request without sending a look-up request to a third-party service. A keyword is any text string that occurs between forward-slash (/) characters in a URL. You can specify complete "words" (text strings), and you can use wildcard characters to specify word patterns.

Caching Recent Requests

Cisco IOS provides a cache table that contains information about recent URL look-up requests. This means a subsequent request for a previously looked-up URL can be handled by the system without sending another look-up request to the third-party filtering server, reducing request response times and system overhead. With the SmartFilter and Websense services, the cache table specifies whether the requested URL is allowed or denied. In the case of the Trend Micro service, the cache table includes category information for the requested URL.

You can configure the size of the cache table and the length of time an entry remains in the cache table before it expires.

Packet Buffering

As mentioned earlier in "About Third-party Filtering" on page 48, the HTTP response from a Web server may arrive before the allow/deny response from the third-party content filtering service. In this situation, the router buffers the HTTP response while waiting for the look-up reply.

If the look-up reply indicates that the URL is allowed, the router releases the data to the user's browser; if the response indicates that the URL is blocked, the router discards the data in the buffer and closes the connection in both directions. This buffering helps to prevent numerous HTTP responses from overwhelming the router.

You can change the number of connection responses that can be held in the buffer, by changing the Maximum Responses parameter in the N2H2, Websense, or Trend Web Filter parameter map. The default is 200, and the range of values is zero to 20,000. Note that increasing this value increases router memory and processing requirements.

Basic Content Filtering in Security Manager

The following sections outline the basic procedures for setting up black- and white-lists, and configuring a third-party content-filtering service.

Configuring a rule that incorporates content filtering requires the same initial steps as any other zone-based firewall rule:

Open the Add Zone-based Firewall Rule dialog box and provide a From Zone and a To Zone (and updating the Sources and Destinations, as necessary).

Choose Content Filter from the Action menu.

The Protocol and Inspect Parameters fields appear, along with the WebFilter Parameter Map and WebFilter Policy Map options.

Select WebFilter Parameter Map or WebFilter Policy Map and supply the name of the appropriate map. See "About WebFilter Policy Maps" on page 51 for more information.

You also can configure the Protocol (HTTP), and apply an Inspect Parameters map to the rule, if desired. If you do not supply an Inspect Parameters map, default values are used for the rule.

To filter Web content, you must apply a WebFilter parameter or policy map, which you can create from the map-selector dialog box while defining the rule, or from the Policy Object Manager. The type of WebFilter map required depends on the technique you select to filter content, and on the Cisco IOS software version running on the router:

For devices running releases earlier than 12.4(20)T, you can only use a WebFilter Parameter map, also known as a URL Filter parameter map, which lets you define local URL filtering (white and black lists), and external filtering using either a SmartFilter (N2H2) or Websense server. (You cannot configure a Trend Micro server via a WebFilter parameter map.) To create a URL parameter map in the Policy Object Manager, select Maps > Parameter Maps > Web Filter > URL Filter.

For devices running release 12.4(20)T and higher, it is preferable to use a WebFilter Policy map. Although WebFilter policy maps are more complex, they provide additional flexibility, and they support use of the Trend Micro filtering service. To create a WebFilter parameter map in the Policy Object Manager, select Maps > Policy Maps > Web Filter > Web Filter.

The following chart outlines the basic flow of Content Filter rule configuration.

Figure 15 Content Filter configuration

About WebFilter Policy Maps

A WebFilter policy map applies other types of maps, specifically parameter and class maps. To define the WebFilter policy map, you will need to create one or more of these types of maps:

Parameter maps - You can apply parameter maps for the various types of Web filtering if you do not want to use the default settings. All four types of parameter map (Local, SmartFilter/N2H2, Websense, and Trend Micro) let you configure some general settings, including enabling Allow mode and specifying whether to display a message or Web page when a Web request is blocked. If you are using the SmartFilter (N2H2) or Websense service, you must apply a parameter map that identifies the contact server. (Trend Micro server information is provided elsewhere in Security Manager.) In the Policy Object Manager, Local, N2H2, Trend, and Websense parameter maps are available in the Maps > Parameter Maps > Web Filter folder.

Class maps for Match conditions - These class maps define the type of traffic you want to target and specify the action to be taken. You select a type of filtering (Local, SmartFilter/N2H2, Websense, or Trend Micro), specify the class map that identifies the targeted traffic, and choose an action (such as Allow, Reset, etc.) to be taken for that traffic. In the Policy Object Manager, you can find these class maps in the Maps > Class Maps > Web Filter folder.

The class map configurations depend on the type of filtering:
Local Filtering - The Local WebFilter class map is a list of one or more URLF Glob parameter maps that specify either domain names or URL keywords that you want to target. A URL keyword is any text string delineated by forward-slash (/) characters in a URL. These class maps help you define allowed (whitelisted) and denied (blacklisted) URLs for a WebFilter policy—you will create separate maps for each list. See the following section, "About URLF Glob Parameter Maps" on page 52, for additional information about URLF Globs.
SmartFilter (N2H2) or Websense Filtering - The class maps for N2H2 and Websense define any server response as the matching criterion.
Trend Micro Filtering - The Trend Micro database contains millions of URLs classified into specific categories (such as gaming, pornography, weapons, stock trading, etc.). The Trend class map provides more than 70 of these categories, organized into two lists: Productivity Categories and Security Ratings—you simply select those categories you want to target.

Note To use one of the external, third-party services, you must set up and configure the appropriate server-connection information before creating zone-based firewall rules that access that service.


About URLF Glob Parameter Maps

The term "glob" refers to an expression-match definition based on pattern matching. As implemented for zone-based firewall rules, a glob pattern can include only two special characters: * matches any number of characters, and ? matches a single character only. For example, use the patterns cisco.com and *.cisco.com in the same glob parameter map if you want to match http://cisco.com as well as http://www.cisco.com.

Note that numerous patterns can be listed in the same parameter map, and any one of them can trigger a match. To access this dialog box in the Policy Object Manager, navigate to Maps > Parameter Maps > Web Filter > URLF Glob Parameters.

And to complete this discussion, here is the Add Match Criterion dialog box, applying the "Cisco" glob parameter map. Notice that the chosen Criterion is Server Domain, and the chosen Type is Matches. This condition matches all domain addresses that end in cisco.com.

Each Match Criterion is applied and listed in the Add Web Filter Class Map dialog box.

Navigate to Maps > Class Maps > Web Filter in the Policy Object Manager to create Web Filter class maps.

About The Many Nested Dialog Boxes

At times, you may find yourself "drilling down" through several levels of "nested" dialog boxes to select or define the elements you need to create a zone-based firewall rule. This nesting is due in part to the complexity and flexibility of zone-based rules, and in part to how the rules are converted to device-configuration commands, as well as the need to create discrete rule-related objects that Security Manager can maintain for re-use.

For example, in the section, "About URLF Glob Parameter Maps" on page 52, we present three of the dialog boxes you will open when defining a Local Web Filter class map for content filtering (although they are presented in reverse order from the way you would access them). Here is the click-sequence in the Policy Object Manager to actually define the class map discussed in the section about URLF Globs:

Maps

Class Maps

Web Filter

Local

New Object button; opens the Add Local Web Filter Class Map dialog box

Add Row button; opens the Add Match Criterion dialog box

Select button; opens the URLF Glob Parameter Map selector dialog box; you can select a previously defined URLF Glob parameter map, or click:

Create button; opens the Add URLF Glob Parameter Map dialog box, where you enter the desired glob patterns

OK, closes the Add URLF Glob Parameter Map dialog box; the new URLF Glob Parameter map appears in the URLF Glob Parameter Map selector dialog box

Select the new glob map and click OK in the URLF Glob Parameter Map selector dialog box; the name of the glob map appears in the Add Match Criterion dialog box

OK in the Add Match Criterion dialog box; the criterion is listed in the Add Local Web Filter Class Map dialog box

OK in the Add Local Web Filter Class Map dialog box; the new Local Web Filter map is listed on the Local Web Filters page of the Policy Object Manager.

Similarly, here is the click-sequence necessary to apply this Local class map to a new content-filtering zone-based firewall rule in Security Manager. In the Add Zone based Firewall Rule dialog box, with Content Filter as the chosen Action, and WebFilter Policy Map selected, click:

Select (next to the WebFilter Policy Map field); opens the URLFilterPolicyMap selector dialog box.

Create button; opens the Add Web Filter Map dialog box.

On the Match Condition and Action tab, click Add Row; opens the Add Match Condition and Action dialog box.

With Local selected, click the Select button next to the Local Class Map field; opens the URLFilterLocalClassMap selector dialog box.

Select the previously created Local class map, click OK to close the selector dialog box.

The name of the selected class map appears in the Local Class Map field; click OK to close the Add Match Condition and Action dialog box.

Click OK to close the Add Web Filter Map dialog box.

Click OK to close the URLFilterPolicyMap selector dialog box.

The name of the selected policy-map object appears in the WebFilter Policy Map field in the Add Zone based Firewall Rule dialog box.

Initially, you may find it confusing to traverse several nested dialog boxes to apply a simple class map, for example. However, as you go about implementing rules for the specific requirements of each zone, the nesting and the pathways through rule configuration will begin to make sense.

Controlling Access to the Router

Most network security engineers are uncomfortable exposing a router's management interfaces to the Internet, and under certain circumstances, require control over LAN access to the router as well. Cisco IOS Software offers several options to limit access to the various interfaces; these include the Network Foundation Protection (NFP) features, various access-control mechanisms for management interfaces, and the zone-based firewall Self zone (introduced in "Zone Pairs and the Self Zone" on page 4).

You should review these options to determine which combination of router control features will work best in your specific situation. Generally, the NFP feature family is best suited for control of traffic destined for the router itself. Refer to Control Plane Security Overview in Cisco IOS Software for information about the NFP features.

If you do decide to apply zone-based firewall rules to control traffic to and from the IP addresses on the router itself, you must understand that the firewall's default policy and capabilities differ from those available for transit traffic. Transit traffic is defined as network traffic whose source and destination IP addresses do not match any IP addresses assigned to any of the router interfaces, and this traffic will not trigger network control messages (such as ICMP Time to Live expired, or network/host unreachable).

As mentioned previously, the zone-based firewall model applies a default deny-all policy to all traffic moving between zones, while traffic from any zone flowing directly to the addresses of the router's interfaces (the Self zone) is implicitly allowed. This ensures that connectivity to the router's management interfaces is maintained when a zone firewall configuration is applied to the router.

Thus, to control IP traffic moving to and from the router's interfaces from the various zones, policies must be explicitly applied to block or allow traffic between the router's Self zone and other zones, and vice versa. It is important to note that although a default allow policy exists between all zones and the Self zone, as soon as a policy is configured from any zone to the Self zone, a corresponding return policy must also be configured, or the return traffic will be blocked.

Self-zone Policy Limitations

Self-zone policy has limited functionality compared to the policies available for transit traffic:

As with classical stateful inspection, router-generated traffic is limited to TCP, UDP, ICMP, and H.323.

Application (Layer 7) inspection is not available for Self-zone policies.

Session and rate limiting cannot be configured on Self-zone policies; that is, an Inspect Parameter map cannot be applied.

Self-zone Policy Configuration

Under most circumstances, these are desirable access policies for router-management traffic:

Deny all Telnet connectivity, as Telnet's clear-text protocol easily exposes user credentials and other sensitive information.

Allow SSH connections from any user in any zone: SSH encrypts user credentials and session data, which provides protection from packet-capturing tools that monitor user activity and compromise user credentials, or sensitive information such as router configuration. Note that SSH Version 2 provides stronger protection, and addresses specific vulnerabilities inherent to SSH Version 1.

Allow HTTP connectivity to the router from the private zones, only if the private zones are trustworthy—HTTP does not employ encryption to protect management traffic, and might reveal sensitive information such as user credentials or configuration.

Allow HTTPS connectivity from any zone. Similar to SSH, HTTPS encrypts session data and user credentials.

Restrict SNMP access to a specific host or subnet, as SNMP can be used to modify router configuration and reveal configuration information. Configure SNMP with access control on the various communities.

Block ICMP requests from the Internet to private-zone addresses (assuming the private-zone addresses are routable), as several types of ICMP attacks can be used to overwhelm router resources, or reconnoiter network topology and architecture. However, one or more public addresses may be exposed to ICMP traffic for network troubleshooting, if necessary.

As mentioned, each rule for traffic inbound to, or outbound from, the Self zone must be matched by a corresponding rule in the opposite direction, unless traffic will not be originated in the opposite direction.

Configuration Commands From The Examples

Zone-based firewall rules are powerful, but also complex. Using zone rules, you can replace access rules, inspection rules, and Web filter rules with a single type of firewall rule. Because zone-based firewall rules can perform so many possible actions, the configuration generated from them uses many different types of commands, including structures for access control lists (ACLs), class maps, and policy maps. There is no one-to-one correspondence between a zone-based firewall rule and a line in the configuration (unlike access rules, for example).

When you deploy your zone-based firewall rules, Security Manager generates the appropriate command-line interface (CLI) configuration and submits it to the selected device. Before deploying, you can preview these CLI commands by saving your rules and the choosing Preview Configuration from the Tools menu to open the Configuration Viewer. Note that the Security Manager documentation and on-line Help include an in-depth discussion of "Troubleshooting and Previewing Device-configuration Commands."

The following sections present the CLI configuration generated by each of the examples presented previously. In each example, notice that Security Manager automatically appends the class-default class to the end of each policy-map's class list to capture any packets not processed by a zone rule. This is how all traffic between zones is dropped unless explicitly allowed. (You can change this default drop behavior, as explained in the Security Manager documentation and on-line Help topic, "Changing the Default Drop Behavior.")


Note In the generated device-configuration commands, the From and To zones in specified in Security Manager's Add and Edit Zone based Firewall dialog boxes are referred to as "source" and "destination" zones. These are not to be confused with the Sources and Destinations fields in the dialog boxes.


CLI for Example 1

In "Example 1: A Basic Configuration" on page 16, we created six zone-based firewall rules, defining inspection policies for traffic traveling between four zones and two sub-zones:

Private zone to Internet zone - Layer 4 inspection of HTTP, HTTPS, DNS, and ICMP traffic.

Private zone to DMZ - Layer 7 inspection of SSH, FTP, POP, IMAP, ESMTP, and HTTP traffic; no other protocols allowed.

Internet to DMZ - Two separate rules, providing different access policies for the two DMZ servers. Internet hosts are allowed DNS and HTTP connections to 172.16.2.2, and SMTP connections are allowed to 172.16.2.3.

Servers sub-zone to Clients sub-zone - Both Private-zone interfaces are configured in a bridge group. This rule applies Layer 7 inspection using a user-defined service that allows X Windows connections over a specific port range.

Clients sub-zone to Servers sub-zone - Layer 4 inspection allows TCP, UDP and ICMP connections between the two sub-zones.

The following device-configuration commands are generated for these rules, and the related interface and zone definitions.

bridge irb
bridge 1 protocol ieee
bridge 1 route ip
interface VLAN1
bridge-group 1
exit
!
interface VLAN2
bridge-group 1
exit
!
interface FastEthernet0
no shutdown
ip address 172.16.1.88 255.255.255.0
exit
!
interface BVI1
no shutdown
ip address 192.168.1.254 255.255.255.0
exit
!
interface VLAN2
no shutdown
exit
!
interface VLAN1
no shutdown
exit
!
interface FastEthernet1
no shutdown
ip address 172.16.2.1 255.255.255.0
exit
!
ip port-map user-Xwindows port tcp from 6900 to 6910
zone security Private
exit
interface BVI1
zone-member security Private
exit
!
zone security Internet
exit
interface FastEthernet0
zone-member security Internet
exit
!
zone security DMZ
exit
interface FastEthernet1
zone-member security DMZ
exit
!
zone security Servers
exit
interface VLAN2
zone-member security Servers
exit
!
zone security Clients
exit
class-map type inspect match-any CSM_ZBF_CLASS_MAP_1
match protocol http
match protocol https
match protocol dns
match protocol icmp
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_1
class type inspect CSM_ZBF_CLASS_MAP_1
inspect
exit
class class-default
drop
exit
!
zone-pair security CSM_Private-Internet_1 source Private destination Internet
service-policy type inspect CSM_ZBF_POLICY_MAP_1
exit
!
class-map type inspect match-any CSM_ZBF_CLASS_MAP_2
match protocol ssh
match protocol ftp
match protocol pop3
match protocol imap
match protocol smtp extended
match protocol http
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_2
class type inspect CSM_ZBF_CLASS_MAP_2
inspect
exit
class class-default
drop
exit
!
zone-pair security CSM_Private-DMZ_1 source Private destination DMZ
service-policy type inspect CSM_ZBF_POLICY_MAP_2
exit
!
ip access-list extended CSM_ZBF_CMAP_ACL_1
permit ip any host 172.16.2.2
exit
!
class-map type inspect match-any CSM_ZBF_CMAP_PLMAP_1
match protocol dns
match protocol http
exit
!
class-map type inspect CSM_ZBF_CLASS_MAP_3
match access-group name CSM_ZBF_CMAP_ACL_1
match class-map CSM_ZBF_CMAP_PLMAP_1
exit
!
ip access-list extended CSM_ZBF_CMAP_ACL_2
permit ip any host 172.16.2.3
exit
!
class-map type inspect CSM_ZBF_CLASS_MAP_4
match access-group name CSM_ZBF_CMAP_ACL_2
match protocol smtp
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_3
class type inspect CSM_ZBF_CLASS_MAP_3
inspect
exit
class type inspect CSM_ZBF_CLASS_MAP_4
inspect
exit
class class-default
drop
exit
!
zone-pair security CSM_Internet-DMZ_1 source Internet destination DMZ
service-policy type inspect CSM_ZBF_POLICY_MAP_3
exit
!
class-map type inspect CSM_ZBF_CLASS_MAP_5
match protocol user-Xwindows
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_4
class type inspect CSM_ZBF_CLASS_MAP_5
inspect
exit
class class-default
drop
exit
!
zone-pair security CSM_Servers-Clients_1 source Servers destination Clients
service-policy type inspect CSM_ZBF_POLICY_MAP_4
exit
!
class-map type inspect match-any CSM_ZBF_CLASS_MAP_6
match protocol tcp
match protocol udp
match protocol icmp
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_5
class type inspect CSM_ZBF_CLASS_MAP_6
inspect
exit
class class-default
drop
exit
!
zone-pair security CSM_Clients-Servers_1 source Clients destination Servers
service-policy type inspect CSM_ZBF_POLICY_MAP_5
exit
!

CLI for Example 2

In "Example 2: HTTP Application Inspection" on page 30, we presented two related examples. In both, the configured firewall policy groups traffic into two classes: HTTP traffic and other traffic, either SMTP, DNS, and FTP in the first case, or TCP, UDP, and ICMP in the second. This HTTP traffic separation allows specific inspection of Web traffic.

Both examples require these interfaces and zones to be defined: a zone named "Private," to which VLAN1 is assigned, and a zone named "Public," to which FastEthernet0 is assigned.

Simple HTTP Inspection Example

This example, on page 32, includes a class map that defines HTTP events that are not allowed; a policy map that applies this class map, with a reset-and-log action for matched traffic; and two zone-based firewall rules, one for inspection of HTTP traffic, and one for inspection of SMTP, DNS, and FTP traffic.

interface VLAN1
no shutdown
exit
!
interface FastEthernet0
no shutdown
exit
!
zone security Private
exit
interface VLAN1
zone-member security Private
exit
!
zone security Public
exit
interface FastEthernet0
zone-member security Public
exit
!
class-map type inspect CSM_ZBF_CLASS_MAP_1
match protocol http
exit
!
class-map type inspect match-any CSM_ZBF_CLASS_MAP_2
match protocol smtp
match protocol dns
match protocol ftp
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_1
class type inspect CSM_ZBF_CLASS_MAP_1
inspect
exit
class type inspect CSM_ZBF_CLASS_MAP_2
inspect
exit
class class-default
drop
exit
!
zone-pair security CSM_Private-Public_1 source Private destination Public
service-policy type inspect CSM_ZBF_POLICY_MAP_1
exit
!

The More-complex HTTP Inspection Example

This example, on page 35, includes a custom regular expression (regex) that defines a set of non-ASCII characters; a class map that defines several HTTP elements to be inspected, one of which incorporates the regular expression; a policy map that applies this class map, with a reset-and-log action for matched traffic; and two zone-based firewall rules, one for stateful inspection of HTTP traffic, and one for inspection of TCP, UDP, and ICMP traffic. The HTTP inspection is configured specifically for protocol violations (as in the earlier example), for non-ASCII headers, for unrecognized header content-types, and for content (message size) that exceeds 10 KB.

parameter-map type regex non_ASCII_characters
pattern [^\x00-\x80]
exit
!
class-map type inspect http match-any HTTP_violations
match req-resp protocol-violation
match req-resp header regex non_ASCII_characters
match req-resp header content-type unknown
match req-resp body length gt 10240
exit
!
policy-map type inspect http HTTP_violations_policy
class type inspect http HTTP_violations
reset
log
exit
exit
!
zone security Private
exit
zone security Public
exit
class-map type inspect CSM_ZBF_CLASS_MAP_1
match protocol http
exit
!
class-map type inspect match-any CSM_ZBF_CLASS_MAP_2
match protocol tcp
match protocol udp
match protocol icmp
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_1
class type inspect CSM_ZBF_CLASS_MAP_1
inspect
service-policy http HTTP_violations_policy
exit
class type inspect CSM_ZBF_CLASS_MAP_2
inspect
exit
class class-default
drop
exit
!
zone-pair security CSM_Private-Public_1 source Private destination Public
service-policy type inspect CSM_ZBF_POLICY_MAP_1
exit
!

CLI for Example 3

In "Example 3: Instant Messaging and Peer-to-peer Application Control" on page 40, we created a zone-based firewall rule restricting Yahoo Messenger activity on the router to text-chat, resetting the connection for any other traffic. The rule requires a Protocol Info parameter map representing the Yahoo server list; two Yahoo Messenger class maps, one that matches any Yahoo traffic, and one that matches Yahoo text-chat only; and an IM policy map, incorporating the two Yahoo class maps.

interface FastEthernet0
no shutdown
exit
!
interface VLAN1
no shutdown
exit
!
parameter-map type protocol-info YahooMessenger_server_list
server name scs.msg.yahoo.com
server name scsd.msg.yahoo.com
server ip 66.77.88.99
server ip range 103.24.5.67 103.24.5.99
exit
!
class-map type inspect ymsgr YahooTextOnly
match service text-chat
exit
!
class-map type inspect ymsgr YahooClassMap
match service any
exit
!
policy-map type inspect im IMmapYahoo
class type inspect ymsgr YahooClassMap
reset
log
exit
class type inspect ymsgr YahooTextOnly
allow
log
exit
exit
!
zone security Private
exit
interface VLAN1
zone-member security Private
exit
!
zone security Public
exit
interface FastEthernet0
zone-member security Public
exit
!
class-map type inspect CSM_ZBF_CLASS_MAP_1
match protocol ymsgr YahooMessenger_server_list
exit
!
policy-map type inspect CSM_ZBF_POLICY_MAP_1
class type inspect CSM_ZBF_CLASS_MAP_1
inspect
service-policy im IMmapYahoo
exit
class class-default
drop
exit
!
zone-pair security CSM_Private-Public_1 source Private destination Public
service-policy type inspect CSM_ZBF_POLICY_MAP_1
exit
!