Welcome to this CCNA Security Certification series where we will be covering the syllabus as follows:

  • 1. Cisco Firewall Technologies – Cisco IOS ZFW, Cisco ASA
  • 2. Securing the control, data, and management plane; Syslog Reporting
  • 3. AAA on Cisco Devices
  • 4. Cisco IPS

Other topics on the exam syllabus have been covered or will be covered in other articles on this site. The articles in this series will be helpful not only for passing your examination but also for the real world. As such, these articles will be heavily based on practical examples, with some theoretical knowledge where needed. The CCNA Security certification exam expects that you are able to use and navigate through the Cisco Configuration Professional; therefore we will configure using both the CLI and the CCP tool.

CCNA Training – Resources (Intense)

CISCO FIREWALL TECHNOLOGIES

This is the first topic we will be dealing with in this series. There are three subtopics of consideration here: Cisco IOS Zone-based policy firewall (ZFW), Network Address Translation (NAT) and the Cisco Adaptive Security Appliance (ASA). Since NAT has been covered in another article, we will focus on the remaining two subtopics.

Cisco IOS Zone Based Policy Firewall

As you may be familiar with, Access Control Lists (ACLs) can be used for packet filtering and security restriction between interfaces. And if you are in the networking world, ACLs are a very important concept to understand. However, basic ACLs when used for packet filtering can be limited in their capability because they are stateless in nature. What do we mean by stateless? Let’s explain with a diagram.

The reason this happens is because the IOS device does not keep track of the session information when using ACLs for packet filtering. Simply put, once the traffic has passed through, the IOS device forgets about it. So when the web server replies to the internal host, the router sees it as a new session and effectively denies it. But what if we want the return traffic of communication that originated from the internal trusted side to be permitted? We need stateful inspection.

Reflexive ACLs are a way to make ACLs stateful, but this method is not scalable. So, Cisco uses CBAC- Context Based Access Control (also known as Classic Firewall) for this functionality. With CBAC, you still configure your normal ACLs but CBAC can automatically ‘punch holes’ in the ACLs to allow inspected traffic to return.

If CBAC was good, why then do we need Zone-based policy firewall? Well, CBAC still restricts inspection to interface-level. It means if you have three interfaces connecting to the outside network for example, you will have to configure ACLs on those interfaces individually. This is not granular enough and can be quite complex.

The Cisco IOS ZFW introduces the concept of zones in which inspection policies are applied per zone rather than per-interface. Interfaces only have to be added to the right zone and the policies will apply to all interfaces in that zone. Cisco says that this model is ‘easier-understood’. Well, I will tell you that it’s not ‘easier-configured’. However, once the concept is grasped, followed by a systematic process of configuration, you will be alright. Let’s talk about concepts that you need to understand before going into configuration.

Zone: A zone is a logical grouping of interfaces with similar functionality or features. Zones are used to establish boundaries; for example, you can’t just walk into the United Kingdom without going through the UKBA. In essence, the UKBA tells you that you are coming from another zone (your point of departure) into the UK which is their zone. By default, traffic from one zone to another is denied (there’s an exception of the self-zone which we would see later). However, traffic within zones is permitted by default.

Zone pair: We mentioned above that members of one zone cannot communicate with members in another zone by default. This is where zone pairs come in. Using zone pairs, the administrator can configure communication between pairs of zones, for example, the inside zone to the DMZ zone. It should be noted here that inspection policies applied to zone pairs are unidirectional, i.e. inside-to-DMZ is different from DMZ-to-inside. This is because zone pairs operate on a ‘Source-to-Destination’ basis. It’s all about where the traffic originated from and where it is going to. This should not be confused with the stateless nature of ACLs. The ZFW is stateful and would allow returning traffic as per the inspection policy. However, there has to be another to allow traffic to originate from the opposite direction.

Let us understand this concept before we move on. Assume you have two zones: inside and outside. Host-inside is on the inside and Host-outside is on the outside zone. Let’s say you configure a zone pair for INSIDE-TO-OUTSIDE in which you allow HTTP and SSH. Now the zone pair means the source = inside and the destination = outside. This means that Host-inside can open HTTP and SSH connections to Host-outside. Now if this is all you configured, then Host-outside cannot open HTTP and SSH connections to Host-inside. This is the unidirectional nature of ZFW. This only makes sense because you don’t want outside hosts having the same level of access to inside hosts as inside hosts have to outside hosts; else it defeats the entire purpose.

