Each type can be appropriate in varying combinations, depending on the network requirements and design.

Products from these three classes are certified by NCSA as firewalls; for example, 3Com Corp.'s NETBuilder is in the packet-filter class, Cisco Systems' Private Internet Exchange (PIX) is in the address-translation class and Internet Devices' AFS2000 is in the proxy class.

A packet filter can be as simple as a router configured with access lists permitting and denying appropriate packet types. This type of packet filter is configured to allow the specific port number s for the Transport Layer protocols used by applications (see "Protocols By Port," at right).

Packet filters can be configured to allow TCP communication only when they are initiated from the internal network. An address-translation device also can provide packet-filtering capabilities, while hiding the internal network numbering scheme from external users by directly manipulating the address information in the header of every packet. With Network Address Translation (NAT), you set up two address ranges: one for the internal network and one for the external network. The firewall maintains a table that maps the internal to external numbers. When the firewall gets a packet from either side, it references this table and replaces the original address with the corresponding IP address listed in the table.

A proxy server also hides the internal numbering scheme from external use rs, but uses a different method to accomplish this. Proxies are split into application and circuit level. An application-level pro xy server runs two instances of each application used to communicate with Internet hosts.

A proxy server may have two copies each of FTP, HTTP and telnet running--one copy to communicate with the internal hosts and one to communicate with the external hosts. A circuit-level proxy operates in a similar fashion, but at the protocol level. For example, it has one copy of TCP for the internal network and one copy for the external network. Either proxy server type transfers data between the two instances of the application.

The Socks security daemon is commonly implemented as a circuit-level proxy that has enhanced features, such as auditing and alarm notification. Socks was designed for TCP-based client/server applications, using a proxy data channel to communicate between client and server. In a Socks environment, an application client makes a request to Socks to communicate with the application server (by default, this occurs on TCP port 1,080). This request includes the application server address and the user's ID. Socks then establishes a proxy circuit to the application server and relays information between client and server. All data goes through Socks, so it can audit, screen and filter as necessary.

Up to version 4, Socks provided connection request, circuit setup and application data-relay services. With Socks version 5, authentication and support for UDP relay have been added. More information on a good example of the Socks implementation can be found at www.socks.nec.com, which supports RFC 1929 user name/password and RFC 1961 Kerberos 5-based GSS-API authentication.

The downside to Socks is that client applications must be specially coded for Socks or application-level proxies. You face a purchasing dilemma here: If you use applications that communicate through a proxy-type firewall, then applications must be written for it. You may come across applications you want to use that won't work through a proxy, which will p ush you toward packet- or address translation-class firewalls.