Firewall Auditing: First We Build an Impregnable Barrier, then We Punch Holes in It

---

If administrators were to name the hardware/software device that is the most critical for system security, they would most likely name the firewall. Of course, firewall architects will swear their equipment and software will stop all illicit intruding traffic and possibly rampaging elephants.

Barbarians at the Wall

In the firewall assessment process, it has to be determined exactly what it is the organization is expecting of its firewalls and that the firewalls are performing at that level of expectation. Assessing the firewall is done with a copy of the organization's policies in hand before verifying the firewall's rulebase. Basically, auditing a firewall consists of two steps. The first step consists of testing the firewall itself and ensuring it is secure. The second step is testing the firewall's rulebase ensuring that only authorized traffic is permitted to pass through it. After all, the firewall's purpose is to deny entry to all traffic, except traffic that is specifically enumerated as being permitted to pass in the rulebase.

These are steps that should be included in the firewall audit program:

• Demonstrate that the firewall is physically secure having very restrictive access. No one should have access without a very specific reason to the machine where the firewall is located. In other words, is the firewall secure from everyone except those having a need-to-know?

• Is remote access permitted to the firewall? Is there a very serious need for remote administration? If not, is the firewall accessible from terminals outside its physical location, and why? Is the firewall accessible only from the physically attacked console?

• Is the operating system used to support the firewall fully armored? Have all unnecessary hardware and software features not needed to support the firewall's operation been removed? Does the firewall reside on a machine used for other functions other than the firewall? It is strongly recommended that all firewalls, regardless of their type and configuration, reside on dedicated machines, devoid of other applications.

There are many checklists available for locking down operating systems. The platform supporting the firewall should be a barebones installation with only the features and ports required to support the firewall opened and enabled.

Experience Note 

An auditor was engaged in a firewall audit and asked to review the system supporting the network firewall. The administrator admitted the auditor to the secure firewall room and showed her to the computer supporting a proxy service. The auditor noticed a pair of speakers attached to the computer and asked why these were present. The administrator stated she used the computer to listen to music while working in the room. After a closer inspection, the auditor noted the installation of a sound card, supporting sound software, MP-3 software, a media player, and a CD-RW in addition to the already installed CD-ROM. Her audit report reflected her findings.

Auditors may want to scan the firewall ports from internal and external views looking for UDP and TCP open ports. On most correctly configured firewalls, auditors should find few open ports, and auditors should not be able to "ping" the firewall and receive a response.

Experience Note 

Auditors should employ a number of scans, other than the Ping, in their firewall assessment.

Auditors should be aware that many firewalls have open ports as a matter of default installations. For example, in some firewall installations, ports 256 and 258 are open for administration of the firewall by default. All ICMP ports should be closed thereby thwarting an attacker's ability to map the internal system. If administrative ports are required, then a formal policy should reflect which specific ports are to be open and that only specific IP addresses are allowed to connect to them. Obviously, the idea behind the firewall's configuration is to deny all connections except those specifically allowed.

Firewall Rulebase

The goal behind examining the rulebase is to ensure that the firewall is enforcing what is expected of it, any exceptions should be considered a performance gap and finding. Examining the actual firewall policy can be done by assessing the processes allowed to pass denying all others. This can be accomplished by placing a laptop, with a scanning program such as Nmap installed, on the outside of the firewall and attempt to scan a system located on the inside of the firewall. Placing a workstation on the inside of the firewall with and TCPdump, or Windump, installed will allow the auditor to examine all passing traffic and determine if the written firewall policy is reflected in the passing traffic.

Because firewalls may be used to partition segments of a network, it is prudent to scan network segments. For example, if a firewall is connected to the outside open-ended network such as the Internet, a scanning computer should be connected to this outside connection. The scanner should scan the firewall looking for the protected DMZ network segment and test the permitted traffic rulebase. From this point, other network segments can be scanned from the scanning machine's perspective. It is a wise step for an auditor to validate the DMZ rulebase and attempt to penetrate the internal network. This basically determines the probability of an attacker compromising the DMZ, containing such services as DNS and Web services, and gaining access to the protected internal network. It is important for auditors to note that if they have the organization's policy in one hand and their scan results are different, then they have an item requiring quick resolution. If the auditor discovers open doors in firewalls, this is cause for immediate and positive action before attackers can launch against these potential exploits.

Before merely listing the open ports and unnecessary services, auditors should assess the degree of risk they pose to the organization. By doing this, the auditor extends her view beyond the firewall and begins to gain visibility into the internal network.

Experience Note 

Ranking vulnerabilities according to their risk is part of professional due diligence and good procedure. It is the auditor's goal to identify the existence of system vulnerabilities. The system should not be limited to the firewall's function; rather it should extend beyond.

Exhibit 28 is a sample of a typical firewall policy for Web service on port 80.

Exhibit 28: Firewall Policy Sample

Direction	Source Address	Destination Address	Protocol	Source Port	Destination Port	Notes
In	External	Internal	TCP	>1023	80	Request external client to internal server
Out	Internal	External	TCP	80	>1023	Response internal server to external client
Out	Internal	External	TCP	>1023	80	Request internal client to external server
In	External	Internal	TCP	80	>1023	Response external server to internal client

For each of the firewall's permitted protocols, the firewall should have a policy statement similar to the one above where allowed traffic is scheduled with all others being denied passage. There should not be any services for which there are not rules. Exceptions are considered deviations and should be identified as audit report findings.

Look at Logging

After assessing the permeability of the firewalls, take a serious look at firewall logs:

• Did the firewall detect all the earlier scans and were expected alerts made to the appropriate employees?

• What was the extent of the firewall's logging?

• If the firewall did not log all the scans, why did not it?

• How extensive is the logging? Is the logging capability remotely accessible?

• Is the media holding the logs erasable?

• Are firewall logs stored within the interior protected network?

• Has the machine holding the logs been fortified against attacks?

---