Re[2]: Variety of bugs in nmap-4.20

[Chris Drake <christopher () pobox com>]

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! 

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?
- in 2b - it's reporting that it parsed 0ms when I gave it 5000ms.
Ignore my comment about differences on different machines - I
accidentally run v3.7 instead of v4.2 (sorry!)

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.

Kind Regards,
Chris Drake


Wednesday, June 20, 2007, 4:39:19 AM, you wrote:

PM> Chris Drake wrote:
> > Hi,
> >
> > I'm Running the latest nmap-4.20 built from source
> > on RedHas AS4 update 4
> >
> > Linux 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 GNU/Linux
> >
> >
> > 1. I specifically ask it to send one ICMP echo request, however, it
> >    sends none, instead sending only an ARP:
> >
> >
> > # /usr/bin/nmap -n --packet_trace -sP -PE  123.123.252.164
> >
> > Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-19 14:56 UTC
> > SENT (0.0370s) ARP who-has 123.123.252.164 tell 123.123.252.162
> > RCVD (0.0390s) ARP reply 123.123.252.164 is-at 00:0C:29:DA:5E:9F
> > Host 123.123.252.164 appears to be up.
> > MAC Address: 00:0C:29:DA:5E:9F (VMware)
> > Nmap finished: 1 IP address (1 host up) scanned in 0.150 seconds
> >
> > # ping 123.123.252.164
> > PING 123.123.252.164 (123.123.252.164) 56(84) bytes of data.
> > 64 bytes from 123.123.252.164: icmp_seq=0 ttl=64 time=5.16 ms
> > 64 bytes from 123.123.252.164: icmp_seq=1 ttl=64 time=0.717 ms

PM> This is normal for the Nmap ping process. If an IP address is recognized
PM> to be on the same IP subnet, Nmap's ping process defaults to an ARP,
PM> regardless of the ping type specified. Your ICMP echo request ping (-PE)
PM> was automatically changed to an ARP ping (-PR).

PM> Nmap also recognized that you just found the device up and running with
PM> the default ARP ping, so it ignored the seemingly redundant ping scan (-sP).

PM> It might still be useful to send an ICMP echo request (-sP), even if a
PM> local-subnet ARP ping (-PR) finds the station to be available. This
PM> might help determine if a personal firewall could be running on the
PM> remote device.

> > 2. I attempt to send a single UDP packet, but
> >    2a - it sends 2 packets
> >    2b - it parses the --host_timeout switch wrongly (curious: works OK
> >         on a "RedHat AS4u4 "full" non-SELinux install, but fails on a
> >         vmware RedHat AS4u4 "minimal" SELinux install.)
> >
> > # /usr/bin/nmap -n --packet_trace -P0 -sU -p 53  --host_timeout
> > 5000 --data_length 1 203.123.123.131
> > host-timeout is given in milliseconds, so you specified less
> > than 15 seconds (0ms). This is allowed but not recommended.
> >
> > Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-19 14:59 UTC
> > SENT (0.0380s) UDP 123.123.252.162:48152 > 203.123.123.131:53 ttl=48 id=52931 iplen=29
> > SENT (1.0470s) UDP 123.123.252.162:48153 > 203.123.123.131:53 ttl=42 id=51814 iplen=29
> > Interesting ports on 203.123.123.131:
> > Unable to find nmap-services!  Resorting to /etc/services
> > PORT   STATE         SERVICE
> > 53/udp open|filtered domain
> >
> > Nmap finished: 1 IP address (1 host up) scanned in 2.130 seconds
> > [root@vm4-DidTheyReadIt bin]# 

PM> This looks to be working properly. Nmap sent a UDP frame, didn't get a
PM> response (which is pretty normal for UDP scans), and Nmap tried again
PM> just to make sure it didn't miss anything.

PM> The --host-timeout refers to the amount of time that Nmap will wait
PM> before "giving up" on a host scan. If you were scanning a lot of hosts,
PM> you might want to hurry things along by limiting every host to scan for
PM> 30 seconds and then stop regardless of your process. Five seconds 
PM> (5000ms) is pretty small, and Nmap told you so. The default is 0, which
PM> means that Nmap won't ever stop a scan based on time.

PM> If you use --max_retries and limit the retry count to 0, it'll send a
PM> single UDP frame and then finish.

> > 3. (Cosmetic) It tells me to use -P0 when I'm already using -P0
> >
> > # /usr/bin/nmap -P0 -n --packet_trace -sP -PE  123.123.252.163
> >
> > Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-19 14:57 UTC
> > SENT (0.0610s) ARP who-has 123.123.252.163 tell 123.123.252.162
> > SENT (0.1700s) ARP who-has 123.123.252.163 tell 123.123.252.162
> > Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
> > Nmap finished: 1 IP address (0 hosts up) scanned in 0.320 seconds

PM> Your command line is a bit contradictory, since you've asked not to send
PM> an Nmap ping (-P0) but also requested an ICMP echo request ping (-PE).
PM> Nmap accepts your second option, overriding the the first -P0 request.

PM> So, as it turns out, you didn't _really_ specify -P0. If you remove the
PM> -PE option, you'll find that Nmap maintains its link between the Nmap
PM> ping and the ping scan with this error message:

PM> "-P0 (skip ping) is incompatable(sic) with -sP (ping scan).  If you only
PM> want to enumerate hosts, try list scan (-sL)"


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




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