Using Cisco IOS Firewalls to Defend the Network

Using Cisco IOS Firewalls to Defend the Network

Exploring Firewall Technology

Securing all aspects of your network can be a daunting task. For an organization with ecommerce, intranet, and extranet sites, as well as e-mail, this only adds to the complexity of the task. Of course, there are costs to providing a high level of security, in terms of both staff and equipment needed to implement a network security policy. These costs must be weighed against the possibility of network security breaches.

For many organizations, the Cisco IOS Firewall meets their need to provide security if they choose not to use a firewall appliance because of financial constraints or technical complexity. For these organizations, the Cisco IOS Firewall provides a full-featured firewall implemented on Cisco routers using Cisco IOS software. This section explores the Cisco IOS Firewall and discusses various firewall technologies.

The Role of Firewalls in Defending Networks

Have you ever wondered where we get the term “firewall”? It originally described the segment that separated the engine compartment from the interior of an automobile. In the network world, this term has been used as a metaphor for how we separate our internal network from the dangers of the outside world. Firewalls allow us to segment our networks into different physical subnetworks, thereby helping limit the potential damage that could spread from one subnet to another. This is much like how original firewalls worked to limit the spread of a fire.

In our world of network security, a firewall may be a piece of software or hardware that acts as a barrier between our internal (trusted) network and the external (untrusted) network, such as the Internet. In practical terms, a firewall is a set of related programs that enforce an access control policy between two or more networks.
Firewalls consist of a pair of mechanisms that perform two separate functions, as shown in Figure 10-1:

• One mechanism blocks traffic.
• The second mechanism permits traffic.

A firewall is a set of related programs located at a network gateway server that protects the resources of a private network from users on other networks. As shown in Figure 10-1, basic firewall services may be provided through several means:

• Static packet filtering
• Circuit-level firewalls
• Proxy server
• Application server

By placing greater emphasis on either blocking traffic or permitting it based on the specifications you determine, modern firewall designs attempt to balance these two functions. Before implementing a given firewall solution, you must define an access control policy. Upon deployment, the firewall enforces access to and from your network via the firewall. Firewall designs can range from a simple single firewall solution in a small network to multiple firewall designs used to protect multiple network segments in large network implementations.

If you are hosting an application for use over the network, firewalls can be used to manage public access to private network resources such as this. Firewalls can log all attempts to enter the private network, and some can trigger alarms when unauthorized or hostile entry is attempted.

Firewalls filter packets based on a variety of parameters, such as their source or destination address and port number. Network traffic can also be filtered based on the protocol used (HTTP, FTP, or Telnet). The result is that the traffic is either forwarded or rejected. Firewalls also can use packet attribute or state to filter traffic.

The Advance of Firewall Technology

Firewall technology has been available to defend networks for quite some time. This section describes four generations of firewall technologies developed between 1983 and 1995. As shown in Figure 10-2, these four generations include static packet-filtering firewalls, circuit-level firewalls, application layer firewalls, and dynamic packet-filtering firewalls. Taken together, these form the foundation of the current technology employed in Cisco firewalls. Figure 10-2 also notes when Cisco acquired PIX technology.

Initial firewalls inspected network traffic using one of four architectural models defined by the information they examine. They used this information to make security-related decisions, determining what to block and what to allow. Today’s firewalls have moreadvanced capabilities, as we can see in the Cisco PIX Security Appliance and Cisco IOS Firewall.
Table 10-2 lists additional details of the four initial firewall technologies.

These various firewall technologies each have advantages and disadvantages, and each has a role to play, depending on the needs of your organization. The Cisco advances in firewall technologies include the acquisition of the original Private Internet Exchange (PIX) technology in 1995. Today Cisco continues to develop PIX capabilities. The Cisco PIX appliances represent network layer firewalls that employ stateful inspection. These firewalls allow internal connections out (outbound traffic) and only allow inbound traffic that is a response to a valid request or that is explicitly allowed by an access control list (ACL). Cisco PIX technology may be configured to perform a variety of critical network functions, including Network Address Translation (NAT) and Port Address Translation (PAT).

In addition to working with Cisco PIX appliances, you may choose to use the features of the Cisco IOS Firewall embedded in Cisco IOS software. This allows you to turn your router into an effective, robust firewall with many of the capabilities of the Cisco PIX Security Appliance. In addition, Cisco offers the Adaptive Security Appliance (ASA), which provides an easy-to-deploy solution that integrates firewall, Unified Communications (voice/video) security, SSL and IPsec VPN, intrusion prevention system (IPS), and content security services.

Transparent Firewalls

In traditional network configurations, a firewall acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall is a Layer 2 firewall and behaves like a “stealth firewall.” In other words, it is not seen as a router hop to connected devices. In this implementation, the security appliance connects the same network on its inside and outside ports. However, each interface resides on a separate VLAN.

The characteristics of transparent firewall mode are as follows:

• Transparent firewall mode supports two interfaces, usually an inside interface and an outside interface.
• Transparent firewall mode can run in single as well as multiple context mode.
• Packets are bridged by the security appliance from one VLAN to the other instead of being routed.
• MAC lookups are performed rather than routing table lookups.

A transparent firewall can be easily introduced into an existing network. Because it is not a routed hop, IP readdressing is unnecessary. Maintenance is also easy, because there are no routing patterns that might require troubleshooting and no NAT configuration to be done.

Even though transparent mode acts as a bridge, there is no need to be concerned that Layer 3 traffic (IP traffic) will pass through the security appliance from a lower security level interface to a higher security level interface.

You can configure transparent firewalls to allow any traffic through using either an extended ACL (for IP traffic) or an EtherType ACL (for non-IP traffic) if you want. Without a specific ACL, the only traffic allowed to pass through the transparent firewall is Address Resolution Protocol (ARP) traffic; this can be controlled by ARP inspection. Note also that transparent firewalls do not pass CDP packets or any packets that do not have a valid EtherType greater than or equal to 0x600. For example, it is not possible to pass IS-IS packets. One exception is BPDUs, which are supported.

Because the security appliance acts as a bridge device in this configuration, IP addressing should be configured as if the security appliance is not in the network. Note, however, that a management IP address is required for connectivity to and from the security appliance itself and that this address must be on the same subnet as the connected network. A further consideration is that as a Layer 2 device, the security appliance interfaces must be on different VLANs to differentiate the traffic flow.

Application Layer Firewalls

If you are looking to provide a higher level of security than what is offered via circuit-level firewalls, application layer firewalls may be the right choice. Application layer firewalls, sometimes called proxy firewalls or application gateways, allow the greatest level of control and work across all seven layers of the OSI model, as shown in Figure 10-3. These firewalls filter traffic at Layers 3, 4, 5, and 7 of the OSI model.

Many application layer firewalls include specialized application software and proxy servers. Proxy services manage traffic through a firewall for a specific service, such as HTTP or FTP. The proxy services provided are specific to the protocols that they are designed to forward. These can also provide increased access control along with detailed checks for valid data and can even be used to generate audit records of the traffic that they transfer.

Proxy firewalls serve as an intermediary between networks, often your internal network and the Internet at large, determining whether to allow communication to proceed. In a configuration that employs proxy firewalls, there is no direct connection between an outside user and internal network resources. The proxy server provides the only visible IP address on the Internet. Clients connect to the proxy server to submit their application layer requests. These requests include the actual destination as well as the data request itself.

Based on the proxy server settings, the proxy server analyzes the request and may even filter or change the packet contents before proceeding. The proxy server also makes a copy of all the incoming packets and then changes the source address. It does this to hide the internal address from the outside world before it sends the packet to the destination address. The proxy server receives a reply from the destination server, and then the proxy server is responsible for passing the response to the client.

Benefits of Using Application Layer Firewalls
The proxy server monitors and controls outbound traffic. Doing so helps protect the private network servers inside the network. Access to the network is provided by the proxy server. The proxy server establishes the session state, user authentication, and authorized policy. In this way, users connect to services through application programs or “proxies” running on the gateway that connects to the outside or unprotected zone. Figure 10-4 shows the application layer proxy firewall and the layers at which it may be used to filter traffic based on the OSI model.

Application layer firewalls are responsible for filtering at Layers 3, 4, 5, and 7 of the OSI reference model. Because they process information at the application layer, most firewall control and filtering is performed in the software. By locating the firewall at the application layer, you gain greater control over traffic compared to packet-filtering, stateful, or application inspection firewalls.

Application support can vary based on the application layer firewall. Some support only a limited number of applications, and others are designed to support only a single application. Typically, application layer firewalls might support such applications as e-mail, web services, DNS, Telnet, FTP, Usenet news, Lightweight Directory Access Protocol (LDAP), and finger.

