NET-240 (NetAcad Chapter 10)

pass

A stateless action that allows the router to forward traffic from one zone to another

inspect

An action that offers state−based traffic control. The router maintains session information for TCP and UDP and permits return traffic.

5. Designing a ZPF requires several steps. Which step involves defining boundaries where traffic is subjected to policy restrictions as it crosses to another region of the network?

Determine the zones

drop

Discards unwanted traffic

10.3.11 Packet Tracer - Configure a ZPF

In this Packet Tracer, you will complete the following objectives: Verify connectivity among devices before firewall configuration. Configure a ZPF on router R3. Verify ZPF functionality using ping, Telnet, and a web browser. Configure a ZPF Configure a ZPF

10.3.12 Lab - Configure ZPFs

In this lab, you will complete the following objectives: Complete a basic router configuration. Use the CLI to configure a ZPF. Use the CLI to verify the configuration. Configure ZPFs

class-map-name

Name of the class-map that will be used to configure the policy for the class in the policy-map.

self

Specifies the system-defined zone. Indicates whether traffic will be going to or from the router itself.

Inspect

The ZPF performs stateful packet inspection.

Zone-based Policy Firewall (ZPF)

The configuration model in which interfaces are assigned to security zones, and firewall policy is applied to traffic moving between the zones.

Classic Firewall

The traditional configuration model in which firewall policy is applied on interfaces.

Drop

This is analogous to a deny statement in an ACL. A log option is available to log the rejected packets.

Pass

This is analogous to a permit statement in an ACL. The pass action does not track the state of connections or sessions within the traffic.

drop

This is the default action for all traffic. Similar to the implicit deny any at the end of every ACL, there is an explicit drop applied by the IOS to the end of every policy−map. It is listed as class class-default in the last section of any policy-map configuration. Other class−maps within a policy−map can also be configured to drop unwanted traffic. Unlike ACLs, traffic is silently dropped, and no ICMP unreachable messages are sent to the source of the traffic.

Inspect

This performs Cisco IOS stateful packet inspection.

10.2.2 Rules for Transit Traffic

Traffic transiting through router interfaces is subject to several rules governing interface behavior. For the transit traffic example, refer to the topology shown in the figure. Basic Security Zone Topology DMZ ZonePrivate ZoneInternetPublic Zone The rules depend on whether or not the ingress and egress interfaces are members of the same zone: If neither interface is a zone member, then the resulting action is to pass the traffic. If both interfaces are members of the same zone, then the resulting action is to pass the traffic. If one interface is a zone member, but the other is not, then the resulting action is to drop the traffic regardless of whether a zone-pair exists. If both interfaces belong to the same zone-pair and a policy exists, then the resulting action is inspect, allow, or drop as defined by the policy. The table summarizes these rules. (On cards 16-23).

10.3.7 Verify a ZPF Configuration

