Extraports Bug?

[Rob Nicholls <robert () robnicholls co uk>]

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?

Rob

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/