How to manage firewall testing using Nmap

So far, in my previous articles on Nmap, we've looked at how the scanner can be used to map and audit a network, as well as track down noncompliant devices and services. But hackers can also use Nmap to obtain a lot of useful information when preparing to attack your network.

In this week's article, I want to look at how to test a firewall configuration's effectiveness. I should reiterate that before running any scans, you should warn colleagues how and why you intend to run the scan against the network -- unless of course you want to simulate an attack to test your incident response policies and procedures!

Nmap includes many features that can be used for circumventing poorly implemented firewalls. It's important therefore to regularly scan your network from outside your perimeter defences in order to see what information it divulges to potential attackers. To make the most of such scans, you need to try to think like an attacker. You should experiment with FTP bounce scans, idle scans and fragmentation attacks -- hacker techniques that exploit network protocols to access ports indirectly and spoof packets. It's important to determine if your firewall configuration can cope with a real life attack.

How to test firewall rules
One of the most important aims of these scans will be to verify and test that your firewall filters and rules are performing as intended. To do this, you need to run a scan to look for ports that appear open to the outside world; then check whether they are filtered or not. A simple Nmap firewall audit scan would be something similar to:

nmap –v –sA –n www.yourorg.com –oA firewallaudit

The Nmap TCP ACK scan (-sA) will establish whether packets can pass through your firewall unfiltered. To speed up the scan, the –n option can be used to prevent reverse DNS resolution on the active IP addresses it finds. I would also use the –oA output option so you create a searchable file as well as an XML file to use for record keeping and reporting. You can use these output files to review the traffic flow through any unfiltered ports and then modify your firewall rule sets where necessary.

One mistake many administrators make when allowing traffic through their firewall is trusting traffic based simply on its source port number, such as DNS replies from port 53 or FTP from port 20. To test firewall rules, however, you can use most of Nmap's TCP scans, including the SYN scan, with the spoof source port number option (--source-port or abbreviated just to –g). By providing the port number, the network mapper will send packets from that port where possible. The following example will run an FIN scan, which will use a spoofed source port number of 25 (SMTP) and save the output to file firewallreport.txt. Now you can see if a particular port is allowing all traffic through:

nmap –sF –g 25 –oN firewallreport.txt www.yourorg.com

Another worthwhile check is to test a firewall's ability to cope with fragmented traffic. Malicious hackers often split up the TCP header over several packets to make it more difficult for packet filters and intrusion detection systems to detect an attack. While fragmented packets won't get past packet filters and firewalls that queue all IP fragments, many devices have queuing functions disabled by default to avoid a drop in performance. Simply adding the -f option will set a scan that uses fragmented IP packets.

When auditing your firewall, option –r will scan ports in numerical order, making it easier to follow the traffic flow when examining the Nmap output files. However, when you're testing the effectiveness of firewalls and IDSes, I would use a randomized port order, which is the default option. You can also randomize the order in which hosts are scanned by setting the --randomize-hosts option (–rH.) The randomization, combined with slow timing options, which we'll look at in a moment, will make any network monitoring devices work hard to detect the scan. Here's an example that could possibly test your network defences:

nmap –sS --scan-delay 500 –f –rH firewallreport.txt www.yourorg.com

Once you have identified any unfiltered ports or other issues, you should review and update your firewall rules to ensure access to all services is controlled and filters and rules are performing as anticipated. If you do make changes to your firewall, rerun the audit scan to ensure your changes have achieved the desired effect. It's also a good idea to run this type of audit scan on a regular basis to ensure your firewall configuration has not been modified unexpectedly.

Nmap includes a variety of timing options that allow you to modify almost every scan aspect. The "scan-delay" option (above) causes Nmap to wait the specified time between each test it sends to a given host.

The default setting keeps a scan going no matter how long it may take to complete, but this can be overridden with the Host Timeout option --host_timeout. The option sets the amount of time a scan will wait before aborting a scan, giving up on the host, and moving on to another IP address. This setting can be useful when scanning network devices over a slow connection.

In my next and final look at Nmap, I'll be exploring the uses of different timing options a little further and how the Zenmap graphical user interface can make using Nmap even easier.