Verify a ZPF configuration by viewing the running configuration. Notice that the class-map is listed first. Then the policy-map makes use of the class-map. Also, notice the highlighted class class-default that will drop all other traffic that is not a member of the HTTP-TRAFFIC class. The zone configurations follow the policy-map configurations with zone naming, zone pairing, and associating a service-policy to the zone pair. Finally, the interfaces are assigned zones. R1# show run | begin class-map ! <some output omitted> ! class-map type inspect match-any HTTP-TRAFFIC match protocol http match protocol https match protocol dns ! policy-map type inspect PRIV-TO-PUB-POLICY class type inspect HTTP-TRAFFIC inspect class class-default drop ! zone security PRIVATE zone security PUBLIC zone-pair security PRIV-PUB source PRIVATE destination PUBLIC service-policy type inspect PRIV-TO-PUB-POLICY ! interface GigabitEthernet0/0 zone-member security PRIVATE ! interface Serial0/0/0 zone-member security PUBLIC ! The example below shows verification information after a test of the ZPF configuration. A PRIVATE zone host 192.168.1.3 established an HTTPS session with a web server at 10.1.1.2. Notice further down in the command output that four packets matched the class class-default. This verification information was generated by having host 192.168.1.3 ping the web server at 10.1.1.2. R1# show policy-map type inspect zone-pair sessions policy exists on zp PRIV-PUB Zone-pair: PRIV-PUB Service-policy inspect : PRIV-TO-PUB-POLICY Class-map: HTTP-TRAFFIC (match-any) Match: protocol http 12 packets, 384 bytes 30 second rate 0 bps Match: protocol https 5 packets, 160 bytes 30 second rate 0 bps Match: protocol dns 0 packets, 0 bytes 30 second rate 0 bps Inspect Number of Established Sessions = 1 Established Sessions Session 2204E220 (192.168.1.3:1049)=>(10.1.1.2:443) https:tcp SIS_OPEN/TCP_CLOSEWAIT Created 00:00:14, Last heard 00:00:11 Bytes sent (initiator:responder) [821:1431] Class-map: class-default (match-any) Match: any Drop 4 packets, 160 bytes R1# The example below shows four other ZPF verification commands that allow a view of specific portions of the ZPF configuration.. R1# show class-map type inspect Class Map type inspect match-any HTTP-TRAFFIC (id 1) Match protocol http Match protocol https Match protocol dns R1# show zone security zone self Description: System Defined Zone zone PRIVATE Member Interfaces: GigabitEthernet0/0 zone PUBLIC Member Interfaces: Serial0/0/0 R1# show zone-pair security Zone-pair name PRIV-PUB Source-Zone PRIVATE Destination-Zone PUBLIC service-policy PRIV-TO-PUB-POLICY R1# show policy-map type inspect Policy Map type inspect PRIV-TO-PUB-POLICY Class HTTP-TRAFFIC Inspect Class class-default Drop

Redundant Firewalls

Web/Mail ServerInternetPerimeterOutsideInside

2. How does ZPF handle traffic between an interface that is a zone member and another interface that does not belong to any zone?

drop

6. When a Cisco IOS zone-based policy firewall is being configured, which two actions can be applied to a traffic class? (Choose two.)

inspect drop

12. Which statement describes a zone when implementing ZPF on a Cisco router?

A zone establishes a security border of a network.

3. Which statement describes a factor to be considered when configuring a zone-based policy firewall?

A zone must be configured with the zone security global command before it can be used in the zone-member security command.

4. Which statement describes one of the rules that govern interface behavior in the context of implementing a zone-based policy firewall configuration?

By default, traffic is allowed to flow among interfaces that are members of the same zone.

match access-group

Configures the match criteria for a class-map based on the specified ACL number or name.

match protocol

Configures the match criteria for a class-map based on the specified protocol.

9. In what step of zone-based policy firewall configuration is traffic identified for policy application?

Configuring class maps

10.1.2 ZPF Design

Designing ZPFs involves several steps: Step 1. Determine the zones - The administrator focuses on the separation of the network into zones. Zones establish the security borders of a network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of the network. For example, the public network would be one zone and the internal network would be another zone. Step 2. Establish policies between zones - For each pair of "source-destination" zones (for example, from the inside network to the outside internet), define the sessions that clients in the source zones can request from servers in destination zones. These sessions are most often TCP and UDP sessions, but may also be ICMP sessions, such as ICMP echo. For traffic that is not based on the concept of sessions, the administrator must define unidirectional traffic flows from source to destination and vice versa. Policies are unidirectional and are defined based on source and destination zones, which are known as zone pairs. Step 3. Design the physical infrastructure - After the zones have been identified, and the traffic requirements between them documented, the administrator must design the physical infrastructure. The administrator must take into account security and availability requirements when designing the physical infrastructure. This includes dictating the number of devices between most-secure and least-secure zones and determining redundant devices. Step 4. Identify subsets within zones and merge traffic requirements - For each firewall device in the design, the administrator must identify zone subsets that are connected to its interfaces and merge the traffic requirements for those zones. For example, multiple zones might be indirectly attached to a single interface of a firewall. This would result in a device-specific interzone policy. Although an important consideration, implementing zone subsets is beyond the scope of this curriculum.

