A number of the security problems with the Internet discussed in Chapter 1 can be remedied or made less serious through the use of existing and well-known techniques and controls for host security. A firewall can significantly improve the level of site security while at the same time permitting access to vital Internet services. This chapter provides an overview of firewalls, including how they protect against the vulnerabilities described in Chapter 1, what firewalls don't protect against, and the components that make up a firewall. This chapter gives special emphasis to the use of advanced authentication and the importance of policy for determining how a firewall will implement a protection scheme.

The Firewall Concept

Perhaps it is best to describe first what a firewall is not: a firewall is not simply a router, host system, or collection of systems that provides security to a network. Rather, a firewall is an approach to security; it helps implement a larger security policy that defines the services and access to be permitted, and it is an implementation of that policy in terms of a network configuration, one or more host systems and routers, and other security measures such as advanced authentication in place of static passwords. The main purpose of a firewall system is to control access to or from a protected network (i.e., a site). It implements a network access policy by forcing connections to pass through the firewall, where they can be examined and evaluated.

A firewall system can be a router, a personal computer, a host, or a collection of hosts, set up specifically to shield a site or subnet from protocols and services that can be abused from hosts outside the subnet. A firewall system is usually located at a higher-level gateway, such as a site's connection to the Internet, however firewall systems can be located at lower-level gateways to provide protection for some smaller collection of hosts or subnets.

Why Firewalls

The general reasoning behind firewall usage is that without a firewall, a subnet's systems expose themselves to inherently insecure services such as NFS or NIS and to probes and attacks from hosts elsewhere on the network. In a firewall-less environment, network security relies totally on host security and all hosts must, in a sense, cooperate to achieve a uniformly high level of security. The larger the subnet, the less manageable it is to maintain all hosts at the same level of security. As mistakes and lapses in security become more common, break-ins occur not as the result of complex attacks, but because of simple errors in configuration and inadequate passwords.

A firewall approach provides numerous advantages to sites by helping to increase overall host security. The following sections summarize the primary benefits of using a firewall.

Protection from Vulnerable Services

A firewall can greatly improve network security and reduce risks to hosts on the subnet by filtering inherently insecure services. As a result, the subnet network environment is exposed to fewer risks, since only selected protocols will be able to pass through the firewall.

For example, a firewall could prohibit certain vulnerable services such as NFS from entering or leaving a protected subnet. This provides the benefit of preventing the services from being exploited by outside attackers, but at the same time permits the use of these services with greatly reduced risk to exploitation. Services such as NIS or NFS that are particularly useful on a local area network basis can thus be enjoyed and used to reduce the host management burden.

Firewalls can also provide protection from routing-based attacks, such as source routing and attempts to redirect routing paths to compromised sites via ICMP redirects. A firewall could reject all source-routed packets and ICMP redirects and then inform administrators of the incidents.

Controlled Access to Site Systems

A firewall also provides the ability to control access to site systems. For example, some hosts can be made reachable from outside networks, whereas others can be effectively sealed off from unwanted access. A site could prevent outside access to its hosts except for special cases such as mail servers or information servers.

This brings to the fore an access policy that firewalls are particularly adept at enforcing: do not provide access to hosts or services that do not require access. Put differently, why provide access to hosts and services that could be exploited by attackers when the access is not used or required? If, for example, a user requires little or no network access to her desktop workstation, then a firewall can enforce this policy.

Concentrated Security

A firewall can actually be less expensive for an organization in that all or most modified software and additional security software could be located on the firewall systems as opposed to being distributed on many hosts. In particular, one-time password systems and other add-on authentication software could be located at the firewall as opposed to each system that needed to be accessed from the Internet.

Other solutions to network security such as Kerberos [NIST94c] involve modifications at each host system. While Kerberos and other techniques should be considered for their advantages and may be more appropriate than firewalls in certain situations, firewalls tend to be simpler to implement in that only the firewall need run specialized software.

Enhanced Privacy

