Cisco IOS Firewall and Security Appliances

The Cisco IOS Firewall set feature provides a single point of protection at the network perimeter, making security policy enforcement an inherent component of the network. The IINS exam objectives covered in this chapter are as follows:

• Describe the operational strengths and weaknesses of the different firewall technologies
• Explain Stateful firewall operations and the function of the state table
• Implement Zone-Based Policy Firewall using SDM

Learn network security in detail on our Cisco CyberOps Associate Course.

This chapter is broken up into the following sections:

• Cisco IOS Firewall Overview
• Types of Firewalls
• Hardware versus Software Firewalls
• Cisco Security Appliances
• Context-Based Access Control
• Cisco Zone-Based Policy Firewall

Back to book index.

Cisco IOS Firewall Overview

The Cisco IOS Firewall set feature provides network security with integrated, inline security solutions and comprises a suite of services that allow administrators to provision a single point of protection at the network perimeter. The Cisco IOS Firewall set feature is a Stateful inspection firewall engine with application-level inspection. This provides dynamic control to allow or deny traffic flows, thereby providing enhanced security. Stateful inspection will be described in detail later in this chapter.

In its most basic form, the principal function of any firewall is to filter and monitor traffic. Cisco IOS routers can be configured with the IOS Firewall feature set in the following scenarios:

• As a firewall router facing the Internet;
• As a firewall router to protect the internal network from external networks, e.g. partners;
• As a firewall router between groups of networks in the internal network; and
• As a firewall router that provides secure connection to remote offices or branches.

The Cisco IOS Firewall provides an extensive set of security features that allow administrators to design customized security solutions tailored to the specific needs of their organization. The Cisco IOS Firewall is comprised of the following functions and technologies:

• Cisco IOS Stateful Packet Inspection
• Context-Based Access Control
• Intrusion Prevention System
• Authentication Proxy
• Port-to-Application Mapping
• Network Address Translation
• Zone-Based Policy Firewall

Cisco IOS Stateful Packet Inspection

Cisco IOS Stateful Packet Inspection (SPI) provides firewall capabilities designed to protect networks against unauthorized traffic and to control legitimate business-critical data. Cisco IOS SPI maintains state information and counters of connections, as well as the total connection rate through the firewall and intrusion prevention software. SPI will be described in detail later in this chapter.

Context-Based Access Control

Context-Based Access Control (CBAC) is a Stateful inspection firewall engine that provides dynamic traffic filtering capabilities. CBAC, also known as the Classic Firewall, will be described in detail later in this chapter.

Intrusion Prevention System

The Cisco IOS Intrusion Prevention System (IPS) is an inline intrusion detection and prevention sensor that scans packets and sessions flowing through the router to identify any of the Cisco IPS signatures that protect the network from internal and external threats. Cisco IPS solutions will be described in detail in the following chapter.

Authentication Proxy

The Authentication Proxy feature, also known as Proxy Authentication, allows administrators to enforce security policy on a per-user basis. With this feature, administrators can authenticate and authorize users on a per-user policy with access control customized to an individual level. Authentication Proxy configuration and detailed knowledge is beyond the scope of the IINS course requirements and will not be described in detail in this guide.

Port-to-Application Mapping

Port-to-Application Mapping (PAM) allows administrators to customize TCP or UDP port numbers for network services or applications to non-standard ports. For example, administrators could use PAM to configure standard HTTP traffic, which uses TCP port 80 by default, to use TCP port 8080. PAM is also used by CBAC, which uses this information to examine non-standard Application Layer protocols. PAM configuration and detailed knowledge is beyond the scope of the IINS course requirements and will not be described in detail in this guide.

Network Address Translation

Network Address Translation (NAT) is used to hide internal addresses, which are typically private addresses (i.e. RFC 1918 addresses), from networks that are external to the firewall. The primary purpose of NAT is address conservation for networks that use RFC 1918 addressing due to the shortage of globally routable IP (i.e. public) address space. NAT provides a lower level of security by hiding the internal network from the outside world. NAT configuration and detailed knowledge is beyond the scope of the IINS course requirements and will not be described in detail in this guide.

Zone-Based Policy Firewall

Zone-Based Policy Firewall (ZPF) is a new Cisco IOS Firewall feature designed to replace and address some of the limitations of CBAC, the Classic Firewall. ZPF allows Stateful inspection to be applied on a zone-based model, which provides greater granularity, flexibility, scalability, and ease-of-use over the Classic Firewall. ZPF is described in detail later in this chapter.

Types of Firewalls

A firewall protects networked computers from intentional hostile intrusion that could compromise confidentiality or result in data corruption or denial of service. Firewalls may be dedicated hardware-based devices, or even software-based programs that run on a secure computer or server. Firewalls must have at least two network interfaces, one for the network it is intended to protect, and one for the network it is exposed to. Basic firewalls consist of two main mechanisms.

The first mechanism is designed to block traffic. This could be traffic originating from external networks, such as the Internet, or internally, such as from restricted users and hosts. The second mechanism is designed to allow traffic. This traffic could be internally originated traffic (e.g. internal users accessing the Internet) or external traffic (e.g. Internet users accessing a company-owned web server). Firewalls fall into four broad categories:

1. Static or Network-Level Packet Filters
2. Circuit-Level Gateways
3. Application-Level Firewalls or Gateways
4. Stateful Inspection Firewalls

As is the case with any technology, firewalling capabilities have evolved as the methods of attacks used by intruders have evolved. Currently, there are four generations of firewall technology. First-generation firewalls were the first types of firewalls used to secure computer networks. These firewalls provided basic filtering capabilities at Layer 3 and Layer 4 of the OSI Model. Second-generation firewalls were introduced to provide further firewalling capabilities into the network. These firewalls allowed network security administrators to provide network security by monitoring traffic at Layer 3, Layer 4, and Layer 5 of the OSI Model.

Third-generation firewalls superseded second-generation firewalls and provided firewalling capabilities at Layer 3, Layer 4, Layer 5, and Layer 7 of the OSI Model. And, finally, the most recent (or the latest generation of) firewalls are fourth-generation firewalls. These firewalls operate at Layer 3, Layer 4, Layer 5, and Layer 7 of the OSI Model and use a concept referred to as Stateful inspection, which allows them to offer greater security than that offered by third-generation firewalls. Stateful inspection is described in detail later in this chapter.

Despite their generational differences, it is important to understand and keep in mind that different generations of firewalls can be used in conjunction with each other, as is often the case, to enhance network security. For example, first-generation firewalls can be used in conjunction with fourth-generation firewalls to provide additional security within a network.

Static or Network-Level Packet Filters

Static or Network-Level Packet Filters are first-generation firewalls. These firewalls work at the Network Layer of the OSI Model by inspecting packet headers and filtering traffic based on the IP address of the source and the destination, the port, and the service. Static packet filters can also filter packets based on protocols, the domain name of the source, and a few other attributes, depending on the software capabilities of the platforms they are implemented on.

Static packet filters are fast and relatively easy to implement. Cisco IP extended ACLs are examples of static packet filters that are supported in Cisco IOS routers and switches, as well as Cisco PIX and ASA firewalls. While static packet filters provide relatively advanced capabilities, they provide limited security capabilities in that they do not understand languages such as HTML and XML, and they are not capable of decoding SSL-encrypted packets to examine their content, for example. As a result, static packet filters cannot validate user inputs or detect maliciously modified parameters in a URL request, which leaves the network vulnerable to threats.

The following diagram illustrates how static packet filters (e.g. IP extended ACLs) can be used to protect internal networks from outside threats:

Figure 7.1. Static Packet Filters

The static packet filter illustrated in this diagram is an IP extended ACL configured and applied to the Serial0/0 interface of Internet-facing R1. This filter allows only WWW connections to the web server with the IP address 200.1.1.2/29 and allows only TCP packets that were originated by internal hosts on the 200.1.2.0/24 subnet to be permitted inbound on the Serial0/0 interface.

Network administrators could also configure network-level filters to control the flow of traffic between the internal user subnet (200.1.2.0/24) and the company web server, for example. The advantages of packet filtering firewalls are their low cost, in monetary terms, and their relatively low impact on network performance. Most routers support packet filtering. Even if other firewalls are used within the network, implementing packet filtering at the router level provides networks with an additional level of security, albeit a relatively low one.

Circuit-Level Gateways

Circuit-level gateways are second-generation firewalls. These firewalls work at the Session Layer of the OSI Model or the TCP layer of the TCP/IP Model. Circuit-level gateways monitor TCP handshaking between hosts to make sure a session is legitimate and are used to validate whether a packet is either a connection request or a data packet belonging to an established connection or virtual circuit.

Information passed to a remote computer through a circuit-level gateway appears to have originated from the gateway and not from the actual internal host. This is useful for hiding information about internal (protected) networks. While circuit-level gateways are relatively inexpensive and have the advantage of hiding information about the private network they protect, it is important to know that they provide relatively limited enhanced network security capabilities due to the fact that they do not filter individual packets. Circuit-level gateways are considered obsolete and have all but disappeared from the networks of today.

Application-Level Firewalls or Gateways

Application-Level Gateways (ALG) are third-generation firewalls. These firewalls evaluate packets for valid data at the Application Layer before allowing a connection. ALGs, which are also referred to as proxies, have the ability to looking more deeply into the Application Layer data going through their filters and, as such, can also filter at Layers 3, 4, and 5, in addition to their Layer 7 filtering capabilities. The two main functions of Application-Level Firewalls are to keep machines behind them anonymous and to speed up access to a resource via caching. Keep in mind that Application-Level Gateway and Application-Level Firewall are interchangeable terms; either can be used and they both refer to the same thing.

