Nmap

---

Nmap is by far the most popular port scanner available. You can download it from http://www.insecure.org/, and it compiles and installs in a breeze on most Windows and Unix operating systems including Mac OS X (via configure, make, make install). You can download Windows binaries (along with the required Winpcap) from http://www.insecure.org/. A graphical Windows frontend for nmap is available at http://www.nmapwin.org/. For this discussion, we’ll use the Unix nmap version 3.48.

Implementation

One reason why nmap is so useful is that it offers many different scanning techniques from which you can 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.

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 will then send 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 will send a FIN packet. The other side will acknowledge that FIN and send a FIN of its own, waiting for the other side to acknowledge before the connection is truly closed. A 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:

1. Client sends SYN to Server: “I want to connect.”

2. Server sends SYN/ACK to Client: “Okay; I need to connect to you.”

3. Client sends ACK to Server: “Okay.”

4. Client and Server send information back and forth, acknowledging each other’s transmissions with ACKs. If either side sends a RST, the connection aborts immediately.

5. Client has finished the conversation; Client sends FIN to Server: “Goodbye.”

6. Server sends ACK to Client (acknowledging Client’s FIN). Server then sends a separate FIN to Client: “Okay. Goodbye.”

7. 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.

Scanning for Hosts

If you care only about determining which hosts on a network are up, you can use the Ping scanning method (-sP). It works similarly to fping (see Chapter 14) in that it sends Internet Control Message Protocol (ICMP) echo requests to the specified range of IP addresses and awaits a response. However, many hosts these days block ICMP requests. In this case, nmap will attempt to make a TCP connection to port 80 (by default) on the host. If it receives anything (either a SYN/ACK or a RST), the host is up. If it receives nothing at all, the host is assumed to be down or not currently on the network. If you want only a list of hostnames for the IP range you’ve specified, try a list scan (-sL).

Table 4-1: TCP Flag Definitions

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 abort a TCP connection abruptly

Note 

It’s important to clarify how the TCP Ping technique works on an IP address. If a service is listening on a port and someone makes a connection to it (sends a SYN packet), the service will send a SYN/ACK packet in return. This obviously indicates that a machine is at that IP address. However, if no service is listening on that port but the machine is still up and on the network, a reset (RST) packet will be sent in return. Even though the machine is responding by telling us there’s nothing listening on that particular port, the fact that a response was sent tells us that a machine is at that IP address. If nothing is received after sending a SYN packet, it either means that no host is at that IP address or that the traffic is being blocked by a firewall. That’s why nmap chooses port 80 by default, because most firewalls and port filters will happily allow web traffic to pass through. If there’s no response, nmap can assume with a decent amount of certainty that the host is down. You can change the port number nmap uses for TCP Pings by specifying –PT <port_number> on the command line.

Scanning for TCP Ports

The basic method of TCP port scanning is to do a TCP connect() (-sT) to a port to see whether anything responds. This is the same thing any TCP client would do to make a connection (complete the three-way handshake), except nmap will disconnect by sending a RST packet as soon as the handshake is complete. If you want to, you can use an RPC scan (-sR) to scan every open port for RPC services (that is, a portmapper). Following are some examples of these types of scans:

[bjohnson@originix ~]$ nmap -sT 192.168.1.109     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:17 EDT Interesting ports on cauliflower (192.168.1.109): (The 1639 ports scanned but not shown below are in state: closed) Port       State       Service 22/tcp     open        ssh 111/tcp    open        sunrpc 884/tcp    open        unknown 889/tcp    open        unknown 6000/tcp   open        X11     Nmap run completed -- 1 IP address (1 host up) scanned in 0.587 seconds [bjohnson@originix ~]$ nmap -sR 192.168.1.109     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:18 EDT Interesting ports on cauliflower (192.168.1.109): (The 1639 ports scanned but not shown below are in state: closed) Port       State       Service (RPC) 22/tcp     open        ssh 111/tcp    open        sunrpc (rpcbind V2) 884/tcp    open        (mountd V1-2) 889/tcp    open        (mountd V1-2) 6000/tcp   open        X11     Nmap run completed -- 1 IP address (1 host up) scanned in 3.320 seconds 

Notice how the –sR scan uses remote procedure call (RPC) commands on the open ports to determine whether they are RPC services. Nmap discovers the types and version numbers of the rpcbind and mountd services running on cauliflower. The following table indicates how the –sT, -sR, and –sP scans operate:

Nmap Sends to Host Port	Nmap Receives from Host Port	Nmap Responds	Nmap Assumes
SYN	SYN/ACK	ACK followed by RST	Port is open; host is up.
SYN	RST	–	Port is closed; host is up.
SYN	–	–	Port is blocked by firewall or host is down.

This is great, but since you’re just making basic TCP connections, your connection most likely gets logged by the service that answers. Sometimes you want to be a bit quieter.

Nmap lets you do some sneaky things with the TCP packets you use for port scanning. 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 set (a reset packet), nmap assumes the port is closed and nothing more is done. However, if it receives a response (indicated by a packet with the SYN/ACK flag set), instead of acknowledging that packet like a normal connection would, it sends a RST packet, as shown in the next table. Since the TCP three-way handshake is never completed, many services will not log the connection. Because you have to manipulate some of these TCP flags at a lower level, you can’t perform this kind of scan without root access to your system.

Nmap Sends to Host Port	Nmap Receives from Host Port	Nmap Responds	Nmap Assumes
SYN	SYN/ACK	RST	Port is open; host is up.
SYN	RST	–	Port is closed; host is up.
SYN	–	–	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 this kind of scan. Nmap has even sneakier scans for you to try, although a good IDS might still pick you up. 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 other side is supposed to respond with a RST packet. So why even bother sending a legitimate TCP packet? If a closed port on a host will always respond with a 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, which is normally used legitimately to close a connection. However, because we’re sending it before a connection has even been established, open ports should just ignore this garbage. Closed ports will still respond with a 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). Because we’re doing some low-level packet mangling, these scans also require root privileges. 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’ TCP/IP stacks don’t follow the specs and do this anyway. This means that you might get false positives with this scan on certain hosts. Also, any host that is protected by a firewall may return false positives. Nmap is assuming that the port is open if it receives nothing in response. What if a firewall is blocking that response? These scans are stealthier, but they’re also a lot less accurate.

