By definition, a firewall is a single device used to enforce security policies within a network or between networks by controlling traffic flows.
The Firewall Services Module (FWSM) is a very capable device that can be used to enforce those security policies. The FWSM was developed as a module or blade that resides in either a Catalyst 6500 series chassis or a 7600 series router chassis. The "tight" integration with a chassis offers increased flexibility, especially with network virtualization and the incredible throughput that is not only available today but will increase significantly with the introduction of the 4.x code train.
The look and feel of the FWSM is similar to that of the PIX and ASA. These products are all part of the same family, originating with the PIX and the "finesse" operating system. If you have had any experience with either the PIX or ASA, you will find comfort in not having to learn another user interface.
Having a good understanding of the capabilities offered by the different types of firewalls will help you in placing the appropriate type of firewall to best meet your security needs.
Understanding Packet-Filtering Firewalls
Packet-filtering firewalls validate packets based on protocol, source and/or destination IP addresses, source and/or destination port numbers, time range, Differentiate Services Code Point (DSCP), type of service (ToS), and various other parameters within the IP header. Packet filtering is generally accomplished using Access Control Lists (ACL) on routers or switches and are normally very fast, especially when performed in an Application Specific Integrated Circuit (ASIC). As traffic enters or exits an interface, ACLs are used to match selected criteria and either permit or deny individual packets.
The primary advantage of packet-filtering firewalls is that they are located in just about every device on the network. Routers, switches, wireless access points, Virtual Private Network (VPN) concentrators, and so on may all have the capability of being a packet-filtering firewall.
Routers from the very smallest home office to the largest service-provider devices inherently have the capability to control the flow of packets through the use of ACLs.
Switches may use Routed Access-Control Lists (RACLs), which provide the capability to control traffic flow on a "routed" (Layer 3) interface; Port Access Control Lists (PACL), which are assigned to a "switched" (Layer 2) interface; and VLAN Access Control Lists (VACLs), which have the capability to control "switched" and/or "routed" packets on a VLAN.
Other networking devices may also have the power to enforce traffic flow through the use of ACLs. Consult the appropriate device documentation for details.
Packet-filtering firewalls are most likely a part of your existing network. These devices may not be the most feature rich, but when you need to quickly implement a security policy to mitigate an attack, protect against infected devices, and so on, this may be the quickest solution to deploy.
The challenge with packet-filtering firewalls is that ACLs are static, and packet filtering has no visibility into the data portion of the IP packet.
Tip - Packet-filtering firewalls do not have visibility into the payload.
Because packet-filtering firewalls match only individual packets, this enables an individual with malicious intent, also known as a "hacker," "cracker," or "script kiddie," to easily circumvent your security (at least this device) by crafting packets, misrepresenting traffic using well-known port numbers, or tunneling traffic unsuspectingly within traffic allowed by the ACL rules. Developers of peer-to-peer sharing applications quickly learned that using TCP port 80 (www) would allow them unobstructed access through the firewall.
Note - The terms used to describe someone with malicious intent may not be the same in all circles.
A cracker refers to someone who "cracks" or breaks into a network or computer, but can also define someone who "cracks" or circumvents software protection methods, such as keys. Generally it is not a term of endearment.
A hacker describes someone skilled in programming and who has an in-depth understanding of computers and/or operating systems. This individual can use his or her knowledge for good (white-hat hacker) or evil (black-hat hacker). Also, it describes my golf game.
A script kiddie is someone who uses the code, methods, or programs created by a hacker for malicious intent.
Figure 1-1 shows an example of a packet-filtering firewall, a router using a traditional ACL in this case, access-list 100. Because the ACL is matching traffic destined for port 80, any flows destined to port 80, no matter what kind, will be allowed to pass through the router.
Given the issues with packet filtering and the fact that they're easy to circumvent, you may dismiss using them entirely. This would be a huge mistake! Taking a holistic approach and using multiple devices to provide defense in depth is a much better strategy. An excellent use of packet filtering is on the border of your network, preventing spoofed traffic and private IP addresses (RFC 1918) from entering or exiting your network. In-depth ACL configuration is beyond the scope of this book, but a good reference is RFC 2827.
Understanding Application/Proxy Firewalls
The following section uses the Open System Interconnection (OSI) model in the description of application/proxy firewalls and warrants a brief review. The OSI model describes how information is transmitted from an application on one computer to an application on another. Each layer performs a specific task on the information and passes it to the next layer. This model helps explain where functions take place.
The seven layers of the OSI model are as follows:
Layer 7 is the application layer: It is the user interface to your computer (the programs), for example, word processor, e-mail application, telnet, and so on.
Layer 6 is the presentation layer: It acts as the translator between systems, converting application layer information to a common format understandable by different systems. This layer handles encryption and standards such as Motion Picture Experts Group (MPEG) and Tagged Image File Format (TIFF).
Layer 5 is the session layer: It manages the connections or service requests between computers.
Layer 4 is the transport layer: It prepares data for delivery to the network. Transmission Control Protocol is a function of Layer 4, providing reliable communication and ordering of data. User Datagram Protocol is also a role of Layer 4, but it does not provide reliable delivery of data.
Layer 3 is the network layer: It is where IP addressing and routing happen. Data at this layer is considered a "packet."
Layer 2 is the data-link layer: It handles the reliable sending of information. Media Access Control is a component of Layer 2. Data at this layer would be referred to as a "frame."
Layer 1 is the physical layer: It is composed of the objects that you can see and some that you cannot, such as electrical characteristics.
Tip - Use the following mnemonic to remember the OSI model: All People Seem To Need Data Processing.
Application firewalls, as indicated by the name, work at Layer 7, or the application layer of the OSI model. These devices act on behalf of a client (aka proxy) for requested services. For example, open a web browser and then pen a web page to http://www.cisco.com. The request is sent to the proxy firewall, and then the proxy firewall acting on your behalf opens a web connection to http://www.cisco.com. That information is then transmitted to your web browser for your viewing pleasure.
Because application/proxy firewalls act on behalf of a client, they provide an additional "buffer" from port scans, application attacks, and so on. For example, if an attacker found a vulnerability in an application, the attacker would have to compromise the application/proxy firewall before attacking devices behind the firewall. The application/proxy firewall can also be patched quickly in the event that a vulnerability is discovered. The same may not hold true for patching all the internal devices.
A computer acting on your behalf at the application layer has a couple of caveats. First, that device needs to know how to handle your specific application. Web-based applications are very common, but if you have an application that's unique, your proxy firewall may not be able to support it without making some significant modifications. Second, application firewalls are generally much slower than packet-filtering or packet-inspection firewalls because they have to run applications, maintain state for both the client and server, and also perform inspection of traffic.
Figure 1-2 shows an application/proxy firewall and how a session is established through it to a web server on the outside.
The step-by-step process, as shown in the figure, is as follows:
The client attempts to connect to the web server located on the outside. For example, a user enters http://www.cisco.com in a web browser.
The proxy server receives the request and forwards that request to the appropriate web server (http://www.cisco.com).
The web server receives the request and responds back to the proxy server with the requested information.
The proxy server receives the information and forwards it to the originating client.
Note - For simplicity's sake, Domain Name Service (DNS), Address Resolution Protocol (ARP), and Layer 2/3 information is not discussed in this example. This also assumes that the client web application has been configured with the appropriate proxy information.
Application/proxy firewalls can be very effective devices to control traffic flow and protect clients from malicious software (malware) and outside attacks. These firewalls must also run applications similar to the clients, which can also make them vulnerable to application attacks.
Understanding Reverse-Proxy Firewalls
Reverse-proxy firewalls function in the same way as proxy firewalls, with the exception that they are used to protect the servers and not the clients. Clients connecting to a web server may unknowingly be sent to a proxy server, where it services the request on behalf of the client. The proxy server may also be able to load balance the requests to multiple servers, consequently spreading the workload.
To be really effective, reverse proxies must understand how the application behaves. For example, suppose you have a web application that requires input of a mailing address, specifically the area code. The application firewall needs to be intelligent enough to deny information that could cause the server on the far end any potential issues, such as a buffer overflow.
Note - A buffer overflow occurs when the limits of a given allocated space of memory is exceeded. This results in adjacent memory space being overwritten. If the memory space is overwritten with malicious code, it can potentially be executed, compromising the device.
If a cracker were to input letters or a long string of characters into the ZIP code field, this could cause the application to crash. As we all know, well-written applications "shouldn't" allow this type of behavior, but "carbon-based" mistakes do happen, and having defense in depth helps minimize the human element. Having the proxy keenly aware of the application and what's allowed is a very tedious process. When any changes are made to the application, the proxy must also change. Most organizations deploying reverse-proxy firewalls don't usually couple their proxy and applications so tightly to get the most advantage from them, but they should.
Another advantage of a reverse-proxy firewall is for Secure Sockets Layer (SSL) termination. Two significant benefits are that SSL does not burden the application server, because it is very processor intensive, and when decryption is done on a separate device, the plain-text traffic can be inspected. Many reverse-proxy firewalls perform SSL termination with an additional hardware module, consequently reducing the burden on the main processors. Figure 1-3 shows an example of a client on the outside (Internet, for example) requesting information from a web server.
The step-by-step process, as shown in the figure, is as follows:
The client opens a web browser and enters the URL that directs them to the associated proxy web server, requesting information.
Steps 2 and 3
The proxy server can have multiple locations from which to glean information, in this example, it requests graphics from Application Server 1 and real-time data from Application Server 2.
Steps 4 and 5
The proxy server prepares the content received from Application Servers 1 and 2 for distribution to the requesting client.
The proxy server responds to the client with the requested information.
As you can see by the previous example, the function of a reverse-proxy server is very beneficial in distributing the processing function over multiple devices and by providing an additional layer of security between the client requesting information and the devices that contain the "real" data.
The same caveats that apply to proxy firewalls also apply to reverse-proxy firewalls, but with a much higher degree of visibility. Because reverse-proxy firewalls are generally providing a service to customers outside the organization, when access to these services is lost so is revenue in the form of access to critical information, such as patient data or product information. With that consideration, it's even more imperative to keep these services running.
Reverse-proxy firewalls aid in protecting and load balancing servers; they also provide a barrier between clients and critical applications through proxy services. Well-written proxy servers significantly reduce the risk of a security breach.
Utilizing Packet Inspection
Packet-inspection firewalls look at the session information between devices. Session information is typically protocol, new or existing connection, source and destination IP address and port numbers, IP checksum, sequence numbers, and application-specific information, such as command and response conditions in Simple Mail Transfer Protocol (SMTP).
A typical flow of traffic from client to server starts with a client initiating the connection to the IP address of the web server destined for port 80 (HTTP). The packet-inspection firewall determines whether that packet is allowed through the firewall based on the current rule-set. If the firewall has the capability to look into the data portion of the IP packet and determine whether it is legitimate Hypertext Transfer Protocol (HTTP) traffic, this process is considered a "deep-packet" inspection because it validates the payload. If all the requirements are met, a flow entry is created in the firewall based on the session information, and that packet is allowed to pass through the firewall. The web server receives the packet and responds accordingly. Return traffic is received by the outside interface of the firewall. The firewall determines whether the return traffic is allowed by comparing the session information (source and destination IP, port numbers, sequence numbers, and so on) with the information contained in the local translation table. If the return traffic matches the previous requirements, the IP payload can be inspected to validate appropriate HTTP compliance (deep-packet inspection), and then it is forwarded to the client.
Figure 1-4 illustrates a graphical representation of the process.
Packet-Inspection Flow Diagram
Packet-inspection firewalls are generally much faster than application firewalls because they are not required to host client applications. Most of the packet-inspection firewalls today also offer very good application or deep-packet inspection. This process allows the firewall to dig into the data portion of the packet and match on protocol compliance, scan for viruses, and so on and still operate very quickly.
Reusing IP Addresses
A feature that is common among all firewalls is Network Address Translation (NAT) and Port Address Translation (PAT) . NAT obfuscates the IP address scheme you are using internally, and the PAT function helps minimize the use of public address space.
Figure 1-5 shows how a firewall can be used to provide NAT and/or PAT functionality.
IP Address Reuse
NAT provides the capability to change the source and/or destination IP address. This is common when private address space is used internally. NAT has a one-to-one relationship between inside and outside IP addresses.
Figure 1-6 shows two clients located on the inside of the firewall. Client 1 has an IP address of 192.168.1.2 and Client 2 has an IP address of 192.168.1.3. A NAT pool of addresses has been assigned to the firewall using IP addresses 172.16.1.2 through 172.16.1.254.
When Client 1 attempts to connect to the Internet, the firewall has been configured to take an IP address from the pool and change the client's source address to the address from the pool. Notice that when the connection passes through the firewall, the source address changed from 192.168.1.2 to 172.16.1.2 (the first address in the pool).
When Client 2 establishes a connection through the firewall, it will get the second address from the pool. As you can see, the size of the pool is directly proportional to the number of clients allowed through. When the 255th client attempts to make a connection through the firewall, the pool of addresses will have been completely allocated and the connection will be denied. This problem will be addressed in the next section, "PAT."
NAT functionality can also be configured statically, called "static" NAT (can you believe it). This feature permanently maps inside to outside or outside to inside addresses. This allows connections from the outside to be established to the inside, using a mapped IP address.
The use of shared NAT pools conserves valuable public IP address space and also supports applications that aren't very well behaved and opens random ports for communication. Static NAT will not conserve public IP addresses, but it provides a mechanism for clients on the public network (Internet) to access services that are privately addressed.
PAT, on the other hand, has a one-to-many IP address relationship. A common implementation is using a private address space internally but having only one public IP address; this could be the case on your home network. Translations are performed at the transport layer of the OSI model.
Figure 1-7 is similar to Figure 1-6, except that instead of a pool of addresses on the firewall, the firewall has been configured to translate the client addresses to the outside IP address of the firewall.
When Client 1 connects through the firewall, the firewall changes the source address of 192.168.1.2 to 172.16.1.1.
When Client 2 connects through the firewall, the firewall changes the source address from 192.168.1.3 to 172.16.1.1.
Both clients use the same IP address. If you are wondering how the firewall knows where to send the data back to, that is where the source port numbers come into play. The firewall creates a table that maps the appropriate source IP and port numbers to the translated source IP and port number. That way, when traffic returns to the shared outside address of 172.16.1.1, it knows the appropriate destination.
As you can see, PAT gives you much better scalability from an IP usage standpoint, consequently reducing the number of public IP addresses required on the Internet. You will also see in Chapter 4, "Understanding Security Levels," how PAT can be used by clients to access multiple resources using the same IP address.
Three basic types of firewalls —packet filtering, application, and packet inspection—are designed to control traffic flows. The previous descriptions provide general functionality of the operation of these types of firewalls. Individual vendors may employ additional features; you should refer to their documentation for specific information.
You might be wondering where the FWSM fits. The FWSM is a packet-inspection firewall with many more bells and whistles that will be explained in the following chapters.
Copyright © 2007 Pearson Education. All rights reserved.