Activity Part 2 - Rules for Self Zone Traffic

Identify the correct rules for self zone traffic by selecting your answers from the 6 drop down menus. Source Interface Member of Zone? YES (self-zone) YES (self-zone) YES YES (self-zone) Destination Interface Member of Zone? YES YES YES YES YES (self-zone) YES YES (self-zone) YES (self-zone) Zone-Pair Exists? NO YES NO YES Policy Exists? PASS NO N/A NO YES Result PASS INSPECT PASS

10.2.4 Check Your Understanding - Rules for Transit Traffic Activity Part 1 - Rules for Transit Traffic

Identify the correct rules for transit traffic by selecting your answers from the 7 drop down menus. Source Interface Member of Zone? NO YES YES (Private) NO Destination Interface Member of Zone? YES (Private) YES (Private) YES (Private) NO NO YES (Private) YES YES (Public) YES (Public) YES (Public) Zone-Pair Exists? N/A N/A N/A N/A YES Policy Exists? N/A N/A N/A N/A N/A YES Result DROP DROP INSPECT

Complex Firewall

InsideOutsidePerimeterAdministratorInternetE-CommerceVPN UsersVPN OfficesWeb/Mail Server

LAN-to-Internet

InternetInsideOutside

Firewall with public servers - 1

InternetInsideOutsideWeb/Mail ServerPerimeter

Firewall with public servers - 2

InternetPerimeterOutsideInsideWeb/Mail Server

8. Which statement describes a feature of a zone-based policy firewall?

It does not depend on ACLs.

match-all

Packets must meet all of the match criteria to be considered a member of the class.

match-any

Packets must meet one of the match criteria to be considered a member of the class.

ZPF Operation 10.2.1 ZPF Actions

Policies identify actions that the ZPF will perform on network traffic. Three possible actions can be configured to process traffic by protocol, source and destination zones (zone pairs), and other criteria. Inspect - This performs Cisco IOS stateful packet inspection. Drop - This is analogous to a deny statement in an ACL. A log option is available to log the rejected packets. Pass - This is analogous to a permit statement in an ACL. The pass action does not track the state of connections or sessions within the traffic.

source source-zone-name

Specifies the name of the zone from which traffic is originating.

destination destination-zone-name

Specifies the name of the zone to which traffic is destined.

10.3.8 Syntax Checker-Configure a ZPF

