There are lots of different scanning options, each with its own purpose. The SYN packet scan that we're using here is considered a stealthy type of scan because it generates less network traffic and fewer system log entries than certain other types of scans. With this type of scan, Nmap sends a SYN packet to a port on the target machine, as if it were trying to create a TCP connection to that machine. If the target machine responds with a SYN/ACK packet, it means that the port is in an open state and is ready to create the TCP connection. If the target machine responds with an RST packet, it means that the port is in a closed state. If there's no response at all, it means that the port is filtered, blocked by a firewall. As a normal Linux administrator, this is one of the types of scans that you would do most of the time.
The -sS scan shows you the state of TCP ports, but it doesn't show you the state of UDP ports. To see the UDP ports, use the -sU option:
donnie@linux-0ro8:~> sudo nmap -sU 192.168.0.37
Starting Nmap 6.47 ( http://nmap.org ) at 2017-12-28 12:41 EST
Nmap scan report for 192.168.0.37
Host is up (0.00018s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
123/udp open ntp
631/udp open|filtered ipp
3283/udp open|filtered netassistant
5353/udp open zeroconf
MAC Address: 00:0A:95:8B:E0:C0 (Apple)
Nmap done: 1 IP address (1 host up) scanned in 119.91 seconds
donnie@linux-0ro8:~>
Here, you can see something a bit different: two ports are listed as open|filtered. That's because, due to the way that UDP ports respond to Nmap scans, Nmap can't always tell whether a UDP port is open or filtered. In this case, we know that these two ports are probably open because we've already seen that their corresponding TCP ports are open.
ACK packet scans can also be useful, but not to see the state of the target machine's network services. Rather, it's a good option for when you need to see if there might be a firewall blocking the way between you and the target machine. An ACK scan command looks like this:
sudo nmap -sA 192.168.0.37
You're not limited to scanning just a single machine at a time. You can scan either a group of machines or an entire subnet at once:
sudo nmap -sS 192.168.0.1-128
sudo nmap -sS 192.168.0.0/24
The first command scans only the first 128 hosts on this network segment. The second command scans all 254 hosts on a subnet that's using a 24-bit netmask.
A discovery scan is useful for when you need to just see what devices are on the network:
sudo nmap -sn 192.168.0.0/24
With the -sn option, Nmap will detect whether you're scanning the local subnet or a remote subnet. If the subnet is local, Nmap will send out an Address Resolution Protocol (ARP) broadcast that requests the IPv4 addresses of every device on the subnet. That's a reliable way of discovering devices because ARP isn't something that will ever be blocked by a device's firewall. (I mean, without ARP, the network would cease to function.) However, ARP broadcasts can't go across a router, which means that you can't use ARP to discover hosts on a remote subnet. So, if Nmap detects that you're doing a discovery scan on a remote subnet, it will send out ping packets instead of ARP broadcasts. Using ping packets for discovery isn't as reliable as using ARP because some network devices can be configured to ignore ping packets. Anyway, here's an example from my own home network:
donnie@linux-0ro8:~> sudo nmap -sn 192.168.0.0/24
Starting Nmap 6.47 ( http://nmap.org ) at 2017-12-25 14:48 EST
Nmap scan report for 192.168.0.1
Host is up (0.00043s latency).
MAC Address: 00:18:01:02:3A:57 (Actiontec Electronics)
Nmap scan report for 192.168.0.3
Host is up (0.0044s latency).
MAC Address: 44:E4:D9:34:34:80 (Cisco Systems)
Nmap scan report for 192.168.0.5
Host is up (0.00026s latency).
MAC Address: 1C:1B:0D:0A:2A:76 (Unknown)
. . .
. . .
We can see three hosts in this snippet, and there are three lines of output for each host. The first line shows the IP address, the second shows whether the host is up, and the third shows the MAC address of the host's network adapter. The first three pairs of characters in each MAC address denote the manufacturer of that network adapter. (For the record, that unknown network adapter is on a recent model Gigabyte motherboard. I have no idea why it's not in the Nmap database.)
The final scan that we'll look at does four things for us:
- It identifies open, closed, and filtered TCP ports.
- It identifies the versions of the running services.
- It runs a set of vulnerability scanning scripts that come with Nmap.
- It attempts to identify the operating system of the target host.
The scan command that does all of these things looks like this:
sudo nmap -A 192.168.0.37
I guess that you could think of the -A option as the all option since it really does do it all. (Well, almost all, since it doesn't scan UDP ports.) First, here's the command that I ran to do the scan:
donnie@linux-0ro8:~> sudo nmap -A 192.168.0.37
Here are the results, broken down into sections for formatting purposes:
Starting Nmap 6.47 ( http://nmap.org ) at 2017-12-24 19:33 EST
Nmap scan report for 192.168.0.37
Host is up (0.00016s latency).
Not shown: 996 closed ports
Right away, we can see that there's no active firewall on this machine because no ports are in the filtered state. By default, Nmap scans only the most 1,000 most popular ports. Since 996 ports are in the closed state, we obviously only have four active network services that would listen on any of these 1,000 ports:
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.1 (protocol 1.99)
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
|_sshv1: Server supports SSHv1
515/tcp open printer?
Port 22 is open for Secure Shell access, which we would normally expect. However, look at the SSH version. Version 5.1 is a really old version of OpenSSH. (At the time of writing, the current version is version 8.1.) What's worse is that this OpenSSH server supports version 1 of the Secure Shell protocol. Version 1 is seriously flawed and is easily exploitable, so you never want to see this on your network.
Next, we have amplifying information on the print service vulnerability that we found with the OpenVAS scan:
631/tcp open ipp CUPS 1.1
| http-methods: Potentially risky methods: PUT
|_See http://nmap.org/nsedoc/scripts/http-methods.html
| http-robots.txt: 1 disallowed entry
|_/
|_http-title: Common UNIX Printing System
In the 631/tcp line, we can see that the associated service is ipp. This protocol is based on the same HTTP that we use to look at web pages. The two methods that HTTP uses to send data from a client to a server are POST and PUT. What we really want is for every HTTP server to use the POST method because the PUT method makes it very easy for someone to compromise a server by manipulating a URL. So, if you scan a server and find that it allows using the PUT method for any kind of HTTP communications, you have a potential problem. In this case, the solution would be to update the operating system and hope that the updates fix the problem. If this were a web server, you'd want to have a chat with the web server administrators to let them know what you found.
Next, we can see that the VNC service is running on this machine:
5900/tcp open vnc Apple remote desktop vnc
| vnc-info:
| Protocol version: 3.889
| Security types:
|_ Mac OS X security type (30)
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-Port515-TCP:V=6.47%I=7%D=12/24%Time=5A40479E%P=x86_64-suse-linux-gnu%r(
SF:GetRequest,1,"x01");
MAC Address: 00:0A:95:8B:E0:C0 (Apple)
Device type: general purpose
VNC can be handy at times. It's like Microsoft's Remote Desktop service for Windows, except that it's free, open source software. But it's also a security problem because it's an unencrypted protocol. So, all your information goes across the network in plain text. If you must use VNC, tunnel it run it through an SSH tunnel.
Next, let's see what Nmap found out about the operating system of our target machine:
Running: Apple Mac OS X 10.4.X
OS CPE: cpe:/o:apple:mac_os_x:10.4.10
OS details: Apple Mac OS X 10.4.10 - 10.4.11 (Tiger) (Darwin 8.10.0 - 8.11.1)
Network Distance: 1 hop
Service Info: OS: Mac OS X; CPE: cpe:/o:apple:mac_os_x
Wait, what? macOS X 10.4? Isn't that really, really ancient? Well, yeah, it is. The secret that I've been guarding for the past couple of chapters is that the target machine for my OpenVAS and Nmap scan demos has been my ancient, collectible Apple eMac from the year 2003. I figured that scanning it would give us some interesting results to look at, and it would appear that I was right. (And yes, that is eMac, not iMac.)
The final thing we can see is the TRACEROUTE information. It's not very interesting, though, because the target machine was sitting right next to me, with only one Cisco switch between us:
TRACEROUTE
HOP RTT ADDRESS
1 0.16 ms 192.168.0.37
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 213.92 seconds
donnie@linux-0ro8:~>
Okay; let's take a look at the lab.