Verifying Your Coverage

Performing a simple Nmap scan directed against your firewalled host is a great way to see how effectively your configuration performs. Details on how to use various port scanners can be found in Chapter 2. Figure 13-8 shows a sample Nmap scan against a Linux server hosting HTTPS and SSH—a fairly good, secure combination.

Nmap scan of a fairly secure Linux HTTPS server

Figure 13-8. Nmap scan of a fairly secure Linux HTTPS server

For comparison, Figure 13-9 shows an insecure Windows Server sharing entirely too many ports. It is serving HTTPS, which is nice, but what else? MS RPC? MS Directory Services? NetBIOS Session Service? MS SQL? All of these services regularly have new vulnerabilities announced against them—just offering these services publicly, patched or not, is blood in the water for hackers. These services should never be accessible outside the networks under your control. Remember—every open port on your computer increases your attack surface.

Nmap scan of an insecure Windows server

Figure 13-9. Nmap scan of an insecure Windows server

Performing a packet capture on your firewalled host is also a good way to see whether your host is leaking information you would rather not have released. When combined with a port scan, this is doubly useful because you can watch the scans come in and then see how your system responds. Details on performing packet captures can be found in Chapter 18. See Figure 13-10 for a screenshot of Wireshark in action during a port scan against a system.

Wireshark capture of a port scan against a Linux server

Figure 13-10. Wireshark capture of a port scan against a Linux server

You can see that Nmap by default does an ICMP echo (ping) request first, to which the server responds. If you really want to lock this down, you could block ping and be more secure, but at a cost of inconvenience at the loss of the ICMP protocol. Some of the packets are green, indicating normal packets; in this case, a SYN packet from the scanning system trying to see whether you are running HTTP. Any green-colored packets coming from the system means it responded with an okay to connect reply, which means the port is open—those should be double-checked against your intended policy. Red-colored packets are TCP reset packets, which tell the requestor that the service requested is not available. Even sending these standard replies (or not sending them) can tell an attacker about your security posture.

—Dave Killion