3.5 Application-level gateways

Contrary to a circuit-level gateway, an application-level gateway serves only one application protocol. To clarify this point, imagine the situation in which the packet filter of a firewall blocks all inbound Telnet and FTP sessions, unless the sessions are terminated by a bastion host (that is also part of the firewall configuration). The bastion host, in turn , hosts an application gateway that operates at the transport (circuit) or application layer. The situation is slightly different in either case:

If the application gateway operates at the transport layer, a circuitlevel gateway (e.g., a SOCKS server) must be running on the bastion host.
If the application gateway operates at the application layer, there are basically two application-level gateways or proxy servers that must be running on the bastion host (i.e., one proxy server for Telnet and another proxy server for FTP).

In either case, a user who wishes to connect inbound to an intranet server must have his or her Telnet or FTP client connect to the application gateway running on the bastion host. The application gateway, in turn, would then authenticate and authorize the user . In the positive case, it would set up a secondary TCP connection to the intranet server and relay application data between the two TCP connections back and forth. If the application gateway were a circuit-level gateway, it would not look into the application data it relays. If, however, the application gateway were an application-level gateway, it would look into and fully control the application data stream. In an attempt to make it hard to retrieve internal files from systems located on the Internet, an application-level gateway could, for example, be configured in a way that permits the use of the FTP PUT command but denies the use of the FTP GET command. Similarly, an application-level gateway for HTTP could be configured to screen data traffic and filter out Java applets and ActiveX controls to protect internal hosts from mobile code and software-driven attacks (this kind of filtering is not possible in the case of circuit-level gateways).

From the client s point of view, interaction with an application gateway requires some additional steps. This is equally true for circuit-level gateways and application-level gateways. In the case of a SOCKS server the additional steps are hidden from the user and the corresponding client software must be modified to be aware of the SOCKS server (i.e., it must be ˜ ˜socksified ).

In general, the use of an application gateway requires some customization and modification of either the user procedures or the client software:

The customization and modification of the user procedures is a simple and straightforward approach to implementing application gateway support. Following this approach, the user first establishes a connection to the application gateway and then requests the establishment of a second connection to the server. An important benefit is that the customization of the user procedures, in general, requires no impact to client software. Given the extensive presence of client software, this approach is attractive for implementing Internet access (in fact, the first Internet firewalls worked that way). The main disadvantage of this approach is that the user has to be trained for an extra step to log on to the proxy server.
The other approach to implementing application gateway support is to customize and modify the client software (similar to the process of ˜ ˜socksifying a client). The main advantage of this approach is that it may provide transparency to users in accessing the Internet and traversing firewall systems. The main disadvantage, however, is that it obviously requires modifications to client software. This is not always possible and seldom easy to accomplish.

Note that both approaches have severe disadvantages, as they require customization and modification of either the user procedures or the client software. Which approach is simpler depends on the application, its availability in source code, and the organization that makes use of the application. ^[15]

Against this background, it would be nice to have a firewall that maintains all software modifications required for application gateway support in the firewall. In this case, neither the user procedures nor the client software would have to be customized or modified accordingly . This idea has led to the development of transparent firewalls.

In short, a transparent firewall is configured to listen on the network segment of the firewall for outgoing TCP connections and to autonomously relay these connections on the client s behalf . Note, however, that transparency is not necessarily provided in both directions. As a matter of fact, inbound transparency is seldom required or used, as users must usually authenticate themselves at a firewall system. Also note that a transparent firewall still requires that all messages to and from the Internet be transmitted through the firewall. However, the existence of the firewall system can be hidden entirely from both the user and the client software.

Let us have a look at an example in which a Telnet client tries to connect to a Telnet server making use of a proxy server. The procedure to establish a Telnet session can be summarized as follows :

