New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

High latency localhost scanning (Nmap 6.49BETA1) #153

Closed
attackdebris opened this Issue Jun 4, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@attackdebris

attackdebris commented Jun 4, 2015

I've noticed some very high latency differences between version 6.47 and version 6.49BETA1 for atleast one specific scan type. The affected scan in question was:
nmap -A -p- 127.0.0.1

The scans completes in approx 8 secs in version 6.47 but in excess of 15-minutes in the new Beta.

@maveas

This comment has been minimized.

maveas commented Jun 11, 2015

I am not able to reproduce this on Kali 1.1.0.

NMAP 6.47

root@demeter:~/tools/nmap# nmap -V
Nmap version 6.47 ( http://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.2.3 openssl-1.0.1e libpcre-8.30 libpcap-1.3.0 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

root@demeter:~/tools/nmap# nmap -A -p- 127.0.0.1
Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-11 10:02 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000048s latency).
All 65535 scanned ports on localhost (127.0.0.1) are closed
Too many fingerprints match this host to give specific OS details
Network Distance: 0 hops
OS and Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 5.32 seconds

NMAP 6.49BETA1

root@demeter:~/tools/nmap# 2015-06-11/nmap-6.49BETA1/nmap -V
Nmap version 6.49BETA1 ( http://nmap.org )
Platform: x86_64-unknown-linux-gnu
Compiled with: nmap-liblua-5.2.3 openssl-1.0.2a libpcre-8.30 nmap-libpcap-1.7.3 nmap-libdnet-1.12 ipv6
Compiled without:
Available nsock engines: epoll poll select

root@demeter:~/tools/nmap/2015-06-11/nmap-6.49BETA1# ./nmap -A -p- 127.0.0.1
Starting Nmap 6.49BETA1 ( http://nmap.org ) at 2015-06-11 11:11 CEST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000023s latency).
All 65535 scanned ports on localhost (127.0.0.1) are closed
Too many fingerprints match this host to give specific OS details
Network Distance: 0 hops
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 75.24 seconds

@attackdebris

This comment has been minimized.

attackdebris commented Jun 11, 2015

Hi maveas,
Whilst you queried the version for the nmap beta, it looks like you ran the scan using version 6.47. I just replicated the same issue (using latest github clone), on the same version of Kali.

@maveas

This comment has been minimized.

maveas commented Jun 11, 2015

Whoops.. Indeed, scanning (with the latest version ;) does produce a high latency.

(My previous comment is corrected.)

@dmiller-nmap

This comment has been minimized.

dmiller-nmap commented Jun 13, 2015

When you run these commands in order, which is the first one that produces the delay?

  1. nmap -sn -Pn -d 127.0.0.1
  2. nmap -sS -Pn -n -d 127.0.0.1
  3. nmap -sS -Pn -n -p- -d 127.0.0.1
  4. nmap -sS -Pn -n -O -d 127.0.0.1
  5. nmap -sS -Pn -n -sC -d 127.0.0.1

Also, please include your Linux kernel version (output of uname -r), because this may be related to #34

@attackdebris

This comment has been minimized.

attackdebris commented Jun 15, 2015

It looks as though number 2 is the first one to produce the delay:

Running number 2 with Nmap 6.47 = 0.10 sec scan time
Running number 2 with Nmap 6.49SVN = 90.47 secs scan time
Kernel version = 3.14-kali1-486

I can also replicate on another build (to a lesser extent):
Running number 2 with Nmap 6.47 = 0.21 sec scan time
Running number 2 with Nmap 6.49SVN = 82.23 secs scan time
Kernel version = 3.14-kali1-686-pae

@dmiller-nmap

This comment has been minimized.

dmiller-nmap commented Oct 5, 2017

Given the kernel version and that this showed up after updating libpcap to 1.5 just after 6.47, this is certainly a duplicate of #34, which has been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment