The first section of this document gives a brief overview of what a firewall, and what components go into creating one. The second section provides some insight into the most common firewall architectures, along with the pros and cons of each. The third section describes one company's firewall configuration and discusses the rationale for the configuration. The last section compares two of the leading firewall products: CheckPoint's FireWall-1 and Trusted Information System's Gauntlet.
A firewall is a combination of a network policy and a firewall system. The network policy defines what services and access is permitted between a trusted internal network and an untrusted external network. The firewall system is a collection of hardware and software used to implement the security access policy.
The primary reason to set up a firewall is to enforce a network access policy. A firewall can simplify the task of protecting your site from unwanted intrusions. Without a firewall, each system that is attached to the internet has to be made secure, and must provide a uniform level of security so that one machine cannot compromise another. As the internal network gets larger, this becomes harder to do.
A firewall not only reduces the risks to the internal network, it can provide enhanced privacy to not allowing services such as finger and the Domain Name Service. In addition, a firewall can be used log access to and from the internal network, and to keep statistics about network usage.
A firewall system can not solve all Internet security issues. For example, it does not provide protection from insider attacks. It is also not very useful to set up a firewall if you users will set up unrestricted modems on internal machines.
Another reason you may not set up a firewall is because it blocks services that you want your users to have access to. For example, sites that need to use NFS and NIS across major gateways may find it costly, if not impossible, to set up a firewall that supports this. In such cases, the need for security must be weighed against the benefits to the users.
The main components of a firewall are a network policy and some combinations of packet filtering and proxy services. [WACK, CARNAHAN] argue that another component is some sort of advanced authentication measures, such as smart cards, and authentication tokens.
A network policy defines what types of services will be allowed or denied. Ideally, it is specified before the firewall system is set up.
IP packet filtering is performed at the network level use a screening router. The router parses the network packet headers for the following information
to filter which packets are allowed into or out of your internal network.
The router uses this information, plus a rules table set up by a system administrator to determine whether to allow or deny the packet. The rules table contains a list of conditions and actions that are applied in a particular order until a match is found. When a packet meets all of the conditions for a particular entry, the action for that entry is applied to the packet. The action may be to allow the packet through, or to drop it.
One of the main advantages of packet filtering is that it is transparent. Users do not need to be aware that packet filtering exists unless they try to use a service that is not allowed. There is no need for specialized application software.
Packet filtering is also fast, and generally inexpensive. Most organizations already have routers.
One of the main disadvantages is of packet filtering that it is more limited in the types of access control that it provides. Routers can only filter based on host addresses, and type of service. They do not have the ability to filter service based on user, or on the type of operation being performed. For example, you may want to allow users on the external network to use FTP to get files from your site, but be able to put files. Packet filtering does not provide a mechanism to do this. It can also be difficult to set up a rules table that is correct, and that accurately reflects your security model.
Packet filtering is typically easier to bypass. [CHAPMAN92] goes into great detail about the various ways in which packet filtering can be insecure.
There are little or no logging capabilities, so it difficult to determine when a screening router has been compromised or is under attack.
Dynamic packet filtering attempts address many of the weaknesses of static packet filtering. With dynamic packet filtering, the router looks inside the network packet to find higher-level protocol information. It uses this information to determine whether a packet is expected based on previous communication. For example, a dynamic packet filter may set up simulated connections for connectionless protocols such as NFS and RPC.
A proxy service is an application that forwards and filters connections to a specific service, such as Telnet and FTP, based on your sites security policy. The host that a proxy service runs on is referred to as an application gateway (or proxy gateway).
Proxy services allow only those services through for which there is a proxy. In addition, proxy servers can proved additional features such as user authentication, enhanced logging, and protocol specific filtering. For example, the proxy server can be configured to allow FTP get commands from the internal network, but deny FTP put commands to the internal network.
Proxy servers also hide the names of internal systems. The internal systems think they are talking to the external network, while the external network thinks it is talking to the application gateway.
There are two main disadvantages to using proxy servers. The first is performance. They must set up two separate connections between the internal and external networks, and there is also some extra processing that must be done.
The second disadvantage is that a new protocol cannot be provided until a proxy server is written. And in some cases, a modified clients are needed to talk to the proxy server.
There are four common combinations of screening routers and application gateways used when creating a firewall system:
A packet filtering architecture typically consists of a single screening router that is placed between the internal and external network (see figure 1).
This type of firewall might be appropriate for sites that have a wide variety of systems for which it would be difficult to obtain modified application software for all the system types.
A dual-homed host architecture consists of a host that is connected to two network interface - the trusted internal network and the untrusted external network. The host's IP forwarding is disabled so that packets cannot be directly routed between the networks. A dual-homed host provides services only by proxying them. The application gateway in figure 2 is an example of a dual-homed host.
A screened host architecture provides services from a host that is attached to only the internal network. A separate router connects the screened host to the external network. The primary security is provided by packet filtering.
The router services for which a proxy exists to the application gateway. Other trusted traffic is allowed to go directly through to the site systems.
The screened host architecture is more flexible than dual-homed host architecture. It can be used to allow trusted services for which there are no proxies.
The firewall is less secure. There are now two systems which much be configured correctly. And, it is easier for the users to bypass the screened host, possibly violating your security policy. Also, if an attacker breaks into either the router or the screened host, they have complete access to the rest of the site systems.
The screened subnet architecture adds an extra level of security by creating a screened subnet (also referred to as a perimeter network or a "DMZ") between the internal and external networks. There may be one or more application gateways on the screened subnet. The exterior router restricts Internet access to specific systems on the screened subnet. The inner router passes traffic to and from the internal systems to one of the hosts on the screened subnet. Thus, no site system is directly reachable from an external system and vice-versa.
Each component of the firewall be set up to handle a specific protocol, which can increase throughput.
It is more difficult for an attacker to get access to information on the internal network. If an attacker manages to get through the external router, they are limited in how much information they have access to on the screened subnet.
The firewall can be made to pass "trusted" services around the application gateway(s), thereby subverting policy. And more emphasis is placed on the routers, which can be difficult to configure correctly.
A software company based in Seattle agreed to outline their security and firewall implementation for this study, with the condition of anonymity. For the purpose of this paper, they will be referred to as Really Cool Software (RCS).
In order to understand the implementation that RCS chose for it's network security, a little background on the company is in order. RCS is a company of approximately 650 employees whose headquarters is split between two buildings in Seattle, WA. The company has branch offices in Europe and Asia and works closely with vendors and customers throughout the world.
RCS produces software that is focused on the networking market, primarily in the area of connecting host computers (everything from NT servers and AS/400's) to desktop computers (any flavor of Microsoft Windows or Macintosh). One of the company's distinguishing features is its focus on technical support for its customers; this task employs approximately 25% of the employees and has had a significant impact on the chosen network implementation.
The company culture of RCS is one of openness and empowerment - all employees are assumed and expected to be able to take initiative and creativity to find good solutions for their customers. While that may be a great goal for a company, as we will see, it can make configuring a secure network quite a challenge.
Approximately three years ago, the IS department in RCS was faced with the reality of a serious lack of security on their internal networks. The company was doubling both in revenue and employees every year, and the corporate culture did not encourage them to set up "walls" that appeared to keep people from doing their jobs.
The IS group set out to define the problems and challenges that they needed to solve to protect the company's networks while still providing customers and vendors ready access to the information they needed. The following are some of the issues and design goals that were raised during the evaluation:
As a growing software company, RCS attends approximately 150 trade shows per year. Since RCS has products that involve logging into large computers, a demo at a trade show would always include a remote login back to a host Seattle. (The alternative of bringing the hosts to the trade shows was not reasonable given the monetary cost.) As the IS manager said, "a trade show is about the most insecured place you can be and we were allowing access to our internal networks from trade show floors!"
RCS also had the same issue with customer site visits. In order to do a product demonstration at a customer site, they often have to remotely log into RCS host computers.
Similarly, the development teams need a way to test software through firewalls. That is, they need to make sure that direct internet connections (i.e., between computers not behind a firewall) and connections through a variety of firewalls would work correctly.
Any other approach violates a basic tenet of the corporate culture.
A significant number of employees, both in sales and technical support,
travel extensively. While off-site, these employees need access to
e-mail and other services (e.g., FTP or internal Web pages) on the
internal networks.
RCS provides extensive customer, vendor and distributor training at its
headquarters. Computers used during external training courses should
not have access to the internal network. However, those same computers
needed access to the internal networks at other times.
This was deemed to be primarily a cost consideration. However, it was
clearly a security issue as well.
Product demonstrations at trade shows, customer support, and development teams located throughout the world all combine to make performance one of the primary criterion upon which their security solution would be built.
Faced with all of these challenges, the IS department decided upon a rather common approach to a firewall and overall network security policy with a few creative solutions to the company's unique problems.
In each of the Seattle buildings, there is a fully redundant collapsed backbone Ethernet network, connected between the buildings by a fiber channel (100BaseFX). The central router for the company is housed in one of these buildings.
Conceptually, this router has three exit points:
In front of the firewall, is a DMZ network with the FTP and Web servers available for distributing public information and communicating with customers and vendors. The DMZ network is protected by a Cisco router that does basic packet filtering on incoming network traffic, ensuring that all appropriate traffic is being directed to either one of the servers or the firewall. Traffic that is not appropriate (e.g., telnet to the Web server) is discarded. In front of this router is what is called the "Free Net".
The "Free Net" is a collection of completely unprotected host computers (including HP, IBM and DEC mainframes, NT server and Novell servers) that are used primarily for trade show and customer demonstrations and support. Occasionally, these systems are also use for product testing and development. (This is a little bit of a risk, but was deemed to be acceptable given the rarity of this work.) In front of the FreeNet there is a POP router that is provided by RCS's ISP for troubleshooting and support that actually connects to the Internet.
The firewall product selected by RCS was CheckPoint Software's FireWall-1, running on a Sun workstation. It was selected for many reasons, but the primary reason was performance. From the testing done during evaluation of firewall products, as well as a review of published reports, FireWall-1 was found to be the fastest firewall on the market at the time. In addition, the IS department liked the manageability of the software both because of a good user interface, as well as the fact that FireWall-1 does an excellent job of managing a centralized network like RCS. The Sun platform was chosen for the firewall for two simple reasons: although there was a Windows NT version of the software available at the time, the platform's performance and manageability were deemed to be unsatisfactory, and most of the IS personnel had Unix backgrounds, thus making a Unix network easier for them to manage.
As has already been discussed, a firewall is really an implementation of an overall security policy. Because of the culture of openness and trust at RCS, all network traffic is allowed to pass out of the internal network. There is no auditing or screening of out-bound traffic. Inbound traffic is understandably much more restrictive, with only FTP and Web traffic allowed to pass through to the internal network. There is a significant amount of logging and auditing of inbound traffic.
One of the most common problems with firewall implementations is the tendency of employees to circumvent that security using dial-up lines from desktop computers. RCS is no exception, and because several of their products involve developing network support for dial-up connections, it is common to have dial-up connections into offices. In an effort to manage this issue, the IS department keeps a list of external dial-up connections and attempts to use employee education to ensure security. When possible, "dial-out only" lines are used. This is a difficult issue for RCS, as the appearance of someone keeping track of an employee's dialup connections can be perceived as contrary to the culture of employee empowerment.
With this security arrangement in place, the network administrator estimates that the RCS firewall registers an average of 2-3 "attacks" per day. Most of these, however, are benign, with approximately 2 -3 per month being antagonistic. Only once has the network been severely victimized and this was actually as a backlash from a storm that was sent to an MCI server in an attempt to bring it down. One of RCS's addresses was used as the spoof address and the backlash from the MCI server flooded the RCS server.
There are four areas in this network plan where RCS is currently researching a future direction: remote access to mail, virtual private networks, product distribution via the World Wide Web, and firewall redundancy.
The current process of having employees that are traveling access their mail via a modem pool is adequate but not ideal. It is possible that a mail proxy will be used to allow a more direct access to the mail server.
Another technology being considered is support for virtual private networks. As RCS does a significant amount of on-line work with customers and vendors, the need for encrypted conversations between firewalls is becoming obvious.
As a software firm, RCS is considering ways to provide product distribution via the Web. Because this can result in a significant spike in the usage pattern on the web server - this, after all, is what caused Microsoft's web server(s) to grind to a halt when Windows '95 was released - RCS is considering outsourcing all software distribution. As the IS manager at RCS said, "Sometimes the most cost-effective solution to a problem is to let someone else deal with it."
Currently the firewall is a single point of failure in RCS's system. They are purchasing a system that will act as a backup if the firewall fails or is compromised.
The following section compares the general strengths and weaknesses of Trusted Information System's Gauntlet product to CheckPoint's FireWall-1 product. A detailed comparison is provided at the end of this document.
The Gauntlet product relies on proxies to provide services. The CheckPoint product uses stateful inspection. For a detailed technical discussion of the advantages and disadvantages of proxies and stateful inspection, see this CNS mail thread.
In general, the tradeoffs between the two products boils down to balancing ease of use and security. According to [DATACOM97], both products are very secure. As for ease use, some of that depends on the systems you are familiar with.
[FORBES96] and some mail groups mentioned that one of the issues that differs between the products is that you can get Gauntlet from the same vendor you get your hardware (e.g., SGI). Some saw that as positive (i.e., SGI then is responsible for the entire system and maintanence and holes would theoretically be less likely). Others saw this as a negative with the rationale that having a vendor supply a firewall to protect against (possible) bugs in its own system is not a wise choice.
The two main strengths of the Gauntlet product are the fact that it provides transparent proxies, and it supports IP-level encryption.
Gauntlet provides a separate proxy server for each application, rather than a single proxy server for all applications, so the applications themselves do not need to be modified. This makes the proxies transparent to the users of the internal network.
Gauntlet also provides IP-level encryption, which can be used to build Virtual Network Perimeters (also known as Virtual Private Networks). All trafiic between the networks forming a VPN must be routed through the firewalls, which encapsulate and trasmit the traffic encrypted using DES.
This features is particularly useful for companies with branches around the world that must rely on sending traffic over untrusted networks between locations.
FireWall-1 uses the relatively new dynamic filtering technology. This technology, also known as Stateful Inspection, has been patented by CheckPoint, Inc. (for details about the patent, see their press release).
FireWall-1 provides application-level filtering at the network level by adding a layer called an Inspection Module between the Data Link and Network layers. This has the advantage of being faster than a true application layer proxy. It also allows FireWall-1 to handle services such as UDP and RPC, which proxies cannot deal with.
As the Internet becomes more a part of business, firewalls are becoming an important ingredient of an overall network security policy. We have seen that there are several approaches to integrating a firewall into a network topology. We've also found that there are many possible criteria upon which decisions are made regarding whether to implement a firewall, and if so, which one. Generally, performance, feature set (that is, does this product provide security in the ways that is most needed) and how well the product fits into the current network infrastructure are the most important issues. The firewall market is still relatively young and there are an abundance of choices (approximately 40 vendors currently offer products), so it is expected that as the market matures, the products that are successful are those that excel in these areas.
The following table compares the features of CheckPoints FireWall-1 product and Trusted Information System's Gauntlet product in detail.
| Vendor | CheckPoint Software | Trusted Information Systems, Inc | |
| Product & Vendor Information | |||
| Product | FireWall-1 | Gauntlet | |
| Architecture | Stateful inspection | Application level proxy | |
| System/OS supported | HP-UX, Solaris, SunOS, Win95, NT 3.51, NT 4.0 | BSD/OS v2.1, HP Unix, Solaris, SunOS, Windows NT 4.0, Irix | |
| Price for 25/100/1000 users | $2995, $7997, $18,990 | $11,900 (s/w only);$16,500 (w/ h/w) | |
| Disk space required | 26 MB | 512 MB | |
| Memory required | 64 MB | 16-32 MB | |
| Consulting services | ? | yes | |
| Management, Logging & Auditing | |||
| Audit Capabilities | yes | yes | |
| Session accounting (eg min/session) | yes | yes | |
| Log filters | Service, time, source, destination | Service, time, source, destination | |
| * log non-filtered packets | no (n/a -- all packets are filtered) | yes | |
| * log violations | yes | yes | |
| * log/view live connections | yes | ||
| Alarm functions | yes | yes | |
| Notification | paging, email, SNMP traps | paging, email | |
| Syncronization & high availability | yes | ||
| Load balancing between firewalls | yes - server load, round trip, round robin, random, domain | ||
| Real-time monitoring | yes | ||
| Remote auto logging | yes | ||
| Usability | |||
| GUI tools | yes | yes | |
| Application transparency | yes | yes | |
| Scalable | yes | yes | |
| Automatic integrity check | no | yes | |
| Encryption | |||
| Virtual encrypted networks | yes | yes | |
| Encryption & authentication | MD5 | MD5, SHTTP, SLL, Cryptocard, Enigma Logic, Safeword, Smartgate, DES, triple DES | |
| Encryption schemes available | DES RC4, SKIP, Manual IPSec, more | DES | |
| Firewall-to-firewall encryption | yes | yes | |
| Timer based management | |||
| Timed sessions on port | yes | yes | |
| Timed security policies | yes | yes | |
| Time based user access | yes | yes | |
| Secure ID | yes | yes | |
| Authentication | |||
| User Authentication | yes - S/Key, SecurID, OSPasswd, RADIUS, AssureNet | yes - SecureID | |
| Client Authentication | all apps, once per IP address, non-transparent | ||
| Session Authentication | all apps, once per session, non-transparent | ||
| Network Interfaces | |||
| Max interfaces | depends only on hardware | depends only on hardware | |
| Supported interfaces | Ethernet, FDDI, ATM, fast Ethernet, AnyLAN, serial up to T1/E1, T3/E3 | Ethernet, FDDI, ATM, fast Enet, serial up to T1/E1, T3/E3 | |
| Application & Protocols Filtered | |||
| Java screening | yes | yes | |
| Active X screening | no | yes | |
| telnet | partial (no content filtering) | yes | |
| ftp | yes | yes | |
| http (www) | yes | yes | |
| Gopher | partial | yes | |
| WAIS | partial | yes | |
| SMTP | yes | yes | |
| NNTP | partial | yes | |
| X11 | partial | yes | |
| Berkeley r-services (rlogin, rsh…) | yes | yes | |
| Sun RPC services (NIS, NFS, …) | yes | no | |
| RealAudio | yes | yes | |
| UDP Support | yes | no | |
| TCP/IP filtered | yes | yes | |
| ICMP - Ping | yes | no | |
| RPC | yes | no | |
| DNS | yes | yes | |
| Finger | yes | yes | |
| NFS | yes | no | |
| NNTP | yes | yes | |
| NTP | yes | yes | |
| Pointcast | yes | yes | |
| POP | yes | yes | |
| Quicktime | yes | no | |
| SHTTP | yes | yes | |
| SSL (Secure sockets layer) | yes | yes | |
| TFTP (trivial FTP) | yes | no | |
| TN3270 | yes | yes | |
| Custom applications | yes | yes | |
| Novell protocol filtered | yes | no | |
| DECnet protocol filtered | yes | no | |
| AppleTalk protocol filtered | yes | no | |
| Bridging protocol filtered | no | yes | |
| Automatic filters | n/a | no | |
| Network Protection | |||
| Network address translation | yes | yes | |
| IP Address hiding | yes | no | |
| Hide internal DNS info | yes | yes | |
| Sequence number prediction | yes | yes | |
| Source routing attack protection | yes | no | |
| Secure on system boot | yes | yes | |
| Misc Features | |||
| Virus scanning | yes | no | |
| Certifications | NCSA | NCSA, NSA | |
| Port scanning detection | no | yes |