Zone-Based Policy Firewall

Top-level class maps allow you to identify the traffic stream at a high level. This is accomplished by using the match access-group and match protocol commands. Top-level class maps are also referred to as Layer 3 and Layer 4 class maps.

Top-level policy maps allow you to define high-level actions by using the inspect, drop, pass, and urlfilter keywords. You can attach maps to a target (zone pair).

Note	Only inspect type policies can be configured on a zone pair.

Application-specific class maps allow you to identify 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). Application-specific class maps are identified by an additional subtype that generally is the protocol name (HTTP or SMTP) in addition to the type inspect.

Application-specific policy maps are used to specify a policy for an application protocol. For example, if you want to drop HTTP traffic with Unique Resource Identifier (URI) lengths exceeding 256 bytes, you must configure an HTTP policy map to do that. Application-specific policy maps cannot be attached directly to a target (zone pair). They must be configured as "child" policies in a top-level Layer 3 or Layer 4 policy map.

A zone is a group of interfaces that have similar functions or features. Zones provide a way for you to specify where a Cisco IOS firewall is applied.

For example, on a router, Gigabit Ethernet interface 0/0/0 and Gigabit Ethernet interface 0/0/1 may be connected to the local LAN. These two interfaces are similar because they represent the internal network, so they can be grouped into a zone for firewall configurations.

By default, the traffic between interfaces in the same zone is not subjected to any policy. The traffic passes freely. Firewall zones are used for security features.

Note	Zones may not span interfaces in different VPN routing and forwarding (VRF) instances.

When a zone-based policy firewall is enabled for TCP keepalive traffic and the host behind the firewall is undergoing an ungraceful disconnect, TCP keepalive works only when the configured TCP timeout is complete. On receiving an out-of-window reset (RST) packet, the firewall sends an empty acknowledge (ACK) packet to the initiator of the RST packet. This ACK has the current sequence (SEQ) and the ACK number from the firewall session. On receiving this ACK, the client sends an RST packet with the SEQ number that is equal to the ACK number in the ACK packet. The firewall processes this RST packet, clears the firewall session, and passes the RST packet.

A security zone is a group of interfaces to which a policy can be applied.

Grouping interfaces into zones involves two procedures:

• Creating a zone so that interfaces can be attached to it.
• Configuring an interface to be a member of a given zone.

By default, traffic flows among interfaces that are members of the same zone.

When an interface is a member of a security zone, all traffic (except traffic going to the router or initiated by the router) between that interface and an interface within a different zone is dropped by default. To permit traffic to and from a zone-member interface and another interface, you must make that zone part of a zone pair and apply a policy to that zone pair. If the policy permits traffic (through inspect or pass actions), traffic can flow through the interface.

Basic rules to consider when setting up zones are as follows:

• Traffic from a zone interface to a nonzone interface or from a nonzone interface to a zone interface is always dropped; unless default zones are enabled (default zone is a nonzone interface).
• Traffic between two zone interfaces is inspected if there is a zone-pair relationship for each zone and if there is a configured policy for that zone pair.
• By default, all traffic between two interfaces in the same zone is always allowed.
• A zone pair can be configured with a zone as both the source and the destination zones. An inspect policy can be configured on this zone pair to inspect or drop the traffic between two interfaces in the same zone.

A policy is applied to the initiating packet of a traffic flow. After the initial packet has been classified and permitted, traffic flows between peers with no further reclassification of the packet (this means that bidirectional traffic flow is allowed after the initial classification). If you have a zone pair between Zone Z1 and Zone Z2, and no zone pair between Zone Z2 and Zone Z1, all traffic that is initiated from Zone Z2 is blocked. Traffic from Zone Z1 to Zone Z2 is permitted or denied based on the zone pair policy.

For traffic to flow among all the interfaces in a router, all interfaces must be members of security zones or the default zone.

It is not necessary for all router interfaces to be members of security zones.

The figure below illustrates the following:

• 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 1

Security Zone Restrictions

The following situations exist:

• The zone pair and policy are configured in the same zone. If no policy is configured for Z1 and Z2, traffic will flow freely between E0 and E1, but not between E0 or E1 to E2. A zone pair and policy may be created to inspect this traffic.
• If no policies are configured, traffic will not flow between any other interfaces (for example, E0 and E2, E1 and E2, E3 and E1, and E3 and E2).
• Traffic can flow between E0 or E1 and E2 only when an explicit policy permitting traffic is configured between zone Z1 and zone Z2.
• Traffic can never flow between E3 and E0/E1/E2 unless default zones are enabled and a zone-pair is created between the default zone and the other zones.