Self-Zone: The self-zone is a default, logical zone that matches all traffic directed to or originating from the router itself. The default ‘deny’ between zones does not apply to the self-zone. Therefore, all traffic from other zones sent to the router itself is permitted by default. Also, all traffic originating from the router to other zones is allowed. This default behaviour can be changed.

Configuration steps for Cisco IOS ZFW


The network diagram that we will be using is shown below: R_Main will be the router of focus on which we will configure the firewall; R_inside will be the inside router; R_outside will serve as the outside router; and R_dmz will be the DMZ router.The IP addresses are shown in the table. All the routers are running EIGRP for dynamic routing so they all have connectivity.

The diagram below which shows that R_outside has connectivity to all other devices signifies that there are no restrictions applied yet.

Security Policy

Let’s create a security policy that we want to apply which is really the first step in determining what to configure.

  • Three zones: Inside, Outside and DMZ.
  • Inside Users should be able to open all TCP services to the DMZ zone and also to the Outside Zone.
  • DMZ devices should be able to HTTP to the Outside. They should not be able to connect to the inside zone.
  • Outside users should be able to open HTTP and HTTPS connections to the DMZ. They should not be able to connect to the inside zone.

Step 1: Define Zones

This is done using the zone security<zone_name> command. That’s really all you need to configure, but you can optionally configure a description for each zone as shown below.

Step 2: Define zone pairs

At this point, you have to stop and think: how many zone pairs do we have to define? We determine this by looking at the security policy we defined above. At this point, we are not concerned with the communication protocols, only the zone-to-zone communication.

  • Inside should be able to connect to the DMZ and the Outside zone. Therefore, we have one zone-pair for inside to DMZ (let’s call it inside-to-dmz-zonepair) and another zone pair for Inside to Outside (let’s call it inside-to-outside-zonepair).
  • DMZ should be able to connect to the Outside zone. One zone-pair for DMZ to Outside (let’s call it dmz-to-outside-zonepair).
  • Outside should be able to connect to DMZ. Here you have to remember that just because we have a zone-pair configured for DMZ to Outside, it doesn’t mean we have one for Outside to DMZ. So let’s configure that and call it outside-to-dmz-zonepair.

So we have 4 zone pairs to configure. You configure this using the following command in global configuration mode: zone-pair security<zone-pair name>source<source zone>destination<destination zone>.

Step 3: Create Traffic matching profiles

This is the part where we talk about the communication protocols between zones. We use ACLs and class maps to match the IP addresses and protocols that will be matched. Think of it this way: You have your zones and your zone pairs. Now we want to define who can communicate with who and using what. Let’s take it step by step, also referring back to our security policy:

  • The first policy states: Inside Users should be able to open all TCP services to the DMZ zone and also to the Outside Zone.
    • Source: Inside users. Can match this using IP address (192.168.12.0/24, 22.22.22.22/32).
    • Destination 1: DMZ zone. Can also match the IP address of the DMZ servers (192.168.14.0/24, 44.44.44.44/32)
    • Destination 2: Outside zone. If Outside represents the Internet for example, you don’t know all the IP addresses on the Internet so you can match ‘any’.
    • Protocol: TCP

    It means we can create two ACLs: One to match Inside-to-DMZ traffic and another to match Inside-to-Outside traffic. There are different ways that you can do this: you can decide to match any address on the inside rather than specifying it in the source of the ACL; you can also create standard access-lists to match just source portions using the IP address of the DMZ. The end-goal is all that matters.

    In my configuration, I have created two ACLs: ACL_INSIDE-TO-OUTSIDE specifies the inside IP addresses as the source and the DMZ IP addresses as the destination. The second ACL, ACL_INSIDE-TO-OUTSIDE specifies the inside IP addresses as the source but uses ‘any’ for the destination since the addresses on the outside cannot be predetermined.

    ZFW’s uses a configuration policy language called the Cisco Policy Language (CPL). CPL has three main parts: Class-maps, Policy maps and Service policies. The inspect type class maps match traffic classes. These class-maps are similar to normal class-maps except that they have a type of ‘inspect’ i.e. class-map type inspect [match-any | match-all]<name>. They can match ACLs, protocols (e.g. TCP, HTTP) and other normal class-maps.

    A note on the match-all and match-any options: ‘match-any’ is like saying “match ANY of the conditions in the class map” while ‘match-all’ is the opposite as it means “match ALL of the conditions”. So one operates like the OR-operator (match-any) while the other operates like the AND-operator (match-all). If neither is specified, the default is match-all. Therefore we can read our CMAP-INSIDE-TO-OUTSIDE class-map as such: match the access-list that has name ACL_INSIDE-TO-OUTSIDE AND also match protocol TCP.

  • The 2nd policy states: DMZ devices should be able to HTTP to the Outside. They should not be able to connect to the inside zone. Using the same reasoning, the configuration will be:

  • The final policy states: Outside users should be able to open HTTP and HTTPS connections to the DMZ. They should not be able to connect to the inside zone. This one is a bit tricky because it involves matching two different protocols. It means we need to remember to specify the ‘match-any’ option.

    You will notice that we didn’t create any ACL for this. It means that this class map will inspect traffic from any IP address on the outside zone to any IP address on the DMZ zone.

