Page Topics

What Is a Firewall? What Firewalls Do What Firewalls Cannot Do How Firewalls Function Types of Firewalls Packet Filtering Stateful Packet Inspection Application Gateways/Proxies Adaptive Proxies Circuit-level Gateway Impostors Firewall Architecture Selecting and Implementing a Firewall Solution Security Policy Implementation Requirements Making the Decision Implementation and Testing Conclusion Resources

Page Illustrations

1. Network Firewall Illustration 2. OSI Model 3. Packet Filtering Firewall 4. Packet Filtering OSI Layers 5. Stateful Packet Inspection OSI Layers 6. Stateful Packet Inspection Firewall 7. Application Gateway OSI Layer 8. Application Gateway Firewall 9. Packet-filtering Router 10. Screened-host or Bastion-host Firewall 11. Dual-homed Gateway 12. Screened Subnet or Demilitarized Zone (DMZ) 13. Firewall Appliance

An Introduction to Network Firewalls and the Firewall Selection Process

Scope

This document is intended to give the reader a basic understanding of network firewalls and the firewall selection process. It addresses what a firewall can and cannot do, different ways firewalls function, architectures used in firewall solutions, and important characteristics of effective firewalls. It outlines a selection process organizations should use to determine which firewall solution will best fit their needs. Readers of this document should have a basic understanding of networking concepts, routing concepts and TCP/IP.

Introduction

With the large number of firewall solutions available today, firewall selection and implementation can be a time-consuming and overwhelming process. The appealing manner in which "firewall" solutions are marketed, along with claims of easy installation and management, can lead organizations to make the decision to implement a firewall solution without taking time to thoroughly examine the need for one. By making hasty decisions, organizations can overlook the impact a firewall solution can have on their existing network and users.

What variables should be taken into consideration when determining the need for a firewall? Organizations with a connection to the Internet or to any other "untrusted" network may need to implement a firewall solution. However, they should consider the impact a firewall will have on all network services, resources and users, and how a firewall will fit in with their particular business needs and network infrastructure. Organizations should determine what their specific requirements are, analyze their current network infrastructure and use that information as a basis for their decision. In some cases, after looking at all the variables, they may find that a firewall solution isn't necessary or would be impractical to implement.

What Is a Firewall?

The term firewall has been around for quite some time and originally was used to define a barrier constructed to prevent the spread of fire from one part of a building or structure to another. Network firewalls provide a barrier between networks that prevents or denies unwanted or unauthorized traffic.

There is no single agreed-upon definition for a network firewall. In recent years, many definitions have been developed and used. The definitions may be worded differently, but they all exhibit characteristic common theme. For the purpose of this paper the following definition will be used to describe a network firewall.

Definition:  A Network Firewall is a system or group of systems used to control access between two networks -- a trusted network and an untrusted network -- using pre-configured rules or filters.

Figure 1. Network Firewall Illustration

Firewalls can be composed of a single router, multiple routers, a single host system or multiple hosts running firewall software, hardware appliances specifically designed to provide firewall services, or any combination thereof. They vary greatly in design, functionality, architecture, and cost. Therefore, to successfully implement a firewall solution in an organization, it is important to understand what each firewall solution can or cannot do.

Firewall solutions can have both positive and negative effects on a network.

Back to Top

What Firewalls Do

Positive Effects

When implemented correctly, firewalls can control access both to and from a network. They can be configured to keep unauthorized or outside users from gaining access to internal or private networks and services. They can also be configured to prevent internal users from gaining access to outside or unauthorized networks and services. Many firewalls can be deployed within an organization to compartmentalize and control access to services between departments and other private networks.

User authentication. Firewalls can be configured to require user authentication. This allows network administrators to control access by specific users to specific services and resources. Authentication also allows network administrators to track specific user activity and unauthorized attempts to gain access to protected networks or services.

Auditing and logging. Firewalls can provide auditing and logging capabilities. By configuring a firewall to log and audit activity, information may be kept and analyzed at a later date. Firewalls can generate statistics based on the information they collect. These statistics can be useful in making policy decisions that relate to network access and utilization.

Security. Some firewalls function in a way that can hide internal or trusted networks from external or untrusted networks. This additional layer of security can help shield services from unwanted scans.

Firewalls can also provide a central point for security management. This can be very beneficial when an organization's human resources and financial resources are limited.

Negative Effects

Although firewall solutions provide many benefits, negative effects may also be experienced.

Traffic bottlenecks. In some networks, firewalls create a traffic bottleneck. By forcing all network traffic to pass through the firewall, there is a greater chance that the network will become congested.

