After a number of context-based access control (CBAC ) tutorials that we have been running in the previous installments, we are going to see another IOS security feature that allows us to configure and operate a firewall straight out of a generic IOS router, as opposed to deploying a specialized hardware firewall like the ASA firewalls. That security feature is called zone-based policy firewall (ZBPF). This subject will span more than one tutorial because of the subject width and the fun therein.

Like the CBAC feature, the ZBPF feature creates a stateful firewall by the means of network segments groupings also known as zones. One zone can coincide exactly to one interface/segment or span multiple interfaces/segments on one router.

With zone-based policy firewall, policies are applied between zone pairs in one or the other direction, which makes it possible to configure two different policies for one zone pair; one policy in each direction. These policies are configured for traffic classes that are created with access control lists set to distinguish specific traffic into classes.

ZBPF also uses deep packet inspection to enforce strict adherence to individual protocol standards. So when a particular protocol (SSH, for example) is being inspected in one direction, the firewall will dynamically and temporarily open gates for return traffic once it has identified it as such and at the same time will inspect the application layer and verify that the traffic adheres strictly to SSH standards. Any noncompliant behavior will be reason for the traffic to be rejected and the involved session(s) closed.

Once again, CBAC is interface-based (configured on an interface) and ZBPF is …. well….. zone-based (configured on a zone), where a zone can include more than one interface. And these zones can grow up to 256 configurable zones.

It should be noted that the zones configured involve traffic originated from hosts located behind or connected to the interface(s) in that zones. This doesn’t take in account traffic originating or destined from/to the router itself. These kinds of traffic policies are configured on the default “self” zone that is automatically set as soon as zones are set. This traffic comprises control plane (EIGRP, OSPF, BGP, … ) and management plane(SNMP, Telnet, ping,…) traffic.

To be noted also is the fact that, although intra-zone traffic is by default permitted and no policy restriction is applied to it, as of IOS version 15.0(1)M, intra-zone access policy as opposed to inter-zone access policy is available as well and can be configured to regulate traffic between hosts located in the same zone but are connected to different interfaces. That was predictable because, would the hosts be located on the same segment, intra-zone policing wouldn’t work since the communication would be through a direct broadcast and no gateway involved. This intra-zone feature adds more flexibility to the way you plan and operate your networks and your zone based policy firewalls. The trick here is to just configure one and same zone as the source and destination in the zone pairing process. This is achieved with a zone pairing with the same zone as source and destination.

Summary comparison chart

CBAC

Zone Based Firewall

Interface-based configuration Zone-based configuration
Controls inbound and outbound access on an interface Controls bidirectional access between zones.
Configuration of routers with more than two interfaces can become complex Simple configuration of routers with more than two zones
Uses inspect statements and stateful ACLs Uses class-based policy language known as C3PL (Cisco Common Classification Policy Language)
Application inspection and control not supported Supports application inspection and control
Support from IOS Release 11.2 Support from IOS Release 12.4 (6) T

Tasks List and Order of Configuration

To deploy a zone-based policy firewall on a Cisco router, there are a number of tasks/configuration steps that need to be completed before the configuration is deemed finalized and operational. All the following tasks need to be completed:

1. Create zones.

2. Assign interfaces to zones.

3. Create zone pairs.

4. Create class maps that describe traffic that must have policy applied to it as it crosses from a zone to another zone.

5. Create policy maps to apply action to your class maps and traffic they have selected.

6. Apply policy maps to zone pairs with the use of service policy command.

Some of these steps are complementary and do call on one another and thus need to be configured in a certain order to avoid error messages by the IOS complaining of missing configurations. Basically, it goes more or less like this:

* We can’t define zone pairs before individual zones are configured; [ {1} should precede {2} ].
* You can’t apply policy maps to zone pairs if policy maps are not yet configured; [{4} should precede {5}].
* In a policy map, you can’t add a class map if class maps are not yet configured; [{3} should precede {4}].
* In a class map, you can’t add an access control lists if access control lists are not configured; [ {2} should precede {3} ].

Some of these error messages about missing dependencies can be overlooked just because we know we are going to put in place the missing configurations. My suggestion is that the six steps listed above be configured in that order.

Topology

To illustrate our zone-based policy firewall discussion, let us posit the following topology. For the needs of this topology, we will use an appropriate IOS that provides the ZBPF feature: c3725-adventerprisek9-mz124-15.

Basic connectivity is configured on the routers with static routing.