Working with Application Layer Firewalls
Application level proxy firewalls control how internal users access the outside world of the Internet and how Internet users access the internal network. They do this by running at the application level of the network protocol stack for each type of service that they want to provide (such as FTP or HTTP). In some configurations, proxy servers are used to block all incoming traffic and only allow internal users to access the Internet. In these implementations, the only packets allowed back through the proxy server are return responses to requests from inside the firewall. Other implementations allow closely controlled traffic to pass onto the internal network, as well as allow for outbound traffic to the Internet.
Figure 10-5 shows the operation of an application level proxy server as it sits between the internal network and the Internet.

The topology shown in Figure 10-6 represents a typical proxy server deployment. In this configuration, the application layer firewall usually has two network interfaces. One is used for the client connections, and the other is used to access the website from the Internet.

By standing in the gap between the internal and external networks, application proxies separate the trusted and untrusted networks either physically or logically.
Figure 10-6 shows a client inside the network requesting access to a website. When the client attempts the connection, his browser uses a proxy server to fulfill all HTTP requests. Note that client-side DNS queries and client-side routing to the Internet are not needed when using a proxy server. All the client needs to be able to do is reach the proxy server to make the request.
Let’s examine how the process works:

1. The proxy server receives the request from a client.
2.  The proxy server performs user authentication according to the rules applied to it.
3.  It uses its Internet connection to access the requested website. In accessing the website, it forwards only Layer 3 and Layer 4 packets that match the firewall rules.
4. When returning content to the requesting client, the proxy server forwards only Layer
5. and Layer 7 messages and content that the server allows (such as nonmalicious traffic) according to the firewall rules.

Application layer firewalls are designed for a single task—to provide the highest level of filtering for a specific protocol. Despite this benefit, a proxy server slows network performance because it must evaluate a significant amount of information embedded in a large number of packets.

Application Firewall Limitations
Application layer firewalls are very processor-intensive, requiring many CPU cycles and a lot of memory to process every packet that needs inspection. Sometimes this leads to issues with throughput. The detailed logging that they can provide, although beneficial, may also lead to significant consumption of disk space. Two solutions can address these issues:

• Use a Context Transfer Protocol (CXTP)
• Have the application layer firewall monitor only key applications By using a CXTP, you can perform authentication and authorization exclusively, rather than adding the overhead of monitoring data on the connection. This greatly improves performance, although without monitoring, you are reducing your ability to be alerted to and track new attack types.

In the second solution, you limit the application layer firewall to processing only certain application types (such as e-mail, Telnet, FTP, or web services). To further reduce process usage, you could process only connections to specific internal resources. The downside of this approach is that you are not monitoring all applications and connections, and this creates a security weakness.

Another limitation of application layer firewalls is that because generally they do not support all applications, you cannot monitor data on all connections. Remember, generally they are limited to one or a small number of connection types, such as e-mail, Telnet, FTP, or web services.

Finally, some application layer firewalls require the installation of vendor-specific software on the client, which the firewall then uses to handle the authentication process and any connection redirection. This can greatly limit scalability and may create management problems if support for thousands of clients is required.

Static Packet-Filtering Firewalls

Packet-filtering firewalls, which typically are part of a router firewall solution, work by filtering traffic at the network layer of the OSI model (the IP layer of TCP/IP). Figure 10-7 shows how static packet-filtering firewalls map to the layers of the OSI model.

Static packet-filtering firewalls act as Layer 3 devices and use filtering rules and ACLs to determine whether to permit or deny traffic based on source and destination IP addresses, as well as source and destination port numbers, and packet type. Rules may also be used to help these firewalls decide whether to reject any packet from the outside that claims to come from an address inside the network.

You will recall that each service relies on specific ports. Static packet-filtering firewalls can also control traffic flow based on ports. Therefore, by restricting certain ports, you can restrict the services that rely on those ports. For instance, if you wanted to block web traffic from a given host, you could block port 80, preventing the host from gaining access to websites.

Packet-filtering firewalls are similar to packet-filtering routers but offer additional benefits. For instance, packet filters are very scalable and application-independent and have high performance standards. The downside is that they do not offer the full range of security solutions required in today’s networks.

Packet filtering may be performed by any device that uses ACLs. For instance, Cisco IOS router configurations frequently use ACLs, not only as packet-filtering firewalls, but also to select specified types of traffic to be analyzed, forwarded, or influenced in some way

In most implementations, we seek to protect the Ethernet interface connecting to the internal (inside) network, while the serial interface that connects to the Internet (outside) is

unprotected. In the example, our internal addresses that the firewall must protect are in the 192.168.0.x range (on the Ethernet interface). Our subnet mask is set to 255.255.255.0, making the IP address of the Ethernet 0 interface 192.168.0.1 255.255.255.0.

As you examine the network security policy shown in Figure 10-8, you see that ACL 101 allows all users from the inside to access Internet services on the outside. In this case, all outgoing connections are accepted. Our router, as configured, checks only packets coming from the Internet (security policy ACL 102).

As you can see, ACL 101 allows Domain Name System (DNS), mail, FTP services, and the return of traffic initiated from the inside, whereas ACL 102 denies access to all other services.

Stateful Packet-Filtering Firewalls

The most common firewall technology is stateful packet filters, or stateful firewalls. This is in no small part related to the fact that they are the most versatile firewall technology. The ability to dynamically filter packets is provided through stateful filtering. This stateful inspection is a firewall architecture that works at the network layer. Unlike static packet filtering, which examines a packet based on the information in its header, stateful inspection can track each connection traversing all interfaces of the firewall and confirm that they are valid.

Stateful Packet Filtering and the State Table

Stateful packet filtering maintains a state table that is part of the firewall’s internal structure. It tracks all sessions and inspects all packets passing through the firewall. If a packet has properties matching those listed in the state table, the firewall allows the packet to pass. Depending on the traffic flow, the state table changes dynamically. Figure 10-9 shows how stateful packet filtering maps to the OSI model.

Stateful firewalls use the state table to keep track of the actual communication process. These firewalls operate at Layers 3, 4, and 5 of the OSI model. At the transport layer, the firewall examines information in the headers of Layer 3 packets and Layer 4 segments. The stateful firewall would examine the TCP header for SYN, RST, ACK, FIN, and other control codes to determine the state of the connection. In our example, the session layer is responsible for both establishing and tearing down the connection.

Whenever an outside service is accessed, the stateful packet filter firewall “remembers” certain details. In other words, it saves the details of the request in the state table. When a TCP or UDP connection is established, either inbound or outbound, the firewall logs the information in a stateful session flow table. This information is then used when the outside system responds to the request. The firewall compares the received packets with the saved state to allow or deny network access.

Source and destination addresses, port numbers, TCP sequencing information, and additional flags for each TCP or UDP connection associated with that particular session are contained in the stateful session flow table, or “state table.” Together, this information creates a connection object. The firewall uses this connection object to compare all inbound and outbound packets against session flows in the stateful session flow table. The firewall permits data only if an appropriate connection exists to validate the passage of that data.

Features vary by firewall. Some of the more advanced stateful firewalls can parse FTP port commands to update the state table to allow FTP to work transparently through the firewall. To ensure that the only packets that are allowed back through the firewall are in response to queries that originate inside the network, TCP sequence number interpretation and DNS query and response matching are used. The threat of TCP RST flood attacks and DNS cache poisoning is greatly reduced through the use of these features.

Disadvantages of Stateful Filtering
Although stateful packet filtering offers speed and transparency, it has a potential disadvantage. Remember, packets must make their way to the outside network. In doing so, internal IP addresses might be exposed to potential hackers. To guard against this, most firewalls incorporate stateful inspection, NAT, and proxy servers together for added security.

To deal with this disadvantage, stateful firewalls keep track of the state of a connection and whether the connection is in an initiation, data transfer, or termination state. This information may be used when you want to deny the initiation of connections from external devices while still allowing users to establish connections to these devices and permit the responses to come back through the stateful firewall.

Figure 10-10 shows a successfully established HTTP TCP session. This session leads to a dynamic ACL rule entry on the outside interface and permits response packets from the web server to the client.

Uses of Stateful Packet-Filtering Firewalls

Stateful packet-filtering firewalls may be used in a number of applications, as described in Table 10-4.

Stateful firewalls also have their limitations, as outlined in Table 10-5.

Application Inspection Firewalls

Application inspection firewalls, sometimes called deep inspection firewalls, are used to provide for the security of applications and services. Of course, certain applications require special handling by the firewall application inspection function. Applications that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports require special application inspection functions.
Figure 10-11 shows an application layer firewall. Application inspection firewalls are essentially stateful firewalls with intrusion detection system capabilities. Specifically, application inspection firewalls

• Are aware of the Layer 5 state of a connection.
• Check the conformity of application commands on Layer 5.
• Can check and affect Layer 7 (such as Java applet or peer-to-peer filtering).
• Prevent more kinds of attacks than stateful firewalls.

