<<

. 5
( 19)



>>

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 com-
98 CCNA Security Course Booklet, Version 1.0




plex 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.



4.1.6 Configuring Dynamic ACLs
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 con-
nect 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 ac-
cess 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:

Challenge mechanism to authenticate individual users



Simplified management in large internetworks



Reduced router processing for ACLs



Less opportunity for network break-ins by network hackers



Creation of dynamic user access through a firewall, without compromising other configured


security restrictions
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, be-
cause 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. In-
stead, the administrator defines one policy for all dynamic ACL users, and this single policy is ap-
plied to all the authenticated users.
Finally, the user can access the internal resources that would otherwise be denied without the dy-
namic 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.
Chapter 4: Implementing Firewall Technologies 99




Also, at a minimum, a placeholder entry is created in the ACL. The user™s successful authentica-
tion creates this dynamic entry.
Step 2. Define the authentication.
A dynamic ACL supports these methods of authentication: local (the username database), an exter-
nal 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 en-
tries 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 com-
mand, 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 authentica-
tion 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.


4.1.7 Configuring Time-Based ACLs
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.
100 CCNA Security Course Booklet, Version 1.0




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 al-
lowed to access the Internet during lunch, but not during regular business hours. Timed ACLs en-
able 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 spe-
cific 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 (ab-
solute) 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 spec-
ify 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 repre-
sented 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. Multi-
ple periodic commands are permitted within the same time range. Specify a beginning and end-
ing time. The ending time can be on a different day. The first parameter specified is the day of the
week:

monday



tuesday



wednesday



thursday



friday



saturday



sunday

Chapter 4: Implementing Firewall Technologies 101




daily (every day)



weekdays (Monday through Friday)



weekend (Saturday and Sunday)



The next parameter is the beginning time, specified as hh:mm. This is followed by the to parame-
ter and the ending time. If the day of week parameter is omitted, it defaults to the day of week con-
figured 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 ex-
pected.
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 em-
ployee-time
R1(config)# access-list 100 deny ip any any
R1(config)# interface FastEthernet 0/1
R1(config-if)# ip access-group 100 in
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 be-
tween 5 PM and 7 PM.


4.1.8 Troubleshooting Complex ACL Implementations
To verify ACL configuration, use the show command.
access-lists

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 command.
ip packet

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.
102 CCNA Security Course Booklet, Version 1.0




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 sub-
stantial 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 in-
dicate 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 granu-
lar real-time determination of successful ACL implementation.
The “g” in the debug output indicates the next hop gateway.
ip packet

The debug output can be stopped with the undebug all command. Sometimes it takes a few mo-
ments 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 imple-
mented to ensure their proper operation.



4.1.9 Mitigating Attacks with ACLs
ACLs can be used to mitigate many network threats:

IP address spoofing, inbound and outbound



DoS TCP SYN attacks



DoS smurf attacks



ACLs can also filter the following traffic:

ICMP messages, inbound and outbound



traceroute



DoS attacks tend to be the most devastating network attacks. Cisco IOS supports several technolo-
gies designed to minimize damage caused by DoS attacks. Most attacks use some type of spoof-
ing. 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 spe-
cific 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 in-
ternal hosts or networks inbound to a private network. An administrator can create an ACL that de-
nies all packets containing the following IP addresses in their source field:

Any local host addresses (127.0.0.0/8)

Chapter 4: Implementing Firewall Technologies 103




Any reserved private addresses (RFC 1918, Address Allocation for Private Internets)



Any addresses in the IP multicast address range (224.0.0.0/4)



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 neces-
sary 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 appli-
cations 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 in-
bound:

Echo reply - Allows users to ping external hosts.



Source quench - Requests the sender to decrease the traffic rate of messages.



Unreachable - Unreachable messages are generated for packets that are administratively


denied by an ACL.
Several ICMP messages are recommended for proper network operation and should be allowed
outbound:

Echo - Allows users to ping external hosts.



Parameter problem - Informs the host of packet header problems.



Packet too big - Required for packet maximum transmission unit (MTU) discovery.



Source quench - Throttles down traffic when necessary.



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 de-
veloped for the Cisco IOS to enhance firewall functionality. What are some technologies that aug-
ment traditional ACLs in creating a secure perimeter for an organization™s network?