Privacy is of great concern to certain sites, since what would normally be considered innocuous information might actually contain clues that would be useful to an attacker. Using a firewall, some sites wish to block services such as finger and Domain Name Service. finger displays information about users such as their last login time, whether they've read mail, and other items. But, finger could leak information to attackers about how often a system is used, whether the system has active users connected, and whether the system could be attacked without drawing attention.

Firewalls can also be used to block DNS information about site systems, thus the names and IP addresses of site systems would not be available to Internet hosts. Some sites feel that by blocking this information, they are hiding information that would otherwise be useful to attackers.

Logging and Statistics on Network Use, Misuse

If all access to and from the Internet passes through a firewall, the firewall can log accesses and provide valuable statistics about network usage. A firewall, with appropriate alarms that sound when suspicious activity occurs can also provide details on whether the firewall and network are being probed or attacked.

It is important to collect network usage statistics and evidence of probing for a number of reasons. Of primary importance is knowing whether the firewall is withstanding probes and attacks, and determining whether the controls on the firewall are adequate. Network usage statistics are also important as input into network requirements studies and risk analysis activities.

Policy Enforcement

Lastly, but perhaps most importantly, a firewall provides the means for implementing and enforcing a network access policy. In effect, a firewall provides access control to users and services. Thus, a network access policy can be enforced by a firewall, whereas without a firewall, such a policy depends entirely on the cooperation of users. A site may be able to depend on its own users for their cooperation, however it cannot nor should not depend on Internet users in general.

Issues and Problems with Firewalls

Given these benefits to the firewall approach, there are also a number of disadvantages, and there are a number of things that firewalls cannot protect against. A firewall is not by any means a panacea for Internet security problems.

Restricted Access to Desirable Services

The most obvious disadvantage of a firewall is that it may likely block certain services that users want, such as TELNET, FTP, X Windows, NFS, etc. However, these disadvantage are not unique to firewalls; network access could be restricted at the host level as well, depending on a site's security policy. A well-planned security policy that balances security requirements with user needs can help greatly to alleviate problems with reduced access to services.

Some sites may have a topology that does not lend itself to a firewall, or may use services such as NFS in such a manner that using a firewall would require a major restructuring of network use. For example, a site might depend on using NFS and NIS across major gateways. In such a situation, the relative costs of adding a firewall would need to be compared against the cost of the vulnerabilities associated with not using a firewall, i.e., a risk analysis, and then a decision made on the outcome of the analysis. Other solutions such as Kerberos may be more appropriate, however these solutions carry their own disadvantages as well.

Large Potential for Back Doors

 

Secondly, firewalls do not protect against back doors into the site. For example, if unrestricted modem access is still permitted into a site protected by a firewall, attackers could effectively jump around the firewall [Haf91]. Modem speeds are now fast enough to make running SLIP (Serial Line IP) and PPP (Point-to-Point Protocol) practical; a SLIP or PPP connection inside a protected subnet is in essence another network connection and a potential backdoor. Why have a firewall if unrestricted modem access is permitted?

Little Protection from Insider Attacks

Firewalls generally do not provide protection from insider threats. While a firewall may be designed to prevent outsiders from obtaining sensitive data, the firewall does not prevent an insider from copying the data onto a tape and taking it out of the facility. Thus, it is faulty to assume that the existence of a firewall provides protection from insider attacks or attacks in general that do not need to use the firewall. It is perhaps unwise to invest significant resources in a firewall if other avenues for stealing data or attacking systems are neglected.

Other Issues

Other problems or issues with firewalls are as follows:

• WWW, gopher - Newer information servers and clients such as those for World Wide Web (WWW), gopher, WAIS, and others were not designed to work well with firewall policies and, due to their newness, are generally considered risky. The potential exists for data-driven attacks, in which data processed by the clients can contain instructions to the clients; the instructions could tell the client to alter access controls and important security-related files on the host.

• MBONE - Multicast IP transmissions (MBONE) for video and voice are encapsulated in other packets; firewalls generally forward the packets without examining the packet contents. MBONE transmissions represent a potential threat if the packets were to contain commands to alter security controls and permit intruders.

• viruses - Firewalls do not protect against users downloading virus-infected personal computer programs from Internet archives or transferring such programs in attachments to e-mail. Because these programs can be encoded or compressed in any number of ways, a firewall cannot scan such programs to search for virus signatures with any degree of accuracy. The virus problem still exists and must be handled with other policy and anti-viral controls.