Single point of failure. Firewalls can create a single point of failure. In most configurations where firewalls are the only link between networks, if they are not configured correctly or are unavailable, no traffic will be allowed through.

User frustration. Firewalls can frustrate users when network resources or services are blocked or unavailable to them, or they are required to authenticate to gain access and forget their passwords. The added security provided by the firewall may not be perceived as worth the increase in the technical support load.

Increased management responsibilities. A firewall often adds to network management responsibilities and makes network troubleshooting more complex. If network administrators don't take time to respond to each alarm and examine logs on a regular basis, they will never know if the firewall is doing its job. All firewalls require ongoing administrative support, general maintenance, software updates, security patches and proper incident handling, increasing the responsibilities of the administrators who are often already overworked.

What Firewalls Cannot Do

The most common misconception about firewalls is that they guarantee security for your network. A firewall cannot and does not guarantee that your network is 100% secure. To achieve greater protection, a firewall should be used in conjunction with other security measures. Even then, there is no guarantee that the network will be 100% secure.

Firewalls cannot offer any protection against inside attacks. For a firewall to be effective, all traffic must pass through it. Users on the internal or trusted network often have access to the protected services without having to go through the firewall. A high percentage of security incidents today come from inside the trusted network.

Firewalls cannot protect against unwanted or unauthorized access through back doors on your network. Back doors are typically created when an internal user dials out from an unauthorized modem and establishes a connection to an untrusted network. This behavior can be innocent in that the user doesn't even realize they are opening a back door, but it is just as threatening as shutting down the firewall.

In most implementations, firewalls cannot provide protection against viruses or malicious code. Since most firewalls do not inspect the payload or content of the packet, they are not aware of any threat that may be contained inside.

Finally, no firewall can protect against inadequate or mismanaged policies. If a password gets out, your network is at risk. Many security breaches occur because users inadvertently give out passwords or leave their workstations open. Even though the person does not have malicious intent, the results can be damaging to the security of the network.

Back to Top

How Firewalls Function

Now that we've defined what a firewall is and what it can and cannot do, let's examine how firewalls function.

There are two security design logic approaches network firewalls use to make access control decisions. These two approaches have opposite logic but the intent of both is to control access. The two approaches are:

• Everything not specifically permitted is denied.
• Everything not specifically denied is permitted.

There are proponents for each approach, but the one most often recommended is everything not specifically permitted is denied. This approach takes a proactive stance to unwanted or unauthorized access. It works on the premise that all access is denied until a rule or filter is configured that will specifically allow access. It provides more security by default, but it can also be considered too restrictive. In many instances, legitimate traffic suffers until the correct variables are identified and rules or filters are configured and implemented that will allow traffic to pass.

The opposite design logic, everything not specifically denied is permitted, takes a reactive stance to unwanted or unauthorized access. It works on the premise that all access is allowed until a rule or filter is configured that will specifically deny it. It provides less security initially, but is considered more flexible because legitimate traffic does not suffer.

Types of Firewalls

A firewall's security design logic is enforced using some type of packet-screening method. Each method uses information from different layers of the Open Systems Interconnection (OSI) model. These methods are based on how firewalls use both pre-configured rules and filters and information gathered from packets and sessions to determine whether to allow or deny traffic. The three well-known methods are packet filtering, stateful packet inspection, and application gateways/proxies. Hybrid packet screening methods often combine two or more of these to provide added functionality and security.

Figure 2. Open Systems Interconnection (OSI) Model

Back to Top

Packet Filtering

Packet filtering is the simplest packet screening method. A packet filtering firewall does exactly what its name implies -- it filters packets. The most common implementation is on a router or dual-homed gateway. The packet filtering process is accomplished in the following manner. As each packet passes through the firewall, it is examined and information contained in the header is compared to a pre-configured set of rules or filters. An allow or deny decision is made based on the results of the comparison. Each packet is examined individually without regard to other packets that are part of the same connection.

Figure 3. Packet Filtering Firewall

A packet filtering firewall is often called a network layer firewall because the filtering is primarily done at the network layer (layer three) or the transport layer (layer four) of the OSI reference model.

Figure 4. Packet Filtering OSI Layers

Packet filtering rules or filters can be configured to allow or deny traffic based on one or more of the following variables:

• Source IP address
• Destination IP address
• Protocol type (TCP/UDP)
• Source port
• Destination port

Note: All firewalls are capable of doing some form of packet filtering.

Strengths

Packet filtering is typically faster than other packet screening methods. Because packet filtering is done at the lower levels of the OSI model, the time it takes to process a packet is much quicker. When implemented correctly, packet filtering firewalls have very little impact on overall network performance.

