In the previous article, we talked about the Cisco IOS Zone-based policy firewall (ZFW) and how to configure zones, zone pairs and inspection policies. In this post, we will continue where we left off and talk more about the self-zone and also learn how to use the Cisco Configuration Professional tool to configure and verify Cisco IOS ZFW.

CCNA Training – Resources (Intense)

We will use the same network diagram as the first article, as shown below.

Cisco IOS ZFW Self-Zone

We mentioned the self-zone briefly in the previous article and said that this is the zone that handles all traffic destined to, or originating from, the router. We also said that by default, this zone is not subject to the default deny that exists among inter-zone communication. Therefore, the self-zone is not restricted in any manner by default. Let’s confirm this by opening a telnet session to R_Main from R_outside.

As you can see, R_outside can connect to R_Main because there are no restrictions by default. But what if we want to apply restrictions? For example, we don’t want everyone from outside to be able to telnet into our firewall. Maybe we want to allow only SSH from outside. Also, we might like to drop ICMP packets from the outside zone to the router itself. So this is our policy, let’s implement it.

The steps are the same as we have seen in the previous article so I’ll go ahead and configure it now.

A few things to note here: the policies you can apply on the self-zone for stateful inspection are limited to TCP, UDP, ICMP and complex-protocol inspection for H.323. It means you can’t do stateful inspection for Application-level protocols like SSH or HTTP. What you can do however is match such protocols in an access-list and then match the corresponding protocol (TCP or UDP).

From the above configuration, I have created two class-maps: one to match traffic to be inspected and the other to match traffic to be dropped. I don’t necessarily need to match traffic to be dropped because they will be dropped by default (class-default class-map) but I want it to be dropped explicitly. Now let’s test it:

Notice how telnet failed but SSH went through. We can see these sessions (inspect/drop) in the inspect type policy map.

So we are good? Well, not quite. I’ll clear the counters on the zone-pairs so everything goes back to zero and then we will initiate a connection from R_Main to R_outside to see what happens.

Hmm, I cannot ping from R_Main to R_outisde. You might wonder what is happening since we only created a zone-pair for outside-to-self and not for self-to-outside. Let’s show policy-map type inspect zone-pair:

Because of the way we created our class-map by matching ICMP protocol and not specifying any direction using an ACL, we can see that we are getting hit counts on the ICMP traffic. But it’s not the outgoing traffic that has a problem; it’s the return traffic. Debugging ICMP on R_outside let’s us see that it is indeed getting the packets and replying but the traffic is being dropped.

Perhaps, if we had been more specific in our ACL, maybe this wouldn’t have happened? Well, let’s also dispel that thought now. I will configure the class-maps to be more specific: use ACLs to match the source (any) and destination (router interface IP addresses). I have also created class-maps to match telnet traffic and ICMP traffic separately. I have applied drop action to them in the policy map as shown below.

After clearing the zone-pair counters again, this is what the show policy-map looks like:

Now let’s test our ICMP traffic again.

The ping still fails. Let’s find out why it failed this time.

Notice that even though the traffic does not match our ICMP class-map, it matches the class-default class-map. Remember what the class-default class map does? Yes, it matches all traffic that is not explicitly matched by any user-defined inspect type class map.

So what are our options? You might say we should override the default ‘drop’ action on the class-default and change it to ‘pass’. But think for a moment about what that will do. It will configure a pass action even for traffic originating from the outside zone that is not explicitly matched in any inspect type class-map.

In our scenario, we have configured class-maps for SSH, Telnet and ICMP. It means HTTP traffic is not explicitly configured so let’s test with that.

View the policy-map and notice that the packet count has increased on the class-default class-map.

This means that HTTP is being blocked because of the default drop action on the class-default class-map. Now let’s change that action to pass.

Ping from R_Main to R_outside again and see that the ping succeeds.

But what have we done? Let’s try our HTTP connection from R_outside to R_Main again.

As you can see, the HTTP connection goes through. We have effectively opened up our firewall to the networks we were trying to protect against in the first place. If you are thinking at this point that using ‘inspect’ instead of ‘pass’ will work, stop thinking that. It won’t. Inspect is basically the same as ‘pass’ but it keeps state information. In short, you will be keeping track of stateful information for attack traffic. That’s even worse because you will be using more resources.

Now that we know that option is not secure, what other options do we have? Remember this policy has been configured on the outside-to-self-zone pair. Something to note here is that communication between the self-zone and other zones are not affected and still operate in the default allow mode. The best option is to configure another zone-pair with the self-zone as the source and the outside zone as the destination. On the zone-pair, we can then inspect all traffic that are originating from the router itself and allow return traffic back.

First, we will restore the default drop action on the class-default class-map in the outside-to-self-zone pair.

Now we can configure a self-to-outside-zone pair, match the protocols in the class-map, and apply the inspect option in the policy map.

Notice the match-any option on the class-map to match ANY of the protocols rather than all. If you match all, then the only traffic that will be matched by the class-map is one that uses TCP, UDP, ICMP and H.323. If you see that kind of traffic on your network, just shut down and go home :D. Now if we initiate our ping, it should go through.