Nmap Sends to Host Port	Nmap Receives from Host Port	Nmap Assumes
FIN	–	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 determine accurately whether the port is open or closed. Some firewalls, however, will filter only 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 (acknowledgement) packet is sent that is not part of an existing connection, the receiving side is supposed to respond by sending a RST. The ACK scan (-sA) can use this fact to determine whether or not a port is being filtered or blocked. If a 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 Sends to Host Port	Nmap Receives from Host Port	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 whether a host is being protected by a firewall that blocks only 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 ports 21 and 22 on 192.168.1.40 are being filtered by a stateless firewall; although the SYN is blocked, the ACK is able to pass through. An example of a stateless firewall is ipchains, which we’ll discuss in Chapter 13.

# nmap -sS 192.168.1.40     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:22 EDT Interesting ports on  (192.168.1.40): (The 1641 ports scanned but not shown below are in state: closed) Port       State       Service 21/tcp     filtered    ftp 22/tcp     filtered    ssh 80/tcp     open        http     Nmap run completed -- 1 IP address (1 host up) scanned in 4.321 seconds # nmap -sA 192.168.1.40     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:22 EDT All 1644 scanned ports on  (192.168.1.40) are: UNfiltered     Nmap run completed -- 1 IP address (1 host up) scanned in 4.660 seconds

Scanning 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. If no messages are received, the port is assumed to be open, as shown in the next table. You can see some flaws in this. If return ICMP messages are being blocked by a firewall, it will appear that all UDP ports on the host are open. Also, if the UDP traffic itself is being blocked by a firewall, it will still appear that the UDP ports are open. This is the same pitfall we saw in Netcat with UDP port scanning. Additionally, many hosts will send out only a certain number of ICMP error messages per second to avoid network saturation. Nmap will automatically adjust its scan rate when this is detected, but this can greatly slow down your UDP scans. Since UDP is a connectionless protocol and not bound to acknowledge receipt of incoming packets, there’s no good way around this problem.

Nmap Sends to Host Port	Nmap Receives from Host Port	Nmap Assumes
Empty UDP packet	-–	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.

Note 

Nmap, by default, tries to Ping a host before it starts scanning it. This is especially important for obtaining accurate UDP scan results. If nmap can’t Ping a host first (either because a firewall is blocking it or you manually turned off the feature using the –P0 option), it won’t be able to give accurate results.

Scanning for Protocols

If you attempt to contact a UDP port with nothing on the other end, the host sends back an ICMP “port unreachable” message. The same can be said for IP protocols. 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.

Hiding Your Scan

Nmap gives you several different scanning options, some of which can help keep your port scan from being detected by system logs, firewalls, and IDSs. Additionally, nmap gives you some of the same randomization and “spoofing” features that such programs as Netcat and hping provide.

FTP Bounce   By design, FTP has a rather glaring flaw that can be used to nmap’s advantage. When you connect to an FTP server using an FTP client, your client talks to the FTP server on TCP port 21. This TCP connection is referred to as the control connection. The FTP server will now need to make a separate connection with the client called a data connection, over which the actual file data will be transferred. The client will start listening for a data connection from the server on a separate TCP port. The client will then issue a PORT command to the server to tell it which port it has chosen and invite the server to make the connection. This method of operation is called an active transfer. Because many client machines use network address translation (NAT) or are firewalled off from outside connections, active FTP won’t usually work because the server-initiated connection (data connection) to the client won’t be able to pass through.

Note 

Passive transfers are what most FTP clients and servers use because the client initiates both control and data connections, bypassing firewall or NAT issues.

Let’s focus on this PORT command for a bit. Its legitimate use is to tell the server side of the FTP connection to connect back to the port we’ve just opened for the data connection. But because we can specify not only the port but the IP address to use, our client issuing the PORT command to the server could have the FTP server try to connect to anything, anywhere. Nmap can use this behavior to make a port scan appear to be coming from a vulnerable FTP server and interpret the results it receives. It’s called the FTP bounce scan. All nmap does is make an active-mode FTP connection to a server and send PORT commands consisting of the IP address and ports of the hosts it’s trying to scan. Nmap will then interpret its results and output them in the same format as a normal port scan.

Now, how do we find an FTP server we can abuse? That’s the great part. It’s a flaw in the design, not just an implementation bug. FTP servers that are compliant with RFC 959 for FTP have to implement this feature. Many FTP server packages, such as wu-ftpd, have been modified to allow only PORT commands back to the originating host, and most OS vendors with built-in FTP servers have made this adjustment as well. But some people will still be running outdated or unpatched FTP servers. It’s just another good reason you shouldn’t run an anonymous FTP server unless you absolutely need to.

Go ahead and choose an anonymous FTP server and give it a try:

nmap –b [e-mail]_host.com –p 6000 192.168.1.200

This command tries to use ftp.lame_host.com to scan port 6000 on 192.168.1.200 to tell you whether it is running an X server. And here’s a sample of the conversation that nmap has with this server.

 Server: 220 LAME_HOST 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 192,168,1,200,23,112 Server: 200 PORT command successful Client: LIST Server: 150 Opening ASCII connection for '/bin/ls' Server: 226 Transfer complete 

Nmap tells LameHost’s FTP server to open a connection to port 6000 on 192.168.1.200 using the PORT command. The last two digits at the end of the PORT command, 23 and 112, represent the port 6000 (FTP determines this by multiplying the first number by 256 and adding the second number: 23 × 256 + 112 = 6000). When that command is successful, it attempts to run the LIST command. Because it is able to open a connection, port 6000 is open on 192.168.1.200. If the server had instead said, “425 Can’t build data connection,” then we would know that port 6000 is closed.

