How do I configure nmap to verify my firewall is performing stateful packet inspection?

Question

As part of a compliance audit, I need to run a routine scan that verifies that our firewalls are performing stateful packet inspection on incoming packets. I have a dedicated server outside our network, on which I can run nmap or whatever software I need to, and scan the external port of our firewall.

The compliance audit manual says I should "run NMAP on all TCP ports with “syn reset” or ”syn ack” bits set", and that a response means 'packets are being allowed through even if they're not part of a previously established session'

What are the nmap switches I need to scan a range of IP addresses - in this case a single /28 subnet - and report on which ports are open and whether the firewall is performing SPI?

Server is Windows 2008; nmap version 5.21 is installed and working.

Answer 1

The flag for SYN ACK scans is -sA. scanning all ports is -p- 192.168.0.0/28 will scan for the obvious subnet. You may want -vv to see more details

The following command:

nmap -sA -p- 192.168.0.0/28 -vv

should work.

Answer 2

The option -sA is a good approach for this. Though the better way to know, if your firewall it's performing stateless or statefull filtering, is by seeing the conf file or the configuration in general.

A way to achieve this with nmap would be this: First do a -sS (syn scan) scan on all ports and see what ports are filtered. Then perform an -sA (ack scan) scan and if the same ports received the result unfiltered it's most likely your firewall not performing statefull filter.

Answer 3

This is all, more or less, in the nmap man page. Read about -sA and --scanflags and you should be able to figure it out.

Perhaps I was too brief here. Apologies.

Along with what was in the second answer you can use the --scanflags argument to set whatever flags you want - for "syn reset" you would use --scanflags RSTSYN. If you also specify -sS (to do a "syn scan") you'll have the responses interpreted correctly, with nmap interpreting no response as a closed port, which I think is what you want.