4

Nmap is so slow as to be almost unusable on my Windows 8.1 laptop.

I'm using Nmap 6.40 and it's taking more than a minute to run a simple check that runs in a fraction of a second on other computers on the same network. I've tried several other computers with different versions of Nmap, but they all get the same result in a fraction of a second. Trying different scans and different targets on my laptop has the same results. It's not a slow laptop in general, core i7/16GB/SSD, other applications run fast enough

This is what Nmap says on my laptop (hostnames etc changed):

C:\Users\colinp>nmap -p4730 target 

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-20 14:28 GMT Standard Time
Nmap scan report for target (192.168.1.1)
Host is up (0.0013s latency).
rDNS record for 192.168.1.1: target
PORT     STATE SERVICE
4730/tcp open  unknown
MAC Address: 2C:76:8A:00:00:00 (Hewlett-Packard Company)

Nmap done: 1 IP address (1 host up) scanned in 79.92 seconds

C:\Users\colinp>

vs an example Ubuntu computer on the same network:

colin@ubuntu:~$ nmap -p 4730 target 

Starting Nmap 5.21 ( http://nmap.org ) at 2014-03-20 14:29 GMT
Nmap scan report for target (192.168.1.1)
Host is up (0.00044s latency).
rDNS record for 192.168.1.1: target 
PORT     STATE SERVICE
4730/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds
colin@ubuntu:~$

EDIT: I just noticed the amount of time taken is suspiciously similar for another host, not sure if that means anything:

C:\Users\colinp>nmap -p4730 target2

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-20 14:47 GMT Standard Time
Nmap scan report for target2 (192.168.1.2)
Host is up (0.00013s latency).
rDNS record for 192.168.1.2: target2
PORT     STATE  SERVICE
4730/tcp closed unknown
MAC Address: 00:25:90:00:00:00 (Super Micro Computer)

Nmap done: 1 IP address (1 host up) scanned in 79.71 seconds

C:\Users\colinp>

Trying to scan a non-existant host is faster, but varies a lot, between 3 and 16 seconds. Again, that takes 0.03 seconds on the ubuntu server.

Name resolution does not seem to be a problem on my laptop, nslookup returns almost instantly.


EDIT: output of diagnostic suggested by @bonsaiviking:

C:\Users\colinp>nmap -d -sL target

Starting Nmap 6.40 ( http://nmap.org ) at 2014-03-20 16:40 GMT Standard Time
Winpcap present, dynamic linked to: WinPcap version 4.1.2 (packet.dll version 4.
1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b (20091008)
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
mass_rdns: Using DNS server 192.168.x.12
mass_rdns: Using DNS server 192.168.x.11
mass_rdns: Using DNS server 192.168.1.254
mass_rdns: Using DNS server 192.168.2.1
mass_rdns: Using DNS server 192.168.x.12
mass_rdns: Using DNS server 192.168.x.11
mass_rdns: Using DNS server 192.168.x.12
mass_rdns: Using DNS server 192.168.x.11
Initiating Parallel DNS resolution of 1 host. at 16:41
mass_rdns: 52.89s 0/1 [#: 8, OK: 0, NX: 0, DR: 0, SF: 0, TR: 1]
Completed Parallel DNS resolution of 1 host. at 16:41, 0.00s elapsed
DNS resolution of 1 IPs took 52.90s. Mode: Async [#: 8, OK: 1, NX: 0, DR: 0, SF:
 0, TR: 1, CN: 0]
Nmap scan report for target (192.168.1.1)
rDNS record for 192.168.1.1: target
No data files read.
Nmap done: 1 IP address (0 hosts up) scanned in 53.36 seconds

IP addresses changed again. Of the DNS servers listed, 192.168.x.11 and 192.168.x.12 are my real DNS servers. No idea where the others come into this. They are not listed when I do ipconfig /all although the following odd entry was under my connection to my internal Hyper-V switch:

   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1

Don't know whether the problem is related to my running Hyper-V? Also I have no actively disabled IPv6, don't know whether that could be causing it?


more diagnostics, IP addresses still obscured, hopefully consistently...

C:\Users\colinp>nslookup -type=PTR 1.1.168.192.in-addr.arpa
Server:  dns-at-my-company.example.com
Address:  192.168.x.12

1.1.168.192.in-addr.arpa.co.uk
        primary name server = ns1.sedoparking.com
        responsible mail addr = hostmaster.sedo.de
        serial  = 2007021501
        refresh = 86400 (1 day)
        retry   = 10800 (3 hours)
        expire  = 604800 (7 days)
        default TTL = 86400 (1 day)

Previous command was missing a .. This looks better:

C:\Users\colinp>nslookup -type=PTR 1.1.168.192.in-addr.arpa.
Server:  dns-at-my-company.example.com
Address:  192.168.x.12

1.1.168.192.in-addr.arpa     name = target
7
  • Diagnostics time: run as administrator, any change? Run nmap -d -n -Pn -p 4730 target, then nmap -d -n -sn target, then nmap -d -sL target. Which ones were slow, which were fast? This is running each phase of the scan separately to isolate the slow part. – bonsaiviking Mar 20 '14 at 16:36
  • administrator, no change (I forgot to mention I tried that). Timings of those commands in order: 5.52, 4.65, 53.36. The output of the last one seems to suggest I have a DNS problem, though nslookup works fast enough. I'll post the output into a question edit – Colin Pickard Mar 20 '14 at 16:43
  • It sounds like the problem is in reverse name resolution, then. Is this command also slow? nslookup -type=PTR 1.1.168.192.in-addr.arpa (obviously substitute your target's IP address in byte-reversed order) – bonsaiviking Mar 20 '14 at 16:48
  • @bonsaiviking, thank you for your help. I think you might be onto something. If I understand what should be happening, I got a very odd result to that nslookup, which I've edited into the end of the question. – Colin Pickard Mar 20 '14 at 16:59
  • @bonsaiviking scratch that. I needed an extra . at the end of that command – Colin Pickard Mar 20 '14 at 17:05
3

Solved in the comments: A problem with how Nmap is detecting DNS servers to use for its parallel reverse DNS resolution. Here is the diagnostics process and the final workaround:

First, you need to determine which phase of the Nmap scan is slowing you down. nmap -p4730 target will do a single-port TCP scan, but it will also do name resolution (if necessary), host discovery ("ping"), and reverse DNS name lookup. It's important to know whether you are running as administrator, too, since Nmap uses different approaches to all of these steps if it doesn't have sufficient privileges to use the best and fastest ones. Run these single-phase scans to determine which phase is the slow one:

  1. nmap -d -n -Pn -p 4730 target - Port scan phase only.
  2. nmap -d -n -sn target - Host discovery phase only.
  3. nmap -d -sL target - Reverse DNS resolution phase only.

From your comments, we determined that the slowpoke was reverse DNS resolution. Adding the -d flag showed that Nmap was choosing 4 different DNS servers, but only 2 of them were valid. Nmap's documentation suggests using the --dns-servers option to specify the correct ones in a comma-separated list. You can also use --system-dns to use your operating system's own DNS resolver instead of Nmap's parallel one. For scans of many hosts, this can be slower, but it's pretty much always guaranteed to work. These options are documented in more detail in the official Nmap Network Scanning book by Gordon "Fyodor" Lyon.

Our final workaround, then, is to determine the IP addresses of your DNS servers, then run Nmap with --dns-servers 192.168.X.X,192.168.X.Y with those servers' IP addresses.

0

Nmap on Windows is not as efficient as on Linux.

You can improve connect scan performance by double clicking the nmap_performance.reg file located in the Nmap directory, which will make three registry changes in order to increase the number of ephemeral ports reserved for applications such as Nmap, and decrease the amount of time before a closed connection can be reused.

To make the changes by hand, add these three Registry DWORD values to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters:

  1. MaxUserPort: Set a large value such as 65534 (0x0000fffe).
  2. TCPTimedWaitDelay: Set the minimum value (0x0000001e).
  3. StrictTimeWaitSeqCheck: Set to 1 so TCPTimedWaitDelay is checked.

Information derived from the nmap site.

2
  • That made a slight difference, but not enough to be usable really. I tried the same scan again twice after merging the .reg and it took 69.16 and 67.87 seconds, whereas before it was consistently taking 79 seconds. – Colin Pickard Mar 20 '14 at 15:21
  • I tried the same version of Nmap, 6.40, on a Windows 7 desktop here. Without the registry change it took average 2.0 seconds per scan; with the change it dropped to average 1.9 seconds. So I'm concluding 1. the .reg change is slightly useful and 2. my laptop has something else wrong with it :( – Colin Pickard Mar 20 '14 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.