If the PORT command works, you can not only frame someone else for your port scan, but you can now port scan any machine to which the FTP server has access. It’s a great way to sneak around port filters and firewalls that normally wouldn’t pass your scan probes. However, always use caution when you’re spoofing like this. Remember that FTP servers can log your connection. If someone accuses LameHost of scanning their network at 13:45 on January 6 and they’ve got an anonymous FTP from your home machine’s IP at that time, you’re toast.

Note 

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.

Idle Scan   In Chapter 14, you’ll learn about a tool called hping that uses an interesting technique to spoof the source address of a port scan but still retrieve the results. Nmap allows you to do something similar with the Idle scan (-sI). All you need to do is find a host that is passing little to no traffic and has a TCP/IP stack with a predictable IP ID increment. Refer to the hping Case Study in Chapter 14 for more information on this method of scanning.

Fragmentation   The -f option of nmap tells it to perform some of its stealth scans (-sS, -sF, -sX, or -sN) using fragmented IP packets that break up the TCP header. The idea is to keep these "mangled" TCP packets with unusual flags from being blocked by firewalls or detected by IDSs. This option can crash some systems and doesn’t work correctly on all Unix variants, so be careful if you use it.

Decoys   We’ve talked about how we’d like to be able to spoof our port scans while still being able to receive the port scan results (instead of having them sent to our unknowing spoof victim). We’ve also talked about how difficult this is to do (in Chapters 1 and 14); nmap tries a different approach. Nmap allows you to specify “decoy” hosts using the -D option. The idea is to pick several "spoof victim" hosts on the Internet and specify them in a comma-delimited list after the -D flag. Nmap will then perform its port scan as usual, but it will mix in spoofed port scans from the decoy IP addresses. A system administrator will see several different port scans, but only one of them is real.

Note 

Nmap’s -S option lets you set the source IP address of your packets. You can use this to spoof a single victim flat out by making it look as though the victim is scanning the target. This option is meant for multi-homed hosts, but it can be used to spoof and create general havoc. You won’t get your scan results back, but you can frame someone else for being a pest. But be careful when spoofing other people. If intrusion detectors or firewalls take actions against the decoys, you can end up drawing more attention to yourself instead of being stealthy.

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.

Timing Your Scan

Nmap uses rather appropriately named timing options for trying to hide your port scan from firewalls and IDSs that use time-based algorithms to determine whether or not you’re actually performing a scan. Additionally, you can indicate your own timing policy by using specific command-line flags. Table 4-2 details nmap’s built-in time policies and shows how to create your own using the appropriate nmap command-line options. You can use the named timing policies by specifying the –T option. The command nmap –T Sneaky –sS 192.168.1.100 –p 1-100 will attempt to avoid detection by using the Sneaky time policy and SYN scan method to scan the first 100 ports on 192.168.1.100.

Table 4-2: Nmap Timing Options and Policies

Name	Time Between Probes	Time Spent on One Host	Probe Response Timeout	Use Parallelized Probes
Paranoid	5 minutes	Unlimited	5 minutes	No
Sneaky	15 seconds	Unlimited	15 seconds	No
Polite	0.4 seconds	Unlimited	6 seconds (10 max)	No
Normal	None	Unlimited	6 seconds (10 max)	Yes
Aggressive	None	Unlimited	0.8 seconds (1.25 max)	Yes
Insane	None	15 minutes	0.3 seconds max	Yes
Create your own using these commandline options:	scan_delay	host_timeout	initial_rtt_timeout min_rtt_timeout max_rtt_timeout	max_parallelism min_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, so that, for example, you can give up after 5 minutes if your port scan is taking too long. The rtt_timeout options specify how long to wait in milliseconds for probe responses.

