Having a policy or a plan in place first is a good idea before you configure anything. Remember that the policy you implement on the firewall is supposed to reflect the business needs of the company.


We use the same topology as shown the earlier article.


Figure 1: Topology for ZBF Configuration




In this demonstration we are going to configure Zone pairs between the Inside and Outside Zones.


Before we go any further, I want to remind you that the configuration includes the following ZBF components:

§  Zones


§  Interfaces that are members of zones


§  Class maps that identify traffic


§  Policy maps that use class maps to identify traffic and then specify the actions which should take place


§  Zone pairs, which identify a unidirectional traffic flow, beginning from devices in one zone and being routed out an interface in a second zone


§  Service policy, which associates a policy map with a zone pair




COMMAND: Show class-map type inspect


This first command is used to classify traffic. But remember this is of type inspect. It shows all the traffic/applications that are going to be inspected and in what Class Maps they are in.


Figure 2: R3 show class-map type inspect


R3# show class-map type inspect




COMMAND: show policy-map type inspect zone-pair In-to-Out sessions


This command shows us any established sessions between the configure Zones for this Zone-Pair. Is also shows us the among of packets for each session.

Figure 3 show policy-map type inspect zone-pair In-to-Out sessions


R3# show policy-map type inspect zone-pair In-to-Out sessions








Cisco has implemented a stateful firewall feature set in Cisco IOS Software called zone-based firewall (ZBF). ZBF has a predecessor called the context-based access control (CBAC), which provided basic firewall features in Cisco IOS Software. ZBF allows the administrator to configure more granular firewall policies and introduces a default deny-all policy that prohibits traffic between firewall security zones until an explicit policy is configured.



This section examines the logic and structural components that make up the IOS-based zone-based firewall (ZBF).



With ZBFs, interfaces are placed into zones. Zones are created by the network administrator, using any naming convention that makes sense (although names such as inside, outside, and demilitarized zone [DMZ] are quite common). Then policies are specified as to what transit (user) traffic is allowed to be initiated (for example, from users on the inside destined to resources on the outside) and what action the firewall should take, such as inspection (which means to do stateful inspection of the traffic).


After traffic is inspected, the reply traffic is allowed back through the firewall because of the stateful filtering feature. The policies are implemented in a single direction (for example, inside to outside). If you want to allow initial traffic in both directions, you create two unidirectional policies for traffic to be allowed and inspected from the inside to the outside, and also from the outside to the inside. You implement two separate policies because the policies themselves are unidirectional.


One benefit of this modular approach is that after policies are in place, if you add additional interfaces, all you need to do is add those interfaces to existing zones, and your policies will automatically be in place.



The ZBF major features include the following:


§  Stateful inspection.


§  Application inspection.


§  Packet filtering.


§  URL filtering.


§  Transparent firewall (implementation method).


§  Support for virtual routing and forwarding (VRF).


§  Access control lists (ACL) are not required as a filtering method to implement the policy.



A zone is a logical area where devices with similar trust levels reside. For example, we could define a DMZ for devices in the DMZ in an organization. A zone is created by the administrator, and then interfaces can be assigned to zones. A zone can have one or more interfaces assigned to it. Any given interface can belong to only a single zone.


There is a default zone, called the self-zone, which is a logical zone. For any packets directed to the router directly (the destination IP represents the packet is for the router), the router automatically considers that traffic to be entering the self-zone. In addition, any traffic initiated by the router is considered as leaving the self-zone. By default, any traffic to or from the self-zone is allowed, but you can change this policy.


For the rest of the administrator-created zones, no traffic is allowed between interfaces in different zones. For interfaces that are members of the same zone, all traffic is permitted by default. So, here is the catch. If you want to allow traffic between two zones, such as between the inside zone (using interfaces facing the inside network) and the outside zone (interfaces facing the Internet or less trusted networks), you must create a policy for traffic between the two zones, and that is where a zone pair comes into play.


A zone pair, which is just a configuration on the router, is created identifying traffic sourced from a device in one zone and destined for a device in the second zone. The administrator then associates a set of rules (the policy) for this unidirectional zone pair, such as to inspect the traffic, and then applies that policy to the zone pair.