Step 1: Create the zones. Use the zone security command to create a zone called PRIVATE. Exit the config-sec-zone configuration mode. Use the zone security command to create a zone called PUBLIC. Exit the config-sec-zone configuration mode. R1(config)#zone security PRIVATE R1(config-sec-zone)#exit R1(config)#zone security PUBLIC R1(config-sec-zone)#exit R1(config)# Step 2: Identify traffic with a class-map. Create an inspect type class-map called HTTP-TRAFFIC. The class-map should use the match-any inspection criteria. Use the match protocol command to allow the HTTP, HTTPS, DNS protocols. Exit config-cmap configuration mode. R1(config-cmap)#class-map type inspect match-any HTTP-TRAFFIC R1(config-cmap)#match protocol http R1(config-cmap)#match protocol https R1(config-cmap)#match protocol dns R1(config-cmap)#exit Step 3: Define an action with a policy-map. Create an inspect type policy-map called PRIV-TO-PUB-POLICY. Associate the HTTP-TRAFFIC class-map that you created in Step 2 to the policy-map using the class type inspect command. Assign the action to inspect. Exit policy-map-c configuration mode. Exit policy-map configuration mode. R1(config)#policy-map type inspect PRIV-TO-PUB-POLICY R1(config-pmap)#class type inspect HTTP-TRAFFIC R1(config-pmap-c)#inspect R1(config-pmap-c)#exit R1(config-pmap)#exit R1(config)# Step 4: Identify a zone pair and match it to a policy-map. Create a zone-pair called PRIV-PUB. The source should be the PRIVATE zone, and the destination should be the PUBLIC zone. Use the service-policy command to assign the PRIV-TO-PUB-POLICY policy-map that you created in Step 3. Exit config-sec-zone-pair mode. R1(config)#zone-pair security PRIV-PUB source PRIVATE destination PUBLIC R1(config-sec-zone-pair)#service-policy type inspect PRIV-TO-PUB-POLICY R1(config-sec-zone-pair)#exit Step 5: Assign zones to the appropriate interfaces. Assign the zone PRIVATE to interface G0/0. Assign the zone PUBLIC to interface S0/0/0. End configuration mode. R1(config)#interface g0/0 R1(config-if)#zone-member security PRIVATE R1(config-if)#interface s0/0/0 R1(config-if)#zone-member security PUBLIC R1(config-if)#end R1# Enter the show run | begin class-map command to verify your configuration. R1#show run | begin class-map ! <some output omitted> ! class-map type inspect match-any HTTP-TRAFFIC match protocol http match protocol https match protocol dns ! policy-map type inspect PRIV-TO-PUB-POLICY class type inspect HTTP-TRAFFIC inspect class class-default drop ! zone security PRIVATE zone security PUBLIC zone-pair security PRIV-PUB source PRIVATE destination PUBLIC service-policy type inspect PRIV-TO-PUB-POLICY ! interface GigabitEthernet0/0 zone-member security PRIVATE ! interface Serial0/0/0 zone-member security PUBLIC ! R1# You successfully configured a Zone-Based Policy Firewall on R1.

10.3.6 Step 5. Assign Zones to Interfaces

The fifth step is to assign zones to the appropriate interfaces. Associating a zone to an interface will immediately apply the service-policy that has been associated with the zone. If no service-policy is yet configured for the zone, all transit traffic will be dropped. Use the zone-member security command to assign a zone to an interface, as shown in the example below. Router(config-if)# zone-member security zone-name In the following example, GigabitEthernet 0/0 is assigned the PRIVATE zone, and Serial 0/0/0 is assigned the PUBLIC zone. R1(config)# interface GigabitEthernet 0/0 R1(config-if)# zone-member security PRIVATE R1(config-if)# interface Serial 0/0/0 R1(config-if)# zone-member security PUBLIC The service-policy is now active. HTTP, HTTPS, and DNS traffic sourced from the PRIVATE zone and destined for the PUBLIC zone will be inspected. Traffic sourced from the PUBLIC zone and destined for the PRIVATE zone will only be allowed if it is part of sessions originally initiated by PRIVATE zone hosts.

10.3.2 Step 1. Create the Zones

The first step, is to create the zones. However, before creating the zones answer a few questions: What interfaces should be included in the zones? What will be the name for each zone? What traffic is necessary between the zones and in which direction? In the example topology, we have two interfaces, two zones, and traffic flowing in one direction. Traffic sourced from the public zone will not be allowed. Create the private and public zones for the firewall with the zone security command, as shown here. Router(config)# zone security zone-name R1(config)# zone security PRIVATE R1(config-sec-zone)# exit R1(config)# zone security PUBLIC R1(config-sec-zone)# exit R1(config)#

10.3.5 Step 4. Identify a Zone-Pair and Match to a Policy

