By default, all three scanners perform a TCP SYN scan, but a variety of other scan types are available (with the exception of Scanrand, which has only one scan mode). SYN scans are the default because they are the most likely to successfully return useful results; however, depending on the network environment, other scan types can often return useful information missed by the default scan.
There are two types of UDP scans supported by our tools: empty packet scans and protocol data scans.
Empty packet scans involve sending UDP packets without any data to a port and waiting to see whether a result is returned. If an ICMP error such as "port unreachable" is returned, it can be assumed that the port is closed. If no response is seen, then the port is considered open or filtered. As mentioned in How Scanners Work, this inability to differentiate between an open and firewalled port is a severe limitation of empty packet scans. Nmap is the only scanner under discussion that uses this technique. To instruct Nmap to perform an empty packet UDP scan, use the -sU flag. For example:
sudo nmap -sUtarget
Protocol data scans are a more sophisticated approach to UDP scanning that involves sending valid application protocol data in UDP packets to ports to see whether an application responds. Using this technique, ports are only assumed to be open if they respond to the protocol data packets with a nonerror response. Since this technique involves speaking to listening applications, it is more likely to be logged or even cause unexpected behavior such as crashing sensitive applications. Unicornscan supports this mode for UDP scans only, which makes it a good choice for accurate scanning of UDP ports. To perform a protocol data scan with Unicornscan, use the -mU flag, such as:
sudo unicornscan -mUtarget
Nmap also supports sending protocol data to UDP ports by using the application fingerprinting (-sV) functionality mentioned in Operating System Detection Here's an example of Nmap performing a UDP scan with protocol data:
sudo nmap -sU -sVtarget
Mixing UDP and application fingerprinting scans in Nmap can lead to extremely slow scans. If possible, limit the ports to be scanned to the most interesting (see Host Discovery).
TCP packets can be marked with six different flags (SYN, ACK, PSH, URG, FIN, RST) in any combination (although only a few combinations are truly legitimate.) These flags are used by TCP/IP stacks to communicate control data about a connection back and forth. The default TCP scan uses packets with the SYN flag set only. This produces the most reliable results, as SYN packets are how new TCP connections are initiated, and the scan traffic appears to be normal connection traffic. Using other flag combinations can often yield interesting results, and both Unicornscan and Nmap support arbitrary flag combinations using command-line arguments.
To select a custom flag combination with Nmap, use the —scanflags option, providing a list of flags to be set in the argument. Flag names can appear in any order and aren't separated by white space or any other characters. For example, to set the SYN and RST flags in the scan packets, you would type:
sudo nmap —scanflags SYNRSTtarget
To choose custom flags with Unicornscan, append the first letter of the flag to be set (uppercase) or unset (lowercase) after the -mT option. The SYN flag is set by default, so if you do not want your packet to have it set, you need to specify s to disable it. For example, to send packets with the SYN and ACK flags set, you would type (remember the SYN flag is already enabled by default):
sudo unicornscan -mTAtarget
If you want to send packets with FIN, PSH and URG flags set (this is known as an Xmas scan (see the next section), you would type:
sudo unicornscan -mTsFPUtarget
While Unicornscan lets you send any arbitrary flag combination in its scan packets, it doesn't interpret the results as well as Nmap. Be cautious using nonstandard scans with Unicornscan and double-check any unexpected results.
In addition to allowing arbitrary flag combinations, Nmap provides command-line options to set TCP flags in some common configurations. Some flag combinations are more likely to produce useful results than others, and Nmap provides shortcuts for the most popular ones. The TCP scan types that are provided are described next.
-sS)This is the default scan type when superuser privileges (see Superuser Privileges) are available (Nmap will fall back to using a connect scan when they are not).
-sT)This is similar to a SYN scan in that packets with the SYN flag are sent, but the connection is fully established then torn down. This mode is inferior to a SYN scan as it involves sending an additional packet, and since a full connection is established, the scan is more likely to be logged by the target host. This is the only TCP scan type supported by Nmap when run by unprivileged users or when scanning IPv6 addresses.
-sN), FIN (-sF), Xmas (-sX), and Maimon (-sM) scansThese four scans function the same way: by abusing an interesting property of TCP stacks. Packets sent to a closed TCP port without the RST flag set have a RST packet sent in return. Meanwhile, packets sent to an open TCP port without one of the SYN, RST, or ACK flags set are silently discarded. By sending packets without any of these flags set, closed ports can be differentiated from open (or filtered) ports. Null scan packets have all flags disabled, FIN scan packets only have the FIN flag set, Xmas scan packets have the FIN, PSH, and URG flags set and Maimon scan packets set the FIN and ACK flags. These scans are not very useful when stateful firewalls (see Chapter 13) are involved, but can often bypass stateless firewalls entirely.
-sA)This scan is useful for discovering firewall rules for certain firewall types. A host receiving these packets should return a RST packet regardless of whether the port is open or closed. If a RST packet is seen, Nmap assumes the port is unfiltered. If no response is seen then Nmap assumes the port is filtered. This technique works only with firewalls configured to be "moderately" stateful (see Chapter 13). Very stateful firewalls allow only SYN packets, which will lead to all ports being reported as filtered. Stateless firewalls will likely allow all ACK packets through, which Nmap interprets as all ports being unfiltered.
-sW)This scan operates by performing an ACK scan and inspecting the TCP window size returned by the target host. Some operating systems set different window sizes depending on whether the port is open or closed, which Nmap can use to produce scan results. (Most common operating systems do not do this, so your mileage may vary when using this scan type).
Here is the output of a standard SYN scan of my OS X desktop:
bryan@firemaw:˜$ sudo nmap -n -sS 10.150.9.46
Interesting ports on 10.150.9.46:
(The 1667 ports scanned but not shown below are in state: filtered)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
427/tcp closed svrloc
443/tcp closed https
3689/tcp open rendezvous
8080/tcp open http-proxyFrom the scan output, we can see that five ports are open (21, 22, 80, 3689, and 8080), two ports are closed (427 and 443), and the remaining ports are filtered. The large number of filtered ports means a firewall is in place. Using an ACK scan, we can try to deduce the firewall policy:
bryan@firemaw:˜$ sudo nmap -n -sA 10.150.9.46
All 1674 scanned ports on 10.150.9.46 are: UnfilteredThe ACK scan shows that all ports are unfiltered, even though we know a firewall is present. This means that the firewall is likely stateless (see Chapter 13) and will allow all packets through that do not have the SYN flag set. We can abuse this property by using a Xmas scan to see past the firewall and discover what ports are really open or closed on the target host:
bryan@firemaw:˜$sudo nmap -n -sX 10.150.9.46Interesting ports on 10.150.9.46: (The 1668 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open|filtered ftp 22/tcp open|filtered ssh25/tcp open|filtered smtp80/tcp open|filtered http 3689/tcp open|filtered rendezvous 8080/tcp open|filtered http-proxy
The output of the Xmas scan shows a new port, 25, that was missing from the SYN scan. This means that port 25 is open on the target, but is being blocked by the firewall. This is a valuable piece of information that we were only able to gather by using a nondefault scan.