Nmap Security Scanner
*Intro
*Ref Guide
*Install Guide
*Download
*Changelog
*Book
*Docs
Security Lists
*Nmap Hackers
*Nmap Dev
*Bugtraq
*Full Disclosure
*Pen Test
*Basics
*More
Security Tools
*Pass crackers
*Sniffers
*Vuln Scanners
*Web scanners
*Wireless
*Exploitation
*Packet crafters
*More
Site News
Site Search:
Exploit World
Advertising
About/Contact
Credits
Sponsors:
edgeos



Nmap Development: Re: Nmap says Host down when actually host is up.

Re: Nmap says Host down when actually host is up.

From: Kris Katterjohn <katterjohn_at_gmail.com>
Date: Fri, 26 Oct 2007 18:20:25 -0500

On 10/26/07, kx <kxmail_at_gmail.com> wrote:
> I can't say for ICMP, but I have definitely written a generic UDP
> server on a Solaris box before that had multiple IP addresses, that
> was listening on all IPs, and when the server would reply to a UDP
> packet, the kernel behavior would be to reply from the IP addresses on
> the Solaris box that was closest to the source, not necessarily from
> the IP address it received the packet on.
>
> Now, in this case it made sense, I would send a packet from a subnet
> connected to the Solaris box, but I would send it to the IP address
> not on the subnet. The response would come back from the IP address on
> my subnet.
>
> Example
>
> Solaris has IP 10.10.1.5 and 10.10.100.5
> I am IP 10.10.1.6
>
> 10.10.1.6 -- UDP --> 10.10.100.5
> 10.10.1.6 <-- UDP -- 10.10.1.5
>
> 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
>

Maybe the host sending the ICMP echo reply from the wrong address
misinterpreted the RFC. RFC 1122 says it's OK for the transport
layers to support this behavior (ICMP is on the same layer as IP, thus
this isn't applicable for it):

3.3.4.3 Choosing a Source Address

            DISCUSSION:
                 When it sends an initial connection request (e.g., a
                 TCP "SYN" segment) or a datagram service request (e.g.,
                 a UDP-based query), the transport layer on a multihomed
                 host needs to know which source address to use. If the
                 application does not specify it, the transport layer
                 must ask the IP layer to perform the conceptual
                 mapping:

                     GET_SRCADDR(remote IP addr, TOS)
                                               -> local IP address

                 Here TOS is the Type-of-Service value (see Section
                 3.2.1.6), and the result is the desired source address.
                 The following rules are suggested for implementing this
                 mapping:

                 (a) If the remote Internet address lies on one of the
                      (sub-) nets to which the host is directly
                      connected, a corresponding source address may be
                      chosen, unless the corresponding interface is
                      known to be down.

                 (b) The route cache may be consulted, to see if there
                      is an active route to the specified destination
                      network through any network interface; if so, a
                      local IP address corresponding to that interface
                      may be chosen.

                 (c) The table of static routes, if any (see Section
                      3.3.1.2) may be similarly consulted.

                 (d) The default gateways may be consulted. If these
                      gateways are assigned to different interfaces, the
                      interface corresponding to the gateway with the
                      highest preference may be chosen.

Thanks,
Kris Katterjohn

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

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
edgeos