Nmap Packet Capture

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:

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.

8 thoughts on “Nmap Packet Capture

  1. Why is it that the traceroute starting at 4610 starts with a TTL of 16 and decrements down to 1? Isn’t that the opposite of how traceroute works? I’ve been mulling this over all morning and I’m baffled.

    1. Wuh, that’s a very good question. And it’s decrementing from 16 to 1, while 17, 18, 19 are coming afterwards. Interesting.

      However, as long as the corresponding ICMP “time exceeded” errors messages from the routers are interpreted correctly, it doesn’t matter at all whether the traceroute trick starts by 1 or by 16 or even shuffles it completely. For whatever reason Nmap is doing it that way…

      1. Thank you so much for the quick reply! It’s a very unique pcap, I’ve never seen traceroute behave that way before.

Leave a Reply

Your email address will not be published. Required fields are marked *