By considering the context of client requests and application responses, these firewalls attempt to enforce correct application behavior, block malicious activity, and help organizations ensure the safety of sensitive information and systems. They can also log user activity. Application-level filtering may include protection against spam and viruses as well, and may be able to block undesirable websites based on content rather than just their IP addresses. The following diagram illustrates the basic operation of an ALG:

Figure 7.2. Application-Level Gateways in Operation

In the diagram above, the internal host is attempting to connect to the web server belonging to www.howtonetwork.net. Because the host has been configured to use a proxy, this request is forwarded to 200.1.1.254, as illustrated in step 1. The ALG, or proxy, receives the request from the internal host and in turn contacts the Internet server on behalf of the host, as illustrated in step 2.

The Internet server receives a request from 200.1.1.254 (the ALG) and, assuming all defaults, sends the web page to the proxy, as illustrated in step 3. Finally, in step 4, the proxy then proceeds and forwards the page to the computer on the intranet, i.e. the internal host. The user is now connected to www.howtonetwork.net via the ALG.

There are many different types of proxies. Some of the most common ones are as follows:

• File Transfer Protocol (FTP) proxies
• SOCKS proxies
• Hypertext Transfer Protocol (HTTP) proxies
• Network Address Translation (NAT) proxies
• Secure Sockets Layer (SSL) proxies

NOTE: You are not required to demonstrate detailed knowledge on each of these different types of proxies. However, the following section provides a brief description of each type.

FTP proxies are used to relay and cache FTP traffic. SOCKS proxies allow for the relaying of far more different types of data, which could be TCP or UDP data. SOCKS is an Internet protocol that facilitates the routing of network packets between client-server applications via a proxy and performs at Layer 5 of the OSI Model. SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make.

HTTP proxies are used to provide a one-way request to retrieve web pages. An HTTP proxy analyses the HTTP headers sent through it in order to deduce the address of the server and therefore may only be used for HTTP traffic. NAT proxies allow for the redirection of all packets without a program having to support a proxy server.

And, finally, SSL proxies are an extension that was created to enhance the HTTP proxy server, which allows for the relaying of TCP data similar to a Socks proxy server. This is performed mainly to allow encryption of web page requests. SSL is a cryptographic protocol that provides security and data integrity for communications over networks such as the Internet. SSL encrypts the segments of network connections at the Transport Layer end-to-end.

Furthermore, a Proxy Server can be split into anonymous and transparent proxy servers. Anonymous proxy servers block the remote computer from knowing the identity of the computer using the proxy server to make requests. This is similar to the operation of Network Address Translation, which hides internal IP addresses from external users; however, it is important to keep in mind that these two technologies are distinctly different.

A transparent proxy server tells the remote computer the IP address of your computer. This provides no privacy as internal addresses are exposed to external users. Anonymous proxies can further be broken down into two more categories, which are elite and disguised.

An elite proxy is not identifiable to the remote computer as a proxy in any way. In other words, the remote host does not know that the originating host is using a proxy server. A disguised proxy gives the remote host enough information to let it know that it is a proxy; however, it is still considered secure because it does not give away the IP of the host that it is relaying information for. The destination host knows that it is talking to a proxy server; however, it does not know the IP address of the originating host.

Application- Level Firewalls provide the following advantages:

• They enhance network security by hiding internal networks. Proxies make connection requests on behalf of their clients, masking or hiding the IP addresses of those clients to external networks and devices.

• They authenticate individuals and not devices. Application-Level Firewalls allow connection requests to be authenticated before traffic is passed to internal or external resources. This allows administrators to authenticate the user making the connection request instead of the device on which the connection request is made.

• They make it more difficult for attackers to perform IP spoofing attacks. By performing NAT-like functions, and breaking up the end-to-end IP connection, proxies can prevent most spoofing attacks.

• They can be used to mitigate against DoS attacks. Application-Level Firewalls can detect DoS attacks and reduce the burden on internal resources, such as routers, etc. However, it should be noted that the proxy itself could fall victim to a DoS attack.

• They can monitor and filter application data, such as web addresses. Proxies have the ability to detect attacks such as malformed URLs, buffer overflow attempts, and unauthorized access. A Uniform Resource Locator (URL) is a subset of the Uniform Resource Identifier (URI) that specifies where an identified resource is available and the mechanism for retrieving it. A URI is commonly referred to as a web address. For example, JPEG files could be blocked based on matches, or language filters could dynamically detect unwanted programming language. If the content is rejected, the proxy returns an HTTP fetch error.

• They can provide detailed logging for security audits. ALGs have the capability to produce detailed logging information, as well as allow administrators to monitor the actual data an individual is sending across the connection.

However, despite these advantages, Application-Level Firewalls also have several disadvantages, which must be weighed during consideration. These disadvantages are as follows:

• They are not as efficient because more operations take place to inspect a packet. Proxies use up a lot of CPU cycles to handle many connections. Advanced filtering capabilities only add to this overhead.

• They come at a higher cost because of higher complexity. Cost is a factor when considering ALGs. Additional hardware such as memory and hard disk space may be needed to handle more connections and provide greater caching capabilities. These add to the proxy cost.

• They require manual updates for new or modified application protocols. Administrators must update proxies to filter modified protocols or applications. This increases the administration overhead.

• Attacks can still occur if there is a weakness in the application itself. For example, there could be a Java script buffer overrun, even though the underlying HTTP protocol has valid headers. This introduces potential security risks.

• Every protocol must have a proxy in order for the firewall to be completely effective. If administrators must allow the use of a protocol that the proxy does not specifically support, they are reduced to using a generic proxy. Generic proxies do not have any in-depth knowledge of the protocols they proxy, so they can only provide basic security checks based on the information contained within the headers of the packets.

• They improve performance reduction since application services have to go through a proxy. ALGs are slower at passing information than other firewalls because of the proxy applications.

• They are not transparent to end users and require manual configuration of each client computer. Client computers on a network with an ALG firewall need to be configured to be able to use the proxies to access resources outside the network.

Stateful Inspection Firewalls

Stateful firewalls are fourth-generation dynamic packet filtering firewalls and are the most common firewall technology used in modern-day networks. These firewalls operate at Layers 3, 4, and 5 of the OSI Model. Stateful firewalls differ significantly from Stateless firewalls, which were the norm in the networks of yesteryear. A Stateless firewall is a firewall that treats each packet in isolation. Because of this, Stateless firewalls have no way of knowing whether any given packet is part of an existing connection, is trying to establish a new connection, or is just a rogue packet. These limitations are addressed in Stateful firewalls.

Stateful firewalls perform Stateful Packet Inspection (SPI), or Stateful Inspection, and keep track of the state of network connections, such as TCP and UDP streams traveling across them. The Cisco IOS Firewall is a Stateful firewall that uses the inherent Stateful inspection engine of Cisco IOS Software for maintaining the detailed session database, which is referred to as the state table.

Stateful firewalls are able to hold a significant amount of attributes of each connection in memory, from start to finish. These attributes, which are known as connection states, may include such details as the IP addresses and port numbers involved in the connection, as well as the sequence numbers of the packets traversing the connection.

Once the initial connection request has been processed and screened, which is usually the most processor-intensive process, all packets after that, for that particular session, can then be processed rapidly because the firewall can determine whether they belong to an existing, pre-screened session. Once the session has ended, the entry for that connection is removed from the state table. The following diagram illustrates a basic Stateful firewall and state table operation:

Figure 7.3. Basic Stateful Firewall and State Table

Based on the diagram above, the internal host (10.1.1.1) initiates an HTTP connection to www.howtonetwork.net. Using DNS, the web address is translated to the IP address 172.16.1.1 and the packet is forwarded to the Stateful firewall. The Stateful firewall receives this packet and because it was originated internally, notes the TCP SYN and creates outbound session information that includes the source and destination IP addresses and ports, as well as the Transport Layer protocol, i.e. TCP.

The external web server receives this packet and sends back a SYN + ACK packet. The Stateful firewall receives this response and checks that either the ACK or the RST bit is set. In this case, the ACK bit is set in the SYN + ACK sent by the external web server. This check is performed to ensure that only internal hosts can initiate a TCP session to an external location, while preventing any external TCP sessions to the internal network. The check succeeds and a dynamic entry is created in the ACL to permit the return traffic.

The internal host acknowledges the SYN + ACK from the external server with an ACK packet and the TCP session is established. The session is then monitored in the state table. Once the session is terminated, the entry is removed from the state table.

As is the case with any other computing resources, the state table is not finite. In other words, it can be exhausted depending on the number of connections and the platform the Stateful firewall has been implemented on. Therefore, in order to prevent the state table from filling up, sessions will time out if no traffic has passed for a certain period, i.e. if they are idle for a certain amount of time. These stale connections are then removed from the state table to prevent it from being filled up by these sessions. To prevent application timeout due to this firewall behavior, many applications send keepalive messages periodically in order to stop a firewall from dropping the connection during periods of no user activity. Additionally, some firewalls can be configured to send these messages for applications.

