Firewall Design

As mentioned at the beginning of the chapter, a firewall is a device or devices that control traffic between different areas of your network. In a more robust design you typically see two or three firewall devices, as well as many other security components to protect company resources. In a firewall design, I refer to the security solution as a firewall system, indicating that many devices are being used to protect your resources.

As you will see in this section, you should follow some practical guidelines when developing a firewall system. These can include packet and application firewalls, application gateway and ATFs, host-based firewalls, and, more than likely, hybrid firewalls, as well as many other security devices, such as VPN concentrators, IDS devices, authentication security servers, and many other components.

After briefly covering the components in a security solution, I discuss some various designs that commonly are used to protect resources. Then I discuss their advantages and disadvantages and cover management issues.

Design Guidelines
You should follow five basic guidelines when designing a firewall system:

Develop a security policy.

Create a simple design solution.

Use devices as they were intended.

Implement a layered defense to provide extra protection.

Consider solutions to internal threats that should be included in your design.

The following subsections cover these five key design points.

Developing a Security Policy
One of the first things you do when designing a firewall system is to create a security policy. The policy should define acceptable and unacceptable behavior, should state restrictions to resources, and should adhere to the company's business plan and policies. Without a security policy, it is practically impossible to develop a security solution that will meet your company's needs.

The key to a good design is basing it on a security policy. Basically, a policy defines who is allowed to access resources, what they are allowed to do with resources, how resources should be protected (in general terms), and what actions are taken when a security issue occurs. Without a security policy, it is impossible to design a firewall system that will protect your assets. In other words, if you don't have a security policy, what should you protect? How much should you protect resources? Who is allowed to access resources? If your policy does not define these items, it is hard to design and implement a solution based on hunches. Actually, without a security policy, the firewall system that you put in place might be creating a security risk: It might not be providing adequate protection to your company's resources.

Designing a security policy is beyond the scope of this book. However, it minimally should address the following items:

The resources that require access from internal and external users

The vulnerabilities associated with these resources

The methods and solutions that can be used to protect these resources

A cost-benefit analysis that compares the different methods and solutions

Designing Simple Solutions
A firewall system design should be kept simple and should follow your security policy. The simpler the design is, the easier it will be to implement it, maintain it, test and troubleshoot it, and adapt it to new changes. Many people like to call this the KISS principle: Keep it simple, stupid. The last kind of problem you want to deal with is a design or configuration error that leaves your network open to all different kinds of attacks.

CAUTION

Complex solutions are prone to design and configuration errors, and are difficult to test and troubleshoot. The simpler you can make the design, the easier it will be to manage it.



Using Devices Correctly
Network devices have functional purposes; they were built with a specific purpose in mind. For example, a Layer 2 switch is used to break up a collision or bandwidth domain, and it also uses VLANs to break up broadcast domains: It is typically not a good device to use to filter traffic because the filtering is done by creating filtering rules based on MAC addresses. The problem with this approach is that MAC addresses tend to change quite a bit: NICs fail, PCs and servers are upgraded, devices are moved to different locations in the network, and so on. Filtering is done best when logical addressing is deployed.

Using the wrong product to solve a security problem can open you to all kinds of security threats. For example, assume that you want to use an IDS to detect different kinds of network threats. You notice that your Cisco router has the capability in the Cisco IOS Firewall feature set, and you decide to enable it, feeling secure that your Cisco router will generate an alarm when an attack occurs. If you had taken time to read the security material related to Cisco routers, you would have realized that Cisco routers can detect only a few dozen different kinds of networking attacks (typically, the most common ones). Therefore, for all the other hundreds of kinds of attacks, your Cisco router will not be capable of detecting them, leaving you exposed. In this example, a better solution would have been to purchase an IDS solution that can detect hundreds of different kinds of attacks.

Using Old Junk to Solve New Problems
As a consultant, I repeatedly hear from customers that they want an inexpensive (that is, "cheap") solution that reuses a lot of the networking gear that they already have in their current design. Unfortunately, with a network that has equipment that is more than 5 years old, this presents a problem because that technology is outdated and probably useless.

When designing a network, especially as it relates to security, you first must come up with a simplified design that describes the basic components that are required. Then you must determine which actual products you will use for these components, based on the features and functions you need. Never try to approach this backward by trying to fit a product to your design: You create problems by doing this instead of solving them. Also remember that there is no such thing as a networking product that will do everything: Do not force yourself to cut corners by trying to make one device do everything.





Creating a Layered Defense
A security design typically uses a layered defense approach. In other words, you usually do not want one layer of defense to protect network. If this one layer is compromised, your entire network will be exposed.

The French and a One-Layer Defense
The French learned the one-layer defense limitation the hard way during World War II with the Maginot line, a physical barrier between Germany and France. The Maginot line extended only the distance of the border between France and Germany. The Germans were smart: They went north and west and came down through the Netherlands, bypassing this fortification and allowing them to easily conquer France.





Instead, you should use a multilayer defense in your firewall system design. With multiple layers, if one layer is compromised, you still have other layers behind it protecting you.

One of the examples that I like to use to describe a firewall system is the fortification systems that kings used to protected their castles in medieval times. Figure 2-22 shows an example of this. In this figure, the first line of defense is the moat surrounding the castle. For the second line of defense, spearmen are behind the moat, preventing anyone from trying to swim across it. Behind the spearmen is the third line of defense: the castle wall, which can be as little as 3 meters high but typically was much higher than this. On the wall are swordsmen, providing the fourth layer of defense. Inside the castle wall are the castle grounds and the castle itself. The castle is built with very high stone walls and turrets, providing the fifth layer of defense. And in the windows of the wall and on top of the turrets are the archers, providing the last layer of defense. As you can see from this system, an attacker must go through many layers of defense to capture or kill the king.


Figure 2-22. A Medieval Firewall System

[View full size image]





Dealing with Internal Threats
Too often, security personnel are concerned about protecting a company's resources and assets from outside threats. Remember that it is much easier to attack your assets from within; plus, most threats and attacks (60 to 70 percent) are internal attacks. Therefore, a good firewall system not only protects you from external threats, but also allows you to minimize internal threats.

DMZ
Most firewall systems use a demilitarized zone (DMZ) to protect resources and assets. A DMZ is a segment or segments that have a higher security level than that of external segments, but a lower security level than that of internal segments. DMZs are used to grant external users access to public and e-commerce resources such as web, DNS, and e-mail servers without exposing your internal network. A firewall is used to provide the security-level segmentation among the external, DMZ, and internal resources. Basically, the DMZ acts as a buffer between different areas in a network.

DMZ Rules and Traffic Flow
To help enforce security more easily, each area in the firewall system is assigned a security level. This could be something as simple as low, medium, and high, or something more sophisticated, such as a number between 1 and 100, where 1 is the lowest security level and 100 is the highest. Typically, traffic from a more secure (higher) layer is permitted to a lower layer, but not vice versa.

For traffic to go from a lower layer to a higher layer, it must be permitted explicitly: In other words, you must set up a filtering rule that allows this traffic to go from a lower level to a higher level. If two areas have the same security level, such as medium, the traffic between the two areas is either permitted or denied, based on the process that the product uses.

CAUTION

When allowing traffic to go from a lower security level to a higher one, you should be very specific about what traffic is allowed. For example, if you want Internet users to access a web server, specify both the destination IP address of the web server, such as 200.1.1.2, the protocol (TCP), and the destination port number (80), in the filtering rule. By being very specific, you are opening a hole in the firewall system for only traffic that is necessary; all other traffic (including other types of traffic to the web server) is blocked by the configuration of your security levels.



It is important to point out that these rules sometimes are built into the firewall or must be configured manually on the firewall. In either situation, this gives you a lot of flexibility in assigning a level of threat to particular areas in your network and configuring your firewall system appropriately.

NOTE

The Cisco PIX firewall uses a numbering scheme approach to security levels, providing a very flexible system for separating areas by their level of threat. Higher-number areas freely can send traffic to lower-number areas, but not vice versa, and areas with the same level cannot send traffic to each other. On Cisco IOS routers, you must configure filtering rules manually to define levels of security.



The network shown in Figure 2-23 illustrates how security levels work.


Figure 2-23. Security Level Example

[View full size image]





In this example, a firewall is used to separate different areas of a network. The firewall has the following four interfaces:

A connection to the Internet, assigned a low security level

A connection to the DMZ, where public servers are located, assigned a medium security level

A connection to a remote company that is working on a project for them, assigned a low security level

A connection to the internal network, assigned a high security level

This company has assigned the following rules:

High- to low-level access: permit

Low- to high-level access: deny

Same-level access: deny

Given these rules, the following traffic is allowed automatically to travel through the firewall:

Internal devices to the DMZ, the remote company, and the Internet

DMZ devices to the remote company and the Internet

Any other type of traffic flow is restricted. One advantage of this design is that, because the remote company and the Internet are assigned the same level, traffic from the Internet cannot reach the remote company (which provides protection), and the remote company cannot use your Internet access for free (which saves you money).

Another advantage of security levels is that they create a layered approach to security. For example, for either hackers on the Internet or the remote company to access internal resources in Figure 2-23, they probably first must hack into your DMZ and then use this as a stepping stone to hack into your internal network. Using this layered approach, you make the hacker's job much more difficult and your network much more secure.

DMZ Types
DMZs come in many types of designs. You can have a single DMZ, multiple DMZs, DMZs that separate the public network from your internal network, and DMZs that separate traffic between internal networks. The following sections show some of these implementations.

Single DMZ
Single DMZs come in two types:

Single segment

Service-leg segment

Figure 2-24 shows an example of a single DMZ with a single segment. In this example, there are two firewalls: a perimeter firewall and a main firewall, with the DMZ segment between the two. One disadvantage of this design is that two firewalls are needed: one to protect the DMZ from the Internet and one to protect the internal network from the DMZ and the Internet.


Figure 2-24. Single DMZ with a Single Segment

[View full size image]





Most firewall designs use a service-leg DMZ, which is shown in Figure 2-25. In this example, a router is used to connect to the Internet. The design in Figure 2-25 has two advantages over the single-segment DMZ shown in Figure 2-24:

The firewall sometimes can be connected directly to the Internet, removing the extra cost of the perimeter router.

All security-level polices can be defined on one device (in a single-segment DMZ, you must define your policies on two devices).


Figure 2-25. Single DMZ with a Service-Leg Segment

[View full size image]