4.2 Firewall Technologies
4.2.1 Securing Networks with Firewalls
The term firewall originally referred to a fireproof wall (usually made of stone or metal) that pre-
vented flames from spreading to connected structures. Later the term firewall was applied to the
104 CCNA Security Course Booklet, Version 1.0




metal sheet that separated the engine compartment of a vehicle or aircraft from the passenger com-
partment. Eventually the term was adapted for use with computer networks: a firewall prevents un-
desirable traffic from entering prescribed areas within a network.
A firewall is a system or group of systems that enforces an access control policy between net-
works. It can include options such as a packet filtering router, a switch with two VLANs, and mul-
tiple hosts with firewall software.
Firewalls are different things to different people and organizations, but all firewalls share some
common properties:

Resistant to attacks



Only transit point between networks (all traffic flows through the firewall)



Enforces the access control policy



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 pack-
ets 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 ac-
tive 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 fire-
walls. Dedicated firewall devices enabled routers and switches to offload the memory- and proces-
sor-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:

Exposure of sensitive hosts and applications to untrusted users can be prevented.



The protocol flow can be sanitized, preventing the exploitation of protocol flaws.



Malicious data can be blocked from servers and clients.



Security policy enforcement can be made simple, scalable, and robust with a properly


configured firewall.
Offloading most of the network access control to a few points in the network can reduce the


complexity of security management.
Firewalls also present some limitations:

If misconfigured, a firewall can have serious consequences (single point of failure).



Many applications cannot be passed over firewalls securely.



Users might proactively search for ways around the firewall to receive blocked material,


exposing the network to potential attack.
Chapter 4: Implementing Firewall Technologies 105




Network performance can slow down.



Unauthorized traffic can be tunneled or hidden as legitimate traffic through the firewall.



It is important to understand the different types of firewalls and their specific capabilities to use
the right firewall for each situation.


4.2.2 Types of Firewalls
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 fil-
tering firewalls, including the following:

Packet-filtering firewall - Typically is a router with the capability to filter some packet


content, such as Layer 3 and sometimes Layer 4 information.
Stateful firewall - Monitors the state of connections, whether the connection is in an


initiation, data transfer, or termination state.
Application gateway firewall (proxy firewall) - A firewall that filters information at Layers 3,


4, 5, and 7 of the OSI reference model. Most of the firewall control and filtering is done in
software.
Address-translation firewall - A firewall that expands the number of IP addresses available


and hides network addressing design.
Host-based (server and personal) firewall - A PC or server with firewall software running on


it.
Transparent firewall - A firewall that filters IP traffic between a pair of bridged interfaces.



Hybrid firewall - A firewall that is a combination of the various firewalls types. For example,


an application inspection firewall combines a stateful firewall with an application gateway
firewall.

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 in-
formation 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, proto-
col, 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 pre-
vents 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:

Source IP address



Destination IP address



Protocol



Source port number

106 CCNA Security Course Booklet, Version 1.0




Destination port number



Synchronize/start (SYN) packet receipt


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 con-
firms that they are valid. Stateful firewalls use a state table to keep track of the actual communica-
tion 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 con-
nection.
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 fire-
wall 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 pas-
sage 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 in-
spection, 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 enter-
prise-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 capa-
bilities, 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
Chapter 4: Implementing Firewall Technologies 107




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 net-
works 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.


4.2.3 Firewalls in Network Design
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 de-
scription 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 inter-
face to the trusted interface.
More complicated designs involve three or more interfaces on a firewall. In this case, there is typi-
cally 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 as-
sociated 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 traf-
fic.
In a layered defense scenario, firewalls provide perimeter security of the entire network and of in-
ternal network segments in the core. For example, network security professionals can use a fire-
wall 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 en-
counters 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 hard-
ened 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 significant number of intrusions come from hosts within the network. For example,


firewalls often do little to protect against viruses that are downloaded through email.
108 CCNA Security Course Booklet, Version 1.0




Firewalls do not protect against rogue modem installations. In addition, and most importantly,


a firewall is no substitute for informed administrators and users.
Firewalls do not replace backup and disaster recovery mechanisms resulting from attack or


hardware failure. An in-depth defense also includes offsite storage and redundant hardware
topologies.
A network security professional is responsible for creating and maintaining a security policy, in-
cluding a firewall security policy. This is a partial generic list that can serve as a starting point for
firewall security policy:

Position firewalls at key security boundaries.



Firewalls are the primary security device, but it is unwise to rely exclusively on a firewall for