Because Stateful firewalls maintain state information, they are susceptible to DoS attacks, with the most common type of attack being TCP SYN floods. These attacks aim to fill up the state tables of these firewalls by sending many SYN packets and not completing the TCP three-way handshake. These connections are referred to as embryonic or half-open connections. However, most firewalls, such as the Cisco IOS firewall and Cisco Adaptive Security Appliance, which will be described later in this chapter, can be configured to time out embryonic connections and clear them from the state table based on administrator-defined time thresholds.

Stateful firewalls provide the following advantages over packet filtering firewalls:

• They are aware of the state of a connection. Stateful firewalls build and maintain a state table to allow only return traffic from connections currently listed in the state table.

• They do not have to open up a large range of ports to allow returning traffic back into the network. Stateful firewalls use the state table to determine whether this is returning traffic (i.e. traffic originated on the internal network and destined to an external network or host), and if so, the connection is permitted; however, if this is not return traffic, the firewall’s filtering table is used to filter the traffic.

• They prevent more kinds of DoS attacks (e.g. TCP SYN attacks) than packet filtering firewalls. This is performed by using the state table to allow only legitimate connections into the network.

• They provide more-detailed logging capabilities than packet filter firewalls. Stateful firewalls can provide detailed logging information on when a connection was established, how long it was up for, and when it was disconnected, for example.

• They can dynamically open ports for certain applications, such as UDP ports used by Real-Time Protocol (RTP) for delivering audio and video over the IP networks, as well as for other audio and video standards, such as H.323.

However, despite their advantages, it is also imperative to know that Stateful firewalls are not infallible. Stateful firewalls have the following disadvantages:

• They can be very complex to configure. Some features in the Cisco ASA, which are described later in this chapter, are extremely complex to configure.

• They cannot prevent Application Layer attacks because they operate at Layers 3, 4, and 5 of the OSI Model. However, it should be noted that some Stateful firewalls, such as the Cisco ASA, can provide Application Layer inspection and filtering.

• They do not support the user authentication of connections. That is, Stateful firewalls do not authenticate sessions originated internally, destined to external networks or hosts.

• Some applications open up multiple connections and some use dynamic port numbers for the additional connections. FTP is a classic example of this.

• Stateful firewalls increase overhead due to the need to maintain state tables. This makes Stateful firewalls slower than packet filtering firewalls.

• Not all protocols contain state information. Examples of protocols that do not support state information are UDP and ICMP. However, it should be noted that Stateful firewalls can perform pseudo-Stateful tracking for UDP. Pseudo-Stateful tracking simply tracks IP addresses and port numbers for UDP because UDP does not use flags or sequence numbers as used by TCP. Additionally, even though TCP does support state information, certain aspects of it are not supported by Stateful firewalls. For example, Microsoft Windows Vista and Windows 7, uses TCP window scaling for non-HTT connections; however, this behavior is incompatible with some firewalls that use Stateful Packet Inspection.

Hardware versus Software Firewalls

The primary difference between a hardware-based firewall and a software-based firewall is the underlying dependency on the operating system on which the firewall is running. Hardware firewalls provide a strong degree of protection from most forms of attack coming from the outside to the internal network. Hardware firewalls can protect computers on a LAN and they can be implemented without much configuration difficulty.

Hardware firewalls are robust and built specifically for the purposes of firewalling. These dedicated devices are also less vulnerable to attack than software firewalls. Examples of hardware firewalls are the Cisco Packet Internetwork Exchange (PIX) firewall and the Cisco Adaptive Security Algorithm (ASA) firewall.

Software firewalls are installed on individual computers and they need sufficient configuration to be effective. Software firewalls contain a set of related programs, usually located at a network gateway server, that protect the resources of a private network from users on other networks or from internal users. Software firewalls allow application screening to verify the interaction between the requesting client and the requested resource.

An example of a software firewall is the Cisco IOS Firewall technology. This is integrated into the Cisco IOS software, providing a Stateful inspection firewall engine with application-level intelligence. Both hardware and software firewalls each have their own advantages and disadvantages. The advantages of hardware firewalls over software firewall are as follows:

• They can operate at greater speeds. Hardware firewalls are dedicated hardware designed for faster response times, and they can handle more traffic.

• They provide greater security than software firewalls. A firewall with its own dedicated operating system (proprietary) is less prone to attacks. This in turn reduces the security risk. For example, the Cisco PIX uses the Finesse Operating System.

• They have enhanced security controls. Because they are designed for a dedicated purpose, hardware firewalls typically provider greater controls.

• They provide less network interference. A physical box that is separated from other network components can be managed better and does not load or slowdown other applications. The box can be moved, shutdown, or reconfigured with minimal interference to the network.

However, despite their advantages, hardware firewalls also have the following disadvantages:

• They cost more. Pricing is a big concern because these are dedicated devices. Therefore, a dedicated hardware firewall typically is more expensive than a software firewall.

• They are difficult to install and upgrade. These dedicated devices are built to be secure and typically use proprietary operating systems. This makes it that much harder to implement, configure, and operate hardware firewalls.

• They typically take up physical space and involve wiring for network connectivity. While software firewalls can be integrated into existing servers, for example, hardware firewalls are standalone physical appliances that must be racked, stacked, and cabled to be integrated into the network.

The best preparation is to have a combination of both hardware and software firewalls. This allows you to have a well-protected system.

Cisco Security Appliances

NOTE: When reading this section, it is important to keep in mind that the emphasis of the IINS course is on the Cisco IOS Firewall feature set. You are not expected to perform any configuration or troubleshoot any Cisco hardware firewall technologies as a requirement.

The Cisco firewall technology provides a wealth of advanced security and networking services for small- to medium-sized enterprises, as well as service provider networks, in a modular, purpose-built solution. Cisco hardware firewall technologies come in three different forms:

• The Cisco PIX 500 Series Security Appliances
• The Cisco ASA 5500 Series Adaptive Security Appliances
• The Cisco Firewall Services Module 

The Cisco PIX 500 Series Security Appliances

The Cisco PIX 500 Series Security Appliances use a dedicated software engine that incorporates the Cisco Adaptive Security Algorithm (ASA), which will be described in the following section. The Cisco PIX 500 Series Security Appliances provide robust integrated network security services, including Stateful inspection, firewalling capabilities, Virtual Private Network (VPN) capabilities, and inline Intrusion Detection System capabilities. Intrusion Detection Systems (ISDs) will be described in detail later in this guide. The following table lists and provides a description of the Cisco PIX 500 Series devices:

Table 7.1. Cisco PIX 500 Series Models

Device Type	Description
Cisco PIX 501	The Cisco PIX 501 Security Appliance is a compact, plug-and-play security appliance for small office/home office (SOHO) environments. PIX 501 security appliances provide an integrated 4-port 10/100 FastEthernet switch and a dedicated 10/100 FastEthernet uplink.
Cisco PIX 506E	The Cisco PIX 506E Security Appliance is for remote office/branch office (ROBO) environments. The PIX 506E Security Appliance provides two auto-sensing 10/100 FastEthernet interfaces.
Cisco PIX 515E	The Cisco PIX 515E Security Appliance is a modular, high-performance security appliance for small- to medium-sized and enterprise network environments. The Cisco PIX 515E Security Appliance can support up to six 10/100 FastEthernet interfaces.
Cisco PIX 525	The Cisco PIX 525 Security Appliance provides GigabitEthernet connectivity for medium- to large-sized and enterprise network environments. The Cisco PIX 525 is capable of supporting up to eight 10/100 FastEthernet interfaces or three GigabitEthernet interfaces.
Cisco PIX 535	The Cisco PIX 535 Security Appliance is a modular, high-performance GigabitEthernet security appliance for service provider network environments. The Cisco PIX 535 can support up to ten 10/100 FastEthernet interfaces or nine GigabitEthernet interfaces, as well as redundant power supplies.

NOTE: The Cisco PIX 500 Series Security Appliances are End-of-Sale (EoS) and can no longer be ordered from Cisco. The recommended replacement, the Cisco ASA 5500 Series Security Appliance, is described in the following section.

The Cisco ASA 5500 Series Adaptive Security Appliances

The Cisco ASA security appliances deliver converged firewall, Intrusion Prevention System (IPS), advanced adaptive threat defense services (which include Anti-X defenses), application security, and VPN services. At the heart of the ASA 5500 Series design is the Adaptive Identification and Mitigation (AIM) architecture that provides proactive threat mitigation. The Cisco ASA 5500 Series Adaptive Security Appliance is an innovative appliance that builds on the depth and breadth of security features, combining the following three technologies:

• Firewall Technology
• Intrusion Prevention System (IPS) Technology
• VPN Technology

The Cisco ASA 5500 Series offers five high-performance, purpose-built (i.e. dedicated) appliances that span small- to medium-sized to large enterprises and service provider environments. The following table lists and describes the different ASA 5500 Series models:

Table 7.2. Cisco ASA 5500 Series Models

