Determining Firewall Rules | Nmap Network Scanning (2023)

One helpful feature of the TCP protocol is that systems arerequired by RFC 793 to send a negative response to unexpected connectionrequests in the form of a TCP RST (reset) packet. The RST packetmakes closed ports easy for Nmap to recognize. Filtering devices suchas firewalls, on the other hand, tend to drop packets destined fordisallowed ports. In some cases they send ICMP error messages(usually port unreachable)instead. Because dropped packets and ICMPerrors are easily distinguishable from RST packets, Nmap can reliablydetect filtered TCP ports from open or closed ones, and it does so automatically. This is shownin Example10.1.

# nmap -sS -T4 scanme.nmap.orgStarting Nmap ( https://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)Not shown: 994 filtered portsPORT STATE SERVICE22/tcp open ssh25/tcp closed smtp53/tcp open domain70/tcp closed gopher80/tcp open http113/tcp closed authNmap done: 1 IP address (1 host up) scanned in 5.40 seconds

One of the most important lines in Example10.1 is thenote “Not shown: 994 filtered ports”.In other words, this host has a properdeny-by-defaultfirewall policy. Only those ports the administratorexplicitly allowed are reachable, while the default action is to deny(filter) them. Three of the enumerated ports are in the open state (22, 53, and 80),and another three are closed (25, 70, and 113). The remaining 994 tested portsare unreachable by this standard scan (filtered).

As described in depth in the section called “TCP ACK Scan (-sA)”, the ACK scan sends TCPpackets with only the ACK bit set. Whether ports areopen or closed, the target is required by RFC 793 torespond with a RST packet. Firewalls that block the probe, on theother hand, usually make no response or send back an ICMP destinationunreachable error. This distinction allows Nmap to report whether theACK packets are being filtered. The set of filtered ports reported byan Nmap ACKscan is often smaller than for a SYN scan against the same machine becauseACK scans are more difficult to filter. Many networks allow nearlyunrestricted outbound connections, but wish to block Internet hostsfrom initiating connections back to them. Blocking incoming SYNpackets (without the ACK bit set) is an easy way to do this, but itstill allows any ACK packets through. Blocking those ACK packets ismore difficult, because they do not tell which side started theconnection. To block unsolicited ACK packets (as sent by the Nmap ACKscan), while allowing ACK packets belonging to legitimate connections,firewalls must statefully watch every established connection todetermine whether a given ACK is appropriate. These statefulfirewalls are usually more secure because they can be morerestrictive. Blocking ACK scans is one extra available restriction.The downsides are that they require more resources to function, and astateful firewall reboot can cause a device to lose state andterminate all established connections passing through it.

While stateful firewalls are widespread and rising inpopularity, the stateless approach is still quite common. Forexample, the LinuxNetfilter/iptablessystem supports the--syn convenience option to make the statelessapproach described above easy to implement.

In the previous section, a SYN scan showed that all but six of1,000 common ports on scanme.nmap.org were in the filtered state.Example10.2 demonstrates anACK scan against the same host to determine whether it is using astateful firewall.

# nmap -sA -T4 scanme.nmap.orgStarting Nmap ( https://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)Not shown: 994 filtered portsPORT STATE SERVICE22/tcp unfiltered ssh25/tcp unfiltered smtp53/tcp unfiltered domain70/tcp unfiltered gopher80/tcp unfiltered http113/tcp unfiltered authNmap done: 1 IP address (1 host up) scanned in 5.96 seconds

The same six ports displayed in the SYN scan are shown here.The other 994 are still filtered. This is because Scanme is protectedby this stateful iptables directive: iptables -A INPUT -mstate --state ESTABLISHED,RELATED -j ACCEPT. This onlyaccepts packets that are part of or related to an establishedconnection. Unsolicited ACK packets sent by Nmap are dropped, exceptto the six special ports shown. Special rules allow all packets tothe ports 22, 25, 53, 70, and 80, as well as sending aRST packetin response to port 113 probes. Note that thesix shown ports are in theunfilteredstate, since the ACK scancannot further divide them into open (22, 53, and 80) or closed (25, 70, 113).

Now let us look at another example. A Linux host named Para onmy local network uses the following (simplified to save space)firewall script:

#!/bin/sh## A simple, stateless, host-based firewall script.# First of all, flush & delete any existing tablesiptables -Fiptables -X# Deny by default (input/forward)iptables --policy INPUT DROPiptables --policy OUTPUT ACCEPTiptables --policy FORWARD DROP# I want to make ssh and www accessible from outsideiptables -A INPUT -m multiport -p tcp --destination-port 22,80 -j ACCEPT# Allow responses to outgoing TCP requestsiptables -A INPUT --proto tcp ! --syn -j ACCEPT

This firewall is stateless, as there is no sign of the--state option or the -m statemodule request. Example10.3shows SYN and ACK scans against this host.

# nmap -sS -p1-100 -T4 paraStarting Nmap ( https://nmap.org )Nmap scan report for para (192.168.10.191)Not shown: 98 filtered portsPORT STATE SERVICE22/tcp open ssh80/tcp closed httpMAC Address: 00:60:1D:38:32:90 (Lucent Technologies)Nmap done: 1 IP address (1 host up) scanned in 3.81 seconds# nmap -sA -p1-100 -T4 paraStarting Nmap ( https://nmap.org )All 100 scanned ports on para (192.168.10.191) are: unfilteredMAC Address: 00:60:1D:38:32:90 (Lucent Technologies)Nmap done: 1 IP address (1 host up) scanned in 0.70 seconds

In the SYN scan, 98 of 100 ports are filtered. Yet the ACK scanshows every scanned port beingunfiltered.In other words, all of theACK packets are sneaking through unhindered and eliciting RSTresponses. These responses also make the scan more than five times asfast, since it does not have to wait on timeouts.