The fourth step is to identify a zone pair and associate that zone pair to a policy-map. The example below shows the command syntax. Create a zone-pair with the zone-pair security command. Then use the service-policy type inspect command to attach a policy-map and its associated action to the zone-pair. Router(config)# zone-pair security zone-pair-name source {source-zone-name | self} destination {destination-zone-name | self} Router(config-sec-zone-pair)# service-policy type inspect policy-map-name Parameter Description source source-zone-name: Specifies the name of the zone from which traffic is originating. destination destination-zone-name: Specifies the name of the zone to which traffic is destined. self: Specifies the system-defined zone. Indicates whether traffic will be going to or from the router itself. The example below shows an example of a zone-pair configuration. A zone-pair named PRIV-PUB is created with PRIVATE assigned as the source zone and PUBLIC assigned as the destination zone. Then the policy-map created in the previous step is associated to the zone-pair. After the firewall policy has been configured, the administrator applies it to traffic between a pair of zones using the zone-pair security command. To apply a policy, it is assigned to a zone pair. The zone pair needs to specify the source zone, the destination zone, and the policy for handling the traffic between the source and destination zones. R1(config)# zone-pair security PRIV-PUB source PRIVATE destination PUBLIC R1(config-sec-zone-pair)# service-policy type inspect PRIV-TO-PUB-POLICY

1. Which statement accurately describes Cisco IOS zone-based policy firewall operation?

The pass action works in only one direction.

11. In ZPF design, what is described as the self zone?

The router itself, including all interfaces with assigned IP addresses.

10.3.3 Step 2. Identify Traffic

The second step is to use a class-map to identify the traffic to which a policy will be applied. A class is a way of identifying a set of packets based on its contents using "match" conditions. Typically, you define a class so that you can apply an action to the identified traffic that reflects a policy. A class is defined with class-maps. The example below shows the syntax for the class-map command. There are several types of class-maps. For a ZPF configuration, use the inspect keyword to define a class-map. Determine how packets are evaluated when multiple match criteria exist. Packets must meet one of the match criteria (match-any) or all of the match criteria (match-all) to be considered a member of the class. Router(config)# class-map type inspect [match-any | match-all] class-map-name Parameter Description match-any: Packets must meet one of the match criteria to be considered a member of the class. match-all: Packets must meet all of the match criteria to be considered a member of the class. class-map-name: Name of the class-map that will be used to configure the policy for the class in the policy-map. The example below shows the syntax for the match statements in class-map sub-configuration mode. Match traffic to an ACL, a specific protocol, or even another class-map. Router(config-cmap)# match access-group {acl-# | acl-name } Router(config-cmap)# match protocol protocol-name Router(config-cmap)# match class-map class-map-name Parameter Description match access-group: Configures the match criteria for a class-map based on the specified ACL number or name. match protocol: Configures the match criteria for a class-map based on the specified protocol. match class-map: Uses another class-map to identify traffic. In the topology, HTTP traffic is being allowed to cross R1 from the PRIVATE to the PUBLIC zone. When allowing HTTP traffic, it is recommended to specifically include HTTPS and DNS protocols, as shown in the example below. Traffic can match any of the statements to become a member of the HTTP-TRAFFIC class. R1(config)# class-map type inspect match-any HTTP-TRAFFIC R1(config-cmap)# match protocol http R1(config-cmap)# match protocol https R1(config-cmap)# match protocol dns

10.2.3 Rules for Traffic to the Self Zone

The self zone is the router itself and includes all of the IP addresses assigned to the router interfaces. This is traffic that originates at the router or is addressed to a router interface. Specifically, the traffic is either for device management, for example SSH, or traffic forwarding control, such as routing protocol traffic. The rules for a ZPF are different for the self zone. For the self zone traffic example, refer to the topology shown in the previous figure. The rules depend on whether the router is the source or the destination of the traffic, as shown in the table. If the router is the source or the destination, then all traffic is permitted. The only exception is if the source and destination are a zone-pair with a specific service-policy. In that case, the policy is applied to all traffic. Source Interface Member of Zone? YES (self zone) Destination Interface Member of Zone? YES Zone-Pair Exists? NO Policy Exists? N/A Result PASS

10.3.4 Step 3. Define an Action

