I am using Nmap every time I installed a new server/appliance/whatever in order to check some unknown open ports from the outside. In most situations I am only doing a very basic run of Nmap without additional options or NSE scripts.

Likewise I am interested in how the Nmap connections appear on the wire. Hence I captured a complete Nmap run (TCP and UDP) and had a look at it with Wireshark. If you’re interested too, feel free to download the following pcap and have a look at it by yourself. At least I took some Wireshark screenshots to give a first glance about the scan.

Laboratory

Not much to say about the “lab” this time. A fresh Ubuntu 16.04.3 LTS server with Nmap 7.60. I scanned the well-known scanme.nmap.org domain with TCP and UDP via IPv6: sudo nmap -6 -sS -sU -A scanme.nmap.org . In order to have a complete transparent capture I used a Profitap ProfiShark 1G network TAP rather than tcpdump on the scanning host itself:

From a 100 Mbps Hub to a #ProfiShark Gigabit TAP. I just dramatically increased my network troubleshooting hardware! #tschakka @Profitap pic.twitter.com/67dO5JH0sV

— Johannes Weber 🎸 (@webernetz) October 24, 2017

These are the mere Nmap results. Only four open ports were found while 1996 ports are closed. The host seems to be a Ubuntu Linux machine:

pcap Download

If you want to play around with Wireshark download the following pcap and go:

Basic Analysis

Preface: It was not my intention to do a complete reverse engineering of Nmap. I just wanted to get a basic feeling about its connections. Hence here are just some quick notes.

Beside the mere scan you can see some more packets, namely the initial DNS request to my local router (packets 1-4) and the traceroute at the end (beginning with packet 4610, Layer Four Traceroute with TCP Port 80) plus its reverse DNS lookups (packets 4645 to 4674, udp.stream eq 338 ):

Since almost all ports are closed (rather than filtered in which no answers are received) there are many many many TCP RST respectively ICMPv6 destination unreachable (port unreachable for UDP connections) packets. The TCP scan started with packet no. 13, UDP with packet no. 2385:

Filter for the TCP flags SYN & ACK to see the TCP connections that did succeed with its 3-way handshake  (tcp.flags.ack == 1) && (tcp.flags.syn == 1) . You’ll find only the three open TCP ports 22, 80, 31337.

Note that the first run of the TCP scan did RST it immediately (e.g.,  tcp.stream eq 7 for TCP port 22) while Nmap later on uses more protocol aware scan techniques to discover the services behind the ports, such as SSH scan on port 22 which reveals the different public keys etc. Same is true for HTTP port 80.

For UDP it (sometimes) uses the application directly such as 53 DNS or 123 NTP while not for 514 Syslog:

Finally you can use the basic Wireshark statistic options to get details about the TCP/UDP conversations, IO graphs and packet lengths. In my trace there are 1442 TCP and 1137 UDP conversations. The IO graphs shows a peak at the frist 5 seconds while it decreases to a lower level for the rest of the scan.

Have a N.I.C.E. day! ;)

Featured image “In der Ferne … 196/366” by Dennis Skley is licensed under CC BY-ND 2.0.