Device Type	Description
Cisco ASA 5505	The Cisco ASA 5505 Adaptive Security Appliance is a cost-effective, easy-to-deploy appliance for small business, branch office, and enterprise teleworker environments. This mode offers an integrated 8-port 10/100 FastEthernet switch, with two Power over Ethernet (PoE) ports.
Cisco ASA 5510	The Cisco ASA 5510 Adaptive Security Appliance is a cost-effective, easy-to-deploy appliance with advanced security and networking services for medium-sized businesses, remote office/branch office (ROBO), and enterprise environments.
Cisco ASA 5520	The Cisco ASA 5520 Adaptive Security Appliance provides high-availability services and GigabitEthernet connectivity. This model is suitable for medium-sized enterprise networks.
Cisco ASA 5540	The Cisco ASA 5540 Adaptive Security Appliance is a high-density, high-availability appliance that provides GigabitEthernet connectivity. This model is recommended for medium- to large-sized enterprise and service provider network environments.
Cisco ASA 5550	The Cisco ASA 5550 Adaptive Security Appliance is a Gigabit-class security appliance that offers up to 1.2Gbps of firewall throughput, with high-availability services, as well as GigabitEthernet and Fiber connectivity. This model is recommended for large enterprise and service provider network environments.

The Cisco Firewall Services Module

The Cisco Firewall Services Module (FWSM) is a high-speed, high-performance integrated firewall module that is installed in Cisco Catalyst 6500 Series switches or Cisco 7600 Series routers. The key features of the FWSM are:

• It is an integrated module. Because the module is installed into Cisco Catalyst 6500 Series switches or Cisco 7600 Series routers, it has the ability to provide advanced security services inside the network infrastructure.

• It provides superior performance and scalability. The FWSM offers the fastest firewall solution in the industry and has unprecedented rates. The FWSM can handle up to 5 Gbps of traffic, 100,000 connections per second, and 1 million concurrent connections. With the capacity to install up to four FWSMs in a single chassis, throughput can be increased up to 20 Gbps to meet growing demands.

• It is a proven technology. The FWSM software is based on the Cisco PIX technology and uses the same tried-and-tested Cisco PIX Operating System.

• It provides a lower Total Cost of Ownership (TCO). The FWSM can be used in virtualized firewall deployments, which allow for multiple firewalls on a single physical platform. Virtualization reduces the number of physical devices required in the network, minimizing complexity, enhancing operational efficiency, and reducing overall costs.

• It has a higher Return on Investment (ROI) than other firewall technologies. The FWSM provides higher ROI due to its flexible deployment, which leverages existing network infrastructure investments, e.g. the Cisco Catalyst 6500 Series switches.

Firewall Modes

Cisco security appliances can run in either routed firewall mode, which is the default, or in transparent firewall mode, which is essentially a Layer 2 firewall.

When running in routed firewall mode, the security appliance is considered to be a router hop in the network. For example, if you perform a Traceroute from an internal workstation to an external IP address, the Traceroute will show the firewall as one of the hops in the path from the source to the destination. This is illustrated in the following diagram:

Figure 7.4. IP Routed Firewalls are Counted as a Hop

As illustrated in the diagram above, a user performs a Traceroute from Host 1 to the IP address 14.1.1.2. Assuming that all routing is correctly configured, the packet traverses R1 and is then forwarded to the FW. Because the FW is running in routed mode (default), and assuming that the firewall is configured to allow Traceroute, the IP address of the firewall (which is in red font in the diagram above) is printed in the Traceroute from the source to the destination. However, for security purposes, firewalls in routed mode typically do not provide their IP address information, and in most Traceroutes, users will simple see a * (wildcard) in the Traceroute from source to destination.

Firewall software version 7.0 allows administrators to deploy Cisco security appliances in a secured bridging mode, referred to as the transparent firewall, or even the stealth firewall. In transparent mode, security appliances simply appear as a ‘bump in the wire’ and not as an actual router hop, as would be the case in routed firewall mode. In essence, the network is simply split into two Layer 2 segments and the appliance is placed in between these two segments, while Layer 3 remains unchanged. This is illustrated in the following diagram:

Figure 7.5. In Secured Bridging Mode Firewall not a Hop

In the diagram illustrated above, the Cisco security appliance is placed in between the switch and the Internet-facing router, effectively creating two LAN segments: one between the switch and the firewall, and the other between the firewall and the router. However, from a Layer 3 (Network) perspective, the two hosts connected to the switch reside on the same IP subnet as the router. These hosts both have their default gateway pointing to R1. Taking this concept an additional step further, the Traceroute example that was used in the routed firewall section would show the following when the security appliance was operating in transparent mode:

Figure 7.6. Firewall not Shown in Traceroute

As illustrated in the diagram above, even though the security appliance is physically present and is segmenting the network at the Data Link Layer, it is invisible at the Network Layer in the Traceroute. The user is unaware that there is even a firewall in the path.

While it is commonly thought that transparent firewalls are unable to provide the same functionality as routed firewalls, this belief is incorrect. In fact, the Cisco security appliance deployed in transparent mode continues to perform Stateful inspection with Application Layer intelligence and still possesses regular firewalling capabilities. Additionally, the security appliance in transparent mode can also perform Network Address Translation (NAT).

In transparent mode, the egress interface of the security appliance is determined by performing a MAC address lookup instead of a route lookup. The only Layer 3 addressing required on a transparent firewall is the management IP address, which is used as the source IP address for packets originating from the security appliance, such as AAA and Syslog messages. The management IP address, however, must reside on the same connected subnet.

While transparent mode is a good technique to protect the network passively, i.e. without an intruder or attacker detecting the existence of a firewall (e.g. via Traceroutes), there are some restrictions that should be taken into consideration.

The first restriction is that transparent firewalls do not support IP routing protocols, such as OSPF, RIP, and EIGRP, because they operate in bridged (Layer 2) mode. The second restriction is that while static routes may be configured on the transparent firewall, they can only be used for traffic that originates from the security appliance and not for traffic that will traverse the security appliance. This is a common misconception.

However, despite these restrictions, it is important to remember that transparent firewalls do allow IP routing protocols through the firewall, as long as ACLs on the firewall permit these protocols through. For example, an EIGRP neighbor relationship can be established between two EIGRP-enabled routers separated by a security appliance in stealth mode.

Application Layer Protocol Inspection

In addition to Stateful firewall capabilities, the Adaptive Security Algorithm provides built-in Application Layer intelligence that assists in detecting and preventing both protocol and Application Layer attacks. The Adaptive Security Algorithm is able to do so by performing deep packet inspection of Application Layer traffic, such as HTTP, by checking the IP header and payload (data) contents. This differs from conventional Stateful firewalls that can only maintain session state information details.

Application awareness allows the security appliance to perform deep packet inspection in the data for any malicious activity. Advanced network attacks that tunnel viruses or worms in HTTP traffic, for example, cannot be detected by traditional Stateful firewalls. However, the security appliance, armed with application inspection, which is enabled by default for most standard well-known protocols with specific TCP and UDP port numbers (e.g. HTTP, DNS, and FTP), provides protection from these attacks that attempt to use embedding techniques to pass malicious traffic encapsulated in other well-known Application Layer protocols.

Adaptive Security Algorithm Operation

There are three basic operational functions that form the basis of the Adaptive Security Algorithm (ASA) in Cisco security appliances:

• Access Control Lists
• Xlate and Conn Tables
• Inspection Engine

ACLs are used to control network access based on specific networks, hosts, and services, such as TCP and UDP port numbers.

Cisco security appliances utilize xlate and conn tables (i.e. translation and connection tables) to maintain state information for each connection. This state information can then be used by the ASA and cut-through proxy to forward traffic effectively within established connections.

The inspection engine is used by security appliances to perform Stateful inspection as well as Application Layer inspection functions. These inspection rule sets are predefined to validate application compliance, as mandated in RFCs and other standards, and cannot be modified in any manner by administrators or other users.

The following diagram illustrates how these three functions work together with security appliances:

Figure 7.7. ASA Operation

Going by the diagram illustrated above, in step 1, Host 1 initiates an HTTP connection to the www.howtonetwork.net address, and a TCP SYN packet destined to the server is sent and then received by the security appliance. The security appliance receives the packet and checks the ACL database to determine whether the connection is permitted. For simplicity’s sake, we will assume that it is.

The security appliance creates a new entry in the connection database (xlate and conn tables), as illustrated in step 2, using the necessary session information, i.e. source and destination IP address pair, protocol type, and the source and destination port number pair.

The security appliance then proceeds and checks the predefined rule sets in the inspection engine, as illustrated in step 3, and performs further Application Layer inspection. Based on these predefined rule sets, and the outcome of the check, the security appliance can either forward or drop the packet. In this example, we will assume that all checks succeed and the packet is forwarded to the www.howtonetwork.net server, as illustrated in step 4.

When the server receives the SYN packet from Host 1, it responds by sending a SYN + ACK back to the host, as illustrated in step 5.

The security appliance receives the server’s response, performs the inspection, and then looks up the connection information in the connection table (xlate and conn tables) to determine whether the session information matches an existing session, as illustrated in step 6.

Once the connection table has been verified, and the security appliance has matched the response from the server to an existing connection, the packet is forwarded to Host 1, as illustrated in step 7, because it belongs to an existing session, i.e. a session that was originated by an internal host to an external network or destination. Host 1 then sends an ACK packet to the server and the HTTP session is established.

Context-Based Access Control

NOTE: CBAC is described in this section for the purposes of being thorough. However, CBAC is being replaced by the Zone-Based Policy Firewall (ZPF). ZPF is a mandatory requirement of the IINS course, while CBAC is viewed as a related topic.

Context-Based Access Control (CBAC) is also commonly referred to as the Classic Firewall. CBAC is a part of the Cisco IOS Firewall set and it provides an advanced firewall engine, which provides advanced traffic-filtering functionality to Cisco IOS routers. The main features of Context-Based Access Control are as follows:

• It protects internal networks from external intrusion;
• It provides DoS protection;
• It provides per-application control mechanisms;
• It examines Layer 3 and Layer 4, as well as Application Layer, information;
• It maintains state information for every connection;
• It generates real-time event alert failures and log messages; and
• It provides enhanced audit trail features.

CBAC provides network protection by offering traffic filtering and traffic inspection capabilities, as well as alerts and audit trails.

Traffic Filtering

CBAC is a software-based firewall feature that offers dynamic traffic filtering capabilities to filter TCP and UDP packets based on Application Layer protocols, such as HTTP. In order for CBAC to work, the network must be divided into trusted (internal) and untrusted (external) logical segments. The principle of CBAC traffic filtering is that it allows any and all traffic originated from the trusted (internal) network to go out to the untrusted (external) network.

Traffic Inspection

CBAC inspects all traffic that traverses the firewall and maintains state information for all TCP and UDP sessions. This state information is then used to create temporary (dynamic) openings through the firewall to allow access to returning traffic that was originated internally.

CBAC also provides deep packet inspection capabilities that look into the payload (data) of Application Layer protocols for malicious activity, e.g. viruses and worms. This prevents attacks that use embedding techniques to pass malicious traffic by encapsulating it into well-known protocols, such as HTTP and SMTP (E-Mail).

Alerts and Audit Trails

CBAC can generate real-time event alerts and audit trails for all session information maintained in the state table. The enhanced audit trail feature uses Syslog to track all network transactions, recording information such as source and destination address pairs, port information, bytes transmitted, and connection duration, for example. For any suspicious activity, CBAC can be configured to send real-time event alerts using Syslog notification messages. CBAC inspection rules can be configured for reporting event alerts and audit trail information on a per-application-protocol basis.

Understanding CBAC Operation

This section describes the basic operation of CBAC, i.e. how it inspects packets and maintains state table information for all connections, allowing it to provide intelligent packet filtering.

CBAC performs per-protocol inspection. Each protocol that requires inspection is individually enabled and an interface and interface direction (i.e. inbound or outbound) is specified to determine where the inspection occurs. Only the protocols specified by the administrator will be inspected by CBAC. All other protocols that are not specified continue uninterrupted, although they may be subject to other router functions, such as NAT or ACL restrictions, etc.

Packets that enter the firewall are subject to inspection only if they first pass the inbound ACL at the input interface and outbound ACL at the output ACL. If a packet is denied by the ACL, the router will simply drop it without CBAC inspection. For TCP inspection, CBAC will keep track of TCP sequence numbers, and any packets with sequence numbers that are not in the expected ranges will be dropped.

CBAC uses several timeout and threshold values to manage session state information. These values help determine when to drop sessions that do not become fully established, which allows CBAC to free up system resources, e.g. memory and CPU. CBAC sends a reset message for all dropped sessions, sending one message to the source and another to the destination. CBAC monitors these thresholds as follows:

• The number of embryonic (half-open) sessions based on time
• The total number of half-open (embryonic) TCP or UDP sessions
• The number of per-host embryonic TCP sessions

As is the case with Stateful firewalls, CBAC maintains a session state table and for every incoming packet, the state table is updated with information pertaining to the session, which typically includes source and destination address pairs, protocol information, and port information for the session. For UDP, CBAC does not maintain state information because of the fact that UDP is a connectionless protocol; however, all returning UDP packets are checked with the idle timeout period to ensure that they have the corresponding source and destination IP addresses and port numbers.

Finally, CBAC uses the connection information in the state table to open dynamic holes in the firewall access list to allow returning traffic that would normally be blocked. CBAC performs this action by dynamically adding and removing ACL entries at the firewall interfaces. However, it is important to remember that these dynamically created ACL entries are temporary and are not saved into NVRAM; that is, if the router is reloaded, the dynamic ACL entries created by CBAC are not retained.

Configuring and Verifying CBAC

NOTE: You are not required to perform any CBAC configuration for the IINS course; however, because you may be called upon to answer questions based on provided configurations, this section has been included.

CBAC configuration and verification is a straightforward process that involves six basic steps:

1. Select an internal and external interface. An internal interface refers to the internal or trusted side where sessions must originate for traffic to be allowed through the firewall. The internal interface is also referred to as the trusted interface and is typically the router LAN interface. The external interface, on the other hand, refers to the untrusted and unprotected side where sessions should not originate, e.g. the Internet. Sessions originating from the external side should be blocked unless explicitly permitted. The concept of internal and external interfaces is illustrated in the following diagram:

Figure 7.8. CBAC Internal and External Interfaces

As illustrated in the diagram above, R1 has been enabled for CBAC and has two defined trust boundaries. The FastEthernet0/0 interface resides on the inside and everything behind it (i.e. Host 1 and Server 1) is trusted. The Serial0/0 interface resides on the outside and everything in front of it (i.e. the Internet) is untrusted. Traffic from inside hosts to the Internet is permitted by default; however, traffic from the Internet (untrusted) will be denied by default, unless explicitly permitted.

2. Configure an IP extended ACL. For CBAC to work, an ACL must be configured and implemented in order to create temporary openings through the firewall to allow return traffic. You cannot use a standard ACL; only named or numbered IP extended ACLs can be used in conjunction with CBAC. As a general rule, explicitly permit network traffic that originates from untrusted networks or hosts (e.g. the Internet) and is destined for the trusted network (e.g. company-owned web servers); all other traffic from untrusted networks or hosts to the trusted network or hosts should be denied. IP extended ACLs are configured using the access-list [100-199|2000-2699] or ip access-list extended [name] global configuration commands for numbered and named IP extended ACLs, respectively.

3. Define an inspection rule. This rule is created to specify which IP traffic, i.e. Application Layer protocols, will be inspected by the firewall engine. Inspection rules should specify each desired Application Layer protocol, as well as the generic TCP or UDP protocols. The inspection rule consists of a series of statements, each listing a protocol, which specifies the same inspection rule name. Inspection rule statements can include other options, such as controlling alert and audit trail messages, as well as checking IP fragmentation. Inspection rules are configured using the ip inspect name [name] [protocol] global configuration command. The same name is used for all protocols to be inspected.

4. Configure global timeouts and thresholds. This step is optional and presents advanced options, which are beyond the scope of the IINS course requirements. Global timeout and threshold configuration will not be described in this guide.

5. Apply the ACL and inspection rule to an interface. CBAC inspection should be applied to the external (outbound) interface when configuring CBAC for outbound traffic. This is performed by using the ip inspect [name] out interface configuration command. CBAC should be applied to the internal interface (inbound) when configuring CBAC for inbound traffic. This is performed by using the ip inspect [name] in interface configuration command. ACLs are applied to interfaces using the ip access-group [name|number] [in|out] interface configuration command.

6. Verify CBAC configuration and operation by using the show ip inspect [options] command to view configuration and statistical information for CBAC.

The following section provides CBAC configuration examples based on the following diagram:

Figure 7.9. CBAC Network

In the following configuration example, CBAC is configured on R1 as follows:

• The ACL is configured to deny all traffic; CBAC will create dynamic entries as needed.
• CBAC is configured to use an inspection rule named IINS-CBAC.
• CBAC is configured to inspect all HTTP (TCP) traffic.
• The CBAC inspection rule will be applied to the Se0/0 interface of R1 for outbound traffic.
• The CBAC inspection rule will be applied to the Fa0/0 interface of R1 for inbound traffic.

R1(config)#access-list 100 deny ip any any R1(config)#ip inspect name IINS-CBAC http R1(config)#ip inspect name IINS-CBAC tcp R1(config)#int se0/0 R1(config-if)#ip inspect IINS-CBAC out R1(config-if)#ip access-group 100 in R1(config-if)#exit R1(config)#int fa0/0 R1(config-if)#ip inspect IINS-CBAC in R1(config-if)#ip access-group 100 out R1(config-if)#exit

Once configured, administrators can validate CBAC operation by using the show ip inspect [options] command. The options available with this command are illustrated below:

R1#show ip inspect ? all           Inspection all available information config        Inspection configuration interfaces    Inspection interfaces mib           FW MIB specific show commands name          Inspection name sessions      Inspection sessions sis           Inspection sessions (debug version) statistics    Inspection statistics tech-support  Inspection technical support

The options printed by this command that you should be aware of are in the following table:

Table 7.3. ‘ip inspect’ Options

Keyword	Description
name [name]	Used to view the configuration for the rule specified
config	Used to view the complete CBAC inspection configuration
interfaces	Used to view the interface configuration, i.e. inspection rules and ACLs
session [detail]	Used to view sessions currently being tracked and inspected by CBAC
all	Used to view all CBAC configuration and all existing sessions

The following output illustrates an HTTP session on R1, from Host 1 to the Internet server:

R1#show ip inspect sessions Established Sessions Session 84362E94 (172.1.1.15:3624)=>(200.1.1.254:80) http SIS_OPEN

The show ip inspect sessions detail provides detailed session information as follows:

R1#show ip inspect sessions detail Established Sessions Session 84362E94 (172.1.1.15:3624)=>(200.1.1.254:80) http SIS_OPEN Created 00:01:59, Last heard 00:01:57 Bytes sent (initiator:responder) [425:200] Out SID 200.1.1.254[80:80]=>172.1.1.15[3624:3624] on ACL 100 In  SID 200.1.1.254[80:80]=>172.1.1.15[3624:3624] on ACL 100  (4 matches)

