Re: Variety of bugs in nmap-4.20

[Professor Messer <james () professormesser com>]

Chris Drake wrote:
> Hi James,
>
> Thanks for the detailed notes.  In my case, I want to test my remote
> iptables logging rules as well as automate a cron job with rrd to
> graph the relative speed differences (and packet losses) between ICMP,
> "TCP", and UDP packets between about 40 servers - having nmap
> second-guess me (wrongly) and block what I'm trying to do is somewhat
> irritating! 

I like the idea of using Nmap "outside of the box," especially for 
network response time measurements. As QoS is rolled out across networks 
in different ways, it's helpful to get additional feedback regarding 
response times, especially across different protocol types.

However, Nmap's job is to find systems that are live on the network and 
then scan them to determine how accessible they might be. The idea of 
using Nmap for more of a network-centric task is a bit outside its 
scope, but the idea isn't unique:

http://insecure.org/nmap/SoC/Ncat.html

On a more fundamental level, it's probably worth discussing the 
advantages and disadvantages of separating the ping process from the 
ping scan. I gave an example of what that would be useful, but that 
doesn't help your current task.

So it isn't that Nmap is second guessing you, it's that your 
requirements are just different than what Nmap actually does. That's not 
really a bug, although it could certainly be considered a feature 
request. :)

> You missed my points in #2 - in 2a, the bug is that it's sending
> something a second time - I don't want it to second-guess me again
> here, because that's going to stuff up my logging of dropped UDP
> packets and ruin my timing graph.  It doesn't send a "helpful" second
> ICMP or SYN or any other kind of packet that I know of - why's it
> deciding to send a second UDP one?

You didn't get a response to your first packet, so Nmap sent another 
packet to be sure it didn't miss anything. Nmap does a LOT of 
retransmitting of information, especially when ports are filtered or 
unresponsive (as you often see with UDP ports).

Again, this kind of activity isn't a bug. Nmap's job is to locate and 
identify, and it'll try many different ways until it finds what it's 
looking for. Sometimes you'll find that Nmap sends three or more 
retransmissions until it gives up. You can restrict the number of 
retransmissions with the --max-retries option.

> - in 2b - it's reporting that it parsed 0ms when I gave it 5000ms.

I agree, that's not quite right. Although it appears as 0ms in the 
output line, it appears to be parsed properly by Nmap. Run the same 
command with the --debug option, and you'll get some additional 
information. That one needs a quick fix.

> Point #3 - yes - I know P0 is silly, but the error message is still
> wrong.  nmap can't find anywhere to send packets - telling us to try
> -P0 isn't going to help anything, and telling us to try not sending a
> P{anything} when we've explicitly specified PE - an ICMP - is, well,
> "rude" :-)   Like I said though - this is cosmetic.

Your interpretation of the problem isn't quite on the mark. Nmap is 
attempting to perform an initial ping of the device, but it doesn't get 
a response. That doesn't mean that the device isn't on the network, it 
could just be hiding behind a personal firewall. To disable this initial 
ping, you can tell Nmap to disable that sanity check (-P0) and perform 
the scan anyway. It's a completely valid suggestion.

I think your larger concern is the redirection of your network packet 
types (from ICMP echo requests to ARPs) without your permission, and 
after you explicitly asked for something else! Although an ARP is 
oh-so-much better than an ICMP echo request when hunting for active 
devices on a local subnet, I can appreciate your point.

One of the advantages of Nmap is that it's open source. If you create a 
patch for this, I'll be glad to help test it!

I think your ideas are interesting, but perhaps Nmap isn't the best tool 
for your specific task (although I've used wrenches as hammers many 
times). You may be better off looking at some packet manipulation tools, 
such as Scapy or hping.


James "Professor" Messer
Author, "Secrets of Network Cartography: A Comprehensive Guide to Nmap"
http://www.ProfessorMesser.com

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