The application inspection function uses NAT to help identify the location of embedded addressing information. NAT is used to translate embedded addresses and to update any checksum or other fields that are affected by the translation. The application inspection function also actively monitors sessions to determine the port numbers for secondary channels. A number of protocols open secondary TCP or UDP ports. The initial session, which takes place on a well-known port, is then used to negotiate dynamically assigned port numbers. These sessions are monitored by the application inspection function. It can identify the dynamic port assignments, and it permits data exchange on these ports for the duration of the specific session. Let’s see an example of how this is done.

We begin with an FTP client that opens a control channel between its port 2010 and the FTP server port 21. As data is to be exchanged, our FTP client alerts the FTP server through the control channel where it expects the data to be delivered. In this case it expects data from FTP server port 20 to its port 2012. If FTP inspection is not enabled, the return data from FTP server’s port 20 to FTP client port 2010 is blocked by the stateful firewall. If FTP inspection is enabled, the stateful firewall inspects the FTP control channel to recognize that the data channel will be established to the new FTP client port 2012. Based on this, the firewall temporarily creates an opening for the data channel traffic for the life of the session.

An application inspection firewall behaves in different ways according to each layer, as described in Table 10-6.

Application inspection firewalls also offer a number of advantages:

• Application inspection firewalls are aware of the state of Layer 4 and Layer 5 connections. For example, they know that a Layer 5 SMTP mail-from command always follows a HELO command.
• Application inspection firewalls check the conformity of application commands on Layer 5.
• Application inspection firewalls can check and affect Layer 7, as previously discussed.
• Application inspection firewalls can prevent more kinds of attacks than stateful firewalls.

Application Inspection Firewall Operation

Figure 10-12 shows inspection engines, a subset of the application inspection firewall. As you can see, one inspection engine is responsible for checking a specific protocol

The first example shows how a client establishes a pre-Fast Serial Interface Processor (preFSIP) session to the pre-FSIP server and then a voice call controlled by pre-FSIP. You can see that the application inspection firewall dynamically inspects and allows response traffic from the pre-FSIP server. In addition, the Layer 5 traffic is being inspected, and the preFSIP inspection engine recognizes a pre-FSIP call setup by understanding the pre-FSIP protocol INVITE message on this layer. Notice that the inspection engine dynamically reads the used media port for the Real-time Transport Protocol (RTP) data stream and dynamically allows that traffic to pass through the firewall.

The next example shows a user opening a website on a web server. The HTTP inspection engine recognizes on Layer 7 that the site contains a Java applet and filters the applet because of filtering rules.

Effective Use of an Application Inspection Firewall
Although application inspection firewalls have their place, they are not without disadvantages:

• Only a few inspection engines currently are available that support Layer 7 content because it is so complex.
• Alone, application inspection firewall technology does not support user authentication.
• An extra load is placed on the firewall’s processing capacity as the application inspection firewall is busy building and maintaining the state table. As monitored connections increase, the more processing power your application inspection firewall needs to maintain the table, driving up operation cost. Application inspection firewalls are appropriate for specific situations. Table 10-7 describes these possible scenarios.

Overview of the Cisco ASA Adaptive Security Appliance

The Cisco ASA 5500 Series Adaptive Security Appliance can scale to meet a range of requirements and network sizes. Currently the ASA 5500 Security Appliance family has six models: the ASA 5505, 5510, 5520, 5540, 5550, and 5580. This section explores the Cisco ASA adaptive security appliance and its role in securing the network. Figure 10-13 shows these various ASA appliances and their roles in meeting business needs.

The ASA 5505 has a number of features, including a built-in Layer 2 switch with eight Fast Ethernet ports that can be divided into VLANs. The ASA 5510, another in the family, can support three integrated Fast Ethernet ports as well as one out-of-band management port. If you have an upgrade license, the ASA 5510 can support five Fast Ethernet ports. Other members of the product line support a single management 10/100 Fast Ethernet port and four Gigabit Ethernet ports (ASA 5520 and 5540). The ASA 5550 supports a single management 10/100 Fast Ethernet port and 12 Gigabit Ethernet ports. Of these, only eight can be used at any given time. Four of these can be used for copper Gigabit Ethernet termination only; the other four may be used for either copper or fiber Gigabit Ethernet termination. The ASA 5580-20 and 5580-40 round out the Cisco ASA family of products. These systems provide service provider level capabilities, including 1-Gbps VPN throughput, the ability to support up to 10,000 concurrent SSL or IPsec VPN sessions, and a 4-RU profile, stateful failover, and VPN load balancing. These 5580 ASAs also offer the largest number of interfaces with two USB ports, two RJ-45 management ports, and two gigabit Ethernet management ports.

Secure Socket Layer (SSL) VPNs are also supported by the ASA 5500 family of products. An optional Security Services Module (SSM) also is supported on selected units (ASA 5510, 5520, 5540). Even without these added features, the Adaptive Security Appliance is secure right out of the box. With only a few installation procedures and a brief initial configuration, the ASA is operational and can begin protecting your network.

The Role of Firewalls in a Layered Defense Strategy

Firewalls provide perimeter security for the entire network and for internal network segments in the core in a layered defense strategy. Firewalls can be used to separate an organization’s human resources or sales networks from other networks or network segments within the organization, adding a layer of security. Figure 10-14 explores the role of firewalls in the layered defense strategy.

A layered defense strategy employs multiple firewalls of varying types, combined in layers to add depth to an organization’s information defenses. Let’s examine how this might work. We will begin with traffic coming from the untrusted network. In a layered defense, the traffic first encounters a packet filter on the outer router. Next, the traffic goes to either a screened host firewall or a bastion host system. This system applies more rules to the traffic and discards any suspect packets. If the traffic is not discarded, it goes to an interior screening router. Only after this series of steps does the traffic pass to the internal host that is the destination. This multilayer approach is called a demilitarized zone (DMZ) or a screened subnet configuration.

Even with the benefits of a layered firewall topology, you cannot implement this and then declare your internal network to be safe. Although some firewall manufacturers may encourage this mentality, you still need to consider a number of factors to build a complete defense in depth:

• Firewalls do not protect you from the significant number of intrusions that come from hosts within the network. One example of this is that firewalls do little to protect against viruses downloaded through e-mail.
• Firewalls cannot protect against rogue modem installations.
• Firewalls are not a substitute for well-planned backup and disaster recovery mechanisms that may need to be implemented because of attack or hardware failure.
  An in-depth defense helps in these situations by implementing offsite storage and redundant hardware topologies.

Creating an Effective Firewall Policy

Some organizations are quick to put technology in place without first taking the time to develop a sound security policy. Remember, the firewall(s) that you implement should be in accordance with your policies. Your policies should not be solely driven by your technologies. Having said this, your firewall policy should be developed before you approach implementation. It should detail what traffic the firewall will filter and the nature of network connectivity needed before you begin any implementation efforts.

If you don’t take the time to develop a well-thought-out firewall policy, one that takes into account your business needs, you can end up making what seem to be good decisions, only to find out that you have impaired your organization’s ability to conduct business. For example, suppose you have configured your firewall to block Microsoft Remote Procedure Call (RPC)-based traffic from entering or leaving a protected subnet. On the surface this might seem like a good idea. However, later you learn that users in that subnet need RPC services to contact hosts on the outside. If you have not defined appropriate RPC filtering rules, it will be difficult to deny access to these workers, particularly if this means that you will impair their productivity or, worse, cause them to be unable to work at all. Decisions like this, made without a full understanding of the impact, often cause administrators to have to make an exception. After one exception is made, more exceptions are likely to come into practice, leading to the construction of filtering rules that are complex and ultimately unmanageable.

Always be mindful that your filtering and connectivity policies incorporate a clear understanding of the organization’s security and business needs. In the example just discussed, a better solution would be to locate the firewall at the Internet gateway, rather than at the subnet. This would give users the RPC access they need without compromising overall security. Most situations can be handled with careful planning and a solid understanding of your business needs. Cisco offers a number of best-practice lists to guide you in developing a sound firewall policy. Table 10-8 summarizes a number of key points to add to what we have discussed so far.

Using ACLs to Construct Static Packet Filters

Access control lists (ACL) can be used to provide basic traffic filtering capabilities on Cisco routers. ACLs can be configured for all routed network protocols to filter packets as they pass through a router or security appliance. There are a number of reasons why you might configure these. For instance, you might want to use an ACL to restrict the contents of routing updates or to provide traffic flow control. Perhaps the most important reason to configure ACLs is to provide security for your network, and that is what you will consider in this section. This section describes the different types of ACLs that are available and gives you guidelines to help you better create ACLs to provide network security.

The Basics of ACLs

An ACL may be used for packet filtering (a type of firewall), as well as for selecting types of traffic to be analyzed, forwarded, or influenced in some manner. It is because of this flexibility that the ACL is one of the most commonly used objects in Cisco IOS software.

