IOS Zone-Based Firewall

Download

Zone Based Firewall is the most advanced method of a stateful firewall that is available on Cisco IOS routers. The idea behind ZBF is that we don’t assign access-lists to interfaces but we will create different zones. Interfaces will be assigned to the different zones and security policies will be assigned to traffic between zones.

Overview of Zone-Based Policy Network Security

A security zone must be configured for each region of relative security with in the network, so that all interfaces that are assigned to the same zone are protected with a similar level of security. For example, consider an access router with three interfaces:

1. One interface connected to the public internet
2. One interface connected to a private LAN that must not be accessible from the public internet
3. 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.

Overview of Zone-Based Firewall

In this example, each zone holds only one interface. I f an additional interface is added to the private zone, the hosts connected to the new interface in the zone can pass traffic to all hosts on the existing interface in the same zone.

Additionally, the hosts’ traffic to hosts in other zones is similarly affected by existing policies.

Typically, the example network has three main policies:

1. Private zone connectivity to the Internet
2. Private zone connectivity to DMZ hosts
3. Internet zone connectivity to DMZ hosts

Rules for Applying Zone-Based Policy Firewall

Router network interfaces’ membership in zones is subject to several rules that govern interface behavior, as is the traffic moving between zone member interfaces:

1. A zone must be configured before interfaces can be assigned to the zone.
2. An interface can be assigned to only one security zone.
3. All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.
4. Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.
5. In order 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.
6. The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.
7. Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.
8. Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.
9. If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.
10. From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).
11. The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

Cisco Policy Language (CPL) Configuration

This procedure can be used to configure a ZFW. The sequence of steps is not important, but some events 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 configured, the router responds with an error message.

1. Define zones.
2. Define zone-pairs.
3. Define class-maps that describe traffic that must have policy applied as it crosses a zone-pair.
4. Define policy-maps to apply action to your class-maps’ traffic.
5. Apply policy-maps to zone-pairs.
6. Assign interfaces to zones.

Configuring Zone-Based Policy Firewall Class-Maps

Class-maps define the traffic that the firewall selects for policy application. Layer 4 class-maps sort the traffic based on these criteria listed here. These criteria are specified using the match command in a class-map:

1. Access-group: A standard, extended, or named ACL can filter traffic based on source and destination IP address and source and destination port.
2. Protocol: The Layer 4 protocols (TCP, UDP, and ICMP) and application services such as HTTP, SMTP, DNS, etc. Any well-known or user-defined service known to Port-Application Mapping can be specified.
3. Class-Map: A subordinate class-map that provides additional match criteria can be nested inside another class-map.
4. Not: The not criterion specifies that any traffic that does not match a specified service (protocol), access-group or subordinate class-map will be selected for the class-map.

Zone-Based Policy Firewall Actions

ZFW provides three actions for traffic that traverses from one zone to another:

1. Drop: This is the default action for all traffic, as applied by the "class class-default" that terminates every inspect-type policy-map. Other class-maps within a policy-map can also be configured to drop unwanted traffic. Traffic that is handled by the drop action is "silently" dropped (i.e., no notification of the drop is sent to the relevant end-host) by the ZFW, as opposed to an ACL's behavior of sending an ICMP “host unreachable” message to the host that sent the denied traffic. Currently, there is not an option to change the "silent drop" behavior. The log option can be added with drop for syslog notification that traffic was dropped by the firewall.
2. 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 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 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 in the ZFW with the inspect action.
3. Inspect: The inspect action offers state-based traffic control. For example, if traffic from the private zone to the Internet zone in the earlier example network is inspected, the router maintains connection or session information for TCP and User Datagram Protocol (UDP) traffic. Therefore, the router permits 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. Audit-trail can be applied with a parameter-map to record connection/session start, stop, duration, the data volume transferred, and source and destination addresses.

Actions are associated with class-maps in policy-maps:

conf t

 policy-map type inspect z1-z2-pmap

  class type inspect service-cmap

   inspect|drop|allow [service-parameter-map]

Parameter-maps offer options to modify the connection parameters for a given class-map’s inspection policy.

Zone Pairs

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 source and destination zones. 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 which 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 device or traffic generated by the device. It does not apply to traffic through the device.

The most common usage of firewall is to apply them to traffic through a device, 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.

Configuration

Topology

Above you see 3 routers and two zones called LAN and WAN. We will configure ZBF on R2. For connectivity, I’ll create a static route on R1 and R3 that points to R2:

R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.12.2

R3(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.2

Configure the Zones

First we will create the two zones, we only have two of them:

R2(config)#zone security LAN

R2(config)#zone security WAN

Assign the interfaces to the correct zone

R2(config)#interface fastEthernet 0/0

R2(config-if)#zone-member security LAN

R2(config)#interface fastEthernet 0/1

R2(config-if)#zone-member security WAN

Configure the Zone Pairs

R2(config)#zone-pair security LAN-TO-WAN source LAN destination WAN

R2(config-sec-zone-pair)#description LAN-TO-WAN TRAFFIC

R2(config)#zone-pair security WAN-TO-LAN source WAN destination LAN

R2(config-sec-zone-pair)#description WAN-TO-LAN TRAFFIC

Creating and Applying Security Policies

R2(config)# class-map type inspect match-any All_Protocols

R2(config-cmap)# match protocol tcp

R2(config-cmap)# match protocol udp

R2(config-cmap)# match protocol icmp

Our class maps need to be wrapped into service policies so that they can be associated with security actions. We do this by creating inspection policy maps.

R2(config)# policy-map type inspect Trusted_to_Internet

R2(config-pmap)# class type inspect All_Protocols

R2(config-pmap-c)# inspect

R2(config)#zone-pair security WAN-TO-LAN source WAN destination LAN

      service-policy type inspect Trusted_to_Internet

----
@NetwaxLab