For completeness sake, if you are running a dynamic routing protocol, you may want to make sure IP routing is not affected by your configuration, so create an ACL to match your dynamic routing protocol, match it in an inspect type class-map and then apply the ‘pass’ action to it.

We can wrap up this subtopic on the Cisco IOS ZFW self-zone here. Remember the points to note: there’s a default allow traffic flow from/to the self-zone from all other zones; if you create a policy altering that default policy, you have to think of the ramifications. You should also make sure that IP routing is not broken if using routing protocols.

Configuring Cisco IOS ZFW using the Cisco Configuration Professional Tool

This section is most useful for those studying for the CCNA Security Certification exam. We will create a simpler version of a network and walk through the Cisco Configuration Professional (CCP) Tool.

The only configurations on the routers are basic connectivity settings. Firewall_Rtr is also set up to allow CCP connection. The inside host can ping the Outside_Rtr and vice versa.

The diagram above shows the welcome screen of the CCP tool. You will notice the Firewall_Rtr there and we can begin configuration. We should normally first determine a security policy but with the CCP tool, there are some pre-configured security policies we can use.

To begin configuration, select the “Configure” button on the top left corner of the CCP Tool in your web browser. If you have more than one device in your CCP tool, also select the one you want to configure from the “Select Community Member” dropdown.

You then navigate using the tree structure on the left hand pane. The part we are interested in is Security ยป Firewall. Under the Firewall folder, there’s a Firewall page and also Firewall Components folder which we will look at later. For now, select the Firewall page.

The Firewall page comes up with two options as shown below: Basic Firewall and Advanced Firewall. Notice that with the Basic Firewall wizard, you can only configure one outside zone and there’s no option for other zones (like DMZ). You will need the Advanced Firewall wizard for that. Also, you will need to use the Advanced Firewall wizard if you have specific security policies that differ from the preconfigured ones as we will see. The Basic Firewall wizard works for us in our scenario.

You are also given the option of configuring CBAC with the “Switch to Classic Firewall” link. Click the “Launch the selected task” button and a screen pops up giving details about the Basic Firewall wizard.

Click Next. Now we are asked to select our trusted and untrusted interfaces. From our setup, Fa0/0 is the trusted interface and Fa0/1 is the untrusted interface.

After clicking Next, if your router supports Call Manager Express (CME), CCP will present you with a warning dialog asking if you want to allow voice traffic through. Clicking Yes means that additional policies will be created for voice traffic. Also, CCP warns that you cannot launch the CCP Tool from the untrusted interface after you configure the firewall. If you need to do that, you can check the “Allow secure Cisco CP access from outside interfaces” options. We don’t need that in our case.

The CCP Tool has three pre-configured application security policies: High Security (the strictest, Deny IM and peer-to-peer traffic, inspect HTTP and email traffic and drop non-compliant traffic, generic TCP and UDP inspection), Medium Security (inspect IM and peer-to-peer traffic, inspect HTTP and email traffic, generic TCP and UDP inspection) and Low Security (least strict, generic TCP and UDP inspection).

The main difference between High Security and Medium Security is that the former is more restrictive and drops offending traffic while the latter tracks these applications. The CCP tool also gives you the option of previewing the commands. Let’s go with Medium Security.

Moving on, if you don’t have a DNS server configured on your router, CCP will ask for these details.

Clicking Next brings you to the end of the configuration where you are presented with a summary of the settings you made. This summary is in High-level language (understandable; not CLI commands). You may decide to go back and make changes as necessary.

When you click on the Finish button, the commands are shown as they will be written to the router. Although you cannot edit these commands in CCP, you may decide to save it to a file, edit it as required, and then paste it into the configuration of your router. In our case, we will deliver the commands to the router by clicking the Deliver button.

Once the commands have been successfully delivered, you get a confirmation dialog and also an information dialog box telling you that you have successfully configured the firewall.

The CCP then presents you with the “Edit Firewall Policy” tab that contains the firewall policies configured and allows adding, editing and deleting of policies.

You can view/add/edit/delete the zones and zone-pairs of the firewall from the Firewall Components folder on the left-hand navigation pane.

We can verify that our policies are working as required by pinging from the inside host to the Outside_Rtr. This is because ICMP traffic is inspected from inside zone to outside zone (you can check the configuration; it is matched under the ccp-cls-insp-traffic class-map).

If we check the policy-map applied to the zone-pair, we will see the ICMP traffic being matched.

Also, our security policy denies traffic originating from the outside to the self-zone as shown from the CCP snippet below:

This means that a ping from the Outside_Rtr to the Firewall_Rtr should fail.

…And it does. Remember to save your running configuration to start-up configuration if you didn’t select the option when CCP delivered the commands.

Summary

This brings us to the end of the Cisco IOS ZFW. These articles (part 1 and this one) have covered deep aspects of the technology that are not necessary to know for the CCNA Security Certification exam (indeed, some are CCIE-level knowledge) but presenting it this way helps form a well-rounded knowledge for you.

In the next article, we will move to Cisco’s standalone firewall appliance, the Cisco Adaptive Security Appliance (ASA). That should be fun.

Reference and Further Reading