A small company, with users on the inside network, with the only other connection being the Internet, might want to create two zones, one for the inside and one for the outside. Then they would assign the inside interface to the inside zone, and the outside interface to the outside zone. Then, a policy could be created that specifies that traffic that is initiated from the inside users and going out to the Internet should be inspected and that information should be placed in the stateful database. A zone pair identifying traffic from the inside to the outside would have the policy applied to it, letting it know that the stateful inspection should be done.


A larger company that has a public-facing server may have three interfaces and three zones. The zones may be inside, outside, and DMZ. Compared to the small company, this medium-sized company creates an additional zone pair (from outside to DMZ) and then applies a policy to that zone pair to allow outside users to access the servers on the DMZ.


Figure 1 shows an example of a medium-sized company with a DMZ.


Figure 1: Topology for This ZBF Discussion










Various rules and options apply to firewalls, but this section covers the best practices for implementing a firewall.



We know that a firewall has a goal of separating two entities, and specifically controlling access between those two, such as two networks. Most commercial firewalls today can do packet filtering, application layer inspection, stateful packet filtering, NAT (in all its flavors), AAA functions, and perform virtual private network (VPN) services. A good example of a device such as this is the Cisco Adaptive Security Appliance (ASA), which is a dedicated firewall appliance.


Many of these same features can all be implemented in software and on top of an IOS router whose license, memory, and CPU can support it. A dedicated firewall appliance is considered more secure and therefore preferable to simply using a standalone router. A defense-in-depth approach suggests that perhaps you can run these features on more than a single device for the added levels of protection.



Here is a partial list of best practices for firewall deployment:

§  Firewalls should be placed at security boundaries, such as between two networks that have different levels of trust (from the perspective of your organization). An example is your internal network compared to the Internet.


§  Firewalls should be a primary security device, but not the only security device or security measure on the network.


§  A policy that starts with a deny all attitude and then specifically only permits traffic that is required is a better security posture than a default “permit all” attitude first and then denying traffic specifically not wanted.


§  Leverage the firewall feature that best suits the need. For example, if you know you have thousands of users who need access to the Internet, you can implement dynamic NAT/PAT for those users, along with stateful filtering and deny all inbound traffic coming from the Internet. This stops users on the Internet from initializing sessions to your users because of the deny on the outside interface. It allows users to access the Internet because you are performing NAT dynamically for them. Return traffic coming back from the Internet is allowed into the firewall because the stateful filtering is being done and the firewall can dynamically allow the return traffic. If you want to allow only specific users access to the Internet, you can additionally enable AAA.


§  Make sure that physical security controls and management access to the firewall devices, and the infrastructure that supports them such as cables and switches, are secure.


§  Have a regularly structured review process looking at the firewall logs. Many tools enable you to review syslog messages and look for anomalies and messages that might indicate a need for further investigation.


§  Practice change management for any configuration modification on the firewalls. AAA and proper documentation is important to have a record of which administrator made which changes and when they were made. The accounting records (or least a copy of these accounting records regarding changes) should be forwarded to at least one server that is out of the administrative control of the admin group. This protects the company from administrators who might make malicious (or innocent) changes to the configuration and cause a network problem and then try to delete the accounting logs.







As mentioned before, the appropriate method for implementing firewall rules is based on a policy. The policy (on paper) drives what the firewall configuration should be. You can implement many different types of access rules on a typical firewall.









The word firewall commonly describes systems or devices that are placed between a trusted and an untrusted network. A detailed understanding of how firewalls and their related technologies work is extremely important for all network security professionals. This knowledge helps you to configure and manage the security of your networks accurately and effectively.


Complete separation means that no network connectivity exists, which does not serve anyone very well. By allowing specific traffic through the firewall, you can implement a balance of the required connectivity and security. Traffic that may be identified as harmful is any traffic that compromises confidentiality, data integrity, or availability for the intended users.


Several network firewall solutions offer user and application policy enforcement that supplies protection for different types of security threats. These solutions often provide logging capabilities that enable the security administrators to identify, investigate, validate, and mitigate such threats.


