Zone-Based Policy Firewalls (ZPFs)

ZPFs use the concept of zones to provide additional flexibility. A zone is a group of one or more interfaces that have similar functions or features. Zones help you specify where a Cisco IOS firewall should be applied. By default, the traffic between interfaces in the same zone is not subject to any policy and passes freely. However, all zone-to-zone traffic is blocked. In order to permit traffic between zones, a policy allowing or inspecting traffic must be configured.

The only exception to this default deny any policy is the router self zone.

The self zone is the router itself and includes all the router interface IP addresses. Policy configurations that include the self zone would apply to traffic destined to and sourced from the router. By default, there is no policy for this type of traffic. Traffic that should be considered when designing a policy for the self zone includes management plane and control plane traffic, such as SSH, SNMP, and routing protocols.

Layered defense

If allowed by the policy, the traffic goes to the screened firewall or bastion host system that applies more rules to the traffic and discards suspect packets. A bastion host is a hardened computer that is typically located in the DMZ. Then the traffic goes to an interior screening router. The traffic moves to the internal destination host only after successfully passing through all policy enforcement points between the outside router and the inside network. This type of DMZ setup is called a screened subnet configuration.

A network administrator must consider many factors when building a complete in-depth defense:

  • Firewalls typically do not stop intrusions that come from hosts within a network or zone.
  • Firewalls do not protect against rogue access point installations.
  • Firewalls do not replace backup and disaster recovery mechanisms resulting from attack or hardware failure.
  • Firewalls are no substitute for informed administrators and users.

 

basic of ZPF

There are two configuration models for Cisco IOS Firewall:

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

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

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.
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. Provides scalability by having one policy affects any given traffic, instead of needing multiple ACLs and inspection actions.

When deciding whether to implement 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.

ZPF design

Common ZPF designs are LAN-to-Internet.

Designing ZPFs involves several steps:

Step 1. Determine the zones – The administrator focuses on the separation of the network into zones. 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.

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

ZPF Actions

The Cisco IOS ZPF can take three possible actions:

  • Inspect – Performs Cisco IOS stateful packet inspection.
  • Drop – Analogous to a deny statement in an ACL. A log option is available to log the rejected packets.
  • Pass – Analogous to a permit statement in an ACL. The pass action does not track the state of connections or sessions within the traffic.
Rules for Transit Traffic

Traffic transiting through router interfaces is subject to several rules governing interface behavior.

The rules depend on whether or not the ingress and egress interfaces are members of the same zone, as shown in Figure bellow:

Transit Traffic-CCNA Security

  • 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.
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. The rules for a ZPF are different for the self zone. For the self zone traffic example, The rules depend on whether the router is the source or the destination of the traffic. 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.

Self ZOne Traffic-CCNA Security

Configure ZPF

The topology and steps will be used throughout the remainder of this topic to demonstrate ZPF configuration.

Steps:
step1. create the zones.

Things to consider

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?

Syntax: r1(config)# zone security zone_name

step2, Identify traffic with a class-map.

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.

Syntax: r1(config)# class-map type inspect [match-any | match-all] class_map_name

  • Match-any: packets must meet one of the match criteria to be considered a member of the class. The match-any keyword instructs the router that any of the match protocol statements will qualify as a successful match resulting in a policy being applied.
  • match-all: packets must nmeet all of the match criteria to be considered a member of the class.
  • class_map_name: name of the class-map used to configure the policy for the class in the policy-map.

Syntax for the match statements in class-map sub-configuration mode. Match traffic to an ACL, a specific protocol, or even another class-map.

R1(config)# match access-group { acl-# | acl-name}

R1(config)# match protocol protocol-name

R1(config)# match class-map class-map-name

step3. Define an action with a policy-map.

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.

R1(config)# policy-map type inspect policy-map-name

R1(config-pmap)# class type inspect class-map-name   //This inspect means use which class map as reference

R1(config-pmap-c)# {inspect | drop | pass}    //ZBP  action

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

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

 

step4. Identify a zone pair and match it to a policy-map

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.

Syntax:

R1(config)# zone-pair security zone-pair-name source { source-zone-name | self } destination { destination-zone-name | self}

R1(config-sec-zone-pair)# service-policy type inspect policy-map-name

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

Because zone-pairs define unidirectional traffic flow, another zone-pair must be created if you want to define polity for return traffic.
Notice that Cisco ZPF can be configured to inspect traffic that moves in the direction defined by the zone pair.

step5. Assign Interfaces to the Proper Security Zones.

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.

Syntax:

R1(config-if)# zone-member security zone-name

The sequence of steps is not required, you can configure according to your habbit.

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.

 

Verify ZPF configuration

 

1. verify a ZPF configuration by viewing the running configuration.

verify_ZPF_running

2. command show policy-map type inspect zone-pair sessions

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

3. other show command:

  • show class-map type inspect
  • show zone security
  • show zone-pair security
  • show policy-map type inspect
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 (intra-zone traffic).
  • Only one zone is allowed per interface: 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.
  • No classic firewall and zone-based firewall configuration on same interface.  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.
  • If only one zone member is assigned, all traffic is dropped. 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.
  • Only explicitly allowed traffic is forwarded between zones: The default inter-zone policy is to drop all traffic unless otherwise specifically allowed by the service-policy configured for the zone-pair.
  • Traffic to the self zone is not filtered: 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.

 

Firewall best practices:

 

Firewall or router + firewall:

Firewalls are edge devices with statefull packet inspection, routers will plain and simple route with the ability to add ACL’s, which is stateless.

Firewalls can do both.

If you don’t have any complex routing (needs for routing protocols like IGRP or BGP) needed in your network then a a firewall will be fine as an internet gateway.

Best practices:

  • Position firewalls at security boundaries
  • Firewalls are critical part of network security, but it is unwise to rely exclusively on a firewall for security
  • Deny all traffic by default, permit only services that are needed
  • Ensure that physical access to the firewall is controlled
  • Regularly monitor firewall logs
  • Practice change management for firewall configuration changes.

 

More reading:

Deep packet inspection engine.

Pages: 1 2