• throughput - Firewalls represent a potential bottleneck, since all connections must pass through the firewall and, in some cases, be examined by the firewall. However, this is generally not a problem today, as firewalls can pass data at T1 (1.5 Megabitssecond) rates and most Internet sites are at connection rates less than or equal to T1.

• all eggs in single basket - A firewall system concentrates security in one spot as opposed to distributing it among systems. A compromise of the firewall could be disastrous to other less-protected systems on the subnet. This weakness can be countered, however, with the argument that lapses and weaknesses in security are more likely to be found as the number of systems in a subnet increase, thereby multiplying the ways in which subnets can be exploited.

Despite these disadvantages, NIST strongly recommends that sites protect their resources with firewalls and other security tools and techniques.

Firewall Components

The primary components (or aspects) of a firewall are:

• network policy,

• advanced authentication mechanisms,

• packet filtering, and

• application gateways.

The following sections describe each of these components more fully.

Network Policy

 

There are two levels of network policy that directly influence the design, installation and use of a firewall system. The higher-level policy is an issue-specific, network access policy that defines those services that will be allowed or explicitly denied from the restricted network, how these services will be used, and the conditions for exceptions to this policy. The lower-level policy describes how the firewall will actually go about restricting the access and filtering the services that were defined in the higher level policy. The following sections describe these policies in brief.

Service Access Policy

The service access policy should focus on Internet-specific use issues as defined above, and perhaps all outside network access (i.e., dial-in policy, and SLIP and PPP connections) as well. This policy should be an extension of an overall organizational policy regarding the protection of information resources in the organization. For a firewall to be successful, the service access policy must be realistic and sound and should be drafted before implementing a firewall. A realistic policy is one that provides a balance between protecting the network from known risks, while still providing users access to network resources. If a firewall system denies or restricts services, it usually requires the strength of the service access policy to prevent the firewall's access controls from being modified on an ad hoc basis. Only a management-backed, sound policy can provide this.

A firewall can implement a number of service access policies, however a typical policy may be to allow no access to a site from the Internet, but allow access from the site to the Internet. Another typical policy would be to allow some access from the Internet, but perhaps only to selected systems such as information servers and e-mail servers. Firewalls often implement service access policies that allow some user access from the Internet to selected internal hosts, but this access would be granted only if necessary and only if it could be combined with advanced authentication.

Firewall Design Policy

The firewall design policy is specific to the firewall. It defines the rules used to implement the service access policy. One cannot design this policy in a vacuum isolated from understanding issues such as firewall capabilities and limitations, and threats and vulnerabilities associated with TCP/IP. Firewalls generally implement one of two basic design policies:

1. permit any service unless it is expressly denied, and

2. deny any service unless it is expressly permitted.

A firewall that implements the first policy allows all services to pass into the site by default, with the exception of those services that the service access policy has identified as disallowed. A firewall that implements the second policy denies all services by default, but then passes those services that have been identified as allowed. This second policy follows the classic access model used in all areas of information security.

The first policy is less desirable, since it offers more avenues for getting around the firewall, e.g., users could access new services currently not denied by the policy (or even addressed by the policy) or run denied services at non-standard TCP/UDP ports that aren't denied by the policy. Certain services such as X Windows, FTP, Archie, and RPC cannot be filtered easily [Chap92], [Ches94], and are better accommodated by a firewall that implements the first policy. The second policy is stronger and safer, but it is more difficult to implement and may impact users more in that certain services such as those just mentioned may have to be blocked or restricted more heavily.

The relationship between the high level service access policy and its lower level counterpart is reflected in the discussion above. This relationship exists because the implementation of the service access policy is so heavily dependent upon the capabilities and limitations of the firewall system, as well as the inherent security problems associated with the wanted Internet services. For example, wanted services defined in the service access policy may have to be denied if the inherent security problems in these services cannot be effectively controlled by the lower level policy and if the security of the network takes precedence over other factors. On the other hand, an organization that is heavily dependent on these services to meet its mission may have to accept higher risk and allow access to these services. This relationship between the service access policy and its lower level counterpart allows for an iterative process in defining both, thus producing the realistic and sound policy initially described.