Step 4: Define Policy actions

Now that we have matched our traffic to be inspected, what do we want to do with it? Using Policy maps (also of ‘inspect’ type), you can configure what actions – inspect, pass or drop – that should be applied to matching traffic. The ‘inspect’ action allows the traffic to go through and implements stateful inspection; the ‘pass’ allows the traffic through but is stateless; and, as you would have guessed, ‘drop’ discards the packet.

Every inspect type policy map has an implicit class-default class configured with the ‘drop’ action. The class-default class map is a system-defined class-map that matches all traffic that do not match any of the user-defined classes.

So we will define four inspect type policy maps to match the four inspect type class maps and apply the action we desire. In this example, we have configured ‘inspect’ for all of them, meaning we want stateful inspection.

Step 5: Assign policy maps to zone pairs

We can now attach our policy maps to the different zone pairs that we configured in step two. We do this by entering the service-policy type inspect <policy-map-name> command under the zone pair configuration.

Notice how our naming convention has helped us know what exactly we are referring to. When dealing with complex configurations such as this, especially when using different ACLs, class maps and policy maps, it is wise to use sensible naming conventions.

Step 6: Assign interfaces to zones

Until this step, we have only been configuring the ZFW policies and it has not taken effect yet because no interfaces have been assigned to any zones. You assign interfaces to zones by using the zone-member security <zone name> interface level configuration command.

Viewing the entire configuration

Whew! It’s been a very long configuration. Just before we test if our ZFW is working as expected, let’s view the entire configuration.

Verifying ZFW Configuration

Inside-to-DMZ communication: From our policy, all TCP services should be permitted from the inside zone to the DMZ zone. Telnet is TCP 23 so let’s try that.

We can verify this traffic match in the access-list.

Now, since we are only inspecting TCP, let’s try to ping from R_inside to R-dmz and see what happens.

This fails because ICMP is not under the protocols we permitted. Let’s see what is happening in the policy-map applied to the zone-pair.

You’d notice that the Telnet traffic is shown in the session information. You’d also notice that the ICMP traffic was caught under the class-default class map.

Inside-to-Outside communication: This can be verified in a similar manner.

DMZ-to-Outside communication: DMZ users should only be able to use HTTP (TCP port 80) to the outside users. We can simulate this by opening a Telnet session to port 80 on R_outside from R_dmz.

Now, if we try to Telnet to the default port 23, this should fail.

Outside-to-DMZ communication: Finally, let’s test this. Outside users should be able to open HTTP and HTTPS (443) connections to the DMZ.

Please note that to test using Telnet, the router should be listening on the ports you are trying to open a connection to. For HTTP, issue the ip http server command in global configuration mode. For HTTPS, issue ip http secure-server.

Summary

Let’s wrap this up with a summary. To configure ZFW on a Cisco Router, you need to define zones and zone pairs, create the traffic profile using inspect type class maps, assign the actions to be taken using inspect type policy maps, attach the policy maps to the zone pairs and then assign interfaces to zones.

Important commands to remember are:

In the next article, we will see how the Cisco Configuration Professional tool can be used to configure Cisco IOS ZFW. Till then, I wish you success in your studies.

Reference and Further Reading