Inside-Out Testing with nmap and iplog

Inside->Out Testing with nmap and iplog

Another way to test what can come in, or probably more interestingly, what can go out through a firewall is to use a combination of nmap and iplog. nmap (www.insecure.org) is a very popular userspace port scanner that comes bundled with most Linux distributions these days. iplog (http://ojnk.sourceforge.net) is a userspace port connection logger. You also could use iptables/netfilter rules to log these connections, but for the sake of testing, using iplog as an independent method for collecting diagnostic information is preferred.

Figure 10.1. nmap INSIDE->OUT scan with iplog.

To test your outbound rules, you will need two systemsone behind your firewall running nmap and one on the outside running iplog. The idea here is that you're going to do full 65536 port TCP/SYN/FIN/UDP scans through your firewall to see what it allows outbound and log these connections on the iplog host. You will want to use this test method whenever you need to verify that you are filtering outbound connections successfully. (A very important test!)

The first system is your scanner system running behind your firewall, which we will call Host-A. The second system is the iplog system, Host-B.

Host-A:

This system will specifically need to be physically connected into the network on the same segment(s) containing the systems that you are testing your rules against. This is due to the nature of iptables/netfilter allowing you to assign rules based on the firewall's interface. Try and make sure that this system is as close to the "real thing" (a web server for example) as possible. Or barring that...use the real thing! In this first example we'll assume our scanner system is a Redhat 9 web server called Host-A, sitting on the DNAT DMZ segment. From this system, we will perform our port scan against the system with Host-B on the opposite side of the firewall. From Host-A we will execute six types of test scans, a three-way-handshake tcpopen() scan, a SYN only scan, a FIN only scan, a NULL scan, an XMAS scan, and a UDP scan. The following is the syntax of the tcpopen() scan:

TCP Open (three-way handshake)

nmap -sT -P0 -p 1-65535 Host-B

SYN scan (sends the SYN packets only)

nmap -sS -P0 -p 1-65535 Host-B

FIN scan (sends the FIN packet only)

nmap -sF -P0 -p 1-65535 Host-B

NULL scan (sends TCP packets with NO flags set)

nmap -sN -P0 -p 1-65535 Host-B

XMAS scan (sends TCP packets with the X flag set)

nmap -sX -P0 -p 1-65535 Host-B

UDP scan (sends UDP packets only)

nmap -sU -P0 -p 1-65535 Host-B

ICMP scan

nmap -sP Host-B

Note

The -P0 flag instructs nmap NOT to use an ICMP or TCP ping to determine if the remote host is active. This ensures that your scan will work regardless of whether it is possible to ping or connect to a service on the remote system; otherwise, if ICMP were not allowed, nmap would exit, thereby ruining the value of this test. All we care about is the data!

Host-B:

This is your logging system, which should catch all the packets your firewall is allowing to pass through its rules. For this example, we will assume that Host-B is a Redhat 9 server on the Internet with no filters or proxy servers other than the firewall being testedbetween it and Host-A. This system is running iplog v 2.2.3, with the following options:

iplog -D -F -P -S -b -d -f -detect-syn-scan=true -n -p -w 

Table 10.1. Options

-D	Logs the destination of traffic.
-F	Logs UDP scans.
-P	Log ICMP ping floods.
-S	Log smurf (These are attacks that involve pinging a system with a broadcast address in the response field. We're not testing this directly, but it comes in handy when playing with the mangle features in iptables.)
-b	Log bogus TCP flags.
-d	Ignore DNS traffic (from the local system, specified in /etc/resolv.conf).
-f	Log FIN scans.
--detect-syn-scan=true	(This keeps iplog from being overwhelmed if you're testing something like SYN flooding through the firewall.)
-n	Log NULL scans.
-p	Log port scans.
-w	Log the IP along with the hostname.
-t	Log traceroutes.
-x	Log Xmas scans.
-y	Log fragment attacks (ala fragrouter).

Once running, iplog will default to dumping its data to syslog on our Redhat 9 systemthis is the logfile /var/log/messages.