NMAP | Anti-Hacker Tool Kit, Third Edition

Nmap is by far the most popular port scanner available. You can download it freely from http://www. insecure .org/. It installs in a breeze on most Unix operating systems (via con-figure , make , make install ). For OS X heads, nmap can be found in the DarwinPorts collection at http://darwinports.opendarwin.org/ under the net category. Fortunately for Windows users, nmap now works quite well on their platform with the support of the WinPCAP library (http://www.winpcap.org/). The Windows version may not be as stable or as robust as its Unix-based counterparts, though.

Windows XP Service Pack 2 introduced some limitations to the use of raw sockets that the Unix world has been enjoying for a few decades. These dubious security measures were intended to defeat the spread of worms, viruses, and "hacking" tools. More of a useful capability than a necessary evil, raw sockets are a core component of scanners and other security tools. The nmap developers have worked around the SP2 restrictions such that most users will not be impeded by the update.

Note	If you're scanning from an Ethernet-based link, then you're unlikely to have problems associated with SP2. The SP2 workaround was to craft custom Ethernet packets, which can include the TCP/IP payloads no longer directly available via raw sockets.

Implementation

One reason why nmap is so useful is that it offers many different scanning techniques from which to choose. You can scan for hosts that are up, TCP ports, UDP ports, and even other IP protocols. Because we'll be talking in detail about how nmap performs some of its TCP scans , you'll need to know a little bit about how TCP connections are made. Table 4-1 shows definitions for common TCP flags that are involved in TCP connections. A complete diagram of these flags and TCP/IP packet construction can be found in Appendix A.

Table 4-1: TCP Connection Flags
Flag	Description
SYN	Used to indicate the beginning of a TCP connection
ACK	Used to acknowledge receipt of a previous packet or transmission
FIN	Used to close a TCP connection
RST	Used to abruptly abort a TCP connection

When a TCP connection is made to a port, the client sends a TCP packet with the SYN flag set to initiate the connection. If a server is listening on that port, it sends a packet with both the SYN and ACK flags set, acknowledging the client's request to connect while asking to make a return connection. The client then sends a packet with the ACK flag set to acknowledge the server's SYN. This is referred to as the TCP three-way handshake. When one side is done talking to the other, it sends a FIN packet. The other side acknowledges that FIN and send a FIN of its own, waiting for the other side to acknowledge before the connection is truly closed. An RST packet can be sent by either side at any time to abort the connection. A sample TCP conversation between a client and server is shown here:

Client sends SYN to Server: "I want to connect."
Server sends SYN/ACK to Client: "Okay; I need to connect to you."
Client sends ACK to Server: "Okay."
Client and Server send information back and forth, acknowledging each other's transmissions with ACKs. If either side sends an RST, the connection aborts immediately.
Client has finished the conversation; Client sends FIN to Server: "Goodbye."
Server sends ACK to Client (acknowledging Client's FIN). Server then sends a separate FIN to Client: "Okay. Goodbye."
Client sends ACK to Server (acknowledging Server's FIN): "Okay."

Keep this information in mind while reading through the next few sections. It will help you to get a better grasp on how nmap and other port scanners get their information.

Identify Hosts on the Network

If you care only about determining which hosts on a network are up, you can use the Ping scanning method ( -sP ). It works similar to the Windows and Unix ping command in that it sends ICMP echo requests to the specified range of IP addresses and awaits a response. Many hosts and firewalls block these ICMP requests . If nmap merely emulated the ping command, then it would hardly be such a popular tool. In fact, nmap employs some additional techniques that attempt to infer whether or not a host exists.

ICMP provides many commands other than the common echo request. Nmap can also try timestamp ( -PP ) or netmask ( -PM ) requests. The reasoning behind these requests is that a firewall or other network device might be configured to only block ICMP echo request packets. There are, in fact, several possible types of ICMP packets and one or more of them might leak through the network.

Nmap also takes the ICMP the Ping concept and applies it to TCP ports. It attempts to make a TCP connection to port 80 (by default) on the host. If it receives any response (a packet with a SYN/ACK or RST flag), then nmap assumes the host has responded. If it receives nothing, the host is assumed to be down, not currently on the network, or explicitly ignoring connections to the target port.

It is important to understand how nmap makes its assumptions when using the "TCP Ping" technique. If a service receives a connection request (a SYN packet), the TCP protocol instructs the service to respond with a SYN/ACK packet. This response implies that a host associated with the destination IP address exists; otherwise , there would not have been any service to respond. Now, imagine a host on the network, but it is not running a service on nmap's "TCP Ping" target port. In this case, the host responds with a reset (RST) packet to inform the client that no service exists. Even though the host tells us there is nothing listening on that particular port, the fact that a response was sent tells us there is a host associated with the destination IP address. When nmap sends an ACK packet it also expects to receive a reset (RST) packet from the server, but for a different reason. The ACK implies that a connection has been established; however, the host has not previously passed the three-way handshake with the client (nmap in this case) so it sends a reset, basically asking nmap, "I haven't even started to chat with you. Why are you acknowledging me?" The reason you might choose to use an ACK packet instead of a SYN packet is pure guile: A packet filter might carefully monitor SYN packets because those are used to establish connections whereas the presence of an ACK flag implies that a connection has already been set up (and approved by the filter).

On the other hand, if nmap receives nothing after sending a SYN or ACK packet, it either means that no host exists at that IP address or that traffic to that host is blocked by a network device. Nmap chooses port 80 by default because most firewalls and port filters blindly permit web traffic. If no response arrives, nmap can assume with a decent amount of certainty that the host is down. The target port(s) are set with the PA (packets sent with the ACK flag) or PS (packets sent with the SYN flag).

Tip

Proxy-based firewalls and proxies in general tend to wreak havoc with the accuracy of these types of discovery scans. The proxy may always respond for the host, whether it exists or not. Even so, you might be able to perform some timing analysis on the scan results. If you suspect a proxy firewall sits between you and the target network, try a TCP Ping against several hosts, but do so one host at a time. If a response comes back quickly from host A but takes a few seconds to come back from host B, then that might mean that the firewall could connect to the first host but not the second (probably because no host sits at that IP address). There's no hard rule about what a response time might be. Keep in mind that, in this case, you're looking for anomalies in the response times, not the actual responses.

On a final note, it is possible to use UDP to identify hosts, but it is notoriously unreliable. Check out the THC-Amap scanner later in this chapter for a more robust UDP tool.

Scan for TCP Ports

The basic method of TCP port scanning is to try a TCP connect() call to the port and wait for a response. This is called "TCP connect()" because the connect() function is what Unix systems use to connect to sockets. In other words, it is the same thing any TCP client, such as a web browser, would do to complete the TCP three-way handshake and establish a connection. Nmap simply disconnects by sending an RST packet as soon as the handshake completes. Following are some examples of these types of scans:

 [Paris:~] mike% nmap -sT 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at 2005-06-27 18:00 PDT Interesting ports on 10.0.1.2: (The 1660 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 135/tcp open msrpc 445/tcp open microsoft-ds Nmap finished: 1 IP address (1 host up) scanned in 1.454 seconds

The following table indicates how nmap handles sT , and sP scans:

Nmap Sets TCP Flag	Nmap Receives Flag from Host	Nmap's Follow-up	Nmap Assumes
SYN	SYN/ACK	ACK followed by RST	Port is open; host is up.
SYN	RST	-	Port is closed; host is up.
SYN	Nothing	-	Port is blocked by firewall or host is down.

Since nmap completes the TCP connection, the scan is most likely logged by the service ( assuming that the service is capable of logging connection attempts). Note that a firewall or network device will observe the scan, if not log it.

Note	On Unix-based systems, nmap requires root-level privilege to perform most functions other than the basic "TCP connect()" scan.

Nmap enables you do some sneaky things with TCP port scans. First, there's the SYN scan ( -sS ), which makes the first part of the TCP connection (sending a TCP packet with the SYN flag set), but then behaves a bit differently. If it receives a TCP packet with the RST flag (a reset packet), nmap assumes the port is closed and does not send any more packets. If it receives a response (indicated by a packet with the SYN/ACK flag), then it sends an RST packet instead of completing the connection, as shown in the next table. Since the TCP three-way handshake does not complete, many services will not log the connection.

Nmap Sets TCP Flag	Nmap Receives Flag from Host	Nmap's Follow-up	Nmap Assumes
SYN	SYN/ACK	RST	Port is open; host is up.
SYN	RST	-	Port is closed; host is up.
SYN	Nothing	-	Port is blocked by firewall or host is down.

Although services might not log these "incomplete" connections, some firewalls and intrusion-detection systems (IDSs) will be on the lookout for them. Nmap has even sneakier scans for you to try, although a good IDS should still observe it. Additionally, a firewall may filter out the sneaky packets and skew the scan results.

You should have already noticed that anytime you send TCP packets to a closed port, the TCP/IP stack on the host is supposed to respond with a reset packet. So why even bother sending a legitimate TCP packet? If a closed port on a host will always respond with an RST, why not just send some garbage packets that make no sense and see what you get back?

The FIN scan ( -sF ) sends a FIN packet whose normal use is to close a connection. However, we're sending it before a connection has been established, so any open port should just ignore this garbage. Closed ports still respond with an RST, as shown in the following table. Nmap offers two other garbage scans: the Xmas tree ( -sX ) scan, which sets the FIN, URG, and PUSH flags of a TCP packet (lighting it up like a Christmas tree), and the null ( -sN ) scan (which turns off all the flags). Keep in mind that not all TCP/IP stacks are implemented correctly. Even though open ports are not supposed to send RST packets in response to these types of probes, some operating systems don't strictly adhere to the protocol and respond anyway. This means that you might get false positives with this scan on certain types of hosts. Also, any host that is protected by a firewall may return false positives. Nmap assumes that the port is open if it does not receive a response. What if a firewall is blocking that response? These scans trade accuracy for stealth.

Nmap Sets TCP Flag	Nmap Receives Flag from Host	Nmap Assumes
FIN	Nothing	Port is open if host is up and not firewall-protected.
FIN	RST	Port is closed; host is up.

Sometimes nmap will tell you that a port is filtered. This means that a firewall or port filter is interfering with nmap's ability to accurately determine if the port is open or closed. Some firewalls, however, will only filter on incoming connections (that is, looking only for incoming SYN packets to a particular port). When you want to test the rules on a firewall, run an ACK scan against a host behind that firewall. Whenever an ACK (acknowledgment) packet is sent that is not part of an existing connection, the receiving side is supposed to respond by sending an RST. The ACK scan ( -sA ) can use this fact to determine whether or not a port is being filtered or blocked. If an RST is received, the port is unfiltered ; otherwise, it's filtered, as shown in the next table. The ACK scan can tell you exactly what firewall rules are protecting a particular host.

Nmap Sets TCP Flag	Nmap Receives Flag from Host	Nmap Assumes
ACK	RST	Port is not firewall-protected; port may be open or closed; host is up.
ACK	Nothing or ICMP unreachable	Port is blocked by firewall if host is up.

Because this scan doesn't tell you about ports that are actually open or closed, you might want to try a different scan in combination with the ACK scan. For example, you can use the ACK scan in combination with the SYN scan ( -sS ) to determine if a host is being protected by a firewall that uses stateful packet inspection or only blocks initial incoming connections (SYN flags). In the following example, a SYN scan reveals only port 80 open on 192.168.1.40. It also tells us that ports 21 and 22 are filtered and nmap can't determine their state. An ACK scan tells us that all ports on 192.168.1.40 are unfiltered, even though the SYN scan told us they were filtered! This means SSH and FTP on 192.168.1.40 are being filtered by a stateless firewall; although the SYN is blocked, the ACK is able to pass through.

 [[Paris:~] mike% nmap -sS 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-27 18:33 PDT Interesting ports on 10.0.1.2: (The 1659 ports scanned but not shown below are in state:  closed  ) PORT    STATE SERVICE 22/tcp  open  ssh 80/tcp  open  http 135/tcp open  msrpc 445/tcp open  microsoft-ds Nmap finished: 1 IP address (1 host up) scanned in 0.720 seconds [Paris:~] mike% sudo nmap -sA 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-27 18:34 PDT All 1663 scanned ports on 10.0.1.2 are:  UNfiltered  Nmap finished: 1 IP address (1 host up) scanned in 0.735 seconds [Paris:~] mike% nmap -sA 10.0.1.42 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-27 18:31 PDT All 1663 scanned ports on 216.74.67.245 are:  filtered  Nmap finished: 1 IP address (1 host up) scanned in 169.348 seconds

When possible, nmap will indicate if ports are open, closed, unfiltered (open or closed, but not blocked), or filtered (blocked by some port filter or similar device).

Scan for UDP Ports

Yep, of course nmap can do this too. The sU option sends empty UDP packets and waits to receive ICMP "port unreachable" messages in return. Notice the subtle distinction? Nmap relies on a different protocol (ICMP) to determine if a UDP port is closed. The converse is not true. There is no ICMP message that indicates a UDP port is open. If the port is open and the service receives a packet, then it typically does nothingthe protocol does not require acknowledgment of incoming packets. You can see some flaws in this from a port enumeration perspective. If return ICMP messages are blocked by a firewall, all UDP ports on the host will appear to be open. Also, if the UDP traffic is blocked by a firewall, all UDP ports will still appear to be open. This is the same pitfall we saw in Netcat with UDP port scanning.

Nmap Sends to Host Port	Nmap Receives from Host Port	Nmap Assumes
Empty UDP packet	Nothing	Port assumed open if host responds to Ping (host is up); port may be closed if firewall blocking ICMP.
Empty UDP packet	ICMP port unreachable	Port is closed.

Check out THC-Amap for a more accurate technique for scanning UDP services.

Scan for Protocols

If you attempt to connect to a UDP port with nothing on the other end, the host sends back an ICMP "port unreachable" message. This behavior holds true for many protocols in the TCP/IP family. Each transport layer IP protocol has an associated number. The most well-used are ICMP (1), TCP (6), and UDP (17). All IP packets have a "protocol" field that indicates what kind of packet headers to expect on the transport layer. If we send a raw IP packet with no transport layer headers and a protocol number of 130 (which refers to an IPsec-like protocol called Secure Packet Shield or SPS), we can determine whether that protocol is implemented on the host. If we get an ICMP "protocol unreachable" message, it's not implemented. Otherwise, we assume it is. This scan method, called protocol scanning ( -sO ), suffers from the same flaws as UDP scanning in that a firewall blocking ICMP messages or the protocol itself can give us false positives.

 [Paris:~] mike% sudo nmap -sO 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-27 18:50 PDT Interesting protocols on 10.0.1.2: (The 250 protocols scanned but not shown below are in state: closed) PROTOCOL STATE          SERVICE 1        open           unknown 2        openfiltered  unknown 6        open           unknown 17       filtered       unknown 47       openfiltered  unknown 255      openfiltered  unknown Nmap finished: 1 IP address (1 host up) scanned in 1.545 seconds

Even though these results may be inaccurate, protocol scans can be helpful in identifying hosts on the network.

Determine Service Applications

Port scanning has managed to evolve from the open/filtered/closed state information and become more detailed about what really lies behind an open port. For the most part, people expect a service listening on port 80 to be a web server, but this does not have to be the case. Nmap provides a simple method for identifying RPC services ( -sR ) and a more complex method that can identify a much greater number of services ( -sV ). Without using the sV option, nmap merely matches port numbers to its predefined list in the nmap-services file. With the sV option, nmap probes the port with a series of nudge strings and takes a fingerprint of the host's response.

 [Paris:~] mike% nmap -sR 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-27 18:53 PDT Interesting ports on 10.0.1.2: (The 1660 ports scanned but not shown below are in state: closed) PORT    STATE SERVICE        VERSION 22/tcp  open  ssh 135/tcp open  msrpc 445/tcp open  microsoft-ds Nmap finished: 1 IP address (1 host up) scanned in 0.949 seconds [Paris:~] mike% nmap -sV 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-27 18:53 PDT Interesting ports on 10.0.1.2: (The 1660 ports scanned but not shown below are in state: closed) PORT    STATE SERVICE        VERSION  22/tcp  open  microsoft-rdp Microsoft Terminal Service  135/tcp open  msrpc         Microsoft Windows msrpc 445/tcp open  microsoft-ds  Microsoft Windows XP microsoft-ds Nmap finished: 1 IP address (1 host up) scanned in 36.696 seconds

Notice that the second scan, which used sV , correctly identified Microsoft Terminal Server running on port 22. Normally, this port is used for secure shell communications, as nmap assumed in the first scan; however, after trying a series of probes against that port, nmap determined the real application behind the port.

Camouflage the Scan

Nmap provides several options that attempt to avoid detection from system logs, firewalls, and intrusion detection systems. Some of these options can be useful for profiling firewall rules or inferring host information. After all, if a security device doesn't detect a scan, then it (probably) won't interfere with it. This gives you a more accurate picture of the network. On the other hand, some of the stealth options act more like network chaff and merely add noise without contributing to accuracy or performance.

Zombie Scan For those of you who are not George Romero fans, think of this technique as an "idle" scan. This scan cleverly uses a feature of the TCP protocol, the packet's IP ID field, and a third-party host to scan a target network. This third-party host needs to receive relatively little traffic from other sources during the scan. Nmap spoofs packets so that they appear to originate from the idle (zombie) host with a destination on the target network. A live host on the target network will respond to the zombie host. Of course, this response can't be seen by nmap because the zombie could be some other host "far" away on the Internet. The sneaky bit is that nmap can monitor the IP ID fields of packets coming from the zombie in order to deduce port information about the victim host. In the end, the victim only ever sees traffic from the zombie. The zombie sees traffic from both the victim and from nmap.

Here's an example:

 [Paris:~] mike% nmap -P0 -sI 10.0.1.32 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-27 21:40 PDT Idlescan using zombie 10.0.1.32 (10.0.1.32:80); Class: Incremental Interesting ports on 10.0.1.2: (The 1660 ports scanned but not shown below are in state: closedfiltered) PORT     STATE SERVICE 22/tcp  open  ssh 135/tcp open  msrpc 445/tcp open  microsoft-ds Nmap finished: 1 IP address (1 host up) scanned in 30.876 seconds

Tip	Unless you disable Pings ( `-P0` ) and possibly DNS resolution ( `-n` ), the target host's network will still receive traffic directly from the system running nmap rather than just the zombie host.

FTP Bounce FTP has a rather glaring design flaw that can be used to nmap's advantage. FTP servers listen for incoming connections on TCP port 21. This is referred to as the control connection used to transmit FTP commands. In order to transfer data (the result of the command), the FTP server needs a separate data connection. The client issues a PORT command that contains the client's IP address and destination port. At this point, the client waits for the server to initiate the data connection. This "Don't call me, I'll call you" scenario means that the server can be instructed to connect to an arbitrary port. This behavior is anathema to firewall administrators who want to control and monitor a service's traffic. This method of operation is called an active transfer . The growth of networks that use network address translation (NAT), proxies, and strict firewalls means that active FTP has become less common. Nevertheless, we'll take a look at how the PORT command can be abused.

Note	Most FTP communications now solely use passive transfers (RFC 1123) because the client initiates the control and data connections, which is easier to use with firewalls and NAT.

The intended use of the PORT command is to provide connection information to the FTP server. Yet we can specify the destination port and the IP address. Instead of specifying our own host, we could instruct the FTP server to connect to someone else's port and IP address combination. Nmap exploits this feature to make a port scan appear to be coming from the FTP server. This is the "FTP bounce" scan. All nmap does is make an active-mode FTP connection to a server, send PORT commands consisting of the target's IP address and port list, and interpret the results.

How to find vulnerable FTP servers? Well, the flaw is in the design of FTP servers that are compliant with RFC 959. At first glance, there's no need to check for patch levels or versions. Unfortunately, modern FTP server applications have been modified to restrict PORT commands to the originating host. Some outdated FTP servers can still be found. This exploit is another good reason you think carefully before running an anonymous FTP.

Here's an example of what an FTP bounce scan looks like:

 [Paris:~] mike% nmap -b anonymous@ftphost -p 6000 10.0.1.17

The previous command tries to use ftphost to scan port 6000 on 10.0.1.17 (we're looking for an X server). This is what happens behind the scenes:

  Server:  220 FTPHOST FTP server version 4 ready  Client:  USER anonymous  Server:  331 Guest login OK, send e-mail as password  Client:  PASS -wwwuser@  Server:  230 Login successful  Client:  PORT 10,0,1,17,23,112  Server:  200 PORT command successful  Client:  LIST  Server:  150 Opening ASCII connection for '/bin/ls'  Server:  226 Transfer complete

Nmap uses the PORT command to have ftphost open a connection to port 6000 on 10.0.1.17. The last two values of the PORT command, 23 and 112 in the example, are the two bytes necessary to represent the destination port. (The destination port can be a 16-bit number. These are the high and low bytes of the port, for example 23 * 256 + 112 = 6000.) Next, nmap attempts to execute the LIST command. If that succeeds, then the FTP server has connected to port 6000 open on 10.0.1.17. If the FTP server had replied with "425 can't build data connection," then we would know that port 6000 is closed.

Even if the FTP bounce works, the FTP server has likely logged the activity because it's part of a "normal" FTP transaction. Keep in mind that the FTP bounce scan is using the TCP connect() method of the FTP server to conduct the scan. It's not possible to pass other types of scans, stealthy or not, through an FTP bounce.

Tip	Even if you find a server that's vulnerable to the FTP bounce, it still might not let you scan privileged ports (those below 1024), as an FTP client shouldn't usually be listening for a data connection on a privileged port.

Fragmentation The -f option causes nmap to break up a TCP-based scan, including "TCP Ping" scans, into fragmented IP packets. The goal is to bypass lazy firewalls or intrusion detection systems that do not bother to fully reconstruct the packet. This option can crash some operating systems and doesn't work correctly on all Unix variants, so be careful if you use it.

Decoy and Spoofed Sources Nmap's D option commingles scans from your IP address with a list of decoy IP addresses. This has the effect of hiding the one scan you care about among several scanning hosts. Administrators of the target network will see scans coming from several IP addresses, but it will not be immediately evident which one is the real scanner.

Note

It is very difficult to spoof TCP connect() scans unless you can sniff the spoofed host's network. Consequently, the decoy scan(s) will only submit the initial TCP packet and not send a follow-up SYNACK. An observant network administrator watching network traffic may still be able to pick out the actual scanner from the decoys.

The -S option lets you set the source IP address of your packets. Use this to spoof an IP address and, unlike the decoy scan, send no traffic from your IP address. This option is also useful for multi- homed hosts if you wish to scan from a particular network interface. You won't receive the scan results because the target host will respond to the spoofed IP address instead of your own host. It's likely that you'll need to include P0 (don't Ping) and e (specify the network interface) flags when running a spoofed scan.

Spoofed and decoy scans can be useful when testing firewall rulesets. Rather than gaining access to a suite of hosts behind a firewall, you could use single host to send spoofed packets. In this case you'll be spoofing legitimate hosts and monitoring the other side of the firewall to see what traffic passes through the device. This is a quick, easy way of verifying rules.

Tip

If your network appears to be the subject of reset scans (TCP packets with the RST flag), then you may have been chosen as a decoy or spoof host by an unknown nmap user. Remember that the RST is a response to ACK scans and closed ports. So, the host "scanning" your network with reset packets may simply be responding to packets that someone spoofed with your network's IP addresses.

Randomizing Hosts and Ports Nmap randomizes the ports you specify by default. You can turn off this feature using the -r flag. If you're providing a list of hosts to scan, you might want to randomize the order in which you scan them, using the randomize_hosts flag.

Manage Scan Speeds

Nmap uses rather appropriately named timing options ( -T ) that try to avoid time-based detection algorithms in firewalls and IDSs: Paranoid, Sneaky, Polite, Normal, Aggressive, and Insane. Additionally, you can indicate your own timing policy by using specific command-line flags. Table 4-2 details the built-in time policies and shows how to create your own using the appropriate command-line options. For example, the following SYN scan attempts to avoid detection by using the Sneaky policy against ports 1 through 100 on 10.0.1.17.

 [Paris:~ ] nmap -T Sneaky --sS -p 1-100 10.0.1.17

Table 4-2: Nmap `T` Option Summary
`-T` Option	Delay Between Probes	Time Spent on One Host	Probe Response Timeout	Use Parallel Probes
Paranoid	5 minutes	Unlimited	5 minutes	No
Sneaky 1	15 seconds	Unlimited	15 seconds	No
Polite 2	0.4 seconds	Unlimited	6 seconds (10 max)	No
Normal 3	None	Unlimited	6 seconds (10 max)	No
Aggressive 4	None	5 minutes	1 seconds (1.5 max)	Yes
Insane 5	None	75 seconds	0.3 seconds max	Yes
Related option	`scan_delay`	`host_timeout`	`initial_rtt_timeout` `min_rtt_timeout` `max_rtt_timeout`	`max_parallelism`

For clarity's sake, the scan_delay option specifies the minimum amount of time in milliseconds to wait between probes. The host_timeout option specifies the maximum amount of time in milliseconds to spend scanning one host. For example, you can give up if the scan takes longer than 5 minutes against a single host. The rtt_time-out options specify how long to wait in milliseconds for probe responses.

Nmap always waits at least 0.3 seconds (300 milliseconds) for probe responses. It starts with an initial rtt_timeout value of 6 seconds and increases or decreases that value depending on previous latency values. It does this to improve scan performance. If the host seems to be responding quickly to nmap's scans, it will decrease the rtt_timeout . If the latency is too great, nmap increases the rtt_timeout . Regardless of responsiveness, the timeout value always stays between the maximum ( max_rtt_timeout ) and minimum (min_rtt_timeout ). Lower rtt_time-out values have a greater chance of missing open ports from systems that respond slowly.

The max_parallelism option controls the number of concurrent port probes. Setting the value to 1 turns off parallelism. By default, nmap will attempt to run up to 36 probes in parallel. Performance for TCP connect() scans ( -sT ) can be improved by using the M option to increase the available sockets, although your system may limit this value. The M option does not apply to any other type of scan.

Identify a Host's Operating System

One of the nmap's most useful features is the capability to determine a host's operating system based on its responses to specific packets. Depending on the operating system (OS), nmap may even provide a particular version and patch level or uptime. The TCP/IP family of protocols is defined in several RFC documents; however, each operating system's implementation of those protocols differs slightly. For example, one OS may respond to invalid flag combinations or have unique values for common portions (such as TTL). Nmap takes advantage of these nuanced differences between TCP/IP stacks. Thus, it can differentiate between systems like Solaris and Windows, OpenBSD and Mac OS X.

The nmap-os-fingerprints file contains the fingerprints that nmap uses to identify the OS of unknown hosts. A detailed description of fingerprinting techniques and how nmap analyzes packets can be found at this URL: http://www.insecure.org/nmap/nmap-fingerprinting-article.html. The OS detection option can also perform TCP packet analysis to determine information like the uptime of a system (using TCP/IP timestamps) and sequence number predictability. Predictable sequence numbers can make it easier to forge TCP connections by "intercepting" packets and guessing sequence numbers.

Here is an example:

 [Paris:~] mike% nmap -O 10.0.1.2 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-28 17:23 PDT Interesting ports on 10.0.1.2: (The 1660 ports scanned but not shown below are in state: closed) PORT     STATE SERVICE 22/tcp  open  ssh 135/tcp open  msrpc 445/tcp open  microsoft-ds Device type: general purpose Running: Microsoft Windows 2003/.NETNT/2K/XP OS details: Microsoft Windows Server 2003 or XP SP2 Nmap finished: 1 IP address (1 host up) scanned in 2.357 seconds'

Command-line Option Summary

We've already covered most of the important options, but nmap provides many more. The following list details these options:

v d The -v option gives you more verbose output, while -d adds debug output. You can use both options more than once on the command line to increase the amount of verbosity and debug output.
oA oG oN oS oX < logfile > With many programs, if you want simultaneous output to the screen and a file, you have to use the Unix tee command. The options provide formatted logs to record the results from your scan. Instead of providing a logfile name you can use a dash (-) to display the results to stdout (the screen).
- oA generates logs in all supported formats. Logs are differentiated by their file suffix; for example, the XML log would have a .xml suffix.
- oG logs each host's result on a single line. This enables you to use grep (or similar commands) to search for port numbers, status, and services. Note that oM produces the same output but is deprecated.
- oN logs results to a file exactly as you see them on screen.
- oS formats the output in "script kiddie " typeset just to be obnoxious.
- oX creates a log in XML format. This is exceptionally useful for reporting and managing large result sets. You can create custom style sheets to quickly display results in a well-organized manner.
resume < logfile > This resumes a scan if the logfile was created with oN or -oG .
iR iL < inputfile > Instead of specifying your host targets on the command line, you can generate hosts randomly to scan (if you find that useful) using iR , or you can use iL to read host targets from a file containing a list of hostnames or IP addresses separated by a space, tab, or newline.

Use a dash (-) instead of inputfile to have nmap read hosts from stdin. This is useful when combining multiple commands.
F Only scan common ports found in the nmap-services file. Without this option, nmap scans ports 11024 and any other ports that are included in nmap-services (or /etc/services if nmap-services isn't present). If used with the sO option for scanning protocols, nmap uses its protocols file (nmap-protocols) instead of the default action of scanning for all 256 protocols. Nmap currently scans about 1,660 ports by default. There are 65,535 possible ports (and port 0).
p < ports > At some point you need to tell nmap which ports to scan. This can be a single port, a comma-separated list of ports, a range of ports separated by a hyphen, or any combination thereof. If this option isn't specified, nmap performs the fast scan in addition to all of the first 1,024 ports (see the description of the F option).
e < interface > On a multi-homed host, you can specify which network interface you want to communicate on. Nmap usually handles this on its own.
g < port > This lets you select a source port from which to perform all of your scanning, and is useful for sneaking your scans by firewalls that allow incoming traffic with a source port of TCP/20 (assuming it to be FTP data), TCP/80 (assuming it to be web traffic), or UDP/53 (assuming it to be DNS).

NmapFE

Nmap comes with its own graphical front end that you can use if you're running the X Window System. The program, NmapFE, and is shown in Figure 4-1. It has many of the same options as nmap but uses forms and menus to grab the input and scanning configurations from the user. It looks pretty, and it's easy to use, but you still have more configuration options using the command line.

Figure 4-1: NmapFE on X Window System

Mac OS X users can find a native GUI in the aqua category under NmapFE. (See Figure 4-2.) The layout is simpler. Both the X Window and OS X versions display the equivalent command line.

Figure 4-2: NmapFE on Mac OS X

Case Study: Watching the Watcher

Let's look at some examples using nmap and see what kind of footprint is left in the logs of one of the host systems. We'll start off with a Ping-only scan (the sP option) of the entire 10.0.1.0/24 network. We can specify this target in several ways on the command line:

 nmap -sP "10.0.1.*" nmap -sP 10.0.1.0/24 nmap -sP 10.0.1.1-254

The last method lets us skip the network and broadcast addresses of this Class C subnet. It's okay to Ping scan these addresses, but it saves time to skip them in a port scan.

 [Paris:~] mike% nmap -sP 10.0.1.0-255 Starting nmap 3.81 (http://www.insecure.org/nmap/) at 2005-06-28 22:05 PDT Host 10.0.1.1 appears to be up. Host 10.0.1.2 appears to be up. Host 10.0.1.5 appears to be up. Host 10.0.1.32 appears to be up. Nmap finished: 254 IP addresses (4 hosts up) scanned in 2.975 seconds

We now know which hosts on the network responded to Pings. But what if some hosts are blocking ICMP Pings? If you recall, nmap tries ICMP and TCP Pings. This should be a complete list. Now we can focus our actual port scans on these systems. Let's run nmap without any options against these systems:

 [Paris:~] mike% nmap 10.0.1.1 10.0.1.2 10.0.1.5 10.0.1.32 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-28 22:12 PDT Interesting ports on 10.0.1.1: (The 1661 ports scanned but not shown below are in state: closed) PORT      STATE SERVICE 53/tcp    open domain 10000/tcp open snet-sensor-mgmt Interesting ports on 10.0.1.2: (The 1660 ports scanned but not shown below are in state: closed) PORT    STATE SERVICE 22/tcp open ssh 135/tcp open  msrpc 445/tcp open  microsoft-ds Interesting ports on 10.0.1.5: (The 1655 ports scanned but not shown below are in state: closed) PORT     STATE SERVICE 22/tcp   open  ssh 80/tcp   open  http 139/tcp open  netbios-ssn 515/tcp open printer 631/tcp open   ipp 2401/tcp open cvspserver 3306/tcp open mysql 6000/tcp open  X11 Interesting ports on 10.0.1.32: (The 1657 ports scanned but not shown below are in state: closed) PORT     STATE SERVICE 22/tcp   open  ssh 80/tcp   open  http 111/tcp open rpcbind 199/tcp open smux 3306/tcp open mysql 8080/tcp open http-proxy Nmap finished: 4 IP addresses (4 hosts up) scanned in 15.393 seconds

Notice the syntax for specifying the target accepts space-separated lists or ranges. This scan targets the default port list (ports 11024 and those in the nmap-services file). Let's see how the Linux messages logon 10.0.1.32 looks:

 Jun 28 13:24:20 Corrino sshd[1666]: Did not receive identification  string from ::ffff:192.168.1.5 Jun 28 13:24:21 Corrino syslog[1496]: [smux_accept] accepted fd 11  from 192.168.1.5:58724

Note	Many services do not log connection information on their own. Use TCP wrappers (inetd or xinetd) to record uninformative services.

The services recorded the scanner's IP address (192.168.1.5) and in the case of Secure Shell (SSHD) even reported something suspicious. The services were able to log the scans because the TCP handshake was completed by nmap's default TCP connect() scan. Next, we'll try a SYN scan along with some timing and information options. When you run scans with "stealthy" timing options, it's a good idea to include a v or d flag to monitor nmap's progress. The output will be too long to include here, but we'll show the command line.

 [Paris:~] mike% nmap -sS -d -v -T Sneaky -p 22,199 10.0.1.32

Sneaky scans take a long time so it's good practice to shrink the target port range to those in which you're interested. Even a range like 2080 would take at least 15 minutes (15-second pause multiplied by 61 ports). Stealth scans are better suited to specific port identification for a range of hosts, perhaps looking for a vulnerable service. Since we included d and v nmap provides an ongoing status:

 [Paris:~] mike% nmap -sS -d -v -T Sneaky -p 22,199 10.0.1.32 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-28 22:28 PDT Packet capture filter (device en0): (icmp and dst host 192.168.1.5)  or ((tcp or udp) and dst host 192.168.1.5 and (dst port 43204 or  dst port 43205 or dst port 43206 or dst port 43207 or dst port  43208)) We got a ping packet back from 10.0.1.32: id = 62351 seq = 23238  checksum = 45481 Hostupdate called for machine 10.0.1.32 state UNKNOWN/COMBO ->  HOST_UP (trynum 0, dotimeadj: yes time: 20713) Finished block: srtt: 471 rttvar: 5000 timeout: 15000000  block_tries: 1 up_this_block: 1 down_this_block: 0 group_sz: 1 massping done:  num_hosts: 1  num_responses: 1 Initiating SYN Stealth Scan against 10.0.1.32 [2 ports] at 22:28 Packet capture filter (device en0): dst host 192.168.1.5 and (icmp  or (tcp and (src host 10.0.1.32))) Discovered open port 22/tcp on 10.0.1.32 Discovered open port 199/tcp on 10.0.1.32 The SYN Stealth Scan took 30.02s to scan 2 total ports. Host 10.0.1.32 appears to be up ... good. Interesting ports on 10.0.1.32: PORT    STATE SERVICE 22/tcp  open  ssh 199/tcp open  smux Final times for host: srtt: 450 rttvar: 2850  to: 15000000 Nmap finished: 1 IP address (1 host up) scanned in 45.242 seconds                Raw packets sent: 4 (148B)  Rcvd: 3 (138B)

For longer scans (more hosts, larger port range, Paranoid timing option), you would also see nmap's estimate of the time to finish the scan:

 SYN Stealth Scan Timing: About 0.51% done; ETC: 05:44  (7:18:05 remaining) SYN Stealth Scan Timing: About 0.60% done; ETC: 06:02  (7:34:42 remaining)

We return to the logfile on 10.0.1.32 for those two services and do not find anything reported. The SYN scan didn't complete the TCP handshake, which didn't trigger the service's log function. Plus, a 15-second delay might be long enough to avoid the gaze of an IDS.

Note

Unlike Unix systems with TCP wrappers (inetd or xinetd) that manage most services and log connection attempts, Windows systems don't natively log TCP connect() attempts on ports. Individual services (like IIS on port 80) might log your connection, but there's no default system in place for logging this kind of activity to the event log. A thorough scan of a Windows box has a better chance of going undetected, unless an IDS or similar device is present on the network.

Next, let's try some sneakier operating system detection:

 [Paris:~] mike% nmap -O -p 22,23 10.0.1.32 Starting nmap 3.81 (http://www.insecure.org/nmap/) at  2005-06-28 22:38 PDT Interesting ports on 10.0.1.32: PORT    STATE  SERVICE 22/tcp open   ssh 23/tcp closed telnet Device type: general purpose Running: Linux 2.4.X2.5.X2.6.X OS details: Linux 2.4.18 - 2.6.7 Uptime 42.645 days (since Tue May 17 07:08:43 2005) Nmap finished: 1 IP address (1 host up) scanned in 3.200 seconds

The most efficient identification requires one open port and one closed port. Port 22 has already been identified as open and we know port 23 isn't available. Nmap's OS detection correctly identified the Linux system, although it gave a rather large window of possible kernels . The actual kernel is 2.6.3 so we needn't be too concerned by the accuracy. The uptime is questionable in this case. We can check the uptime and see how close the estimate was:

 [mike@Corrino ~]$ uptime  13:52:18 up 92 days, 36 min, 1 user, load average:  0.04, 0.04, 0.01