| Previous | Table of Contents | Next |
Circuit-Gateway Firewalls
As discussed previously, application-gateway firewalls receive connections from clients, dropping some and accepting others, but always creating a new connection with whatever restrictions exist whenever a connection is accepted. Although in theory this process should be transparent to users, in reality the transparency is less than ideal. A third type of firewall, the circuit-gateway firewall, has been designed to remedy this limitation by producing a more “seamless,” transparent connection between clients and destinations using routines in special libraries. The connection is often described as a virtual circuit because the proxy creates an end-to-end connection between the client and the destination application. A circuit-gateway firewall is also advantageous in that rather than simply relaying packets by creating a second connection for each allowed incoming connection, it allows multiple clients to connect to multiple applications within an internal network.
Most circuit-gateway firewalls are implemented using SOCKS, a protocol that includes a set of client libraries for proxy interfaces with clients. SOCKS receives an incoming connection from clients, and if the connections are allowed, it provides the data necessary for each client to connect to the application. Each client then invokes a set of commands to the gateway. The circuit-gateway firewall then imposes all predefined restrictions, such as the particular commands that can be executed, and establishes a connection to the destination on the client’s behalf. To users this process appears transparent.
As with application-gateway firewalls, circuit-gateway firewall clients must generally be modified to be able to interface with the proxy mechanism that is used. Making each client aware of SOCKS may not be an overwhelming task because of the availability of a variety of SOCKS libraries available for different platforms. The client must simply be compiled with the appropriate set of SOCKS libraries for the particular platform (e.g., UNIX, Windows, and so forth) on which the client runs.
Circuit-gateway firewalls also have limitations. First and foremost, the task of modifying all clients to make them aware of the proxy mechanism is, unfortunately, potentially extremely costly and time-consuming. Having a common interface to the proxy server so that each client would not have to be changed would be a major improvement. Second, circuit-gateway firewalls tend to provide a rather generic access mechanism that is independent of the semantics of destination applications. Because in many instances the danger associated with specific user actions depend on each application11, offering proxies that take into account application semantics would be more advantageous. In addition, SOCKS has several limitations. Most implementations of SOCKS are rather deficient in their ability to log events. Furthermore, SOCKS neither supports strong access authentication methods nor provides an interface to authentication services that could provide this function.
11Invoking the delete command to delete data in an application that reinitializes all parameter values by retrieving values from a data base not accessible to users every time it is invoked is, for example, potentially not catastrophic. In other applications, however, being able to delete data is likely to be hazardous.
Hybrid Firewalls
Although the distinction between packet-filtering firewalls, application-gateway firewalls, and circuit-gateway firewalls is meaningful, many firewall products cannot be classified as exactly one type. One of the currently most popular firewall products on the market, for example, is basically a packet-filtering firewall that supports proxies for two commonly used TCP/IP services. As firewalls evolve, additionally, it is likely that some of the features in application-gateway firewalls will be included in circuit-gateway firewalls, and vice versa.
Virtual Private Networks
An increasingly popular Internet security control measure is Virtual Private Networks (VPNs), which incorporate end-to-end encryption into the network, enabling a secure connection to be established from any individual machine to any other (Bernstein et al., 1996). At present, this technology is most commonly implemented in firewalls, allowing organizations to create secure “tunnels” across the Internet (see Exhibit 3). Attackers who have planted one or more network capture devices anywhere along the route used to send packets between the firewalls will not gain any advantage from capturing these packets unless they can crack the encryption key, an unlikely feat unless a key that is extremely short in length is used. The chief disadvantage of the firewall-to-firewall VPN is that it does not provide an end-to-end tunnel. In this scheme packets transmitted between a host and the firewall for that host are in cleartext and are thus still subject to being captured. Increasingly, however, vendors are announcing support for end-to-end VPNs, allowing host-to-host rather than only firewall-to-firewall tunnels.
Exhibit 3. A Virtual Private Network
Like any other type of Internet security control measure, VPNs are not a panacea. Anyone who can break into a machine that stores an encryption key can, for example, subvert the integrity of a VPN. VPNs do not supplant firewalls or other kinds of network security tools, but rather supplement the network security administrator’s arsenal with capabilities that were not, for all practical purposes, previously available. With the PPTP (point-to-point tunneling protocol) standard currently being widely implemented in VPN products (usually in firewalls with VPN support capabilities), the task of setting up secure tunnels is at least now much less formidable than it was even recently.
| Previous | Table of Contents | Next |