• Virtual Interfaces as Members of Security Zones
  

A zone pair allows you to specify a unidirectional firewall policy between two security zones.

To define a zone pair, use the zone-pair security command. The direction of the traffic is specified by a source and destination zone. The source and destination zones of a zone pair must be security zones.

You can select the default or self zone as either the source or the destination zone. The self zone is a system-defined zone. It does not have any interfaces as members. A zone pair that includes the self zone, along with the associated policy, applies to traffic directed to the router or traffic generated by the router. It does not apply to traffic through the router.

The most common usage of firewalls is to apply them to traffic through a router, so you need at least two zones (that is, you cannot use the self zone).

To permit traffic between zone-member interfaces, you must configure a policy permitting (or inspecting) traffic between that zone and another zone. To attach a firewall policy map to the target zone pair, use the service-policy type inspect command.

The figure below shows the application of a firewall policy to traffic flowing from zone Z1 to zone Z2, which means that the ingress interface for the traffic is a member of zone Z1 and the egress interface is a member of zone Z2.

Figure 2

Zone Pairs

If there are two zones and you require policies for traffic going in both directions (from Z1 to Z2 and Z2 to Z1), you must configure two zone pairs (one for each direction).

If a policy is not configured between a pair of zones, traffic is dropped. However, it is not necessary to configure a zone pair and a service policy solely for the return traffic. By default, return traffic is not allowed. If a service policy inspects the traffic in the forward direction and there is no zone pair and service policy for the return traffic, the return traffic is inspected. If a service policy passes the traffic in the forward direction and there is no zone pair and service policy for the return traffic, the return traffic is dropped. In both these cases, you need to configure a zone pair and a service policy to allow the return traffic. In the above figure, it is not mandatory that you configure a zone pair source and destination solely for allowing return traffic from Z2 to Z1. The service policy on the Z1 to Z2 zone pair takes care of it.

Zone-based policy firewalls examine the source and destination zones from the ingress and egress interfaces for a firewall policy. It is not necessary that all traffic flowing to or from an interface be inspected; you can designate that individual flows in a zone pair be inspected through your policy map that you apply across the zone pair. The policy map will contain class maps that specify the individual flows.

You can also configure inspect parameters like TCP thresholds and timeouts on a per-flow basis.

Access Control Lists (ACLs) applied to interfaces that are members of zones are processed before the policy is applied on the zone pair. You must make sure that interface ACLs do not interfere with the policy firewall traffic when there are policies between zones.

Pinholes (are ports opened through a firewall that allows applications controlled access to a protected network) are not punched for return traffic in interface ACLs.

The Cisco IOS firewall is VPN routing and forwarding (VRF)-aware. It handles IP address overlap across different VRFs, separate thresholds, and timeouts for VRFs. All interfaces in a zone must belong to the same VRF.

However, you should not group interfaces from different VRFs in the same zone because VRFs belong to different entities that typically have their own policies.

You can configure a zone pair between two zones that contain different VRFs, as shown in the figure below.

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

Figure 3

Zones and VRF

In the figure above, 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 multiple zones vrf_B_1 and vrf_B_2. Zone Z1 does not have VRF interfaces. You can specify 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 you have to make sure that traffic can flow between them.

There is no need to specify the global thresholds and timers on a per-VRF basis. Instead, parameters are supplied to the inspect action through a parameter map.

The Cisco IOS firewall supports transparent firewalls where the interfaces are placed in bridging mode and IP firewalling is performed on the bridged traffic.

To configure a transparent firewall, use the bridge command to enable the bridging of a specified protocol in a specified bridge and the zone-member security command to attach an interface to a zone. The bridge command on the interface indicates that the interface is in bridging mode.

A bridged interface can be a member of a zone. In a typical case, the Layer 2 domain is partitioned into zones and a policy is applied the same way as for Layer 3 interfaces.

• Transparent Firewall Restriction for P2P Inspection
  

A class is a way of identifying a set of packets based on its contents. Normally you define a class so that you can apply an action on the identified traffic that reflects a policy. A class is designated through class maps.

An action is a specific functionality that is typically associated with a traffic class. For example, inspect, drop, and pass are actions.

To create firewall policies, you should complete the following tasks:

• Define a match criterion (class map).
• Associate actions to the match criterion (policy map).
• Attach the policy map to a zone pair (service policy).

