IOS Zone-Based Firewall Overview for CCIE Routing and Switching 4.0 Candidates

Hello to all of you CCIE R&S 4.0 candidates!  The people have spoken on our blog, and we are delivering!  You all wanted to hear more about CCIE 4.0 specific topics that have been added to the new blueprint.  I thought I would take this opportunity to bring you all a blog on zone-based firewalls.

First of all, what are “zone based” firewalls anyways?  Basically, the idea is that instead of just putting ACLs on interfaces, or using CBAC for inspection where we have to replicate the same thing on multiple interfaces, we now group interfaces into “zones.”  A group of similar interfaces from the perspective of network security usually go into the same zone.  For instance, we could have a zone for our internet facing interface and a zone for all of our various inside network facing interfaces.  If we wanted to get more complex, we could add in a zone for a DMZ or something like that.  Essentially, it works very similar to how we do things with an ACTUAL firewall, like an ASA appliance.  So, why don’t we just go buy an ASA?  Sigh…if only it were that simple hehe.  Cisco seems to be implementing more and more things we can do in the actual IOS these days, even though there are appliances that do similar things and more.  Plus, we need to learn it for 4.0.

Today we will be implementing a basic IOS zone-based firewall solution for our corporate network.  In the diagram you see below, R6 is our router that will be running zone-based firewall.  We want to group all our inside interfaces into a zone we call “inside” and our internet facing interface into a zone we call “outside.”

Before we get too excited with configuration, let’s talk about the basic theory here.  I also want to mention that you can find all of this information and a LOT more on the DoCD under configuration guides/security and VPN/securing the data plane. Additionally, there is a TON of stuff you could do with zone-based firewall.  It has specifically been stated in the Ask The Expert Forum from Cisco that the idea is to know the “basic configuration” of this technology so that is what we will focus on.

The Basic Concepts

Security Zone -

A Security zone is a group of interfaces to which a policy can be applied. In our example we have an “inside” zone and an “outside” zone. By default, traffic flows freely between interfaces in the same zone. Another huge thing to remember is that when an interface is a member of a zone, all traffic to and from that interface is dropped by default.  To make traffic pass between zones, we need to create a zone-pair and a policy for that zone-pair. The exception to this rule is traffic going to or coming from the router itself.  This traffic will pass by default.

Zone-Pair –

A zone-pair allows you to specify a uni-directional firewall policy between two zones.  This part of how we make things flow between our different zones.  We define zone-pairs that tell us what the source and destination zone is (for instance “inside” to “outside” or “outside” to “inside”).  If you want traffic to flow from one zone to another, you need a zone-pair and a policy applied to that zone-pair.

Zone Policy –

A zone policy defines what we allow or deny to go between zones.  It is very much like MQC in the configuration, with some added words.  Instead of class-maps we have “class-map type inspect” and instead of policy-maps we have “policy-map type inspect”.  For actions in our policy-maps we have “inspect”, “pass” and “drop.”  Pass and drop are pretty self explanatory, but “inspect” works just like traditional CBAC – we inspect traffic on a certain protocol, and allow the return traffic by default.  With our class-map type inspect maps we can actually drill very deep into protocols and do things all the way up to layer 7 (deep packet inspection) if we choose to, or we can keep it simple and just inspect based on layer 3 and layer 4 information.

The Configurations

Ok, enough theory let’s get our hands dirty on some real gear!!! Like I said, pretty much everything in this example will be done on R6 because it is serving as our zone-based firewall.

Step 1: Define The Zones

Here we define the names of our zones, and we put our various interfaces into the zones.  We will put fa0/0 into the zone we called “outside” and the others into the zone we call “inside.”

R6(config)#zone security inside
R6(config)#zone security outside
R6(config)#int fa0/0
R6(config-if)#zone-member security outside
R6(config)#int s0/1/0
R6(config-if)#zone-member security inside
R6(config)#int s0/2/0
R6(config-if)#zone-member security inside
R6(config)#int s0/2/1
R6(config-if)#zone-member security inside

Step 2: Define The Zone-Pairs

For this example, we will create a single zone-pair for traffic coming from inside our network and destined for anything outside our network.  Here I create a zone-pair called “inside-to-outside”.  The source zone will be the “inside” zone and the destination will the the “outside” zone.

