Network Firewalls

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. Network Layers The layered concept of networking was developed to accommodate changes in technology. Each layer of a specific network model may be responsible for a different function of the network. Each layer will pass information up and down to the next subsequent layer as data is processed. The OSI Network Model Standard The OSI network model layers are arranged here from the lower levels starting with the physical (hardware) to the higher levels. Physical Layer - The actual hardware. Data Link Layer - Data transfer method (802x ethernet). Puts data in frames and ensures error free transmission. Also controls the timing of the network transmission. Adds frame type, address, and error control information. IEEE divided this layer into the two following sublayers. Logical Link control (LLC) - Maintains the Link between two computers by establishing Service Access Points (SAPs) which are a series of interface points. IEEE 802.2. Media Access Control (MAC) - Used to coordinate the sending of data between computers. The 802.3, 4, 5, and 12 standards apply to this layer. If you hear someone talking about the MAC address of a network card, they are referring to the hardware address of the card. Network Layer - IP network protocol. Routes messages using the best path available. Transport Layer - TCP, UDP. Ensures properly sequenced and error free transmission. Session Layer - The user's interface to the network. Determines when the session is begun or opened, how long it is used, and when it is closed. Controls the transmission of data during the session. Supports security and name lookup enabling computers to locate each other. Presentation Layer - ASCII or EBCDEC data syntax. Makes the type of data transparent to the layers around it. Used to translate date to computer specific format such as byte ordering. It may include compression. It prepares the data, either for the network or the application depending on the direction it is going. Application Layer - Provides services software applications need. Provides the ability for user applications to interact with the network. Many protocol stacks overlap the borders of the seven layer model by operating at multiple layers of the model. File Transport Protocol (FTP) and telnet both work at the application, presentation, and the session layers. The Internet, TCP/IP, DOD Model This model is sometimes called the DOD model since it was designed for the department of defense It is also called the TCP/IP four layer protocol, or the internet protocol. It has the following layers: Link - Device driver and interface card which maps to the data link and physical layer of the OSI model. Network - Corresponds to the network layer of the OSI model and includes the IP, ICMP, and IGMP protocols. Transport - Corresponds to the transport layer and includes the TCP and UDP protocols. Application - Corresponds to the OSI Session, Presentation and Application layers and includes FTP, Telnet, ping, Rlogin, rsh, TFTP, SMTP, SNMP, DNS, your program, etc. Please note the four layer TCP/IP protocol. Each layer has a set of data that it generates. The Link layer corresponds to the hardware, including the device driver and interface card. The link layer has data packets associated with it depending on the type of network being used such as ARCnet, Token ring or ethernet. In our case, we will be talking about ethernet. The network layer manages the movement of packets around the network and includes IP, ICMP, and IGMP. It is responsible for making sure that packages reach their destinations, and if they don't, reporting errors. The transport layer is the mechanism used for two computers to exchange data with regards to software. The two types of protocols that are the transport mechanisms are TCP and UDP. There are also other types of protocols for systems other than TCP/IP but we will talk about TCP and UDP in this document. The application layer refers to networking protocols that are used to support various services such as FTP, Telnet, BOOTP, etc. Note here to avoid confusion, that the application layer is generally referring to protocols such as FTP, telnet, ping, and other programs designed for specific purposes which are governed by a specific set of protocols defined with RFC's (request for comments). However a program that you may write can define its own data structure to send between your client and server program so long as the program you run on both the client and server machine understand your protocol. For example when your program opens a socket to another machine, it is using TCP protocol, but the data you send depends on how you structure it. Data Encapsulation, a Critical concept to be understood When starting with protocols that work at the upper layers of the network models, each set of data is wrapped inside the next lower layer protocol, similar to wrapping letters inside an envelope. The application creates the data, then the transport layer wraps that data inside its format, then the network layer wraps the data, and finally the link (ethernet) layer encapsulates the data and transmits it. Each network layer either encapsulates the data stream with additional information, or manages data handling or come part of the connection. Without going into a great deal of technical detail, I will describe a general example of how these layers work in real life. Assuming that the protocol stack being used is TCP/IP and the user is going to use an FTP client program to get or send files from/to a FTP server the following will essentially happen: The user will start the FTP client program on the sending computer. The user will select the address (If the user selected a name, a description of DNS would need to be described complicating this scenario) and port of the server. The user will indicate to the FTP client program that they want to connect to the server. The application layer will send information through the presentation layer to the session layer telling it to open a connection to the other computer at a specific address and port. The presentation layer will not do much at this time, and the presentation layer is actually handled by the FTP program. The session layer will negociate through to the FTP server for a connection. There are several synchronization signals sent between the client and server computers just to establish the connection. This is a description of the sending of a signal from the client to the server: The session layer of the client will send a data packet (SYN) signal to the transport layer. The transport layer will add a header (TCP header) to the packet indicating what the source port is and what the destination port is. There are also some other flags and information that will not be discussed here to minimize complexity of this explanation. The network layer will add source IP address and destination IP address along with other information in a IP header. The datalink layer will determine (using ARP and routing information which is not discussed here for brevity) the hardware address of the computer the data is being sent to. An additional header (ethernet) will be added at this layer which indicates the hardware address to receive the message along with other information. The information will be transmitted across the physical wire (hardware layer) until the signal reaches the network card of the server computer. The signal may go through several hubs or repeaters. The FTP server will normally only look for ethernet frames that are matching its own hardware address. The FTP server will see the ethernet frame matching its address and strip the ethernet header information and send it to the network layer. The network layer will examine the IP address information, strip the IP header, and if the IP address matches its own, will send the information to the transport layer. The transport layer will look at the TCP port number and based on the port number and services being run, will strip the TCP header and send the information to the appropriate program which is servicing the requested port. At this point, the session layer in the FTP program will conduct a series of data exchanges between itself through all the lower layers to the client computer until a session is established. At this point information may be sent through several FTP commands between the client and the server. Every transmission passes through the network layers from the application layer down to the hardware layer and back up the layers on the receiving computer. When the client decides to terminate the session layer will be informed by the higher layers and will negociate for the closing of the connection.