In the following configuration example, CBAC is configured on R1 as follows:

• The ACL is configured to explicitly permit TCP WWW traffic to internal server 172.16.1.254.
• The ACL is configured to deny all other IP traffic.
• CBAC is configured to use an inspection rule named IINS-CBAC.
• CBAC is configured to inspect all ICMP and SMTP (UDP) traffic.
• The CBAC inspection rule will be applied to the Se0/0 interface of R1 for outbound traffic.
• The CBAC inspection rule will be applied to the Fa0/0 interface of R1 for inbound traffic.

R1(config)#ip access-list extended CBAC-ACL R1(config-ext-nacl)#permit tcp any host 172.16.1.254 eq 80 R1(config-ext-nacl)#deny ip any any R1(config-ext-nacl)#exit R1(config)#ip inspect name IINS-CBAC icmp R1(config)#ip inspect name IINS-CBAC smtp R1(config)#ip inspect name IINS-CBAC udp R1(config)#int s0/0 R1(config-if)#ip inspect IINS-CBAC out R1(config-if)#ip access-group CBAC-ACL in R1(config-if)#exit R1(config)#int f0/0 R1(config-if)#ip inspect IINS-CBAC in R1(config-if)#ip access-group CBAC-ACL out R1(config-if)#exit

To view detailed session information for CBAC for a ping from Host 1 to the Internet server, for example, the show ip inspect sessions detail command is used, as illustrated below:

R1#show ip inspect sessions detail Established Sessions Session 84362BCC (172.1.1.15:8)=>(200.1.1.254:0) icmp SIS_OPEN Created 00:00:09, Last heard 00:00:06 ECHO request Bytes sent (initiator:responder) [128:128] Out SID 200.1.1.254[0:0]=>172.1.1.15[0:0] on ACL CBAC-ACL In  SID 200.1.1.254[0:0]=>172.1.1.15[0:0] on ACL CBAC-ACL  (4 matches) Out SID 0.0.0.0[0:0]=>172.1.1.15[3:3] on ACL CBAC-ACL In  SID 0.0.0.0[0:0]=>172.1.1.15[3:3] on ACL CBAC-ACL Out SID 0.0.0.0[0:0]=>172.1.1.15[11:11] on ACL CBAC-ACL In  SID 0.0.0.0[0:0]=>172.1.1.15[11:11] on ACL CBAC-ACL

To view all CBAC configuration parameters, the show ip inspect config command is used as follows:

R1#show ip inspect config Session audit trail is disabled Session alert is enabled one-minute (sampling period) thresholds are [unlimited : unlimited] connections max-incomplete sessions thresholds are [unlimited : unlimited] max-incomplete tcp connections per host is unlimited. Block-time 0 minute. tcp synwait-time is 30 sec — tcp finwait-time is 5 sec tcp idle-time is 3600 sec — udp idle-time is 30 sec tcp reassembly queue length 16; timeout 5 sec; memory-limit 1024 kilo bytes dns-timeout is 5 sec Inspection Rule Configuration  Inspection name IINS-CBAC icmp alert is on audit-trail is off timeout 10 smtp max-data 20000000 alert is on audit-trail is off timeout 3600 udp alert is on audit-trail is off timeout 30

Alternatively, the show ip inspect interfaces command can also be issued. This command allows administrators to view interface CBAC configuration, as illustrated in the output below:

R1#show ip inspect interfaces Interface Configuration Interface Serial0/0 Inbound inspection rule is not set Outgoing inspection rule is IINS-CBAC icmp alert is on audit-trail is off timeout 10 smtp max-data 20000000 alert is on audit-trail is off timeout 3600 udp alert is on audit-trail is off timeout 30   Inbound access list is CBAC-ACL Outgoing access list is not set Interface FastEthernet0/0 Inbound inspection rule is IINS-CBAC icmp alert is on audit-trail is off timeout 10 smtp max-data 20000000 alert is on audit-trail is off timeout 3600 udp alert is on audit-trail is off timeout 30 Outgoing inspection rule is not set Inbound access list is not set Outgoing access list is CBAC-ACL

Before we move on to the next section of this chapter, there are several Cisco IOS Firewall enhancements that were introduced in Cisco IOS software 12.3(T) and 12.4 Mainline. While going into configuration detail on each of these features is beyond the scope of the IINS course requirements, the features are described briefly. These features are as follows:

• HTTP Inspection Engine
• E-Mail Inspection Engine
• Inspection of Router-Generated Traffic
• Firewall ACL Bypass
• Transparent IOS Firewall

The HTTP Inspection Engine in the Cisco IOS Firewall has been enhanced with the introduction of Advanced Application Inspection and Control. This allows for deep packet inspection of HTTP traffic, which may be used by attackers to embed malicious traffic, such as worms and Trojans, for example. Any HTTP packets that do not conform to standards in HTTP are dropped and a reset message is sent out to both source and destination. Additionally, the router also sends out a Syslog message.

The E-Mail Inspection Engine in the Cisco IOS Firewall adds support for ESMTP, Post Office Protocol (POP) 3, and Internet Message Access Protocol (IMAP). ESMTP, which stands for Enhanced Simple Mail Transport Protocol, is similar to the basic SMTP and provides a basic method for exchanging e-mail messages. However, ESMTP specifies service extensions to the original SMTP standard that support graphics, audio and video files, and text in various national languages. ESMTP also uses the EHLO command, which is not used in SMTP. An ESMTP client starts a connection by using the EHLO command, instead of the HELO command that is used in SMTP. Advanced application inspection in the Cisco IOS Firewall prevents protocol masquerading and enforces strict RFC standards.

The inspection of router-generated traffic allows CBAC to inspect TCP, UDP, and H.323 (which is used in voice communications) connections that may have the firewall as one of the connection endpoints. For example, CBAC now has the ability to inspect Telnet sessions originated from the router, which negates the need to explicitly permit the traffic in the IP extended ACL used in conjunction with CBAC.

The Firewall ACL Bypass feature allows a packet to avoid redundant ACL checks by allowing the firewall to permit the packet on the basis of existing inspection sessions instead of dynamic ACLs. Thus, input and output dynamic ACL searches are eliminated, improving the overall throughput performance of the base engine. Because input and output dynamic ACLs are no longer necessary, the need for CBAC to create dynamic ACLs on the interface is eliminated. This results in improved connections-per-second performance of the firewall, as well as reduced run-time memory consumption of the firewall. Additionally, this feature is transparent to the user and no additional commands are required to enable or disable it.

The Transparent IOS Firewall feature acts as a Layer 2 transparent bridge using CBAC. Transparent firewalls were described in detail earlier in this chapter. This enhancement allows a Cisco IOS Firewall to be implemented concurrently as a Layer 2 and a Layer 3 firewall.

Cisco Zone-Based Policy Firewall

The Cisco Zone-Based Policy Firewall (ZPF) was designed to overcome the interface-based model limitation of CBAC, also known as the Classic Firewall. This limitation was that all traffic passing through the interface was subject to the same inspection policy, which in turn limited granularity and policy enforcement, especially in scenarios where multiple interfaces existed. This concept is illustrated in the following diagram:

Figure 7.10. Cisco CBAC Firewall with Network Segments

The diagram above illustrates a Cisco IOS Firewall-enabled router (CBAC) with three different network segments and an external connection to the Internet, via Serial0/0. While CBAC could be used to inspect traffic from the internal (trusted) networks to the external (untrusted) networks, the same CBAC inspection rules would also then apply for traffic between internal network segments, which may not be desirable in some cases.

When using CBAC, it is not possible to configure it to inspect HTTP and SMTP traffic from the User LAN to the Internet and vice-versa, to inspect HTTP traffic from the User LAN to the DMZ and vice-versa, and to inspect FTP traffic from the User LAN to the Datacenter, for example, because only one CBAC rule can be applied inbound or outbound per interface.

With ZFW, Stateful inspection can now be applied in a zone-based model. Interfaces are assigned to zones and policy inspection is applied to traffic moving between zones. This concept is illustrated in the following diagram:

Figure 7.11. ZFW Stateful Inspecton on a Network

The diagram above shows a router with three different LAN segments, divided into Zones 1, 2, and 3. In addition to this, the router is also connected to the Internet, which is Zone 4. Using ZPF, administrators can control the inspection of traffic between the different zones by assigning interfaces to zones and performing policy inspection on traffic moving between these different zones. This is not possible when using the Classic Firewall, i.e. CBAC.

ZPF provides greater granularity, flexibility, and scalability, as well as an easy-to-use zone-based security approach. With a zone-based inspection model, varying policies can be applied to multiple groups of hosts connected to the same interface. The security zones used in ZPF establish the security boundaries of the network where traffic is subjected to policy restrictions as it crosses to another zone within the network.

Rules for Implementing and Applying Zones

There are certain rules that you must be familiar with when implementing ZPF. These rules are applicable to the configuration and implementation of ZPF in Cisco IOS routers as follows:

• A zone must be configured before interfaces can be assigned to the zone. In other words, an interface cannot be assigned to a zone that does not exist.

• An interface can be assigned to only one security zone. This same concept is applicable in CBAC. Assigning an interface to multiple zones would result in confusing the router.

• All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone and traffic to any interface on the router, e.g. Loopback interfaces.

• Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone. In other words, if two or more interfaces are in the same zone, all hosts connected to those interfaces can communicate with each other by default.

