Chapter 10: Application-Level Gateways | Internet & Intranet Security

Team-Fly

In this chapter, we elaborate on application-level gateways and proxy servers. More specifically, we introduce the technology in Section 10.1, elaborate on user authentication and authorization in Section 10.2, overview some proxy servers in Section 10.3, and draw some conclusions in Section 10.4.

10.1 INTRODUCTION

Remember from our previous discussions that an application gateway can either work at the transport or application layer, and that one distinguishes between circuit-level gateways and application-level gateways accordingly. Circuit-level gateways have been overviewed and discussed in Chapter 9, whereas application-level gateways are addressed in this chapter.

To clarify the difference between a circuit-level gateway and an application-level gateway, imagine the situation in which the packet filter of a firewall configuration 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 or application layer. The situation is slightly different in either case:

If the application gateway operates at the transport layer, a circuit-level 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., a 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 is a circuit-level gateway, it would not look into the application data it relays. If, however, the application gateway is an application-level gateway, it would be able to 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 executable content and software-driven attacks. This kind of filtering is simply not possible in the case of a circuit-level gateway.

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 we saw in Chapter 9 that the additional steps are hidden from the user and that 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 user procedures or client software:

The customization and modification of user procedures is an obvious approach to implement 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 destination server. An important benefit is that the customization of 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 logon to the proxy server. For organizations that have been using TCP/IP applications for a long time, the corresponding user training may be a time-consuming and expensive process.
The other approach to implement 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 is very seldom easy to accomplish.

Note that both approaches to implement application gateway support have severe disadvantages, as they require customization and modification of either user procedures or client software. Consequently, 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 fact, many vendors have come up with transparent firewall products in the past.

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 users and the clients. We will return to the idea of transparent firewalls when we talk about network address translation (NAT) in Chapter 11.

We will have a closer look at an example in which a Telnet client tries to connect to a Telnet server making use of a proxy server, as illustrated in Figure 10.1. Note that the black rectangle that is part of the firewall represents the Telnet proxy server. Also note the similarity of Figure 10.1 to Figure 9.1. The only differences are that the SOCKS server in Figure 9.1 is replaced with a Telnet proxy server in Figure 10.1, and that the two TCP connections in Figure 9.1 are replaced with Telnet sessions in Figure 10.1. 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 packet-filtering rules.
The Telnet proxy server, in turn, checks the source IP address of the client machine. The connection request is accepted or rejected according to some preconfigured access control information.
In addition to the source IP address check of the client machine, 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 destination 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 destination 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 destination 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.

click to expand
Figure 10.1: The placement and use of a Telnet proxy server.

To properly authenticate the user, the Telnet proxy server must have access to some identification and authentication information. This is generally true for any application-level gateway or proxy server that provides support for user-level authentication (not only for a Telnet proxy server). User authentication and authorization are addressed next.

Team-Fly