Packet filtering firewalls can be implemented transparently. They typically require no additional configuration for clients. The only indication users may have that a firewall exists, is the inability to get to a resource or service that has been blocked.

Packet filtering firewalls are typically less expensive. Many hardware devices and software packages have packet filtering features included as part of their standard package. If an organization already owns a device or software package with packet filtering capabilities, other than time spent planning and configuring rules or filters, there is little or no additional cost.

Packet filtering firewalls typically scale better than other types of firewalls. This can be accounted for in part by the fact that they do not have the processing overhead that other types have.

Packet filtering firewalls are application independent. Decisions are based on information contained in the packet's header and not on information that relates to a specific application.

Weaknesses

Packet filtering firewalls allow a direct connection to be made between the two endpoints. Although this type of packet screening is configured to allow or deny traffic between two networks, the client/server model is never broken.

Packet filtering firewalls are fast and typically have no impact on network performance, but it's usually an all-or-nothing approach. If ports are open, they are open to all traffic passing through that port, which in effect leaves a security hole in your network.

Defining rules and filters on a packet filtering firewall can be a complex task. The network administrator must have a good understanding of services and protocols to be able to translate the organization's security requirements and needs into an accurate list of allow and deny rules or filters. In some cases, the task of configuring rules or filters may become so complicated that implementation is impossible. Lengthy access rules or filters can have a negative impact on network performance and be prone to error. As the number of rules or filters increases, so does the amount of time it takes the firewall to make comparison decisions and the chance that an inaccurate rule or filter will be added.

The accuracy of rules or filters on packet filtering firewalls can be very difficult to test. Even if the rules and filters seem simple and straightforward, verifying the correctness of a rule through testing can be a time-consuming process. Sometimes testing results can be misleading and inaccurate.

Packet filtering firewalls are prone to certain types of attacks. Since packet inspection goes no deeper than the packet header information, this method of packet screening is easier to circumvent and cannot protect against attacks directed at the application level. There are three common exploits to which packet filtering firewalls are susceptible. These are IP spoofing, buffer overruns, and ICMP tunneling. IP spoofing is sending your data and faking a source address that the firewall will trust. Buffer overruns typically occur when data sizes inside a buffer exceed what was allotted. ICMP tunneling allows a hacker to insert data into a legitimate ICMP packet.

Packet filtering firewalls do not perform user authentication. Again, this method of packet screening looks at information contained in the packet header and bases decisions on that information alone.

Back to Top

Stateful Packet Inspection

Stateful packet inspection uses the same fundamental packet screening technique that packet filtering does. In addition, it examines the packet header information from the network layer of the OSI model to the application layer to verify that the packet is part of a legitimate connection and the protocols are behaving as expected.

Figure 5. Stateful Packet Inspection OSI Layers

The stateful packet inspection process is accomplished in the following manner. As packets pass through the firewall, packet header information is examined and fed into a dynamic state table where it is stored. The packets are compared to pre-configured rules or filters and allow or deny decisions are made based on the results of the comparison. The data in the state table is then used to evaluate subsequent packets to verify that they are part of the same connection. In short, stateful packet inspection uses a two step process to determine whether or not packets will be allowed or denied. This method can make decisions based on one or more of the following:

• Source IP address
• Destination IP address
• Protocol type (TCP/UDP)
• Source port
• Destination port
• Connection state

The connection state is derived from information gathered in previous packets. It is an essential factor in making the decision for new communication attempts. Stateful packet inspection compares the packets against the rules or filters and then checks the dynamic state table to verify that the packets are part of a valid, established connection. By having the ability to "remember" the status of a connection, this method of packet screening is better equipped to guard against attacks than standard packet filtering.

Figure 6. Stateful Packet Inspection Firewall

Stateful packet inspection solutions offer sophisticated decision-making capabilities, yet they operate faster than other packet screening methods because they require little processing overhead. Allow and deny decisions are made at the lower levels of the OSI model.

Some newer stateful packet inspection firewalls maintain more advanced connection state information. Some are able to reassemble the packets as they pass through the firewall and perform additional processing such as content filtering.

Strengths

Stateful packet inspection firewalls, like packet filtering firewalls, have very little impact on network performance, can be implemented transparently and are application independent.

Stateful packet inspection firewalls are more secure than basic packet filtering firewalls. Because stateful packet inspection digs deeper into the packet header information to determine the connection state between endpoints, it is better equipped to guard against unwanted or unauthorized access.