• In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.

• The self zone is the only exception to the default ‘deny all’ policy. The self zone controls traffic sent to the router itself or originated by the router. Therefore, all traffic to any router interface or traffic originated by the router is allowed until explicitly denied.

• Traffic cannot flow between a zone member interface and any interface that is not a zone member, by default. Pass, inspect, and drop actions can only be applied between two configured zones. For example, if interface FastEthernet0/0 is a member of Zone A and interface FastEthernet0/1 is not affiliated with any zones, traffic from FastEthernet0/0 cannot flow to FastEthernet0/1, and vice-versa.

• Interfaces that have not been assigned to a zone function as classical router ports and can still use classic Stateful inspection/CBAC configuration. However, interfaces that have been configured for zones cannot be configured for CBAC.

• If it is required that an interface on the router not be part of the zone-based firewall policy, it might still be necessary to put that interface in a zone and configure a pass all policy, which is sort of a dummy policy, between that zone and any other zone to which traffic flow is desired. Otherwise, that interface will not be able to communicate with other interfaces that have been assigned to zones, and vice-versa, as described earlier.

Configuring ZPF Using Cisco Policy Language

NOTE: You are not required to configure ZPF using CPL, as the only requirement of the IINS course is ZPF configuration using Cisco SDM; however, it is important to be familiar with the terminology, as well as the configuration format used in CPL.

ZFW is configured using the new Cisco Policy Language (CPL). CPL is a new format of configuration integrated into Cisco IOS versions 12.3(T) and 12.4 Mainline that is used to configure ZPF from the CLI. While there are several steps that need to be completed, they do not necessarily have to be implemented in the order that is illustrated below:

1. Define zones. CPL allows administrators to define their own zone names. For example, administrators can create an INTERNAL zone for all internal users and a DMZ zone for all DMZ devices. A DMZ is a firewall configuration for securing LANs. Typically, company-owned public-facing servers, such as web servers, are found in a DMZ.

2. Define zone-pairs; for example the INTERNAL zone and the DMZ zone could be paired together so that a policy can be applied for traffic between these two zones. It is important to remember that this action must be performed for both directions. For example, for the INTERNAL and DMZ zones to communicate in a bi-directional manner, traffic must be permitted to go from the INTERNAL zone to the DMZ zone and from the DMZ zone to the INTERNAL zone.

3. Define class-maps that describe traffic that must have policy applied as it crosses a zone-pair. Class-maps are commonly used in Modular QoS CLI (MQC), and they can be used to match ACLs, protocols, and other criteria. Class-map configuration is beyond the scope of the IINS course requirements.

4. Define policy-maps to apply action to your class-map traffic. Policy-maps contain one or more class-maps. The policy-map is the inspection policy. As is the case with class-map configuration, policy-map configuration is beyond the scope of the IINS course requirements.

5. Apply policy-maps (inspection policy) to the zone-pair(s). This allows for inspection between the different zones based on the traffic specified in the policy-maps. For example, a policy-map could contain a class-map that matches all TCP traffic and another class-map that matches all UDP traffic. This policy-map is then assigned to a zone-pair (e.g. the INTERNAL and DMZ zone) and it will inspect all TCP and UDP traffic for that zone-pair.

6. Assign interfaces to zones. As previously stated, interfaces can only belong to a single zone. It is therefore important to pay close attention to what you are doing; otherwise, if the configuration is incorrect, traffic will be denied by default.

Configuring ZPF Using Cisco Router and Security Device Manager

It is important that you understand how to configure ZPF using Cisco SDM, as this is a mandatory requirement of the IINS course. In this section, ZPF configuration using Cisco SDM will be illustrated using the following network diagram as a reference:

Figure 7.12. ZPF Network

The first task in configuring ZPF using SDM is to select the Firewall and ACL option on the main configuration page in Cisco SDM and then click on the Basic Firewall radio button, as illustrated in the following screenshot:

Figure 7.13. Choose ‘Firewall and ACL’ with SDM

Next, click on the Launch the selected task button, as illustrated in the following screenshot:

Figure 7.14. Launch Basic Firewall Wizard

This brings up the Basic Firewall Configuration Wizard. Click on Next to continue:

Figure 7.15. Click ‘Next’

On the following screen, select the outside (untrusted) and inside (trusted) interfaces. Based on the network topology used in this configuration example, the outside interface is Serial0/0 and the inside interface is FastEthernet0/0. Select these interfaces by checking the appropriate checkboxes next to the interface, as illustrated in the following screenshot:

Figure 7.16. Select the Outside and Inside Interfaces

NOTE: The Allow secure SDM access from outside interfaces checkbox allows administrators to allow external networks to communicate with internal networks; for example, allowing external networks to communicate with an internal company-owned web server. By default, all traffic from external networks to internal networks is blocked, unless it is return traffic that has been originated by an internal host. This is beyond the scope of the IINS course requirements. Administrators are warned of this default action (i.e. all external traffic to internal networks and to the router is blocked) by the following pop-up box. Simply click OK to continue:

Figure 7.17. Click ‘OK’

Once you have clicked OK, SDM transitions to the Basic Firewall Security Configuration page, which is illustrated in the following screenshot:

Figure 7.18. Basic Firewall Security Confi guration Page

On the Basic Firewall Security Configuration page, three different security levels can be selected: High Security, Medium Security, or Low Security. It is important to understand ZPF operation when any one of these options is selected.

If the High Security option is selected, ZPF will operate as follows:

1. The router checks inbound and outbound HTTP traffic and email traffic for protocol compliance, and drops noncompliant traffic; and

2. The router returns traffic for other TCP and UDP applications if the session was initiated inside the firewall.

If the Medium Security option is selected, ZPF will operate as follows:

1. The router identifies inbound and outbound Instant Messaging and Peer-to-Peer traffic, and checks inbound and outbound HTTP traffic and email traffic for protocol compliance; and

2. The router returns TCP and UDP traffic on sessions initiated inside the firewall.

If the Low Security option is selected, ZPF will operate as follows:

1. The router does not identify application-specific traffic; and

2. The router returns TCP and UDP traffic on sessions initiated inside the firewall.

Unless absolutely justified, it is recommended that the High Security option, which is the default, be selected. Click on the Next button. This will bring you to the Basic Firewall Domain Name Server Configuration page, as illustrated in the following screenshot:

Figure 7.19. Basic Firewall Domain Name Server Page

Enter the desired DNS credentials and click on Next, as illustrated in the following screenshot:

Figure 7.20. Enter the DNS Credentials

After clicking on the Next button, SDM transitions to the Firewall Configuration Summary page, which provides a summary of the selected options. The Firewall Configuration Summary page is illustrated in the following screenshot:

Figure 7.21. Summary Page

To complete the configuration, click on the Finish button. Cisco SDM then prepares the commands that it will send to the IOS router, as illustrated in the following screenshot:

Figure 7.22. Command Preparation

Once Cisco SDM has prepared the commands it will use to configure the router, click on the OK button for these commands to be delivered to the router, i.e. for Cisco SDM to configure the router. Cisco SDM then brings up a pop-up box indicating the router has been configured for ZPF as designed by the administrator. This is illustrated in the following screenshot:

Figure 7.23. Click ‘OK’

Finally, click on the OK button to confirm and complete ZPF configuration. By default, SDM then brings up the Edit Firewall Policy page, as illustrated in the following screenshot:

Figure 7.24. Edit Firewall Policy Page

The headings with the minus (-) signs next to them represent the default policy-maps created by SDM and applied to a zone pair. By default, these are presented in an expanded format in SDM, which allows administrators to view their applicable class-maps. Clicking on the minus signs hides all associated class-maps, as illustrated in the following screenshot:

Figure 7.25. Hiding the Class-Maps

While the policy-map names cannot be edited, new rules (i.e. class-maps) can be added to each policy-map by right-clicking the selected option, as illustrated in the following screenshot:

Figure 7.26. New Rules can be Added

To view (and edit) the contents of each class-map (i.e. the traffic matched), double-click on the class-map. For example, to view the traffic matched by the sdm-cls-protocol-p2p class-map, double-click on it, as illustrated in the following screenshot:

Figure 7.27. Double Click ‘Class-Map’ to View and Edit

From the output illustrated above, the sdm-cls-protocol-p2p class-map matches edonkey, gnutella, kazaa2, fasttrack, and bittorrent traffic. The Action: drop-down menu shows that this traffic will be dropped. Additionally, this information will be logged, as indicated by the checked Log checkbox.

The traffic matched by class-maps can also be viewed by simply pointing the mouse over the desired class-map, under the desired policy-map, as illustrated in the following screenshot:

Figure 7.28. Point at the Class-Map to View

In the screenshot above, the mouse (which is not visible) is pointed over the sdm-cls-insp-traffic class-map. The traffic (protocols) matched by this class-map are DNS, HTTPS, ICMP, IMAP, POP3, TCP, and UDP. As illustrated in the screenshot, this traffic is permitted by the firewall.

Once ZPF has been configured, administrators can monitor and view traffic statistics by navigating to the Monitor page (on the top toolbar) in SDM and navigating to and selecting the Firewall Status option, as illustrated in the following screenshot:

Figure 7.29. ‘Firewall Status’ Tab Shows Statistics