Now that you understand the flexibility and the power of an ACL, let’s consider its makeup. An ACL is a group of statements wherein each statement defines a pattern in an IP packet or UDP/TCP packet. If it is an extended ACL, you can include the port number and established bit if you like. As packets pass through an interface where an ACL has been associated, the router scans the list from top to bottom in the exact order in which it appears, looking for a pattern that matches the incoming packet. Each pattern has an associated permit or deny rule that determines whether the packet is allowed or denied entry to the
network.

ACLs are used as packet filters to determine which packets can access a router service or cross an interface. Packets that are allowed across an interface are called “permitted” packets. Those that are not allowed across an interface are called “denied” packets. You may use an ACL to enforce one or more of your corporate security policies. For instance, you might have a corporate security policy that states that you may allow packets only using source addresses from within the trusted network to access the Internet. With a written security policy such as this, you can develop an ACL that includes certain statements that, when applied to a router interface, can enforce this corporate security policy.

Well-written ACLs are central to Cisco router security. They are used to restrict access to router network services and to filter packets as they pass through the router. Cisco routers support two types of ACLs—standard IP ACLs and extended IP ACLs:

• Standard ACLs allow you to permit or deny traffic from only specific IP addresses. With these ACLs, the destination of the packet and the ports involved are not taken into account. In the following example, this ACL allows traffic from all addresses in the range 192.168.3.0 to 192.168.3.255: access-list 10 permit 192.168.3.0
• Extended ACLs are made up of a series of statements created in global mode. With extended ACLs you can filter IP packets based on a number of attributes. Extended ACLs can filter packets according to protocol type, source and IP address, destination IP address, source TCP or UDP ports, destination TCP or UDP ports, and optional protocol type information if you require finer granularity of control. The following example shows ACL 101, which has been configured to permit traffic originating from any address on the 63.36.9.0/24 network to any destination host port 80 (HTTP): access-list 101 permit tcp 63.36.9.0 0.0.0.255 any eq 80

Cisco ACL Configuration

In versions of the Cisco IOS before Release 11.2, a number had to be assigned to each ACL when it was created. Since this release, you may now use either a number or a name to identify Cisco ACLs and the protocols that they are being used to filter.

Numbered ACLs can be effective when working with smaller networks with more homogeneously defined traffic. Each ACL type is limited to an assigned range of numbers, so it is easy to determine the type of ACL that you are using. There can be up to 99 standard IP ACLs, numbered from 1 to 99. Additionally, the expanded range for standard ACLs range from 1300 to 1999. Extended IP ACLs may range from 100 to 199, with an expanded range from 2000 to 2699. Table 10-9 lists the number ranges and the types of associated ACL.

As mentioned, with Cisco IOS Release 11.2, you can now identify ACLs with a name rather than a number. If you’re working with a release earlier than IOS 11.2, it will not recognize named ACLs. Named ACLs give you greater flexibility and allow you to configure more ACLs in a router than you could with numbered ACLs. Note, however, that if you identify your ACL with a name instead of a number, the mode and command syntax you will use are different. Also be aware that for now, only packet and route filters can use a named list.

Working with Turbo ACLs

As discussed earlier, routers work with ACLs by searching the ACL sequentially, looking for a matching rule. However, because of increasing needs and requirements for security filtering, along with packet classification, ACLs are getting longer and longer. ACLs can expand to the point that searching them can require a significant amount of time and can impact the memory used when the router is forwarding packets. Another issue is that the time it takes the router to search the list is not always consistent. Unfortunately, this adds variable latency to the packet forwarding. ACLs with several entries can impact your router, causing a high CPU load as well.

The Cisco 7200 series, Cisco 7500 series, and Cisco 12000 series routers support the Turbo ACL feature, which processes ACLs into lookup tables for greater efficiency. Turbo ACLs use the packet header to access these tables in a small, fixed number of lookups, independent of the existing number of ACL entries. The Turbo ACL feature has a number of benefits:

• For ACLs with more than three entries, the CPU load is lower when matching the packet to the predetermined packet matching. The Turbo ACL feature fixes the CPU load, regardless of the size of the ACL, allowing the use of larger ACLs without adding CPU overhead.
• The Turbo ACL feature leads to much reduced latency because the time it takes to match the packet is fixed. More importantly, the time taken to match is consistent, allowing for better network stability and more accurate transit times.

If the routers you are working with support Turbo ACLs, you should use the access-list compiled command in global configuration mode whenever you develop ACLs with more than three statements. This command supports no keywords or arguments.

If you want to view the status of your Turbo ACLs, you may use the show access-list compiled command in privileged EXEC mode. This command does not support any keywords or arguments.

R2(config)# access- list compiled
R2(config)# exit
R2# show access- list compiled

Developing ACLs
You must consider a number of things before you begin developing any ACLs. Table 10-10 summarizes some of the key considerations.

Using the CLI to Apply ACLs to the Router Interface

For the ACL to take effect, you must first apply packet-filtering ACLs to a router interface. These ACLs are applied based on the direction of the data flow.
Figure 10-16 shows the directional nature of ACL application to router interfaces. The ACL may be applied to either incoming packets (an “in ACL”) or outgoing packets (an “out ACL”):

• Inbound (in): Applies to packets received on the router interface.
• Outbound (out): Applies to packets transmitted outbound on the router interface.

When configuring out ACLs, you set up the filter only on the one outgoing interface instead of on each individual incoming interface.

One of the more challenging aspects of applying an ACL is making sure that it is applied in the right direction. Before you apply a packet-filtering ACL to a router interface, be sure that you understand in which direction it will filter.

To apply an ACL to a router’s interface, use the ip access-group command in interface
configuration mode:
ip access- group {access-list-number | access-list-name} {in | out}

Considerations When Creating ACLs

Table 10-12 describes some of the caveats that you need to consider when creati g ACLs.

Filtering Traffic with ACLs

You should filter traffic with ACLs to block services that hackers use to gather information about your network. This is an effective way to decrease the likelihood that an attacker will be able to develop an effective footprint of your organization’s services. Always apply these general rules when considering how to handle router services, ports, and protocols:

• Disable unused services, ports, or protocols: If you find that there is no need to use an enabled service, port, or protocol, disable it immediately.
• Limit access to services, ports, or protocols: If a limited number of users or systems need access to an enabled router service, port, or protocol, limit access to it using ACLs.

ACLs act as traffic filters between your corporate (trusted) network and the Internet (untrusted network), as shown in Figure 10-17. The router uses these ACLs to enforce corporate security policies by rejecting protocols and restricting port usage.

The “Blocked Services” table lists common router services attackers use to gather information about your network and that might lead to an attack. Unless your specific network configuration requires one of these services to operate properly, do not allow them to traverse the router. ACLs should be used to block these services inbound to the protected network and outbound to the Internet. Table 10-13 lists blocked services, along with the port and transport protocol that they use.

Table 10-14 lists common services that reside on either the corporate protected network or the router itself. ACLs should be used to deny these services to untrusted clients.

Access to router services can be controlled in two ways:

• Disable the service: Disabling a router service makes it impossible for anyone to use that service. This is a safer and more reliable action than attempting to block all access to the service using an ACL.
• Restrict access to the service using ACLs: If limited access to a service is required, it is best to build and test appropriate ACLs to apply to the service.

Preventing IP Spoofing with ACLs

You may implement ACLs to mitigate a wide range of threats. This section looks at how you can use ACLs to mitigate IP spoofing:

• IP address spoofing: inbound
• IP address spoofing: outbound

To mitigate IP address spoofing, do not allow any IP packets containing the source address of any internal hosts or networks inbound to a private network. Figure 10-18 shows the topology referenced in the ACL application shown in Example 10-1, where ACL 150 is applied to router R2.

Example 10-1 Mitigating IP Address Spoofing with an ACL

R2(config)# access- list 1 50 deny ip 1 2. 1 . 1 . 0 0. 0. 0. 255 any log
R2(config)# access- list 1 50 deny ip 1 27. 0. 0. 0 0. 255. 255. 255 any log
R2(config)# access- list 1 50 deny ip 0. 0. 0. 0 0. 255. 255. 255 any log
R2(config)# access- list 1 50 deny ip 1 2. 0. 0. 0 0. 255. 255. 255 any log
R2(config)# access- list 1 50 deny ip 1 72. 1 6. 0. 0 0. 1 5. 255. 255 any log
R2(config)# access- list 1 50 deny ip 224. 0. 0. 0 1 5. 255. 255. 255 any log
R2(config)# access- list 1 50 deny ip host 255. 255. 255. 255 any log
R2(config)# access- list 1 50 permit ip any 1 2. 1 . 1 . 0 0. 0. 0. 255
R2(config)# interface e0/1
R2(config-if)# ip access- group 1 50 in
R2(config-if)# exit