The third step is to use a policy-map to define what action should be taken for traffic that is a member of a class. The example below shows the command syntax to configure a policy-map. An action is a specific functionality. It is typically associated with a traffic class. For example, inspect, drop, and pass are actions. R1(config)# policy-map type inspect policy-map-name R1(config-pmap)# class type inspect class-map-name R1(config-pmap-c)# {inspect | drop | pass} Parameter Description inspect: An action that offers state−based traffic control. The router maintains session information for TCP and UDP and permits return traffic. drop: Discards unwanted traffic pass: A stateless action that allows the router to forward traffic from one zone to another The example below shows an example of a policy-map configuration. The class HTTP-TRAFFIC that was configured in the previous step is associated with a new policy-map named PRIV-TO-PUB-POLICY. The third inspect command configures R1 to maintain state information for all traffic that is a member of the class HTTP-TRAFFIC. R1(config)# policy-map type inspect PRIV-TO-PUB-POLICY R1(config-pmap)# class type inspect HTTP-TRAFFIC R1(config-pmap-c)# inspect inspect - This action offers state-based traffic control. For example, if traffic traveling from the PRIVATE zone to the PUBLIC zone is inspected, the router maintains connection or session information for TCP and UDP traffic. The router would then permit return traffic sent from PUBLIC zone hosts in reply to PRIVATE zone connection requests. drop - This is the default action for all traffic. Similar to the implicit deny any at the end of every ACL, there is an explicit drop applied by the IOS to the end of every policy−map. It is listed as class class-default in the last section of any policy-map configuration. Other class−maps within a policy−map can also be configured to drop unwanted traffic. Unlike ACLs, traffic is silently dropped, and no ICMP unreachable messages are sent to the source of the traffic. pass - This action allows the router to forward traffic from one zone to another. The pass action does not track the state of connections. Pass only allows the traffic in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction. The pass action is ideal for secure protocols with predictable behavior, such as IPsec. However, most application traffic is better handled in the ZPF with the inspect action.

Configure a ZPF 10.3.1 Configure a ZPF

The topology shown in the figure will be used throughout the remainder of this topic to demonstrate ZPF configuration. The sequence of steps is not required. However, some configurations must be completed in order. For instance, you must configure a class-map before you assign a class-map to a policy-map. Similarly, you cannot assign a policy-map to a zone-pair until you have configured the policy. If you try to configure a section that relies on another portion of the configuration that you have not yet configured, the router responds with an error message. Zone-Based Policy Firewall Configuration Steps R1G0/0S0/0/0 Private ZoneHTTPHTTP return trafficAny other trafficInternetPublic Zone Step 1: Create the zones. Step 2: Identify traffic with a class-map. Step 3: Define an action with a policy-map. Step 4: Identify a zone pair and match it to a policy-map. Step 5: Assign zones to the appropriate interfaces.

Drop

The traffic is not permitted to travel to the destination. The rejected packets can be logged.

Pass

The traffic is permitted to travel to the destination zone. This does not track the state of connections or sessions.

ZPF Overview 10.1.1 Benefits of a ZPF

There are two configuration models for Cisco IOS Firewall: Classic Firewall - The traditional configuration model in which firewall policy is applied on interfaces. Zone-based Policy Firewall (ZPF) - The configuration model in which interfaces are assigned to security zones, and firewall policy is applied to traffic moving between the zones. If an additional interface is added to the private zone, the hosts connected to the new interface in the private zone can pass traffic to all hosts on the existing interface in the same zone. A simple three-zone network is shown in the figure. Basic Security Zone Topology DMZ ZonePrivate ZonePublic ZoneInternet The primary motivations for network security professionals to migrate to the ZPF model are structure and ease of use. The structured approach is useful for documentation and communication. The ease of use makes network security implementations more accessible to a larger community of security professionals. There are several benefits of a ZPF: It is not dependent on ACLs. The router security posture is to block unless explicitly allowed. Policies are easy to read and troubleshoot with the Cisco Common Classification Policy Language (C3PL). C3PL is a structured method to create traffic policies based on events, conditions, and actions. This provides scalability because one policy affects any given traffic, instead of needing multiple ACLs and inspection actions for different types of traffic. Virtual and physical interfaces can be grouped into zones. Policies are applied to unidirectional traffic between zones. When deciding whether to implement IOS Classic Firewall or a ZPF, it is important to note that both configuration models can be enabled concurrently on a router. However, the models cannot be combined on a single interface. For example, an interface cannot be simultaneously configured as a security zone member and for IP inspection.