To view traffic statistics, select the zone-pair name and click on the Monitor Policy button. For example, to monitor traffic from the in-zone (LAN) to the out-zone (Internet), select the sdm-zp-in-out zone-pair and click on the Monitor Policy button. This operation is illustrated in the following screenshot:

Figure 7.30. Monitor Traffic via ‘Monitor Policy’ Button

NOTE: Once you click on the Monitor Policy button, Cisco SDM enables monitoring for the selected zone-pair. To stop monitoring a zone-pair, click on the Stop Monitoring button, as illustrated in the screenshot above.

When monitoring is enabled, the Active Sessions option allows administrators to view all active sessions. In the screenshot above, there are two active sessions: an ICMP session from 172.1.1.25 to 200.1.1.254 and an HTTPS session from 172.1.1.15 to 217.32.166.136.

The Dropped Packets option allows administrators to view packet loss information. Finally, the Allowed Packets option provides administrators with a graph on traffic throughput statistics, as illustrated in the following screenshot:

Figure 7.31. ‘Dropped Packets’ Shows Packet Loss

Chapter Summary 

The following section is a summary of the major points you should be aware of in this chapter:

Cisco IOS Firewall Overview

• Cisco IOS Firewall set provides network security with integrated, inline security solutions
• The Cisco IOS Firewall set is a Stateful inspection firewall engine
• The Cisco IOS Firewall suite also includes application-level inspection
• Cisco IOS routers can be configured with the IOS Firewall feature set as follows:

1. As a firewall router facing the Internet
2. As a firewall router to protect the internal network from external networks, e.g. partners
3. As a firewall router between groups of networks in the internal network
4. As a firewall router that provides secure connection to remote offices or branches

• The Cisco IOS Firewall is comprised of the following functions and technologies:

1. Cisco IOS Stateful Packet Inspection
2. Context-Based Access Control
3. Intrusion Prevention System
4. Authentication Proxy
5. Port-to-Application Mapping
6. Network Address Translation
7. Zone-Based Policy Firewall

Types of Firewalls

• A firewall protects networked computers from intentional hostile intrusion
• Firewalls must have at least two network interfaces: internal and external
• Basic firewalls consist of two main mechanisms:

1. The first mechanism is designed to block traffic
2. The second mechanism is designed to allow traffic

• Firewalls fall into five broad categories:

 

5. Static or Network-Level Packet Filters
6. Circuit Level Gateways
7. Application Level Firewalls or Gateways
8. Stateful Inspection Firewalls

• Static or Network-Level Packet Filters are first-generation firewalls
• ACLs used in Cisco IOS routers are considered static or Network-Level packet filters
• Circuit level gateways are second-generation firewalls
• Circuit level gateways work at the Session Layer of the OSI Model
• Circuit level gateways monitor TCP handshaking between packets
• Application Level Gateways, or ALGs, are third-generation firewalls
• ALGs evaluate packets for valid data at the Application Layer
• ALGs filter at Layers 3, 4, and 5, and 7
• ALGs are also referred to as Proxies
• There are many different types of proxies. Some of the most common ones are:

1. File Transfer Protocol (FTP) proxies
2. SOCKS proxies
3. Hypertext Transfer Protocol (HTTP) proxies
4. Network Address Translation (NAT) proxies
5. Secure Sockets Layer (SSL) proxies

• Stateful firewalls are fourth-generation dynamic packet filtering firewalls
• Stateful firewalls operate at Layers 3, 4, 5, and 7 of the OSI Model
• Stateful firewalls perform Stateful Packet Inspection (SPI)
• Stateful firewalls maintain detailed session database, referred to as the state table

Hardware versus Software Firewalls

• Hardware firewalls are robust and built specifically for the purposes of firewalling
• Examples of hardware firewalls are the Cisco PIX and ASA firewalls
• Software firewalls are installed on individual computers
• An example of a software firewall is the Cisco IOS Firewall technology

Cisco Security Appliances

• Cisco hardware firewall technologies come in three different forms:

1. The Cisco PIX 500 Series Security Appliances
2. The Cisco ASA 5500 Series Adaptive Security Appliances
3. The Cisco Firewall Services Module

• The following table lists and provides a description of the Cisco PIX 500 series devices:

Device Type	Description
Cisco PIX 501	The Cisco PIX 501 is a compact, plug-and-play security appliance for small office/home office (SOHO) environments. PIX 501 security appliances provide an integrated 4-port 10/100 FastEthernet switch and a dedicated 10/100 FastEthernet uplink
Cisco PIX 506E	The Cisco PIX 506E is a security appliance for remote office/branch office (ROBO) environments. The PIX 506E security appliance provides two auto-sensing 10/100 FastEthernet interfaces
Cisco PIX 515E	The Cisco PIX 515E security appliance is a modular, high-performance security appliance for small-to-medium and enterprise network environments. The Cisco PIX 515E security appliance can support up to six 10/100 FastEthernet interfaces
Cisco PIX 525	The Cisco PIX 525 security appliance provides GigabitEthernet connectivity for medium-to-large enterprise network environments. The Cisco PIX 525 is capable of supporting up to eight 10/100 FastEthernet interfaces or three GigabitEthernet interfaces
Cisco PIX 535	The Cisco PIX 535 security appliance is a modular, high-performance GigabitEthernet security appliance for service provider network environments. The Cisco PIX 535 can support up to ten 10/100 FastEthernet interfaces, or nine GigabitEthernet interfaces, as well as redundant power supplies

• The following table lists and describes the different ASA 5500 series models:

Device Type	Description
Cisco ASA 5505	The Cisco ASA 5505 security appliance is a cost-effective, easy-to-deploy appliance for small business, branch office, and enterprise teleworkers environments. This mode offers and integrated 8-port 10/100 FastEthernet switch, with two Power over Ethernet (PoE) ports
Cisco ASA 5510	The Cisco ASA 5510 security appliance is a cost-effective, easy-to-deploy appliance for medium-sized businesses, remote office/branch office (ROBO) and enterprise environments with advanced security and networking services
Cisco ASA 5520	The Cisco ASA 5520 security appliance provides high-availability services and GigabitEthernet connectivity. This model is suitable for medium-sized enterprise networks
Cisco ASA 5540	The Cisco ASA 5540 security appliance is a high-density, high-availability appliance that provides GigabitEthernet connectivity. This model is recommended for medium-to-large enterprises and service provider network environments
Cisco ASA 5550	The Cisco ASA 5550 security appliance is a Gigabit-class security appliance that offers up to 1.2Gbps of firewall throughput, with high-availability services, as well as GigabitEthernet and Fiber connectivity. This model is recommended for large enterprise and service provider network environments

• The FWSM is a high-speed, high-performance integrated firewall module
• The FWSM is supported in Cisco Catalyst 6500 switches, or Cisco 7600 routers
• Cisco security appliances can run in routed or in transparent firewall mode
• Routed firewall mode is the default for any Cisco firewall
• In routed firewall mode, the security appliance is a router hop in the network
• Transparent firewalls are also referred to as stealth firewalls
• In transparent mode, security appliances simply appear as a ‘bump in the wire’
• There are three basic operational functions that form the basis of the ASA:

1. Access Control Lists
2. Xlate and Conn Tables
3. Inspection Engine

Context-Based Access Control

• CBAC is being replaced by the Zone-Based Policy Firewall (ZPF)
• CBAC is also commonly referred to as the Classic Firewall
• CBAC is a part of the Cisco IOS Firewall set and it provides and advanced firewall engine
• The main features of Context-Based Access Control are:

1. It protects internal networks from external intrusion
2. It provides DoS protection
3. It provides per-application control mechanisms
4. It examines Layer 3 and Layer 4, as well as Application Layer information
5. It maintains state information for every connection
6. It generates real-time event alert failures and log messages
7. It provides enhanced audit trail features

Cisco Zone-Based Policy Firewall

• ZPF was designed mainly to overcome the interface-based model limitation of CBAC
• ZPF uses a zone-based model, where interfaces are assigned to different zones
• The following rules must be acknowledged when implementing ZPF:

1. A zone must be configured before interfaces can be assigned to the zone
2. An interface can be assigned to only one security zone
3. All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router, e.g. Loopback interfaces.
4. Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.
5. In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.
6. The self zone is the only exception to the default “deny all” policy. The self zone controls traffic sent to the router itself or originated by the router. Therefore, all traffic to any router interface or traffic originated by the router allowed until explicitly denied.
7. Traffic cannot flow between a zone member interface and any interface that is not a zone member, by default. Pass, inspect, and drop actions can only be applied between two configured zones.
8. Interfaces that have not been assigned to a zone function as classical router ports and can still use classic Stateful inspection/CBAC configuration. However, interfaces that have been configured for zones cannot be configured for CBAC.
9. If it is required that an interface on the router not be part of the zone-based firewall policy, it might still be necessary to put that interface in a zone and configure a pass all policy, which is sort of a dummy policy, between that zone and any other zone to which traffic flow is desired

Commands Used in this Chapter

The following section is a summary of the commands used in this chapter: 

Command	Description
ip inspect name [name] [prot]	Used to enabled CBAC inspection for a protocol
ip inspect [name] [in|out]	Used to apply CBAC inspection policies to interfaces
access-list [100-199|2600-2699]	Used to create a numbered IP extended ACL
ip access-list extended [name]	Used to create a named IP extended ACL
ip access-group	Used to apply an ACL to an interface
show ip inspect [options]	Used to view CBAC statistics and configuration

 

Cisco IOS firewall notes.