The service access policy is the most significant component of the four described here. The other three components are used to implement and enforce the policy. (And as noted above, the service access policy should be a reflection of a strong overall organization security policy.) The effectiveness of the firewall system in protecting the network depends on the type of firewall implementation used, the use of proper firewall procedures, and the service access policy.

Advanced Authentication

Sections , , and describe incidents on the Internet that have occurred in part due to the weaknesses associated with traditional passwords. For years, users have been advised to choose passwords that would be difficult to guess and to not reveal their passwords. However, even if users follow this advice (and many do not), the fact that intruders can and do monitor the Internet for passwords that are transmitted in the clear has rendered traditional passwords obsolete.

Advanced authentication measures such as smartcards, authentication tokens, biometrics, and software-based mechanisms are designed to counter the weaknesses of traditional passwords. While the authentication techniques vary, they are similar in that the passwords generated by advanced authentication devices cannot be reused by an attacker who has monitored a connection. Given the inherent problems with passwords on the Internet, an Internet-accessible firewall that does not use or does not contain the hooks to use advanced authentication makes little sense.

Some of the more popular advanced authentication devices in use today are called one-time password systems. A smartcard or authentication token, for example, generates a response that the host system can use in place of a traditional password. Because the token or card works in conjunction with software or hardware on the host, the generated response is unique for every login. The result is a one-time password that, if monitored, cannot be reused by an intruder to gain access to an account. [NIST94a] and [NIST91a] contain more detail on advanced authentication devices and measures.

  
Figure: Use of Advanced Authentication on a Firewall to Preauthenticate TELNET, FTP Traffic.

Since firewalls can centralize and control site access, the firewall is the logical place for the advanced authentication software or hardware to be located. Although advanced authentication measures could be used at each host, it is more practical and manageable to centralize the measures at the firewall. Figure illustrates that a site without a firewall using advanced authentication permits unauthenticated application traffic such as TELNET or FTP directly to site systems. If the hosts do not use advanced authentication, then intruders could attempt to crack passwords or could monitor the network for login sessions that would include the passwords. Figure also shows a site with a firewall using advanced authentication, such that TELNET or FTP sessions originating from the Internet to site systems must pass the advanced authentication before being permitted to the site systems. The site systems may still require static passwords before permitting access, however these passwords would be immune from exploitation, even if the passwords are monitored, as long as the advanced authentication measures and other firewall components prevent intruders from penetrating or bypassing the firewall.

Sections and contain more information on using advanced authentication measures with firewalls. See [NIST94b] for more information on using advanced authentication measures with hosts.

Packet Filtering

IP packet filtering is done usually using a packet filtering router designed for filtering packets as they pass between the router's interfaces. A packet filtering router usually can filter IP packets based on some or all of the following fields:

• source IP address,

• destination IP address,

• TCP/UDP source port, and

• TCP/UDP destination port.

Not all packet filtering routers currently filter the source TCP/UDP port, however more vendors are starting to incorporate this capability. Some routers examine which of the router's network interfaces a packet arrived at, and then use this as an additional filtering criterion. Some UNIX hosts provide packet filtering capability, although most do not.

Filtering can be used in a variety of ways to block connections from or to specific hosts or networks, and to block connections to specific ports. A site might wish to block connections from certain addresses, such as from hosts or sites that it considers to be hostile or untrustworthy. Alternatively, a site may wish to block connections from all addresses external to the site (with certain exceptions, such as with SMTP for receiving e-mail).

Adding TCP or UDP port filtering to IP address filtering results in a great deal of flexibility. Recall from Chapter 1 that servers such as the TELNET daemon reside usually at specific ports, such as port 23 for TELNET. If a firewall can block TCP or UDP connections to or from specific ports, then one can implement policies that call for certain types of connections to be made to specific hosts, but not other hosts. For example, a site may wish to block all incoming connections to all hosts except for several firewalls-related systems. At those systems, the site may wish to allow only specific services, such as SMTP for one system and TELNET or FTP connections to another system. With filtering on TCP or UDP ports, this policy can be implemented in a straightforward fashion by a packet filtering router or by a host with packet filtering capability.

 
Figure: Representation of Packet Filtering on TELNET and SMTP.