pass

This action allows the router to forward traffic from one zone to another. The pass action does not track the state of connections. Pass only allows the traffic in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction. The pass action is ideal for secure protocols with predictable behavior, such as IPsec. However, most application traffic is better handled in the ZPF with the inspect action.

inspect

This action offers state-based traffic control. For example, if traffic traveling from the PRIVATE zone to the PUBLIC zone is inspected, the router maintains connection or session information for TCP and UDP traffic. The router would then permit return traffic sent from PUBLIC zone hosts in reply to PRIVATE zone connection requests.

7. Which three statements describe zone-based policy firewall rules that govern interface behavior and the traffic moving between zone member interfaces? (Choose three.)

To permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone. If traffic is to flow between all interfaces in a router, each interface must be a member of a zone. Pass, inspect, and drop options can only be applied between two zones.

10. When configuring a class map for a zone-based policy firewall, how is the match criteria applied when using the match-all parameter?

Traffic must match all of the match criteria specified in the statement.

match class-map

Uses another class-map to identify traffic.

10.3.9 ZPF Configuration Considerations

When configuring a ZPF with the CLI, there are several factors to consider: The router never filters the traffic between interfaces in the same zone. An interface cannot belong to multiple zones. To create a union of security zones, specify a new zone and appropriate policy map and zone pairs. ZPF can coexist with Classic Firewall although they cannot be used on the same interface. Remove the ip inspect interface configuration command before applying the zone-member security command. Traffic can never flow between an interface assigned to a zone and an interface without a zone assignment. Applying the zone-member configuration command always results in a temporary interruption of service until the other zone-member is configured. The default inter-zone policy is to drop all traffic unless otherwise specifically allowed by the service-policy configured for the zone-pair. The zone-member command does not protect the router itself (traffic to and from the router is not affected) unless the zone- pairs are configured using the predefined self zone.

Zone-Based Firewalls Summary 10.4.1 What Did I Learn in this Module?

ZPF Overview The IOS ZPF provides a flexible and powerful replacement for the older Classic IOS Firewall. It provides a new configuration mode in which interfaces are assigned to security zones and firewall policies are applied to traffic moving between the zones. The ZPF provides a structured and simplified method of designing and implementing network security on routers that are performing a firewall function. ZPF Operation ZPFs use user-defined policies to act on specific traffic that is travelling from a source zone to a destination zone. Three actions can be specified: Inspect - The ZPF performs stateful packet inspection. Drop - The traffic is not permitted to travel to the destination. The rejected packets can be logged. Pass - The traffic is permitted to travel to the destination zone. This does not track the state of connections or sessions. Default rules are applied to transit traffic based on the configuration of the ingress and egress interfaces and the existence of policies. For example, if neither ingress or egress interface is defined as member of a zone, traffic is permitted to exit the egress interface. Similarly, if both interfaces are members of the same zone, then traffic is allowed to pass. However, if one interface is a member of a zone and the other is not, traffic will be dropped. It is important to understand these and the other rules covered in the module. A special zone exists that is known as the self zone. The self zone is the router itself. In the self zone, the router interfaces serve as either the source or destination of the traffic. Self zone traffic is either for management of the device, or for traffic forwarding control. Similar to the rules for transit traffic, rules exist for how traffic in the self zone will be handled. Configure a ZPF There are five steps in the process of configuring a ZPF. First the zones are created. Next, one or more class maps are created to specify the traffic which should be associated with a policy. Then, policies are created that associate the class-map traffic with the pass, drop, or inspect actions. It is then necessary to create zone pairs that will be associated with policy maps. Finally interfaces are associated with zones. At this point, the ZPF policy is active.