Verification of Perimeter Components

In the "Accomodating Change" section of Chapter 19, "Maintaining a Security Perimeter," we described the need to thoroughly test hosts, devices, and applications before deploying them on a production network. Components of the security perimeter should undergo such testing as well, both in the lab environment before deployment and as part of your vulnerability assessments. This part of the assessment focuses on ensuring that access restrictions implemented by your security devices are properly implemented, even if they do not allow access to a vulnerable service on your network. To test whether access controls are properly implemented, you need to be intimately familiar with your security policy so that you can locate deviations from it.

In this section, we concentrate on verifying controls that are implemented by a border firewall to demonstrate what's involved in testing the configuration of a perimeter component; however, the same techniques should be used to verify proper application of the security policy on any other device that restricts the way traffic moves across your network.

As a security analyst who is about to audit the security policy implemented by your firewall, you need to make sure a plan is laid out to systematically validate mechanisms that control components of your infrastructure. You will need to verify that rule sets and ACLs have the intended effect. For each rule in your firewall, whether it allows or blocks traffic, you need to verify that network traffic travels as expected.

Preparing for the Firewall Validation

Your border firewall is primarily responsible for controlling the flow of traffic between the internal network and the Internet. The firewall's assessment should verify that network traffic complies with the intent of the firewall rules. For example, if the firewall rulebase is configured to allow SMTP traffic from the Internet to a mail server that is located in a screened network, you will attempt to connect to the mail server from the Internet to guarantee that traffic passes through the firewall as defined in the rulebase. You must further validate that only SMTP traffic from the Internet is allowed to pass and that all other traffic is rejected by the firewall and logged accordingly. In the event that you are able to connect to the mail server from an unapproved network, you must inspect the firewall configuration to determine the cause of the deviation from your security policy.

Figure 22.10 provides an example of a common network configuration, which we will use to demonstrate how to perform an assessment of the firewall. To test how traffic from the Internet traverses the firewall, we have set up an assessment station outside of the organization's network. We have also configured listener systems to see what packets are able to pass through the firewall. The assessment station is equipped with network and the vulnerability scanners we discussed in the "Network Service Discovery" and "Vulnerability Discovery" sections of this chapter. Listener systems are configured to monitor network traffic in promiscuous mode on internal subnets. The listening systems are configured with packet-sniffing software, such as Tcpdump (http://www.tcpdump.org/). Another graphical alternative is Ethereal (http://www.ethereal.com/), which is available for free and can be used on UNIX and Windows systems.

Figure 22.10. Assessment and listener stations are placed at key points of the network to conduct an internal assessment of the border firewall.

Tip

Although normally used as an IDS, Snort (http://www.snort.org/) can also be very useful for vulnerability assessment. It can be configured on a "listener" station to watch the network for specific patterns and types of traffic to determine whether your defense lines are filtering against such traffic.

Your listener systems monitor packets that pass the firewall and help determine whether access controls succeeded or failed. With logging enabled on the firewall, you can view the log file to determine which packets were accepted or dropped during the audit, but these logs rarely provide as much detail as a listening station that is equipped with a sniffer. To fully audit the border firewall, you must move the assessment station from the Internet to another network segment to validate access controls for each firewall interface.

Verifying Access Controls

To verify that the firewall properly enforces access controls, you can utilize a scanner, such as Nmap or SuperScan, to perform the following tests:

• Verify that the firewall service ports that should be explicitly blocked are indeed blocked and that approved traffic is allowed to pass.

• Verify controls over broadcasts and other types of discovery traffic.

• Verify that authorized firewall management stations are the only devices allowed to establish an interactive session with the firewall.

• Verify that only authorized traffic can cross boundaries of internal subnets.

Your audit of the firewall's configuration begins by attempting to access systems and services that are behind the firewall.

Traffic Restrictions

During the external assessment, you used network scanners, such as Nmap, to determine what devices can be accessed from the Internet. We use the same process, depicted in Figure 22.11, to ensure that unauthorized traffic is blocked by the firewall and that approved traffic is allowed to pass. The arrows represent the inbound discovery requests from the assessment station directed toward the devices located in the screened network.

Figure 22.11. The assessment station issues discovery packets in an attempt to reach servers located behind the firewall.

To use Nmap for determining whether the firewall blocks ICMP echo request traffic, you can use the sP parameter to perform an ICMP scan, like this:

 # nmap sP -PE 192.168.1.1-254 

If your security policy prohibits inbound ICMP traffic, the firewall should block this scan as the assessment station attempts to incrementally scan the 192.168.1.0/24 network. To ensure that the firewall blocked ICMP packets, you can check firewall logs, as well as sniffer logs, on the listener system.

Next, you can attempt to verify that your firewall drops all packets that are not destined for approved network devices. Nmap can perform such scans using the following syntax:

 UDP: # nmap -sU p 1-65534 IP_ADDR_OF_MONITOR SYN: # nmap -sS p 1-65534 IP_ADDR_OF_MONITOR 

These two scans will attempt to connect to the monitoring system using every possible TCP and UDP port. You will want to try this with several different monitoring systems located on different interfaces of the firewall. Keep in mind that even if Nmap does not report a success, it is still possible that some of the probe packets made it through the firewall. Your monitoring stations should capture these probes, even if the replies from the probes are blocked by the firewall.

You should also try other Nmap scan types to see if your firewall is effective at blocking all discovery efforts. Here are some of the alternative Nmap scans you should include in this step:

• ACK scans (-sA) These often pass through simple firewalls when SYN scans would be blocked.

• FIN scans (-sF) These scans check to see if the flag used to close a TCP session will pass through the firewall.

• NULL scan (-sN) Sends packets with no flags set. These should not normally appear on a network.

• Frag option (-f) Combines with other scan types to create scans that use many tiny fragment packets. Many firewalls cannot properly handle fragments and may allow them through when they shouldn't.

After you have completed all your scan attempts, you will need to view your monitoring station's packet captures to see what got through. Figure 22.12 shows an example of what this may look like. If you detect traffic making it through your firewall that should have been denied, you will need to research your particular firewall to see how to eliminate the holes. Hopefully, this will be as simple as changing the firewall's configuration. If not, you may need to consult with the firewall vendor.

Figure 22.12. An example of some packets that got through the firewall, captured using Ethereal.

Firewall Management

You should also ensure that the firewall itself is well protected. An important part of this is control of the management interfaces used to configure and maintain the firewall. You want to verify that an attacker will not be able to connect directly to the firewall. Generally, the firewall should be configured to only allow connections from your administrative hosts. These administrative hosts should reside on a trusted internal management network. To verify that this is the case, attempt to connect to the firewall using its management console from the assessment station that is located on various network segments. You should also verify that the authentication credentials that your administrators use are strong and the credentials themselves are only passed across encrypted communications channels.

You have analyzed the firewall rulebase and performed an audit to verify that traffic is allowed or denied according to controls that are defined in the security policy. Performing such an internal assessment is critical to locating misconfigurations or vulnerabilities of which an attacker might take advantage. As part of the assessment, you have clearly defined which traffic flows through the firewall. You may also want to apply these tests on other firewalls and routers within your network. Next we will look for other access methods that may expose your network to attack.