Port address translation is utilized by most proxy firewall products. When PAT is used, all outbound traffic is translated to the external IP address used by the firewall, in a way similar to hiding NAT. Unlike hiding NAT, the external address of the firewall must be used. This cannot be set to some other legal value.
The method for dealing with inbound traffic varies from product to product. In some implementations, ports are mapped to specific systems. For example, all SMTP traffic directed at the firewall’s external interface (which has a destination port number of 25) is automatically forwarded to a specific internal system. For a small environment, this limitation is rarely a problem. For large environments that operate multiple systems running the same type of server (such as multiple mail or FTP servers), this deficiency can be a major obstacle.
In order to get around this problem, some proxy servers can analyze data content in order to support multiple internal services. For example, a proxy may be able to forward all inbound SMTP mail addressed as
[email protected] to one internal mail system and mail addressed to [email protected] to another. If you have multiple internal servers running the same service, make sure your firewall can distinguish between them. I’ve seen more than one organization that has been bitten by this limitation and has been forced to place servers outside the firewall. This is like walking to work in a blizzard because the shiny new Corvette you just purchased got stuck in a half-inch of snow.
Firewall Logging and Analysis
While a firewall’s primary function is to control traffic across a network perimeter, a close second is its ability to document and analyze all the traffic it encounters. Logging is important because it documents who has been crossing your network perimeter—and who has attempted to cross, but failed. Analysis is important because it might not be readily apparent from a casual view of the log which incidents are attempts to actually cross your perimeter, and which are investigations for openings in the “fence” in preparation for a future attack.
What defines a good firewall log? Obviously, this comes down to personal preference. There are, however, a number of features you should consider:
The log should present all entries in a clear, easy-to-read format.
You should be able to view all entries in a single log so that you can better identify traffic patterns, although the ability to export the log data to an analysis tool would be of even greater value.
The log should clearly identify which traffic was blocked and which traffic was allowed to pass.
Ideally, you should be able to manipulate the log, using filtering and sorting, to focus on specific types of traffic, although this feature is best suited to an analysis tool.
The log should not overwrite itself or drop entries based upon a specific size limitation. You should be able to securely view logs from a remote location.
The logging software should have some method of exporting the log to at least one common format, such as ASCII text (preferably with some kind of delimiter). This allows the data to be manipulated further within a reporting tool, spreadsheet, or database program.
Kind of a tall order, but all are important features. It is very rare that an attacker will gain access on the very first try. If you schedule time to scrutinize the logs on a regular basis, you may be able to thwart an attack before it even happens. A good logging tool will help.
For example, look at the log viewer shown in Figure 5.13. This is FireWall-1’s log viewer, and it does a very good job of fulfilling the criteria we have listed. The log is easy to read, easy to follow, and can even be reviewed remotely from an alternate workstation through a secure session. The Select menu option even lets you select different filtering and sort options.
Figure 5.13: Firewall-1’s log viewer
Look closely at the services reported in each of the packet entries in Figure 5.13. See anything strange? Our source system Herne appears to be attempting to connect to Skylar on every TCP service port sequentially. Our display starts at service port 20 (FTP-data) and continues one port at a time to port 35. This is an indication that Herne is running a port scanner against Skylar in order to see what services are offered.
In contrast to this would be a log viewer such as the one used with Secure Computing’s BorderWare firewall. This firewall maintains no less than six separate logs. While this makes tracking a particular service a bit easier, it makes tracking a specific host far more difficult. You would need to use a third-party program in order to combine the information and get a clear look at what is going on. Also, while the log in Figure 5.13 can be exported and saved using a simple menu option, BorderWare requires you to enable FTP administration and manually transfer the file to your local machine.
Tip Keep the flexibility of the log interface in mind when you are selecting a firewall product. While the firewall’s ACL will typically be set and require very few changes, you should plan on spending quite a bit of time reviewing your firewall logs and analyzing traffic flow.
Virtual Private Networks (VPNs)
Virtual private networks (VPNs) are considered a feature that sets a high-end firewall apart from the rest of the crowd. VPNs allow authenticated and encrypted access to an intranet through the public Internet. This means that instead of expensive point-to-point communication, LANs or mobile users can use inexpensive ISPs to
communicate with their internal organization’s resources.
However, simply providing basic VPN service is not enough. You’ll need to determine what configuration, management, and encryption options your firewall provides for VPNs. In some cases a dedicated VPN solution that integrates into your firewall might provide the best results.
Intrusion Detection and Response
The ability of a firewall to notify an administrator while an attack is taking place should also enter the purchase and deployment decision. In the case of the high-profile DoS (Denial of Service) attacks that took place in February of 2000, the ability of the firewall systems to instantly notify the IT staff of unusual network activity allowed several of the sites to return to functionality within the hour.
Future firewall systems promise a degree of cooperation that would allow entire networks to respond to and reconfigure themselves in the event of an attack. While experts feel that the technology for this level of proactive monitoring and response is feasible, challenges remain. To be truly effective, such a system would require the cooperation and communication of all affected parties, even if this involved distinct (or even competitive) businesses and organizations. Assuming such a level of communication and integration existed, the anonymity of an attacker would become much more difficult to maintain, and the effects of an attack would be neutralized much more quickly.
There are already formal and informal groups that monitor and report intrusions, as well as virus, worms, and Trojan horse infections (such as the “I Love You” worm in May of 2000). However, the reporting mechanisms are, more often than not, manual, requiring an “eyes on” approach. Ideally, reporting would be automatic, standardized, and provide intelligent systems with enough information to allow for automatic or proactive
Integration and Access Control
Firewalls are integrating more and more with other network systems and services. This trend promises to simplify administration, reduce complexity, and increase TCO (Total Cost of Ownership), as firewalls no longer have to duplicate pre-existing network infrastructure.
Examples of integration include directory and authentication services that eliminate redundant user account information and allow customizable authentication schemes. Two industry standards that provide these services are LDAP (Lightweight Directory Access Protocol) and RADIUS (Remote Authentication Dial In User Service).