One of the most well-known network scanners is Nmap. With a name derived from network mapper, Nmap has been around since 1997 and continues to be actively developed. As of March 2016, the latest stable version is 7. Nmap’s speed, reliability, and customization options have made it the preferred go-to tool for many network and security professionals.
Nmap can be executed with a plethora of options, but when executed without any switches against a server named system1 with the IP address of 10.211.55.9, it generates the following output:
Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-09 19:41 CET
Nmap scan report for system1 (10.211.55.9)
Host is up (0.00033s latency).
rDNS record for 10.211.55.9: system1.shared
Not shown: 993 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
79/tcp open finger
80/tcp open http
513/tcp open login
3306/tcp open mysql
MAC Address: E8:2A:EA:41:F3:0D (Intel Corporate)
The scan against system1 acknowledged the existence of seven services that are listening for incoming network traffic. The service that is running on each port number is matched by Nmap against IANA’s list of assigned services and port numbers to give the user an idea of the type of service provided.
Additionally, Nmap can make use of its internal database of system response fingerprints to better determine what type of service it is up against.
Nmap’s default configuration is to scan hosts for services running on ports that are so-called well-known ports. The number of ports that Nmap considers to be well-known is exactly 1,000. Nmap must be specifically configured to scan the remaining 120,000 available TCP and UDP ports.
After the scan is complete, Nmap will report the port’s state. Nmap recognizes six port states:
Open - A service running on the targeted host is configured to accept connections in the form of TCP or UDP packets depending on which type was scanned.
Closed - A port is reported as closed when there is no service running on the targeted host on the probed port. Worth noting is that Nmap will only report a port as closed if the targeted host responds back to Nmap in some way, other than “port open,” during the network scan. So even if Nmap lists all ports of a host as closed, you can still make the conclusion that the host is currently up and running.
Filtered - This is where it can start to get tricky for the security tester. In its most basic form, the filtered state means that Nmap was unable to determine whether a port was open or closed since no response was returned from the target. There are a good number of reasons as to why a port provides no response. Such reasons include host-based firewalls, router packet filtering rules, and network intrusion prevention systems. Of course, it could simply be the case that there are no servers at the other end. Worth noting is that running Nmap against filtered ports is significantly slower than working with ports that are either open or closed. This is due to Nmap having to wait for a complete timeout to make sure there are no slow responses.
Unfiltered - Nmap considers the port to be accessible but can’t determine if its open, closed, or filtered.
Open|Filtered - This category is used when Nmap is unable to determine whether a port is open or filtered.
Closed|Filtered - This category is used when Nmap is unable to determine whether a port is closed or filtered.
A more detailed description of Nmap’s different port states can be found at https://nmap.org/book/man-port-scanning-basics.html.
Security testers will for the most part encounter ports that are reported as either open, closed, or filtered.
If the scope of the security test contains a lot of servers, it might be a good idea to initiate the network scanning part of the test with a ping sweep. Such a sweep is carried out by telling Nmap to send messages to all targets in order to find out if they are alive or not. A ping sweep is executed like so:
nmap -sn 192.168.178.0/24
Judging by Nmap’s output, the ping sweep took only seconds to complete and it revealed that ten hosts are up on the 192.168.178/24 network segment. The response also contains the MAC Address of each responding machine since that scan was initiated on the same local network as the hosts (a ping scan over the Internet would not have revealed the MAC addresses). This is also the reason behind the scan being so quick.
Starting Nmap 6.49BETA3 ( https://nmap.org ) at 2016-03-22 14:00 CET
Nmap scan report for 192.168.178.1
Host is up (0.0034s latency).
MAC Address: 9C:C7:A6:3D:8C:5D (AVM GmbH)
Nmap scan report for 192.168.178.30
Host is up (0.059s latency).
MAC Address: 70:56:81:9B:6F:39 (Apple)
Nmap scan report for 192.168.178.46
Host is up (0.021s latency).
MAC Address: 84:C9:B2:01:82:77 (D-Link International)
Nmap scan report for 192.168.178.74
Host is up (0.034s latency).
MAC Address: E8:DE:27:65:C8:63 (Tp-link Technologies Co.)
Nmap scan report for 192.168.178.77
Host is up (0.085s latency).
MAC Address: B8:8D:12:3F:90:84 (Apple)
Nmap scan report for 192.168.178.98
Host is up (0.10s latency).
MAC Address: 5C:96:9D:8A:56:FF (Apple)
Nmap scan report for 192.168.178.99
Host is up (0.0056s latency).
MAC Address: 64:EB:8C:2B:E7:0C (Seiko Epson)
Nmap scan report for 192.168.178.102
Host is up (0.054s latency).
MAC Address: 08:EE:8B:80:74:03 (Samsung Elec Co.)
Nmap scan report for 192.168.178.171
Host is up (0.077s latency).
MAC Address: C4:62:EA:A5:3B:73 (Samsung Electronics Co.)
Nmap scan report for 192.168.178.73
Host is up.
If the number of available hosts uncovered by the ping sweep differs greatly from the number of expected available hosts, it could indicate that firewalls or similar network filtering devices are blocking the traffic or that the hosts themselves simply aren’t answering. They might still be there and have ports open. You won’t know for sure before trying each and every port.
Knowing what ports are currently accepting TCP connections is good, but knowing what services hide behind those port numbers is even better. Nmap has a built-in service detection feature that can be used to identify the most common services. The switch used to enable Nmap’s service detection is -sV, and a complete example of how the feature can be used is as follows:
nmap -sV -p 1-65535 -Pn system1
The switches used in the example above enable the following functionality:
• sV | Enables Nmap’s service detection feature. • p 1-65535 | Instructs Nmap to scan all of the 65,535 possible TCP ports. • Pn | Instructs Nmap to skip trying to find out if the host is alive before the subsequent port scanning and service detection probes. The reason for using the -Pn switch is that some systems are configured to block ICMP traffic. With the -Pn switch enabled, Nmap will try to enumerate the targeted system’s services regardless of the how the system responds to incoming ICMP traffic.
Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-09 23:41 CET
Nmap scan report for system1 (10.211.55.9)
Host is up (0.00031s latency).
rDNS record for 10.211.55.9: system1.shared
Not shown: 65528 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.2
22/tcp open ssh OpenSSH 6.6.1 (protocol 2.0)
23/tcp open telnet Linux telnetd
79/tcp open finger BSD/Linux fingerd
80/tcp open http Apache httpd 2.4.6 ((CentOS))
513/tcp open login?
3306/tcp open mysql MariaDB (unauthorized)
MAC Address: E8:2A:EA:41:F3:0D (Intel Corporate)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/.
The scan uncovered the names, and in a few cases the version number, of six services on system1. The only service reluctant to give away additional information was the service running on port 513. The service on 513/tcp would in this case require a more in-depth, and manual, investigation of its inner secrets.
The scan also uncovered that the Linux distribution in question is CentOS, which was determined to be probing the http service running on port 80 for information.
As stated previously, while some service types have historically been bound to a certain TCP or UDP port number (like port 80/tcp for web servers and port 69/udp for TFTP), services of any kind can be bound to any port number. This can make services running on nonstandard port numbers harder to find and identify.
UDP-based services are, when compared with TCP-based services, far more complicated to deal with when it comes to network scanning. The reason for this complication lies within UDP itself and its connection-less nature. The protocol is designed to be fast and does not provide the same services like retransmission of lost packets, as TCP. Also, the endpoints of a UDP-based conversation can receive the network datagrams in any order; UDP does not put them in the correct order, like TCP does. In other words, UDP is a communication protocol that hopes for the best, but makes no promises.
All this means that even though Nmap is among the best UDP scanners out there, it can’t always produce a reliable result due to the very design of the UDP protocol.
For example, the example below is an attempt at scanning UDP-based services on the host system1: nmap -sU -sV -p 60-69 system1 Even though Nmap was configured to only probe ten UDP ports using the -sU and -sV switches, the scan took more than a minute and a half to complete. Scanning a large network using this method could prove to be too slow to be worth the effort. Only scan ports that are likely to be active.
Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-10 01:57 CET
Nmap scan report for system1 (10.211.55.9)
Host is up (0.00038s latency).
rDNS record for 10.211.55.9: system1.shared
PORT STATE
60/udp closed
61/udp closed
62/udp closed
63/udp closed
SERVICE VERSION
unknown
ni-mail
acas
via-ftp
64/udp closed
65/udp closed
66/udp closed
67/udp closed
68/udp open|filtered dhcpc
69/udp open|filtered tftp
MAC Address: E8:2A:EA:41:F3:0D (Intel Corporate)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/.
The scan indicates that two UDP-based services are running on ports 68 and 69. Note that Nmap was unable to completely verify the availability of the two presumably open ports and has therefore categorized their respective states as open|filtered. The open|filtered state calls for further manual inspection.
For example, manually verifying the existence of a TFTP service on system1 can be done using the tftp command-line tool and its status feature:
tftp system1
tftp> status
Connected to system1.localdomain.
Mode: netascii Verbose: off Tracing: off
In some cases, determining what operating system (OS) Nmap is working against is easy. Below is an example of how Nmap was able to identify that the targeted web server (claimed it) was running on a CentOS Linux distribution: ... 80/tcp open http Apache httpd 2.4.6 ((CentOS))
There are, however, cases when establishing the OS of a target is more difficult. That’s when Nmap’s OS detection feature can come in handy.
nmap -sV -O 192.168.178.1
The -O switch will activate Nmap’s OS detection feature. The OS detection feature works by fingerprinting the TCP/IP stack of the targeted machine. In other words, every network packet that gets returned to Nmap during a scan is examined in detail to determine the OS type. The fingerprinting is made possible because operating systems implement the TCP/IP stack with slight variations. Nmap can identify more than two thousand OS types and versions. Successfully being able to fingerprint a host depends on that system having both open and closed ports that the network scanner can connect to. If the host does not have both, or they appear to be filtered, the fingerprinting will fail or at least be quite unreliable.
Below is an example of how Nmap can be used to try to determine the actual identity of a network gateway device. In under just twenty seconds, Nmap made the assumption that the target is a “Fortinet FortiGate 200B firewall.”
Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-10 03:34 CET
Nmap scan report for 192.168.178.1
Host is up (0.010s latency).
Not shown: 993 closed ports
PORT STATE SERVICE VERSION
66
covia
tacacs-ds
sqlnet
dhcps
21/tcp open ftp FRITZ!Box Fon WLAN 7390 WAP ftpd
53/tcp open domain
80/tcp open http FRITZ!Box http config
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: MARAMBILI)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: MARAMBILI)
5060/tcp open sip AVM FRITZ!OS SIP
8181/tcp open http AVM FRITZ!Box 7300-series WAP http config
Device type: firewall
Running (JUST GUESSING): Fortinet embedded (94%)
OS CPE: cpe:/h:fortinet:fortigate_200b
Aggressive OS guesses: Fortinet FortiGate 200B firewall (94%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: -10 hops
Service Info: Devices: WAP, broadband router, VoIP adapter
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/.
However, the fingerprinting failed to report the target’s correct operating system identity. Having analyzed the response from the host, Nmap guessed that its operating system was Fortinet embedded. The real identity of the host is, however, a DSL router running custom software made by the ISP. This goes to show that while Nmap gets it right some of the time, it does not get it right all of the time.
One of the more useful features of Nmap is the nmap scripting engine, or NSE. The NSE can be used to do sophisticated version detection as well as detecting potential vulnerabilities in the targeted services. The NSE can also be used for backdoor detection and, in some cases, even as a vulnerability exploitation tool (even though there are far better exploitation tools out there).
The switch used to enable the NSE is -sC, and a basic example of using the -sC switch would be like so: nmap system1 -sC
In this case, an NSE script will be executed for each service found, in order to dig up more information. For example, after Nmap had found an FTP server on system1, it executed the ftp-anon NSE script against it. The result that came back indicates that an FTP service is configured to allow anonymous FTP access.
In a similar fashion, Nmap executed a NSE script after it had found the finger service on port 79/tcp. The NSE finger script revealed a number of active user sessions. Such information could be used for social engineering purposes.
Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-10 04:13 CET
Nmap scan report for system1 (10.211.55.9)
Host is up (0.00030s latency).
rDNS record for 10.211.55.9: system1.shared
Not shown: 993 closed ports
PORT STATE SERVICE
21/tcp open ftp
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxr-xr-x 2 0 0 4096 Nov 20 19:22 pub
22/tcp open ssh
| ssh-hostkey:
| 2048 9f:d1:be:3f:92:92:f3:f4:c3:d4:2f:30:c8:bb:a7:3b (RSA)
|_ 256 70:fc:bc:e9:c9:e2:39:8e:bf:45:78:14:05:e2:52:34 (ECDSA)
23/tcp open telnet
79/tcp open finger
| finger: Login Name Tty
| dave
| klara
| marie
| root
|_sarah
80/tcp open http
| http-methods:
|_ Potentially risky methods: TRACE
|_http-title: Apache HTTP Server Test Page powered by CentOS
513/tcp open login
3306/tcp open mysql
MAC Address: E8:2A:EA:41:F3:0D (Intel Corporate)
Another example of NSE usage would be to guess SNMP community names: nmap system2 -sU -p 161 --script snmp-brute.nse
68
root pts/1
pts/4
pts/0 3
pts/3 1
pts/2 2
Idle Login Time
Mar 23 09:15
Mar 23 09:17
Mar 23 09:16
Mar 23 09:13
Mar 23 09:18
Office Office Phone Host
(10.211.55.2)
(10.211.55.2)
(10.211.55.2)
(10.211.55.2)
(10.211.55.2)
Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-10 05:26 CET
Nmap scan report for system2 (10.211.55.10)
Host is up (0.00035s latency).
rDNS record for 10.211.55.10: system2.shared
PORT STATE SERVICE
161/udp open snmp
| snmp-brute:
|_ secret - Valid credentials
MAC Address: 10:C0:0C:F1:D9:2A (Unknown)
Note that the NSE might have more than one script for a certain type of service. Running an Nmap scan without pointing out a specific NSE script to be run for a certain type of service will cause Nmap to run the default NSE script for that service. For example, there are a number of NSE scripts for Microsoft's SQL Server that won't be run unless Nmap gets configured to explicitly do so:
ms-sql-brute.nse
ms-sql-config.nse
ms-sql-dac.nse
ms-sql-dump-hashes.nse
ms-sql-empty-password.nse
ms-sql-hasdbaccess.nse
ms-sql-info.nse
ms-sql-query.nse
ms-sql-tables.nse
The default location for NSE is /usr/share/nmap/scripts/
A complete list of Nmap’s current NSE scripts, and how they can be used, can be found at https:// nmap.org/nsedoc/.
Any security tester will sooner or later find themselves scanning ports and services that, despite being open, reveal little or no further information. An example would be the following scan against port 36785/tcp
nmap system2.shared -p 36785 -sV -sC -O
The service running on port 36785 only returned a string of text : System return: 84985 Checksum return: e9388fb525b3cd12972ff58997bad2c2 Trying to test the security of the service based solely on that string of text might prove impossible. The program running behind the port might demand some very specific input in order to open itself up fully. It’s up to the security tester to decide on how much effort she should put into trying to identify the service based on this small amount of information. If she’s lucky, she might be able to google the returned string and get some useful results. Another alternative is to investigate other open ports on the same system to see if any similarities can be found.
Starting Nmap 7.01 ( https://nmap.org ) at 2016-03-10 06:38 CET
Nmap scan report for system2.shared (10.211.55.10)
Host is up (0.00041s latency).
PORT STATE SERVICE VERSION
36785/tcp open unknown
1 service unrecognized despite returning data. If you know the service/version, please
submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port36785-TCP:V=7.01%I=7%D=3/10%Time=56E1086B%P=x86_64-pc-linux-gnu%r(N
SF:ULL,49,"System\x20return:\x2011885757\x20Checksum\x20return:\x200548070
SF:c99b0be1a9a86d24c9d17a4fe")%r(LANDesk-RC,48,"System\x20return:\x2084985
SF:99\x20Checksum\x20return:\x20e9388fb525b3cd12972ff58997bad2c2");
MAC Address: 10:C0:0C:F1:D9:2A (Unknown)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1
closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.2 - 4.0
Network Distance: 1 hop
OS and Service detection performed. Please report any incorrect results at https://nmap.org/
submit/.
If there are other services within the scope of the security test that reveal more information, it can be wise for the security tester to focus her efforts on those services instead. However, make sure that all available ports for each system are listed in the final report. It should also be clear if the security tester has thoroughly tested the port or not.
Robert Svensson
Tags: #nmap #scanning #fingerprinting #nmapscriptingengine #tcpscan #udpscan
2017-11-01 20:50:00
This is the personal website and article collection of me — Robert Svensson. I currently work for Contentful writing about APIs, coding and the future of content management
You can also find out what I'm up to by following me on GitHub, Twitter and LinkedIn. Feel free to send me an e-mail at [email protected]