Nmap will, by default, always wait at least 0.3 second (300 milliseconds) for probe responses. It starts with the initial rtt_timeout value (the default is 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 will increase the rtt_timeout. But the timeout value always stays between the maximum and minimum. The lower the rtt_timeout, the more chance of missing open ports from systems that can’t respond as quickly.

The –max_parallelism and –min_parallelism options let you control how many probes can be run simultaneously. Setting the value of max_parallelism to 1 turns off parallelism. As with the rtt_timeout value, nmap tries to adjust the parallelism value intelligently depending on latency, system resources, and the like.

TCP Reverse Ident Scanning

If the remote host you’re scanning is running identd, which listens on TCP port 113 by default, nmap will try to find out information about the users running certain processes. Identd will tell you this kind of information, allowing you to find services running as root. A buffer overflow on a vulnerable service has a much better payoff if the service is running as the super user. Use the –I flag to enable this type of scan.

bash-2.04$ nmap –sT -I 192.168.1.210     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:28 EDT Interesting ports on  (192.168.1.210): (The 1630 ports scanned but not shown below are in state: closed) Port       State       Service                 Owner 21/tcp     open        ftp                     root 22/tcp     open        ssh                     root 23/tcp     open        telnet                  root 80/tcp     open        http                    nobody 111/tcp    open        sunrpc                  bin 113/tcp    open        auth                    nobody 512/tcp    open        exec                    root 513/tcp    open        login                   root 514/tcp    open        shell                   root 884/tcp    open        unknown                 root 889/tcp    open        unknown                 root 1024/tcp   open        kdm                     bjohnson 1032/tcp   open        iad3                    bjohnson 6000/tcp   open        X11                     root     Nmap run completed -- 1 IP address (1 host up) scanned in 3.173 seconds

We’ve found several services running as root, including FTP and telnet. Next we might want to connect to these ports directly to determine the version number of the service and check it against known vulnerable versions of FTP and telnet servers. A vulnerable FTP or telnet service on this box could mean root access for a hacker.

Note 

Because nmap must make valid connections to the identd service to determine this information, the –I option can’t be used in a stealth scan.

OS Fingerprinting

One of the most useful features nmap offers is the ability to identify hosts remotely without relying on application banners. Nmap can often tell you what OS a host is running, sometimes down to the version and revision level, simply by performing its network scans. How can it do this? When the -O flag is specified, nmap uses several different techniques to look for particular identifying traits in the IP packets returned from hosts. By sending specially crafted TCP and UDP headers, nmap can get an idea of how the remote host speaks IP. In addition to analyzing the TCP/IP stack, nmap also uses a few ICMP techniques to further refine its detection granularity. It then analyzes the results and compares the information it discovers with known “traits” that are kept in a file (the “nmap-os-fingerprints” file). This file is maintained by nmap’s developer. If you scan a host with a known operating system using the –O flag and nmap can’t recognize it, it will output the cryptic results from its identification tests as well as a URL for submitting that information to nmap’s developer. Just drop in the output from the test and the name of the OS, and nmap will include that fingerprint in its next version. Alternatively, you can use the –-osscan_guess or –-fuzzy command line options (the two are synonymous), which tell nmap to be more flexible in its OS guessing technique. This increases your chances of coming up with a fingerprint match, but it decreases reliability.

The OS detection option can also perform TCP packet analysis to determine such information as 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.

For more information on nmap’s OS fingerprinting, see the Case Study at the end of this section.

Version Detection

Starting with nmap version 3.45, a new feature called version detection was added to help nmap more accurately determine the services listening on particular ports. Whereas normal nmap scans identify open ports using a static “well-known ports” file called nmap-services, the version detection scan (-sV) will actually send probe text to each service in hopes of obtaining a “banner” or service identification string. It tells you exactly what is running on a given port instead of just telling you what service is usually run on that port. An example scan would look like this:

bash-2.04$ nmap -sV 192.168.1.50     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-06 14:08 GMT Interesting ports on 192.168.1.50: (The 1637 ports scanned but not shown below are in state: closed) PORT    STATE SERVICE VERSION 21/tcp  open  ftp     WU-FTPD wu-2.5.0 22/tcp  open  ssh     OpenSSH 3.6.1p2 (protocol 2.0) 23/tcp  open  telnet  Linux telnetd 80/tcp  open  http    Apache httpd 1.3.14 ((Unix)  (Red-Hat/Linux)) 512/tcp open  exec? 513/tcp open  rlogind 514/tcp open  shell? 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at  http://www.insecure.org/cgi-bin/servicefp-submit.cgi : SF-Port512-TCP:V=3.48%D=10/6%Time=3F817758%r(NULL,10,"\x01Where\x20are\x20 SF:you\?\n");     Nmap run completed -- 1 IP address (1 host up) scanned in 21.111 seconds 

Nmap was able to determine the types and versions of FTP, SSH, and Apache web servers running on this box. Just as with OS Fingerprinting, if nmap can’t identify a service but receives a response, you can submit the service’s fingerprint to the developer for inclusion in future versions. The file nmap-service-probes contains all the current service fingerprints and can be found in the /usr/local/share/nmap directory by default.

Version detection is very handy. It gives you more accurate service information and it can be run with normal user privileges. However, it is extremely noisy in the system logs. Any time you run a version detection against a system, it will most likely leave a rather large footprint.

Command-Line Option Summary

We’ve already covered many of nmap’s command-line options in our discussions of nmap’s usage. However, let’s touch on the rest of the options that we haven’t talked about yet. The following list details these options.

• –P0 –PT –PS –PU –PE –PP –PM –PB   Nmap always attempts to Ping a host before it performs any other kind of port or protocol scan on it. This is an attempt at not wasting time on hosts that aren’t up. But many hosts and firewalls will block ICMP Ping traffic, so we want to have some control over what kind of Ping nmap uses to determine a host’s status.

  • –P0 says don’t Ping at all—just blindly scan.

  • -PT says use a TCP Ping (which basically telnets to port 80 if you’re not the super user but uses the ACK scanning technique on 80 if you are). Specifying a port or port range after the –PT option tells nmap to use a port other than 80.

  • –PS sends SYN packets (again, if you’re the super user). Specifying a port or port range after the –PS option tells nmap to use a port other than 80.

  • -PU sends a UDP Ping (a UDP packet to port 31338 by default). Specifying a port or port range after the –PU option tells nmap to use a port other than 31338.

  • –PE forces straight ICMP Ping and replaces the old –PI option. –PP and –PM are identical to –PE except that they use ICMP timestamp requests and ICMP netmask requests, respectively.

  • –PB, which is the default type, tries both ICMP and TCP Ping. This flag has been deprecated, as you can get the same effect using a combination of –PT and –PE.

• -6   This flag enables IPv6 support, which is not covered in this book.

• –v –d   The -v option gives you more verbose nmap 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.

• –oN –oX –oG –oA –oM –oS <logfile>   With many programs, if you want to see the output on screen and send it to a file, you have to use the Unix tee command. Nmap gives you logging options for recording the data from your scan:

  • –oN logs basically everything that gets output to the screen in a human-readable format. This is useful if you’re scanning several machines.

  • -oX logs information in XML format to the file specified.

  • -oG logs information in "greppable" format, meaning that each host has all its port and OS information on an individual line. This allows you to use the grep utility to search for patterns (such as particular OSs or port numbers) and easily interpret the results.

  • -oA logs in normal (-oN), XML (-oX), and greppable (-oG) formats, using <logfile> as a base filename.

  • –oM formats the output into a machine-readable file (that can be reinterpreted by nmap later).

  • –oS formats the output in "script kiddie" typeset—just to be obnoxious.

• --resume <logfile>   If you cancel a scan (CTRL-C) but you were making a human-readable (-oN) or greppable (-oG) logfile, you can continue the scan by feeding that logfile to nmap.

• --append_output   When used with a –o option for output, nmap appends output to the file instead of overwriting it.

• –iR <numhosts> –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 followed by the number of hosts you want to generate. Alternatively, 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.

• –F   Tells nmap to scan only for “known” ports in nmap’s built-in services file (nmap-services). Without this option, nmap scans ports 1–1024 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 built-in protocols file (nmap-protocols) instead of the default action of scanning for all 256 protocols.

• -A   Tells nmap to use all of its advanced scanning options in tandem, currently OS identification (-O) and version detection (-sV).

• –p <ports>   Obviously, at some point you need to tell nmap which ports you want to scan. <ports> 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 1024 ports (see the description of the –F option).

• –e <interface>   On a multi-homed host, you can specify on which network interface you want to communicate. Nmap usually handles this on its own.

• –g <port>   Lets you select a source port from which to perform all of your scanning. This 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).