Stateful packet inspection provides application layer protocol awareness. By looking deeper into the packet header information, this method of packet screening can verify that the application layer protocols are behaving as expected.

Stateful packet inspection firewalls usually have some logging capabilities. Logging can help identify and track the different types of traffic that pass though the firewall.

Weaknesses

Like packet filtering, stateful packet inspection does not break the client/server model and therefore allows a direct connection to be made between the two endpoints.

Rules and filters in this packet screening method can become complex, hard to manage, prone to error and difficult to test.

Regardless of the drawbacks, stateful packet inspection does have the advantage of providing a higher degree of security by monitoring connection state information.

Back to Top

Application Gateways/Proxies

An application gateway/proxy is considered by many to be the most complex packet screening method. This type of firewall is usually implemented on a secure host system configured with two network interfaces. The application gateway/proxy acts as an intermediary between the two endpoints. This packet screening method actually breaks the client/server model in that two connections are required: one from the source to the gateway/proxy and one from the gateway/proxy to the destination. Each endpoint can only communicate with the other by going through the gateway/proxy.

This type of firewall operates at the application level of the OSI model. For source and destination endpoints to be able to communicate with each other, a proxy service must be implemented for each application protocol. The gateways/proxies are carefully designed to be reliable and secure because they are the only connection point between the two networks. Typically, when a proxy is developed, the software is written to be as strict and secure as possible. Another strength of this method of packet screening is that the interfaces on the host system do not forward packets.

Figure 7. Application Gateway OSI Layer

An application gateway/proxy firewall operates in the following manner. When a client issues a request from the untrusted network, a connection is established with the application gateway/proxy. The proxy determines if the request is valid (by comparing it to any rules or filters) and then sends a new request on behalf of the client to the destination. By using this method, a direct connection is never made from the trusted network to the untrusted network and the request appears to have originated from the application gateway/proxy.

The request is answered in the same manner. The response is sent back to the application gateway/proxy, which determines if it is valid and then sends it on to the client. By breaking the client/server model, this type of firewall can effectively hide the trusted network from the untrusted network. It is important to note that the application gateway/proxy actually builds a new request, only copying known acceptable commands before sending it on to the destination.

Figure 8. Application Gateway Firewall

Unlike packet filtering and stateful packet inspection, an application gateway/proxy can see all aspects of the application layer so it can look for more specific pieces of information. It can, for instance, tell the difference between a piece of e-mail containing text and a piece of e-mail containing a graphic image, or the difference between a webpage using Java and a webpage without. From a security standpoint, the application gateway/proxy packet screening method is far superior to the other types of packet screening. However, this method isn't always the most practical to use.

Strengths

Application gateways/proxies do not allow a direct connection to be made between endpoints. They actually break the client/server model. In this respect, this method of packet screening truly keeps the internal and external networks separate.

Application gateways/proxies do not route between networks. This keeps the internal network separate from the external one. Since no routing is being done, this method of packet screening inherently provides a form of Network Address Translation or NAT.

Application gateways/proxies allow the network administrator to have more control over traffic passing through the firewall. They can permit or deny specific applications or specific features of an application. Many security experts believe that application gateways/proxies are more secure because of this granular control.

Application gateways/proxies typically have the best content filtering capabilities. Since they have the ability to examine the payload of the packet, they are capable of making decisions based on content.

Application gateways/proxies offer robust user authentication. In many cases, they can integrate with the host system's user database, which allows the administrator to utilize existing user/group information.

This type of packet screening also has extensive logging capabilities. It is capable of logging user activity and different types of traffic. This ability can provide a valuable resource when dealing with security incidents and policy implementation.

Weaknesses

The most significant weakness or disadvantage of application gateways/proxies is the impact they can have on performance. Since all incoming and outgoing traffic is inspected at the application level, they are typically slower than packet filtering and stateful packet inspection methods that look at traffic at the network layer. All traffic must pass through all seven layers of the OSI model prior to being inspected. As a result, the inspection process requires more processing power and has the potential to become a bottleneck for the network.

Another drawback of application gateways/proxies is that each protocol (HTTP, SMTP, etc.) requires its own gateway/proxy application. If one does not exist, then the corresponding protocol will not be allowed through the firewall. In addition, since each protocol requires its own gateway/proxy, support for new applications can become a problem.

Application gateways/proxies typically require additional client configuration. Clients on the network may require specialized software or configuration changes to be able to connect to the application gateway/proxy. This can have quite an impact on larger networks with numerous clients.

Scalability can be an issue with application gateways/proxies when they are installed in large networks. Performance typically degrades when the number of clients increases or the number of gateways/proxies located on any one host system increases.