R6(config)#zone-pair security inside-to-outside source inside destination outside

Step 3: Define The Policy

Awesome! So we have defined our zones, we have placed interfaces into the zones, and we have setup a zone-pair.  Now we need to decide what we actually want to do.  Let’s say that we only want to allow our corporate network users to communicate using HTTP, HTTPS, telnet, SSH, SMTP, POP3, and ICMP to the outside world.  First, we make a class-map type inspect…

R6

class-map type inspect match-any allowed
match protocol telnet
match protocol ssh
match protocol icmp
match protocol http
match protocol https
match protocol smtp
match protocol pop3

Cool, that’s done.  Now we need to decide what to do about this traffic we are matching.  We need a policy-map type inspect…we will call our policy fw-policy.

policy-map type inspect fw-policy
class type inspect allowed
inspect

Step 4: Apply The Policy

Similarly to how we need to apply QoS policies to interfaces, we need to apply our zone-based firewall policy to a zone-pair.

R6(config)#zone-pair security inside-to-outside
R6(config-sec-zone-pair)#service-policy type inspect fw-policy

That is basically it!  Let’s do some verification and testing.  Right now we have a loopback address setup inside our corporate network of 1.1.1.1 that all the routers know about.  Additionally, R6 and R7 have 6.6.6.6 and 7.7.7.7 respectively.

R6#show zone security
zone self
Description: System defined zone
zone inside
Member Interfaces:
Loopback1
Serial0/1/0
Serial0/2/0
Serial0/2/1
zone outside
Member Interfaces:
FastEthernet0/0
R6#show zone-pair security
Zone-pair name inside-to-outside
Source-Zone inside  Destination-Zone outside
service-policy fw-policy
R6#show class-map type inspect allowed
Class Map type inspect match-any allowed (id 5)
Match protocol telnet
Match protocol ssh
Match protocol icmp
Match protocol http
Match protocol https
Match protocol smtp
Match protocol pop3
R6#show policy-map type inspect fw-policy
Policy Map type inspect fw-policy
Class allowed
Inspect
Class class-default
Drop
From R1 (On the other side of our corporate "cloud") let's ping R7.
R1(config)#do ping 7.7.7.7
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.7, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/45/48 ms

Sweet! Exactly as we expected.  The packets from INSIDE our corporate network hit the firewall, and because the packets are ICMP they get inspected at R6 and move on to R7.  When R7 replies with an ICMP echo-reply R6 knows to allow the return traffic.  We can see this on R6 if we look at our policy counters.

R6(config-if)#do sh policy-map type inspect zone-pair
policy exists on zp inside-to-outside  ß Output truncated
Zone-pair: inside-to-outside
Service-policy inspect : fw-policy
Class-map: allowed (match-any)
Match: protocol telnet
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol ssh
0 packets, 0 bytes
30 second rate 0 bps
Match: protocol icmp
1 packets, 80 bytes
 30 second rate 0 bps
 

If we were to try to ping R1 from R7 however, things would be a bit different…

R7(config-if)#do sh ip route | i 1.1.1.1
D EX    1.1.1.1 [170/2562816] via 141.41.67.6, 00:03:46, FastEthernet0/0
R7(config-if)#do ping 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

As you see, the ping from R7 to R1 failed.  Why?  Well, for one we did not even define any kind of zone-pair for traffic going from the outside zone to the inside zone, which is what is happening here.  Secondly, had we defined a zone-pair we would have had to allow the traffic in a policy.  If we tried similar tests to/from R6 itself, we would see success as the default is to allow anything to/from a special zone called zone “self.”

So that is it for basic zone-based firewalls!  Like I said, you can do much more with it and there are plenty of options to tweak.  For the gory details on other options, check out the command reference and config guide.  However, as stated the ask the expert forum has said we should know basic configuration.  Anything else we should be able to find if needed.  I hope this was useful for you guys, and I’ll talk to you all soon!

Joe Astorino – CCIE #24347

IOS Zone-Based Firewall Overview for CCIE Routing and Switching 4.0 Candidates, 5.0 out of 5 based on 1 rating

Tags: ccie lab, CCIE R&S 4.0 Lab, CCIE Training, CCIE Workbook, IOS Zone-Based Firewalls, ipexpert, Joe Astorino