• --data_length <number>   Tells nmap to pad the data portion of its TCP, UDP, and ICMP packets with <number> bytes of random data. Scans will be slower but may not be detected as port scans because they contain data.

• --ttl <value>   Tells nmap that any packets it sends out should “expire” after <value> number of hops to intermediate routers.

• --packet_trace   One of the most useful new options, this displays a detailed list of each packet nmap sends and receives during its scan. This can be useful for debugging. You’ll need root privileges to use this option, and you’ll probably want to use it in conjunction with one of the –o options to log all the data to a file.

• --version_trace   Like the packet_trace option above, except it displays debugging information for the version detection scanning.

• --datadir <directory>   If you have your own copies of nmap data files such as nmap-services, nmap-protocols, or nmap-os-fingerprints, you can put them all in one directory and have nmap use them with this option. The default data directory is /usr/local/share/nmap.

• --scanflags <flags>   This is a “hidden” nmap option that you won’t find in the man page. You can use this option to specify manually the TCP flags you want set in your scanning packets. You can either specify an integer representation of the ORed values of the TCP flags or a string representation of the flags (such as “URGPSH” to set both the URG and PUSH TCP flags).

Nmapfe

Nmap comes with its own graphical front end that you can use if you’re running the X Window System. The program is called 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: Nmap frontend

Case Study: Mapping Networks and Potential Targets

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 (an old Linux system with an IP address of 192.168.1.100). We'll start off with a Ping-only scan (the –sP option) of the entire 192.168.1.0 network. We can specify this target in several ways on the command line:

nmap –sP "192.168.1.*" nmap –sP 192.168.1.0/24 nmap –sP 192.168.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.

bash-2.04$ nmap -sP 192.168.1.1-254     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:30 EDT  Host  (192.168.1.1) appears to be up. Host  (192.168.1.100) appears to be up. Host  (192.168.1.101) appears to be up. Host (192.168.1.102) appears to be up. Nmap run completed -- 254 IP addresses (4 hosts up) scanned in 8.093 seconds

We now know which hosts on the network responded to Pings. But what if some hosts are blocking ICMP Pings? If you recall, by default nmap uses both ICMP and TCP Pings (refer to the –P option). So this should be a complete list. Now we can focus our actual port scans on just these four systems. Let's try running nmap without any options against these four systems and see what happens:

bash-2.04$ nmap 192.168.1.1,100-102     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:30 EDT Interesting ports on  (192.168.1.1): (The 1643 ports scanned but not shown below are in state: closed) Port       State       Service 80/tcp     open        http     Interesting ports on  (192.168.1.100): (The 1634 ports scanned but not shown below are in state: closed) Port       State       Service 21/tcp     open        ftp 22/tcp     open        ssh 23/tcp     open        telnet 80/tcp     open        http 512/tcp    open        exec 513/tcp    open        login 514/tcp    open        shell 1024/tcp   open        kdm 1032/tcp   open        iad3 6000/tcp   open        X11     Interesting ports on  (192.168.1.101): (The 1642 ports scanned but not shown below are in state: closed) Port       State       Service 139/tcp    open        netbios-ssn 641/tcp    open        unknown     Interesting ports on  (192.168.1.102): (The 1640 ports scanned but not shown below are in state: closed) Port       State       Service 21/tcp     open        ftp 22/tcp     open        ssh 23/tcp     open        telnet 80/tcp     open        http     Nmap run completed -- 4 IP addresses (4 hosts up) scanned in 17.165 seconds

Notice the syntax for specifying the target. As with ports, we can specify IP addresses using a combination of comma-separated lists and ranges. Now we've just performed a default scan. This means that it scanned only the ports defined in nmap's services file in addition to ports 1–1024; it used the generic TCP connect() method (the loudest possible); and it used the Normal timing option (no delay). Let's see how the Unix messages log looks now on 192.168.1.100:

Mar 15 20:25:33 originix in.telnetd[1653]: warning: can't get client address: Connection reset by peer Mar 15 20:25:33 originix in.telnetd[1653]: refused connect from unknown Mar 15 20:25:34 originix in.rlogind[1655]: warning: can't get client address: Connection reset by peer Mar 15 20:25:34 originix in.rlogind[1655]: refused connect from unknown Mar 15 20:25:34 originix in.ftpd[1656]: warning: can't get client address: Connection reset by peer Mar 15 20:25:34 originix in.ftpd[1656]: refused connect from unknown Mar 15 20:25:34 originix in.rshd[1658]: warning: can't get client address: Connection reset by peer Mar 15 20:25:34 originix in.rshd[1658]: refused connect from unknown Mar 15 20:25:34 originix in.rexecd[1657]: warning: can't get client address: Connection reset by peer Mar 15 20:25:34 originix in.rexecd[1657]: refused connect from unknown

Note 

None of these individual services log this kind of traffic on its own. Use of TCP wrappers (inetd or xinetd) is imperative in obtaining this kind of information.