Application gateways/proxies installed on general-purpose operating systems are vulnerable to the security loopholes of the underlying system. If the underlying system is not secure, the firewall is not secure.

This packet screening method is also more susceptible to distributed denial of service attacks. If enough data is forced on the application gateway/proxy, it can cease to operate.

In some instances, implementation costs can be prohibitive. The enhanced security of application gateways/proxies may require the purchase of additional hardware, software, expertise, or support, which in turn drives up the cost of the firewall solution.

Back to Top

Adaptive Proxies

Just as stateful packet inspection was developed as an enhanced form of packet filtering, adaptive proxies (also known as dynamic proxies) were developed as an enhanced form of application gateways/proxies. Combining the merits of both application gateways/proxies and packet filtering, adaptive proxies work by inspecting the first part of a connection at the application layer to make allow or deny decisions. Then subsequent packets are inspected at the network layer and allowed or denied at that layer. Like stateful packet inspection, adaptive proxies examine packets and then feed the information into dynamic state tables where the information is stored. The data in the table is then used to evaluate subsequent packets from the same connection. If packets are considered part of a new connection, they are passed back up to the application layer and inspected there. In this way, it is always the adaptive proxy, working at the application layer, that inspects and makes allow or deny decisions for each new connection. Only after the adaptive proxy on the application layer has approved the session, does it pass to the less secure but faster packet filter on the network layer.

Circuit-level Gateway

Unlike a packet filtering firewall, a circuit-level gateway does not examine individual packets. Instead, circuit-level gateways monitor TCP or UDP sessions. Once a session has been established, it leaves the port open to allow all other packets belonging to that session to pass. The port is closed when the session is terminated. In many respects this method of packet screening resembles application gateways/proxies and adaptive proxies, but circuit-level gateways operate at the transport layer (layer 4) of the OSI model.

Impostors

When discussing firewalls, packet screening methods, and how firewalls function, there are a few misconceptions that need to be addressed.

Network Address Translation (NAT)

One technology that is commonly thought to act as a firewall solution is Network Address Translation (NAT). NAT translates "internal" IP addresses on one network to "external" IP addresses on another network. There are three methods NAT uses to accomplish address translation.

• Static NAT - maps a specific single address to another specific single address.
  

  Example:
  10.0.0.1   -mapped to-   168.13.1.1

  
  

• Pooled NAT- dynamically maps all specific single addresses to a pool or range of external addresses.
  

  Example:
  10.0.0.1-10.0.0.254  -mapped to-  168.13.1.1-168.13.1.254

  
  

• Port Level NAT- dynamically maps all specific single internal addresses to a specific single external address. The internal address is mapped or identified by the specific external address in combination with a unique port number.

Example:
10.0.0.1  -mapped to-  168.13.1.1:1084
10.0.0.2  -mapped to-  168.13.1.1:1085
10.0.0.3  -mapped to-  168.13.1.1:1086

By comparing the way NAT functions between two networks, and the way packet screening methods function between two networks, you can see that NAT does not adhere to the firewall definition. NAT does not control access between the networks. Some may argue that NAT does control access because you cannot "see" the internal network. NAT does this not by using rules or filters, however, but through concealment. It hides the network from outside users.

Personal Firewalls

Another technology commonly called a "firewall" and marketed as something that will provide security for a network is the personal "firewall." A personal firewall provides protection to a single device (typically a personal computer) from an untrusted network (typically the Internet). Again, when compared to the firewall definition, personal firewalls do not meet the criteria. They do not control access between two networks; they control access to one specific device.

Important Aspects of Effective Firewalls

Regardless of which security design logic or packet screening method is chosen, two important aspects of the firewall's implementation can determine whether or not a firewall solution will be effective:

• First, the device or host system on which the firewall solution resides must be secure. If the system can be compromised, then the firewall can also be compromised. If the firewall you choose is based on a well-known network operating system, make sure the operating system is fully patched and all security updates have been applied.

• Second, for a firewall to be effective, all traffic to and from your network must pass through it. If a firewall can be physically or logically bypassed, there is no guarantee that your trusted network is safe. The architecture used for your firewall solution is very important.

Back to Top

Firewall Architecture

Since firewall solutions can be configured using a single system or multiple systems, the architecture used to implement the solution can be simple or complex. When deciding on a specific architecture, keep in mind that the most effective firewall solutions are implemented so all network traffic passes through them. This implementation characteristic is evident in the following commonly identified firewall architectures.

Packet Filtering Router