The Telnet client acting on behalf of the user requests a TCP connection to the Telnet proxy server running on the firewall (at an arbitrary but fixed port number). If a screening router is put in front of the firewall, the connection must be authorized according to the corresponding packet-filtering rules.
The Telnet proxy server, in turn, may check the source IP address of the client machine. The connection request can be accepted or rejected according to some authorization and access control information.
In addition to the source IP address check of the client, the user may also need to authenticate himself or herself (e.g., using a username and password).
If the user is properly authenticated, the client must provide the address or name of the Telnet server (again, this step can be and will be made transparent to the user).
The Telnet proxy server then establishes a second TCP connection to the Telnet server. Again, this connection request may have to pass through a screening router. In this case, the packet-filtering rules of the screening router must be configured so that they let packets through that are originated by a firewall system.
After having established the second TCP connection to the Telnet server, the Telnet proxy server relays Telnet data between the two connections. In addition, the Telnet proxy server also may scan the data traffic for specific Telnet commands and filter them out. Also, the Telnet proxy server may log all command executions to build an audit trail.

To properly authenticate the user, the Telnet proxy server must have access to some authentication and authorization information. This is generally true for any application-level gateway or proxy server that provides support for user-level authentication (not just Telnet proxy servers). In general, there are several user authentication and authorization schemes that an application-level gateway or proxy server could implement and use. In either case, the application-level gateway or proxy server must have access to some reference information it can use to verify whether the authentication information provided by a client (or user) is valid (e.g., a one-way hash value of a user password or the public key certificate of a user). The reference information can be stored either locally or remotely. If many firewall systems and network access servers (NAS) are put in place, the second approach is preferable since it makes it possible to aggregate security information at a single point. Typically, a standardized protocol is used to retrieve the reference information from a centralized security server. There are currently two competing protocol proposals:

Livingston Enterprises, Inc., has developed and implemented a protocol called Remote Authentication Dial-In User Service (RADIUS) [18]. ^[16] In short, the RADIUS protocol can be used to carry authentication, authorization, and configuration information between an NAS that desires to authenticate its users and a shared authentication or security server. Livingston Enterprises, Inc., also has made publicly and freely available corresponding RADIUS security server software. A companion protocol that can be used to carry accounting information between an NAS and a shared authentication or security server is specified in [19].
The terminal access controller access control system (TACACS) was originally developed by BBN under ARPA funding in the early 1980s. It was used to authenticate users to terminal access computers on the ARPANET. Later, Cisco Systems developed, implemented, and deployed a family of protocols that are based on TACACS [20]. While the TACACS and extended TACACS (XTACACS) protocols are no longer in use, TACACS+ is a protocol in current use. Refer to the Cisco manuals for the corresponding TACACS, XTACACS, and TACACS+ commands.

Both protocols (RADIUS and the protocol family for the TACACS derivates) are widely supported by firewall systems and network access servers.

After having successfully authenticated and authorized the client (or user), a proxy server sets up a secondary TCP connection to the requested application server. From the user s point of view, a secondary authentication may now be required and actually take place, since the application server may want to authenticate and authorize the client (or user) as well. This secondary authentication step is beyond the scope of the firewall. If the user is successfully authenticated and authorized, the application server usually starts serving the request.

In summary, application-level gateways and proxy servers provide a sophisticated and advanced technology to secure TCP-based applications and application protocols for the WWW. Commercial firewalls typically come along with proxy server support for Telnet, FTP, SMTP, HTTP, and many other TCP-based applications and application protocols. There are

advantages and disadvantages that should be kept in mind when discussing the suitability of application-level gateways and proxy servers. The advantages are related to user authentication and authorization, application protocol control, logging, and accounting. Contrary to that, the disadvantages are related to the fact that a proxy server must be built specifically for each application protocol, that application gateways (i.e., circuit-level and application-level gateways) are notoriously bad at handling UDP-based application protocols, and that it is necessary to know the application protocol in order to code and set up a proxy server.

^[15] For example, in large organizations, training users may be harder than modifying an application.

^[16] As of this writing, the IETF has made the RADIUS protocol a draft standard.