The main problem with this approach, however, is that, because a single firewall is handling all security policies, a successful DoS attack can degrade the firewall's performance. In the best case, only your throughput is affected; in the worst case, the firewall might crash. With a single-segment DMZ, because the policies are spread between the two firewalls, there is less likelihood of an overload occurring. This is especially true for traffic between the DMZ and the internal network. If a hacker is attacking a web server on the DMZ, the perimeter firewall takes the brunt of this attack, which allows the internal firewall to handle DMZ/internal traffic without affect.

Multiple DMZs
A firewall system can be used to separate multiple areas of your network, including multiple DMZs. Figure 2-26 shows an example of a network with multiple DMZs. In this example, a firewall is used to break up a network into four areas: the internal network, a DMZ for Company A's server, a DMZ for Company B's server, and the Internet. In this example, the internal network is assigned a high security level, both company servers are assigned a medium security level, and the Internet is assigned a low security level. Assume that high-to-low access is allowed by default but that same-to-same is denied. In this example, the internal network can access any resource, and each company server can access the Internet, but not the other company's server. You would need to set up security rules to allow Internet access into the two servers on the medium-security segments, as well as communication between the two servers, if this is desired.


Figure 2-26. Multiple DMZ Example

[View full size image]





Actually, this type of design is very common in ISPs. Most ISPs offer web-hosting services and use this type of design to separate each company's server(s) from the others.

Internal DMZ
Another type of DMZ is an internal one. An internal DMZ enables you to provide separation between different parts of your internal network. Most people assume that a DMZ is used to separate your internal services from those that you offer to the public, such as a web or e-commerce server; however, they can be used effectively to protect resources in one part of your company from another.

Figure 2-27 illustrates the usefulness of an internal DMZ. In this example, a firewall is used to separate the internal network (in the right of the figure) from the engineering and accounting users. In this example, both engineering and accounting are assigned a medium level of security. Assume that same security level to the same security level is denied by default; in other words, if two interfaces have the same security level, they cannot, by default, communicate with each other. With this configuration, accounting and engineering are allowed to send traffic to the internal network but not themselves. Internal users cannot access either of these two groups because the internal users are on a lower security level interface. To allow these last types of access, you would need to configure security rules on your firewall to allow same-to-same or low-to-medium levels of access.


Figure 2-27. Internal DMZ Example

[View full size image]





As you can see in this example, you easily can protect important resources in your network from other internal users. Internal DMZs enable you to accomplish the following:

Control traffic between areas

Localize security problems

I already have discussed the first bulleted point. For the second, imagine that a hacker somehow could compromise your perimeter defenses and access an internal resource such as a file server. By using an internal DMZ, you still are protecting important resources. In Figure 2-27, the accounting and engineering resources are protected from the hacker if an internal resource connected to the lower-level internal interface was compromised.

Components
Now that you have a basic understanding of firewall system design practices, this section takes a closer look at the components that make up a firewall system. A good firewall system typically contains the following components:

Perimeter router

Firewall

VPN

IDS

It is important to point out here that I used the word component, not device, to describe what is included in a firewall system. This is because many devices can support multiple components. For example, a Cisco IOS router can act as a perimeter router or a main firewall, can terminate VPN connections, and can perform IDS—all in one chassis. Remember my caution, though, if you are using a single layer for defense: Using multiple layers provides for a better design and protection. The following sections cover the different components used in a firewall system.

Perimeter Router Component
The main purpose of the perimeter router is to provide a connection to a public network, such as the Internet, or a different company. It is used to convert data-link layer media types from a LAN to either a WAN or MAN medium.

The functions of the perimeter router can include the following:

Routing through static routes or a dynamic routing protocol

Filtering through either packet filtering or stateful filtering

Terminating VPN connections

Providing address translation

TIP

Remember that the main function of the perimeter router is to access a different network: It is your first, but not your last, line of defense. Therefore, you do not want to overload it with a bunch of security functions that another component in the firewall system can handle better.



Firewall Component
The main purpose of the firewall component is to separate your network into different security levels and control traffic between these levels. Typically, you find a firewall component near the perimeter of the network, protecting you from external threats as well as providing controlled access to a public DMZ segment. However, you also might find firewall components inside your internal network, separating critical resources so that they are better protected.

The functions of the firewall can include the following:

Stateful filtering

User authentication of connection with CTPs

Connection filtering with CGFs

Address translation

VPN Component
The main purpose of the VPN component is to provide a protected connection between two devices, two networks, or a device and a network. This protection can include encryption, authentication, and packet-integrity checking, preventing eavesdrop attacks from prying eyes. VPNs are a cost-effective, remote-access solution because they enable you to use a public network, in a secure manner, to connect two private networks. This is cheaper than purchasing private WAN links to provide connectivity.

The functions of the VPN component can include the following:

Protecting (encrypting) traffic between LAN sites and remote access users

Assigning addressing information to remote access clients

Using simple packet filters to restrict traffic flow

VPNs are covered in more depth in Part VIII.

IDS Component
The main purpose of the IDS component is to detect, and possibly prevent, reconnaissance, DoS, and unauthorized access attacks. To understand the different kinds of network attacks that your company is facing, you need an intimate understanding of the different kinds of traffic flowing through your network, as well as the intentions of this traffic.

Most traffic entering or traversing your network has a valid purpose: to access web pages with HTTP, resolve names to addresses with DNS, send e-mail with SMTP, and so on. However, a small percentage of traffic has malicious intentions. In these cases, a hacker might be executing a reconnaissance attack to determine what kinds of resources are available in your network, and then might execute a DoS attack to affect their level of service or carry out an unauthorized attack to open a back door into your network. An IDS solution should be capable of detecting these kinds of threats.

IDS Overlooked
IDS components often are overlooked or are seen as unnecessary in a security solution if your network has a firewall component. I once performed work for a company that took this position on IDS solutions, and it was shaken when I set up a test IDS system that detected more than 1000 network threats directed against the network system over a single day. You will not know what kinds of attacks your network is facing unless you monitor it. Plus, new types of attacks are appearing at a steady rate. A good IDS solution can help detect and prevent attacks.





IDS components fall under one of three categories:

Anomaly-based

Signature-based

Hybrid-based

Anomaly-based solutions capture traffic over a period of time and use this as a reference for what is valid. These systems then compare new traffic to what is considered to be "normal" and look for anomalies. One disadvantage of anomaly-based solutions is that they tend to generate a lot of false positives (they trigger alarms that are not really attacks). This is because traffic patterns change; if you do not stay up-to-date on a database of normal traffic flows, false positives are bound to happen.

Signature-based solutions compare traffic to signatures to look for attacks. A signature is a static definition of things to examine in packet or packets; these can include header information as well as data. Signature-based solutions have a lot less false positive alarms. However, their main disadvantage is that they cannot detect new kinds of attacks unless you keep your signature database updated. This is where an anomaly-based solution shines: It can detect new kinds of attacks without a software upgrade.

In many of today's IDS solutions, a hybrid approach is used, with both signatures and anomaly detection used in tandem to provide the best possible intrusion detection.

IDS solutions come in two flavors:

Network-based IDS

Host-based IDS

A network-based IDS solution is a protocol analyzer on steroids: It plugs into your network at key points and monitors traffic. Network-based systems can be used to detect attacks against many different devices. A good network-based IDS solution should have the capability, when an attack is detected, to access (log into) your firewall component and configure a temporary filter to block the malicious traffic. This is an excellent tool for shutting down the hacker's access even into public areas of your network.

A host-based IDS solution is IDS software running on a host, such as a PC or file server, that detects attacks only against that host. This can provide an additional measure of protection for critical servers that are not necessarily protected by a firewall or IDS component. One downside of host-based solutions is that they require extra processing power to examine packet information sent to the host.

CAUTION

IDS solutions are still in their infancy and should not be relied upon solely for security. For many IDS systems, a very wily hacker can slip by attacks without raising an alarm. Remember that a good firewall system has multiple components to it.



Your IDS component should play a key role in your firewall system. The functions of the IDS component can include these:

Monitoring traffic for statistical purposes

Examining traffic for network threats

Reporting network threats and possibly taking action to prevent the threats

IDS is discussed in more depth in Chapter 16, "Intrusion-Detection System."

TIP

IDS systems can generate a lot of logging information. You should review and analyze this carefully daily. By doing this, you will gain an excellent understanding of the traffic patterns in your network, as well as what hackers are currently up to.



Component Placement
Now that you understand some of the components used in a firewall system, this section talks about where these components are placed in a network design. As you will see, you can design a network in many different ways, each with advantages and disadvantages.

NOTE

It is important to point out that there is no one correct way to design a secure network. Each network is unique, and its unique characteristics must be taken into account when designing a solution. However, the examples shown here are a good starting point for creating the appropriate design for your network.



Simple Firewall System Design
To help understand where components are placed in a firewall system, I use two examples. The first example, shown in Figure 2-28, is the simpler of the two designs.


Figure 2-28. Simple Firewall System Design

[View full size image]





In this example, a perimeter router with basic packet filtering screens traffic as it enters the network. A standalone IDS device is used to detect attacks that the perimeter packet-filtering firewall did not filter.

The traffic then is processed by a stateful firewall. The stateful firewall has set up three security levels: low for the Internet side, medium for the DMZ, and high for the internal network. A security rule was added on the stateful firewall to allow traffic from the Internet to only the web server. All other traffic from a lower security level to a higher one is prohibited; however, higher-to-lower movement is permitted, allowing the web server administrator located on the internal network to log into the DMZ web server to update web pages.

An internal router in this design provides routing to internal segments. If you need to set up security levels and restrict access to areas of this network, you can use basic packet-filtering services on the router.

One of the advantages of this design is its simplicity: It has a minimum of three layers of defense: the packet-filtering firewall at the perimeter, the IDS, and the stateful firewall. Optionally, you can turn the internal router into a packet-filtering firewall.

This design has some disadvantages, however:

Any attacks directed at the perimeter router/firewall are not seen by the IDS, which might be useful in determining who is trying to hack into the router and how they are trying to do it.

No IDS exists on the inside the network, so you cannot easily determine whether internal attacks are occurring.

The internal router might provide only simple packet filtering, which makes it difficult to implement security levels for internal users. However, this can be remedied by using a different type of firewall, such as a stateful firewall or an AGF.