security.
Deny all traffic by default, and permit only services that are needed.



Ensure that physical access to the firewall is controlled.



Regularly monitor firewall logs. Cisco Security Monitoring, Analysis, and Response System


(MARS) is especially useful in monitoring firewall logs.
Practice change management for firewall configuration changes.



Firewalls primarily protect from technical attacks originating from the outside. Inside attacks


tend to be nontechnical in nature.
A Cisco router running Cisco IOS Firewall is both a router and a firewall. If there are two fire-
walls, 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.



4.3 Context-Based Access Control
4.3.1 CBAC Characteristics
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 informa-
tion. 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 per-
form 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 informa-
tion but also examines the Application Layer protocol information (such as FTP connection infor-
mation) to learn about the state of the session. This allows support of protocols that involve
Chapter 4: Implementing Firewall Technologies 109




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 in-
formation, 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 re-
quests and does not complete the connection. The resulting volume of half-open connections over-
whelms 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 signa-
tures. Certain types of network attacks have specific characteristics or signatures. When CBAC de-
tects 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:

Monitors TCP connection setup



Tracks TCP sequence numbers



Inspects DNS queries and replies



Inspects common ICMP message types



Supports applications that rely on multiple connections



Inspects embedded addresses



Inspects Application Layer information



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 originat-
ing 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.
110 CCNA Security Course Booklet, Version 1.0




4.3.2 CBAC Operation
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 ap-
plication-aware. This means that the filter is able to recognize all sessions of a dynamic applica-
tion. 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 main-
tain information in a state table (or connection table) to keep track of these active sessions. This al-
lows 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 fil-
ter 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 tempo-
rary 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 preex-
isting 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 ap-
plied on the external interface preventing Telnet traffic from entering the protected network. This
connection goes through a multistep operation:

When the traffic is first generated, as it passes through the router, the ACL is
Step 1.
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.
Based on the inspection rules for CBAC, the Cisco IOS software might inspect
Step 2.
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.
The connection information is compared to entries in the state table. If the
Step 3.
connection does not currently exist, the entry is added. If it does exist, the idle timer for the
connection is reset.
If a new entry is added, a dynamic ACL entry is added on the external interface
Step 4.
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.
When the session terminates, the dynamic information from the state table and
Step 5.
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
Chapter 4: Implementing Firewall Technologies 111




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 use-
ful 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 re-
ceived 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 dis-
carded if the packets are invalid. How does CBAC determine if a packet is a subsequent packet be-
longing 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 acknowl-
edgment 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 ma-
chine. After the three-way handshake, all packets have the ACK flag set until the session is termi-
nated. 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 hand-
shake 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 config-
urable 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 proto-
cols 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
112 CCNA Security Course Booklet, Version 1.0




enforces the policy that if the initial session was permitted, any additional channels of that applica-
tion should be permitted as well.
With CBAC, the protocols to inspect are specified in an inspection rule. An inspection rule is ap-
plied to an interface in a direction (in or out) where the inspection applies. The firewall engine in-
spects 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:

Generate alert messages



Protect system resources that could impede performance



Block packets from suspected attackers



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:

Total number of half-opened TCP sessions



Number of half-opened sessions in a time interval



Number of half-opened TCP sessions per host



If a threshold for the number of half-opened TCP sessions is exceeded, the firewall has two op-
tions:

It sends a reset message to the endpoints of the oldest half-opened session, making resources


available to service newly arriving SYN packets.
It blocks all SYN packets temporarily for the duration that the threshold value is configured.


When the router blocks a SYN packet, the TCP three-way handshake is never initiated, which
prevents the router from using memory and processing resources that valid connections need.

4.3.3 Configuring CBAC
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
Chapter 4: Implementing Firewall Technologies 113




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 enter-
ing 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 sec-
ond interface connects to a network in a DMZ, and the third interface connects to the internal pro-
tected 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 ex-
tranet 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 organi-
zation™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 ad-
ministrator 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 inter-
faces. For example, an administrator might permit email traffic and at the same time block all Tel-
net traffic.
These are the guidelines for configuring IP ACLs on a Cisco IOS Firewall:

Start with a basic configuration. A basic initial configuration allows all network traffic to flow


from protected networks to unprotected networks while blocking network traffic from
unprotected networks.
Permit traffic that the Cisco IOS Firewall is to inspect. For example, if the firewall is set to


