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

Grouping interfaces into zones involves the following 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 to and from that interface (except traffic going to the router or initiated by the router) is dropped. To permit traffic to and from a zone-member interface, you must make that zone part of a zone pair and then apply a policy to that zone pair. If the policy permits traffic (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.
• 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 as if the pass action is configured.
• A zone pair can be configured with a zone as both the source and the destination zone. An inspect policy can be configured on this zone pair to inspect or drop the traffic between two interfaces in the same zone.

For traffic to flow among all interfaces in a router, these interfaces must be a member of a security zone.

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

The figure below illustrates the following:

Figure 1

Security Zone Restrictions

The following situations exist:

• The zone pair and policy are configured in the same zone. Traffic flows freely between interfaces E0 and E1 because they are members of the same security zone (Z1).
• If no policies are configured, traffic will not flow between any other interfaces (for example, E0 and 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.

A class identifies 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 functionality that is typically associated with a traffic class. For example, inspect, drop, and pass are actions.

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

• Define match criteria (class map)
• Associate actions to the match criteria (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), determined by how the service-policy command is configured, are checked against the match criteria configured for a class map to determine if the packet belongs to that class.

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.

A virtual interface is a logical interface configured with generic configuration information for a specific purpose or for configuration common to specific users, plus router-dependent information. The template contains Cisco IOS XE software interface commands that are applied to virtual access interfaces, as needed. To configure a virtual template interface, use the interface virtual-template command.

Zone member information is acquired from a RADIUS server and then the dynamically created virtual interface is made a member of that zone. The zone-member security command puts the interface into the corresponding zone.

For more information on Per Subscriber Firewall on LNS feature, see the Release Notes for Cisco ASR 1000 Series Aggregation Services Routers for Cisco IOS XE Release 2.

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 configuring a source and a 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, is applied to traffic directed to the router or traffic generated by the router. It does not apply to traffic through the router. The most common use 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 that permits (or inspects) 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.

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 Access Control Lists (ACLs).

Layer 3 and Layer 4 class maps identify traffic streams on which different actions are performed.

A Layer 3 or Layer 4 policy map is sufficient for the basic inspection of traffic.

The following example shows how to configure class map c1 with the match criteria of ACL 101 and the FTP protocol, and create an inspect policy map named p1 to specify that packets will be dropped on the traffic at c1:

Router(config)# class-map type inspect match-all c1
Router(config-cmap)# match access-group 101
Router(config-cmap)# match protocol ftp
Router(config-cmap)# exit 
Router(config)# policy-map type inspect p1
Router(config-pmap)# class type inspect c1
Router(config-pmap-c)# drop

• Supported Protocols
  

If a traffic meets multiple match criteria, these match criteria must be applied in the order of specific to less specific. For example, consider the following class map example:

class-map type inspect match-any my-test-cmap
 match protocol ftp 
 match protocol tcp

In this example, the FTP traffic must first encounter the match protocol ftp command to ensure that the traffic will be handled by the service-specific capabilities of FTP inspection. If the "match" lines were reversed so that the traffic encountered the match protocol tcp command before it was compared to the match protocol ftp command, the traffic would simply be classified as TCP traffic and inspected according to the capabilities of the firewall's TCP Inspection component.

In addition to user-defined classes, a system-defined class map named class-default represents all packets that do not match any of the user-defined classes in a policy. It always is the last class in a policy map.

You can define explicit actions for this group of packets. If you do not configure any actions for class-default in an inspect policy, the default action is drop.

Access lists are packet-classifying mechanisms. Access lists define the actual network traffic that is permitted or denied when an ACL is applied to a particular router network interface. Thus, the ACL is a sequential collection of permit and deny conditions that applies to a packet. A router tests packets against the conditions set in the ACL one at a time. A deny condition is interpreted as "do not match." Packets that match a deny access control entry (ACE) cause an ACL process to terminate and the next match statement within the class to be examined.

Class maps are used to match a range of variables in an ACL based on the following criteria:

• If a class map does not match a permit or a deny condition, then the ACL fails.
• If a class map is specified, the class map performs either an AND (match-all) or an OR (match-any) operation on the ACL variables.
• If a match-all attribute is specified and any match condition, ACL, or protocol fails to match the packet, further evaluation of the current class is stopped, and the next class in the policy is examined.
• If any match in a match-any attribute succeeds, the class map criteria are met and the action defined in the policy is performed.
• If an ACL matches the match-any attribute, the firewall attempts to ascertain the Layer 7 protocol based on the destination port.

If you specify the match-all attribute in a class map, the Layer 4 match criteria (ICMP, TCP, and UDP) are set and the Layer 7 match criteria are not set. Hence, the Layer 4 inspection is performed and Layer 7 inspection is omitted.

Access lists come in different forms: standard and extended access lists. Standard access lists are defined to permit or deny an IP address or a range of IP addresses. Extended access lists define both the source and the destination IP address or an IP address range. Extended access lists can also be defined to permit or deny packets based on ICMP, TCP, and UDP protocol types and the destination port number of the packet.

The following example shows how a packet received from the IP address 10.2.3.4 is matched with the class test1. In this example, the access list 102 matches the deny condition and stops processing other entries in the access list. Because the class map is specified with a match-all attribute, the "class-map test1" match fails. However, the class map is inspected if it matches one of the protocols listed in test1 class map.

If the class map test1 had a match-any attribute (instead of match-all), then the ACL would have matched deny and failed, but then the ACL would have matched the HTTP protocol and performed the inspection using "pmap1."

access-list 102 deny ip 10.2.3.4 0.0.0. any
access-list 102 permit any any
class-map type inspect match-all test1
match access-list 102
match protocol http
class-map type inspect match-any test2
 match protocol sip
 match protocol ftp
 match protocol http
parameter-map type inspect pmap1
 tcp idle-time 15
parameter-map type inspect pmap2
 udp idle-time 3600
policy-map type inspect test
 class type inspect test1
 inspect pmap1
 class type inspect test2
 inspect pmap2
class type inspect class-default
 drop log

A WAE device can be either an NME-WAE that is installed on an ISR as an integrated service engine or a standalone WAE device.

The figure below shows a WAAS branch deployment that uses WCCP to redirect traffic to an off-path, standalone WAE device for traffic interception. The configuration for this option is the same as the WAAS branch deployment with an NME-WAE.

Figure 4

WAAS Off-Path Branch Deployment

The figure below shows a WAAS branch deployment that has an inline WAE device that is physically in front of the router. Because the WAE device is in front of the router, Layer 7 inspection on the client side is not supported because the Cisco IOS XE firewall receives WAAS optimized packets.

Figure 5

WAAS Inline Path Branch Deployment

An edge WAAS device with the Cisco IOS XE firewall is applied at branch office sites that must inspect traffic moving to and from a WAN connection. The Cisco IOS XE firewall monitors traffic for optimization indicators (TCP options and subsequent TCP sequence number changes) and allows optimized traffic to pass while still applying Layer 4 stateful inspection and deep packet inspection to all traffic, maintaining security while accommodating WAAS optimization advantages.

Note

If the WAE device is in the inline location, the device enters its bypass mode after the automatic discovery process. Although the router is not directly involved in WAAS optimization, the router must be aware that WAAS optimization is applied to the traffic in order to apply the Cisco IOS XE firewall inspection to network traffic and make allowances for optimization activity if optimization indicators are present.

Perform the following task to configure a class map for classifying network traffic.

Note	You must perform at least one step from Step 4, 5, or 6.

1.    enable

2.    configure terminal

3.    class-map type inspect [match-any | match-all] class-map-name

4.    match access-group {access-group | name access-group-name}

5.    match protocol protocol-name

6.    end

Perform the following task to create a policy map for a Layer 3 or Layer 4 firewall policy that will be attached to zone pairs.

If you are creating an inspect type policy map, note that only the following actions are allowed: drop, inspect, and pass.

Note	You must perform at least one step from Step 5, 6, or 7.

1.    enable

2.    configure terminal

3.    policy-map type inspect policy-map-name

4.    class type inspect class-name

5.    inspect [parameter-map-name]

6.    drop [log]

7.    pass [log]

8.    end