A Gauntlet Firewall is a hardware- and software-based firewall system. It provides secure access and internetwork communications between private networks and public networks (such as the Internet), and between subnets of private networks. It offers application-level security services for both incoming and outgoing communications based on existing security practices or an organization's security policies.
This chapter provides an overview of the Gauntlet Firewall and how it works. It is not a thorough discussion of firewalls or security practices. Refer to “Additional Resources” for a list of other resources that provide excellent introductory and advanced discussions of firewalls. The chapter contains these sections:
Simply put, a firewall is a single point of defense that protects one side of a network from the other side. This usually means protecting your company's private network from other networks to which it is connected, such as the Internet. Firewalls can be as simple as a router that filters packets or as complex as a multisystem, multirouter solution that combines packet filtering with application gateways.
That which is not expressly permitted is prohibited.
The firewall will allow only those activities that are explicitly set, either through system defaults or through your own configurations. New services don't get through the firewall unless you allow them through. You must be able to identify and remove any “backdoors” you have left in place that no longer match your security policy.
Recognizing that most security breaches occur through a compromised user account, the Gauntlet Firewall generally has no user accounts. While you can set up an administrator account, users do not need to log into the firewall to access information on the other side of your firewall.
The Gauntlet Firewall is auditable, controllable, and configurable. It logs many activities and processes.
Establishing a network security perimeter involves designating a network of systems you wish to protect and defining the mechanisms used to protect them. The firewall is the communications gateway for all hosts inside the perimeter. To have a successful network security perimeter, all communications from outside the security perimeter to hosts inside the perimeter must pass through the firewall.
Your firewall must be configured to differentiate between the “good guys” and the “bad guys.” The firewall makes this determination using information you provide about different networks. It understands three types of networks: trusted, untrusted, and unknown.
Trusted networks are the networks inside your security perimeter. Trusted networks are usually the ones you are trying to protect. Often, you or someone in your organization administers the systems on these networks. Your organization controls the security measures for these networks. Usually, they are within the physical security perimeter. They can also be connected in a virtual private network, as explained in Chapter 28, “Managing Virtual Private Networks”.
When you set up the firewall, you explicitly configure the networks your firewall can trust. After initial configuration, the trusted networks usually include the firewall itself and all networks inside your security perimeter.
Untrusted networks are the networks outside your security perimeter. They are untrusted because they are usually outside your control or knowledge. You have no control over the administration or security policies for these sites. They are the ones from which you are trying to protect your network. However, you still need and want to communicate with these networks, even though they are untrusted.
When you set up the firewall, you explicitly configure the networks from which your firewall can accept requests, but which it does not trust. By default, after initial configuration, the untrusted networks are all networks outside the perimeter.
The firewall uses different service groups for requests from untrusted networks than it does for requests from trusted networks. For example, the default configuration allows HTTP requests from trusted networks but not from untrusted networks. For some types of requests (including TELNET, FTP, rlogin, rsh, HTTP, and POP3), the firewall may use additional authentication before processing the request.
Unknown networks are those networks that are neither trusted nor untrusted. They are unknown quantities to the firewall because you have not explicitly told the firewall that this network is a trusted or an untrusted network. By default, the list of untrusted networks contains all networks that are not trusted (*). In that case, there are no unknown networks. If you change the list of untrusted networks to contain some specific networks, all networks not in the trusted or untrusted list become unknown.
Consider a company that lists its own networks as the trusted network. The company lists the networks for three clients as the untrusted networks. Every other network on the Internet is now an unknown network and cannot pass requests through the firewall.
Your security policy provides a list of allowed and prohibited activities. Similarly, the Gauntlet Firewall uses service groups to specify allowed activities. Service groups are collections of rules about what the firewall can and cannot do in particular situations. Service groups indicate which proxies can run, and whether they require authentication, special logging, or other general settings. The service groups you create and rules you assign should be based on your site's security policies.
By default, the Gauntlet Firewall includes one service group for requests from trusted networks and one for requests from untrusted networks. The firewall uses the source IP address of the request to determine which service group to use.
The default service group for trusted networks allows for a variety of services (including TELNET, FTP, NNTP, and HTTP). It does not require users to authenticate. The default service group for untrusted networks allows for only a few services (including FTP, TELNET, NNTP, and POP3). It requires users to authenticate before accessing hosts inside your security perimeter. You can, of course, modify these default service groups to match your security policy.
Transparency means that your firewall is not visible to your users as they work. They can continue to use TELNET, for example, to access client sites without having to explicitly connect to the firewall.
The default Gauntlet Firewall configuration implements transparency inside your firewall for your trusted networks. This is accomplished by creating default routes that send all requests to untrusted networks through the firewall and by certain configuration options on the firewall.
In contrast, the firewall does not implement transparency for requests from untrusted networks. In this case, you want users outside your security perimeter to be aware that they are entering your site through your firewall.
The advantage of transparent access is that you do not need to reconfigure your client systems or learn new procedures in order to use supported services. Nontransparent access is supported, but users must learn procedures to perform their tasks.
The Gauntlet Firewall uses hardware and software to protect your network.
The operating system is a version of the standard Silicon Graphic's IRIX operating system, “hardened” by the Gauntlet software. As part of the firewall, the operating system has been tailored to provide support for only the services necessary to run the firewall. For example, the operating system on the firewall does not support IP packet forwarding, source routed packets, or ICMP redirects. These services change the directions that packets flow, and could direct networks to circumvent the firewall. Services such as NFS, NIS, and RPC cannot easily be made secure and so should be disabled.
Unsupported network services do not just report an error to the requesting site. The operating system logs these access attempts, providing information about such probes.
The software on the Gauntlet Firewall includes security services on a per-application basis. As noted above, all packets, and therefore all application requests go to the firewall. On the firewall, proxy software relays information from one side of the firewall to the other. The proxy prevents the applications on outside networks from talking directly with the applications on your inside network, and vice versa. No IP packets pass from one side of the firewall to the other. All data is passed at the application level. (The “trusted ports” feature in this implementation is an exception to this generalization.)
In addition, the Gauntlet Firewall includes a generic plug-board proxy. This proxy patches TCP traffic from a particular port on one side of the firewall to a particular TCP port on another system on the other side of the firewall. As with the service-specific proxies, no IP packets pass from one side of the firewall to the other. If you have not installed a proxy for a service, that type of traffic does not pass through the firewall.
The Gauntlet Firewall also includes an authenticating circuit proxy. This proxy also patches TCP traffic from a particular port on one side of the firewall to a particular TCP port on another system on the other side of the firewall. The circuit proxy requires users to authenticate first; the plug proxy does not.
Because the non-plug proxies use the same protocols to communicate as the applications, you do not need to modify the original client or server applications. For example, when the TELNET application connects to the firewall, the application follows the standard TELNET protocol in RFCs 764 and 854. You can continue to use the same TELNET application to connect to remote sites.
All of the proxies are configurable. You can accept or reject requests to or from certain sites and networks, or set up other rules the proxies use when passing requests through the firewall. You can also enable or disable individual proxies and run only the ones you need. You can easily translate your security policies into configuration rules.
The proxies log all activities to and through the firewall. You can use the logs to gather usage statistics or to look for potential attacks.
In addition, several of the proxies support strong user authentication systems. These one-time passwords or security token systems provide additional security because users use a different password each time they access the network.
The Gauntlet Firewall includes additional security software in the form of an IP screening utility. This feature checks IP packets based on several criteria (for example, address and protocol) and processes or rejects the packets. It detects spoofed packets claiming to be from one network that are actually from another network.
Using the IP screening utility, you can configure the firewall so that the firewall is transparent to your users for most activities. The IP screening facility provides a method for permitting high bandwidth or unsupported protocols in situations where the security requirements are not as stringent as with an Internet firewall.
The Gauntlet Firewall also contains several programs that ease the job of administering the firewall. These include management tools for configuring the firewall, and scripts for reporting activity through the firewall and performing general administration.
The graphical Gauntlet Firewall Manager utility provides an easy-to-use interface for performing most standard configuration activities. You do not need to modify system files or configuration files unless you want to customize uncommon features of your configuration.
The Gauntlet Firewall also includes shell scripts that assist in upgrading, creating backups, checking integrity, and other general administrative tasks.
Consider a company, Yoyodyne, that has a connection to the Internet via an Internet service provider (ISP). They have installed a Gauntlet Firewall to protect their corporate network (yoyodyne.com) from every other host on the Internet. They are using the configuration shown in Figure 1-1.
The Yoyodyne network is first separated from the rest of the Internet by a router. The router passes traffic from the Internet to the Gauntlet firewall only when that traffic is bound for some part of the Yoyodyne internal network. More sophisticated routers can additionally strengthen a company's security perimeter by implementing certain security functions such as “IP spoofing filters.”
The firewall is helping to establish a security perimeter to protect the internal (trusted) network. It screens all requests that need to pass from one side of the firewall to the other. Using rules Yoyodyne created based on their security policies, the firewall determines whether to accept or pass requests through (at the application or TCP level) to the other side.
In order to protect the inside network, the firewall must be able to see all of the packets intended for hosts on the inside network. While there are a number of ways to physically and logically accomplish this, the recommended configuration is the firewall system installed as a dual-homed bastion host.
As a dual-homed bastion host, the firewall system has two network interface cards, thus two connections—one to your network and one to the outside, as shown in Figure 1-2.
All outside network traffic enters and exits the firewall through one network interface, such as ec0. All inside network traffic enters and exits through a second network interface, such as ec1. To accomplish this, each interface has a separate IP address. Yoyodyne was assigned the 204.254.155 network, and chose 18.104.22.168 as the outside IP address; it chose 10.0.1.253 for the inside IP address.
|Note: You can also use two firewalls to create a virtual private network (or a virtual network perimeter), exchanging encrypted information across an untrusted network, such as the Internet. Because of United States government export regulations, this feature is generally not available outside the United States and Canada. Refer to Chapter 28, “Managing Virtual Private Networks”, for information about the encryption features of the Gauntlet Firewall.|
The firewall follows a standard set of steps for the packets it receives on either interface. The steps are discussed in these sections:
As we examine each step of the process, consider a Yoyodyne employee working at a client site (outside the security perimeter) who needs access to their system at work via TELNET.
Routing information on outside hosts and at the ISP directs all requests to hosts on the inside network to the firewall. In addition, the domain name system (DNS) on the firewall and other outside DNS servers advertise the outside IP address of the firewall as the only way to connect to anything on the inside network. Hosts on the inside network use routing information to direct all requests for outside networks to the inside address of the firewall.
For example, the client company systems consult their routing information and pass the TELNET request along until it reaches the Yoyodyne firewall.
Once the firewall receives a packet it must determine what to do with it. First, the operating system kernel examines the destination of the packet and determines whether the packet is destined for a host inside the firewall. The firewall accepts the packet and redirects it to the appropriate proxy. If there is no proxy configured to accept a packet, the firewall drops the packet and logs the failed access.
Next, the firewall examines the source address of the packet and the interface on which it received the packet. This process verifies the information against configuration tables, and prevents the firewall from accepting IP spoofed packets. If this check indicates that the current request could not possibly have come in through the associated interface, the firewall rejects the packet and logs it. For example, if the Yoyodyne firewall receives a packet on ec0 (the outside interface) claiming to be from 10.0.1.10 (an inside address), the firewall rejects the packet and logs the spoof attempt.
In our TELNET example, the destination of the packet is the firewall. The firewall receives a request on ec0, the outside interface. The address does not indicate that it came from an inside network. The firewall accepts the packet for local delivery and processing.
Now that the firewall knows to deliver the packet locally, it looks at the contents of the packet. The operating system checks various tables on the firewall to determine if it offers the requested service on the requested port. If it does not, it logs the attempt as a potential security alert and rejects the request.
In our TELNET example, the packet indicates that it is a TELNET request on TCP port 23. The configuration tables indicate that the firewall supports this type of service.
Now that the firewall knows to offer the requested service, the operating system uses other configuration information to forward the request to the appropriate daemon. In our TELNET example, the firewall forwards the request to the TELNET proxy, which processes the TELNET request.
The proxy now processes the request. It first checks its configuration information. The proxy determines how to handle the request based on the source (IP address) of the request. By default, it uses one service group (set of rules) for trusted networks and another service group for untrusted networks.
Once configured, the proxy processes the request as the standard application would. The proxies follow the same protocols and handshakes as indicated in the RFCs or other documents. Requesting applications think they are talking to an actual server, not a proxy.
The proxies also check whether the request is permitted for the destination. For some services, the proxies can perform the additional step of authenticating the user. This verification provides additional assurance that users really are who they say they are. The proxies then pass each request to the appropriate program on the other side of the firewall using the standard protocol for that service.
In our TELNET example, the TELNET proxy uses the generic untrusted service group because the request came from an outside network. The untrusted service group and rule permits TELNET to access systems on the inside network, but requires authentication. The firewall prompts the user to authenticate. Once the user authenticates, the proxy provides a command-line interface allowing the user to indicate the internal system to which they wish to connect. The proxy then uses the standard TELNET protocol to pass packets back and forth between the host on the outside network and the host on the inside network.