inspect Telnet, Telnet traffic should be permitted on all ACLs that apply to the initial Telnet
flow.
Use extended ACLs to filter traffic that enters the router from unprotected networks. For a


Cisco IOS Firewall to dynamically create temporary openings, the ACL for the return traffic
must be an extended ACL. If the firewall only has two connections, one to the internal
network and one to the external network, applying ACLs inbound on both interfaces works
well because packets are stopped before they have a chance to affect the router.
114 CCNA Security Course Booklet, Version 1.0




Set up antispoofing protection by denying any inbound traffic (incoming on an external


interface) from a source address that matches an address on the protected network.
Antispoofing protection prevents traffic from an unprotected network from assuming the
identity of a device on the protected network.
Deny broadcast messages with a source address of 255.255.255.255. This entry helps prevent


broadcast attacks.
By default, the last entry in an ACL is an implicit denial of all IP traffic that is not specifically


allowed by other entries in the ACL. Optionally, an administrator can add an entry to the ACL
that denies IP traffic with any source or destination address, thus making the denial rule
explicit. Adding this entry is especially useful if it is necessary to log information about the
denied packets.

Define inspection Rules
The administrator must define inspection rules to specify which Application Layer protocols to in-
spect at an interface. Normally, it is only necessary to define one inspection rule. The only excep-
tion 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 re-
turn traffic of active sessions. ICMP inspection allows ICMP echo reply packets forwarded as a re-
sponse 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 down-
load 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 (nor-
mally 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
Chapter 4: Implementing Firewall Technologies 115




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:

On the interface where traffic initiates, apply an ACL in the inward direction that permits only


wanted traffic and apply the rule in the inward direction that inspects wanted traffic.
On other interfaces, apply an ACL in the inward direction that denies all traffic, except traffic


that has not been inspected by the firewall, such as GRE and ICMP traffic that is not related to
echo and echo reply messages.

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 de-
nied because of the external ACL. Next, create inspection rules for TCP inspection and UDP in-
spection.
R1(config)# ip inspect name MYSITE tcp
R1(config)# ip inspect name MYSITE udp
116 CCNA Security Course Booklet, Version 1.0




These inspection rules are applied to the internal interface in the inbound direction.
R1(config)# interface Fa0/0
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 command.
ip inspect

Router(config)# no ip inspect
This command removes all CBAC commands, the state table, and all temporary ACL entries cre-
ated 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.


4.3.4 Troubleshooting CBAC
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 rec-
ommended that alerts are left enabled.
This is an example of an alert informing that someone is trying to send an unapproved SMTP com-
mand 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:

Sending a pipe (|) in the To or From fields of an email message



Sending :decode@ in the email header



Using old SMTP wiz or debug commands on the SMTP port



Executing arbitrary commands to exploit a bug in the Majordomo email program.



This is an example of an alert that is generated when a hacker tries to exploit the SMTP Major-
domo 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 at-
tempts. 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
Chapter 4: Implementing Firewall Technologies 117




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 cre-
ated, 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 ex-
tended 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.
118 CCNA Security Course Booklet, Version 1.0




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)
(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 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 25A3604 ftp L7 inspect result: PASS packet
*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 command replaces the
policy-firewall
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 ex-
treme 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.



4.4 Zone-Based Policy Firewall
4.4.1 Zone-Based Policy Firewall Characteristics
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 inspec-
tion 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 fire-
wall 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 struc-
ture 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 se-
curity professionals.
Chapter 4: Implementing Firewall Technologies 119




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 limi-
tations:

Multiple inspection policies and ACLs on several interfaces on a router make it difficult to


correlate the policies for traffic between multiple interfaces.
Policies cannot be tied to a host group or subnet with an ACL. All traffic through a given


interface is subject to the same inspection.
The process relies too heavily on ACLs.


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 implic-
itly 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:

Not dependent on ACLs.



The router security posture is to block unless explicitly allowed.



Policies are easy to read and troubleshoot with C3PL.



One policy affects any given traffic, instead of needing multiple ACLs and inspection actions.


When deciding whether to implement CBAC or zones, one important note is that both configura-
tion 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 con-
sider 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 net-
work to which the internal network is connected is one zone.
Step 2. Establish policies between zones - For each pair of “source-destination” zones (for exam-
ple, from inside network to Internet), define the sessions that clients in the source zones can re-
quest 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 unidi-
rectional 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

<<

. 5
( 19)



>>