As networks expanded and began handling sensitive business and personal data, the demand for stronger security measures led to the creation of the firewall. The term “firewall” originally referred to a physical barrier—typically made of stone or metal—designed to prevent the spread of fire between buildings. In networking, firewalls serve a similar purpose: they separate trusted, protected networks from untrusted or public networks, such as the internet, to prevent unauthorized access.
In the early days, network protection relied primarily on Access Control Lists (ACLs). These lists—standard, extended, numbered, or named—controlled traffic based on IP addresses and ports. While effective for basic filtering, ACLs lacked intelligence and required constant manual updates. As networks evolved, new firewall technologies emerged to address more complex threats.
Evolution of Firewall Technologies
By the late 1990s, stateful firewalls became the standard. These devices could track active sessions and make decisions based on the state and context of traffic. For example, stateful inspection ensured that only packets belonging to established, valid sessions were allowed through. Early Cisco implementations used “TCP established” ACL options and reflexive ACLs, later evolving into dynamic and time-based ACLs that provided temporary or scheduled access control.
Today’s firewalls have grown far beyond simple packet filters. Modern types include:
In modern network design, firewalls must be strategically placed to secure sensitive systems while still allowing necessary communication. The best designs balance protection and accessibility by layering firewall rules at the edge, core, and host levels.
Hands-On Learning
To reinforce these concepts, learners should practice configuring and testing real or simulated firewall technologies. In lab environments, students can use Cisco routers to explore:
Example configuration of a simple ZBF on a Cisco router:
! Define security zones zone security INSIDE zone security OUTSIDE ! Create a policy map for traffic inspection class-map type inspect match-any WEB-TRAFFIC match protocol http match protocol https policy-map type inspect INSIDE-TO-OUTSIDE class type inspect WEB-TRAFFIC inspect class class-default drop log ! Apply zones to interfaces zone-pair security IN-OUT source INSIDE destination OUTSIDE service-policy type inspect INSIDE-TO-OUTSIDE interface GigabitEthernet0/0 zone-member security OUTSIDE interface GigabitEthernet0/1 zone-member security INSIDE
Hands-on labs are available to guide learners through configuring ACLs, CBAC, and ZBF using both the command-line interface (CLI) and graphical tools. These exercises encourage real-world thinking about how to secure edge routers and internal resources effectively.
Access Control Lists (ACLs) remain a fundamental tool in network security, used to filter, permit, or deny traffic based on a set of defined conditions. ACLs help administrators enforce security policies, mitigate attacks, and control how packets traverse network interfaces. They can filter traffic at multiple layers of the OSI model, from Layer 2 (Data Link) through Layer 4 (Transport) and even Layer 7 (Application).
Understanding ACL Types and Evolution
Historically, ACLs were implemented as simple numbered lists that filtered traffic using Ethernet types or MAC addresses. For example, ACL numbers 200–299 were used for Ethernet-type filters, while ACLs numbered 700–799 filtered based on MAC addresses. Today, ACLs have evolved to focus primarily on IP traffic, using IPv4 or IPv6 addresses combined with TCP and UDP port numbers to classify and control packets with much greater precision.
Standard ACLs
Standard ACLs are the simplest type and filter packets solely based on the source IP address. They cannot inspect destination information or port numbers. They are best used close to the destination network to avoid unnecessarily filtering legitimate traffic.
R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255 R1(config)# access-list 10 deny any R1(config-if)# ip access-group 10 in
In this example, only packets sourced from the 192.168.10.0/24 network are permitted to enter the interface. All other traffic is implicitly denied.
Extended ACLs
Extended ACLs provide much greater control by filtering based on multiple fields: source and destination IP addresses, Layer 4 protocols (TCP, UDP, ICMP, etc.), and port numbers. They are typically placed close to the source of the traffic to minimize unnecessary network load.
R1(config)# access-list 101 permit tcp 192.168.10.0 0.0.0.255 any eq 443 R1(config)# access-list 101 deny tcp any any eq 21 R1(config)# access-list 101 permit ip any any R1(config-if)# ip access-group 101 in
This configuration allows HTTPS traffic (TCP/443) from the 192.168.10.0/24 network while denying FTP (TCP/21) from any source.
Named ACLs
To make ACL management easier, Cisco introduced named ACLs, which replace numeric identifiers with descriptive names. Named ACLs are more flexible: you can insert, delete, or reorder specific entries without recreating the entire list.
R1(config)# ip access-list extended SECURE-WEB R1(config-ext-nacl)# permit tcp 192.168.1.0 0.0.0.255 any eq 443 R1(config-ext-nacl)# deny ip any any log R1(config-ext-nacl)# exit R1(config-if)# ip access-group SECURE-WEB in
Named ACLs are ideal for dynamic environments where frequent policy updates are required. The no command can remove individual entries without deleting the entire ACL.
no
VTY Line Access Control
ACLs can also be applied to virtual terminal (VTY) lines to restrict remote administrative access via SSH or Telnet. Standard ACLs are typically used for this purpose.
R1(config)# ip access-list standard ADMIN-ACCESS R1(config-std-nacl)# permit 192.168.100.0 0.0.0.255 R1(config)# line vty 0 4 R1(config-line)# access-class ADMIN-ACCESS in R1(config-line)# transport input ssh
This configuration restricts SSH access to the router to devices within the 192.168.100.0/24 subnet.
Logging and Monitoring ACL Activity
When troubleshooting or investigating attacks, administrators can enable logging within ACL statements. The log keyword records matching packets to the router’s console, buffer, or syslog server. However, logging consumes additional CPU resources and should only be used temporarily during diagnostics.
log
R1(config)# access-list 105 permit tcp any any eq 22 log
Each log entry includes action (permit or deny), protocol, source and destination addresses, and port numbers. Logs are generated for the first match and every five minutes thereafter while traffic continues to match the rule.
Best Practices and Common Pitfalls
permit
in
out
Example Using Sequence Numbers:
R1(config)# ip access-list extended FIREWALL-IN R1(config-ext-nacl)# 10 permit tcp 10.0.0.0 0.0.0.255 any eq 443 R1(config-ext-nacl)# 20 deny ip any any log R1(config-ext-nacl)# 15 permit tcp 10.0.0.0 0.0.0.255 any eq 80
Here, the new statement numbered 15 is inserted between 10 and 20 without re-creating the ACL.
Conclusion
ACLs remain a cornerstone of Cisco network security. They provide a flexible, efficient, and powerful method for filtering traffic and enforcing security policies. While more advanced technologies such as Zone-Based Firewalls (ZBF) and Next-Generation Firewalls (NGFW) offer deep inspection capabilities, ACLs continue to play a vital role at the edge and core of modern enterprise networks.
When designing an access control strategy, the choice between using a standard or extended ACL depends on how granular the filtering needs to be. Standard ACLs filter traffic based only on the source IP address, while extended ACLs provide finer control, allowing filtering by protocols, ports, and destination addresses.
Example 1 – Blocking a Subnet with a Standard ACL
Suppose all traffic from subnet 172.16.4.0/24 must be denied access to another subnet, while all other traffic should pass. A standard ACL can easily achieve this when applied outbound on an interface:
172.16.4.0/24
R1(config)# access-list 1 deny 172.16.4.0 0.0.0.255 R1(config)# access-list 1 permit any R1(config)# interface FastEthernet0/0 R1(config-if)# ip access-group 1 out
This configuration denies traffic from subnet 172.16.4.0/24 from leaving interface Fa0/0, effectively blocking its access to other networks.
Fa0/0
Command Breakdown:
0.0.0.255
Example 2 – Blocking FTP Traffic with an Extended ACL
Extended ACLs allow filtering based on more specific criteria, such as protocols and ports. Consider a scenario where FTP traffic from subnet 172.16.4.0/24 must be blocked from reaching 172.16.3.0/24 while all other traffic remains permitted:
172.16.3.0/24
R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 21 R1(config)# access-list 101 deny tcp 172.16.4.0 0.0.0.255 172.16.3.0 0.0.0.255 eq 20 R1(config)# access-list 101 permit ip any any R1(config)# interface FastEthernet0/1 R1(config-if)# ip access-group 101 in
In this configuration:
permit ip any any
ACL Placement Considerations:
Example Behavior:
With the above ACL applied inbound on Fa0/1, all FTP traffic from 172.16.4.0/24 destined for 172.16.3.0/24 will be dropped immediately upon entering the router. However, FTP sessions from 172.16.4.0 to other networks are unaffected and will be permitted.
Fa0/1
172.16.4.0
Key Takeaway: Always remember that ACLs are processed top-down and end with an implicit deny all. For proper functionality, ensure a final permit ip any any statement is included when other traffic should pass unfiltered.
deny all
When configuring Access Control Lists (ACLs), understanding the direction of traffic flow through the router is essential. Traffic direction determines whether an ACL inspects packets entering or leaving an interface.
Inbound (Ingress) Traffic: Inbound traffic refers to packets entering a router interface before being routed to their destination. Inbound ACLs filter traffic prior to any routing table lookups, making them efficient for early packet control.
Outbound (Egress) Traffic: Outbound traffic refers to packets that have already been processed by the router’s routing table and are about to exit an interface. Outbound ACLs are applied after the routing decision is made and before the packet leaves the interface.
ACLs can track return traffic dynamically using features such as reflexive ACLs or stateful firewalls like Zone-Based Policy Firewalls (ZBF), which maintain session tables to allow legitimate return traffic automatically.
ACL Placement Guidelines
Most modern networks use Extended ACLs to balance access control with resource efficiency. For instance, administrators may permit business-critical HTTPS traffic (TCP port 443) while blocking insecure or nonessential protocols.
Using Tools to Identify Open Ports
Before defining ACL rules, administrators often use network scanners like Nmap to identify open ports on target devices. For example, if an ACL blocks POP3 (TCP port 110) from external access but allows it internally, an Nmap scan will show port 110 as open when performed from within the LAN, but filtered or closed when scanned externally.
Verifying ACL Configuration
Once ACLs are applied, verification ensures that desired traffic passes and unwanted traffic is blocked. Two useful Cisco IOS commands include:
R1# show ip access-lists
This displays all ACLs and the number of packets matching each access control entry (ACE). Packet counts confirm whether ACL rules are functioning as expected.
R1# show running-config | include access-group
This command identifies which interfaces have ACLs applied and in which direction (inbound or outbound).
Logging Considerations
While the log option can be used to monitor packets that match ACL entries in real time, it can impose a heavy processing load on routers and switches. Logging should be enabled temporarily for troubleshooting or validation, then disabled once the configuration has been verified.
Example Verification Workflow:
R1# show ip access-lists R1# show running-config | section interface R1# debug ip packet detail R1# undebug all
Using this workflow, administrators can view ACL hit counts, confirm interface bindings, and perform targeted debugging—then quickly disable debugging to restore performance.
Key Takeaway: Effective ACL design relies on correctly identifying traffic direction, strategic placement, and proper verification. Misplaced ACLs or unchecked logging can degrade performance or inadvertently block critical business services.
In earlier Cisco IOS environments, Cisco Security Device Manager (SDM) provided a graphical interface for configuring routers, including Standard and Extended Access Control Lists (ACLs). Although SDM simplified complex configurations for administrators, it has since become a legacy tool. Cisco SDM has been replaced by Cisco Configuration Professional (CCP) and, more recently, by Cisco DNA Center and web-based GUIs found on modern ISR and Catalyst devices.
Nevertheless, understanding SDM remains valuable for legacy networks and certification purposes, as many older routers still support SDM-based configurations.
Legacy SDM Interface Overview
SDM consisted of two main frames:
ACL configuration was accessed via Configure > Additional Tasks > ACL Editor. Administrators could create, edit, and apply access rules through the SDM wizard interface.
Types of Rules in Cisco SDM
Within SDM, ACLs were grouped under several functional categories:
Creating Standard ACLs Using Cisco SDM (Legacy Procedure)
Applying ACLs to Interfaces
To view the actual IOS commands SDM generates, go to View > Running Config from the menu bar. This allows administrators to understand the underlying CLI structure that SDM executes on the router.
Modern Alternatives to SDM
Example CLI Equivalent of a Standard ACL Configuration
R1(config)# access-list 10 permit 192.168.10.0 0.0.0.255 R1(config)# access-list 10 deny any R1(config)# interface GigabitEthernet0/1 R1(config-if)# ip access-group 10 in
Key Takeaway: While Cisco SDM is now considered obsolete, understanding its workflow is useful for managing legacy devices. Modern network management emphasizes centralized, API-driven configuration and automation tools that build upon the foundational concepts introduced by SDM.
Dynamic Access Control Lists (ACLs), also known as lock-and-key ACLs, were introduced in Cisco IOS around 1996 — before ACL logging and reflexive ACLs became standard features. They represented one of the earliest forms of on-demand, user-authenticated access control on Cisco routers. Dynamic ACLs apply exclusively to IP traffic and rely on Telnet or SSH authentication combined with Extended ACLs to grant temporary access through a router or firewall.
How Dynamic ACLs Work
By default, an extended ACL is configured to deny traffic through the router. When an external user wants to gain access, they initiate a Telnet or SSH session to the router. Once authenticated—either through a local username/password or an AAA server (RADIUS or TACACS+)—the router terminates the session and dynamically inserts a new, temporary ACL entry into the access list. This entry allows the authenticated user’s IP traffic for a specific duration, controlled by idle and absolute timeout values.
This process effectively creates a temporary “hole” in the firewall—only for authenticated and approved users—and closes it automatically when the timer expires or the user disconnects.
Why Use Dynamic ACLs?
Dynamic ACLs are particularly useful for:
Advantages of Dynamic ACLs
Dynamic ACL Workflow
username
Configuration Steps
Step 1 – Create an Extended ACL
Start by defining an extended ACL that initially blocks traffic but allows Telnet or SSH connections used for authentication. A placeholder entry will be dynamically updated once users authenticate.
Router(config)# access-list 110 permit tcp any host 192.168.1.1 eq 22 Router(config)# access-list 110 dynamic remote_access timeout 10 permit ip any 192.168.10.0 0.0.0.255 Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip access-group 110 in
Step 2 – Configure Authentication
Define authentication using a local database or AAA server. For example:
Router(config)# username netadmin secret MySecurePass Router(config)# aaa new-model Router(config)# aaa authentication login default local
Step 3 – Enable Dynamic Authentication on VTY Lines
Enable lock-and-key authentication using the autocommand access-enable command on the vty lines:
autocommand access-enable
Router(config)# line vty 0 4 Router(config-line)# autocommand access-enable host timeout 5 Router(config-line)# login authentication default
This configuration forces authentication before dynamic ACL entries are created. The host keyword ensures that the user’s specific IP address replaces the any keyword in the ACL entry, allowing user-specific filtering. The timeout value defines the idle timeout—how long the ACL entry remains active without activity.
host
any
timeout
Timeouts in Dynamic ACLs
Example Combined Configuration
! Step 1 - Define dynamic ACL Router(config)# access-list 120 permit tcp any host 192.168.1.1 eq 22 Router(config)# access-list 120 dynamic remote_access timeout 15 permit ip any 192.168.10.0 0.0.0.255 Router(config)# interface GigabitEthernet0/0 Router(config-if)# ip access-group 120 in ! Step 2 - Configure authentication Router(config)# username guest secret Secure123 Router(config)# aaa new-model Router(config)# aaa authentication login default local ! Step 3 - Enable lock-and-key authentication Router(config)# line vty 0 4 Router(config-line)# login authentication default Router(config-line)# autocommand access-enable host timeout 5
How It Works:
Modern Context
While dynamic (lock-and-key) ACLs were groundbreaking in the mid-1990s, they are now largely considered legacy security mechanisms. Modern Cisco platforms use AAA-based authentication with downloadable ACLs (dACLs) from Cisco ISE or ACS servers. These dACLs provide the same dynamic access concept—authenticated, temporary, per-user access—but with centralized policy management and enhanced scalability.
Summary
Dynamic ACLs introduced the concept of authenticated, temporary access control—a precursor to modern network access control frameworks. While they’re rarely used in production networks today, understanding them provides foundational insight into how Cisco’s context-based firewalls and Identity-Based Networking Services (IBNS) evolved.
Time-based Access Control Lists (ACLs), introduced to Cisco IOS in 1998, extend the functionality of extended ACLs by allowing permit/deny actions to be enforced only during specified time periods. This enables administrators to control access to network resources based on time of day, day of week, or specific calendar dates.
Time-based ACLs are especially useful when a temporary firewall exception is needed but should not remain open indefinitely. Examples include:
How Time-Based ACLs Work
Time-based ACLs are built on extended ACLs. A time-range object is created and then referenced inside a permit or deny statement. IOS evaluates the ACL entry only when the router’s clock matches the defined time window.
time-range
Creating a Time Range
Each time range must have a unique name (no spaces, must begin with a letter). The time-range configuration mode supports two types of schedules: absolute (one-time event) and periodic (recurring schedule).
Router(config)# time-range RANGE_NAME Router(config-time-range)# absolute start-time start-date end-time end-date Router(config-time-range)# periodic day hh:mm to [day] hh:mm
Absolute Time Range — one-time period only.
15:00
07 July 2025
23:59 31 December 2035
Periodic Time Range — recurring schedule.
Supported keywords for repeating periods include:
The router’s system clock must be set accurately for time-based ACLs to work correctly (manual clock or NTP recommended).
Referencing Time Ranges in ACLs
A time range is activated by adding time-range NAME to an extended ACL entry:
time-range NAME
Router(config)# access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 443 time-range WORK_HOURS
The ACL entry is evaluated only when the router’s clock falls within the defined time window.
Configuration Example – Allow Internet Access Only During Lunch and After Work
Requirement: Employees should not access the Internet during normal business hours. Internet access should be permitted only during lunch (12:00–13:00) and again from 17:00–19:00.
R1(config)# time-range employee-time R1(config-time-range)# periodic weekdays 12:00 to 13:00 R1(config-time-range)# periodic weekdays 17:00 to 19:00 R1(config-time-range)# exit R1(config)# access-list 100 permit ip 192.168.1.0 0.0.0.255 any time-range employee-time R1(config)# access-list 100 deny ip any any R1(config)# interface FastEthernet0/1 R1(config-if)# ip access-group 100 in
Result:
Best Practices for Time-Based ACLs
Time-based ACLs remain useful today in environments that need scheduled access control without full firewall automation—though modern enterprise networks increasingly replace them with solutions such as dynamic downloadable ACLs (dACLs) from Cisco ISE and zero-trust identity policies.
Once an Access Control List (ACL) has been deployed, verification and troubleshooting are essential to ensure the ACL is filtering traffic as intended. Misconfigured ACLs can accidentally block legitimate traffic or unintentionally allow unauthorized access, so monitoring is a core security responsibility.
Viewing ACL Hit Counters
The primary verification method is the show access-lists command, which displays every ACL entry along with the number of packets that matched it. Each match counter reflects how many times traffic has been permitted or denied by that entry.
show access-lists
Router# show access-lists Router# show access-lists 100 Router# show access-lists BLOCK_FTP
Interpreting the output:
Using Debug for Real-Time Packet Inspection
For deeper troubleshooting, especially when packet filtering behaviors are unclear, use debug ip packet to observe traffic as it is processed by the router.
debug ip packet
Router# debug ip packet Router# debug ip packet 100 Router# debug ip packet 100 detail
Details and cautions:
Stop debugging output using:
Router# undebug all
Best Practices for ACL Verification
Even though there are only a few ACL verification commands, testing every ACL after deployment is critical. Proper validation prevents accidental service disruption and ensures the network remains protected against unauthorized access.
Access Control Lists (ACLs) remain one of the simplest and most effective first-line defenses in network security. When deployed properly, ACLs not only filter traffic — they actively mitigate attacks, block spoofed packets, protect key services, and limit malicious ICMP behavior.
Common Security Threats Addressed by ACLs
Blocking IP Spoofing
Most DoS attacks rely on spoofing. A router should never receive inbound packets containing internal or special-use source IP addresses. ACLs can immediately eliminate spoofed traffic by denying packets with forbidden source ranges.
Block inbound spoofed sources such as:
127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
224.0.0.0/4
Best practice also applies outbound:
If a packet leaves the network, its source IP must belong to the internal organization. All other source addresses should be denied.
! Drop spoofed inbound IPs ip access-list extended BLOCK-SPOOF deny ip 127.0.0.0 0.255.255.255 any deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any deny ip 224.0.0.0 15.255.255.255 any permit ip any any
Permitting Only Required Services Through the Firewall
Some protocols must be allowed through security boundaries — for example:
Routers may also require administrative access from approved IPs:
! Example — allow secure management ip access-list extended MGMT-ACCESS permit tcp host 203.0.113.10 any eq 22 ! SSH from NOC permit udp host 203.0.113.20 any eq 514 ! Syslog collector permit udp host 203.0.113.30 any eq 161 ! SNMP manager deny ip any any
Controlling ICMP for Security and Stability
ICMP plays two roles — attackers abuse it, but network devices also rely on it for troubleshooting and path management. A secure ACL approach blocks harmful ICMP messages while allowing operationally important ones.
Recommended ICMP allowed inbound:
Recommended ICMP allowed outbound:
All other ICMP messages should be blocked by default.
! Example ICMP control policy ip access-list extended ICMP-FILTER ! Inbound (from Internet) permit icmp any any echo-reply permit icmp any any source-quench permit icmp any any unreachable deny icmp any any ! Outbound permit icmp any any echo permit icmp any any parameter-problem permit icmp any any packet-too-big deny icmp any any
ACLs are powerful, but they are just one part of a secure perimeter. The next step in strengthening network defenses is exploring stateful firewalls, Zone-Based Firewall (ZBF), and Context-Based Access Control (CBAC), which build upon ACLs to provide deeper inspection and dynamic session awareness.
The term firewall originated long before computer networks existed. It described a fire-resistant barrier (usually stone or metal) that stopped flames from spreading between structures. The automotive and aviation industries later adopted the term for the partition that isolates the engine compartment from passengers. Today, the term has evolved again — a firewall in networking is a barrier that prevents unauthorized, malicious, or untrusted traffic from entering protected portions of a network.
In modern networks, a firewall is a system or collection of systems that enforces an access control policy between trusted and untrusted environments. A firewall may take many forms, including:
iptables
Regardless of scale or complexity, all firewalls share core characteristics:
1988 — Packet Filter Firewalls (Stateless) DEC introduced the first network firewall based on packet filtering. Individual packets were inspected using criteria such as source/destination IP, protocol, and port — then permitted or denied. These early firewalls were stateless, meaning they did not track whether packets belonged to an ongoing connection.
1989 — Stateful Firewalls AT&T Bell Labs pioneered the stateful firewall, which tracks active sessions. When a connection is established, temporary dynamic rules are created and removed when the session ends. Stateful inspection significantly improved protection against spoofing and DoS attacks by distinguishing legitimate return traffic from unsolicited traffic.
1990s onward — Dedicated Firewall Appliances Early firewalls ran as software on routers and servers. As traffic volumes increased, dedicated firewall appliances emerged to offload the CPU-intensive work of packet inspection. Today, organizations may deploy:
Modern Cisco ISR routers continue to support full stateful firewall capabilities, providing enterprise-grade protection for environments that don’t require a dedicated appliance.
Because of these risks, modern network security relies on defense-in-depth — combining firewalls with intrusion prevention, segmentation, endpoint security, strong authentication (Zero Trust), and continuous monitoring.
There is no single firewall type capable of solving every security challenge. The appropriate choice depends on:
A firewall system is often made up of multiple components, but the most recognizable function is traffic filtering — the selective permitting or denying of packets based on an organization’s security policy. Filtering can be implemented in several ways, which leads to different categories of firewalls. The most common types include:
Packet-filtering firewalls operate primarily at the Network Layer (Layer 3) but frequently enforce rules using Layer 4 protocol and port information. ACL-style logic determines whether a packet is permitted or denied based on:
These firewalls are sometimes called static filters because each packet is evaluated individually, without tracking whether it belongs to an active session. Despite their limitations, packet filters remain foundational — especially as part of router-based perimeter defenses.
Because services rely on specific ports, packet filters can be highly effective at limiting attack surfaces. For example, blocking outbound TCP port 25 on selected subnets prevents malware-infected workstations from attempting to send bulk spam or exfiltrate stolen data via SMTP.
Stateful firewalls are the most widely used firewall technology today. Instead of making decisions one packet at a time, a stateful firewall builds and maintains a state table that tracks connection information across all network interfaces. Each session is recorded in the table using metadata such as:
When a client inside the network initiates a connection, the stateful firewall records the session. When the external server responds, the packet is compared against the state table — legitimate return traffic is permitted automatically without requiring explicit ACL entries.
Modern stateful firewalls go even further, implementing protocol-aware support mechanisms. Examples include:
A potential drawback is that stateful inspection can expose internal IP addressing unless combined with NAT or proxy functions — which is why most commercial firewalls today blend stateful filtering + NAT + deep inspection into a single platform.
Cisco offers multiple firewall implementation paths, each suitable for different scale and budget requirements:
ASA was designed as a core component of Cisco’s Self-Defending Network model, providing multi-layer threat defense while maintaining ease of deployment and lower operational costs. ASA remains widely deployed, although many organizations are now transitioning toward Next-Generation Firewalls (NGFWs) with features like SSL decryption, identity-aware policy, and machine-learning-driven threat detection.
Firewalls are not one-size-fits-all. Selecting the correct solution involves a balance of:
No matter which platform is selected, successful deployment depends on thoughtful security architecture — including segmentation, redundancy, logging/monitoring, and policy governance.
In network security, the term demilitarized zone (DMZ) refers to a portion of a network that is isolated by a firewall or a set of firewalls. Borrowed from the military concept of a neutral buffer zone, a DMZ limits where untrusted devices can communicate while protecting trusted internal resources.
A DMZ helps define which parts of a network are trusted and which are untrusted. Firewall design is centered around controlling traffic at interfaces — determining whether to permit or deny packets based on their source, destination, and type of traffic.
Some deployments are simple, consisting of two firewall interfaces:
In this model, outbound traffic from the inside is usually allowed to the outside with few restrictions. Inbound traffic from the outside is normally blocked entirely or allowed only in very specific cases. Return traffic associated with legitimate outbound connections is allowed back in.
More advanced topologies introduce a third interface:
Common DMZ services include email, DNS, HTTP, and HTTPS servers. Typical traffic rules in a three-interface design:
A layered defense combines multiple firewalls and filtering methods to protect both the perimeter and sensitive internal segments. For example, a screened subnet configuration may include:
Only traffic that successfully passes each layer is permitted to reach internal hosts. A bastion host is specifically hardened for this purpose and is commonly located in the DMZ.
Although layered firewall architectures are powerful, they do not guarantee complete security. Additional considerations include:
A DMZ and layered firewall approach is effective only when combined with monitoring, patching, endpoint protection, and informed users.
Security professionals must define and maintain a written firewall policy. A good starting point includes:
A Cisco router running Cisco IOS Firewall can operate as both a router and a firewall. When two firewall devices are deployed, they can be connected by a LAN segment that serves as the DMZ. This setup provides redundancy for public access to DMZ resources and isolates internal networks from direct exposure.
Context-Based Access Control (CBAC) is a major component of the legacy Cisco IOS Firewall feature set. Unlike basic ACLs, CBAC performs stateful inspection at the Application Layer, allowing the firewall to understand how protocols behave, track active sessions, and dynamically permit return traffic. This enables CBAC to support complex and multi-channel applications such as FTP, H.323, and multimedia protocols, which standard ACLs cannot properly secure.
CBAC can also parse and translate NAT/PAT-embedded addressing information, helping ensure multi-channel and dynamic protocols continue functioning after address translation. In addition, CBAC can block peer-to-peer applications (such as Gnutella or KaZaA) and popular instant-messaging platforms (e.g., Yahoo!, AOL, MSN), giving administrators fine-grained control over non-business traffic.
1. Traffic Filtering CBAC dynamically permits return TCP/UDP traffic only when a session has been legitimately initiated. When inside hosts create connections, CBAC temporarily opens access in the ACL to allow the return packets back through the firewall. This supports intranet, extranet, and Internet perimeter deployments. Unlike stateless filtering, CBAC evaluates Layer 3 and 4 information and Application Layer state data, enabling support for protocols requiring multiple negotiated channels.
2. Traffic Inspection Since CBAC tracks TCP/UDP sessions, it can protect against attacks that exploit connection state. For example:
These protections help reduce DoS attack effectiveness by eliminating abnormal traffic before it reaches internal hosts.
3. Intrusion Detection CBAC includes a limited intrusion detection capability designed to identify specific attack signatures—particularly those targeting SMTP. When an attack signature is matched, CBAC: • Terminates the unauthorized connection • Generates syslog alerts for analysis
4. Alert and Audit Generation CBAC supports extensive session-based logging through syslog. Each inspected session can record timestamps, source/destination addresses, ports, and bytes transferred. Suspicious activity triggers real-time syslog alerts that can be forwarded to monitoring systems.
Introduced in 1997, CBAC was a major advancement over previous IOS solutions such as TCP established and reflexive ACLs. Key improvements include:
CBAC offers significant protections, but with important considerations:
Even though CBAC is considered a legacy technology today (superseded by Zone-Based Firewall), understanding it remains valuable for:
Without CBAC, traffic filtering is limited to ACL implementations that examine packets at the Network Layer or, at most, the Transport Layer. CBAC relies on a stateful packet filter that is application-aware. This means that the filter is able to recognize all sessions of a dynamic application. CBAC examines not only Network Layer and Transport Layer information but also examines Application Layer protocol information (such as FTP connection information) to learn about the state of the session. For example, CBAC can monitor TCP, UDP, and ICMP connections and maintain information in a state table (or connection table) to keep track of these active sessions. This allows support of protocols that involve multiple channels created as a result of negotiations in the control channel. Most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) involve multiple channels.
The state table tracks the sessions and inspects all packets that pass through the stateful packet filter firewall. CBAC then uses the state table to build dynamic ACL entries that permit returning traffic through the perimeter router or firewall.
How does CBAC work? CBAC creates openings in ACLs at firewall interfaces by adding a temporary ACL entry for a specific session. These openings are created when specified traffic exits the internal protected network through the firewall. The temporary openings allow returning traffic that would normally be blocked and additional data channels to enter the internal network back through the firewall. The traffic is allowed back through the firewall only if it is part of the same session and has the expected properties as the original traffic that triggered CBAC when exiting through the firewall. Without this temporary ACL entry, this traffic would be denied by the preexisting ACL. The state table dynamically changes and adapts with the traffic flow.
Assume that a user initiates an outbound connection, such as Telnet, from a protected network to an external network, and CBAC is enabled to inspect Telnet traffic. Also assume that an ACL is applied on the external interface preventing Telnet traffic from entering the protected network. This connection goes through a multistep operation:
1. When the traffic is first generated, as it passes through the router, the ACL is processed first if an inbound ACL is applied. If the ACL denies this type of outbound connection, the packet is dropped. If the ACL permits this outbound connection, the CBAC inspection rules are examined.
2. Based on the inspection rules for CBAC, the Cisco IOS software might inspect the connection. If Telnet traffic is not inspected, the packet is allowed through, and no other information is gathered. Otherwise, the connection goes to the next step.
3. The connection information is compared to entries in the state table. If the connection does not currently exist, the entry is added. If it does exist, the idle timer for the connection is reset.
4. If a new entry is added, a dynamic ACL entry is added on the external interface in the inbound direction (from the external network to the internal protected network). This allows the returning Telnet traffic, that is, packets that are part of the same Telnet connection previously established with the outbound packet, back into the network. This temporary opening is only active for as long as the session is open. These dynamic ACL entries are not saved to NVRAM.
5. When the session terminates, the dynamic information from the state table and the dynamic ACL entry are removed.
This is very similar to how reflexive ACLs are processed. CBAC creates temporary openings in the ACLs to allow returning traffic. These entries are created as inspected traffic leaves the network and are removed whenever the connection terminates or the idle timeout period for the connection is reached. Also, as with reflexive ACLs, the administrator can specify which protocols to inspect, as well as on which interface and in which direction the inspection occurs.
CBAC is flexible in its configuration, especially in choosing which direction to inspect traffic. In a typical setup, CBAC is used on the perimeter router or firewall to allow returning traffic into the network. CBAC can also be configured to inspect traffic in two directions - in and out. This is useful when protecting two parts of a network, where both sides initiate certain connections and allow the returning traffic to reach its source.
CBAC TCP Handling
Recall that TCP uses a three-way handshake. The first packet contains a random sequence number and sets the TCP SYN flag. When the first packet from a TCP flow with the TCP SYN flag is received by the router, the inbound ACL on the inside secured interface is checked. If the packet is permitted, a dynamic session entry is created. The session is described by endpoint addresses, port numbers, sequence numbers, and flags.
All subsequent packets belonging to this session are checked against the current state and discarded if the packets are invalid. How does CBAC determine if a packet is a subsequent packet belonging to an already established session?
When the TCP SYN packet is transmitted, the second packet contains a random sequence number that the responding host generates, as well as an acknowledgment sequence number (the received sequence number incremented by one), and the TCP SYN and ACK flags are set. The third packet acknowledges the received packet by incrementing the packet sequence number in the acknowledgment sequence, raising the sequence number by the appropriate number of transmitted octets, and setting the ACK flag.
All subsequent segments increment their sequence numbers by the number of transmitted octets and acknowledge the last received segment by an increment of one, according to the TCP state machine. After the three-way handshake, all packets have the ACK flag set until the session is terminated. The router tracks the sequence numbers and flags to determine the session that the packet belongs to.
CBAC UDP Handling
With UDP, the router cannot track the sequence numbers and flags. There is no three-way handshake and no teardown process. If the first packet from a UDP flow is permitted through the router, a UDP entry is created in the connection table. The endpoint addresses and port numbers describe the UDP connection entry. When no data is exchanged within the connection for a configurable UDP timeout, the connection description is deleted from the connection table.
CBAC Handling of Other IP Protocols
Stateful firewalls do not usually track other protocols, such as GRE and IPSec, but handle protocols in a stateless manner, similar to how a classic packet filter handles these protocols. If stateful support is provided for other protocols, the support is usually similar to the support for UDP. When a protocol flow is initially permitted, all packets matching the flow are permitted until an idle timer expires.
Dynamic applications, such as FTP, SQLnet, and many protocols that are used for voice and video signaling and media transfer, open a channel on a well-known port and then negotiate additional channels through the initial session. Stateful firewalls support these dynamic applications through application inspection features. The stateful packet filter snoops the initial session and parses the application data to learn about the additional negotiated channels. Then the stateful packet filter enforces the policy that if the initial session was permitted, any additional channels of that application should be permitted as well.
With CBAC, the protocols to inspect are specified in an inspection rule. An inspection rule is applied to an interface in a direction (in or out) where the inspection applies. The firewall engine inspects only the specified protocol packets if they first pass the inbound ACL that is applied to the inside interface. If a packet is denied by the ACL, the packet is dropped and not inspected by the firewall.
Packets that match the inspection rule generate a dynamic ACL entry that allows return traffic back through the firewall. The firewall creates and removes ACLs as required by the applications. When the application terminates, CBAC removes all dynamic ACLs for that session.
The Cisco IOS Firewall engine can recognize application-specific commands such as illegal SMTP commands in the control channel and detect and prevent certain Application Layer attacks. When an attack is detected, the firewall can take several actions:
The timeout and threshold values are used to manage connection state information. These values help determine when to drop connections that do not become fully established or that time out.
Cisco IOS Firewall provides three thresholds against TCP-based DoS attacks:
If a threshold for the number of half-opened TCP sessions is exceeded, the firewall has two options:
There are four steps to configure CBAC:
Step 1. Pick an interface - internal or external.
Step 2. Configure IP ACLs at the interface.
Step 3. Define inspection rules.
Step 4. Apply an inspection rule to an interface.
Pick an Interface
First determine the internal and external interfaces for applying inspection. With CBAC, internal and external refers to the direction of conversation. The interface in which sessions can be initiated must be selected as the internal interface. Sessions that originate from the external interface will be blocked.
In a typical two-interface scenario in which one interface connects to the external network and the other connects to the protected network, CBAC prevents the specified protocol traffic from entering the firewall and the internal network, unless the traffic is part of a session initiated from within the internal network.
In a three-interface scenario in which the first interface connects to the external network, the second interface connects to a network in a DMZ, and the third interface connects to the internal protected network, the firewall can permit external traffic to resources within the DMZ, such as DNS and web services. The same firewall can then prevent specified protocol traffic from entering the internal network unless the traffic is part of a session initiated from within the internal network.
CBAC can also be configured in two directions at one or more interfaces. Configure the firewall in two directions when the networks on both sides of the firewall require protection, such as with extranet or intranet configurations, and for protection against DoS attacks. If configuring CBAC in two directions, configure one direction first, using the appropriate internal and external interface designations. When configuring CBAC in the other direction, the interface designations must be swapped.
Configure IP ACLs at the Interface
For Cisco IOS Firewall to work properly, an administrator must configure IP ACLs at the inside, outside, and DMZ interfaces.
To provide the security benefits of ACLs, an administrator should, at a minimum, configure ACLs on border routers situated at the edge of the network between the internal and external networks. This provides a basic buffer from the outside network or from a less controlled area of an organization's network into a more sensitive area of the network.
ACLs can also be used on a router positioned between two internal parts of a network to control traffic flow. For example, if the research and development (R&D) network of an organization is separated from the human resources network by a router, an ACL can be implemented to prevent the R&D employees from accessing the human resources network.
ACLs can be configured on an interface to filter inbound traffic, outbound traffic, or both. The administrator must define ACLs for each protocol enabled on an interface to control traffic flow for that protocol. Use ACLs to determine what types of traffic to forward or block at the router interfaces. For example, an administrator might permit email traffic and at the same time block all Telnet traffic.
These are the guidelines for configuring IP ACLs on a Cisco IOS Firewall:
Define inspection Rules
The administrator must define inspection rules to specify which Application Layer protocols to inspect at an interface. Normally, it is only necessary to define one inspection rule. The only exception occurs if it is necessary to enable the firewall engine in two directions at a single firewall interface. In this instance, the administrator can configure two rules, one for each direction.
An inspection rule should specify each desired Application Layer protocol to inspect, as well as generic TCP, UDP, or ICMP, if desired. Generic TCP and UDP inspection dynamically permits return traffic of active sessions. ICMP inspection allows ICMP echo reply packets forwarded as a response to previously seen ICMP echo messages.
The inspection rule consists of a series of statements, each listing a protocol and specifying the same inspection rule name. Inspection rules include options for controlling alert and audit trail messages.
Inspection rules are configured in global configuration.
Router(config)# ip inspect name inspection_name protocol [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
Example 1
In this example, the IP inspection rule is named FWRULE. FWRULE inspects extended SMTP and FTP with alert and audit trails enabled. FWRULE has an idle timeout of 300 seconds.
ip inspect name FWRULE smtp alert on audit-trail on timeout 300
ip inspect name FWRULE ftp alert on audit-trail on timeout 300
Example 2
In this example, the PERMIT_JAVA rule allows all users permitted by standard ACL 10 to download Java applets.
ip inspect name PERMIT_JAVA http java-list 10
access-list 10 permit 10.224.10.0 0.0.0.255
Example 3
In this example, a list of protocols, including generic TCP with an idle timeout of 12 hours (normally 1 hour), is defined for the Cisco IOS Firewall to inspect.
ip inspect name in2out rcmd
ip inspect name in2out ftp
ip inspect name in2out tftp
ip inspect name in2out tcp timeout 43200
ip inspect name in2out http
ip inspect name in2out udp
Apply an Inspection Rule to an Interface
The last step for configuring CBAC is to apply an inspection rule to an interface.
This is the command syntax used to activate an inspection rule on an interface.
Router(config-if)# ip inspect inspection_name {in | out}
For the Cisco IOS Firewall to be effective, both inspection rules and ACLs should be strategically applied to all router interfaces. There are two guiding principles for applying inspection rules and ACLs on the router:
For example, an administrator needs to permit inside users to initiate TCP, UDP, and ICMP traffic with all external sources. Outside clients are allowed to communicate with the SMTP server (209.165.201.1) and HTTP server (209.165.201.2) that are located in the enterprise DMZ. It is also necessary to permit certain ICMP messages to all interfaces. All other traffic from the external network is denied.
For this example, first create an ACL that allows TCP, UDP, and ICMP sessions and denies all other traffic.
R1(config)# access-list 101 permit tcp 10.10.10.0 0.0.0.255 any
R1(config)# access-list 101 permit udp 10.10.10.0 0.0.0.255 any
R1(config)# access-list 101 permit icmp 10.10.10.0 0.0.0.255 any
R1(config)# access-list 101 deny ip any any
This ACL is applied to the internal interface in the inbound direction. The ACL processes traffic initiating from the internal network prior to leaving the network.
R1(config)# interface Fa0/0
R1(config-if)# ip access-group 101 in
Next, create an extended ACL in which SMTP and HTTP traffic is permitted from the external network to the DMZ network only, and all other traffic is denied.
R1(config)# access-list 102 permit tcp any 209.165.201.1 0.0.0.0 eq 80
R1(config)# access-list 102 permit tcp any 209.165.201.2 0.0.0.0 eq smtp
R1(config)# access-list 102 permit icmp any any echo-reply
R1(config)# access-list 102 permit icmp any any unreachable
R1(config)# access-list 102 permit icmp any any administratively-prohibited
R1(config)# access-list 102 permit icmp any any packet-too-big
R1(config)# access-list 102 permit icmp any any echo
R1(config)# access-list 102 permit icmp any any time-exceeded
R1(config)# access-list 102 deny ip any any
This ACL is applied to the interface connecting to the external network in the inbound direction.
R1(config)# interface S0/0/0
R1(config-if)# ip access-group 102 in
If the configuration stopped here, all returning traffic, with the exception of ICMP messages, is denied because of the external ACL. Next, create inspection rules for TCP inspection and UDP inspection.
R1(config)# ip inspect name MYSITE tcp
R1(config)# ip inspect name MYSITE udp
These inspection rules are applied to the internal interface in the inbound direction.
R1(config-if)# ip inspect MYSITE in
The inspection list automatically creates temporary ACL statements in the inbound ACL applied to the external interface for TCP and UDP connections. This permits TCP and UDP traffic that is in response to requests generated from the internal network.
To remove CBAC from the router, use the global no ip inspect command.
Router(config)# no ip inspect
This command removes all CBAC commands, the state table, and all temporary ACL entries created by CBAC. It also resets all timeout and threshold values to their factory defaults. After CBAC is removed, all inspection processes are no longer available, and the router uses only the current ACL implementations for filtering.
CBAC inspection supports two types of logging functions: alerts and audits.
Alerts
Alerts display messages concerning CBAC operation, such as insufficient router resources, DoS attacks, and other threats. Alerts are enabled by default and automatically display on the console line of the router. The administrator can globally disable alerts, although it is highly recommended that alerts are left enabled.
Router(config)# ip inspect alert-off
The administrator can also disable and enable alerts per inspection rule; however, it is highly recommended that alerts are left enabled.
This is an example of an alert informing that someone is trying to send an unapproved SMTP command to an email server:
%FW-4-SMTP_INVALID_COMMAND: Invalid SMTP command from initiator
(209.165.201.5:49387)
CBAC can also detect other types of SMTP attacks:
This is an example of an alert that is generated when a hacker tries to exploit the SMTP Majordomo bug:
02:04:55: %FW-4-TCP_MAJORDOMO_EXEC_BUG: Sig:3107:
Majordomo Execute Attack - from 209.165.201.5 to 192.168.1.1:
Audits
Auditing keeps track of the connections that CBAC inspects, including valid and invalid access attempts. For example, it displays messages when CBAC adds or removes an entry from the state table. The audit record gives some basic statistical information about the connection. Auditing is disabled by default, but can be enabled with the following command:
Router(config)# ip inspect audit-trail
For example, this audit message is being created from a telnet connection initiated from 192.1.1.2:
%FW-6-SESS_AUDIT_TRAIL: tcp session
initiator (192.168.1.2:32782) sent 22 bytes
responder (209.165.201.1:23) sent 200 bytes
By default, alerts and audits are displayed on the console line. This information can be logged to other locations, including the internal buffer of the router or an external syslog server.
CBAC supports many show commands that can be used to view the temporary ACL entries created, the state table, and CBAC operation. To view information about CBAC inspections, use the show ip inspect command.
Router# show ip inspect [parameter]
The following output shows the inspection rules configured for the inspect_outbound inspection rule. This rule inspects TCP and UDP traffic, both with their default idle timeouts.
Router# show ip inspect name inspect_outbound
Inspection name inspect_outbound
cuseeme alert is on audit-trail is on timeout 3600
ftp alert is on audit-trail is on timeout 3600
http alert is on audit-trail is on timeout 3600
rcmd alert is on audit-trail is on timeout 3600
realaudio alert is on audit-trail is on timeout 3600
smtp max-data 20000000 alert is on audit-trail is on timeout 3600
tftp alert is on audit-trail is on timeout 30
udp alert is on audit-trail is on timeout 15
tcp alert is on audit-trail is on timeout 3600
In the next example, the state table has two entries: 192.168.1.2 is inside the network, and 209.165.201.1 is outside. The second entry shows the internal device opening a connection to an external FTP server. The first connection displays the data connection that the FTP server opened back to the internal client. This shows the CBAC dynamic ACL entries created in the inbound extended ACL. The show ip access-list command displays the dynamic ACL entries created by the inbound extended ACL.
Router# show ip inspect sessions
Established Sessions
Session 25A3378 (209.165.201.1:20)=>(192.168.1.2:32704) ftp-data SIS_OPEN
Session 25A5AC2 (192.168.1.2:32703)=>(209.165.201.1:21) ftp SIS_OPEN
Router# show ip access-list
Extended IP access list 100
permit tcp host 209.165.201.1 eq 21 host 192.168.1.2 eq 32703 (24 matches)
permit tcp host 209.165.201.1 eq 20 host 192.168.1.2 eq 32704 (88 matches)
<output omitted>
There are two dynamic ACL entries to allow return traffic from the FTP server, 209.165.201.1, to the FTP client, 192.168.1.1.
For detailed troubleshooting of CBAC, the administrator can use debug commands. With debug commands, the administrator sees in real time the operation of CBAC on the router. The debug ip inspect command can inspect various applications and other operation details.
Router# debug ip inspect protocol parameter
The application names to use for inspection are cuseeme, dns, ftp-cmd, ftp-token, h323, http, netshow, rcmd, realaudio, rpc, rtsp, sip, skinny, smtp, sqlnet, streamworks, tftp, and vdolive.
This output from the debug ip inspect timers command enables an administrator to determine, among other things, when idle timeouts are reached.
Router# debug ip inspect timers
*Mar 2 01:20:43: CBAC* sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22)
(10.0.0.1:46409) => (10.1.0.1:21)
*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PROCESS-SWITCH packet
*Mar 2 01:20:43: CBAC sis 25A3604 pak 2541C58 TCP P ack 4223720032 seq 4200176225(22)
*Mar 2 01:20:43: CBAC sis 25A3604 ftp L7 inspect result: PASS packet
*Mar 2 01:20:43: CBAC* sis 25A3604 pak 2544374 TCP P ack 4200176247 seq 4223720032(30)
(10.0.0. 1:46409) <= (10.1.0.1:21)
*Mar 2 01:20:43: CBAC* sis 25A3604 ftp L7 inspect result: PASS packet
*Mar 2 01:20:43: CBAC* sis 25A3604 pak 25412F8 TCP P ack 4223720062 seq 4200176247(15)
(10.0.0. 1:46409) => (10.1.0.1:21)
*Mar 2 01:20:43: CBAC sis 25C1CC4 pak 2544734 TCP S seq 4226992037(0) (10.1.0.1:20) =>
(10.0.0.1:46411)
*Mar 2 01:20:43: CBAC* sis 25C1CC4 pak 2541E38 TCP S ack 4226992038 seq 4203405054(0)
(10.1.0.1:20) <= (10.0.0.1:46411)
Beginning with Cisco IOS Release 12.4(20)T, the debug policy-firewall command replaces the debug ip inspect command.
CBAC has dramatically transformed the capability of Cisco routers to serve as firewalls. CBAC has incredible versatility, enabling a Cisco router to act as a true stateful firewall. Despite the extreme usefulness of CBAC in securing modern networks, it does have some shortcomings. Newer technologies enable a more intuitive and structured implementation of Cisco routers as Cisco IOS Firewalls while building on the functionality of CBAC.
In 2006, Cisco Systems introduced the zone-based policy firewall configuration model with Cisco IOS Release 12.4(6)T. With this new model, interfaces are assigned to zones and then an inspection policy is applied to traffic moving between the zones. A zone-based firewall allows different inspection policies to be applied to multiple host groups connected to the same router interface. It also has the ability to prohibit traffic via a default deny-all policy between firewall zones.
The zone-based policy firewall (ZPF or ZBF or ZFW) inspection interface supports previous firewall features, including stateful packet inspection, application inspection, URL filtering, and DoS mitigation.
Firewall policies are configured using the Cisco Common Classification Policy Language (C3PL), which uses a hierarchical structure to define network protocol inspection and allows hosts to be grouped under one inspection policy.
The primary motivations for network security professionals to migrate to the ZPF model are structure and ease of use. The structured approach is useful for documentation and communication. The ease of use makes network security implementations more accessible to a larger community of security professionals.
Implementing CBAC is complex and can be overwhelming. Unlike ZPF, CBAC does not utilize any dedicated hierarchical data structures to modularize the implementation. CBAC has these limitations:
Zones establish the security borders of a network. The zone itself defines a boundary where traffic is subjected to policy restrictions as it crosses over into another region of a network. The default policy between zones is deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from the CBAC model in which traffic was implicitly allowed until it was explicitly blocked with an ACL.
While many ZPF commands appear similar to CBAC commands, they are not the same. A second significant change is the introduction of Cisco Common Classification Policy Language (C3PL). This new configuration policy language allows a modular approach to firewall implementation.
Some of the benefits of ZPF include the following:
When deciding whether to implement CBAC or zones, one important note is that both configuration models can be enabled concurrently on a router. However, the models cannot be combined on a single interface. For example, an interface cannot be configured as a security zone member and configured for IP inspection simultaneously.
Designing zone-based firewalls involves a few steps:
Step 1. Determine the Zones - The internetworking infrastructure under consideration must be split into separate zones with various security levels. In this step, the administrator does not consider physical implementation of the firewall (number of devices, defense depth, redundancy, etc.), but focuses instead on the separation of the infrastructure into zones. For example, the public network to which the internal network is connected is one zone.
Step 2. Establish policies between zones - For each pair of "source-destination" zones (for example, from inside network to Internet), define the sessions that clients in the source zones can request from servers in destination zones. These sessions are most commonly TCP and UDP sessions, but also ICMP sessions such as ICMP echo. For traffic that is not based on the concept of sessions, such as IPsec Encapsulating Security Payload [ESP], the administrator must define unidirectional traffic flows from source to destination and vice versa. As in Step 1, this step is about the traffic requirements between zones, not the physical setup.
Step 3. Design the physical infrastructure - After the zones have been identified and the traffic requirements between them documented, the administrator must design the physical infrastructure, taking into account security and availability requirements. This includes dictating the number of devices between most-secure and least-secure zones and determining redundant devices.
Step 4. Identify subset within zones and merge traffic requirements - For each firewall device in the design, the administrator must identify zone subsets connected to its interfaces and merge the traffic requirements for those zones. For example, multiple zones might be indirectly attached to a single interface of a firewall, resulting in a device-specific interzone policy.
Common ZPF designs are LAN-to-Internet firewall, a firewall with public servers, redundant firewalls, and complex firewalls.
The Cisco IOS zone-based policy firewall can take three possible actions when configured using Cisco SDM:
To apply rate limits to the traffic of a specified class, the police option can be used in conjunction with the inspect or pass command.
The membership of the router network interfaces in zones is subject to several rules governing interface behavior, as is the traffic moving between zone member interfaces:
The rules for a zone-based policy firewall are different when the router is involved in the traffic flow. In addition, the rules depend on whether the router is the source or the destination of the traffic.
When an interface is configured to be a zone member, the hosts that are connected to the interface are included in the zone, but traffic flowing to and from the interfaces of the router is not controlled by the zone policies. Instead, all the IP interfaces on the router are automatically made part of the self zone. To limit IP traffic moving to the IP addresses of the router from the various zones on a router, policies must be applied. The policies can be set to block, allow, or inspect traffic between the zone and the self zone of the router, and vice versa. If there are no policies between a zone and the self zone, all traffic is permitted to the interfaces of the router without being inspected.
A policy can be defined using the self zone as either the source or the destination zone. The self zone is a system-defined zone. It does not require any interfaces to be configured as members. A zone-pair that includes the self zone, along with the associated policy, applies to traffic that is directed to the router or traffic that the router generates. It does not apply to traffic traversing the router.
When the router is involved in the traffic flow, additional rules for zone-based policy firewalls govern interface behavior:
The only exception to the deny-by-default approach is the traffic to and from the router itself. This traffic is permitted by default. An explicit policy can be configured to restrict such traffic.
There are several steps for configuring ZPF with the CLI:
Step 1. Create the zones for the firewall with the zone security command.
Step 2. Define traffic classes with the class-map type inspect command.
Step 3. Specify firewall policies with the policy-map type inspect command.
Step 4. Apply firewall policies to pairs of source and destination zones using the zone-pair security command.
Step 5. Assign router interfaces to zones using the zone-member security interface command.
When configuring ZPF with the CLI, there are several factors to consider:
CBAC dynamically creates entries in ACLs attached to interfaces on which the ip inspect command is configured. ZPF does not change ACLs. Review ACL usage before entering the zone-member command.
Create the Zones
The administrator creates the zones for the firewall with the zone security command. An optional description is recommended.
Router(config)# zone security zone-name
Router(config-sec-zone)# description line-of-description
Think about what should constitute the zones. The general guideline is to group together interfaces that are similar when viewed from a security perspective. In other words, interfaces that have similar security needs should be placed into a zone.
Define Traffic Classes
ZPF traffic classes enable the network security professional to define traffic flows in as granular a fashion as desired.
This is the syntax for creating ZPF traffic classes.
Router(config)# class-map type inspect [match-any | match-all] class-map-name
For Layer 3 and Layer 4, top-level class maps, the match-any option is the default behavior.
Router(config)# class-map type inspect protocol-name [match-any | match-all] class-map-name
For Layer 7, application-specific class maps, see www.cisco.com for construction details.
The syntax for referencing access lists from within the class map is:
Router(config-cmap)# match access-group {access-group | name access-group-name}
Protocols are matched from within the class map with the syntax:
Router(config-cmap)# match protocol protocol-name
Nested class maps can be configured as well using the syntax:
Router(config-cmap)# match class-map class-map-name
The ability to create a hierarchy of classes and policies by nesting is one of the reasons that ZPF is such a powerful approach to creating Cisco IOS firewalls.
Specify Firewall Policies
Similar to other modular CLI constructs with Cisco IOS software, the administrator has to specify what to do with the traffic matching the desired traffic class. The options are pass, inspect, drop, and police.
This is the syntax for creating ZPF policy maps.
Router(config)# policy-map type inspect policy-map-name
Traffic classes on which an action must be performed are specified within the policy map.
Router(config-pmap)# class type inspect class-name
The default class (matching all remaining traffic) is specified using this command.
Router(config-pmap)# class class-default
Finally, the action to take on the traffic is specified.
Router(config-pmap-c)# pass | inspect | drop [log] | police
Apply Firewall Policies
After the firewall policy has been configured, the administrator applies it to traffic between a pair of zones using the zone-pair security command. To apply a policy, a zone pair must first be created. Specify the source zone, the destination zone, and the policy for handling the traffic between them.
Router(config)# zone-pair security zone-pair-name [source source-zone-name | self] destination [self | destination-zone-name]
Use the service-policy type inspect policy-map-name command to attach a policy-map and its associated actions to a zone-pair. Enter the command after entering the zone-pair security command.
Deep-packet inspection (attaching a Layer 7 policy map to a top-level policy map) can also be configured. This is the syntax used with Cisco IOS Release 12.4(20)T.
Router(config-pmap-c)# service-policy {h323 | http | im | imap | p2p | pop3 | sip | smtp | sunrpc | urlfilter} policy-map
The policy map is the name of the Layer 7 policy map being applied to the top-level Layer 3 or Layer 4 policy map.
Assign Interfaces
Finally, the administrator must assign interfaces to the appropriate security zones using the zone-member interface command.
Router(config-if)# zone-member security zone-name
The zone-member security command puts an interface into a security zone. When an interface is in a security zone, all traffic to and from that interface (except traffic going to the router or initiated by the router) is dropped by default. To permit traffic through an interface that is a zone member, the zone must be part of a zone pair to which a policy is applied. If the policy permits traffic (via inspect or pass actions), traffic can flow through the interface.
ZPF configuration with the CLI might appear a little intimidating at first. The good news is that there are two ways to configure ZPF - with the Cisco IOS CLI or with Cisco SDM.
Zone-Based Policy Firewall configuration is much easier with Cisco Router and Security Device Manager (SDM).
There are four steps to configure ZPF with SDM:
Step 1. Define zones.
Step 2. Configure class maps to describe traffic between zones.
Step 3. Create policy maps to apply actions to the traffic of the class maps.
Step 4. Define zone pairs and assign policy maps to the zone pairs.
Unlike the CLI configuration, with SDM, the interfaces are associated with zones in Step 1.
A similar, newer Cisco GUI called Cisco Configuration Professional (CCP) can be used to configure ZPF. See www.cisco.com/go/ciscocp. CCP adds the feature of communities, which are groups of devices, to improve network management. Some technologies, such as SIP protocol inspection under the self zone, are supported on SDM but not on CCP. Cisco IOS 12.4(9)T or later is required for CCP. CCP will eventually replace SDM.
Define Zones
The first step in configuring a Cisco IOS zone-based policy firewall with SDM is to define zones. A zone, or security zone, is a group of interfaces to which a security policy can be applied. The interfaces in a zone share common functions or features. For example, an administrator might place two interfaces that connect to the local LAN in one security zone, and the interfaces that connect to the Internet into another security zone.
For traffic to flow among all interfaces in a router, all interfaces must be a member of a security zone. However, it is not required that all router interfaces be members of security zones.
These are the steps for creating a zone using SDM:
Step 1. Choose Configure > Additional Tasks > Zones.
Step 2. From the Zone panel, click Add to create a new zone.
Step 3. The Add a Zone window appears. Enter a zone name in the Zone Name field.
Step 4. Choose the interfaces for this zone by checking the check box in front of the interface name. Because physical interfaces can be placed in only one zone, they do not appear in the list if they have already been assigned to a zone. You can place virtual interfaces, such as Dialer interfaces or Virtual Template interfaces, in multiple zones, so these interfaces always appear in the list.
As you assign interfaces to zones, keep in mind the zone-based policy firewall rules that govern interface behavior.
Step 5. Click OK to create the zone, and click OK in the Commands Delivery Status window.
After a zone has been created, the interfaces that are associated with the zone can be changed, but the name of the zone cannot be changed. Click Edit in the Zone panel to choose different interfaces for an existing zone. Click Delete in the Zone panel to remove a zone. A zone that is a member of a zone pair cannot be deleted.
Configure Class Maps
The next step in configuring ZPF with SDM is to configure class maps. Class maps identify traffic and traffic parameters for policy application.
Layer 3 and 4 class maps sort the traffic based on specific criteria:
Class maps can apply match-any or match-all operators to determine how to apply the match criteria. If match-any is specified, traffic must meet just one of the match criteria in the class map. If match-all is specified, traffic must match all of the class map criteria to belong to that particular class.
These are the steps to create a class map using SDM:
Step 1. Choose Configure > Additional Tasks > C3PL > Class Map > Inspection.
Step 2. From the Inspection Class Maps, click Add.
Step 3. Enter a class map name in the Class Map field and optionally add a description in the Description field. Select the desired protocols from the list and click Add>> to add them to the inspection list for this class map.
Class maps can be reviewed, created, and edited in the Inspect Class Map window. The Class Map Name area of the window lists the configured class maps, and the lower portion of the window displays the details of the selected class map. If it is necessary to edit a class map or see more details, choose the class map from the list and click Edit.
Create Policy Maps
Now that the class maps are created, it is time to create policy maps. Class maps are applied within policy maps. Policy maps specify the actions to be taken when traffic matches the criteria. A policy map associates traffic classes with actions.
Inspection policy maps specify the action the router is to take for traffic that matches the criteria in the associated class maps. These are the actions that a policy map supports:
These are the steps to create a policy map using SDM:
Step 1. Choose Configure > Additional Tasks > C3PL > Policy Map > Protocol Inspection.
Step 2. From the Protocol Inspection Policy Maps, click Add.
Step 3. Enter a policy name in the Policy Name field and optionally add a description in the Description field. The name and description that you enter will be visible in the Protocol Inspect Policy Maps window.
Step 4. The Class Map and Action columns display the class maps that are associated with this policy map, and the action that the router takes for the traffic that the class map describes. Click Add to add a new class map to the list and configure the action.
Step 5. The Associate Class map window appears. In the Class Name field, enter the name of the class map to apply. If the class map name is unknown, or a new class map is to be created, click the down arrow to the right of the Class Name field. A pop-up menu appears for adding a class map, choosing a class map, or choosing the class default.
Step 6. After selecting the class map, define the action that the policy map takes for traffic that matches this class map. From the Action section, choose Pass, Drop, or Inspect, based on the particular needs for this class map.
Step 7. Click OK.
Step 8. To add another class map to the policy, click Add. To modify the actions of an existing class map, choose the class map from the Class Map list and click Edit. To delete a class map, choose the class map from the Class Map list and click Delete. Use the Move Up and Move Down buttons to change the order in which the class maps are evaluated.
Step 9. Click OK. In the Command Delivery Status window, click OK.
Define Zone Pairs
A zone-pair allows a unidirectional firewall policy between two security zones to be specified. The direction of the traffic is determined by specifying a source and destination security zone. The same zone cannot be defined as both the source and the destination.
If the intent is for traffic to flow in both directions between two zones, a zone pair must be created for each direction. If the intent is for traffic to flow freely among all interfaces, each interface must be configured in a zone.
These are the steps for configuring a new zone pair using SDM:
Step 1. Choose Configure > Additional Tasks > Zone Pairs.
Step 2. In the Zone Pairs panel, click Add. The Add a Zone Pair window appears.
Step 3. In the Zone Pair field, enter a name for the zone pair. Choose a source zone from which traffic originates, a destination zone to which traffic is sent, and the policy that determines which traffic can be sent across the zones.
The source zone and destination zone lists contain the zones that are configured on the router and the self zone. The self zone can be used when configuring zone pairs for traffic originating from the router itself, or destined for the router itself, such as a zone pair that is configured for SNMP traffic. The Policy list contains the name of each policy map that is configured on the router.
Step 4. Click OK in the Add a Zone Pair window, and click OK in the Command Delivery Status window.
Step 5. To edit a zone pair, in the Zone Pairs panel choose the zone pair to edit and click Edit. If editing a zone pair, the policy map can be changed, but the name or the source or destination zones cannot be changed.
The Basic Firewall wizard of Cisco SDM helps implement a firewall. The wizard goes through the creation of the firewall by asking for information about the interfaces on the router, as well as whether the intent is to configure a DMZ network, and what rules to use in the firewall.
These are the steps for accessing the Basic Firewall Configuration wizard using SDM:
Step 1. From Cisco SDM, choose Configuration > Firewall and ACL.
Step 2. In the Create Firewall tab, click the Basic Firewall option and click Launch the Selected Task button.
Step 3. The Basic Firewall Configuration Wizard window appears. Click Next to begin the configuration.
If there is no CBAC configured on the router, a zone-based policy firewall is created by the Basic or Advanced Firewall wizards.
The first task to configure a basic firewall is to define inside (trusted) and outside (untrusted) interfaces. An outside (untrusted) interface is typically the router interface that is connected to the Internet or to a WAN. An inside (trusted) interface is typically a physical or logical interface that connects to the LAN. It is possible to select multiple inside and outside interfaces.
These are the steps for configuring a firewall using the Basic Firewall Configuration wizard:
Step 1. From the Basic Firewall Interface Configuration window, check the outside (untrusted) check box and the inside (trusted) check box to identify each interface as an outside or an inside interface. Outside interfaces connect to an organization's WAN or to the Internet. Inside interfaces connect to the LAN. More than one of each can be chosen.
Step 2. (Optional) Check the Allow Secure Cisco SDM Access From Outside Interfaces check box if the intent is to allow users outside the firewall access to the router using Cisco SDM. Choosing this option permits secure HTTP access to the outside (untrusted) interface. Because it is a secure Cisco SDM connection to the firewall, it is not possible to browse the outside (untrusted) interface via HTTP after the firewall wizard completes the configuration. After clicking Next, the wizard displays a screen that allows the administrator to specify a host IP address or a network address. The firewall is modified to allow access to the address specified.
Step 3. Click Next. If the Allow Secure SDM Access From the Outside Interfaces check box is checked, the Configuring Firewall for Remote Access window appears.
Step 4. Specify the source host or network from which Cisco SDM is allowed to remotely manage the router. Choose Network address, Host IP address, or any from the Type drop-down list, and then fill in the IP address and Subnet Mask as appropriate.
After interface configuration, the Basic Firewall Security Configuration window appears. Cisco SDM provides preconfigured application security policies that can be used to protect the network. Use the slider bar to select the security level desired and to view a description of the security it provides.
In the Basic Firewall Security Configuration window, click the Preview Commands button to view the Cisco IOS commands that make up the selected policy. The router must be configured with the IP address of at least one DNS server for application security to work.
The Firewall Configuration Summary window displays the policy name chosen, SDM_HIGH, SDM_MEDIUM, or SDM_LOW, and the configuration statements in the policy.
Click Finish to complete the configuration. The commands executed by the Basic Firewall wizard are often quite lengthy. The configurations created by wizards tend to be much more exhaustive than those created by a manual CLI or SDM configuration.
After creating the zone-based policy firewall, examine it in SDM by choosing Configure > Firewall and ACL and clicking the Edit Firewall Policy tab. A graphical view of the firewall displays in the context of the router interfaces. It is also possible to modify the firewall from this window.
The CLI ZPF commands generated by a two-interface firewall with default inspection parameters are not that lengthy. Typically, protocols such as HTTP, SMTP, and FTP are inspected in this type of scenario. A policy map applies stateful inspection to these protocols listed in a class map. Two zones, such as private and Internet, are created. The inside interface is made a member of the private zone, and the WAN interface is a member of the Internet zone. Lastly, a zone pair, such as priv-to-internet, is created. This pair has a source zone of private, a destination zone of Internet, and the policy map is applied to it.
If the router runs a Cisco IOS image that supports ZPF, SDM can be used to display the status of the firewall activity for each zone pair that is configured on the router. To display the firewall status information, choose Monitor > Firewall Status.
The firewall policy list area displays the policy name, source zone, and destination zone for each zone pair. Choose one of the following options to specify how data should be collected:
Use the show policy-map type inspect zone-pair session command to examine the active connections in the ZPF state table. The following output shows active connections from 10.0.2.12 to 172.26.26.51 port 80.
Router# show policy-map type inspect zone-pair session
Zone-pair: CNS-PAIR
Service-policy inspect : HTTP-Policy
Class-map: HTTP-Class (match-all)
Match: access-group 110
Match: protocol http
Inspect
Session 643BCF88 (10.0.2.12:3364)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:10, Last heard 00:00:00
Bytes sent (initiator:responder) [1268:64324]
Session 643BB9C8 (10.0.2.12:3361)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:16, Last heard 00:00:06
Bytes sent (initiator:responder) [2734:38447]
Session 643BD240 (10.0.2.12:3362)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:14, Last heard 00:00:07
Bytes sent (initiator:responder) [2219:39813]
Session 643BBF38 (10.0.2.12:3363)=>(172.26.26.51:80) http SIS_OPEN
Created 00:00:14, Last heard 00:00:06
Bytes sent (initiator:responder) [2106:19895]
Class-map: class-default (match-any)
Match: any
Drop (default action)
58 packets, 2104 bytes
Cisco IOS Zone-Based Policy Firewall provides state-of-the-art firewall design and configuration. What began with TCP established in 1995 has evolved into a rich set of technologies for securing networks.
But firewalls alone can never provide a complete security solution. Other technologies are required to build a secure infrastructure. Network intrusion prevention is another security technology that is required to support the network firewall. Intrusion prevention goes a long way toward closing any security gaps in a modern network.