A packet filtering router is a router configured to screen packets between two networks. It routes traffic between the two networks and uses packet filtering rules to permit or deny traffic. Implementing security with a router is usually not that easy. Most routers were designed to route traffic, not to provide firewall functionality, so the command interface used for configuring rules and filters is neither simple nor intuitive.

Figure 9. Packet-filtering Router

Screened Host (Bastion Host)

The screened host, or bastion host, is typically located on the trusted network, protected from the untrusted network by a packet filtering router. All traffic coming in through the packet filtering router is directed to the screened host. Outbound traffic may or may not be directed to the screened host. This type of firewall is most often software based and runs on a general-purpose computer that is running a secure version of the operating system. Security is usually implemented at the application level.

Figure 10. Screened-host or Bastion-host Firewall

Dual-homed Gateway

A dual-homed gateway typically sits behind the gateway (usually a router) to the untrusted network and most often is a host system with two network interfaces. Traffic forwarding on this system is disabled, thereby forcing all traffic between the two networks to pass through some kind of application gateway or proxy. Only gateways or proxies for the services that are considered essential are installed on the system. This particular architecture will usually require user authentication before access to the gateway/proxy is allowed. Each proxy is independent of all other proxies on the host system.

Figure 11. Dual-homed Gateway

Screened Subnet or Demilitarized Zone (DMZ)

A screened subnet or DMZ is typically created between two packet filtering routers. When using this architecture, the firewall solution is housed on this screened subnet segment along with any other services available to the untrusted network. Conceptually, this architecture is similar to that of a screened host, except that an entire network rather than a single host is reachable from the outside.

Figure 12. Screened Subnet or Demilitarized Zone (DMZ)

Firewall Appliance

A firewall appliance typically sits behind the gateway (usually a router) to the untrusted network. This architecture resembles the packet filtering router and dual-homed Gateway architectures in that all traffic must pass through the appliance. In most instances these appliances come pre-configured on their own box. They may also have other services built in, such as Web servers and e-mail servers. Because they usually don't need the extensive configuration that other firewalls often require, they are touted as being much simpler and faster to use. Some manufacturers market them as "plug-and-play" firewall solutions.

Figure 13. Firewall Appliance

For some networks, implementing more than one firewall solution may be a more effective option. For example, implement a packet filtering router at the entrance to the network for perimeter security and then configure an application gateway for a specific department or building. This type of solution would not only protect the trusted network from the outside, but would also protect a specific department or building from unauthorized users on the trusted network.

Back to Top

Selecting and Implementing a Firewall Solution

In order to pick the best architecture and packet screening method for a firewall solution, the following questions should be considered:

• What does the firewall need to do?
• What additional services would be desirable?
• How will it fit in the existing network?
• How will it effect existing services and users?

Do you need a firewall?

The decision to implement a firewall solution should not be made without doing some research and analysis. The decision to implement a firewall solution should be based on requirements that have been identified and documented, not because implementation of a firewall has been identified as a solution at other organizations. Firewall implementations based on little or no thought can create more security holes and cause more network problems than no firewall implementation at all.

What does the firewall need to control or protect?

In order to make a sound decision, first identify what functions the firewall would need to perform. Will it control access to and from the network, or will it protect services and users?

What would the firewall control?

• Access into the network
• Access out of the network
• Access between internal networks, departments, or buildings
• Access for specific groups, users or addresses
• Access to specific resources or services

What would it need to protect?

• Specific machines or networks
• Specific services
• Information - private or public
• Users

After identifying what the firewall needs to control or protect, determine what might happen without this control and protection. What would happen if users had access to things they shouldn't? What would happen if the unprotected services or information were compromised? Is the risk of not having control or protection great enough to warrant taking the next step in the assessing the need for a firewall solution?

What impact will a firewall have on your organization, network and users?

• What resources will be required to implement and maintain a firewall solution?

• Who will do the work? Are experienced technical personnel available for the job or will someone need to be hired from outside your organization?

• Is hardware available that meets the requirements to support a firewall solution?

• Will existing services be able to function through a firewall?

• What will the financial impact be on the organization? (Financial impact should include initial implementation costs, ongoing maintenance and upgrades, hardware and software costs, and technical support costs, whether the support is provided in-house or from an outside source.)

Examining what the firewall needs to do, how it will fit in the existing network, and how it will effect existing services and users, should help the organization make an informed decision on whether or not a firewall is needed. The next step in the selection process is to review or develop the organization's security policy.

Back to Top

Security Policy

