Technical notes › Use custom nmap port sets
If you have a server in the cloud, it’s important to set up a firewall to make sure you don’t inadvertently let services listen on the public internet.
Maybe you use
iptables, or maybe you have a cloud firewall in front of your machine entirely.
No matter what you do, it’s also important to check that the firewall you’ve configured actually works.
nmap can be used for this, as well as any task involving sending packets to servers, waiting for responses, and displaying the results in a nice little table. I recommend that you save a script of your own, so you can easily re-scan when you change something.
Here’s my version of such a script:
#!/bin/sh exec sudo nmap "$@" \ -PE \ -v --reason \ -p 22,80,443,1234,4646,4647,4648,5353,8300,8301,8302,8500,8600,8080 \ --datadir=$HOME/path/to/my/custom/nmap/datadir
We use the following arguments:
-PEargument checks the host is up with an ICMP Echo Request packet. (See the “Why the sudo?” section for more.)
-vargument enables verbose output, which is useful if, for you, it takes a while to print any output. If it’s fast, you can remove it.
--reasonargument tells nmap to print the reason why each port is in its state.
-pargument specifies the list of TCP ports to scan, as comma-separated numbers. Our port numbers here include SSH, HTTP, HTTPS, the ports used by the Hashicorp suite of services, and one (1234) that I know should never be listening, as a sort of meta-test.
--datadirargument allows us to specify custom service names. (See the “Custom service names” section for more.)
Here’s an (abridged) version of what it outputs:
$ nmap-box.sh some-host Nmap scan report for some-host Host is up, received echo-reply ttl 47 (0.025s latency). PORT STATE SERVICE REASON 22/tcp open ssh syn-ack ttl 47 80/tcp open http syn-ack ttl 47 443/tcp open https syn-ack ttl 47 1234/tcp filtered never-open no-response 4646/tcp filtered nomad no-response 5353/tcp filtered madns no-response 8080/tcp filtered http-misc no-response 8300/tcp filtered consul no-response 8500/tcp filtered consul no-response 8600/tcp filtered consul no-response Nmap done: 1 IP address (1 host up) scanned in 1.30 seconds
From this, I can see that the rules present in my cloud firewall and the firewall on the machine itself, when put together, allow inbound SSH, HTTP, and HTTPS traffic: each port responds with a
syn-ack TCP packet when probed.
I can also see that the internal services are unreachable, as they should be, as nmap reports
no-response: they appear identical to port 1234, the port with nothing listening on it.
Why the sudo?
Before the status of each port is fetched, it’s important to first check that the machine is up and online.
Otherwise, every port will come back as
filtered with the reason
no-response, and you’ll think everything’s OK when it’s not.
nmap will automatically perform this check before scanning a server.
This is known as host discovery.
Our script above passes the
-PE argument to nmap, meaning it should first ping the server with an Echo request, and only continue scanning once it’s received a ping response.
However, in order for nmap to do this, it needs to send and receive raw network traffic, rather than relying on the simplified interfaces that the OS provides.
On Unix and Unix-like systems, this usually requires you to be the root user.
If you’re not root, nmap will ignore the
-PE option, and perform host discovery by checking if TCP ports 80 or 443 are open instead:
Warning: You are not root -- using TCP pingscan rather than ICMP
This means that if your server isn’t serving anything on those ports, nmap will assume it’s down and scan no further. Hence,
A nice side-effect of this is that nmap can use quicker TCP SYN scan as its port scanning technique, rather than the slower TCP connect scan, meaning the script will run slightly faster.
Custom service names
In the SERVICE column of the output, nmap will list the name of the service associated with that port number.
This confused me for a long time: I assumed that nmap was somehow parsing the bytes it receives in the response and using that to determine which service was running.
Instead, all it’s doing is looking up the number in
/etc/services and printing what’s in there.
This means that if you stray from common port numbers, nmap has very strange ideas of what services are running. By default, it calls Nomad “dots-signal” and Consul “fmtp”, despite me never having heard of either of those before, just because they happen to share the same port.
To get around this, we can create our own nmap “datadir” that contains the data nmap uses to look things like this up.
Create a directory, and place inside it a file named
nmap-services with contents such as the following:
ssh 22/tcp http 80/tcp https 443/tcp never-open 1234/tcp nomad 4646/tcp nomad 4647/tcp nomad 4648/tcp nomad 4648/udp
Then, if you pass the parent directory to nmap with the
--datadir parameter as in the script above, nmap will use your custom name–service mappings.