Application-Gateway Firewalls

A second type of firewall handles the choke function of a firewall in a different manner — by determining not only whether but also how each connection through it is made. This type of firewall stops each incoming (or outgoing) connection at the firewall, then (if the connection is permitted) initiates its own connection to the destination host on behalf of whomever created the initial connection. This type of connection is thus called a proxy connection. Using its data base defining the types of allowed connections, the firewall either establishes another connection (permitting the originating and destination host to communicate) or drops the original connection altogether. If the firewall is programmed appropriately, the whole process can be largely transparent to users.

An application-gateway firewall is simply a type of proxy server that provides proxies for specific applications. The most common implementations of application-gateway firewalls address proxy services (such as mail, FTP, and telnet) so that they do not run on the firewall itself — something that is very good for the sake of security, given the inherent dangers associated with each. Mail services, for example, can be proxied to a mail server. Each connection is subject to a set of specific rules and conditions similar to those in packet-filtering firewalls except that the selectivity rules used by application-gateway firewalls are not based on ports, but rather on the to-be-accessed programs/services themselves (regardless of what port is used to access these programs). Criteria such as the source or destination IP address can, however, still be used to accept or reject incoming connections. Application-level firewalls can go even further by determining permissible conditions and events once a proxy connection is established. An FTP proxy could restrict FTP access to one or more hosts by allowing use of the get command, for example, while preventing the use of the put command. A telnet proxy could terminate a connection if the user attempts to perform a shell escape or to gain root access. Application-gateway firewalls are not limited only to applications that support TCP/IP services; these tools can similarly govern conditions of usage of a wide variety of applications, such as financial or process control applications.

Two basic types of application-gateway firewalls are currently available: (1) application-generic firewalls, and (2) application-specific firewalls. The former provide a uniform method of connection to every application, regardless of which particular one it is. The latter determine the nature of connections to applications on an application-by-application basis. Regardless of the specific type of application-gateway firewall, the security control resulting from using a properly configured one can be quite precise. When used in connection with appropriate host-level controls (e.g., proper file permissions and ownerships), application-gateway firewalls can render externally originated attacks on applications extremely difficult. Application-gateway firewalls also serve another extremely important function — hiding information about hosts within the internal network from the rest of the world, so to speak¹⁰. Finally, a number of commercial application-gateway firewalls available today support strong authentication methods such as token-based methods (e.g., use of hand-held authentication devices).

---

¹⁰Some packet-filtering firewalls are also able to accomplish this function.

---

Application-gateway firewalls currently are the best selling of all types of firewalls. Nevertheless, they have some notable limitations, the most significant of which is that every TCP/IP client for which the firewall provides proxies must be aware of the proxy that the firewall runs on its behalf. This means that each client must be modified accordingly, which is often no small task in today’s typical computing environment. A second limitation is that unless one uses a generic proxy mechanism, every application needs its own custom proxy. This limitation is not formidable in the case of proxies for services such as telnet, FTP, and HTTP, because a variety of proxy implementations are available for these widely used services. Proxies for many other services are at the present time, however, not available, and must be custom written. Third, although some application-gateway firewall implementations are more transparent to users than others, any vendor’s claim that any implementation is completely transparent warrants healthy skepticism. Some application-gatewall firewalls even require users who have initiated connections to make selections from menus before they reach the desired destination. Finally, most application-gateway firewalls are not easy to initially configure and update correctly. To use an application-gateway firewall to the maximum advantage, network administrators should set up a new proxy for every new application accessible from outside a network. Furthermore, network administrators should work with application owners to ensure that specific, useful restrictions on usage are placed on every remote connection to each critical application from outside the network. Seldom, however, are such practices observed because of the time, effort, and complexity involved.