In addition, several software applications can run on a system to protect only that host. These types of applications are known as personal firewalls. This section includes an overview of network and personal firewalls and their related technologies.



These concepts apply to IOS routers performing firewall services and to dedicated firewalls, which are purpose built for security. This section covers the concepts of firewalls, their strengths and weaknesses, and why they are used in specific situations. This information is used in nearly all networks where security is a concern.



A firewall is a concept that can be implemented by a single device, a group of devices, or even simply software running on a device such as a host or a server. As mentioned in the introduction, the function of a firewall primarily is to deny unwanted traffic from crossing the boundary of the firewall. For network traffic, this means that a firewall, in its basic form, could be implemented by the following:


§  A router or other Layer 3 forwarding device that has an access list or some other method used to filter traffic that is trying to go between two of its interfaces. This is the primary method that is implemented by an IOS router (using firewall features) or the Adaptive Security Appliance (ASA) firewall.


§  A switch that has two virtual LANs (VLAN) without any routing in between them, which would absolutely keep traffic from the two different networks separate (by not being able to have inter-VLAN communications).


§  Hosts or servers that are running software that prevents certain types of received traffic from being processed and controls which traffic can be sent. This is an example of a software firewall.



Here are some common properties that a good firewall should possess:


§  It must be resistant to attacks: If a firewall can be brought down or compromised to the point where it allows unwanted access, it thus fails to implement policy correctly. If the firewall is a victim of a denial-of-service (DoS) attack, to the point where it cannot provide normal access for users, that is also problem. If there is some vulnerability that an attacker can leverage with an exploit, thus enabling the attacker to modify the firewall configuration, which (of course) is also a problem.


§  Traffic between networks must be forced through the firewall: If multiple paths exist between network A and network B, and a firewall is controlling the traffic for these connections, but if there are alternative paths, the malicious traffic has the potential to avoid the firewall. So, if there are multiple paths, each of those paths should have the same firewall policy, and very likely will have the same firewall methodology at each point.


§  The firewall enforces the access control policy of the organization: Many times, unfortunately, the tail wags the dog as new firewalls are put into place. Rules are made for that firewall about traffic allowed through the firewall, and then as a result we document the policy. What ideally should happen is that a policy would be created on paper first that identifies the business requirements for which traffic should be allowed through the firewall, and then the rules should be created and applied to the firewall to enforce that policy, in that order.



Companies often make a significant investment in security, including the monies they spend on firewalls. Table 1 describes some of the items a firewall can help protect against.


Table 1: Protective Measures Provided by a Firewall


Reduces the Risk Of


Exposure of sensitive systems to untrusted individuals

By hiding most of the functionality of a host or network device, and permitting only the minimum required connectivity to that given system, the firewall reduces the exposure for that system. An example is only allowing web traffic to a specific IP address of a web server on your demilitarized zone (DMZ). Even if that web server has other services running, those services will not be available to users trying to access those services through the firewall.

Exploitation of protocol flaws

You can configure a firewall to inspect protocols to ensure compliance with the standards for that protocol at multiple layers of the protocol stack. It can also control the amount of time it will allow for a normal connection sequence before saying enough is enough. An example is only allowing a specific amount of time between a Domain Name System (DNS) request and the DNS reply.


Another example is the three-way handshake for TCP and the firewall only allowing so much time for that to complete between a client on one side of the firewall and a server being accessed on the other side of the firewall.

Unauthorized users

By using authentication methods, a firewall could control which user’s traffic is allowed through the firewall and be configured to block on all other traffic based on policy. For example, a firewall could leverage authentication, authorization, and accounting (AAA) services using its local configuration or an Access Control Server (ACS) server.

Malicious data

A firewall can detect and block malicious data, which would stop traffic from reaching the intended destination. This function could also be provided by an intrusion prevention system (IPS).


We could hope that by just purchasing a firewall and putting it in place all of our security issues can be put to rest. It should be understood that having a firewall and implementing correctly the policies for an organization are mitigation steps for reducing risk but do not completely eliminate risk. In addition, firewalls do have some limitations, as described in Table 2.