Now we know how to distinguish between stateful and statelessfirewalls, but what good is that? The ACK scan of Para shows thatsome packets are probably reaching the destination host. I sayprobably because firewall forgery is always possible. While you may not be able to establishTCP connections to those ports, they can be useful for determiningwhich IP addresses are in use, OS detection tests, certain IP IDshenanigans, and as a channel for tunneling commands torootkitsinstalled on those machines. Other scan types, such asFIN scan,mayeven be able to determine which ports are open and thus infer thepurpose of the hosts. Such hosts may be useful aszombiesfor an IP ID idle scan.

This pair of scans also demonstrates that what we are calling aport state is not solely a property of the port itself. Here, thesame port number is considered filtered by one scantype and unfiltered by another. What IP address youscan from, the rules of any filtering devices along the way, and whichinterface of the target machine you access can all affect how Nmapsees the ports. The port table only reflects what Nmap saw whenrunning from a particular machine, with a defined set of options, atthe given time.

The humble identification field within IP headers can divulge asurprising amount of information. Later in this chapter it will beused for port scanning (idle scan technique) and to detect whenfirewall and intrusion detection systems are forging RST packets asthough they come from protected hosts. Another neat trick is todiscern what source addresses make it through the firewall. There isno point spending hours on a blind spoofing attack “from” 192.168.0.1if some firewall along the way drops all such packets.

I usually test this condition withNping,the free network probing tool that comes with Nmap. This is a rathercomplex technique, but it can be valuable sometimes. Here are the stepsI take:

The end result of this technique is a list of source addressnetblocks that are permitted through the firewall, and those that areblocked. This information is valuable for several reasons. The IPaddresses a company chooses to block or allow may give clues as towhat addresses are used internally ortrusted.For example, machineson a company's production network might trust IP addresses on thecorporate network, or trust a system administrator's personal machine.Machines on the same production network also sometimes trust eachother, or trust localhost. Common IP-based trust relationships areseen in NFS exports, host firewall rules, TCP wrappers, customapplications, rlogin, etc. Another example is SNMP, where a spoofed request to a Cisco router could cause the router to transfer (TFTP) its configuration data back to the attacker. Beforespending substantial time trying to find and exploit these problems,use the test described here to determine whether the spoofed packetseven get through.

A concrete example of this trusted-source-address problem isthat I once found that a company's custom UDP service allowed users toskip authentication if they came from special netblocks entered into aconfiguration file. These netblocks corresponded to differentcorporate locations, and the feature was meant to ease administrationand debugging. Their Internet-facing firewall smartly tried to blockthose addresses, as actual employees could access production from aprivate link instead. But by using the techniques described in thissection, I found that the firewall was not perfectly synced with theconfig file. There were a few addresses from which I couldsuccessfully forge the UDP control messages and take over theirapplication.

This technique of mapping out the firewall rules does not useNmap, but the results are valuable for future runs. For example, thistest can show whether to use certaindecoys(-D).The best decoys will make it all the way to the target system. Inaddition, forged packets must get through for the IP ID idle scan(discussed later) to work. Testing potential source IPs with thistechnique is usually easier than finding and testing every potentialidle proxy machine on a network. Potential idle proxies need only betested if they pass step number two, above.

The previous sections have all focused on the prevalent TCPprotocol. Working with UDP is often more difficult because theprotocol does not provide acknowledgment of open ports like TCP does.Many UDP applications will simply ignore unexpected packets, leavingNmap unsure whether the port is open or filtered. So Nmap places these ambiguous portsin the open|filtered state, as shown in Example10.4.

# nmap -sU -p50-59 scanme.nmap.orgStarting Nmap ( https://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)PORT STATE SERVICE50/udp open|filtered re-mail-ck51/udp open|filtered la-maint52/udp open|filtered xns-time53/udp open|filtered domain54/udp open|filtered xns-ch55/udp open|filtered isi-gl56/udp open|filtered xns-auth57/udp open|filtered priv-term58/udp open|filtered xns-mail59/udp open|filtered priv-fileNmap done: 1 IP address (1 host up) scanned in 1.38 seconds

This 10-port scan was not very helpful. No port responded tothe probe packets, and so they are all listed as open or filtered. One way to better understandwhich ports are actually open is to send a whole bunch of UDP probes fordozens of different known UDP services in the hope of eliciting aresponse from any open ports. Nmap version detection (Chapter7, Service and Application Version Detection) doesexactly that. Example10.5shows the same scan with the addition of version detection(-sV).

# nmap -sV -sU -p50-59 scanme.nmap.orgStarting Nmap ( https://nmap.org )Nmap scan report for scanme.nmap.org (64.13.134.52)PORT STATE SERVICE VERSION50/udp open|filtered re-mail-ck51/udp open|filtered la-maint52/udp open|filtered xns-time53/udp open domain ISC BIND 9.3.454/udp open|filtered xns-ch55/udp open|filtered isi-gl56/udp open|filtered xns-auth57/udp open|filtered priv-term58/udp open|filtered xns-mail59/udp open|filtered priv-fileNmap done: 1 IP address (1 host up) scanned in 56.59 seconds

Version detection shows beyond a doubt that port 53 (domain) isopen, and even what it is running. The other ports are stillopen|filtered because they did not respond to anyof the probes. They are probably filtered, though this is notguaranteed. They could be running a service such as SNMP which onlyresponds to packets with the correct community string. Or they couldbe running an obscure or custom UDP service for which no Nmap versiondetection probe exists. Also note that this scan took more than 40times as long as the previous scan. Sending all of those probes toeach port is a relatively slow process. Addingthe --version-intensity 0 option would reduce scantime significantly by only sending the probes most likely to elicit aresponse from services at a given port number.