The success of any firewall solution's implementation is directly related to the existence of a well-thought-out and consistently-implemented security policy. Without a security policy, there are no requirements to use as a guideline on which to base a selection decision. A security policy states, at a high level, what security measures an organization wants to put into practice. These security measures are developed independently from any technical solution that will be used to enforce them. By keeping the security policy and technical solution separate, the policy will not be limited by the capabilities of the hardware or software or any specific firewall solution. The choice of the technology used in the firewall solution should reflect the security policy not the other way around.

The development of a security policy requires input from all levels of an organization. Executive staff, management staff, technical staff, internal users and external customers will all have an interest in the firewall solution and the effects it will have on them. Obtaining input and support from all parties during the development of the security policy will make the firewall selection process smoother and there will be less confusion and resistance during implementation. Having a security policy that has been approved and is supported by management will allow the firewall administrator to justify the firewall's rules and filters when users complain that access to services have been denied or changed. The involvement of all levels will also provide a more streamlined process for future decisions, when they become necessary.

Security policies typically have an administrative section and a technical section. The administrative section addresses issues such as whether remote access will be allowed, will all users have access to e-mail services, and who will be responsible for changes and updates. The technical section addresses issues such as whether access will be controlled by user ID, groups of users, or IP addresses; will activity be tracked by user IDs or by IP addresses, will all traffic to and from the network be controlled or just Web traffic. Many of the things addressed in the technical section form the foundation upon which a firewall solution's rules and filters are built.

Some of the topics a security policy may address are:

Administrative Issues

• User access - Which users will be allowed access to and from the network?

• Access to services - Which services will be allowed in and out of the network?

• Access to resources - Which resources will be available to users?

• User authentication - Will the organization require user authentication?

• Logging and auditing - Will the organization want to keep log and audit files. What will be logged? If the organization intends to take action on policy violations, then it is important to gather the appropriate data for evidence. If it never plans take action, an elaborate logging mechanism adds unnecessary cost and complexity?

• Policy violation consequences - What will be the consequences of policy violation? Who will be responsible for overseeing the implementation of the consequences?

• Exceptions - How will exceptions to the security policy be handled?

• Responsibilities - Who will oversee and administer the security policy? Who has final authority on decisions?

• Technical responsibilities - Who will oversee and administer the technical implementation - firewall, etc.

Technical Issues

• Remote access - Will the organization allow remote access to the network?

• Physical security - How will physical security of machines, one of the most obvious security elements that is often overlooked, be achieve?

• Implementation methods - What methods will be used to implement the security policy, i.e. firewall, acceptable use policy, etc.?

• Virus protection - How will the organization handle virus protection?

It is important to spend time creating a comprehensive security policy, since this is the document on which many of the technical requirements for firewall selection are based.

Back to Top

Implementation Requirements

Technical Requirements

A firewall solution's technical requirements should reflect the organization's security policy and network infrastructure. First, the firewall's capabilities should match the specific security requirements listed in the security policy. By properly identifying security requirements, it is easy to narrow down the field of potential products. Selecting a firewall is actually making a decision on what technology to use to implement the organization's security policy. Therefore, the entire firewall solution should be able to support all aspects of the security policy. A poor understanding of a security policy's requirements can lead to the implementation of a complicated technical solution when a simple solution would have done the job.

Architecture

In order for an organization to make an informed decision on which firewall functions and architecture to use, it needs to determine how a firewall will fit into its environment. Current network architecture must be reviewed to determine what firewall solutions and architectures it will support.

The network topology needs to be analyzed to determine whether or not specific components of each firewall solution are suitable. A site may have a topology that does not lend itself to a specific firewall solution, or the site may use services that would require a major restructuring or a complete change of the network itself. The organization needs to determine what firewall functions and architecture are most appropriate in its environment.

A helpful and necessary step during the process is to create or update network documentation. A good network diagram will help avoid mistakes and make the firewall selection and implementation processes much easier. Diagrams of the following configurations are highly beneficial.

• Current physical configuration
• Current logical configuration
• Proposed firewall solution physical configuration
• Proposed firewall solution logical configuration

Having good documentation will reduce the risk of making mistakes in the selection process, especially if the existing network is very complex. (See the paper Documenting Your Network for further information about creating network documentation.)

Making the Decision

Once the organization establishes a security policy that essentially outlines its security requirements and creates a network diagram to help determine the best architecture and system requirements, it should have a clear indication of which firewall solutions best meet its needs. Some additional things to consider when selecting a firewall solution are:

