Nmap Development mailing list archives
Re: Variety of bugs in nmap-4.20
From: Professor Messer <james () professormesser com>
Date: Tue, 19 Jun 2007 17:23:55 -0400
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
Current thread:
- Variety of bugs in nmap-4.20 Chris Drake (Jun 19)
- Re: Variety of bugs in nmap-4.20 DePriest, Jason R. (Jun 19)
- Re: Variety of bugs in nmap-4.20 Brandon Enright (Jun 19)
- Re[2]: Variety of bugs in nmap-4.20 Chris Drake (Jun 19)
- Re: Variety of bugs in nmap-4.20 Professor Messer (Jun 19)
- Re[2]: Variety of bugs in nmap-4.20 Chris Drake (Jun 19)
- Re: Variety of bugs in nmap-4.20 Professor Messer (Jun 19)
- Re: Variety of bugs in nmap-4.20 Fyodor (Jun 19)
- Re[2]: Variety of bugs in nmap-4.20 Chris Drake (Jun 19)
- Re: Variety of bugs in nmap-4.20 Fyodor (Jun 19)