Home page logo
/

nmap-dev logo Nmap Development mailing list archives

RE: Nmap says Host down when actually host is up.
From: "Dario Ciccarone (dciccaro)" <dciccaro () cisco com>
Date: Fri, 26 Oct 2007 11:05:31 -0400

Doing some trimming - hate to have to scroll down 20 lines to get to the
new content ;) 

Not as clear as is what is going on below, and as Kris stated, it
shouldn't happen with ICMP, but just throwing it out for
consideration.

Cheers,
  kx


+1 on strange things with ICMP.  The UDP socket code I've been writing
lately has seen some of strangest ICMP messages back.  Between all the
different OS, firewalls, NATs, and other strange network 
devices out there,
you're going to see some crazy ICMP packets.

Load balancers. You missed that one. And that *could* be the case here -
some misbehaving device doing load balancing in the path. And then the
answer could either be from the same host, but different interface - or
from a totally different host, which shares the original IP our friend
here was scanning with other hosts - and the load balancer algorithm
didn't work right. 


I haven't given it more than 2 seconds of thought, but we could try
something TCP SYNCOOKIE inspired for our ICMP ECHO requests.

Say we stuffed some useful data in the payload like:

<64 bit timestamp><32 bit salt><32 bit target IP XOR 32 bit 
salt><32 bit
checksum (CRC?)>

Then when we receive an ICMP ECHO REPLY from a host we don't 
know about, we
check the payload. If:

* The time is within some reasonable range
* The salt matches the salt being used by the nmap process
* The XOR of the salt and jumbled IP field match an IP we're probing
* The checksum computes

Then we accept the echo reply as valid even though something 
is slightly
broken.

Or maybe I'm missing something this is a terrible idea?

You're suggesting something very similar in concept to
http://www.ietf.org/rfc/rfc3947.txt - "Negotiation of NAT-Traversal in
the IKE". Too bad for it to really work you need for the other end, the
receiving one, to also understand what you're trying to do and report
back to you "yeah, here's how I should look - check if that is how you
see me" and then detect NAT/PAT/other in the path from source to
destination.

Otherwise, it's all guesswork - and not only that, but adding
complex[itude]? complex[iness]? - heck, adding more code to nmap to
handle a corner case, which means more chance of errors in the normal
case, more time spent debugging the new (and the old) code . . . not
worth it, unless it becomes a widespread issue :)

A puzzle - will remain like that for the time being :)

Dario

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


  By Date           By Thread  

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