For a plethora of reasons, auditing the security of our servers and networks is of paramount importance. Whether we are talking about a development server, a workstation, or a major enterprise application, security should be baked into every step of the deployment. While we can easily check our firewall settings from “the inside” of our systems. It is also a good idea to run a security audit from "the outside”. Using a network enumeration tool such as the famous and highly vetted Network Mapper (NMap).

Installing NMap

The software package is usually available in default repositories. Simply use your package manager to install the nmap package.

Install NMap on Debian derivatives:

sudo apt-get install nmap

Install NMap on RHEL derivatives:

sudo yum install nmap

Verify your installation and check the version with:

michael@cbook:~/Desktop$ nmap --version 
Nmap version 7.60 ( https://nmap.org )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.3.3 openssl-1.1.0g nmap-libssh2-1.8.0 libz-1.2.8 libpcre-8.39 libpcap-1.8.1 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

Users will need to check the version of the locally installed package to ensure it’s up-to-date. We may also face a scenario someday wherein we need to confirm our installed package isn’t vulnerable to a security flaw itself.

Basic NMap Usage: Our First Scan

One of the benefits of NMap is that it is approachable to beginners as well as useful to seasoned professionals. It can be as simple as typing “nmap” and then choosing a target.

NMap command syntax, from the manual:

[sudo] nmap [Scan Type...] [Options] {target specification}

Note: NMap should only be used on your own network/servers or with permission from the owner. Many packets will be generated and sent across the wire so we need to make sure we're responsible and respectful with our scanning. 

Luckily for us, the generous people at Nmap.org provide us with a safe sandbox in which to sharpen our skills. We will be using the URL scanme.nmap.org:

michael@cbook:~/Desktop$ sudo nmap scanme.nmap.org
[sudo] password for michael: 
Starting Nmap 7.60 ( https://nmap.org ) at 2020-02-22 14:25 CST
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.058s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Not shown: 992 closed ports
PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    open     http
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
445/tcp   filtered microsoft-ds
593/tcp   filtered http-rpc-epmap
9929/tcp  open     nping-echo
31337/tcp open     Elite
Nmap done: 1 IP address (1 host up) scanned in 274.24 seconds

Above you’ll see that we ran NMap with no options or arguments. A pure NMap invocation like this will run a SYN (or “half-open”) scan.

TCP Connections: The Handshake

During a complete TCP/IP connection, a “handshake” is carried out wherein the two systems negotiate the terms of their communication. This type of scan we are using only initiates the TCP connection but won’t complete the full handshake, thus the name half-open.

The authoritative TCP/IP Guide reminds us of the major goals accomplished by this technical handshake:

  • Contact and Communication: The client and server make contact with each other and establish communication by sending each other messages. The server usually doesn’t even know what client it will be talking to before this point, so it discovers this during connection establishment.
  • Sequence Number Synchronization: Each device lets the other know what initial sequence number it wants to use for its first transmission.
  • Parameter Exchange: Certain parameters that control the operation of the TCP connection are exchanged by the two devices.

Note: This list comes directly from The TCP/IP Guide: http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh.htm

Port Status

Our results for the public NMap test URL are quite informative. Notice the common ports of 22 and 80. These ports and services are so common that one would expect to encounter them in almost any scan. The SSH service is the de facto standard for remote access via Linux and the humble web port 80 serves the NMap test website’s content. Theese ports are publicly exposed on the internet as we can tell by the “open” state.

The other ports are largely protected by a firewall, with the exceptions of port 9929 and 31337. NMap makes it’s best effort to guess the services on these ports:

PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    open     http
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
445/tcp   filtered microsoft-ds
593/tcp   filtered http-rpc-epmap
9929/tcp  open     nping-echo
31337/tcp open     Elite

The “open” states are self-explanatory, pointing out that these ports are fully open and listening for connections via their services. The “filtered” state tells us that the ports are being controlled and/or monitored. Typically this implies the use of a firewall.

Using NMap Command Options

Why Use ‘Half-Open’ Scanning: nmap -sS

We just discovered that the default NMap scan technique is SYN scanning. One might wonder why that decision was made. It's actually largely due to the relatively “quiet” and quickly efficient nature of the scan. NMap has the potential to send a very large amount of traffic across the network and onto your target. Intrusion Detection Systems (IDSs) may interpret your security audit as malfeasance and assume ill intent. On smaller and/or weaker networks, a powerful scan could disable the router, thereby inadvertently becoming a Denial-of-Service (DoS) attack. Different options have very different packet loads.

In the below example, we are scanning (with admin rights) the same public server maintained by the NMap Project. We could also use the IP address (45.33.32.156) instead of the domain name.

sudo nmap -sS -O scanme.nmap.org

We use the -sS and -O arguments to specify the particular type of scan we want. The -sS options signifies that we want the default SYN “half-open” scan. The -O flag makes sure NMap also takes an educated guess of the OS on the server of interest. If NMap gets a response then we know that server exists.

Let’s now look at the output of our example:

michael@cbook:~/Desktop$ sudo nmap -sS -O scanme.nmap.org
[sudo] password for michael: 
Starting Nmap 7.60 ( https://nmap.org ) at 2020-02-22 14:59 CST
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.058s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Not shown: 992 closed ports
PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    open     http
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
445/tcp   filtered microsoft-ds
593/tcp   filtered http-rpc-epmap
9929/tcp  open     nping-echo
31337/tcp open     Elite
Aggressive OS guesses: Linux 2.6.32 - 3.13 (96%), Linux 2.6.22 - 2.6.36 (94%), Linux 3.10 - 4.8 (94%), Linux 3.10 (94%), Linux 2.6.32 (94%), Linux 3.2 - 4.8 (94%), Linux 2.6.32 - 3.10 (93%), HP P2000 G3 NAS device (93%), Linux 2.6.18 (93%), Linux 3.16 - 4.6 (93%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 13 hops
OS detection performed. Please report any incorrect results at https://nmap.org/submit/
Nmap done: 1 IP address (1 host up) scanned in 310.01 seconds

In our results we can see the information gathered about the targeted host. We can see the ports and their states (which can also allow us to infer the running services), IPv4 and IPv6 addresses, guessed or presumed OS, number of router “hops”, etc. 

Getting More Service Information: nmap -A / nmap -sV

As you’ve probably already guessed, your firewall settings should directly match what we find in the NMap output. Since NMap runs independently of your firewall service, it's a useful tool to run a security audit of your firewall's configuration. If we ever come across some surprising output from NMap, it’s a good idea to take a deeper look at that machine’s firewall setup.

Let’s get additional information on our services and their software versions. We use the -A argument to retrieve the service details. We use the -Pn option to treat the target as alive. We’ve already done some scanning so we know it’s up and responsive.

michael@cbook:~/Desktop$ sudo nmap -A -Pn --script vuln scanme.nmap.org
[sudo] password for michael: 
Starting Nmap 7.60 ( https://nmap.org ) at 2020-02-22 15:39 CST
Pre-scan script results:
|_broadcast-avahi-dos: ERROR: Script execution failed (use -d to debug)
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.062s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Not shown: 992 closed ports
PORT      STATE    SERVICE        VERSION
22/tcp    open     ssh            OpenSSH 6.6.1p1 Ubuntu 2ubuntu2.13 (Ubuntu Linux; protocol 2.0)
80/tcp    open     http           Apache httpd 2.4.7 ((Ubuntu))
| http-csrf: 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=scanme.nmap.org
|   Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://scanme.nmap.org:80/
|     Form id: cse-search-box-sidebar
|     Form action: https://nmap.org/search.html
|     
|     Path: http://scanme.nmap.org/
|     Form id: cse-search-box-sidebar
|_    Form action: https://nmap.org/search.html
|_http-dombased-xss: Couldn't find any DOM based XSS.
| http-enum: 
|   /images/: Potentially interesting directory w/ listing on 'apache/2.4.7 (ubuntu)'
|_  /shared/: Potentially interesting directory w/ listing on 'apache/2.4.7 (ubuntu)'
|_http-server-header: Apache/2.4.7 (Ubuntu)
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
445/tcp   filtered microsoft-ds
593/tcp   filtered http-rpc-epmap
9929/tcp  open     nping-echo     Nping echo
31337/tcp open     tcpwrapped
Aggressive OS guesses: Linux 2.6.32 - 3.13 (95%), Linux 2.6.22 - 2.6.36 (94%), Linux 3.10 - 4.8 (94%), Linux 2.6.32 (94%), Linux 3.2 - 4.8 (94%), Linux 2.6.32 - 3.10 (93%), HP P2000 G3 NAS device (93%), Linux 3.10 (93%), Linux 2.6.26 - 2.6.35 (93%), Linux 2.6.18 (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 13 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
TRACEROUTE (using port 587/tcp)
HOP RTT       ADDRESS
1   10.48 ms  router.charter.net (192.168.1.1)
2   ... 3
4   28.82 ms  agg50.ausutxla01r.texas.rr.com (24.175.43.181)
5   45.54 ms  agg22.dllatxl301r.texas.rr.com (24.175.41.46)
6   138.25 ms bu-ether24.dllstx976iw-bcr00.tbone.rr.com (66.109.6.52)
7   130.20 ms 66.109.5.121
8   38.27 ms  dls-b21-link.telia.net (62.115.156.208)
9   66.54 ms  las-b21-link.telia.net (62.115.123.137)
10  62.64 ms  sjo-b21-link.telia.net (62.115.116.40)
11  68.12 ms  linode-ic-342731-sjo-b21.c.telia.net (62.115.172.133)
12  158.79 ms 173.230.159.71
13  68.43 ms  scanme.nmap.org (45.33.32.156)
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 651.24 seconds

There is a lot of results here, so carefully read the full output. You will notice that some of the information is the same as our earlier example, only more verbose and more detailed. Where we initially saw the ports and their service, our most recent output includes the software and the version currently running. Where we initially only saw a number of hops, we now see which specific 13 routers make up our packets path of travel.

Basic Security Audit with Vulscan Plugin

The --script vuln option adds the Vulscan module. This security audit describes our possible software risks. Let’s walk through how this analysis is possible. Through normal NMap usage, we can quickly determine the services (and their software versions) that we have running on our systems. When this data is correlated with the publicly available flaw databases, we can see how our systems might be maliciously attacked. These flaws and exploits are cataloged and organized by CVE identifiers. In the case of our helpful Vulscan module, we are comparing against several of the biggest vulnerability databases available.

This kind of insight into your systems security is very important. Of all the running services on the scanme.nmap.org server, only the Apache web service appears to be vulnerable. From the terminal output we see a couple possible security holes.

Found the following possible CSRF vulnerabilities: 
|     
|     Path: http://scanme.nmap.org:80/
|     Form id: cse-search-box-sidebar
|     Form action: https://nmap.org/search.html
|     
|     Path: http://scanme.nmap.org/
|     Form id: cse-search-box-sidebar
|_    Form action: https://nmap.org/search.html

Cross Site Request Forgeries (CSRF) are malicious attempts by attackers to craft falsified requests. Here we see a couple locations and details that I’m sure their public web teams are examining for future hardening.

|_http-server-header: Apache/2.4.7 (Ubuntu)
| http-slowloris-check: 
|   VULNERABLE:
|   Slowloris DOS attack
|     State: LIKELY VULNERABLE
|     IDs:  CVE:CVE-2007-6750
|       Slowloris tries to keep many connections to the target web server open and hold
|       them open as long as possible.  It accomplishes this by opening connections to
|       the target web server and sending a partial request. By doing so, it starves
|       the http server's resources causing Denial Of Service.
|       
|     Disclosure date: 2009-09-17
|     References:
|       http://ha.ckers.org/slowloris/
|_      https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750

This implementation of Apache also appears to be susceptible to an older Denial of Service (DoS) attack. Slowloris was first identified and recorded in 2009. Here in the output we can see the unique CVE identifier CVE-2007-6750 as well as some other URLs for further reading.

Interesting Use-Cases

Automating Your Security Audits

By coupling a given NMap scan with a cronjob, a shell script, or even a list of hosts, we can automate the process of scanning in a routine manner. This is ideal for monthly/weekly security audits or simply just checking inventory in your enterprise environment.

Leveraging Vulscan

Using an NSE vulnerability plugin such as Vulscan extends Nmaps functionality to include identifying security risks in flawed software services. Combining the vulscan task with a weekend cronjob (as an example) yields a free weekly vulnerability report for your chosen target(s).

Standing on the Shoulders of Giants: Community Modules

In NMap’s 23 years of live development, a vast and varied user community has grown and refined itself. Thanks to collaborative efforts among this user base, a wealth of tools, modules, and plugins have been freely distributed for a wide variety of use-cases:

“The Nmap Scripting Engine (NSE) is one of Nmap's most powerful and flexible features. It allows users to write (and share) simple scripts to automate a wide variety of networking tasks. Those scripts are then executed in parallel with the speed and efficiency you expect from Nmap. Users can rely on the growing and diverse set of scripts distributed with Nmap, or write their own to meet custom needs.”

NMap Scripting Engine (NSE) Documentation

Conclusion

Thanks for joining us. In this article we learned how to install NMap. We also explored a very basic, but important way to use it. The complete usage of NMap is a huge subject area and outside the scope of this article. Hopefully this tutorial shed some light on getting started with this powerful and versatile suite of tools and plugins. Comparing our output to the desired configuration of our firewall allows us to be certain that our implementation is solid and secure. Happy scanning!

Resources