This ACL denies all packets containing these IP addresses in their source field:

• Any addresses from the internal 12.1.1.0 network
• Any local host addresses (127.0.0.0/8)
• Any reserved private addresses (RFC 1918)
• Any addresses in the IP multicast address range (224.0.0.0/4)
  You will want to apply this ACL inbound to the external interface (e0/1) of router R2 to help mitigate IP spoofing attacks.
  Also, you should not allow any outbound IP packets with a source address other than a valid IP address of the internal network. Example 10-2 shows the application of an ACL to do this.

Example 10-2 Applying an ACL to Disallow Any Outbound Packets with a Nonvalid Source Address

R2(config)# access- list 1 05 permit ip 1 2. 1 . 1 . 0 0. 0. 0. 255 any
R2(config)# access- list 1 05 deny ip any any log
R2(config)# interface e0/1
R2(config-if)# ip access- group 1 05 in
R2(config-if)# end

ACL 105 is on router R2. This ACL permits only packets that contain source addresses from the 12.2.1.0/24 network and denies all others.

Note that this ACL is applied inbound to the inside interface (e0/0) of router R2. If you are working with Cisco routers running Cisco IOS Release 12.0 and later, they may use IP Unicast Reverse Path Forwarding (RPF) verification. This would provide an
alternative IP address spoof mitigation mechanism.

Restricting ICMP Traffic with ACLs

Unfortunately, hackers can use a number of ICMP message types to attack a network. Many legitimate ICMP messages exist, so deciding what to permit and what to deny can be challenging. For instance, various management applications use ICMP messages, and network management uses ICMP messages automatically generated by the router.

One favorite of hackers are ICMP echo packets. Hackers use ICMP echo packets to discover subnets and hosts on the protected network as well as to generate DoS floods. Hackers can also use ICMP redirect messages to alter host routing tables. Because hackers

can use both ICMP echo and redirect messages maliciously, the router should block them inbound.
Example 10-3 shows ACL 112. This ACL statement is used to block all ICMP echo and redirect messages.

Example 10-3 Blocking ICMP Echo and Redirect Messages with an ACL

R2(config)# access- list 1 1 2 deny icmp any any echo log
R2(config)# access- list 1 1 2 deny icmp any any redirect log
R2(config)# access- list 1 1 2 deny icmp any any mask- request log
R2(config)# access- list 1 1 2 permit icmp any 1 2. 2. 1 . 0 0. 0. 0. 255
R2(config)# interface e0/0
R2(config-if)# ip access- group 1 1 2 in
R2(config-if)# end

For even greater security, this ACL also blocks ICMP mask request messages. Note that this ACL allows all other ICMP messages inbound to the 12.2.1.0/24 network.
The following ICMP messages are required for proper network operation; they should be allowed outbound:

• Echo allows users to ping external hosts.
• Parameter problem tells the host about packet header problems.
• Packet too big is required for packet maximum transmission unit (MTU) discovery.
• Source quench throttles down traffic as needed.

As a best practice, all other ICMP message types should be blocked outbound. Example 10-4 shows how you can use an ACL to properly handle ICMP messages.

Example 10-4 Applying an ACL to Properly Handle ICMP Messages

R2(config)# access- list 1 1 4 permit icmp 1 2. 2. 1 . 0 0. 0. 0. 255 any echo
R2(config)# access- list 1 1 4 permit icmp 1 2. 2. 1 . 0 0. 0. 0. 255 any parameter- problem
R2(config)# access- list 1 1 4 permit icmp 1 2. 2. 1 . 0 0. 0. 0. 255 any packet- too- big
R2(config)# access- list 1 1 4 permit icmp 1 2. 2. 1 . 0 0. 0. 0. 255 any source- quench
R2(config)# access- list 1 1 4 deny icmp any any log
R2(config)# interface e0/1
R2(config-if)# ip access- group 1 1 4 out
R2(config-if)# end

ACL 114 permits all the required ICMP messages outbound to the e0/1 interface while denying all others.

Configuring ACLs to Filter Router Service Traffic

ACLs are an effective means of filtering router service traffic. This section examines how to use ACLs to filter IP traffic destined for Telnet, SNMP, and Routing Information Protocol (RIP).

Typically when constructing an ACL, you would not build a succession of small ACLs, a we will here. However, for clarity it is best to initially examine each of these individually.
In practice, you might want to build at least one ACL for the outside router interface, one for the inside router interface, and one or more ACLs for general router use.

vty Filtering
Systems administrators use Secure Shell (SSH) to remotely access the router console to perform configuration and maintenance. Because of the power this solution provides, you should restrict which hosts have access to the router’s vty lines by using an ACL statement.
Figure 10-19 shows an example of vty filtering with an ACL. Example 10-5 shows how to create an ACL to perform vty filtering.

Example 10-5 Performing vty Filtering with an ACL

R2(config)# access- list 90 permit host 1 2. 2. 1 . 3 log
R2(config)# access- list 90 deny any log
R2(config)# line vty 0 4
R2(config-line)# login authentication vty- sysadmin
R2(config-line)# transport input ssh
R2(config-line)# access- class 90 in
R2(config-line)# end

The IP standard ACL 90 shown here allows only host 12.2.1.3 to access router R2 using SSH (port 22). The command transport input ssh also denies SSH access to R2 from any

other hosts. As configured, this ACL also logs all successful and unsuccessful attempts to access R2 using SSH. This log provides a record for future reference and can serve as a means to help detect attempted unauthorized access.

SNMP Service Filtering

SNMP version 2c (SNMPv2c) lacks authentication, so you should use it only on protected internal networks. It is also a best practice to limit access to a router SNMP agent using an ACL statement.

Figure 10-20 shows a topology in which SNMP service filtering with an ACL occurs. Example 10-6 shows the syntax necessary to perform SNMP service filtering with an ACL.

Example 10-6 Using an ACL to Provide SNMP Service Filtering

R2(config)# access- list 80 permit host 1 2. 2. 1 . 3
R2(config)# snmp- server community snmp- host1 ro 80

Here only the SNMP server with an IP address of 12.2.1.3 may access the router R2 SNMP agent. The snmp-server command specifies that the SNMP server must use a community string of snmp-host1.

SNMP version 3 (SNMPv3) is supported in the latest Cisco IOS software versions. This version offers more-secure SNMP operations and should be implemented rather than older SNMP versions whenever possible.

RIPv2 Route Filtering

To provide directions on where to route traffic, Cisco routers share routing table update information. You can use ACLs to limit which routes a router accepts or advertises to its counterparts. Figure 10-21 shows a sample topology using RIPv2. Example 10-7 shows the syntax necessary to provide RIPv2 filtering with an ACL.

Example 10-7 Using an ACL to Provide RIPv2 Route Filtering

R1(config)# access- list 1 2 deny 1 2. 2. 2. 0 0. 0. 0. 255
R1(config)# access- list 1 2 permit any
R1(config)# router rip
R1(config-router)# distribute- list 1 2 out
R1(config-router)# version 2
R1(config-router)# no auto- summary
R1(config-router)# network 1 2. 0. 0. 0
R1(config-router)# end

Here a standard IP ACL is applied to RIP. Access list 12 is used to prevent R1 from advertising any routes of the 12.2.2.0 DMZ network out of interface e0/0.

Grouping ACL Functions

To this point we have looked at a number of discrete ACLs that are designed for a specific function. Although this has worked well for the purposes of our discussion, it is not a realistic application of how ACLs typically are used. It is far more common to combine many ACL functions into two or three larger ACLs.

This section examines a possible configuration for a typical router. Example 10-8 shows a partial configuration file that contains several ACLs made up of most of the ACL features we have discussed. This is presented as an example of how to integrate multiple ACL policies into a few main router ACLs.

Example 10-8 Integrating Multiple ACL Policies