From IT-and-RESEARCH, tracing to HR-and-SALES yields

then DMZ

and OUTSIDE

and ZBPF

Looking at the physical topology, we could create four different zones so as to be able to discriminate and police different traffic types between them. I will choose to group HR-and-SALES and IT-and-RESEARCH in one zone (INSIDE zone) so we can explore together the intra-zone feature.

That leads us to the following logical topology:

Now that the zones are defined, let’s define the following policies:

  • From the inside zone, ping, traceroute, and SSH will be possible from HR-and-SALES and IT-and-RESEARCH routers to OUTSIDE router located in OUTSIDE.
  • From the inside zone, ping, traceroute, and SSH will be possible from HR-and-SALES and IT-and-RESEARCH routers to DMZ router located in DMZ
  • From the OUTSIDE zone, ping and traceroute only are possible to DMZ router only and only in the DMZ zone.
  • From the DMZ zone, SSH, ping, traceroute are possible only toward the routers in the INSIDE zone.

Knowing now, on paper, the zones needed and the policies to apply, let’s go ahead and configure the six objects on the task list.

Creating the Zones

We create the three zones: INSIDE, OUTSIDE, DMZ. Notice the config-sec-zone configuration mode

In global configuration mode.

Notice that configuring / creating the three zones doesn’t disrupt the existing network connectivity.

The same applies from

and from inside

Assigning Interfaces to Zones

On the ZBPF router, the interfaces FE 0/0 and 0/1 are in the INSIDE zone.

So from the interface configuration mode,

the interface FE 1/0 is in the DMZ zone

and the interface FE 2/0 is in the OUTSIDE zone!!!

We shall notice the fact that pre-existing connectivity is broken now, upon interface assignment to their zones.

The hosts in the INSIDE zone are, however, still able to communicate between them

and also with the ZBPF router’s loopback

and the other interfaces on the ZBPF router.

This is a very important point to keep in mind when deploying ZBPF. Assigning interfaces to zones will break the connectivity until the rest of the configuration steps are completed. At this point, we have a broken connectivity because we have told the IOS to apply to the interface FE 0/0 policies related to FE0/0 while the said policies are not yet configured. This means that, when configuring the ZBPF feature on a router in a production environment, we need to pay attention to mandatory network disruptions during configuration as soon as you assign one single interface to a zone and as you configure and apply the proper policies to let desired traffic pass through and restore the connectivity.

Now that both configuration steps related to zones (zone creation and interface assignment to zones) are done, we need to configure the remaining configuration steps so as to restore the network connectivity.

Looking at a basic policy definition like the one we defined earlier:

  • From the inside zone, ping, traceroute and SSH will be possible from HR-and-SALES and IT-and-RESEARCH routers to OUTSIDE router located in OUTSIDE.

We can see the following:

  • The policy pairs the zones INSIDE an OUTSIDE.
  • And goes on to specify the kind of traffic to be allowed to go from INSIDE to outside.(not the other way round, as far as that policy is concerned).

In the following section, we will configure the zone pairings as per the policies we defined in the earlier section.

We will be indicating a policy, the zones it pairs, and the commands to configure the pairing.

Pairing the Zones

  • From the INSIDE zone, ping, traceroute and SSH will be possible from HR-and-SALES and IT-and-RESEARCH routers to OUTSIDE router located in OUTSIDE.
    • That policy pairs the INSIDE zone with the OUTSIDE zone.

      The following command does the needed pairing:

  • From the inside zone, ping, traceroute and SSH will be possible from HR-and-SALES and IT-and-RESEARCH routers to DMZ router located in DMZ.
    • That policy pairs the INSIDE zone and the DMZ zone.

      The following command does the needed pairing:

  • From the OUTSIDE zone, ping and traceroute only are possible to DMZ router only in the DMZ zone only.
    • That policy pairs the OUTSIDE zone and the DMZ zone.

    The following command does the needed pairing:

  • From the DMZ zone, SSH, ping, traceroute only are possible toward the routers in the INSIDE zone.
    • That policy pairs the DMZ zone to the INSIDE zone.

      The following command does the needed pairing:

As this article reaches its end let’s sum up what have been done up to now:

  • The zones are configured and assigned interfaces, which broke the connectivity.
  • Zone pairing is done, which doesn’t restore the connectivity because there are other settings left to configure and apply the policies.

In the next article, we will take this article from this point and sail through the rest of the configuration steps for a complete zone-based policy firewall.