Table 2: Potential Firewall Limitations





Configuration mistakes have serious consequences.

The firewall’s job is to implement a policy. Based on a specific firewall you are dealing with, there are specific ways of implementing features such as access control lists (ACL), packet inspection, Network Address Translation (NAT), authentication, and so on. If the firewall rules are not implemented correctly, it might not do the job of implementing the policy as intended. It takes good technical gear and a good technical configuration on that gear for a successful policy implementation.

Not all network applications were written to survive going through the firewall.

If there is some type of custom application that simply will not work based on the combination of what the application is doing and what the current firewall rules in place are, the choice is to rewrite the application or make an exception in the firewall policy for the application.

Individuals who are forced to go through a firewall might try to engineer a way around it.

If there is a firewall policy, for example, that specifies no instant messaging file transfers are allowed, it might be possible for a user to circumvent that rule by getting creative. Options such as hiding the forbidden instant messaging file transfers inside of another protocol so that it looks like standard Hypertext Transfer Protocol (HTTP) or Hypertext Transfer Protocol Secure (HTTPS) is one thing they may try. This concept is called tunneling and can be done with a variety of protocols. A firewall that is capable of application layer inspection may be able to identify and prevent this type of malicious tunneling.

Latency being added by the firewall.

If a firewall is given a huge job of analyzing all the traffic, it might take a few milliseconds or more per packet for the analysis, and as a result some slight delay may be added to the overall network traffic delivery time.



Having just one single point of control/security for your entire network is not wise; if that one single point is misconfigured or fails to implement policy, the network is wide open to all the negative impact that the firewall is trying to prevent. One solution, which is really more an idea than a solution, is to use a defense-in-depth approach or what is known as a layered approach to security. In short, it cannot be just a single device protecting all of your network; it needs to be a team effort by nearly all the devices.


Another reason for this defense-in-depth approach is that not all attacks or malicious traffic is coming from outside networks. Much of it is sourced from internal devices that are already on the inside of the networks, such as end-user machines.


The goal of the firewall, or firewalls, is to reduce risk. It is part of an overall strategy for keeping the network up and keeping data reliable and available. Firewalls do not replace the need for other systems such as a backup or disaster recovery plans, which are additional pieces needed for overall business continuity.



Network-based firewalls provide key features used for perimeter security. The primary task of a network firewall is to deny or permit traffic that attempts to enter or leave the network based on explicit preconfigured policies and rules. Firewalls are often deployed in several other parts of the network to provide network segmentation within the corporate infrastructure and also in data centers. The processes used to allow or block traffic may include the following:


§  Simple packet-filtering techniques

§  Proxy servers (also known as application layer gateway [ALG])

§  NAT

§  Stateful inspection firewalls

§  Transparent firewalls

§  Next-generation context and application-aware firewalls










The network infrastructure primarily consists of routers and switches and their interconnecting cables. The infrastructure has to be healthy and functional if we want to be able to deliver network services reliably.


If we break a big problem down into smaller pieces, such as security and what an attacker might do, we can then focus on individual components and parts. By doing this, the work of implementing security becomes less daunting. That is what Network Foundation Protection (NFP) is all about: breaking the infrastructure down into smaller components and then systematically focusing on how to secure each of those components.



This section covers a strategic approach to hardening the network so that you can manage it and allow it to correctly maintain the routing tables, and most important, so that the network stays “healthy” and can forward traffic.



Many pieces and parts make up a network, and even one simple component that is not working can cause a failure of the network. If a network does not work, revenue and productivity suffer. In a nutshell, if you have vulnerabilities such as weak passwords (or no passwords), software vulnerabilities, or misconfigured devices, that leaves the door open to attackers.


The impact of a down network is huge; it normally affects the workforce and other systems and customers that rely on that network. The NFP framework is designed to assist you to logically group functions that occur on the network and then focus on specific security measures you can take with each of these functions.







For Cisco IOS routers and switches, the Network Foundation Protection (NFP) framework is broken down into three basic planes (also called sections/areas), each of which has a separate chapter dedicated to it later in this book:


Management plane:

This includes the protocols and traffic that an administrator uses between his workstation and the router or switch itself. An example is using a remote management protocol such as Secure Shell (SSH) to monitor or configure the router or switch. The management plane is listed here first because until the device is configured (which occurs in the management plane), the device will not be very functional in a network. If a failure occurs in the management plane, it may result in losing the ability to manage the network device altogether.


Control plane:

This includes protocols and traffic that the network devices use on their own without direct interaction from an administrator. An example is a routing protocol. A routing protocol can dynamically learn and share routing information that the router can then use to maintain an updated routing table. If a failure occurs in the control plane, a router might lose the capability to share or correctly learn dynamic routing information, and as a result might not have the routing intelligence to be able to route for the network.


Data plane:

This includes traffic that is being forwarded through the network (sometimes called transit traffic). An example is a user sending traffic from one part of the network to access a server in another part of the network; the data plane represents the traffic that is either being switched or forwarded by the network devices between clients and servers. A failure of some component in the data plane results in the customer’s traffic not being able to be forwarded. Other times, based on policy, you might want to deny specific types of traffic that is traversing the data plane.





Some interdependence exists between these three planes. For example, if the control plane fails, and the router does not know how to forward traffic, this scenario impacts the data plane because user traffic cannot be forwarded. Another example is a failure in the management plane that might allow an attacker to configure devices and as a result could cause both a control plane and data plane failure.


Table 1: Components of a Threat Control and Mitigation Strategy




Security Measures

Protection Objectives

Management Plane

Authentication, authorization,

accounting (AAA)


Authenticated Network Time

Protocol (NTP)


Secure Shell (SSH)


Secure Sockets Layer/Transport

Layer Security (SSL/TLS)


Protected syslog


Simple Network Management

Protocol Version 3 (SNMPv3)


Parser views

Authenticate and authorize any administrators. Protect time synchronization by using authenticated NTP. Use only encrypted remote-access protocols such as SSH for CLI and SSL/TLS for GUI tools, and use secure versions of SNMP. If plaintext tools are used (such as syslog or Telnet), they should be protected by encryption protocols such as IPsec or should be used out of band (a separate network just for management traffic). A parser “view” is a way to limit what a specific individual, based on his role, can do on the router.

Control plane

Control Plane Policing (CoPP) and Control Plane Protection (CPPr)


Authenticated routing protocol Updates

The control plane tools can be implemented to limit the damage an attacker can attempt to implement directly at one of the router’s IP addresses (traffic addressed directly to the router, which the router must spend CPU resources to process).


Routing protocol updates should be authenticated to remove the possibility of an attacker manipulating routing tables by putting a rogue router running the same routing protocol on your network. The attacker could be doing reconnaissance to learn the routes, or the attacker could be attempting to manipulate the resulting data plane by changing the routing on the network.

Data plane

Access control lists (ACL)


Layer 2 controls, such as private VLANs, Spanning Tree Protocol (STP) guards


IOS IPS, zone-based firewall

ACLs, when applied as filters on interfaces, can control which traffic (transit traffic) is allowed on the data plane.


At Layer 2, by protecting the infrastructure there, you can avoid a rogue switch from becoming the root of your spanning tree, which would affect the data plane at Layer 2.


Firewall filtering and services can also control exactly what traffic is flowing through your network. An example is using an IOS zone-based firewall to implement policy about the data plane and what is allowed.


As you might have noticed, NFP is not a single feature but rather is a holistic approach that covers the three components (that is, planes) of the infrastructure, with recommendations about protecting each one using a suite of features that you can implement across your network.


When implementing the best practices described by NFP, does that mean your network is going to be up forever and not have any problems? Of course not. If the network is designed poorly, with no fault tolerance, for example, and a device fails (because of a mechanical or software failure or a physical problem or because cables were removed), if you do not have the failovers in place to continue to move traffic, your data plane is going to suffer. Other factors, such as lack of change control or an administrator accidentally putting in the incorrect configuration, are, of course, ongoing potential opportunities for the network to stop functioning.






Go to top