hostname R2
!
interface Ethernet0/0
ip address 12.1.1.2 255.255.0.0
ip access-group 126 in
!
interface Ethernet0/1
ip address 12.2.1.1 255.255.255.0
ip access-group 128 in
!
router ospf 44
network 12.1.0.0 0.0.255.255 area 0
network 12.2.1.0 0.0.0.255 area 1
!
no access-list 80
access-list 80 permit host 12.2.1.2
access-list 80 permit host 12.2.1.3
!
!snmp-server community snmp-host1 ro 80
no access-list 126
! comment - the entry below prevents any IP packets containing the
! source address of any internal hosts or networks, inbound to the
! private network.
access-list 126 deny ip 12.2.1.0 0.0.0.255 any log
! comment - the set of entries below prevent any IP packets
! containing the invalid source address such as the local loopback
access-list 126 deny ip 127.0.0.0 0.255.255.255 any log
access-list 126 deny ip 0.0.0.0 0.255.255.255 any log
access-list 126 deny ip 12.0.0.0 0.255.255.255 any log
access-list 126 deny ip 172.16.0.0 0.15.255.255 any log
access-list 126 deny ip 192.168.0.0 0.0.255.255 any log
access-list 126 deny ip 224.0.0.0 15.255.255.255 any log
access-list 126 deny ip any host 12.2.1.255 log
access-list 126 deny ip any host 12.2.1.0 log
access-list 126 permit tcp any 12.2.1.0 0.0.0.255 established
access-list 126 deny icmp any any echo log
access-list 126 deny icmp any any redirect log
access-list 126 deny icmp any any mask-request log
access-list 126 permit icmp any 12.2.1.0 0.0.0.255
access-list 126 permit ospf 12.1.0.0 0.0.255.255 host 16.1.1.2
access-list 126 deny tcp any any range 6000 6063 log
access-list 126 deny tcp any any eq 6667 log
access-list 126 deny tcp any any range 12345 12346 log
access-list 126 deny tcp any any eq 31337 log
access-list 126 permit tcp any eq 20 12.2.1.0 0.0.0.255 gt 1023
access-list 126 deny udp any any eq 2049 log
access-list 126 deny udp any any eq 31337 log
access-list 126 deny udp any any range 33400 34400 log
access-list 126 permit udp any eq 53 12.2.1.0 0.0.0.255 gt 1023
access-list 126 deny tcp any range 0 65535 any range 0 65535 log
access-list 126 deny udp any range 0 65535 any range 0 65535 log
access-list 126 deny ip any any log
!
no access-list 128
access-list 128 permit icmp 12.2.1.0 0.0.0.255 any echo
access-list 128 permit icmp 12.2.1.0 0.0.0.255 any parameter-problem
access-list 128 permit icmp 12.2.1.0 0.0.0.255 any packet-too-big
access-list 128 permit icmp 12.2.1.0 0.0.0.255 any source-quench
access-list 128 deny tcp any any range 1 19 log
access-list 128 deny tcp any any eq 43 log
access-list 128 deny tcp any any eq 93 log
access-list 128 deny tcp any any range 135 139 log
access-list 128 deny tcp any any eq 445 log
access-list 128 deny tcp any any range 512 518 log
access-list 128 deny tcp any any eq 540 log
access-list 128 permit tcp 12.2.1.0 0.0.0.255 gt 1023 any lt 1024
access-list 128 permit udp 12.2.1.0 0.0.0.255 gt 1023 any eq 53
access-list 128 permit udp 12.2.1.0 0.0.0.255 any range 33400 34400
log
access-list 128 deny tcp any range 0 65535 any range 0 65535 log
access-list 128 deny udp any range 0 65535 any range 0 65535 log
access-list 128 deny ip any any log
!
snmp-server community snmp-host1 ro 80

Implementing a Cisco IOS Zone-Based Firewall

Traditionally, Cisco IOS Firewalls were configured as an inspection rule only on interfaces. This has changed, however, with the introduction of zone-based firewalls. This section examines the Cisco IOS unidirectional firewall policy between groups of interfaces known as zones and shows you how to configure a Cisco IOS zone-based policy firewall.

Understanding Cisco IOS Firewalls

The Cisco IOS classic firewall, formerly known as Context-Based Access Control (CBAC), is one of the key feature sets of the Cisco IOS Firewall. This section explores how to configure the Cisco IOS classic firewall, including how to configure Granular Protocol Inspection (GPI) and an application firewall.

The Cisco IOS classic firewall can provide network protection on multiple levels using a variety of functions:

• Traffic filtering
• Traffic inspection
• Alerts and audit trails
• Intrusion prevention

Traffic Filtering
The Cisco IOS classic firewall can intelligently filter TCP and UDP packets based on application layer protocol session information. The Cisco IOS classic firewall can be configured to permit specified TCP and UDP traffic through the firewall only when the connection is initiated from within the network that you want to protect. Traffic inspection for sessions that originate from either side of the firewall is an added capability. The Cisco IOS classic firewall also offers the flexibility to be used for intranet, extranet, and Internet perimeters of your network.

If not for the Cisco IOS classic firewall, traffic filtering would be limited to ACL implementations. Such implementations only examine packets at the network layer or, at most, the transport layer.

An advantage of the Cisco IOS classic firewall is that it examines not only network and transport layer information but also the application layer protocol information in an effort to learn about the state of the session. This enables the Cisco IOS classic firewall to support protocols that involve multiple channels created as a result of negotiations in the control channel. This is essential in supporting most of the multimedia protocols as well as some other protocols (such as FTP, RPC, and SQL*Net) that involve multiple channels.

The Cisco IOS classic firewall offers Java blocking. This blocking can be configured to filter HTTP traffic based on the server address or to deny access to Java applets not embedded in an archived or compressed file. An issue with Java is the potential for a user to inadvertently download destructive applets into your network.

One way to protect against this risk is to require all users to disable Java in their browsers. This may be too limiting, though, and it might not be possible for your organization. If this is the case, you should create a Cisco IOS classic firewall inspection rule and use this to filter Java applets. Taking this step will allow users to download only applets residing within the firewall and trusted applets from outside the firewall. If you require more robust content filtering of Java, ActiveX, or virus scanning, you might want to consider purchasing a dedicated content-filtering product.

Traffic Inspection
One of the key responsibilities of the Cisco IOS classic firewall is to inspect traffic as it travels through the firewall to discover and manage state information for the various TCP and UDP sessions. Using this state information, temporary openings are created in the firewall to allow return traffic as well as additional data connections for sessions that are permitted.

The Cisco IOS classic firewall uses packet inspection at the application layer, an maintenance of TCP and UDP session information, to provide the ability to detect and prevent certain types of network attacks such as TCP SYN flooding attacks. In a TCP SYN flooding attack, an attacker floods a server with a barrage of requests for connection but does not complete the connection. As a result, the volume of half-open connections overwhelms the server, causing it to deny service to valid requests. Attacks such as this, which deny access to a network device or service, are called denial-of-service (DoS) attacks.

The Cisco IOS classic firewall helps protect against attacks in a number of ways. For instance, it inspects packet sequence numbers in TCP connections to see if they are within expected ranges and drops any suspicious packets. Cisco IOS classic firewall also may be configured to drop half-open connections. It also can detect unusually high rates of new connections and issue alert messages.

Cisco IOS classic firewall also can help prevent certain DoS attacks involving fragmented IP packets. For instance, an attacker can overwrite the fragment offset in the noninitial IP fragment packets. If this occurs, when the firewall reassembles the IP fragments, it might create wrong IP packets, causing the memory to overflow or your system to crash. Another form of attack can occur when an attacker makes the fragment size small enough to force Layer 4 (TCP and UDP) header fields into the second fragment. When this occurs, the ACL rules that have been configured for those fields do not match.

In another form of attack, the attacker might send a continuous stream of incomplete IP fragments, causing the firewall to lose CPU processing power and memory while trying to reassemble the bad packets. As you can see, even when the firewall prevents an attacker from making an actual connection to a given host, an attacker can still disrupt services provided by that host.

The Role of Alerts and Audit Trails
Real-time alerts and audit trails generated by the Cisco IOS classic firewall provide a means for you to gain insight into what is happening on your firewall. Syslog provides a means to track all network transactions. With this, you can capture such information as recording time stamps, source host, destination host, ports used, and the total number of transmitted bytes. This allows you to create advanced, session-based reporting. The real-time alert capability sends syslog error messages to central management consoles as soon as suspicious activity is detected. You can also configure alerts and audit trail information on a per-application protocol basis using Cisco IOS classic firewall inspection rules. For example, if you want to generate audit trail information for HTTP traffic, you can specify this in the rule covering HTTP inspection.

Classic Firewall Process
The Cisco IOS classic firewall provides Stateful Packet Inspection (SPI) to inspect traffic and create temporary openings at firewall interfaces. When specified traffic exits your internal network through the firewall, the Cisco IOS classic firewall creates these openings. They allow returning traffic (that would normally be blocked) and additional data channels to enter your internal network through the firewall. This traffic is managed by the firewall and is allowed only if it is part of the same session as the original traffic that triggered Cisco IOS classic firewall when exiting through the firewall.

Figure 10-22 shows the operation of a classic firewall and the flow of traffic as a user connects with a web server on the Internet. The ACL shown in Example 10-9 makes this traffic flow possible from the internal network while blocking traffic from an outside attacker, as shown in Figure 10-22. In this figure and example, traffic is inspected, and a temporary opening is created in the firewall interfaces to permit allowed traffic to pass. Return traffic from sessions initiated inside the internal network is also allowed to enter the internal network through the firewall. All other traffic from the outside is denied in this example.

Example 10-9 Applying ACLs for Classic Firewall Operation