• Ease of installation - This can have a big impact depending on who is doing the installation
• Ease of configuration - How hard are the rules and filters to configure? Is there an intuitive GUI interface or is configuration performed from the command line?
• Training - Will the firewall administrator require additional training? Who will provide it?
• Scalability - Is the firewall solution scalable?
• Flexibility - Firewall solutions that are hardware-based can be easier to install, but software solutions provide more flexibility.
• Firewall Support - Who will support the firewall solution? An effective firewall requires constant administration and management and those who administer or manage it need to be competent and efficient. Having highly trained administrators, whether internal or external, is crucial. Firewall administration is a critical job and should be afforded the required amount of time and expertise.
• Platform - System security isn't easy, so choose a firewall that works on a platform with which administrators are familiar. Is central management important?

Remember, the ability to make an informed decision requires an understanding of how a firewall works and what capabilities it has. No matter which product is selected, it will not solve all of the organization's security problems on its own. Selection focus should be on the security elements of the product, not its bells and whistles. A complex solution is not always the best solution.

Implementation and Testing

Many people say that a firewall is only as good as its implementation. In other words, if a firewall is not implemented correctly, it may be ineffective.

In complex network environments it can be easy to make mistakes during the implementation process. There are many crucial components associated with a firewall's implementation. Each of these components must be identified, configured, and tested. The one component that has the most impact on the network and on the firewall's ability to provide the appropriate access control is the configuration of the rules and filters.

The ideal implementation plan would be to install the firewall solution in a test environment, test the rules and filters and then implement the solution in the production environment. In many situations this is just not possible. Many organizations configure rules and filters and implement them without testing them. Regardless of whether a test environment is available, time should be taken to test the rules and make sure they are allowing and denying access in the appropriate ways.

Test, test, test!

• Use available programs to scan ports on the firewall from both the internal trusted network and the external untrusted network.
• Are rules and filters controlling access as expected? Is the firewall passing the traffic that should be allowed and blocking the traffic that should be denied?
• Test from every network segment.
• If authentication has been implemented, test it.
• Check logging capabilities. Ensure the firewall is tracking the things that were specified.
• Run each test more than once.

This process can be time consuming but it can also identify problems before they become threats.

Back to Top

Conclusion

Like all other technologies, firewall technologies continue to change and grow. The differences between packet screening methods are becoming more blurred as vendors move to integrate the best features of each method into single products. Just remember, there is no "one-size-fits-all" solution.

When choosing and implementing a firewall solution, do the homework and make a decision based on the organization's needs, security policy, technical analysis, and financial resources. Solutions available today utilize different types of equipment, network configurations, and software. The capabilities of each solution vary. It takes time to research each solution thoroughly, but that time can mean the difference between success and failure. Firewall solutions can be very complex. It is crucial to base the decision on a thorough understanding of the benefits and drawbacks of each solution for the specific organization that will be implementing it.

Resources

ICSA Firewall Buyer's Guide.
http://www.icsalabs.com/html/communities/firewalls/index.shtml

Internet Firewalls: Frequently Asked Questions.
http://www.interhack.net/pubs/fwfaq/

Internet Firewalls - Resources.
http://www.cerias.purdue.edu/coast/firewalls/fw-body.html

Firewall Product Overview.
http://www.thegild.com/firewall/

Packet Filtering for Firewall Systems. CERT Coordination Center. Carnegie Mellon University. February 12, 1999.
http://www.cert.org/tech_tips/packet_filtering.html

Dan Strom. The Packet Filter: A Basic Network Security Tool. September 25, 2000.
http://www.sans.org/infosecFAQ/firewall/packet_filter.htm

Maximum Internet Security: A Hacker's Guide. Sams Publishing. June 25, 1997.

Marcus J. Ranum. Thinking About Firewalls. Trusted Information Systems, Inc. 1993.
http://www.vtcif.telstra.com.au/pub/docs/security/ThinkingFirewalls/
ThinkingFirewalls.html

Firewall Buyer's Guide and FAQ.
https://www.securehq.com/shqbuyersguide.wml
&sessionid=200132811363510950&storeid=1&id=8

Firewall Buyer's Guide. Network World Fusion. July 19, 1999.
http://www2.nwfusion.com/bg/firewalls/firewalls.jsp

Design the Firewall System. CERT Coordination Center. Carnegie Mellon University. July 1, 1999.
http://www.cert.org/security-improvement/practices/p053.html

Firewalls for Beginners.
http://secinf.net/info/fw/firewalls_for_beginners_by_Matt.htm (No longer available)

Keith D. Maxon. Application Layer Firewalls vs. Network Layer Firewalls: Which Is the Better Choice? October 16, 2002
http://secinf.net/info/fw/firewall.htm

The Firewall Hardening Guide.
http://secinf.net/firewalls_and_VPN/The_Firewall_Hardening_Guide/

Back to Top