It's pretty obvious they were port scanned, but these services weren't able to determine the client IP address. That's because nmap sent a reset (RST) packet after the TCP handshake was complete instead of a FIN. Some services won't be able to capture the IP address of the scanner in this case. Some services will, however, and regardless, we've still left a lot of evidence in the log. Let's become root and try a SYN scan with a “sneaky” timing policy. The scan will take a little longer, but hopefully it won't be so loud. We'll do this only on 192.168.1.100 so we can watch the logs. When performing scans with stealthy timing options, it's not a bad idea to use a –v or –d flag so you can keep tabs on what's going on. The output will be too long to include here, but here's the command line.

# nmap -d -v -v -sS -T Sneaky -p 20-80 192.168.1.100

The problem with stealth scans is that they take a long time. So we'll want to shrink our port range. Even 20–80 is going to take at least 15 seconds multiplied by 61 ports. That's more than 15 minutes! And that doesn't even take into account the 15-second wait time for probe responses. Obviously, stealth scans are better suited if you're looking for a particular port on a range of machines (perhaps hoping that a vulnerable service is running behind it).

The goal was achieved, however, as our logs on 192.168.1.100 picked up nothing. And 15-second wait times might be long enough to keep an IDS from detecting us.

Let's see how nmap's OS detection works. We are using the –O option to scan three machines: 192.168.1.1, 192.168.1.100, and 192.168.1.101. Let's see what nmap finds:

# nmap -O 192.168.1.1,100,101     Starting nmap V. 2.54BETA30 ( www.insecure.org/nmap/ ) Interesting ports on  (192.168.1.1): (The 1548 ports scanned but not shown below are in state: closed) Port       State       Service 80/tcp     open        http     No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi). TCP/IP fingerprint: SInfo(V=2.54BETA30%P=i386-unknown-freebsd4.3%D=3/16%Time=3C9346F5%O=80%C=1) TSeq(Class=TD%gcd=1A4%SI=0%IPID=Z%TS=U) T1(Resp=Y%DF=N%W=400%ACK=S++%Flags=AR%Ops=) T2(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=) T3(Resp=Y%DF=N%W=400%ACK=S++%Flags=AR%Ops=) T4(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=) T5(Resp=Y%DF=N%W=400%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=400%ACK=S%Flags=AR%Ops=) T7(Resp=Y%DF=N%W=400%ACK=S++%Flags=AR%Ops=) PU(Resp=N)     Interesting ports on  (192.168.1.100): (The 1540 ports scanned but not shown below are in state: closed) Port       State       Service 21/tcp     open        ftp 22/tcp     open        ssh 23/tcp     open        telnet 80/tcp     open        http 512/tcp    open        exec 513/tcp    open        login 514/tcp    open        shell 1024/tcp   open        kdm 6000/tcp   open        X11     Remote operating system guess: Linux 2.1.19 - 2.2.17 Uptime 2.597 days (since Wed Mar 13 23:00:28 2002) Interesting ports on  (192.168.1.101): (The 1547 ports scanned but not shown below are in state: closed) Port       State       Service 139/tcp    open        netbios-ssn 641/tcp    open        unknown     Remote operating system guess: Windows 98 w/ Service Pack 1     Nmap run completed -- 2 IP addresses (2 hosts up) scanned in 12 seconds

These results were obtained with an older version of nmap (2.54). Nmap's OS detection correctly guessed our Linux and Windows boxes. It even determined the uptime of the Linux box. Nmap had trouble with our Linksys router, though. This fingerprint was submitted to the developers (using http://www.insecure.org/cgi-bin/nmap-submit.cgi) so that this Linksys would be identifiable in future versions of nmap. Let's run the scan again with version 3.48 of nmap:

# nmap -O 192.168.1.1     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-08 16:34 EDT Interesting ports on 192.168.1.1: (The 1643 ports scanned but not shown below are in state: closed) Port       State       Service 80/tcp     open        http Device type: WAP|broadband router Running: Linksys embedded OS details: Linksys BEFW11S4 WAP or BEFSR41 router     Nmap run completed -- 1 IP address (1 host up) scanned in 6.846 seconds

Voilà! Nmap can now identify the Linksys access point down to its model number. Nmap's OS fingerprint database now contains nearly 1000 different signatures!

Case Study: Ports Painting a Picture

Using a port scanner, we can quickly get a map of the different services running on a remote host. If we make a TCP connection to port 80 and get a response, chances are the host is running a web server. By analyzing the response, we can verify this supposition. A port scan can provide information necessary in identifying target hosts. Identifying the services running on a host can tell us the host's purpose and hint to several places we can check for holes. Listening behind every open port might be a vulnerable service just waiting to be exploited.

Because different operating systems come with different services installed and running by default, sometimes the output of a port scan alone can help identify the host's operating system. Let's do a port scan of a box on my network and see what we can find.

[bjohnson@originix ~]$ nmap –sT -I 192.168.1.100     Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2003-10-10 16:28 EDT Interesting ports on  (192.168.1.100): (The 1636 ports scanned but not shown below are in state: closed) Port       State       Service 21/tcp     open        ftp 22/tcp     open        ssh 23/tcp     open        telnet 80/tcp     open        http 1024/tcp   open        kdm 1030/tcp   open        iad1 6000/tcp   open        X11 8888/tcp   open        sun-answerbook     Nmap run completed -- 1 IP address (1 host up) scanned in 1.413 seconds

Looks like this box is running a lot of the usual suspects: FTP, SSH, telnet, and Web. Eventually, we might want to see what happens when we FTP, telnet, or point a web browser at this host. But what's this last entry—sun-answerbook? With some research, we find that this service is typically installed by default and runs at startup on most Sun systems. Looks like we've found a Sun Solaris host.

But not so fast. Just because something answered on port 8888, a port used by the Answerbook service, doesn't mean that it's actually Answerbook! It could be anything: a web server, an FTP server, or a backdoor shell set up by a hacker! As it turns out, the system administrator set up the Netcat tool (see Chapter 1) to listen on port 8888 as a sort of trap. The sysadmin might be able to fool the untrained hacker into thinking that a Linux box is actually a Sun host.

THC-Amap