router(config)# ip access- list 1 04 deny ip any any
router(config)# ip access- list 1 03 permit http any any
router(config)# ip inspect name FWRULE tcp
router(config)# interface S0
router(config-if)# ip access- group 1 03 out
router(config-if)# ip access- group 1 04 in
router(config-if)# ip inspect FWRULE out
router# show ip inspect sessions
Established Sessions
Session 641721A8 (12.0.1.12:3575)=>(12.0.6.12:80) http SIS_OPEN

SPI and CBAC
Stateful Packet Inspection (SPI) was introduced as a feature called Context-Based Access Control (CBAC). Before this, the ACL was the only packet-filtering mechanism offered by Cisco IOS software. CBAC represented a significant advance over ACLs in that it provided stateful packet-filtering capability.

CBAC can monitor several attributes in TCP connections, UDP sessions, and ICMP. This monitoring is done in an effort to be sure that the only traffic allowed through a firewall ACL is the return traffic for a dialogue that was originated on the private side of the firewall. Cisco IOS SPI provides a mechanism to discover connections that originate on the secure (trusted) side of the firewall, and watch for and allow the return traffic that corresponds with these connections. Connections originating on the unsecure (untrusted) side of the firewall are not allowed to reach the secure network. This is controlled by an ACL facing the unsecure network.

CBAC has undergone a number of changes over the years to enhance its capabilities and increase performance. For instance, inspection of some protocols has been enhanced to ensure protocol compliance or to offer application-level service filtering.
In Cisco IOS software Release 12.3(4)T and continuing forward, substantial improvements in performance and significant changes to the stateful inspection architecture were added through the ACL Bypass feature. Over the years, as CBAC developed and its functionality increased, it was renamed Cisco IOS Stateful Packet Inspection to more accurately reflect its capabilities. You may still hear the term CBAC used, because it is frequently used synonymously with Stateful Packet Inspection, but the CBAC name does not reflect the complete feature set offered by Cisco IOS SPI.

SPI works by inspecting the packet after it passes the inbound ACL of an input interface if the ip inspect in command is applied, or after the outbound ACL of the output interface if the ip inspect out command is used. In this way, outbound traffic must be permitted by input ACLs facing the source and outbound ACLs facing the destination.

Examining the Principles Behind Zone-Based Firewalls

Cisco IOS Release 12.4(6)T introduced a new configuration model for the Cisco IOS Firewall feature set. This new model presented the Cisco IOS zone-based policy. It provides intuitive policies for multiple interface routers, a greater level of granularity with regard to firewall policy application, and the ability to prohibit traffic between firewall zones until an explicit policy is applied to allow desirable traffic via a default deny-all policy. The new zone-based policy inspection interface supports almost all the firewall features implemented in prior releases:

• Stateful packet inspection
• Application inspection
• Virtual private network (VPN) virtual routing and forwarding (VRF)-aware Cisco IOS Firewall
• URL filtering
• Denial-of-service (DoS) mitigation Cisco IOS Release 12.4(6)T also adds a number of new capabilities and characteristics:
• Policies are applied between zones
• Default deny-all policy
• Subnet- and host-specific policies
• Combining service lists with network and host address lists is allowed
• Clearer statement of firewall policies
• Unidirectional policy between zones
• Multiple traffic classes and actions are applied per zone pair
• All connection parameters are global unless a parameter map is specified Policies may be made up of combinations of the following:
• IP addresses or subnets using ACLs
• Protocols
• Application services
• Application-specific policies

This move to the Cisco IOS zone-based policy firewall changes the firewall from an interface-based model to a more flexible, easier-to-understand, zone-based configuration model that helps improve performance as well. Under this new model, interfaces are assigned to zones, and then an inspection policy is applied to traffic moving between the zones.

Considerable flexibility and granularity are provided through interzone policies, allowing different inspection policies to be applied to multiple host groups connected to the same router interface. Firewall policies are configured through the Cisco Policy Language, which employs a hierarchical structure to define inspection for network protocols and allows the grouping of hosts to which the inspection policy will be applied.

Changes to Firewall Configuration

Configuration of the Cisco IOS Firewall has completely changed with the new Cisco IOS zone-based policy firewall. Let’s examine some of these changes.
First and perhaps most notable is the introduction of zone-based configuration. The Cisco IOS Firewall is the first Cisco IOS software threat defense feature to implement a zone configuration model, but other features may adopt the zone model in the future. Prior versions of the Cisco IOS Firewall employed stateful inspection and the CBAC interface-based configuration model. This model employed the ip inspect command set, and it will be maintained for a period of time. But few, if any, new features can be configured with the classic command-line interface (CLI). This is because the Cisco IOS zone-based policy firewall does not use the stateful inspection or CBAC commands. Even though this is the case, you may use the two configuration models concurrently on routers, but you may not combine them on interfaces. For instance, an interface cannot be configured as a security zone member and configured for IP inspection simultaneously.

As introduced with Cisco IOS Release 12.4(6)T, zones establish the security borders of your network. The zone itself defines a boundary where traffic is subjected to policy restrictions as it crosses over into another region of your network. The default policy between zones is deny all. This means that if no policy is explicitly configured, all traffic moving between zones is blocked. If you are familiar with the earlier stateful inspection model, you will recognize this as a significant departure. In the former model, traffic was implicitly allowed until it was explicitly blocked with an ACL.

A second significant change with Cisco IOS Release 12.4(6)T is the introduction of a new configuration policy language known as Cisco Policy Language. If you’re familiar with the Cisco IOS software modular quality-of-service CLI (MQC), you might recognize the format as similar to how QoS specifies which traffic will be affected by the action applied in a policy map.

Zone Membership Rules
Several rules govern the membership of router network interfaces in zones. These rules pertain to interface behavior as the traffic moves between zone member interfaces. These rules are as follows:

• Before interfaces can be assigned to the zone, a zone must be configured.
• Interfaces may be assigned to only one security zone.
• When an interface is assigned to a zone, all traffic to and from the given interface is implicitly blocked when the interface is assigned to a zone. The exception is traffic to and from other interfaces in the same zone, and traffic to any interface on the router.
• Among interfaces that are members of the same zone, traffic is implicitly allowed to flow by default.
• 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 only exception to the default deny-all policy is the self zone. Traffic to any router interface is allowed until traffic is explicitly denied.
• Traffic may not flow between a zone member interface and any other interface that is not a zone member. Pass, inspect, and drop actions can be applied only between two zones.
• If an interface has not been assigned to a zone, it functions as a classical router port and might still use classical stateful inspection or CBAC configuration.
• You may still need to put an interface in a zone and configure a pass-all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired, even if it is required that an interface on the box not be part of the zoning or firewall
  policy.
• If traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model.
• The one exception to the preceding deny-by-default approach is traffic to and from the router, which is permitted by default. However, an explicit policy can be configured to restrict such traffic.

To ensure that all interfaces that are assigned to the same zone are protected with a similar level of security, a security zone should be configured for each region of relative security within the network. Figure 10-23 shows a basic firewall topology. Figure 10-23 shows an access router with two interfaces:

• One interface connected to the public Internet
• One interface connected to a private LAN that must be able to reach the public Internet

Both interfaces in this network are assigned to their own zone.
In this example, each zone holds only one interface. If an additional interface were to be added to the private zone, the hosts connected to the new interface in the zone would be able to pass traffic to all hosts on the existing interface in the same zone. The existing policies would also affect the traffic of local hosts to hosts in other zones in a similar manner. The network generally has two main policies:

• Private zone connectivity to the Internet
• Internet zone connectivity to the private zone

Understanding Security Zones
A security zone consists of a group of interfaces to which a policy can be applied. Two steps are involved when grouping interfaces into zones:

• Creating a zone so that interfaces can be attached to it
• Configuring an interface to be a member of a given zone

All traffic to and from an interface (except traffic going to the router or initiated by the router) is dropped when an interface is a member of a security zone. If you want to permit traffic to and from a zone member interface, you must make that zone part of a zone pair and then apply a policy to that zone pair. If the policy has been configured to permit traffic (via inspect or pass actions), traffic can flow through the interface. The default behavior is for traffic to be allowed to flow among interfaces that are members of the same zone. If you want traffic to flow among all the interfaces in a router, each interface must be a member of one security zone or another. However, it is not a requirement for all router interfaces to be members of security zones.

Zones and Inspection
Zone-based policy firewalls examine the source and destination zones from the ingress and egress interfaces for a firewall policy. In this configuration it is not necessary that all traffic flowing to or from an interface be inspected. You can specify that individual flows in a zone pair be inspected through the policy map that is applied across the zone pair. The policy map that you apply will contain class maps that specify the individual flows.