Enhanced Firewall System Design
The second firewall system design is shown in Figure 2-29. As you can see, it has more components and rectifies some of the security deficiencies in the simple firewall system design. I examine the perimeter router component first. As in the last example, the perimeter router/packet-filtering firewall is performing basic filtering of traffic as it comes into the Internet. Nothing is different in this example except for what the bottom-right IDS device is doing: monitoring both the external Internet segment and the segment between the packet-filtering perimeter router and the stateful firewall. This allows the IDS to see what attacks are directed at the router, as well as what attacks are getting through the router.


Figure 2-29. Enhanced Firewall System Design

[View full size image]





Next is the VPN concentrator. It is used to provide encrypted connections for the remote office connection (from the remote office firewall to the concentrator), as well as to terminate remote-access user connections from telecommuters and SOHO users. Notice that an IDS sensor behind the VPN concentrator is examining the unencrypted traffic. This is placed here just in case one of the remote access users or the remote office becomes compromised: The IDS can view the unencrypted traffic to detect network threats, which the IDS device connected between the perimeter router and the Internet firewall cannot because the traffic is encrypted at this point.

In addition, when the unencrypted traffic is sent to the Internet firewall from the external users, it is assigned a medium level of security, which means that it can be routed back to the Internet without any filtering and to the DMZ (assuming that same-to-same level of access is allowed). To access an internal resource, the internal firewall needs a security rule configured.

The Internet firewall provides a second layer of filtering after it passes the perimeter router/firewall. It handles traffic from the VPN concentrator, the Internet, and the DMZ. Notice that the server in the DMZ has a host-based firewall installed, adding protection to it.

The bottom-left IDS is monitoring the Internet Firewall-to-Internal Firewall segment as well as the internal high-security segment, detecting attacks that get through the respective firewalls. Plus, the host-based firewall software is installed on the internal file server.

Inside the network, an internal stateful firewall is used to provide security levels. In this example, the file-server connection has a high security level, and all of the other connections are set to low. This means that rules must be configured on the internal firewall to allow any type of traffic to reach the internal file server.

In all, this is a good security design. It uses IDS components at key places to monitor critical traffic, and it has a layered defense approach, with a packet-filtering firewall and two stateful firewalls. Plus, host-based firewall software is used on critical servers. A VPN also is used to protect traffic across the Internet.

This design also has some disadvantages, however:

It costs a lot more than the simple design.

The IDS systems are monitoring a lot of traffic and are generating a lot of logging information. If someone does not take the time to examine the IDS logs carefully, attacks could slip through the cracks.

Much more configuration and management need to be done, to ensure that the correct security policies are implemented on the firewalls: the perimeter packet-filtering firewall, the two stateful firewalls, and the two host-based software firewalls. In this scenario, you definitely want to look at management software that enables you to define all your security policies from one desktop, and then have these polices converted into the configuration commands and downloaded and executed on your firewall devices.

TIP

As I learned a long time ago, there is no such thing as network nirvana. Every solution has advantages and disadvantages. The trick is to weigh these when factoring which solution meets your security policy requirements, provides the best cohesive yet manageable solution, and is the most cost-effective. Notice that I did not say that the solution has to be the most secure—only that it needs to meet your security policies.



Design Considerations
Here are some important points to remember when placing components in a firewall system:

Use a packet-filtering firewall for the boundary router, to provide an extra level of protection. If you are really concerned about security, use a stateful firewall for this component.

All servers that have publicly available resources should be placed in a DMZ. Servers that handle critical processes or financial transactions should have host-based firewall software installed on them. In addition, all unnecessary services on these servers should be disabled.

For DMZ servers with sensitive information, consider using a multiple DMZ design. This is especially true if you have a web server and a database server that it interfaces with. Put the web server on a lower security level than the database server.

If external users or remote sites that traverse a public network want to access internal resources, require a VPN. This ensures that any sensitive data is protected.

VPN connections, as well as remote-access connections through private networks, should be terminated on their own DMZ on the Internet firewall. An IDS system should be used to examine this traffic after it is decrypted. This also allows the traffic to go right back out to the Internet, but because it is going through the firewall, you have more control over what is allowed.

For critical internal resources, use an IDS component to monitor key segments to detect network threats. You can add extra security by segmenting your internal network into different security levels. This can compartmentalize your network and restrict access from the general population of users to areas that they have no business being in, such as accounting and R&D.

For e-mail, you should have a public e-mail server in the DMZ that accepts all incoming and outgoing mail services. I highly recommend that you have antivirus, spam, and host-based firewall software running on this server. I also recommend that you use a limited form of a CGF that can examine mail content and make filtering decisions on it, to catch networking threats that the antivirus software cannot deal with. After e-mail is processed, it then can be forwarded to an internal server. I also recommend that all outgoing e-mail be forwarded through the DMZ e-mail server and have the same processes performed on it (remember that someone on the inside might try to use your e-mail server for malicious purposes).

I could list probably a dozen or so more items, but these are the more important ones. As you can see from this list, you have your work cut out for you.

Firewall Implementation
Now that you have chosen your components for your firewall system, you need to set them up and configure your security policies on them. Typically, you use either a command-line interface (CLI) or a graphical user interface (GUI) to perform the configuration. Cisco products support both methods, but this book focuses on the CLI, which is the most common method used by Cisco administrators.

TIP

I have found that, at least with Cisco products, the Cisco development team for routers always implements features using the CLI first and then adds this function to GUI-based products, such as Security Device Manager (SDM) and CiscoWorks VMS. Therefore, I highly recommend that you become very comfortable with the Cisco CLI if you plan to keep your Cisco IOS routers up-to-date with the latest security technology.



Security Device Manager
Cisco has introduced a new web device manager called Security Device Manager (SDM) that provides an alternative to CLI configuration of a Cisco router. SDM is a web software component loaded into flash of a supported Cisco router that enables you to use a web browser to configure the router. Not all routers support SDM, but most routers that Cisco currently sells today do, including the 831, 836, 837, 1701, 1710, 1711, 1712, 1721, 1751, 1760, 2610XM, 2611XM, 2620XM, 2650XM, 2651XM, 2691, 3620, 3640, 3661, 3662, 3725, 3745, 7204VXR, 7206VXR, and 7301. You also need Cisco IOS 12.2(11)T6 or later on your router. If you buy one of the previously mentioned routers today, SDM automatically ships with it; however, you easily can download SDM from the Cisco web site and install it in flash on a supported router platform.

Figure 2-30 shows the main screen of SDM. With SDM, Cisco provides wizardlike functionality when configuring many Cisco IOS features, including LAN, WAN, firewall, and VPN features. The use of SDM is beyond the scope of this book; however, if you are comfortable using the CLI of a router, you will find that using SDM makes configuring a Cisco router, including its security features, a very simple process. More information about SDM can be found at http://www.cisco.com/en/US/products/sw/secursw/ps5318/index.html.


Figure 2-30. SDM's Main Window





TIP

If you are not familiar with the CLI of Cisco routers, SDM is the right management tool for you. Using a GUI interface, SDM turns your input into actual router CLI commands. After you perform and apply a configuration in SDM on your router, you can use the CLI to view the actual commands that SDM implemented. This provides a training tool to help you become more familiar with the CLI.



Implementing Firewall Features
One of the first things you need to do is secure your firewall(s) itself. In other words, if a hacker breaks into your firewall, your network is wide open to a multitude of attacks. Therefore, you should be very careful about how it is administered, what services it is running, and how an administrator can access and manage it. Part II, "Managing Access to Routers," covers this information.

Most firewall devices use rule sets to set up security rules and access controls. As you will see with Cisco routers in Part III, "Nonstateful Filtering Technologies," and Part IV, "Stateful and Advanced Filtering Technologies," most of the security rules and access controls are defined by using access control lists (ACLs). As you will see, you can use many methods in the Cisco IOS to create your rule sets. These rule sets should be defined as specifically as possible: If you are permitting traffic between two machines, be specific about the type of traffic, such as TCP on port 80, or UDP on port 69. Basically, the rule-set premise should be to permit certain things and drop everything else.

Other features also should be implemented on your firewalls, if necessary: address translation (Part V, "Address Translation and Firewalls"), access authentication to your network (Part VI, "Managing Access Through Routers"), IDS (Part VII, "Detecting and Preventing Attacks"), VPNs (Part VIII, "Virtual Private Networks"), and other necessary features and services.

Firewall Administration and Management
After you have completed your firewall system implementation, you need to administer and manage it on an ongoing basis. One of the weakest links in your security setup is the people maintaining it: People are prone to making errors. Therefore, your security solution should be simple enough for your administrators to make changes to it and to troubleshoot it, yet still meet the objectives outlined in your company's security policy.

Even in this situation, configuration errors will be made in your firewall system. Therefore, before any changes are made to the firewall system, it is important that you back them up before the changes are made. After changes are made, it is of the utmost importance that you always test changes in your firewall system.

You should use two basic methods when testing the configuration. First, you should print the configuration and compare its rule set to your security policy, to double-check that the configuration it is using follows the security policy. Second, use software tools to test the change. In this situation, you, the administrator, are pretending to be the hacker. Many tools available to you enable you to perform all kinds of tricks, such as IP spoofing, DoS attacks, and others. Some of these I cover in this book as I show you how to use your Cisco IOS router to protect yourself from them. Many vendors also sell software packages geared toward security policy testing. The tools I use are either freeware or shareware.

CAUTION

Any major changes to a firewall system first should be done in a lab environment and should be tested before being configured on your production firewall system. Failure to do this can create serious security problems for your network if you make configuration mistakes.

Firewall Categories

A firewall system can be composed of many different devices and components. One of those components is the filtering of traffic, which is what most people commonly call a firewall. Filtering firewalls come in many different flavors, including the following:

Packet-filtering firewalls

Stateful firewalls

Application gateway firewalls

Address-translation firewalls

Host-based (server and personal) firewalls

Hybrid firewalls

The following sections cover these different firewall categories, explaining how they function and describing the advantages and disadvantages each of them have.

Packet-Filtering Firewalls
The simplest form of a firewall is a packet-filtering firewall. A packet-filtering firewall is typically a router that has the capability to filter on some of the contents of packets. The information that the packet-filtering firewall can examine includes Layer 3 and sometimes Layer 4 information, as shown in Figure 2-5. For example, Cisco routers with standard ACLs can filter information at Layer 3, and Cisco routers with extended ACLs can filter information at both Layers 3 and 4.


Figure 2-5. Packet Filtering Firewalls and the OSI Reference Model