Before Nmap 3.45, when nmap printed out its open port list, next to each port it told you which service usually runs on that port (21 for FTP, 22 for SSH, 23 for Telnet, and so on). However, what if someone is running one of those services on a nonstandard port? If someone is running a telnet server listening on TCP port 110, for example, a port usually reserved for the POP3 mail retrieval protocol, nmap would have told you it found a POP3 server running—not a telnet server. Nmap’s new version detection scanning in versions 3.45 and later will actually ask the service what it is; older versions can only make an educated guess.

THC-amap is a port scanning utility that actually examines the way a service responds. You can download Amap from The Hacker’s Choice web site (http://www.thc.org/). It is a Unix tool and installs via the standard Unix method.

Implementation

The easiest way to use amap is to give it an output file generated by nmap. If you create a machine-readable output file with nmap (using nmap –oM output.nmap), you can feed that output file to amap using amap –i output.nmap. You can also use amap to scan a host directly.

Following is an example of an nmap RPC scan (nmap –sR) on a host. Because it uses the RPC scanning method, it is able to obtain application information about the actual services running on ports registered with the portmapper. In this example, it knows that 903 and 908 are being used by NFS’s mountd.

localhost# nmap -oM output.nmap -sR 192.168.1.50     Starting nmap 3.30 ( http://www.insecure.org/nmap/ ) at 2003-07-22 18:54 EDT Interesting ports on originix (192.168.1.50): (The 1639 ports scanned but not shown below are in state: closed) Port       State       Service (RPC) 22/tcp     open        ssh 111/tcp    open        sunrpc (rpcbind V2) 903/tcp    open        (mountd V1-2) 908/tcp    open        (mountd V1-2) 6000/tcp   open        X11     Nmap run completed -- 1 IP address (1 host up) scanned in 0.700 seconds 

However, watch what happens when we feed this output.nmap file to amap:

localhost# amap -i output.nmap amap v4.3 started at 2003-10-06 16:31:29 – APPLICATION MAP mode Protocol on IP 192.168.1.50 port 6000 tcp matches telnet Protocol on IP 192.168.1.50 port 22 tcp matches ssh Protocol on IP 192.168.1.50 port 22 tcp matches ssh-openssh Protocol on 192.168.1.50:111/tcp matches rpc Protocol on 192.168.1.50:111/tcp matches rpc-rpcbind-v2 Protocol on 192.168.1.50:846/tcp matches rpc Protocol on 192.168.1.50:846/tcp matches rpc-mountd-v2 Unidentified ports: 192.168.1.50:908/tcp (total 1). amap v4.3 finished at 2003-10-06 16:31:33

Amap reports that it’s found a telnet server running on TCP port 6000. Because this port is usually used by an X server, nmap simply assumed it was an X server. Amap was able to determine that it was in fact a “hidden” telnet server.

localhost# telnet 192.168.1.50 6000 Trying 192.168.1.50... Connected to 192.168.1.50. Escape character is '^]'. Welcome to Rogue Telnet Server! Use username admin, password gogogo to gain access! login:

How does amap work this magic? The answer lies in the appdefs files. Amap comes with three different database files: appdefs.resp, appdefs.rpc, and appdefs.trig. The appdefs.trig file contains a list of triggers used to make a service listening on an open port respond. When amap finds an open port, it runs through all the triggers in this file to see what kind of response it gets. Here is a snippet of the default appdefs.trig file:

smtp:25:tcp:0:"HELO AMAP\r\n" ftp:21:tcp:0:"USER AMAP\r\n" rpc:111,2049:udp:1:0x03 9b 65 42 00 00 00 00 00 00 00 02 00 0f 42 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 rpc:111,2049:tcp:1:0x80 00 00 28 18 72 db 5a 00 00 00 00 00 00 00 02 00 01 86 a0 00 00 00 02 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 dns:53:udp:1:0x00 00 10 00 00 00 00 00 00 00 00 00 dns:53:tcp:1:0x00 0c 00 00 10 00 00 00 00 00 00 00 00 00 dns-bind:53:udp:1:0x00 06 01 00 00 01 00 00 00 00 00 00 07 76 65 72 73 69 6f 6e 04 62 69 6e 64 00 00 10 00 03 ldap:389:tcp:1:0x30 0c 02 01 01 60 07 02 01 02 04 00 80 00 

Notice the format of each line. The line begins with a protocol name, followed by the port and transport protocol, the volatility of the probe (a 1 means it could be harmful to the listening service), and finally the outgoing data for the probe. For example, the trigger for FTP tells amap to issue a USER AMAP command to every listening service in an attempt to find an FTP server.

The appdefs.resp file is a list of signature responses matched with the appropriate protocol names. Anytime amap gets a response from one of its trigger probes, it tries to match the response it gets with one (or more) of the responses listed in appdefs.resp to determine what application-level protocol the service is using. Here is a snippet of the default appdefs.resp file:

# HTTP http::tcp::^HTTP/0. http::tcp::^HTTP/1. http::tcp::<HEAD>.*<BODY> http::tcp::<HTML>     # FTP ftp:ftp:tcp::^220.*\n331 ftp:ftp:tcp::^220.*\n530 ftp::tcp::^220.*FTP ftp::tcp::^220 .* Microsoft .* FTP

If amap issued its FTP trigger to an FTP server, it would expect to receive a response that matched one of the regular expressions listed with the “ftp” protocol in this file.

The appdefs.rpc file is a list of RPC services and their matching RPC ID numbers. This is the same kind of data used by nmap to identify RPC services using its RPC scan.

You can create your own responses and triggers to help improve amap’s reliability and functionality. If you find services that are unidentified, you can run the amapcrap utility to send random “stuff” to the port. The amapcrap utility will output the lines you should use in your appdefs.trig and appdefs.resp to identify the service. Sometimes, however, amapcrap won’t be quite as helpful. For example, we used amapcrap to generate random ASCII triggers between 4 and 10 bytes long and sent them to a web server running on a Linksys Cable/DSL Router and a Linksys Wireless Access Point Router. We noticed that the results from both probes were identical.

localhost# amapcrap -M 4,10 -m a 192.168.1.1 80 # Starting AmapCrap on 192.168.1.1 port 80 # Writing a "+" for every 10 connect attempts #     # Put this line into appdefs.trig: PROTOCOL_NAME::tcp:0:"ihz\r\n"     # Put this line into appdefs.resp: PROTOCOL_NAME::tcp::0x485454502f312e312034303120417574686f72697a6174696f6e2052 657175697265640d0a5757572d41757468656e7469636174653a204261736963207265616c6d3d 224c696e6b73797320424546535234312f424546535231312f4245465352553331220d0a436f6e 74656e742d747970653a20746578742f68746d6c0d0a457870697265733a205468752c20313320 44656320313936392031303a32393a303020474d540d0a436f6e6e656374696f6e3a20636c6f73 650d0a507261676d613a206e6f2d63616368650d0a0d0a3c68746d6c3e3c686561643e3c746974 6c653e34303120417574686f72697a6174696f6e2052657175697265643c2f7469746c653e3c2f 686561643e3c626f6479206267636f6c6f723d72656420746578743d77686974653e3c68313e34 303120417574686f72697a6174696f6e2052657175697265643c2f68313e546869732073657276 657220636f756c64206e6f7420766572696679207468617420796f752061726520617574686f72 697a656420746f206163636573732e2045697468657220796f7520737570706c69656420746865 2077726f6e672063726564656e7469616c7328652e672e2c206261642070617373776f7264292c 206f7220796f75722062726f7773657220646f65736e277420756e6465727374616e6420686f77 20746f20737570706c79207468652063726564656e7469616c732072657175697265642e3c2f62 6f64793e3c2f68746d6c3e00 

By copying and pasting this text into the appropriate files and renaming the PROTOCOL_NAME to something meaningful (such as linksys-www), amap should now be able to identify Linksys network appliances when you check the web service it’s running on port 80. We were able to make this work with version 2.7 of amap, but apparently THC hasn’t been keeping amapcrap current with amap. When we put the previous long hex string into the appdefs.resp file, we got an error message saying that the line is too long. Thankfully, you don’t have to rely solely on amapcrap. Try running amap with the –d option on the Linksys web port.

localhost# amap –d 192.168.1.1 80 amap v4.3 (www.thc.org) started at 2003-10-06 16:51:01 - APPLICATION MAP mode Protocol on 192.168.1.1:80/tcp matches http Protocol on 192.168.1.1:80/tcp matches http 0000:  4854 5450 2f31 2e31 2034 3031 2041 7574    [ HTTP/1.1 401 Aut ] 0010:  686f 7269 7a61 7469 6f6e 2052 6571 7569    [ horization Requi ] 0020:  7265 640d 0a57 5757 2d41 7574 6865 6e74    [ red..WWW-Authent ] 0030:  6963 6174 653a 2042 6173 6963 2072 6561    [ icate: Basic rea ] 0040:  6c6d 3d22 4c69 6e6b 7379 7320 4245 4653    [ lm="Linksys BEFS ] 0050:  5234 312f 4245 4653 5231 312f 4245 4653    [ R41/BEFSR11/BEFS ] 0060:  5255 3331 220d 0a43 6f6e 7465 6e74 2d74    [ RU31"..Content-t ] 0070:  7970 653a 2074 6578 742f 6874 6d6c 0d0a    [ ype: text/html.. ] 0080:  4578 7069 7265 733a 2054 6875 2c20 3133    [ Expires: Thu, 13 ] 0090:  2044 6563 2031 3936 3920 3130 3a32 393a    [  Dec 1969 10:29: ] 00a0:  3030 2047 4d54 0d0a 436f 6e6e 6563 7469    [ 00 GMT..Connecti ]

This is helpful. In the output, we can see a reference to Linksys. Therefore, instead of using the long hex output string that amapcrap suggested, we can define our own Linksys identifier in appdefs.resp:

linksys-www:80:tcp::.*Linksys 

By adding this line to appdefs.resp, any TCP service responding on port 80 that contains the text “Linksys” in its output will match the linksys-www response and be identified as such.

Several amap command line options let you tweak its behavior, from limiting specific protocol triggers to controlling timing and formatting output. The command line options are listed in the following table.

Command-line Options	Description
Modes
-A	Send triggers to listening services and analyze responses (default)
-B	Do not actively send triggers, just grab banners that are sent to us upon connection
-P	Just scan for open ports
Options
-1	Speed up the scan by stopping a service analysis after the first response signature it matches
-b	Print ASCII banner of responses
-i <FILE>	Scan machines and ports from this Nmap generated output file
-u	Ports specified on command line are UDP (default is TCP)
-R	Do not identify RPC service
-H	Do not send application triggers marked as potentially harmful
-U	Do not dump unrecognized responses
-d	Dump all responses
-v	Verbose mode, use twice for debug information
-q	Do not report closed ports, and do not print them as unidentified
-o <FILE>	Write output to file <FILE>
-m	Make output to file (-o) machine-readable (colon-separated list)
-c CONS	Amount of parallel connections to make (default 32, maximum 256)
-C RETRIES	Number of reconnects on connect timeouts (see -T) (default 3)
-T SEC	Connect timeout on connection attempts in seconds (default 5)
-t SEC	Response wait timeout in seconds (default 5)
-p PROTO	Send triggers for this protocol only
-D <FILE>	Read definitions from <FILE>.trig, <FILE>.resp, and <FILE>.rpc instead of the default (appdefs.trig, appdefs.resp, and appdefs.rpc)
-h	Print the command-line arguments and usage

Amap is a sophisticated “banner grabber,” something we’ll discuss more in the following sections. But amap is useful only if its three signature files are kept updated and accurate. Regardless, although it’s not always foolproof, amap is a powerful, accurate tool for determining what services are running on a host.

---