As networks continued to grow over time, they were increasingly used to transfer and store sensitive data. This intensified the need for stronger security technologies, which led to the invention of the firewall. The term firewall originally referred to a fireproof wall, usually made of stone or metal that prevented flames from spreading between connected structures. Similarly, in networking, firewalls separate protected from non-protected areas. This prevents unauthorized users from accessing protected network resources.
Initially, basic Access Control Lists (ACLs), including standard, extended, numbered and named, were the only means of providing firewall protection. Other firewall technologies began to mature in the late 1990s. Stateful firewalls use tables to track the real-time state of end-to-end sessions. Stateful firewalls take into account the session-oriented nature of network traffic. The first stateful firewalls used the "TCP established" option for ACLs. Later, reflexive ACLs were used to dynamically reflect certain types of inside-to-outside traffic upon the return of that traffic. Dynamic ACLs were developed to open a hole in the firewall for approved traffic for a finite period of time. Time-based ACLs were created to apply ACLs during certain times of the day on specified days of the week. With the proliferation of ACL types, it became more and more important to be able to verify the proper behavior of these ACLs with show and debug commands.
Today there are many types of firewalls in existence, including packet-filtering, stateful, application gateway (proxy), address-translation, host-based, transparent, and hybrid firewalls. Modern network design must carefully include proper placement of one or more firewalls to protect those resources that must be protected while allowing secure access to those resources that must remain available.
In a hands-on lab for the chapter, Configuring CBAC and Zone-Based Firewalls, learners use CLI and SDM to configure and test Context-Based Access Control and Zone-Based Policy Firewall. The lab is found in the lab manual on Academy Connection at cisco.netacad.net.
A Packet Tracer activity, Configure IP ACLs to Mitigate Attacks, provides learners additional practice implementing the technologies introduced in this chapter. In particular, learners configure ACLs to ensure that remote access to routers is available only from management stations. Edge routers are configured with ACLs to mitigate common network attacks and these ACLs are tested for proper operation.
In a second Packet Tracer activity, Configuring Context-Based Access Control (CBAC), learners configure and IOS firewall with CBAC on a perimeter router. CBAC functionality is verified with ping, Telnet, and HTTP.
The last Packet Tracer activity for the chapter, Configuring a Zone-Based Policy Firewall (ZPF), has learners configure a ZPF policy on a perimeter router. ZPF functionality is verified with ping, Telnet and HTTP.
Packet Tracer activities for CCNA Security are found on Academy Connection at cisco.netacad.net.
Access control lists (ACLs) are widely used in computer networking and in network security for mitigating network attacks and controlling network traffic. Administrators use ACLs to define and control classes of traffic on networking devices based on various parameters. These parameters are specific to Layer 2, 3, 4, and 7 of the OSI model.
Virtually any type of traffic can be defined explicitly by using an appropriately Numbered ACL. For example, in the past, the Ethernet type field of an Ethernet frame header was used to define certain types of traffic. An Ethernet type of 0x8035 indicated a reverse address resolution protocol (RARP) frame. Numbered ACLs with a range of 200-299 were used to control traffic according to Ethernet type.
It was also common to create ACLs based on MAC addresses. An ACL numbered 700-799 indicates traffic is classified and controlled based on MAC addresses.
After the type of classification is specified, control parameters required for that ACL can be set. For example, an ACL numbered 700-799 could be used to block a client with a specific MAC address from associating with a predetermined access point.
Today, when classifying traffic, the most common types of parameters used in security-related ACLs involve IPv4 and IPv6 addresses as well as TCP and UDP port numbers. For example, an ACL can permit all users with a specific IP network address to download files from the Internet using secure FTP. That same ACL can be used to deny all IP addresses from traditional FTP access.
Standard ACLs
ACLs numbered 1-99 or 1300-1999 are standard IPv4 and IPv6 ACLs. Standard ACLs match packets by examining the source IP address field in the IP header of that packet. These ACLs are used to filter packets based solely on Layer 3 source information.
Standard ACLs permit or deny traffic based on source address. This is the command syntax for configuring a standard numbered IP ACL:
Router(config)# access-list {1-99} {permit | deny} source-addr [source-wildcard]
The first value specifies the ACL number. For standard ACLs, the number range is 1 to 99. The second value specifies whether to permit or deny the configured source IP address traffic. The third value is the source IP address that must be matched. The fourth value is the wildcard mask to be applied to the previously configured IP address to indicate the range.
Extended ACLs
Extended ACLs match packets based on Layer 3 and Layer 4 source and destination information. Layer 4 information can include TCP and UDP port information. Extended ACLs give greater flexibility and control over network access than standard ACLs. This is the command syntax for configuring an extended numbered IP ACL:
Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]
Similar to standard ACLs, the first value specifies the ACL number. ACLs numbered 100-199 or 2000-2699 are extended ACLs. The next value specifies whether to permit or deny according to the criteria that follows. The third value indicates protocol type. The administrator must specify IP, TCP, UDP, or other specific IP sub-protocols. The source IP address and wildcard mask determine where traffic originates. The destination IP address and its wildcard mask are used to indicate the final destination of the network traffic. Although the port parameter is defined as optional, when the destination IP address and mask are configured, the administrator must specify the port number to match, either by number or by a well-known port name, otherwise all traffic to that destination will be dropped.
All ACLs assume an implicit deny, meaning that if a packet does not match any of the criteria specified in the ACL, the packet is denied. Once an ACL is created, at least one permit statement should be included or all traffic will be dropped once that ACL is applied to an interface.
Both standard and extended ACLs can be used to describe packets entering or exiting an interface. The list is searched sequentially. The first statement matched stops the search through the list and defines the action to be taken.
Once the standard or extended numbered IP ACL is created, the administrator must apply it to the appropriate interface.
This is the command to apply the ACL to an interface:
Router(config-if)# ip access-group access-list-number {in | out}
This is the command to apply the ACL to a vty line:
Router(config-line)# access-class access-list-number {in | out}
It is possible to create a named ACL instead of a numbered ACL. Named ACLs must be specified as either standard or extended.
Router(config)# ip access-list [standard | extended] name_of_ACL
Executing this command places a user into subconfiguration mode where permit and deny commands are entered. The permit and deny commands have the same basic syntax as those in the numbered IP ACL commands.
A standard named ACL can use deny and permit statements.
Router(config-std-nacl)# deny {source [source-wildcard] | any}
Router(config-std-nacl)# permit {source [source-wildcard] | any}
An extended named ACL offers additional parameters.
Router(config-ext-nacl)# {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]
Advantages for using named ACLs include that an administrator can delete a specific entry in a named ACL by going into ACL subconfiguration mode and prefacing the command with the no parameter. Using the no parameter with a numbered ACL entry results in the entire ACL being deleted. An administrator can also add entries in the middle of a named ACL. With a numbered ACL, commands can only be added to the end of the ACL.
Once the ACL statements are created, the administrator activates the ACL on an interface with the ip access-group command, specifying the name of the ACL.
Router(config-if)# ip access-group access-list-name {in | out}
An ACL can also be used to permit or deny specific IP addresses from gaining virtual access. Standard ACLs allow restrictions to be enforced on the originator source IP address or IP address range. An extended ACL does the same but can also enforce the access protocol such as port 23 (Telnet) or port 22 (SSH). The access-class extended ACL only supports the any keyword as the destination. The access list must be applied to the vty port.
Router(config-line)# access-class access-list-name {in | out}
At the end of an ACL statement, the administrator has the option to configure the log parameter.
R1(config)# access-list 101 permit tcp 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 eq 22 log
If this parameter is configured, the Cisco IOS software compares packets and finds a match to the statement. The router logs it to any enabled logging facility, such as the console, the internal buffer of the router, or a syslog server. Several pieces of information are logged:
Log messages are generated on the first packet match and then at five minute intervals after that first packet match.
Enabling the log parameter on a Cisco router or switch seriously affects the performance of that device. When logging is enabled, packets are either process- or fast-switched. The log parameter should be used only when the network is under attack and an administrator is trying to determine who the attacker is. In this instance, an administrator should enable logging for the period required to gather the appropriate information and then disable logging.
Several caveats should be considered when working with ACLs:
Now that the syntax and guidelines for standard and extended IP ACLs are defined, what are some specific scenarios for which ACLs provide a security solution?
Determining whether to use standard or extended ACLs is based on the overall objective of the entire ACL. For example, imagine a scenario in which all traffic from a single subnet, 172.16.4.0, must be denied access to another subnet, but all other traffic should be permitted.
In this case, a standard ACL can be applied outbound on interface Fa0/0:
R1(config)# access-list 1 deny 172.16.4.0 0.0.0.255
R1(config)# access-list 1 permit any
R1(config)# interface FastEthernet 0/0
R1(config-if)# ip access-group 1 out
All hosts on subnet 172.16.4.0 are blocked from going out on interface Fa0/0 to subnet 172.16.3.0.
These are the access-list command parameters:
Because of the implicit deny at the end of all ACLs, the command access-list 1 permit any must be included to ensure that only traffic from the 172.16.4.0 subnet is blocked and that all other traffic is allowed.
As compared to standard ACLs, extended ACLs allow for specific types of traffic to be denied or permitted. Imagine a scenario in which FTP traffic from one subnet must be denied on another subnet. In this case, an extended ACL is required because a specific traffic type is filtered.
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
In this ACL, FTP access is denied from subnet 172.16.4.0/24 to subnet 172.16.3.0/24. All other traffic is allowed. TCP port 21 is used for FTP program commands. TCP port 20 is used for FTP data transfer. Both ports are denied.
A permit ip any any statement is required at the end of the ACL; otherwise, all traffic is denied because of the implicit deny.
In this example, the best placement of the ACL is inbound on the Fa0/1 interface. This ensures that the unwanted FTP traffic is dropped before wasting router processing resources.
Router(config)# interface fastethernet 0/1
Router(config-if)# ip access-group 101 in
Keep in mind, with this ACL, a permit any any statement overrides the implicit deny all statement at the end of every ACL. This means that all other traffic, including FTP traffic originating from the 172.16.4.0/24 network destined for any network other than the 172.16.3.0/24 network, would be permitted.
The direction of traffic through a networking device is defined by the ingress (inbound) and egress (outbound) interfaces for the traffic. Inbound traffic refers to traffic as it enters into the router, prior to the routing table being accessed. Outbound traffic refers to traffic that entered the router and has been processed by the router to determine where to forward that data. Prior to the data being forwarded out of that interface, an outbound ACL is examined.
Depending on the type of device and the type of ACL configured, the return traffic can be dynamically tracked.
In addition to flow, it is important to keep the placement of ACLs in mind. Placement depends on the type of ACL being used.
Extended ACL placement - Extended ACLs are placed on routers as close as possible to the source that is being filtered. Placing Extended ACLs too far from the source is inefficient use of network resources. For example, packets can be sent a long way only to be dropped or denied.
Standard ACL placement - Standard ACLs are placed as close to the destination as possible. Standard ACLs filter packets based on the source address only. Placing these ACLs too close to the source can adversely affect packets by denying all traffic, including valid traffic.
Most often, ACLs are used to prevent a majority of traffic from entering a network. At the same time they selectively permit some more secure types of traffic, such as HTTPS (TCP port 443), to be used for business purposes. This generally requires using Extended ACLs and a clear understanding of which ports must be blocked versus permitted.
The Nmap program can be used to determine which ports are open on a given device. For example, an ACL blocks POP3 traffic from downloading email through the Internet from a mail server on the company network, but allows email to be downloaded from a workstation inside the company network. The output of an Nmap scan on the POP3 server depends on where the scan originates. If the scan is done from a PC inside the network, the POP3 port appears open (TCP port 110).
After an ACL is applied to an interface, it is important to verify that it is functioning as intended, that is, traffic that should be denied is denied and valid traffic is permitted.
While the log option shows matches of logged packets as they happen, it can be an excessive resource burden on the networking device. The log option is best used on an interim basis to verify or troubleshoot configuration of an ACL.
The show ip access-list command can be used as a basic means of checking the intended effect of an ACL. With this command, only the number of packets matching a given access control entry (ACE) is recorded.
The show running-config command can be used to view which interfaces have ACLs applied.
ACLs can be configured from the CLI or using SDM.
Standard and Extended ACLs can be configured using Cisco Router and Security Device Manager (SDM). The SDM window has two frames. The About Your Router frame contains hardware and software details. The Configuration Overview frame provides current router configuration details, including interface, firewall, VPN, routing, and IPS information.
The Configure button at the top of the SDM application window opens the Task list. Click the Additional Tasks button to access the page for configuring ACLs.
Rules define how a router responds to a particular kind of traffic. Using Cisco SDM, an administrator can create access rules that cause the router to deny certain types of traffic while permitting other types. Cisco SDM provides default rules that an administrator can use when creating access rules.
An administrator can also view rules that were not created using Cisco SDM, called external rules, and rules with syntax that Cisco SDM does not support, which are called unsupported rules.
The SDM Rules (ACLs) Summary window provides a summary of the rules in the router configuration and access to other windows to create, edit, and delete rules. To access this window, choose Configure > Additional Tasks > ACL Editor. These are the types of rules that Cisco SDM manages:
Cisco SDM refers to ACLs as access rules. Using Cisco SDM, an administrator can create and apply standard rules (Standard ACLs) and extended rules (Extended ACLs). These are the steps for configuring a standard rule using Cisco SDM:
Step 1. Choose Configure > Additional Tasks > ACL Editor > Access Rules.
Step 2. Click Add. The Add a Rule window appears. Only interfaces with a status of up/up will be listed in the drop-down list.
Step 3. In the Add a Rule window, enter a name or number in the Name/Number field.
Step 4. From the Type drop-down list, choose Standard Rule. Optionally, enter a description in the Description field.
Step 5. Click Add. The Add a Standard Rule Entry window appears.
Step 6. From the Select an action drop-down list, choose Permit or Deny.
Step 7. From the Type drop-down list, choose an address type:
Step 8. Depending on what was selected from the Type drop-down list, these additional fields must be completed:
Step 9. (Optional) Enter a description in the Description field. The description must be less than 100 characters.
Step 10. (Optional) Check the Log matches against this entry. Depending on how the syslog settings are configured on the router, the matches are recorded in the local logging buffer, sent to a syslog server, or both.
Step 11. Click OK.
Step 12. Continue adding or editing rule entries until the standard rule is complete. If at anytime the order of the rule entries in the Rule Entry list needs to be rearranged, use the Move Up and Move Down buttons.
After the Rule Entry list is complete, the next step is to apply the rule to an interface. These are the steps for applying a rule to an interface:
Step 1. From the Add a Rule window, click Associate. The Associate with an Interface window appears.
Step 2. From the Select an Interface drop-down list, choose the interface to which this rule will be applied. Only interfaces with a status of up/up will be listed in the drop-down list.
Step 3. From the Specify a Direction section, click either Inbound or Outbound. If the router is to check packets inbound to the interface, click Inbound. If the router is to forward the packet to the outbound interface before comparing it to the entries in the access rule, click Outbound.
Step 4. If a rule is already associated with the designated interface in the desired direction, an information box appears with the following options:
To view the IOS commands generated by SDM and sent to the router, view the running-configuration file by selecting View from the menu bar followed by Running Config.
To configure ACLs that can handle two-way traffic typical of TCP-based applications, there are several IOS solutions.
Over time, engineers have created more sophisticated types of filters based on increasingly precise parameters. Engineers have also expanded the range of platforms and the range of ACLs which can be processed at wire speed. These improvements to platforms and ACLs allow network security professionals to implement cutting-edge firewall solutions without sacrificing network performance.
In a modern network, a network firewall must be placed between the inside of the network and the outside of the network. The basic idea is that all traffic from the outside should be blocked from entering the inside unless it is explicitly permitted by an ACL, or if it is returning traffic initiated from the inside of the network. This is the fundamental role of a network firewall, whether it is a dedicated hardware device or a Cisco router with IOS Firewall.
Many common applications rely on TCP, which builds a virtual circuit between two endpoints. The first generation IOS traffic filtering solution to support the two-way nature of TCP virtual circuits was the TCP established keyword for extended IP ACLs. Introduced in 1995, the TCP established keyword for extended IP ACLs enabled a primitive network firewall to be created on a Cisco router. It blocked all traffic coming from the Internet except for the TCP reply traffic associated with established TCP traffic initiated from the inside of the network.
The second generation IOS solution for session filtering was reflexive ACLs. Reflexive ACLs were introduced to the IOS in 1996. These ACLs filter traffic based on source and destination addresses, and port numbers, and keep track of sessions. Reflexive ACL session filtering uses temporary filters which are removed when a session is over.
The TCP established option and reflexive ACLs are examples of complex ACLs.
This is the syntax for the TCP established option in a numbered extended IP ACL.
The established keyword forces the router to check whether the TCP ACK or RST control flag is set. If the ACK flag is set, the TCP traffic is allowed in. If not, it is assumed that the traffic is associated with a new connection initiated from the outside.
Using the established keyword does not implement a stateful firewall on a router. No stateful information is maintained to keep track of traffic initiated from the inside of the network. All that the established parameter does is allow any TCP segments with the appropriate control flag. The router does not keep track of conversations to determine whether the traffic is return traffic associated with a connection initiated from inside the network.
Therefore, using the established keyword to allow return traffic into a network opens a hole in the router. Hackers can take advantage of this hole by using a packet generator or scanner, such as Nmap, to sneak TCP packets into a network by masquerading them as returning traffic. Hackers accomplish this by using the packet generator to set the appropriate bit or bits in the TCP control field.
The established option does not apply to UDP or ICMP traffic, because UDP and ICMP traffic does not rely on any control flags as used with TCP traffic.
Despite the security hole, using the established keyword does provide a more secure solution since a match occurs only if the TCP packet has the ACK or RST control bits set.
R1(config)# access-list 100 permit tcp any eq 443 192.168.1.0 0.0.0.255 established
R1(config)# access-list 100 permit tcp any 192.168.1.3 0.0.0.0 eq 22
R1(config)# access-list 100 deny ip any any
R1(config)# interface s0/0/0
R1(config-if)# ip access-group 100 in
If the keyword established were left off, then any TCP traffic with source port 443 would be permitted. With the keyword, only traffic from source port 443 with the ACK TCP control flag set is permitted.
As is typical with a firewall configuration, all incoming traffic is denied unless explicitly permitted (SSH, port 22, traffic in this case) or unless it is associated with traffic initiated from the inside of the network (HTTPS traffic in this case). Any TCP source port 443 traffic initiated from outside the network with the appropriate control flag set is allowed in.
Reflexive ACLs were introduced to Cisco IOS in 1996, about a year after the TCP established option became available. Reflexive ACLs provide a truer form of session filtering than is possible with TCP established. Reflexive ACLs are much harder to spoof because more filter criteria must be matched before a packet is permitted through. For example, source and destination addresses and port numbers are checked, not just ACK and RST bits. Also, session filtering uses temporary filters that are removed when a session is over. This adds a time limit on a hacker's attack opportunity.
The established keyword is available only for the TCP upper layer protocol. The other upper layer protocols, such as UDP and ICMP, must either permit all incoming traffic or define all possible permissible source and destination, host and port address pairs for each protocol.
The biggest limitation of standard and extended ACLs is that they are designed to filter unidirectional rather than bidirectional connections. Standard and extended ACLs do not keep track of the state of a connection. If someone inside sends traffic to the Internet, it is difficult to safely allow the returning traffic back into the network without opening a large hole on the perimeter router. Reflexive ACLs were developed for this reason. Reflexive ACLs allow an administrator to perform actual session filtering for any type of IP traffic.
Reflexive ACLs work by using temporary access control entries (ACEs) inserted into an extended ACL, which is applied on the external interface of the perimeter router. When the session ends or the temporary entry times out, it is removed from the ACL configuration of the external interface. This reduces network exposure to DoS attacks.
To make this work, a named extended ACL examines the traffic as it exits the network. The ACL can be applied inbound on an internal interface or outbound on the external interface. ACEs examine traffic associated with new sessions using the reflect parameter. Based on these statements (using reflect), the connection ACEs are built dynamically to permit return traffic. Without the reflect statements, return traffic is dropped by default. For example, an administrator could set up the ACL statements to examine only HTTP connections, thus allowing only temporary reflexive ACEs to be created for HTTP traffic.
As traffic is leaving the network, if it matches a permit statement with a reflect parameter, a temporary entry is added to the reflexive ACL. For each permit-reflect statement, the router builds a separate reflexive ACL.
A reflexive ACE is an inverted entry: the source and destination information is flipped. For example, a reflexive ACE is created if a user on a workstation with IP address 192.168.1.3 telnets to 209.165.200.5, where the source port number is 11000.
R1(config-ext-nacl)# permit host 209.165.200.5 eq 23 host 192.168.1.3 eq 11000
Any temporary reflexive ACEs that are created contain the permit action to allow the returning traffic for this session.
To configure a router to use reflexive ACLs involves just a few steps:
Step 1. Create an internal ACL that looks for new outbound sessions and creates temporary reflexive ACEs.
Step 2. Create an external ACL that uses the reflexive ACLs to examine return traffic.
Step 3. Activate the Named ACLs on the appropriate interfaces.
This is the syntax for the internal ACL.
Router(config)# ip access-list extended internal_ACL_name
Router(config-ext-nacl)# permit protocol source-addr [source-mask] [operator operand] destination-addr [destination-mask] [operator operand] [established] reflect reflexive_ACL_name [timeout seconds]
For example, these are the commands for matching internal users surfing the Internet with a web browser and relying on DNS.
R1(config)# ip access-list extended internal_ACL
R1(config-ext-nacl)# permit tcp any any eq 80 reflect web-only-reflexive-ACL
R1(config-ext-nacl)# permit udp any any eq 53 reflect dns-only-reflexive-ACL timeout 10
Cisco IOS creates two reflexive ACEs that maintain session information for outbound web connections (web-only-reflexive-ACL) and DNS queries (dns-only-reflexive-ACL). Notice that a 10-second timeout for DNS queries is set.
After building the internal extended Named ACL, which creates the reflexive ACEs, the temporary entries need to be referenced as traffic flows back into the network. This is done by building a second extended Named ACL. In this Named ACL, use the evaluate statement to reference the reflexive ACEs that were created from the internal ACL.
Router(config)# ip access-list extended external_ACL_name
Router(config-ext-nacl)# evaluate reflexive_ACL_name
Continuing the example with HTTP and DNS traffic, this syntax creates an external ACL that denies all traffic originating from the outside, but permits return HTTP and DNS traffic.
R1(config)# ip access-list extended external_ACL
R1(config-ext-nacl)# evaluate web-only-reflexive-ACL
R1(config-ext-nacl)# evaluate dns-only-reflexive-ACL
R1(config-ext-nacl)# deny ip any any
The last step is to apply the ACLs.
R1(config-if)# description connection to the ISP.
R1(config-if)# ip access-group internal_ACL out
R1(config-if)# ip access-group external_ACL in
Reflexive ACLs provided the first solution for session filtering on Cisco routers. Reflexive ACLs are one of the many types of complex ACLs supported on Cisco networking devices. Some complex ACLs are designed to permit dynamic connections through routers to be built on a per-user basis. Other complex ACLs are automatically enabled during particular dates and times.
Dynamic ACLs, also known as lock-and-key ACLs, were added as an option to Cisco IOS in 1996, before ACL logging and reflexive ACLs were available as options. Dynamic ACLs are available for IP traffic only. Dynamic ACLs are dependent on Telnet connectivity, authentication (local or remote), and Extended ACLs.
Dynamic ACL configuration starts with the application of an Extended ACL to block traffic through the router. Users who want to traverse the router are blocked until they use Telnet to connect to the router and are authenticated. The Telnet connection is then dropped, and a single-entry dynamic ACL is added to the existing extended ACL. This permits traffic for a particular period. Both idle and absolute timeouts are possible.
One reason to use dynamic ACLs is to provide a specific remote user or group of remote users access to a host within the network. Another reason to use dynamic ACLs is when a subset of hosts on a local network needs to access a host on a remote network that is protected by a firewall.
Dynamic ACLs offer these security benefits over standard and static extended ACLs:
A combination of user-prompted and automated device activities occur when a dynamic ACL is implemented and invoked.
First, a remote user must open a Telnet or SSH connection to the router. The external ACL of the router must permit this connection. The router prompts the user for a username and password, which the user must enter.
Next, the router authenticates the connection using either the local username database defined with username commands, an AAA server using RADIUS or TACACS+, or the password command on the vty lines. If the authentication is successful, the Telnet or SSH connection is terminated, because the function of the connection is for authentication only.
After the user successfully authenticates, Cisco IOS adds a dynamic ACL entry that grants the user access to the configured internal resources. It is not possible to set up per-user access policies. Instead, the administrator defines one policy for all dynamic ACL users, and this single policy is applied to all the authenticated users.
Finally, the user can access the internal resources that would otherwise be denied without the dynamic ACL entry.
There are a few basic steps for setting up a dynamic ACL:
Step 1. Create an Extended ACL.
A dynamic ACL supports both numbered and named extended ACLs. One of the first entries in the ACL permits Telnet or SSH access to an IP address on the router that the external users can use. Also, at a minimum, a placeholder entry is created in the ACL. The user's successful authentication creates this dynamic entry.
Step 2. Define the authentication.
A dynamic ACL supports these methods of authentication: local (the username database), an external AAA server, and the line password. Typically, the line password is not used because all users must use the same password.
Step 3. Enable the dynamic authentication method.
This occurs on the vty lines of the router. When enabled, the router can create dynamic ACL entries on the interface ACL that has the dynamic ACL reference.
This is the command to create the dynamic ACL entry.
Router(config)# access-list {100-199} dynamic dynamic_ACL_name [timeout minutes] {permit | deny} protocol source-addr [source-wildcard] [operator operand] destination-addr [destination-wildcard] [operator operand] [established]
The dynamic keyword lets an administrator specify the name of the dynamic ACL that is to be used. This name must be unique among all named ACLs on the router. The timeout parameter is optional. It specifies an absolute timeout for the dynamic entry that an authenticated user creates. The timeout can range from 1 to 9999 minutes.
Two timeouts are associated with dynamic ACL entries: absolute and idle. The absolute timer is specified in the dynamic ACL entry. The idle timeout value is specified in the autocommand command, which enables lock-and-key authentication on the vty lines. If timeouts are not specified, the default is to never time out the entry. Therefore, it is recommended that an idle or an absolute timeout be configured.
Following the timeout parameter in the ACL statement, specify which user traffic is permitted. Normally, the IP address of the external user is unknown, so use the keyword any.
After creating the Extended ACL to enable Telnet and/or SSH permission and the dynamic entries, activate it on the router interface with the ip access-group command.
With a local username database configured, the last thing to do is enable lock-and-key authentication on the vty lines.
Router(config)# line vty 0 4
Router(config-line)# autocommand access-enable host [timeout minutes]
The autocommand access-enable command specifies lock-and-key authentication. After a user successfully authenticates, a temporary ACL entry is inserted into the Extended ACL. This entry is placed at the dynamic parameter placeholder in the Extended ACL. The temporary entry is added only on the one interface to which the user connects. Without the autocommand access-enable command, the router will not create the temporary ACL entries.
The host parameter is optional. By specifying this parameter, the Cisco IOS replaces the dynamic ACL entry's keyword any with the user's IP address. If the Extended ACL is applied inbound, the source keyword any is replaced with the user's IP address; if it is applied outbound, the destination keyword any is replaced.
The optional timeout parameter is used to set the idle timeout for the user's temporary ACL entry.
Another useful complex ACL is the time-based ACL. Time-based ACLs, introduced to Cisco IOS in 1998, are similar to Extended ACLs in function, but they allow for access control based on time. Timed-based ACLs enable traffic to be restricted based on the time of day, the day of the week, or the day of the month.
Time-based ACLs offer the security professional more control over permitting or denying access to resources. Sometimes it is necessary to open a hole in the filter of a router to allow a specific type of traffic. This hole should not be allowed to remain indefinitely. For example, users could be allowed to access the Internet during lunch, but not during regular business hours. Timed ACLs enable the enforcement of this kind of policy.
Time-based ACLs also allow security professionals to control logging messages. ACL entries can log traffic at certain times of the day, but not constantly. The administrator can simply deny access without analyzing the many logs that are generated during peak hours.
Time-based ACLs are an extension of numbered and named Extended ACLs. The administrator creates time-based entries and uses the time-range parameter to specify the period of time that the ACL statement is valid. The period of time specified can be recurring or a specific instance that happens only once.
When creating a time range with the time-range command, it must have a unique name. The name must begin with a letter and cannot contain a space. Use this name later to associate a specific ACL statement with this range. Executing the time-range command places the router in ACL sub-configuration mode. In this mode, two types of ranges can be specified: one-time only (absolute) and recurring (periodic).
These are the commands for creating a time range.
Router(config)# time-range time_range_name
Router(config-time-range)# absolute [start_time start_date] [end_time end_date]
Router(config-time-range)# periodic day_of_the_week hh:mm to [day_of_the_week] hh:mm
The absolute command specifies a single time period for which the time range is valid. ACL statements that reference this time range are not used after this period. The administrator can specify a beginning time, an ending time, or both. The time is specified in 24-hour time: hh:mm, where the hours range from 0 to 23 and the minutes range from 0 to 59. For example, 3 p.m. is represented as 15:00. The date is specified as day month year. The day is specified as a number from 1 to 31; the month is the name of the month, such as May, and the year is a four-digit value, such as 2003. Examples of date specification are 19 November 2009 and 07 July 2010. If the starting time is omitted, it defaults to the current time on the router. If the ending time is omitted, it defaults to 23:59 31 December 2035.
The periodic command specifies a recurring time period for which the time range is valid. Multiple periodic commands are permitted within the same time range. Specify a beginning and ending time. The ending time can be on a different day. The first parameter specified is the day of the week:
The next parameter is the beginning time, specified as hh:mm. This is followed by the to parameter and the ending time. If the day of week parameter is omitted, it defaults to the day of week configured for the beginning time. Following this is the ending time, specified as hh:mm. It is important to note that the router clock must be set in order for this command to operate as expected.
After creating time ranges, the administrator must activate them. This is done by adding the time-range parameter to the ACL statement. This is supported in both named and numbered extended ACLs. This is the configuration syntax for a numbered ACL.
Router(config)# access-list {100-199} {permit | deny} protocol source-addr [source-mask] [operator operand] destination-addr [destination-mask] [operator operand] [established][log | log-input][established][time-range name_of_time_range]
The time range needs to be added to the ACL statement. When this is done, the ACL statement is processed by the Cisco IOS only when the time of the router falls within the period specified by the periodic or absolute commands defined in the time-range configuration.
A network administrator has a situation that requires time-based ACLs. Users are not allowed to access the Internet during business hours, except during lunch and after hours until 7 p.m. when the office closes. This is a time-based ACL that supports the requirement:
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)# interface FastEthernet 0/1
R1(config-if)# exit
In this example, the commands allow IP access to the Internet during lunch time and after work hours. ACL 100 permits employee traffic to the Internet during lunch and after work hours between 5 PM and 7 PM.
To verify ACL configuration, use the show access-lists command.
Router# show access-lists [access-list-number | access-list-name]
The command output shows how many packets have been matched against each entry in the ACLs, enabling the user to monitor the particular packets that have been permitted or denied.
To troubleshoot an ACL configuration, use the debug ip packet command.
Router# debug ip packet [access-list-number] [detail]
The debug ip packet command is useful for analyzing the messages traveling between the local and remote hosts. IP packet debugging captures the packets that are process-switched, including received, generated, and forwarded packets.
The detail option displays detailed IP packet debugging information. This information includes the packet types and codes as well as source and destination port numbers.
Because the debug ip packet command generates a substantial amount of output and uses a substantial amount of system resources, use this command with caution in production networks.
An ACL counter counts how many packets are matched (permitted or denied) by each line of the ACL. This number is displayed as the number of matches.
By checking the number of matches with the show access-lists command, an administrator can determine if the configured standard and extended IP ACLs are filtering properly. For example, if an entry has significantly more matches than expected, the entry may be too broad. This could indicate that the ACL is not having the intended effect on network traffic.
In the debug ip packet output, the denial of a packet is explicitly displayed. This enables granular real-time determination of successful ACL implementation.
The "g" in the debug ip packet output indicates the next hop gateway.
The debug output can be stopped with the undebug all command. Sometimes it takes a few moments before the output stops scrolling, depending on which debug commands were configured and the amount of traffic traversing the router.
The verification and troubleshooting commands for ACLs are relatively easy to use, and there are not many commands to remember. It is critical that ACLs are tested after they have been implemented to ensure their proper operation.
ACLs can be used to mitigate many network threats:
ACLs can also filter the following traffic:
DoS attacks tend to be the most devastating network attacks. Cisco IOS supports several technologies designed to minimize damage caused by DoS attacks. Most attacks use some type of spoofing. There are many well-known classes of IP addresses that should never be seen as source IP addresses for traffic entering an organization's network. There are specific ACLs that are easy to implement that prevent attacks being sourced with these types of addresses.
ICMP has been used extensively in network attacks over the years. Cisco IOS now supports specific technologies to prevent ICMP-based attacks from affecting a network.
As a rule, administrators should not allow any IP packets containing the source address of any internal hosts or networks inbound to a private network. An administrator can create an ACL that denies all packets containing the following IP addresses in their source field:
Administrators should not allow any outbound IP packets with a source address other than a valid IP address of the internal network. An administrator can create an ACL that permits only those packets that contain source addresses from inside the network and denies all others.
DNS, SMTP, and FTP are common services that often must be allowed through a firewall.
It is also quite common that a firewall needs to be configured to permit protocols that are necessary to administer a router. For example, it may be necessary to allow traffic through an internal router that permits router maintenance traffic from an outside device. Telnet, SSH, syslog, and SNMP are examples of services that a router may need to include. SSH is always preferred over Telnet.
Hackers use several ICMP message types to attack networks. However, various management applications use ICMP messages to gather information. Network management uses ICMP messages that are automatically generated by the router.
Hackers can use ICMP echo packets to discover subnets and hosts on a protected network and to generate DoS flood attacks. Hackers can use ICMP redirect messages to alter host routing tables. Both ICMP echo and redirect messages should be blocked inbound by the router.
Several ICMP messages are recommended for proper network operation and should be allowed inbound:
Several ICMP messages are recommended for proper network operation and should be allowed outbound:
As a rule, block all other ICMP message types outbound.
ACLs are used to block IP address spoofing, selectively permit specific services through a firewall, and to allow only required ICMP messages.
ACLs are a pervasive tool in network security. But there are other technologies that have been developed for the Cisco IOS to enhance firewall functionality. What are some technologies that augment traditional ACLs in creating a secure perimeter for an organization's network?
The term firewall originally referred to a fireproof wall (usually made of stone or metal) that prevented flames from spreading to connected structures. Later the term firewall was applied to the metal sheet that separated the engine compartment of a vehicle or aircraft from the passenger compartment. Eventually the term was adapted for use with computer networks: a firewall prevents undesirable traffic from entering prescribed areas within a network.
A firewall is a system or group of systems that enforces an access control policy between networks. It can include options such as a packet filtering router, a switch with two VLANs, and multiple hosts with firewall software.
Firewalls are different things to different people and organizations, but all firewalls share some common properties:
In 1988, DEC created the first network firewall in the form of a packet filter firewall. These early firewalls inspected packets to see if they matched sets of rules, with the option of forwarding or dropping the packets accordingly. This type of packet filtering, known as stateless filtering, occurs regardless of whether a packet is part of an existing flow of data. Each packet is filtered based solely on the values of certain parameters in the packet header, similar to how ACLs filter packets.
In 1989, AT&T Bell Laboratories developed the first stateful firewall. Stateful firewalls filter packets on information stored in the firewall based on data flowing through the firewall. The stateful firewall is able to determine if a packet belongs to an existing flow of data. Static rules, as in packet filter firewalls, are supplemented with dynamic rules created in real time to define these active flows. Stateful firewalls help to mitigate DoS attacks that exploit active connections through a networking device.
The original firewalls were not standalone devices, but routers or servers with software features added to provide firewall functionality. Over time, several companies developed standalone firewalls. Dedicated firewall devices enabled routers and switches to offload the memory- and processor-intensive activity of filtering packets. Modern routers, such as the Cisco Integrated Services Routers (ISRs), also can be used as sophisticated stateful firewalls for organizations that may not require a dedicated firewall.
There are several benefits of using a firewall in a network:
Firewalls also present some limitations:
It is important to understand the different types of firewalls and their specific capabilities to use the right firewall for each situation.
A firewall system can be composed of many different devices and components. One component is traffic filtering, which is what most people commonly call a firewall. There are several types of filtering firewalls, including the following:
Packet-filtering firewalls work primarily at the Network Layer of the OSI model. Firewalls are generally considered Layer 3 constructs. However, they permit or deny traffic based on Layer 4 information such as protocol, and source and destination port numbers. Packet filtering uses ACLs to determine whether to permit or deny traffic, based on source and destination IP addresses, protocol, source and destination port numbers, and packet type. Packet-filtering firewalls are usually part of a router firewall.
Services rely on specific ports to function. For example, SMTP servers listen to port 25 by default. Because packet-filtering firewalls filter traffic according to static packet header information, they are sometimes referred to as static filters. By restricting certain ports, an administrator can restrict the services that rely on certain ports. For example, blocking port 25 on a specific workstation prevents an infected workstation from broadcasting email viruses across the Internet.
Packet-filtering firewalls use a simple policy table lookup that permits or denies traffic based on specific criteria:
Packet filters do not represent a complete firewall solution, but they are an important element.
Stateful firewalls are the most versatile and the most common firewall technologies in use. Stateful firewalls provide stateful packet filtering using connection information maintained in a state table. Stateful filtering is a firewall architecture that is classified at the Network Layer, although for some applications it can also analyze traffic at Layer 4 and Layer 5.
Unlike static packet filtering, which examines a packet based on the information in a packet header, stateful filtering tracks each connection traversing all interfaces of the firewall and confirms that they are valid. Stateful firewalls use a state table to keep track of the actual communication process. The firewall examines information in the headers of Layer 3 packets and Layer 4 segments. For example, the firewall looks at the TCP header for synchronize (SYN), reset (RST), acknowledgment (ACK), finish (FIN), and other control codes to determine the state of the connection.
When an outside service is accessed, the stateful packet filter firewall retains certain details of the request by saving the state of the request in the state table. Each time a TCP or UDP connection is established for inbound or outbound connections, the firewall logs the information in a stateful session flow table. When the outside system responds to a request, the firewall server compares the received packets with the saved state to allow or deny network access.
The stateful session flow table contains the source and destination addresses, port numbers, TCP sequencing information, and additional flags for each TCP or UDP connection that is associated with that particular session. This information creates a connection object that is used by the firewall to compare all inbound and outbound packets against session flows in the stateful session flow table. The firewall permits data only if an appropriate connection exists to validate the passage of that data.
More advanced stateful firewalls include the ability to parse FTP port commands and update the state table to allow FTP to work transparently through the firewall. Advanced stateful firewalls can also provide TCP sequence number interpretation and DNS query and response matching to ensure that the firewall allows packets to return only in response to queries that originate from inside the network. These features reduce the threat of TCP RST flood attacks and DNS cache poisoning.
There is a potential disadvantage of using stateful filtering. While stateful inspection provides speed and transparency, packets inside the network must make their way to the outside network. This can expose internal IP addresses to potential hackers. Most firewalls incorporate stateful inspection, network address translation (NAT), and proxy servers for added security.
Cisco Systems provides several options for network security professionals to implement a firewall solution. These include the Cisco IOS Firewall, the PIX Security Appliances (this product is now end of life), and the Adaptive Security Appliances.
Cisco IOS Firewall is a specialized Cisco IOS feature that runs on Cisco routers. It is an enterprise-class firewall for support of small and medium-sized business (SMB) and enterprise branch offices.
The Cisco PIX Security Appliance is a standalone device that delivers robust user and application policy enforcement, multivector attack protection, and secure connectivity services. The Cisco PIX Security Appliances can scale to meet a range of requirements and network sizes.
Cisco ASA Adaptive Security Appliances are easy-to-deploy solutions that integrate firewall capabilities, Cisco Unified Communications (voice and video) security, Secure Sockets Layer (SSL) and IPsec VPN, IPS, and content security services. Designed as a key component of the Cisco Self-Defending Network, ASA provides intelligent threat defense and secure communications services that stop attacks before they affect business continuity. ASA was designed to protect networks of all sizes and lower organizations' overall deployment and operation costs by providing comprehensive multilayer security.
When choosing between the various options for a firewall solution, it is important to perform a cost versus risk analysis. Whatever decision is made for the purchase of a firewall solution, the proper network security design is critical for the successful deployment of a firewall.
In network security, there is often reference to a demilitarized zone (DMZ). A DMZ is a portion of a network bounded by a firewall or set of firewalls. The term was originally used as a military description for an area between military powers where conflict is not permitted.
DMZs define the portions of a network that are trusted and the portions that are untrusted. Firewall design is primarily about device interfaces permitting or denying traffic based on the source, the destination, and the type of traffic.
Some designs are as simple as designating an outside network and inside network, determined by two interfaces on a firewall. The outside network (or public network) is untrusted and the inside network (or private network) is trusted. In this case, traffic from the inside is usually permitted to traverse the firewall to the outside with little or no restrictions. Traffic originating from the outside is generally blocked entirely or very selectively permitted. Traffic returning from the outside that is associated with traffic originating from the inside is permitted to traverse from the untrusted interface to the trusted interface.
More complicated designs involve three or more interfaces on a firewall. In this case, there is typically one outside interface, one inside interface, and one DMZ interface. Traffic is permitted freely from the inside through the outside and DMZ interfaces. Traffic from the DMZ is permitted freely through the outside interface. Traffic from the outside is generally blocked entirely unless it is associated with traffic originating from the inside or the DMZ. However, with a DMZ, it is common for specific traffic types to be allowed from the outside, provided it is the right type of traffic and that it is destined for the DMZ. This type of traffic is typically email, DNS, HTTP, or HTTPS traffic.
In a layered defense scenario, firewalls provide perimeter security of the entire network and of internal network segments in the core. For example, network security professionals can use a firewall to separate the human resources or financial networks of an organization from other networks or network segments within the organization.
A layered defense uses different types of firewalls that are combined in layers to add depth to the security of an organization. For example, traffic that comes in from the untrusted network first encounters a packet filter on the outer router. The traffic goes to the screened firewall or bastion host system that applies more rules to the traffic and discards suspect packets. A bastion host is a hardened computer that is typically located in the DMZ. The traffic now goes to an interior screening router. The traffic moves to the internal destination host only after successfully passing through all filtering between the outside router and the inside network. This type of DMZ setup is called a screened subnet configuration.
A common misconception is that a layered firewall topology is all that is needed to ensure a safe internal network. This myth is probably encouraged by the booming firewall business. A network administrator must consider many factors when building a complete in-depth defense:
A network security professional is responsible for creating and maintaining a security policy, including a firewall security policy. This is a partial generic list that can serve as a starting point for firewall security policy:
A Cisco router running Cisco IOS Firewall is both a router and a firewall. If there are two firewalls, one design option is to join them with a LAN functioning as a DMZ. It also provides hosts in the untrusted public network redundant access to DMZ resources.
Context-based access control (CBAC) is a solution available within the Cisco IOS Firewall. CBAC intelligently filters TCP and UDP packets based on Application Layer protocol session information. It provides stateful Application Layer filtering, including protocols that are specific to unique applications, as well as multimedia applications and protocols that require multiple channels for communication, such as FTP and H.323.
CBAC can also examine supported connections for embedded NAT and PAT information and perform the necessary address translations. CBAC can block peer-to-peer (P2P) connections, such as those used by the Gnutella and KaZaA applications. Instant messaging traffic can be blocked, such as Yahoo!, AOL, and MSN.
CBAC provides four main functions: traffic filtering, traffic inspection, intrusion detection, and generation of audits and alerts.
Traffic Filtering
CBAC can be configured to permit specified TCP and UDP return traffic through a firewall when the connection is initiated from within the network. It accomplishes this by creating temporary openings in an ACL that would otherwise deny the traffic. CBAC can inspect traffic for sessions that originate from either side of the firewall. It can also be used for intranet, extranet, and Internet perimeters of the network. CBAC examines not only Network Layer and Transport Layer information but also examines the Application Layer protocol information (such as FTP connection information) to learn about the state of the session. 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.
Traffic Inspection
Because CBAC inspects packets at the Application Layer and maintains TCP and UDP session information, it can detect and prevent certain types of network attacks such as SYN-flooding. A SYN-flood attack occurs when a network attacker floods a server with a barrage of connection requests and does not complete the connection. The resulting volume of half-open connections overwhelms the server, causing it to deny service to valid requests. CBAC also helps to protect against DoS attacks in other ways. It inspects packet sequence numbers in TCP connections to see if they are within expected ranges and drops any suspicious packets. CBAC can also be configured to drop half-open connections, which require firewall processing and memory resources to maintain.
Intrusion Detection
CBAC provides a limited amount of intrusion detection to protect against specific SMTP attacks. With intrusion detection, syslog messages are reviewed and monitored for specific attack signatures. Certain types of network attacks have specific characteristics or signatures. When CBAC detects an attack based on those specific characteristics, it resets the offending connections and sends syslog information to the syslog server.
Alert and Audit Generation
CBAC also generates real-time alerts and audit trails. Enhanced audit trail features use syslog to track all network transactions and record timestamps, source and destination hosts, ports used, and the total number of transmitted bytes for advanced session-based reporting. Real-time alerts send syslog error messages to central management consoles upon detecting suspicious activity.
The first CBAC commands were introduced to Cisco IOS software in 1997. CBAC is a dramatic improvement over the TCP established and reflexive ACL firewall options in several fundamental ways:
It is important to note that CBAC only provides filtering for those protocols that are specified by an administrator. If a protocol is not specified, the existing ACLs determine how that protocol is filtered, and no temporary opening is created. Additionally, CBAC only detects and protects against attacks that travel through the firewall. It does not typically protect against attacks originating from within the protected network unless that traffic travels through an internal router with the Cisco IOS Firewall enabled.
While there is no such thing as a perfect defense, CBAC detects and prevents most of the popular attacks on a network. However, there is no impenetrable defense. Determined, skilled attackers can still find ways to launch effective attacks.
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.