As an example of packet filtering, consider a policy to allow only certain connections to a network of address 123.4.*.*. TELNET connections will be allowed to only one host, 123.4.5.6, which may be the site's TELNET application gateway, and SMTP connections will be allowed to two hosts, 123.4.5.7 and 123.4.5.8, which may be the site's two electronic mail gateways. NNTP (Network News Transfer Protocol) is allowed only from the site's NNTP feed system, 129.6.48.254, and only to the site's NNTP server, 123.4.5.9, and NTP (Network Time Protocol) is allowed to all hosts. All other services and packets are to be blocked. An example of the ruleset would be as follows:

The first rule allows TCP packets from any source address and port greater than 1023 on the Internet to the destination address of 123.4.5.6 and port of 23 at the site. Port 23 is the port associated with the TELNET server, and all TELNET clients should have unprivileged source ports of 1024 or higher. The second and third rules work in a similar fashion, except packets to destination addresses 123.4.5.7 and 123.4.5.8, and port 25 for SMTP, are permitted. The fourth rule permits packets to the site's NNTP server, but only from source address 129.6.48.254 to destination address 123.4.5.9 and port 119 (129.6.48.254 is the only NNTP server that the site should receive news from, thus access to the site for NNTP is restricted to only that system). The fifth rule permits NTP traffic, which uses UDP as opposed to TCP, from any source to any destination address at the site. Finally, the sixth rule denies all other packets - if this rule weren't present, the router may or may not deny all subsequent packets. This is a very basic example of packet filtering. Actual rules permit more complex filtering and greater flexibility.

Which Protocols to Filter

The decision to filter certain protocols and fields depends on the network access policy, i.e., which systems should have Internet access and the type of access to permit. The following services are inherently vulnerable to abuse and are usually blocked at a firewall from entering or leaving the site [Chap92], [Garf92]:

• tftp, port 69, trivial FTP, used for booting diskless workstations, terminal servers and routers, can also be used to read any file on the system if set up incorrectly,

• X Windows, OpenWindows, ports 6000+, port 2000, can leak information from X window displays including all keystrokes,

• RPC, port 111, Remote Procedure Call services including NIS and NFS, which can be used to steal system information such as passwords and read and write to files, and

• rlogin, rsh, and rexec, ports 513, 514, and 512, services that if improperly configured can permit unauthorized access to accounts and commands.

Other services, whether inherently dangerous or not, are usually filtered and possibly restricted to only those systems that need them. These would include:

• TELNET, port 23, often restricted to only certain systems,

• FTP, ports 20 and 21, like TELNET, often restricted to only certain systems,

• SMTP, port 25, often restricted to a central e-mail server,

• RIP, port 520, routing information protocol, can be spoofed to redirect packet routing,

• DNS, port 53, domain names service zone transfers, contains names of hosts and information about hosts that could be helpful to attackers, could be spoofed,

• UUCP, port 540, UNIX-to-UNIX CoPy, if improperly configured can be used for unauthorized access,

• NNTP, port 119, Network News Transfer Protocol, for accessing and reading network news, and

• gopher, http (for Mosaic), ports 70 and 80, information servers and client programs for gopher and WWW clients, should be restricted to an application gateway that contains proxy services.

While some of these services such as TELNET or FTP are inherently risky, blocking access to these services completely may be too drastic a policy for many sites. Not all systems, though, generally require access to all services. For example, restricting TELNET or FTP access from the Internet to only those systems that require the access can improve security at no cost to user convenience. Services such as NNTP may seem to pose little threat, but restricting these services to only those systems that need them helps to create a cleaner network environment and reduces the likelihood of exploitation from yet-to-be-discovered vulnerabilities and threats.

Problems with Packet Filtering Routers