My First Firewall
The very first firewall product that I worked with, back in late 1993, was called the TIS Firewall Toolkit. From my recollection, it was the first commercial firewall product available. At that time, TIS was developing a UNIX-based version of the product, and the beta versions were available for free download to encourage use of the product and to help find and remove any bugs. This firewall could perform only simple packet filtering. It is a freely available source product, although TIS holds the rights to sell it as a commercial product.





Because TCP/IP is the de facto standard of communications protocols in today's networks, most packet-filtering firewalls support at least this protocol. However, packet-filtering firewalls can support other protocols as well, including IPX, AppleTalk, DECnet, and Layer 2 MAC address and bridging information. Cisco routers with standard and extended ACLs support many protocols, including the ones mentioned.

Filtering Actions
When implementing packet filtering, packet-filtering rules are defined on the firewall. These rules are used to match on packet contents to determine which traffic is allowed and which is denied. When denying traffic, two actions can be taken: notify the sender of traffic that its data was dropped or discard the data without any notification. This can be important when implementing a firewall solution. With the first option, the user knows that traffic was filtered by a firewall. If this is an internal user trying to access an internal resource, the user can call the administrator and discuss the problem. The administrator then can change the filtering rules to allow the user access if the user has the appropriate privileges. If the packet-filtering firewall did not send back a message, the user would have no idea why the connection could not be set up and would have to spend more time troubleshooting the problem.

On the other hand, if a hacker on the Internet is trying to access internal resources in your network, and the hacker gets back a message that the information is being filtered, this gives the hacker information about your network that might tell him how you are protecting it. In this situation, you might want to have your packet-filtering firewall silently drop the filtered traffic. As an example, you might have an internal web server running on port 80 of a device. You have a filtering rule that blocks port 80 traffic for most outside users except for your remote office locations. When a hacker tries to reach port 80 while doing a port scan, if your packet-filtering firewall sends back a message that port 80 is being filtered, the hacker now knows that you are using a filtering device to protect internal resources, and he will spend more time investigating the reaction to different kinds of packets that he tries to slip through the firewall.

Filtering Information
A packet-filtering firewall can filter on the following types of information:

Source and destination Layer 3 address

Layer 3 protocol information

Layer 4 protocol information

Interface of sent or received traffic

For example, a Cisco router can be used to filter on specific ICMP messages (Layer 3), or source and destination IP addresses (Layer 3) and TCP port numbers (Layer 4). Table 2-2 displays some of the things that a TCP/IP packet-filtering firewall can filter on.

Table 2-2. TCP/IP Packet Filtering Information Layer
Filtered Information

3
IP addresses

3
TCP/IP protocols, such as IP, ICMP, OSPF, TCP, UDP, and others

3
IP precedence (type of service [ToS]) information

4
TCP and UDP port numbers

4
TCP control flags, such as SYN, ACK, FIN, PSH, RST, and others





As you can see, you can use a lot of information when making filtering decisions on your packet-filtering firewall. For example, examine the filtering table that the packet-filtering firewall (a router, in this example) is using in Figure 2-6. Table 2-3 shows the router's packet-filtering rules. Assume that these rules are activated on the WAN interface connected to the Internet as traffic comes into the interface.

Table 2-3. Packet-Filtering Table Rule
Source Address
Destination Address
IP Protocol
IP Protocol Information
Action

1
Any
200.1.1.2
TCP
Port 80
Allow

2
Any
200.1.1.3
UDP
Port 53
Allow

3
Any
200.1.1.4
TCP
Port 25
Allow

4
Any
Any other address
Any
Any
Drop






Figure 2-6. Packet-Filtering Firewall Example

[View full size image]





In this example, rule 1 states that if traffic from any device on the Internet is sent to TCP port 80 of 200.1.1.2, the packet-filtering firewall should allow it. Likewise, if any traffic is sent to UDP port 53 of 200.1.1.3 or TCP port 25 of 200.1.1.4, the traffic should be allowed. Any other type of traffic should be dropped.

It is important to point out that if you omit rule 4, you might have issues with a packet-filtering firewall. A packet-filtering firewall will make one of two assumptions:

If there is no match in the rule set, allow the traffic.

If there is no match in the rule set, drop the traffic.

For example, assume that you have a packet-filtering firewall that used the first process. In this example, if you omitted rule 4 in Table 2-3, if there were no matches in rules 1 through 3, all other traffic would be permitted.

If your packet-filtering firewall uses the second process, if you omitted rule 4 in Table 2-3, any traffic that did not match the first three rules would be dropped (Cisco uses this process with its ACLs).

CAUTION

Understanding the rule sets that your packet-filtering firewall uses, as well as understanding how the rules are processed, is extremely important. You need to be very careful when creating or changing your rules: An inadvertent configuration mistake can create a huge security hole in your packet-filtering firewall.



Another important item to point out is how packet filters are activated on the firewall. Typically, they are activated on an interface, with a direction specified for traffic flow. For example, a packet-filtering firewall might enable you to filter traffic as it comes into an interface, leaves an interface, or both. If it enables you to filter in both directions, this gives you more flexibility in creating your rule sets: You can restrict traffic coming into your network as well as user traffic trying to leave it. Typically, inbound rules for external users filter on both Layers 3 and 4 information. When setting up policies about Internet access, in many situations, a simple Layer 3 packet filter can be used to restrict which of your internal users have the right to access the Internet. Of course, you always can apply Layer 4 filtering to your users' traffic, to be more granular about what sites and applications they are allowed to access.

Advantages of Packet-Filtering Firewalls
Packet-filtering firewalls have two main advantages:

They can process packets at very fast speeds.

They easily can match on most fields in Layer 3 packets and Layer 4 segment headers, providing a lot of flexibility in implementing security policies.

Because packet-filtering firewalls examine only Layer 3 and/or Layer 4 information, many routing products support this type of filtering; this includes Cisco routers with the use of standard and extended ACLs. Depending on the router model that you purchase, you can scale your filtering to very high speeds.

Because routers are typically at the perimeter of your network, providing WAN and MAN access, you can use packet filtering to provide an additional layer of security. These routers commonly are called perimeter or boundary routers, and they were shown previously in Figure 2-6. Even with simple Layers 3 and 4 filtering, packet-filtering firewalls can provide protection against many types of attacks, including certain types of denial-of-service (DoS) attacks, and can filter out unnecessary, unwanted, and undesirable traffic. This allows an internal firewall to deal with other types of threats and attacks that the packet-filtering firewall cannot detect or deal with.

Limitations of Packet-Filtering Firewalls
Despite their advantages, packet-filtering firewalls have these disadvantages:

They can be complex to configure.

They cannot prevent application-layer attacks.

They are susceptible to certain types of TCP/IP protocol attacks.

They do not support user authentication of connections.

They have limited logging capabilities.

As mentioned earlier, one of the disadvantages of packet-filtering firewalls involves the creation and maintenance of their rule sets. For TCP/IP, you must be familiar with the operation of various TCP/IP protocols and the fields in their headers, including IP, TCP, UDP, and ICMP, to name a few. Without this knowledge, you inadvertently could block traffic that you are supposed to allow, or allow traffic that you are supposed to block. In either situation, if you are not careful with your configuration, you could be creating a lot of problems for yourself. Plus, any changes that you do make must be tested thoroughly to ensure proper configuration.

Packet-filtering firewalls cannot prevent all types of attacks. For example, you might be allowing traffic to port 80 to a specific web server in your network. By doing this, the packet-filtering firewall is examining the destination address in the Layer 3 packet and the destination port number in the segment. If there is a match, the packet-filtering firewall allows the traffic. One problem with this approach is that the packet-filtering firewall does not examine the actual contents of the HTTP connection. One of the most popular methods of hacking a network is to take advantage of vulnerabilities found in web servers. A packet-filtering firewall cannot detect these attacks because they occur over TCP connections that have been permitted.

Also, packet-filtering firewalls cannot detect and prevent certain kinds of TCP/IP protocol attacks, such as TCP SYN floods and IP spoofing. If a packet-filtering firewall allows traffic to an internal web server, it does not care what kind of traffic it is. A hacker can take advantage of this and flood the web server with TCP SYNs to port 80, pretending to want resources on the server, but tying up resources on it instead. As another example, a packet-filtering firewall cannot detect all kinds of IP spoofing attacks. If you allow traffic from an external network, such as 201.1.1.0/24, your packet-filtering firewall can only examine the source IP address in the packets; it cannot determine whether this is the real source (or destination) of the packet. A hacker can take advantage of this to implement a DoS attack against your internal network by flooding it with allowed traffic from an allowed source.

These two problems, IP spoofing and DoS attacks, typically can be dealt with by causing an individual first to authenticate traffic before allowing it through the firewall. Unfortunately, a packet-filtering firewall examines only Layers 3 and 4 information. Performing authentication requires a firewall that processes authentication information, which is a Layer 7 (application layer) process.

Finally, packet-filtering firewalls typically support logging functions. However, their logging functions are limited to just Layers 3 and 4 information. If someone was executing a specific type of web server attack on port 80 and you were denying port 80 traffic, your packet-filtering firewall could log the deny action, but, unfortunately, the firewall wouldn't log the application-layer data encapsulated in the HTTP transport segment. Therefore, you, as an administrator, would know that someone was attempting to access port 80 on your server, but you would not know what that person was trying to do.

Uses for Packet-Filtering Firewalls
Because of these limitations, packet-filtering firewalls typically are used in the following areas:

As a first line of defense (perimeter router)

When security policies can be implemented completely in a packet filter and authentication is not an issue

In SOHO networks that require minimal security and are concerned about cost

Many companies use packet-filtering firewalls as a first line of defense, with some other type of fully functioning firewall behind it providing additional security. An example of this is a Cisco PIX.

Likewise, packet-filtering firewalls can be used for internal access control between different subnets and departments where authentication is not necessary. In this example, you are concerned about controlling access to specific internal resources from your users; you are not as concerned about sophisticated hacking attacks from your users.

Many SOHO networks employ packet-filtering firewalls because of their simplicity and cost when compared to other types of firewalls. SOHOs are interested in basic security at a reasonable cost. You must realize, of course, that packet-filtering firewalls do not provide complete protection for the SOHO, but they do provide at least a minimal level of protection to keep out many types of network threats and attacks.

Stateful Firewalls
Unlike packet-filtering firewalls, stateful firewalls keep track of the state of a connection: whether the connection is in an initiation, data transfer, or termination state. This is useful when you want to deny the initiation of connections from external devices, but allow your users to establish connections to these devices and permit the responses to come back through the stateful firewall.

