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 1 is a sample of a typical firewall policy for Web service on port 80.

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

Exhibit 1: Firewall Policy Sample

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?

Auditing Remote System Administration

Generally, administrating a network consists of updating user accounts, examining logs, establishing and maintaining standard configurations, and installing and updating software. Administrators perform these tasks from either the location of the workstation or server or from a remote location. For the administration team who has several hundred servers and several thousand workstations, handling these tasks remotely is the most effective and efficient way of doing business.

Here are a few considerations that should be part of the auditor's program in systems with remote configuration capability:

• Ensure that the system accepts administration commands from only an authenticated administrator. Client systems must use strong authentication and traffic encryption mechanisms. Under no circumstances should the administrator send her password in clear text to the system on which she is going to work. The only logical exception for transmitting the user password in clear text is the use of one-time passwords transmitted from the administrator and accepted by the target system.

• Auditors must ensure that the system permits administration to take place from the authenticated host only. It is important that the system receiving the administrator's attention authenticates her identity through means distinct from IP addresses or DNS names, as attackers can easily spoof (falsify) such information. In the case of UNIX, using an authentication tool such as secure shell, SSH, is recommended. In other cases, establishing a VPN, Virtual Privacy Network, where the identity of the administrator is assured and the computer traffic is encrypted through a tunnel, is also highly recommended.

• Auditors must ensure that all administration tasks are operating at the minimum privilege necessary. Administrator tasks should only be performed at minimum privilege levels and not higher. It is a wise consideration to review the separation of duties among administrators so privilege levels are restricted to just a few employees. Of course, the size of the operation will generally dictate the number of privileged individuals. This procedure eliminates risks in having a single point of failure with one administrator.

• Auditors must ensure that administrator information cannot be intercepted, modified, or read by attackers. Mechanisms such as encrypted traffic or VPNs will go a long way ensuring that traffic travels between the administrator's system and the system being serviced in a private and unaltered fashion. If the administrators' communication packets can be read by unauthorized persons, not only does this pose a serious risk to the target system, but this information could be used to attack other systems.

• Auditors should determine if administrators have created checksums of critical system files before placing the system in a production environment. This will permit administrators to know if important files have been altered, deleted, or created by attackers hoping to corrupt the target system.

Web Application Vulnerability Assessments | Part 1

One of the most attractive business frontiers is E-commerce. For the first time in history, a business can have its doors open to the entire world where users can make purchases with nothing more than their credit cards in hand. Businesses are drawn to E-commerce to disseminate company information, sell products and services, provide customer service, and gain a competitive advantage. Most organizations with a presence on the World Wide Web have installed preventive and detection controls in the form of installing DMZs, firewalls, and intrusion detection equipment, and hiring competent employees. Senior managers are surprised at what an attacker can do with a Web-browser and a little creativity.

Auditors must be aware there are logical steps in reducing risks, but the majority of vulnerabilities are found in faulty programming, misconfiguration, and absent systems monitoring.

Auditors must be aware that risks are controlled by:

• Knowing the organization's critical assets

• Knowing threats and vulnerabilities

• Implementation and compliance with policies, procedures, and standards; primary concerns include but are not limited to:

  • Change control management

  • Code development and maintenance

  • Quality assurance testing

  • User acceptance testing

• Effective and continuous audits

• Continuing risk management

HTML Examination

As a logical first step, auditors should carefully examine the HTML, HyperText Markup Language, composition of the organization's Web site. Attackers examine the Web page coding as one of their first steps to gaining as much knowledge as possible about their targets. Basically, auditors should download all the pages comprising the organization's Web site and examine the HTML coding. Often there are valuable programmer comments, passwords, telephone numbers, names, contractor's information, and business addresses, commonly placed within the HTML. For example:

 

 

 <BODY> BGCOLOR = "#0000FF" TEXT = #FFFFF">

 

 

 

 San Diego, CA, XXX-555-1234 or e-mail me at alicedoe@ABCWebDe-

 sign.com — >

An examination of this Web page HTML reveals the XYZ Corporation is using an outsource Web design firm, and the page designer has listed her name and contact information. This information could be very useful to an attacker who was interested in doing a bit of social engineering with Alice Doe or her employer.

Testing for Indexed Directories