Packet filtering routers suffer from a number of weaknesses, as described in [Chap92]. Packet filtering rules are complex to specify and usually no testing facility exists for verifying the correctness of the rules (other than by exhaustive testing by hand). Some routers do not provide any logging capability, so that if a router's rules still let dangerous packets through, the packets may not be detected until a break-in has occurred.

Often times, exceptions to rules need to be made to allow certain types of access that normally would be blocked. But, exceptions to packet filtering rules sometimes can make the filtering rules so complex as to be unmanageable. For example, it is relatively straightforward to specify a rule to block all inbound connections to port 23 (the TELNET server). If exceptions are made, i.e., if certain site systems need to accept TELNET connections directly, then a rule for each system must be added. Sometimes the addition of certain rules may complicate the entire filtering scheme. As noted previously, testing a complex set of rules for correctness may be so difficult as to be impractical.

Some packet filtering routers do not filter on the TCP/UDP source port, which can make the filtering ruleset more complex and can open up ``holes'' in the filtering scheme. [Chap92] describes such a problem with sites that wish to allow inbound and outbound SMTP connections. As described in section , TCP connections include a source and destination port. In the case of a system initiating an SMTP connection to a server, the source port would be a randomly chosen port at or above 1024 and the destination port would be 25, the port that the SMTP server ``listens'' at. The server would return packets with source port of 25 and destination port equal to the randomly-chosen port at the client. If a site permits both inbound and outbound SMTP connections, the router must allow destination ports and source ports > 1023 in both directions. If the router can filter on source port, it can block all packets coming into the site that have a destination port > 1023 and a source port other than 25. Without the ability to filter on source port, the router must permit connections that use source and destination ports > 1024. Users could conceivably run servers at ports > 1023 and thus get ``around'' the filtering policy (i.e., a site system's telnet server that normally listens at port 23 could be told to listen at port 9876 instead; users on the Internet could then telnet to this server even if the router blocks destination port 23).

Another problem is that a number of RPC (Remote Procedure Call) services are very difficult to filter effectively because the associated servers listen at ports that are assigned randomly at system startup. A service known as portmapper maps initial calls to RPC services to the assigned service numbers, but there is no such equivalent for a packet filtering router. Since the router cannot be told which ports the services reside at, it isn't possible to block completely these services unless one blocks all UDP packets (RPC services mostly use UDP). Blocking all UDP would block potentially necessary services such as DNS. Thus, blocking RPC results in a dilemma.

Packet filtering routers with more than two interfaces sometimes do not have the capability to filter packets according to which interface the packets arrived at and which interface the packet is bound for. Filtering inbound and outbound packets simplifies the packet filtering rules and permits the router to more easily determine whether an IP address is valid or being spoofed. Routers without this capability offer more impediments to implementing filtering strategies.

Related to this, packet filtering routers can implement both of the design policies discussed in section . A ruleset that is less flexible, i.e., that does not filter on source port or on inbound and outbound interfaces, reduces the ability of the router to implement the second and more stringent policy, deny all services except those expressly permitted, without having to curtail the types of services permitted through the router. For example, problematic services such as those that are RPC-based become even more difficult to filter with a less-flexible ruleset; no filtering on source port forces one to permit connections between ports > 1023. With a less-flexible ruleset, the router is less able to express a stringent policy, and the first policy, permit all services except those expressly permitted, is usually followed.

Readers are advised to consult [Chap92], which provides a concise overview of packet filtering and associated problems. While packet filtering is a vital and important tool, it is very important to understand the problems and how they can be addressed.

Application Gateways

 

To counter some of the weaknesses associated with packet filtering routers, firewalls need to use software applications to forward and filter connections for services such as TELNET and FTP. Such an application is referred to as a proxy service, while the host running the proxy service is referred to as an application gateway. Application gateways and packet filtering routers can be combined to provide higher levels of security and flexibility than if either were used alone.

As an example, consider a site that blocks all incoming TELNET and FTP connections using a packet filtering router. The router allows TELNET and FTP packets to go to one host only, the TELNET/FTP application gateway. A user who wishes to connect inbound to a site system would have to connect first to the application gateway, and then to the destination host, as follows:

1. a user first telnets to the application gateway and enters the name of an internal host,

2. the gateway checks the user's source IP address and accepts or rejects it according to any access criteria in place,

3. the user may need to authenticate herself (possibly using a one-time password device),

4. the proxy service creates a TELNET connection between the gateway and the internal host,

5. the proxy service then passes bytes between the two connections, and

6. the application gateway logs the connection.

  
Figure: Virtual Connection Implemented by an Application Gateway and Proxy Services.

This example points out several benefits to using proxy services. First, proxy services allow only those services through for which there is a proxy. In other words, if an application gateway contains proxies for FTP and TELNET, then only FTP and TELNET may be allowed into the protected subnet, and all other services are completely blocked. For some sites, this degree of security is important, as it guarantees that only those services that are deemed ``trustworthy'' are allowed through the firewall. It also prevents other untrusted services from being implemented behind the backs of the firewall administrators.

Another benefit to using proxy services is that the protocol can be filtered. Some firewalls, for example, can filter FTP connections and deny use of the FTP put command, which is useful if one wants to guarantee that users cannot write to, say, an anonymous FTP server.

Application gateways have a number of general advantages over the default mode of permitting application traffic directly to internal hosts. These include:

• information hiding, in which the names of internal systems need not necessarily be made known via DNS to outside systems, since the application gateway may be the only host whose name must be made known to outside systems,

• robust authentication and logging, in which the application traffic can be pre-authenticated before it reaches internal hosts and can be logged more effectively than if logged with standard host logging,

• cost-effectiveness, because third-party software or hardware for authentication or logging need be located only at the application gateway, and

• less-complex filtering rules, in which the rules at the packet filtering router will be less complex than they would if the router needed to filter application traffic and direct it to a number of specific systems. The router need only allow application traffic destined for the application gateway and reject the rest.

A disadvantage of application gateways is that, in the case of client-server protocols such as TELNET, two steps are required to connect inbound or outbound. Some application gateways require modified clients, which can be viewed as a disadvantage or an advantage, depending on whether the modified clients make it easier to use the firewall. A TELNET application gateway would not necessarily require a modified TELNET client, however it would require a modification in user behavior: the user has to connect (but not login) to the firewall as opposed to connecting directly to the host. But a modified TELNET client could make the firewall transparent by permitting a user to specify the destination system (as opposed to the firewall) in the TELNET command. The firewall would serve as the route to the destination system and thereby intercept the connection, and then perform additional steps as necessary such as querying for a one-time password. User behavior stays the same, however at the price of requiring a modified client on each system.

In addition to TELNET, application gateways are used generally for FTP and e-mail, as well as for X Windows and some other services. Some FTP application gateways include the capability to deny put and get command to specific hosts. For example, an outside user who has established an FTP session (via the FTP application gateway) to an internal system such as an anonymous FTP server might try to upload files to the server. The application gateway can filter the FTP protocol and deny all puts to the anonymous FTP server; this would ensure that nothing can be uploaded to the server and would provide a higher degree of assurance than relying only on file permissions at the anonymous FTP server to be set correctly.

An e-mail application gateway serves to centralize e-mail collection and distribution to internal hosts and users. To outside users, all internal users would have e-mail addresses of the form:

user@emailhost

where emailhost is the name of the e-mail gateway. The gateway would accept mail from outside users and then forward mail along to other internal systems as necessary. Users sending e-mail from internal systems could send it directly from their hosts, or in the case where internal system names are not known outside the protected subnet, the mail would be sent to the application gateway, which could then forward the mail to the destination host. Some e-mail gateways use a more secure version of the sendmail program to accept e-mail.

Circuit-Level Gateways

[Ches94] defines another firewall component that other authors sometimes include under the category of application gateway. A circuit-level gateway relays TCP connections but does no extra processing or filtering of the protocol. For example, the TELNET application gateway example provided here would be an example of a circuit-level gateway, since once the connection between the source and destination is established, the firewall simply passes bytes between the systems. Another example of a circuit-level gateway would be for NNTP, in which the NNTP server would connect to the firewall, and then internal systems' NNTP clients would connect to the firewall. The firewall would, again, simply pass bytes.