explorermag.com star rating

Gauntlet has a long and venerable pedigree in the Unix environment, and has recently made the move successfully to the NT platform too.  In general terms, it can be considered that there are essentially three commonly-accepted firewall architectures: pure packet filtering, stateful inspection, and proxy server. With Gauntlet, Network Associates has introduced a fourth, called Adaptive Proxy (patent pending), supposedly providing the best of both stateful inspection packet filter and proxy server firewall technologies.

Adaptive proxy

The idea behind Adaptive Proxy is that the firewall dynamically adapts packet flow between the application proxy and dynamic packet filter layers based on the session state. When security requirements are high, more processing takes place at the application proxy layer; when security requirements are low, more processing takes place at the packet filter layer.

Theoretically, stateful inspection is capable of examining up through the application layer, but in practice, this is extremely difficult to do at layer 2/3, which is where the inspection engine is inserted in the stack. However, application constructs - for example an FTP command - are not guaranteed to be contained in a single packet. So the stateful inspection code must now be concerned about collecting packets until the entire application construct is present, and none of the packets can be forwarded until the entire FTP command is present and examined. Typical stateful inspection firewalls still provide application proxies to be used when application constructs must be examined. If you want to allow FTP GET’s and deny FTP PUT’s in these firewalls, for example, you must direct the traffic to the FTP proxy.

This is one of the key differences between the stateful inspection and Adaptive Proxy architectures. With stateful inspection there is no interaction between the application level proxy and the kernel code, so stateful inspection firewalls must make a decision to handle everything at layer 2/3 or everything at layer 7. The Gauntlet Adaptive FTP Proxy (the only proxy to include this technology at present) does not have that limitation. It can handle the FTP control connection at layer 7, and then decide to handle the data connection at layer 2/3. If the Proxy sees a problem somewhere, it can communicate with the packet filter and terminate the data connection. This decision is made by the proxy for each and every connection, and provides an ideal balance between security and performance without compromising on security at all. It is also possible to enable or disable the adaptive proxy feature for FTP if required.

Installation

Installation is relatively straightforward, but there is more manual "hardening" required with Gauntlet than with some other NT-based firewalls. Much of this could be avoided if Gauntlet employed a more rigorous automatic hardening procedure on the underlying OS.

One of the nice features of the installation, however, is that extensive checking is performed to ensure that all the necessary patches and hot fixes have been applied, and that you have done some basic security work of your own, such as renaming the Administrator account amongst other things.

Management

The firewall management station interface is very easy to use. The management station is provided as a Win32 application on the NT platform and is primarily designed to run locally on the firewall. By employing file sharing on the firewall it is possible to run the management GUI from another machine on the network, thereby allowing the use of a single GUI to control several firewalls.
The new MMC-based management console shipping with CyberCop Monitor will eventually provide a single, consistent interface for the whole of the Net Tools suite – including Gauntlet – and this will be available in a future release.

Configuration

Policy and rule definition is not quite as intuitive as some of the competition, though once you get used to the Gauntlet concepts it is no more difficult to define your security policies than any other firewall. You begin by specifying which of your interfaces are inside, outside or DMZ (called the "Service Net" in Gauntlet), and which are going to use Network Address Translation (NAT). Illegal Network Address Translation (INAT) is a new feature for this release providing for the use of illegal IP addresses internally which may duplicate legitimate IP addresses on the outside of the firewall. Next, the administrator will define one or more policies which can later be applied to a range of IP addresses for fine-grained control. The default Gauntlet configuration includes two policies labelled trusted and untrusted, and these are adequate for many basic installations.

When creating a policy, the administrator defines which proxies are enabled and which are disabled. As you would expect, there is a wide range of proxies available including FTP, HTTP & HTTPS, POP3, SMTP, Telnet, H.323, LDAP, Microsoft SQL, NetShow, NNTP, PPTP, Oracle SQL*net, RealAudio, StreamWorks, Sybase SQL, SNMP and VDOLive.

There is also the ability to define your own custom proxies if required though this is limited to providing little more than a port and a range of source addresses. This "Plug" proxy is still more secure than simple packet filtering, however, since it does not allow direct connections to be established through the firewall. Each of the proxies has its own configuration screen allowing a certain amount of customisation. For instance, for the HTTP proxy you can specify to which server and port on your DMZ requests from the untrusted network should be handed off. The HTTP proxy also provides for Java and ActiveX blocking, virus scanning and URL filtering. As well as allowing the use of commercial URL filtering services, it is also possible to create your own list of destination addresses which should be denied to users.

The SMTP proxy provides a link between internal and external mail hubs, but no SMTP server on the firewall itself. Anti-relay, anti-spam and virus scanning capabilities are all featured in the SMTP proxy. Split DNS is available, and there are a number of options for DNS configurations.

Each policy can specify whether or not authentication is required, and major authentication systems, such as Security Dynamics SecureID, Radius, and Bellcore’s S/KEY are all supported, in addition to the usual NT domain authentication and reusable passwords. Authentication mechanisms can be determined on a per user basis if required.

As proxies are enabled and configured, a corresponding set of packet screening rules is also created. These can be modified or extended using the Packet Screening tab in the Gauntlet Firewall Manager. The Packet Screening dialogue box is typical of most firewalls and is almost certain to frighten off anyone who does not know firewalls intimately. Given the fact that most sites will use proxies exclusively, however, exposure to this box should be kept to a minimum. When creating or modifying packet filters, the administrator can choose a protocol from a drop down list or specify the protocol number exactly. Next, the interface is chosen (inside, outside, DMZ, or any) and the action of the filter is specified (deny, forward with reply, forward without reply, or absorb).

Deny and forward actions bypass the proxies altogether, whereas the Absorb action ensures that packets are processed by the corresponding proxies on the firewall. It should be noted that packet screening logging information is not as extensive as with proxies. The final parameters to configure are the source and destination address(es) and port(s).

Once configured, policies can be applied to a range of source addresses using Policy Maps. By default the "trusted" policy is applied to internal addresses and the "untrusted" policy is applied to all external addresses. It is possible however, to implement very fine-grained control by creating very restrictive (or open) policies and apply these to individual addresses and proxies if required.

Reporting

Gauntlet’s logging and alerting capabilities are extensive and amongst the best we have seen. Alerts can be configured for a limited range of events such as port scans, denied packets, source routed packets, spoof attempts, broadcast packets, and so on. There are no alerts for the more common attacks, however, such as Ping of Death, LAND, or SYN Flood. The main reason for this, however, is that NAI provides integration with CyberCop monitor, the intrusion detection part of the Net Tools suite.

Log files can be rotated daily or weekly, and old files can be deleted automatically, with the age set by the administrator. Exception reports can also be generated at regular intervals, and both exception and detailed log reports can be viewed on-line in the Firewall Manager or e-mailed to the administrator. A Log Monitor facility also provides a real-time view into the logs as things happen.

Verdict

Although we would like to see more automatic hardening of the OS during installation, once configured correctly Gauntlet for NT performs well, passing all of our penetration tests with flying colours. The only downside we could see was the management utility which is essentially designed to run locally on the firewall host. By sharing drives on the firewall, it is possible to manage remotely, but this is neither the most secure nor the most scalable solution. The move to the new MCC-based management console in the next release will be most welcome.

Gauntlet combines the security of a proxy server firewall with the speed of a packet filter, whilst eliminating some of the shortcomings of pure stateful inspection products. The innovative Adaptive Proxy architecture provides a good balance between security and performance, and the ongoing integration with the rest of the Net Tools suite will provide a good framework for your enterprise security needs.