The class-map command creates a class map to be used for matching packets to a specified class. Packets arriving at the targets (such as the input interface, output interface, or zone pair), that are determined by how the service-policy command is configured, are checked against match criteria configured for a class map to determine if the packet belongs to that class.

The policy-map command creates or modifies a policy map that can be attached to one or more targets to specify a service policy. Use the policy-map command to specify the name of the policy map to be created, added to, or modified before you can configure policies for classes whose match criteria are defined in a class map.

Quality of service (QoS) class maps have numerous match criteria; firewalls have fewer match criteria. Firewall class maps have the type inspect and this information controls what shows up under firewall class maps.

A policy is an association of traffic classes and actions. It specifies what actions should be performed on defined traffic classes. An action is a specific function, and it is typically associated with a traffic class. For example, inspect and drop are actions.

• Layer 3 and Layer 4 Class Maps and Policy Maps
  
• Layer 7 Class Maps and Policy Maps
  
• Class-Default Class Map
  
• Hierarchical Policy Maps
  

A parameter map allows you to specify parameters that control the behavior of actions and match criteria specified under a policy map and a class map, respectively.

There are three types of parameter maps:

• Inspect parameter map

An inspect parameter map is optional. If you do not configure a parameter map, the software uses default parameters. Parameters associated with the inspect action apply to all nested actions (if any). If parameters are specified in both the top and lower levels, the parameters in the lower levels override those in the top levels.

• URL Filter parameter map

A parameter map is required for URL filtering (through the URL filter action in a Layer 3 or Layer 4 policy map and the URL filter parameter map).

• Protocol-specific parameter map

A parameter map that is required for an Instant Messenger application (Layer 7) policy map.

Network Address Translation (NAT) enables private IP internetworks that use nonregistered IP addresses to connect to the Internet. NAT operates on a router, usually connecting two networks, and translates the private (not globally unique) addresses in the internal network into legal addresses before packets are forwarded onto another network. NAT can be configured to advertise only one address for the entire network to the outside world. A router configured with NAT will have at least one interface to the inside network and one to the outside network.

In a typical environment, NAT is configured at the exit router between a stub domain and the backbone. When a packet leaves the domain, NAT translates the locally significant source address into a globally unique address. When a packet enters the domain, NAT translates the globally unique destination address into a local address. If more than one exit point exists, each NAT must have the same translation table. If the software cannot allocate an address because it has run out of addresses, it drops the packet and sends an ICMP host unreachable packet.

With reference to NAT, the term "inside" refers to those networks that are owned by an organization and that must be translated. Inside this domain, hosts will have addresses in one address space. When NAT is configured and when the hosts are outside, hosts will appear to have addresses in another address space. The inside address space is referred to as the local address space and the outside address space is referred to as the global address space.

Consider a scenario where NAT translates both the source and the destination IP addresses. A packet is sent to a router from inside NAT with the source address 192.168.1.1 and the destination address 10.1.1.1. NAT translates these addresses and sends the packet to the external network with the source address 209.165.200.225 and the destination address 209.165.200.224.

Similarly, when the response comes back from outside NAT, the source address will be 209.165.200.225 and the destination address will be 209.165.200.224. Therefore, inside NAT, the packets will have a source address of 10.1.1.1 and a destination address of 192.168.1.1.

In this scenario, if you want to create an Application Control Engine (ACE) to be used in a firewall policy, the pre-NAT IP addresses (also known as inside local and outside global addresses) 192.168.1.1 and 209.165.200.224 must be used.

The WAAS firewall software, which was introduced in Cisco IOS Release 12.4(15)T, provides an integrated firewall that optimizes security-compliant WANs and application acceleration solutions with the following benefits:

• Optimizes a WAN through full stateful inspection capabilities.
• Simplifies Payment Card Industry (PCI) compliance.
• Protects transparent WAN accelerated traffic.
• Integrates WAAS networks transparently.
• Supports the Network Management Equipment (NME) WAE modules or standalone WAAS device deployment.

WAAS has an automatic discovery mechanism that uses TCP options during the initial three-way handshake used to identify WAE devices transparently. After automatic discovery, optimized traffic flows (paths) experience a change in the TCP sequence number to allow endpoints to distinguish between optimized and nonoptimized traffic flows.

Note	Paths are synonymous with connections.

WAAS allows the Cisco IOS firewall to automatically discover optimized traffic by enabling the sequence number to change without compromising the stateful Layer 4 inspection of TCP traffic flows that contain internal firewall TCP state variables. These variables are adjusted for the presence of WAE devices.