Let’s consider an example. We can specify a policy map that performs HTTP URL filtering for hosts on 192.168.1.0/24 (salespeople) but that only does plain HTTP inspection for 192.168.2.0/24 (sales managers) for your inside-to-outside traffic.
This results in two flows (192.168.1.0/24 to any, 192.168.2.0/24 to any), and we can apply different inspection parameters to these flows to configure the different behaviors. Zonebased policy firewalls allow inside-to-Internet traffic (the source zone inside and the destination zone outside).

Security Zone Restrictions
The following are important security zone restrictions:

• Interfaces may not be part of a zone and a legacy inspection policy at the same time.
• An interface may be a member of only one security zone.
• If an interface is a member of a security zone, all traffic to and from that interface is blocked unless you configure an explicit interzone policy on a zone pair involving that zone.
• It is not possible for traffic to flow between an interface that is a member of a security zone and one that is not a member of a security zone, because a policy can be applied only between two zones.
• For traffic to flow among all the interfaces on a router, each interface must be a member of one security zone or another. This is key, because after you make an interface a member of a security zone, a policy action (such as inspect or pass) is needed to explicitly allow packets. Without this policy action, all packets are dropped.
• If an interface on a router cannot be part of a security zone or firewall policy, it may be necessary to put that interface in a security zone and configure a “pass all” policy between that zone and other zones where traffic should flow.
• An ACL may not be applied between security zones or on a zone pair unless defined within a class map.
• ACLs may not be applied between security zones and zone pairs. A better means to accomplish this is to include the ACL configuration in a class map and to use policy maps to drop traffic.
• An ACL on an interface that is a zone member should not be restrictive.
• Each interface in a given security zone must belong to the same VRF.
• Policies may be configured between security zones whose member interfaces are in separate VRFs. Traffic may not flow between these VRFs unless the configuration allows it.
• If traffic does not flow between VRFs, the policy across the VRFs is not executed. This represents a misconfiguration on the routing side, rather than on the policy side.
• Traffic passes freely between interfaces in the same security zone and is not subjected to any policy.
• Both the source and destination zones in a zone pair must be members of a security zone.
• You should not define the same zone as both the source and the destination.

Working with Zone Pairs
Zone pairs are used to allow you to specify a unidirectional firewall policy between two security zones. To define the zone pair, you need to use the zone-pair security command. We define the direction of the traffic flow by specifying a source and destination zone. These must be security zones. As mentioned previously, remember that the same zone cannot be defined as both the source and the destination.

Let’s take a closer look at how this works. If we have an interface that is configured to be a zone member, all the hosts connected to that interface are included in the zone. However, the traffic flowing to and from this router interface is not controlled by the zone policies. Instead, each IP interface on the router is automatically made part of the self zone when the Cisco IOS zone-based policy firewall is configured. If you want to control IP traffic moving to the router interfaces from the various zones on a router, you must apply policies to block or allow traffic, as well as to inspect traffic between the zone and the router self zone, and vice versa.

You may also select the default self zone as either the source or the destination zone if you want to. This zone, the self zone, is a system-defined zone that does not have any interfaces as members. When a zone pair includes the self zone, along with the associated policy, this applies to traffic directed to the router or traffic generated by the router. However, it does not apply to traffic through the router.

A more common usage of firewalls is to apply them to traffic through a router. This means that you usually need at least two zones rather than working with the self zone.
If you want to permit traffic between zone member interfaces, you must first configure a policy permitting (or inspecting) traffic between that zone and another zone. To attach a firewall policy map to the target zone pair, you use the service-policy type inspect command.

Figure 10-24 shows the application of a firewall policy to traffic flowing from zone Z1 to zone Z2. In this case, the ingress interface for the traffic is a member of zone Z1, and the egress interface is a member of zone Z2.

If you are working with a topology such as this, and there are two zones, and you require policies for traffic going in both directions (from Z1 to Z2 and Z2 to Z1), you must configure two zone pairs (one for each direction).

Traffic is dropped if a policy is not configured between a pair of zones. Even though this is the case, it is not necessary to configure a zone pair and a service policy solely for return traffic. Recall that return traffic is allowed by default, so long as a service policy permits the traffic in the forward direction.

In the example that we have been considering, it would not be mandatory for you to configure a zone pair source Z2 destination Z1 solely to allow return traffic from Z2 to Z1. This is taken care of by the service policy on the Z1-Z2 zone pair.

Security Zone Firewall Policies

To build Cisco IOS zone-based policy firewall policies, you use the Cisco Policy Language framework. Creating Cisco IOS zone-based policy firewall policies involves three main constructs:

• Class map
• Policy map
• Parameter map

A class map is a way to identify a set of packets based on its contents using “match” conditions. Classes generally are defined so that you can apply an action on the identified traffic that reflects a policy. The class itself is designated via the class map.

To create a class map, you use the class-map command. After it is created, the class map is used to match packets to a specified class. When packets arrive at the targets (for instance, the input interface, output interface, or zone pair), determined by how the service-policy command is configured, they are checked against the match criteria that have been configured for a class map to determine if the packet belongs to that class.

Actions are associated with traffic classified by class maps using policy maps. An action is defined as a specific functionality and typically is associated with a traffic class. Some common actions are inspect, drop, and pass.

You can use the policy-map command to either create or modify a policy map that can then be attached to one or more targets. This is done to specify a service policy. The policy-map command is used to specify the name of the policy map to be created, added to, or modified. This must be done before you can configure policies for classes whose match criteria are defined in a class map.

Parameter maps are used to specify parameters to be applied to classified traffic. Using the parameter-map type command, you may specify parameters that control the behavior of actions and match criteria specified under a policy map and a class map. Table 10-15 defines the three types of parameter maps that are currently available.

Class Maps

If you are familiar with MQC class maps, you will recall that they have numerous match criteria. In contrast, firewalls have fewer match criteria. Firewall class maps also have the type of “inspect.” This information controls what shows up under firewall class maps. The class map defines the traffic that the firewall selects for the policy application. The class map uses the logical qualifiers match any or match all to determine how a particular packet is matched against the filters in the class map. Table 10-16 describes the three types of filters you will use.

The match-any or match-all operators may be applied by class maps to determine how to apply the match criteria. If match-any is specified, traffic must meet only one of the match criteria in the class map. In contrast, if match-all is specified, traffic must match all the class map criteria to belong to that particular class.
In cases in which traffic might meet multiple criteria, you should apply match criteria in order from more specific to less specific. Example 10-10 shows a sample class map.

Example 10-10 Sample Class Map

class- map type inspect match- any my- test- cmap
 match protocol http
 match protocol tcp

In this case, HTTP traffic must encounter the match protocol http statement first so that the traffic will be handled by the service-specific capabilities of HTTP inspection. What would happen if we reversed the “match” lines so that traffic encounters the match protocol tcp statement before it is compared to the match protocol http statement? If this were the case, the traffic would be classified as TCP traffic and would be inspected according to the capabilities of the TCP inspection component of the firewall. This would

create a problem for certain services such as FTP and TFTP, as well as various multimedia and voice signaling services such as H.323, session initiation protocol (SIP), Skinny, RealTime Streaming Protocol (RTSP), and others. It is important that additional inspection capabilities be used to recognize the more complex activities of these services.

An ACL may be applied by class maps as one of the match criteria for policy application. In the case where the only match criteria of a class map is an ACL and the class map is associated with a policy map applying the inspect action, the router applies inspection for all known services (according to the show ip port-map command). In this case, the ACL must apply the restriction to limit traffic to specific desired types. Be aware that the PAM list includes only application services such as HTTP, NetBIOS, H.323, DNS, and so on. A service that is not known to PAM will not be inspected. Because the PAM list tends to include more services with each Cisco IOS software release, be sure to check the port map list to be certain that your services are known to the firewall software.

Verifying Zone-Based Firewall Configuration

When your zone-based firewall is in place, it is important to verify your Cisco IOS zonebased policy firewall configuration and operation. With the Cisco IOS zone-based policy firewall, new commands have been introduced that will enable you to view policy configuration as well as monitor firewall activity. Let’s take a look at some of the commands that you might want to use.

You can display zone descriptions along with the interfaces contained in a specified zone using the show zone security [zone-name] command. If the zone name is not included, this command displays information for all the zones that are configured.
If you would like to display the source zone and the destination zone, as well as the policy attached to the zone pair, you can use the show zone-pair security [source source-zonename] [destination destination-zone-name] command. If no source or destination is specified, all the zone pairs with source, destination, and the associated policy are displayed. In cases in which only the source or destination zone is mentioned, any of the zone pairs that contain this zone as the source or destination are displayed.

To display a specified policy map, you can use the show policy-map type inspect [policymap-name [class class-map-name]] command. Should the name of a policy map not be specified, this command displays all policy maps of type inspect, including any Layer 7 policy maps that contain a subtype.

Using these commands, you can view configuration details for your Cisco IOS zone-based policy firewall configuration. These commands can also help you verify proper operation and are a good first step in resolving issues that might arise.

• CCNA Security Study Notes