IOS Zone Based Firewall

One of the most commonly covered security features when it comes to Cisco security is the ZBF.  It wouldn't be much of a network security blog without at least one post on this topic, so here's my take.

With IOS version 12.4(6)T, Cisco introduced the Zone Based Firewall (ZBF), sometimes referred to as the Zone Policy Based Firewall.  With this, the Classic IOS Firewall or Context-Based Access Control (CBAC), available since IOS version 11.2, is now deprecated. Nearly all of the features of the Classic IOS Firewall are implemented in ZBF as well as wide range of new features. In addition to the new features available in ZBF, it is also said to improve firewall performance over CBAC for most inspection activities.  I've seen it stated in some places that if you attempt to inter-mingle CBAC configuration commands with your ZBF, it MIGHT work, however most documentation states that it wont.  So I wouldn't risk it.  Choose one or the other.

When learning about ZBF, the first thing that you should wrap you mind around is the concept of security zones. Zones establish the security boarders of your network and establish the boundaries of traffic restriction polices.  Zones can be the familiar WAN, LAN and DMZ at the edge of your network, but they can also be whatever else your network requires, at any location your network needs a firewall placed.   If you've worked with dedicated firewall platforms in the past, the concept of zones is probably not anything new.

Inter-Zone traffic is defined by policies written in the Cisco Policy Language (CPL), also commonly referred to as the Cisco Common Classification Policy Language (C3PL).  CPL is similar to Modular QoS Command-Line (MQC), as its goal was to utilize a common language for QoS but it has been extended out to also include security.

The number of steps, and order of the steps, to configure the ZBF differ depending on who writes the guide, but I’ll go with the 6 steps listed in Cisco’s Zone Based Policy Firewall Design and Application Guide.  We’ll define the zones and then the zone-pairs, define the class-maps and then the policy-maps, and then we’ll assign policy-maps to zone-pairs and interfaces to zones.  In this example, well configure a ZBF with the three familiar LAN, WAN and DMZ zones.

1. Define Zones

To define the zones, we simply use the zone security keyword, followed by the name of the zone.  The name and function of each zone is entirely dependent on the function of your network.

zone security LAN
zone security WAN
zone security DMZ

So far, nothing out of the ordinary.  Note that we don't use the "name" keyword that is insisted upon in some places.   There is one other thing to consider in the zones, and that is the router's self zone.  This zone, called Self, is automatically created, and cannot be removed.  It refers to the router itself.  With it, you can control traffic to and from the router itself, such as routing protocols and ssh access.  Unlike other zones, traffic is allowed to flow to and from the Self zone unless explicitly denied by policy.

It should also be noted that all IP addresses belong to the Self zone, regardless of which zone the interface that the IP address belongs to is assigned.  And the Inspect action is not allowed in rules that are applied to the Self zone.

2. Define zone-pairs

Next, we define the zone pairs.  A zone pair is pretty much what it sounds like, it pairs up two different zones to control traffic.  You can have zero, one, or two zone pairs between each pair of zones present in the router.  If you have no zone pairs define, then traffic cannot travel in either direction between the two zones.  If you have one zone pair defined, then you are allowing traffic in one direction between the zones.  And finally, if you have two zone pairs defined, you are allowing traffic in both directions between the two zones.  Of course this doesn't mean all traffic will be allowed.  More on that later.

zone-pair security LAN-to-WAN source LAN destination WAN
zone-pair security WAN-to-LAN source WAN destination LAN
zone-pair security DMZ-to-WAN source DMZ destination WAN
zone-pair security WAN-to-DMZ source WAN destination DMZ
zone-pair security LAN-to-DMZ source LAN destination DMZ
zone-pair security DMZ-to-LAN source DMZ destination LAN
zone-pair security WAN-to-Self source WAN destination Self

3. Define class-maps

Class-maps are used to identify the traffic flowing between zones.  You can match by protocol, by ACL, or by both.  Let's create an ACL, and then a class-map that utilizes the ACL and some protocols.

access-list ICMP_ACL permit icmp host 1.2.3.4 10.0.0.0 0.255.255.255
!
class-map type inspect match-any INBOUND_TRAFFIC_CLASS
 match access-group name ICMP_ACL
 match protocol http
 match protocol https

We've defined an ACL permitting specific ICMP, and then a class-map that will match either that IMCP, all http or all https.  Note that we can use match-any which only requires one of the conditions to be matched, or we can use match-all, which requires all of the conditions to be matched.  You can also use multiple class-maps to define traffic for a single zone-pair should your configuration become that complex.

There's three actions we can take on traffic.  In the above example, I used inspect.  The three are:

• Drop - drop the traffic.
• Pass - pass the traffic without inspection.
• Inspect - pass the traffic and inspect it statefully, so that return traffic is also permitted.  This is kind of like a reflexive ACL in function.

You can also nest one class-map inside of another.

4. Define policy-maps

Now we'll tie one or more class-maps together into a policy map.  Note that there are two classes in use on this policy-map.  There's really no limit on how many you can use if your policy dictates or you find it aids in the readability of your configuration.

policy-map type inspect INBOUND_TRAFFIC_POLICY
 class type inspect INBOUND_TRAFFIC_CLASS
   inspect
 class class-default
   drop

Note the class-default class at the end.  This is a predefined construct, and I'm using it here to drop all other traffic.  In this case, it's like a deny all at the end of an ACL.

5. Apply Policy-maps to zone-pairs

Now we'll apply the policy to a zone-pair. 

zone-pair security WAN-to-LAN
 service-policy type inspect INBOUND_TRAFFIC_POLICY

6. Assign Interfaces to zones

And finally, we'll assign interfaces to the zones.  An interface may belong to one zone, or no zones, but it cannot belong to multiple zones.  And if it doesn't belong to a zone, then the zone rules do not apply to it.

interface FastEthernet0/0
 zone-member security LAN
interface FastEthernet0/1
 zone-member security WAN
interface FastEthernet0/2
 zone-member security DMZ
interface FastEthernet0/3
 zone-member security LAN

Note that multiple interfaces are assigned to the LAN zone.  This is perfectly legal, and brings up a couple final caveats to consider.  First, intra-zone traffic was permitted by default in early IOS versions, however it is not in later versions (version 15.0(1)M and up).  Check the documentation for your IOS release to be certain.  Second, with intra-zone traffic, you only need one zone-pair since the source and destination are the same.

In this post, I've gone through the basics of a ZBF configuration.  While there is a lot to digest here if you're new to ZBF, I've only scratched the surface of what is possible.  We can also add protocol classification using NBAR, rate limiting (policing), Layer 7 class-maps including deep packet inspection (DPI), Wide Area Application Services (WAAS), and a wide range of other features.  I'm sure I'll talk about some of those in future posts.

I'm also going to take an opportunity to give mention to the famed Cheat Sheets available at Packetlife.net.  Like all of them, the ZBF one is great.  I had it and a few others printed out and posted around my desk while I studied for the CCNA Security.