If the Cisco IOS firewall notices that a traffic flow has successfully completed WAAS automatic discovery, it permits the initial sequence number shift for the traffic flow and maintains the Layer 4 state on the optimized traffic flow.

Note	Stateful Layer 7 inspection on the client side can also be performed on nonoptimized traffic.

• WAAS Traffic Flow Optimization Deployment Scenarios
  

Out-of-Order (OoO) packet processing support for Common Classification Engine (CCE) firewall application and CCE adoptions of the Intrusion Prevention System (IPS) allows for packets that arrive out of order to be copied and reassembled in the correct order. The OoO packet processing reduces the need to retransmit dropped packets and reduces the bandwidth needed for transmission on a network. To configure OoO support, use the parameter-map type ooo global command.

Note	IPS sessions use OoO parameters that are configured using the parameter-map type ooo global command.

Note	OoO processing is not supported in SMTP because SMTP supports masking actions that require packet modification.

OoO packet processing support is enabled by default when a Layer 7 policy is configured for DPI for the following protocols:

• AOL IM protocol
• eDonkey P2P protocol
• FastTrack traffic P2P protocol
• Gnutella Version 2 traffic P2P protocol
• H.323 VoIP Protocol Version 4
• HTTP--The protocol used by web browsers and web servers to transfer files, such as text and graphic files
• IMAP--Method of accessing e-mail or bulletin board messages kept on a mail server that can be shared
• ICQ IM Protocol
• Kazaa Version 2 P2P protocol
• Match Protocol SIP--Match Protocol SIP
• MSN Messenger IM protocol
• POP3--Protocol that client e-mail applications use to retrieve mail from a mail server
• SUNRPC--Sun RPC
• Windows Messenger IM Protocol
• Yahoo IM protocol

For information on configuring a Layer 7 class map and policy map (policies), see the "Configuring Layer 7 Protocol-Specific Firewall Policies" section.

Note	OoO packets are dropped when IPS and zone-based policy firewall with L4 inspection are enabled.

Intrazone support allows a zone configuration to include users both inside and outside a network. Intrazone support allows traffic inspection between users belonging to the same zone but different networks. Before Cisco IOS Release 15.0(1)M, traffic within a zone was allowed to pass uninspected by default. To configure a zone pair definition with the same zone for source and destination, use the zone-pair security command. This allows the functionality of attaching a policy map and inspecting the traffic within the same zone.

Layer 3 and Layer 4 policies are "top level" policies that are attached to the target (zone pair). Use the following tasks to configure Layer 3 and Layer 4 firewall policies:

• Configuring a Class Map for a Layer 3 and Layer 4 Firewall Policy
  
• Creating a Policy Map for a Layer 3 and Layer 4 Firewall Policy
  

Depending on your policy, you can configure either an inspect, URL filter, or protocol-specific type parameter map. If you are configuring a URL filter type or protocol-specific type policy, you must configure a parameter map, as appropriate. However, a parameter map is optional if you are using an inspect type policy.

Note

Changes to the parameter map are not reflected on connections already established through the firewall. Changes are applicable only to new connections permitted to the firewall. To ensure that your firewall enforces policies strictly, clear all the connections allowed in the firewall after you change the parameter map. To clear existing connections, use the clear zone-pair inspect sessions command.

Use one of the following tasks to configure a parameter map:

• Creating an Inspect Parameter Map
  
• Creating a URL Filter Parameter Map
  
• Configuring a Layer 7 Protocol-Specific Parameter Map
  
• Configuring OoO Packet Processing Support in the Zone-Based Firewall Applications
  
• Configuring Intrazone Support in the Zone-Based Firewall Applications
  

Configure Layer 7 policy maps if you are need extra provisioning for Layer 7 inspection modules. It is not necessary that you configure all of the Layer 7 policy maps specified in this section.

Use one of the following tasks to configure a Layer 7, protocol-specific firewall policy:

• Layer 7 Class Map and Policy Map Restrictions
  
• Configuring an HTTP Firewall Policy
  
• Configuring a URL Filter Policy
  
• Configuring an IMAP Firewall Policy
  
• Configuring an Instant Messenger Policy
  
• Configuring a Peer-to-Peer Policy
  
• Configuring a POP3 Firewall Policy
  
• Configuring an SMTP Firewall Policy
  
• Configuring a SUNRPC Firewall Policy
  
• Configuring an MSRPC Firewall Policy