Many security people disagree on what layer of the OSI reference model stateful firewalls function at: Layers 3 and 4 (transport), or Layers 3, 4, and 5 (session). From a transport layer perspective, the stateful firewall examines information in the headers of Layer 3 packets and Layer 4 segments. For example, it looks at the TCP header for SYN, RST, ACK, FIN, and other control codes to determine the state of the connection.

However, because the session layer establishes and tears down the connection—the transport layer handles the actual mechanics of the connection—some say that stateful firewalls operate at Layer 5, as shown in Figure 2-7. In either case, remember that stateful firewalls know about a connection and its state.


Figure 2-7. Stateful Firewalls and the OSI Reference Model





Problems with Packet-Filtering Firewalls
This section and the next one examine one of the issues that packet-filtering firewalls have with traffic and how stateful firewalls can deal with it.

Refer to Figure 2-8 for the example. In the figure, the packet-filtering firewall has a rule placed on its inbound interface from the Internet stating that any external traffic sent to 200.1.1.10 (a user's PC) is denied. As shown in Figure 2-8, when 170.1.1.1 tries to access 200.1.1.10, the packet-filtering firewall drops the traffic, as it is supposed to do.


Figure 2-8. Packet-Filtering Firewall Example—Initiating Connections

[View full size image]





However, what happens if someone inside the network, such as 200.1.1.10, tries to access this external device (170.1.1.1)? Assume that this is an HTTP request to 170.1.1.1, which has a web server running on it. HTTP uses TCP, and TCP goes through a three-way handshake to establish a connection before data is transferred: SYN, SYN/ACK, and ACK. Initially, 200.1.1.10 sends a SYN to establish a connection. With TCP (and UDP), a source port number is chosen that is greater than 1,023, which represents this specific connection. The destination is port 80, telling 170.1.1.1 that this is an HTTP request for web services.

As the packet-filtering firewall receives the traffic on its internal interface, it checks to see if the traffic for 200.1.1.10 is allowed to leave the network. In this case, no filtering rules prevent this, so traffic for 200.1.1.10 traffic is sent to the 170.1.1.1.

170.1.1.1 now responds back to the TCP SYN message of 200.1.1.10 with a SYN/ACK (the second step in the three-way handshake), as shown in Figure 2-9. However, when the packet-filtering firewall examines the packet, it determines that because the destination is 200.1.1.10, the packet should be dropped, according to its packet-filtering rules. Therefore, the connection cannot be set up to the external web server, denying the internal user's web access.


Figure 2-9. Packet-Filtering Firewall Example—Handling Responses

[View full size image]





Opening Ports
You can solve this problem with packet-filtering firewalls in two ways:

Open destination ports greater than 1023 as traffic comes back to the source

Examine the TCP control bits to determine whether this is returning traffic

Take a look at the first solution. In this situation, the source originally opened a source port greater than 1023, such as 10,000, and used a destination port of 80 for HTTP. Therefore, to allow the traffic to return from 170.1.1.1, the packet-filtering firewall needs a rule that will allow port 10,000. Of course, the problem with this is that the source can use any source port number greater than 1023: Whichever one is free and is chosen by the operating system is the one assigned. Therefore, you would have to allow all ports greater than 1023 to allow the returning traffic to 200.1.1.10, as shown in Figure 2-10.


Figure 2-10. Packet-Filtering Firewall Example—Opening Ports

[View full size image]





CAUTION

Opening ports greater than 1023 is not a recommended practice to allow returning traffic from an originating connection: You are creating a huge security hole in your firewall that will open your internal devices to all kinds of attacks.



Examining TCP Control Bits
The second approach is to examine transport layer information about the connection to determine whether it is part of an existing connection and, if so, allow the returning traffic back to 200.1.1.1. With TCP, this can be done by examining the control flags in the TCP segment header. These are shown in Table 2-4 and are defined in RFC 793. Note that multiple codes, commonly called flags, can be sent in the same segment header, such as SYN and ACK (SYN/ACK), or FIN and ACK (FIN/ACK).

Table 2-4. TCP Control Information TCP Message
Explanation

ACK
Acknowledges receipt of data

FIN
Terminates a connection

PSH
Acts as the push function

RST
Resets the connection

SYN
Initiates a connection and synchronizes sequence numbers

URG
Points to urgent data in the segment payload





In this situation, the packet-filtering firewall examines not only the source and destination addresses and port numbers, but, for TCP connections, it also examines the code bits to determine whether this is traffic being initiated from a device or traffic being sent in response to a request. For example, when the internal user (200.1.1.10) sends a TCP SYN, you know that the 170.1.1.1 will respond with a SYN and ACK in the TCP segment header. Therefore, if you know what kind of response control flags TCP uses, you could configure your packet-filtering firewall to allow this traffic, as shown in Figure 2-11.


Figure 2-11. Packet-Filtering Firewall Example—Examining Transport Control Codes

[View full size image]





Two problems exist with examining control codes at the transport layer:

Not all transport layer protocols support control codes.

Control codes can be manipulated manually to allow a hacker to slip packets through a packet-filtering firewall.

One of the biggest problems of having the packet-filtering firewall examine the control codes is that, in the TCP/IP protocol suite, TCP has control codes, but UDP doesn't. Therefore, for a UDP connection, you do not know whether this is the beginning, middle, or end of a connection unless you examine the data encapsulated in the UDP segment.

The other problem is that, even for transport-layer protocols that support control codes, such as TCP, these control codes can be manipulated manually. For example, the packet-filtering router in Figure 2-11 allows traffic to 200.1.1.10 if certain control codes, such as SYN and ACK, are set in the TCP header. The assumption here—and it is a big assumption—is that the data is a response to information that 200.1.1.10 requested from an external device, such as 170.1.1.10. However, the packet-filtering firewall cannot distinguish between a valid response and a fake response. With a fake response, a hacker generates TCP segments with certain code flags set, trying to gain access through your firewall. A packet-filtering firewall, cannot distinguish between the two types of traffic.

CAUTION

The established Cisco parameter for TCP extended ACLs examines the code flags and allows returning traffic into the network. However, a hacker can manipulate this returning traffic, opening you to reconnaissance, DoS, and other types of attacks.



State Table
Unlike packet-filtering firewalls, stateful firewalls use a mechanism to keep track of the state of a connection. See Figure 2-12 and Figure 2-13 for an illustration of this. Figure 2-12 uses the same network discussed in the last section with a packet-filtering firewall. In this example, the packet-filtering firewall has been replaced by a stateful firewall, but the filtering rule is unchanged: Any traffic sent to 200.1.1.10 is dropped.


Figure 2-12. Stateful Firewall Filtering Example—Part 1

[View full size image]






Figure 2-13. Stateful Firewall Filtering Example—Part 2

[View full size image]





Assume that 170.1.1.1 sends traffic to 200.1.1.10. As shown in Figure 2-12, this traffic is dropped. Now assume that 200.1.1.10 opens a web connection to 170.1.1.1, as shown in the bottom part of Figure 2-12. When 200.1.1.10 does this, it uses a TCP segment with a source port of 10,000 and a destination port of 80. It uses a SYN flag in the control field.

When the stateful firewall receives this traffic, it first checks to see whether the 200.1.1.10 connection is allowed out. In this case, no filtering rules prevent this. Unlike a packet-filtering firewall, which just forwards the packet to 170.1.1.1, a stateful firewall adds a filtering rule to its configuration. This information either is added to the top of the existing filtering rule set or is placed into a state table. This table is used to keep track of the state of connections. The former process is shown in Figure 2-13.

After 170.1.1.1 receives the connection request, it responds to 200.1.1.1 with a SYN/ACK. When this segment reaches the stateful firewall, the firewall looks in its state table first (if the second method discussed previously is used) to see if the connection exists. Then it processes the filtering rules on the interface. In this example, only one table was used, but the connection entry was placed at the top. Because the connection information was added when 200.1.1.1 initiated the connection, the stateful firewall knows that the response from 170.1.1.1 (TCP port 80) to 200.1.1.1 (TCP port 10,000) is part of an existing connection and, therefore, that should allow the traffic, as shown in Figure 2-13.

One advantage of the stateful process is that when the connection terminates, the source or destination device tears down the connection and the stateful firewall notices this by examining the TCP header control flags and dynamically removes the connection from the state table (or filtering rules table).

Therefore, when comparing packet-filtering firewalls and stateful firewalls, stateful firewalls are more intelligent because they understand the state of a connection: initiating a connection, transferring data, or terminating a connection. Basically, a stateful firewall contains a superset of packet-filtering functions.

Advantages of Stateful Firewalls
As you learned in the previous explanation, stateful firewalls have advantages over packet-filtering firewalls:

Stateful firewalls are aware of the state of a connection.

Stateful firewalls do not have to open up a large range of ports to allow communication.

Stateful firewalls prevent more kinds of DoS attacks than packet-filtering firewalls and have more robust logging.

First, stateful firewalls are aware of a connection's state: Stateful firewalls typically build a state table and use this table to allow only returning traffic from connections currently listed in the state table. After a connection is removed from the state table, no traffic from the external device of this connection is permitted. Therefore, these types of connections are more difficult to spoof. For instance, with HTTP, connections are very short lived, so if a hacker noticed the connection being torn down and tried to sneak in some data by spoofing the TCP port numbers and IP addresses, the data would be stopped because the connection entry already would have been removed.

However, if this was a Telnet connection, which might last many minutes or hours, the hacker could attempt to spoof the connection. To do this, the hacker would not only have to spoof the port numbers in the transport layer segment, but he also would have to spoof the IP addressing information, which is a difficult process if the hacker wants this information returned to his desktop. Even so, when the real source or destination terminated the connection, the stateful firewall would remove the entry.

Second, stateful firewalls do not require you to open a large range of port numbers to allow returning traffic back into your network: The state table is used to determine whether this is returning traffic; otherwise, the filtering table is used to filter the traffic.

Third, by using a state table, the stateful firewall can prevent more kinds of DoS attacks than a packet-filtering firewall. Plus, the stateful firewall can log more information than a packet-filtering firewall, such as when a connection was set up, how long it was up, and when it was torn down.

Limitations of Stateful Firewalls
You would think that with these advantages, stateful firewalls are a great tool, and they are. But stateful firewalls have these limitations:

They can be complex to configure.

They cannot prevent application-layer attacks.

They do not support user authentication of connections.

Not all protocols contain state information.

Some applications open multiple connections, some of which use dynamic port numbers for the additional connections.

Additional overhead is involved in maintaining a state table.

The first three items I already discussed in the section on packet-filtering firewalls. As with packet-filtering firewalls, most of the filtering is done by specifying rule sets with Layers 3 and 4 information, which can be complex. Plus, because stateful firewalls really only process Layers 3, 4, and 5 (depending on whom you speak with) information, they can't detect application-layer attacks or perform any type of user authentication to allow the setup of a connection.

Stateful Firewall Problem: Nonstateful Protocols
In addition to these problems, stateful firewalls have issues with nonstateful protocols. Protocols that go through a defined process to establish, maintain, and tear down a connection are called stateful; mechanics are defined as to how these processes occur. TCP is an example of a stateful protocol.

However, not all protocols are stateful: UDP and ICMP are not. For example, UDP has no defined process for how to set up, maintain, and tear down a connection; this is defined on an application-by-application basis. A simple example is a DNS resolution: A source generates a DNS request to resolve a name, and a DNS server responds with a reply with the IP address for the name. In this example, keeping track of the state of the connection is simple: The stateful firewall looks for a DNS request, adds an entry to the state table to allow the reply, and then removes the entry when the DNS server sends the reply.

Not all UDP applications are this simple, however. In most of these applications, many packets are sent between the source and destination, typically at a constant rate. Most stateful firewall solutions treat UDP traffic as stateful by assigning an idle timer to these connections in the state table. As an example, a stateful firewall might use an idle timer of 30 seconds; if after 30 seconds no UDP traffic is seen for a UDP entry in the state table, the stateful firewall removes it. The main problem with this approach is that if a hacker sends spoofed packets into your network, this would keep the entry in the table indefinitely. Of course, a hacker must be quick about this because most UDP connections are temporary.

Like UDP, ICMP also presents problems. A simple example is a ping test. Depending on the ping program, it might generate 1, 3, 5, or even 10 echo test requests. Given this discrepancy, how should a stateful firewall handle this nonstateful protocol? As with UDP, one solution is to use an idle timer, but this entry in the state table can be spoofed. As with UDP, ICMP connections are very brief, so spoofing this connection is unlikely. Another solution would be to put a separate entry in the state table for each echo request. The problem with this is that if you are doing a congestion test by generating thousands of echo requests, your stateful firewall can become overburdened by trying to manage all of these short, temporary connections.

Stateful Firewall Problem: Multiple Application Connections
Another problem that stateful firewalls have involves dealing with applications that open additional connections to transmit information. These can include FTP, multimedia, NetBIOS, and many others. FTP is used as an example here. FTP supports two different modes:

Standard (or active)

Passive

Both modes set up two TCP connections. An example of these connections is shown in Figure 2-14. With passive-mode FTP, as long as the user is inside the network establishing connections going out, you have no problems: Both outbound connections are placed in the state table, and the returning traffic for these automatically is allowed. However, if the client device is outside the stateful firewall, you would need a specific filtering rule to allow the port 21 connection (called the control channel) and a very expansive filtering rule to allow the second connection (the data channel).


Figure 2-14. FTP Connections





NOTE

Packet-filtering firewalls have the same problem with external users and passive FTP.



With standard FTP, if the client is inside the network and the server is outside, both stateful and packet-filtering firewalls would have problems dealing with the data connection that the FTP server was establishing to the client: You would have to open a whole range of ports to allow this second connection.

Stateful Firewall Problem: Size of State Table
When it comes to the state table, it is a double-edged sword for stateful firewalls. Yes, it does provide a lot of advantages. But in large networks, the stateful firewall might be busy building and maintaining the state table, putting an extra burden on its processing capacity. The more connections your stateful firewall must monitor, the more horsepower your stateful firewall needs to maintain the table, thus increasing its cost. Unlike stateful firewalls, packet-filtering firewalls typically have small filtering tables, which has much less impact on its processing than a stateful firewall has with its state table.

Uses for Stateful Firewalls
Because of its increased intelligence over packet-filtering firewalls, stateful firewalls typically are used in the following areas:

As a primary means of defense

As an intelligent first line of defense (perimeter router with stateful capabilities)

Where more stringent controls over security than packet filtering are needed, without adding too much cost

In most situations, a stateful firewall is used as a primary means of defense by filtering unwanted, unnecessary, or undesirable traffic. Its main advantage over packet-filtering firewalls is that it opens dynamic, temporary holes in the filter rule set to allow returning traffic from connections that originated inside your network.

In some situations, certain routing products support a stateful function and can be used as either a primary line of defense or, more typically, as an additional security boost on your perimeter router. In a design with two firewalls—main and perimeter—a router typically is not used as the main stateful firewall because of performance issues; instead, a dedicated firewall appliance is used as the main firewall device.

Also, stateful firewalls provide more control over packet-filtering firewalls, typically at not too much additional cost. If you are more concerned about security, you might consider purchasing a stateful firewall or upgrading a router that supports stateful features to take advantage of more intelligent packet filtering.

Application Gateway Firewalls
Application gateway firewalls (AGFs), commonly called proxy firewalls, filter information at Layers 3, 4, 5, and 7 of the OSI reference model, as shown in Figure 2-15. Because AGFs process information at the application layer, most of the firewall control and filtering is done in software, which provides much more control over traffic than packet-filtering or stateful firewalls.


Figure 2-15. Application Gateway Firewalls and the OSI Reference Model





Sometimes AGFs support only a limited number of applications, or even just one application. Some of the more common applications that an AGF might support include e-mail, web services, DNS, Telnet, FTP, Usenet news, LDAP, and finger.

TIP

When choosing an AGF, one of the issues to evaluate is the applications supported and the applications needed to send through it.



Authentication Process
One of the features of AGFs is that they typically allow you to authenticate connection requests before allowing the traffic to an internal or external resource. This enables you to authenticate the user requesting the connection instead of the device. This is one disadvantage that packet-filtering and stateful firewalls have: They examine only Layers 3 and 4 information and, thus, can authenticate only the Layer 3 address of a device.

Figure 2-16 shows a simple example of an AGF using an authentication process. In this example, the user first must authenticate to the AGF. This can be done by having the user open a special connection—perhaps a web browser connection to the AGF, or the AGF can intercept the user's initial connection request and send the user a request for authentication information, like a web browser pop-up window. The AGF or an authentication server then authenticates the user's identity. The authentication process occurs in software at the application layer. In Figure 2-16, the authentication database is on the AGF and uses a username and password. In this database, the AGF allows Richard to access web server A upon successful authentication, but it will not allow Richard to access web server B. As you can see from this example, when Richard authenticates, he can access web server A; however, he cannot access any other resource. In Figure 2-16, when Richard tries to send information to web server B, the AGF drops that information.


Figure 2-16. AGF Authentication Process

[View full size image]





NOTE

To make the authentication and connection process more efficient, many AGFs authenticate a user once and then use authorization information stored in the authentication database to determine what resources a person can access. The authorization then is used to limit the additional resources that the user is allowed to access, if any, instead of requiring the user to authenticate for each resource that he wants to access. Also note that the AGF can be used to authenticate both inbound and outbound connections.



Authentication Methods
An AGF can use many methods to authenticate a connection request, including username and passwords, token card information, Layer 3 source addresses, and biometric information. Typically, Layer 3 source addresses are not used for authentication, unless they are combined with one of the other methods. Authentication information can be stored locally or on a security server or directory service. An example of a security server is Cisco Secure ACS. Examples of directory services include Novell NDS, Microsoft Active Directory, and LDAP.

CAUTION

You should not rely on the use of just Layer 3 source addresses to perform authentication because Layer 3 addresses are susceptible to masquerading and spoofing attacks.



If you are using a username and password for authentication, the AGF prompts for the username and password. Then it does a lookup for the username and compares the password to what the person typed. If both are the same, the user is validated. One problem with this authentication method is that if the username and password are sent across the connection in clear text, this information is susceptible to eavesdropping; a hacker then can use this information to execute a masquerading attack. Therefore, this information should be encrypted. Typically, this is done through the Secure Socket Layer (SSL) protocol within a web browser connection. This means that the person must open an HTTP SSL (HTTPS) connection to the AGF to perform the authentication. Another method is to have the person use an encrypted Telnet application, such as Secure Shell (SSH). In either method, though, the person first must access the AGF directly to perform the authentication.

Biometric information is more secure than a username and password because usernames and passwords are guessed more easily. With biometrics, some unique physical characteristic of a person, such as a fingerprint or retinal scan, is examined. However, when sending this information to the AGF, it, like usernames and passwords, is susceptible to eavesdropping. Therefore, a secure connection should be used to transmit this authentication information.

Of all of the authentication methods, token cards are the most secure. Token cards create a one-time password, a password that can be used only once. After the password has been used, it is no longer valid. The advantage of token cards is that they are not susceptible to eavesdropping: If the hacker eavesdrops and sees the token card information, it is of no use to him because it will have expired by the time the hacker tries to use it. The downside of token cards is that they can be expensive to deploy on a large scale and are more difficult to troubleshoot and set up.

Application Gateway Firewall Types
AGFs fall under two categories: connection gateway firewalls (CGFs) and cut-through proxy (CTP) firewalls. The next two sections compare the two different types.

Connection Gateway Firewalls
CGFs offer more protection than CTP firewalls. Figure 2-17 shows the process that a person goes through when setting up a connection through a CGF. In Step 1, Richard attempts to set up a connection to the internal web server (200.1.1.2). The CGF intercepts the connection and authenticates it, if this has been configured. After authentication, the CGF opens a separate connection to the internal web server (Step 2). At this point, any web traffic sent by Richard to 200.1.1.2 first is processed by the CGF and then is redirected to the internal web server, as shown in Step 3. Any other traffic from Richard is dropped unless it has been authorized by the first authentication request or unless the CGF asks for authentication for any additional connections. If Richard does not authenticate successfully, the CGF terminates the connection.


Figure 2-17. Connection Gateway Firewall Process

[View full size image]





NOTE

Many CGFs (and CTPs) enable you to configure multiple authorization rules for a single user. Therefore, when the user successfully authenticates, all the authorization rules are put into effect without requiring the user to authenticate for each connection request.



One nice feature of a CGF is that it can examine all data that Richard sends to the web server, even specific URL requests. This allows the CGF to examine what pages Richard tries to access and whether Richard is trying to sneak malformed URLs or data that might try to crash the server or open the server because of a security weakness. Basically, any character that Richard types in for the connection is visible to the CGF. This type of examination is not possible by a packet-filtering or stateful firewall because these devices operate, for the most part, at Layers 3 and 4.

With a CGF, you can be creative in your filtering. For example, you can restrict what Java applets or ActiveX scripts a user has access to. With a Telnet connection, you can monitor and restrict what commands a person can execute on a networking device, such as a Cisco router. With an FTP server, you can restrict what directories a person can see and what files he can download. As you can see, you can create some very powerful filtering rules to secure your network with a CGF.

Cut-Through Proxy Firewalls
One of the main problems of a CGF is that, for the applications that it supports, all traffic is processed at the application layer; this is very process-intensive. In some cases, you might be interested only in performing authentication of a connection at the application layer; after that, you are not really interested in monitoring the activities on the connection—you want just the authentication features. Of course, you could perform this function with a CGF; however, a CGF always processes information at Layer 7, which can introduce a noticeable delay in individuals' connections, especially on an CGF that handles thousands of connections.

Cut-through proxy (CTP) firewalls are a modified version of CGF that deals with this inefficiency. Figure 2-18 shows a simple example of the process that a CTP uses to allow connections into a network. In this example, Richard tries to access the internal web server (200.1.1.2). The CTP intercepts the connection request and authenticates Richard, shown in Step 1. After authentication, this connection and any other authorized connections are added to the filtering rules table, shown in Step 2. From here, any traffic from Richard to the web server is handled by the filtering rules at Layers 3 and 4.


Figure 2-18. Cut-Through Proxy Firewall Process





As you can see from this example, the authentication process is handled at Layer 7; after being authenticated, however, all traffic is processed at Layers 3 and 4. Therefore, the advantage that CTP has over CGF is a huge boost in throughput. However, because CTP does not examine application-layer data, it cannot detect application-layer attacks.

Typically, the CTP supports Telnet, HTTP, and HTTPS for handling the initial authentication. This is done by having the individual set up an authentication to the CTP itself. Optionally, some CTPs can intercept certain connections and respond with authentication prompts. After authentication, the CTP allows the connection initiation request to the internal resource.

Advantages of Application Gateway Firewalls
AGFs have many advantages over packet-filtering and stateful firewalls, including the following:

They authenticate individuals, not devices.

Hackers have a harder time with spoofing and implementing DoS attacks.

They can monitor and filter application data.

They can provide detailed logging.

One of the advantages of an AGF (CGF and CTP) is that it enables you to authenticate the individual who is trying to access internal resources. This enables you to prevent most spoofing attacks. Plus, DoS attacks are limited to the AGF itself: The AGF can detect these, reducing the burden on your internal resources.

With a CGF, you can monitor all data on a connection, which enables you to detect application attacks such as malformed URLs, buffer overflow attempts, unauthorized access, and more. You even can control what commands or functions an individual is allowed to perform based on the authentication and authorization information.

Finally, with an AGF, you can generate very detailed logs. With a CTP, you can log only the authentication process and any filtering done at Layers 3 and 4; with a CGF, you can monitor the actual data that the individual is sending across a connection. This can be extremely useful if a hacker finds a new type of attack: You can monitor what he does and how he does it so that you can address the problem. Besides using logging for security purposes, you can use it for management purposes by keeping track of who is accessing what resources, how much bandwidth is used, and how often the resources are accessed.

Limitations of Application Gateway Firewalls
Even with their advantages, AGFs have the following limitations:

They process packets in software.

They support a small number of applications.

They sometimes require special client software.

The main limitation of AGFs is that they are very process intensive. They require a lot of CPU cycles and memory to process every packet that they see, which sometimes creates throughput problems. Plus, the detailed logging can create disk space problems. To address these issues, you can use one of these two solutions:

Use a CTP

Have the AGF monitor only key applications

For the first solution, using a CTP enables you to do authentication and authorization only; you cannot monitor data on the connection. With the second solution, you limit the AGF to processing only certain application types, such as e-mail, Telnet, FTP, or web services—and then, perhaps, processing just connections to specific internal resources. The problem with this approach is that you are not monitoring all applications and connections, creating a security weakness.

AGFs also typically do not support all applications. They generally are limited to one or a handful of connection types, such as those listed at the beginning of this section. Therefore, you cannot monitor data on all connections.

Finally, AGFs sometimes require you to install vendor-specific software on the client, which is used to handle the authentication process and any possible connection redirection. This can create scalability and management issues if you need to support thousands of clients.

Other Types of Application Proxy Devices
Other types of application gateway devices exist besides AGFs. AGFs are used mainly for security purposes; however, other application gateways (commonly called proxies) can be used to help with throughput issues.

For example, a common type of proxy is an HTTP proxy. With an HTTP proxy, an individual configures the web browser to point to the proxy. Whenever the individual requests a web page, the request goes to the proxy first. The proxy examines its local cache to see if the information was retrieved previously. If it is in the cache, the proxy responds with the information; otherwise, the proxy generates a request to pull the information from the real web server, caches that information, and forwards it to the client. This is similar to a CGF, but without the security functions.

Sometimes these proxies are used to help reduce logging functions on the AGF itself. The AGF monitors connections and creates logging records for security events, but the application proxy handles the detailed logging of all connection data. Likewise, application proxies are useful for tracking your internal users' Internet and remote resource access. This is important if you have acceptable use and abuse policies and need to monitor resource requests so that you can enforce these policies.

Uses for Application Gateway Firewalls
Because of its increased intelligence over packet-filtering and stateful firewalls, AGFs typically are used in the following areas:

A CGF commonly is used as a primary filtering function.

A CTP commonly is used as a perimeter defense.

An application proxy is used to reduce the logging overhead on the CGF, as well as to monitor and log other types of traffic.

In many situations, a CGF is used as a primary filtering defense. In this situation, a perimeter router might or might not be used as a first line of defense; however, the CGF functions as the main line of defense and protection. The CGF performs authentication, but this can be offloaded to a CTP perimeter device. The CGF also performs application filtering and monitoring, and is used to prevent many types of application layer attacks.

A CTP commonly is used as a perimeter defense tool. It performs initial authentication but processes filtering at Layers 3 and 4, thereby reducing its load and allowing a smaller-end device to handle perimeter connectivity.

If too much traffic needs to be monitored or logged, an application proxy is used to offload these functions from the CGF. This allows the CGF to handle important security screening tasks, but it still enables you to keep a detailed record of all connections.

Address-Translation Firewalls
Address translation was developed to address two issues with IP addressing:

It expands the number of IP addresses at your disposal.

It hides network addressing designs.

The main reason that address translation (RFC 1631) and private addresses (RFC 1918) were developed was to deal with the concern of the shortage of addresses that was seen on the horizon in the mid- to late 1990s. I thoroughly discuss this topic in Chapter 11, "Address Translation," and Chapter 12, "Address Translation Issues."

Basically, address translation translates the source/destination address(es) and/or port numbers in an IP packet or TCP/UDP segment header. Because of this, address-translation firewalls (ATF) function at Layers 3 and 4 of the OSI reference model, as shown in Figure 2-19.


Figure 2-19. Address-Translation Firewalls and the OSI Reference Model





This section focuses on the second reason: hiding network addressing designs.

Filtering Process
Most people assume that address translation is used to translate private to public addresses or vice versa, so you might be wondering how you can use address translation as a security function. Examine Figure 2-20, which illustrates the usefulness of address translation in protecting your network. In this example, two web servers have private addresses assigned to their NICs, 192.168.11.2 and 192.168.12.2. Because private IP addresses are nonroutable in public networks, a public address must be associated with these two devices, and a DNS server needs to send the public address in response to DNS queries for the addresses of these devices.


Figure 2-20. Address-Translation Firewall Example

[View full size image]





The ATF defines the translation rules. Traffic heading to 200.1.1.2 is translated to 192.168.11.2, and traffic to 200.1.1.3 is translated to 192.168.12.2, and vice versa. This process serves two functions. First, an outside person cannot decipher anything about the IP address structure of your network: That person knows only that 200.1.1.2 and 200.1.1.3 are reachable addresses and appear to be on the same segment. The outside person does not know that these web servers are on two different physical segments behind two different routers.

Second, traffic sent to any other device in your network cannot be reached it unless it first is translated; remember that your internal devices are using private addresses. If an outside person sends traffic to an address of 192.168.x.x, his ISP (or some other ISP) will drop it. If the outside person sends traffic with a public address in it, only the public addresses listed in your translation table will allow the translation to take place so that the data can reach the internal resource. For example, there is no way that 170.1.1.1 can reach web server C because there is no translation in the ATF.

Address translation also can be used to restrict traffic leaving your network. Again, refer to Figure 2-20. In this example, if web server A sends data to 170.1.1.1, when the packets are received by the ATF, the firewall looks at its table and sees that this should be translated to 200.1.1.2 and forwarded to the Internet. However, there is a problem if web server C tries to send data to 170.1.1.1. When the ATF sees these packets from web server C, it looks in its translation table and does not find a match. At this point, the ATF can take one of two actions:

Drop the packets

Forward the packets

If the ATF takes the first approach, you definitely have restricted Internet access for devices that are not listed in the translation table. If the address-translation firewall forwards the packets but does not perform any address translation, the same result occur, but when these packets are received by your ISP. In this instance, because they are private addresses, your ISP should drop them.

CAUTION

I am assuming that you are using private addresses inside your network. Address translation can translate private addresses to public addresses (and vice versa), private addresses to private addresses, and public addresses to public addresses. If you are using public addresses on inside devices and you do not have translation rules on your ATF for these devices, you need to ensure that your ATF drops all packets without configured rules (assuming that you want to implement a drop policy when no match occurs).



Given these two scenarios—traffic heading into your network or leaving your network—the ATF serves as an access-control point. As a control point, the ATF controls which traffic enters or leaves by the nature of its function: translating addresses. Therefore, because traffic must go through this device to enter or leave your network, it becomes easier to centralize your security policies as well as to implement them.

NOTE

These two examples used simple network address translation: translating one IP address to another. However, this can be expanded easily to include TCP or UDP ports in the translation process, allowing you to restrict translations for specific applications.



Advantages of Address-Translation Firewalls
ATFs provide these advantages:

They hide your network-addressing design.

They control traffic entering and leaving your network.

They allow for the use of private addressing.

As already mentioned, ATFs hide your IP addressing design. Plus, you easily can control traffic as it enters and leaves your network if your internal devices are using private addresses: Your address translation firewall serves as a choke-point. Only through the configuration of address-translation rules can traffic enter or leave the network. Plus, with the capability to use private addresses, you have millions of IP addresses at your disposal: 1 Class A, 16 Class B, and 256 Class C network numbers.

Limitations of Address-Translation Firewalls
Just like any firewall solution, address translation firewalls have limitations, including the following:

Delay is introduced because of packet manipulations.

Some applications do not work with address translation.

Tracing and troubleshooting become more difficult.

Because address translation must change the IP address(es) in the IP header, the header checksum must be recomputed; plus, if port address translation is performed on TCP or UDP segment headers, the checksums in these headers also must be recomputed. This process of changing packet and segment contents, as well as recomputing checksums, is very process intensive and adds delay to your data stream. In addition, the more connections that you have defined in your address table, the longer it takes to find a match and the more processing it takes to maintain the table.

The second issue with address translation is that not all protocols function correctly or at all when address translation is performed on the packet and segment contents. Some applications embed addressing information in the data payload of TCP and UDP segment payloads, which typically is not translated by an ATF. This can create reachability issues. Multimedia and NetBIOS applications are notorious for embedding addressing information in data payloads. This topic is covered in more depth in Chapter 12.

The third issue with address translation is a double-edged sword. Yes, by hiding your addressing scheme, you are making your network more secure. On the other hand, hackers can use this to their advantage by hiding their source addressing information. Therefore, when you are being attacked by a hacker, it becomes much more difficult for you to track down the actual culprit. Plus, troubleshooting is not an easy process when dealing with address translation because you must know both the IP address assigned to a device on its NIC and its translated address when trying to find the source and destination of a connection.

Uses for Address-Translation Firewalls
ATFs are somewhat different when compared to other types of firewalls, such as application gateways, stateful firewalls, and packet-filtering firewalls. These latter firewalls filter traffic based on filtering rules that you define, which can be very specific. ATFs are more general in their filtering process because they can filter only on address (and sometimes port) information. Therefore, ATFs typically are used in the following situations:

When you have a private IP addressing scheme in your internal network

When you need to easily separate two or more networks

If you are using private IP addresses, you need to use some type of address-translation device to allow traffic into and out of your network. An ATF provides extra security when performing this process.

An ATF also can separate two or more networks and control traffic between these through the use of address translation easily. Again, this typically is done when address translation is required. For example, one of the networks might be using private addresses, or the two networks might be using an overlapping address space.

Host-Based Firewalls
A host-based firewall is basically firewall software running on a PC or file server. When running on a personal PC, this commonly is called a personal firewall. This typically is used to enhance your security solution or to provide additional protection to your desktop. You can use literally dozens of free, shareware, and premium software-based firewall products to protect Microsoft Windows, Apple Macintosh, and the many flavors of UNIX that you might have running as your operating system.

Host-based firewalls usually do not have the same capabilities of the other firewall categories that I already discussed. They are typically a simplified packet-filtering firewall that filter on the IP protocol, such as TCP or UDP, source and destination IP addresses, and protocol information such as TCP or UDP port numbers. Host-based firewalls were built to provide a low-cost alternative to other firewall categories yet still provide a decent level of protection: They typically have fewer filtering and logging capabilities.

Figure 2-21 shows two examples of using host-based firewalls. On the left, the file server has firewall software loaded on it, providing an additional layer of protection along with the packet-filtering router/firewall. At the bottom right is a user who is connected directly to the Internet and who has a host-based firewall installed on his desktop.


Figure 2-21. Host-Based Firewall Example

[View full size image]





Advantages of Host-Based Firewalls
Host-based firewalls have the following advantages:

They can be used to enhance your security.

Some can provide host-based authentication.

Their cost is typically less than $100—and sometimes they even are free.

Typically, host-based firewalls are used to enhance the security of a device and typically are used as just one component in a firewall system. Other firewall solutions also are used, but the host-based software provides an additional layer of protection for critical resources. You never should assume that by having a main firewall between your internal devices and the network that you are now completely safe. Remember that 60 to 70 percent of attacks come from within your network. Therefore, for select resources, installing this software on critical resources provides a higher level of security.

With some host-based firewall products, user authentication is built in, allowing authentication of users before they can access resources. One advantage that this provides is that if you don't have an AGF, you can still perform user authentication at the host level.

In small networks, such as SOHO environments, purchasing one of the other firewalls from the categories that I mentioned might be cost-prohibitive. Many SOHO packet-filtering and stateful firewalls exist in the $150 to $500 range, but for a small company just beginning, it is cheaper to load a freeware host-based firewall. This is typically true for the home user who needs to protect his PC from only the casual Internet hacker.

Limitations of Host-Based Firewalls
Host-based firewalls have the following limitations:

They are software-based firewalls.

They are simplified packet filters.

They have weak logging capabilities.

They are difficult to manage on a large scale.

The first limitation of a host-based firewall is that it adds processing overhead to your PC or server: It requires more memory and CPU cycles to process traffic, and it requires a larger disk drive to log information.

For the most part, host-based firewalls are generic packet-filtering firewalls. They typically filter on IP addresses, TCP and UDP port numbers, and ICMP messages. Because they are meant for the casual user, care must be taken in their configuration, or you might create more security problems than you solve. In addition, the information that they log is typically generic in nature and will not help a lot when trying to determine whether an application layer attack is occurring or has occurred.

One of the main limitations of host-based firewalls is that they run on top of a commercial operating system, such as Windows 2000, 2003, or XP; Linux; or some other common operating system. Each of these operating systems has had security issues in the past, and you can bet that all will have security issues in the future. Therefore, these systems are more vulnerable to attack than firewall appliances. Firewall appliances, such as the PIX, typically use a proprietary operating system, which makes them more difficult to attack. Plus, these appliances were built to do one thing: implement access control, which typically is done by application-specific integrated circuits (ASICs) instead of processors. This allows firewall appliances to handle a high number of connections compared to host-based firewalls, which use a generic processor. Given this advantage of firewall appliances, as well as their low cost (between $100 and $500), many people opt to use a firewall appliance instead of host-based software. For example, I used a PIX 501 for my home network until I went wireless and installed a Linksys 54G wireless firewall appliance.

Host-based firewalls are also difficult to administer on a large scale. If you want to protect 50 web servers, all with the same security policies, ensuring that each server has the same firewall software configuration and patches becomes a difficult management process. Imagine trying to manage 50 firewalls—a simple rule change would have to be replicated 50 times. In this situation, it would be easier to use a central solution that handles firewall functions for all your servers. Plus, the more individual devices you need to secure, the more expensive a host-based system becomes, making a central solution more attractive.

Another concern is ensuring that all host-based firewalls have the appropriate rules defined on them. You might have two or three different rule sets for your various servers, and two or three more rule sets for your users. Managing the rule sets—adding, changing, and deleting rules—would be a difficult process.

NOTE

Because of management issues, you need to carefully examine the management capabilities of any host-based firewall solution that you might be considering, especially when it comes to being able to manage a wide range of rule sets across different types of hosts.



Uses for Host-Based Firewalls
Host-based firewalls offer a decent level of protection at a low cost. Because of their limitations, they typically are used in the following situations:

With home users or telecommuters with Internet access

In small SOHO environments

To add an extra level protection to critical resources, such as e-mail and database servers

Hybrid Firewalls
Because of the many advances in technology, the widespread use of the Internet, and the explosion of e-commerce and e-business, the need for security has increased greatly. Therefore, classifying a firewall product is a difficult, if not impossible, process. To provide robust security features to compete against other vendors, many of the firewall categories that I discussed previously are incorporated into a single product that sometimes is referred to as a hybrid firewall. An example of this is the Cisco PIX firewall. It supports a stateful firewall, a cut-through proxy, a minimal form of a connection gateway firewall, and address translation, as well as many other features.

Cisco IOS Routers
When I started working with Cisco routers in 1993, access control lists had just been introduced to the Cisco IOS. This allowed the Cisco IOS to perform very basic packet filtering. From there, Cisco continually has added features to the Cisco IOS. Currently, the Cisco IOS supports many of the same security features that the Cisco PIX firewalls support, including stateful filtering, cut-through proxy (called authentication proxy), address translation, and many other features.





Actually, in today's market place, it is almost impossible to find a firewall that neatly fits into one of the categories I previously discussed. To improve their security and market appeal, today's firewall products contain many innovative features and functions.

TIP

When evaluating a firewall solution, you should closely examine the additional features and functions of the firewall, as well as its primary function. For example, if you are interested in wire-speed stateful filtering, you would consider a Cisco PIX over a Cisco router with the Cisco IOS firewall feature set. However, when examining hardware-based firewalls such as the PIX and other vendors, scrutinize their additional features and functions to see how they best fit into your security design.



Firewalls and Other Services
Just because a firewall is branded "firewall" doesn't mean that it only performs firewall functions. Many vendors' products include a host of other features that ease administration of your network and secure it better:

Dynamic Host Configuration Protocol (DHCP) server and client functions

Virtual Private Networks (VPNs)

Intrusion detection

Fully functioning unicast and multicast routing protocols

Enhanced content filtering

Most firewalls support Dynamic Host Configuration Protocol functions. For SOHO environments, this is very important. A firewall might need to support a DHCP server to assign addressing information dynamically to clients. Likewise, the firewall might be connected directly to the ISP, and the ISP might use DHCP or Point-to-Point Protocol over Ethernet (PPPoE) to assign addressing information dynamically to the firewall.

Also, it is becoming more popular to use the Internet to connect various remote sites and users. The problem of using the Internet is that all information is susceptible to eavesdropping. Many firewalls support VPN functions that enable you to encrypt traffic between devices or networks. Cisco IOS-based VPNs are discussed in Part VIII, "Virtual Private Networks."

Some firewalls support intrusion-detection capabilities, which allow them to detect certain kinds of attacks. In most cases, the intrusion-detection system (IDS) included is a simplified implementation. This feature typically enables you to detect common networking attacks, such as popular DoS attacks, and is more suitable for SOHO environments or as an added measure of security in enterprise networks. To detect hundreds of network threats and attacks, a real IDS solution, such as Cisco's 4200 series sensors or IDS modules (IDSMs) for the Catalyst 6500 switches, should be used.

Many firewalls now can filter on some content, typically web-based. For example, some firewalls can filter Java and ActiveX scripts, which can contain dangerous code; some firewalls even can filter URL information. Chapter 10, "Filtering Web and Application Traffic," discusses how the Cisco IOS can filter web content.

As you can see, firewalls have come a long way and will face many new challenges in the future to adapt to new technologies and to deal with new security threats.