Home page logo

nmap-dev logo Nmap Development mailing list archives

Extraports Bug?
From: Rob Nicholls <robert () robnicholls co uk>
Date: Thu, 12 May 2011 17:28:26 +0100

I was going through some port scan results from a recent penetration test to try and identify why Kris' Ruby Nmap Parser was taking longer than usual to process a file and spotted that the output was mostly closed ports (in one example there were 30 open ports and no filtered ports). I was expecting to see the 65505 closed ports, for example, show up as an extraports entry in the XML file, but instead I had a line per port (an extra 65k lines per host made the Nmap and XML output files considerably larger than expected!).

A similar scan a matter of hours later against hosts on another subnet using the same 5.51 SVN version of Nmap returned:
Not shown: 65502 closed ports
Reason: 65502 resets

The command I used was:

nmap -vv --script "* and not *brute* and not broadcast and not *flood* and not *fuzz* and not *snoop* and not *http-enum*" -n -Pn --reason -p- -A -oA xxx_xxx_tcp_full_exclude_xxx -iL xxx.txt --defeat-rst-ratelimit --min-hostgroup 64 --exclude xxx.xxx.xxx.xxx

Does anyone have any idea why one set of files is normal (and small) and the other is (huge and) full of individual closed ports? The only obvious difference I can see is that I used --exclude on this bad scan; but that doesn't seem to have made any difference when I ran a quick test in the test lab (although the SVN version on a host in the lab is probably slightly older). I'll try and do some more testing to try and replicate the issue, but I was hoping someone else might have seen this "lack of extraports" bug before?


Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]