Auditors should obtain a list of the indexed Web page directories. The manual process is a slow one, where the browser is used to request specific directories. For this reason, it is more expeditious for the auditor to obtain a list of indexed directories from the Web page administrator. However, if a true outside view is sought, the auditor can deploy her browser in this fashion (http://www.xyzcorporation.com/images).

If the browser returns the images directory, it is important for the auditor to examine each and every file related to the Web site. More than once, auditors have discovered files that were not innocent files.

Experience Note

While conducting an audit of a client's Web site, the auditor began to survey the files accessible from the URL address line of the browser, using the format of www.xzycorporation.com/files. After downloading the files, it was discovered that one of them contained personally identifiable employee information.

Web Server Examination

Auditors may frequently access a company's Web site and determine the presence of specific Web servers. In UNIX and Windows environments, auditors may use the telnet client. By requesting a bogus file, the server file returns an error message and often the Web server will be correctly named. With this knowledge, an attacker merely researches the Internet for known vulnerabilities and executes them. For example:

 # telnet www.xyzcorporation.com 80

Trying 275.xxx.xxx.xxx

Connected to

XYZCorporation.

Escape character is ^

GET/no-such-page.html HTTP/1.0 (At this time the auditor presses

the Enter key twice)

HTTP/1.0 error 404 Not Found

Server: IIS-1.0 (This is the Internet Information Server version

1.0)

Content-Type: text/html

Content-Length: 295

Another useful tool for auditors is found at the Web site www.netcraft.com. This tool is useful whether Web sites are SSL, Secure Sockets Layer, enabled. By completing a few entries, the netcraft tool will display information about the particular Web site of interest including the Web server and operating system.

Experience Note

It is possible that savvy administrators have changed the banners in their server responses, so it is beneficial to verify the information before listing it as a possible finding.

Although this is not considered a high-risk vulnerability, but there are many advantages in concealing system information from attackers. Attackers using techniques to identify the Web server and its version will browse the Internet in an effort to obtain vulnerability information that can be used to exploit the server. So, if they do not have accurate information, they must resort to another means to identify the Web server. It is not a perfect remedy. Efforts to conceal information will often discourage the casual attacker but probably will not dissuade the more-motivated ones.

In a Window's environment, the HTTP server field may be edited via a hex editor in the W3SVC.DLL file and in a UNIX environment, the TCP/IP stack may be changed following the instructions at http://ippersonality.sourcefourge.net. It is suggested that the Web server response should be changed to reflect something nonsensical such as Vital O/S 2003.

There are many advantages in the practice of security through obscurity. Auditors have a variety of tools available when mirroring a Web site. The advantage of mirroring a Web site is that auditors can view it at their leisure and conduct an in-depth review of the HTML as well as its construction. There are Web site mirroring tools at www.webstripper.net, www.esalesbiz.com/extra, and www.softbytelabs.com.

Web site mirroring software will generally follow all links on a Web site and copy discovered files to the auditor's hard drive. In configuring them, rules can be set limiting the software to specific domains or preventing downloading certain file types.

Experience Note

WGET is a UNIX tool to mirror Web sites and may be found at http://wget.sunsite.dk.

Once a Web site has been downloaded, the auditor can open the pages in a simple text editor application, such as Notepad or Vi, and review the HTML content. Auditors should review coding for e-mail addresses, names, addresses, passwords, and other information useful to an attacker.

Accidental Error Messages

It is not unusual for Web servers to mishandle unanticipated user input. They fail to adequately address incorrect input and frequently provide verbose error messages that can provide valuable information to an attacker. For example, if a user incorrectly entered her user name information, the system might respond with an error message such as We were unable to find an account for this user name, click here to enroll. If the user inputs an incorrect password, the system might respond with an error message such as You have entered an incorrect password, you can reset it by clicking here.

Attackers can use overly informative error messages to either launch a denial-of-service attack or attempt to engage a brute-force attack against the password entry. A more appropriate error message is one similar to: There has been a user error; please provide the correct input. Auditors must be mindful that authorized user logons should never be the same as the user names used by the organization's e-mail naming conventions. From an attacker's point of view, the e-mail user naming convention being the same as the user name logon is having half the problem solved for a successful attack.

Some Web sites permit an unlimited number of failed sign-on attempts without being locked out. The vulnerability in this flawed practice is that user accounts can be compromised via brute-force attacks targeting the Web site's password entry.

Brute-force attacks are either manually or automatically performed where alphabetical and numerical combinations are tried as data entries to gain entry. From a preventive control stance, the sign-in policy should be that the user is locked out for a specified time after three failed sign-on attempts.

Experience Note

Remember, even this policy is not without a threat potential in that an attacker can target the sign-on with incorrect data entry and lock out a legitimate user when she attempts entry. Having a viable and acceptable user reactivation policy is an important aspect of this preventive control.

There is a useful password-guessing tool to be found at www.tlsecurity.net/windows/cracker/webcracker.htm. This tool will automatically brute-force passwords in HTTP basic authentication and form-based authentication. Auditors should attempt to gain entry through brute-force methods as a means of testing entry security.

Another method that may have some success in defeating brute-force entry tools is to avoid direct linking to the sign-on function. For example, Web pages found behind the sign-on function should have a referrer field where the originating Web page of the user is checked against the allowed Web page URL, uniform resource locator.

Another method defeating some attacks is the error message, "inactivity timeout." This action causes the user's session to be terminated after a predefined period of inactivity. Auditors may test and verify this procedure by opening a Web page session in a sensitive area such as an E-commerce site where financial or personal information is collected. The server should terminate the session after predetermined period of user inactivity. This step prevents someone from hijacking the user's session.

More Unexpected User Input

There are a variety of ways that user input can be different from what was anticipated by the Web page developers. The size of the input can be too large, or too small. The input's content can be inappropriate in that alternate characters or executable scripts may be used causing the server to execute the input. Developers should incorporate user input screening in their programming routines. These are the types of input that should be filtered:

• Metacharacters are special characters that represent something other than what they are themselves. For example, the ; (semicolon) is a command separator and the ? (question mark) is a match for a single character.

• HTML delimiter characters such as "<" and ">".

• Path redirection such as "/../" or ".." indicate the user is attempting to access the directory structure outside the Web server's Web page. These are known as regular expressions and must be screened before being processed by the server.

Experience Note

User input must always be screened with all improper input denied.

Overflow Vulnerabilities

Improperly validated user input to the Content-Type header can cause a buffer overflow condition. As a result of nonvalidated user input, excessive data copied onto the data stack can overwrite critical parts of the stack frame such as the calling function's return address, potentially permitting remote code execution with root privileges on the Web server. It is important for auditors to determine if user input is checked for correctness and any input other than the expected input merely returns an error message.

Additionally, it is important that not only user-supplied input is screened and verified, but everything coming from the user's browser to the Web server should be filtered. Users can put executable code within the URL address and without proper filtering, it is possible that user input may be executed by the server.