Nmap says Host down when actually host is up.

[Swapnali]

Hi,

I am using nmap 4.20 for windows. I am working on a windows xp with sp2. I
have tried to find the solution for my problem on the nmap lists but it
didn't help. Hence this mail.

I have tried many host discovery options to figure out why nmap says a
particular host is down when actually the host is up. Enclosed is also the
screenshot of the nmap response as opposed to the icmp ping response to a
particular IP along with the ethereal snapshot. When I do icmp ping, I do
receive the reply. But when I use "nmap -sP <ip>" the response I receive is;

Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-22
14:49 Central Daylight
Time
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
4.188 seconds

I used ethereal to check whats going on. I saw a ping request going to a
destination IP and a reply from another interface of the same machine with a
different IP in the source with icmp seq. number being the same. Is nmap
matching both destination IP in request and src ip in reply packet? If this
is the case, it might be a bug. Because, as in this case a machine might
have multiple IP's. Infact I am facing this problem with many hosts. Am I
missing something here?
I will appreciate any help/ info on this. Awaiting a positive response.

-Swapnali

[DePriest, Jason R.]

Post by Swapnali
Hi,
I am using nmap 4.20 for windows. I am working on a windows xp with sp2. I
have tried to find the solution for my problem on the nmap lists but it
didn't help. Hence this mail.
I have tried many host discovery options to figure out why nmap says a
particular host is down when actually the host is up. Enclosed is also the
screenshot of the nmap response as opposed to the icmp ping response to a
particular IP along with the ethereal snapshot. When I do icmp ping, I do
receive the reply. But when I use "nmap -sP <ip>" the response I receive is;
Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-22
14:49 Central Daylight
Time
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
4.188 seconds
I used ethereal to check whats going on. I saw a ping request going to a
destination IP and a reply from another interface of the same machine with a
different IP in the source with icmp seq. number being the same. Is nmap
matching both destination IP in request and src ip in reply packet? If this
is the case, it might be a bug. Because, as in this case a machine might
have multiple IP's. Infact I am facing this problem with many hosts. Am I
missing something here?
I will appreciate any help/ info on this. Awaiting a positive response.
-Swapnali

Greetings, Swapnali,

Try running nmap against a single trouble system
nmap -sP <host>
but include -vv (that is two v's and not one w) and --packet-trace as well
so
nmap -sP -vv --packet-trace <host>
That should provide helpful information for you and for the list.

-Jason

[Swapnali]

Following is verbose output.

Nmap says Host 10.10.209.108 seems to be a subnet broadcast address
(returned 1 extra pings)

D:\>nmap -sP -vv --packet-trace 10.10.209.108

Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-23 08:40 Central
Daylight
Time
SENT ( 0.2340s) ICMP 10.205.42.40 > 10.10.209.108 Echo request
(type=8/code=0) tt
l=56 id=10663 iplen=28
SENT (0.2500s) TCP 10.205.42.40:33574 > 10.10.209.108:80 A ttl=54 id=16833
iplen
=40 seq=655835166 win=3072 ack=4099358750
RCVD (0.2660s) ICMP 10.204.100.2 > 10.205.42.40 Echo reply (type=0/code=0)
ttl=2
49 id=10663 iplen=28
Host 10.10.209.108 seems to be a subnet broadcast address (returned 1 extra
ping
s).
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 2.313 seconds
Raw packets sent: 2 (68B) | Rcvd: 1 (46B)

[Fyodor]

Post by Swapnali
Following is verbose output.
Nmap says Host 10.10.209.108 seems to be a subnet broadcast address
(returned 1 extra pings)
D:\>nmap -sP -vv --packet-trace 10.10.209.108
Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-23 08:40 Central
Daylight
Time
SENT ( 0.2340s) ICMP 10.205.42.40 > 10.10.209.108 Echo request
(type=8/code=0) ttl=56 id=10663 iplen=28
RCVD (0.2660s) ICMP 10.204.100.2 > 10.205.42.40 Echo reply (type=0/code=0)
ttl=249 id=10663 iplen=28

Are you sure this host is really up? If so, it is strange that it is
replying to the ping packet from a different IP than the one the ping
was sent to. I normally only see that with subnet-directed broadcast
addresses, so Nmap does not treat the machine as being up unless it
receives the response from the same address it sent to. It is also
interesting that this target host apparently didn't reply to the port
80 request. Again, are you sure it is actually up? What OS is it
running?

Does anyone know if the RFC even allows a machine receiving an ICMP
echo request to respond from a different IP address? I doubt that is
allowed, but I'm not certain.

Cheers,
-F

[Kris Katterjohn]

Post by Fyodor
Does anyone know if the RFC even allows a machine receiving an ICMP
echo request to respond from a different IP address? I doubt that is
allowed, but I'm not certain.
Cheers,
-F

RFC 1122 Section 3.2.2.6:

The IP source address in an ICMP Echo Reply MUST be the same
as the specific-destination address (defined in Section
3.2.1.3) of the corresponding ICMP Echo Request message.

So, no, it isn't allowed technically.

Thanks,
Kris Katterjohn

[Dario Ciccarone (dciccaro)]

Hm. 10.10.209.18 *could be* the network address for subnet
10.10.10.209.108/30 - hosts being .109 and .110, broadcast .111 - still
wouldn't explain why .2 is replying. Funny.

Got the whole packet capture for this? The ICMP echo request should
include the whole content of the payload section of the ICMP echo
request. Can you add some payload and see what you get back ? see if it
also changes the data ?

I would theorized .2 has the wrong network mask for the subnet, the
router for .108/30 is translating the ping to a subnet-level broadcast
and .2 is replying - but using .30 implies a P2P link, not a broadcast
medium w/ multiple hosts on it . . .


Dario

-----Original Message-----
Sent: Thursday, October 25, 2007 5:23 PM
To: Swapnali
Subject: Re: Nmap says Host down when actually host is up.

Post by Swapnali
Following is verbose output.
Nmap says Host 10.10.209.108 seems to be a subnet broadcast address
(returned 1 extra pings)
D:\>nmap -sP -vv --packet-trace 10.10.209.108
Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-23

08:40 Central

Post by Swapnali
Daylight
Time
SENT ( 0.2340s) ICMP 10.205.42.40 > 10.10.209.108 Echo request
(type=8/code=0) ttl=56 id=10663 iplen=28
RCVD (0.2660s) ICMP 10.204.100.2 > 10.205.42.40 Echo reply

(type=0/code=0)

Post by Swapnali
ttl=249 id=10663 iplen=28

Are you sure this host is really up? If so, it is strange that it is
replying to the ping packet from a different IP than the one the ping
was sent to. I normally only see that with subnet-directed broadcast
addresses, so Nmap does not treat the machine as being up unless it
receives the response from the same address it sent to. It is also
interesting that this target host apparently didn't reply to the port
80 request. Again, are you sure it is actually up? What OS is it
running?
Does anyone know if the RFC even allows a machine receiving an ICMP
echo request to respond from a different IP address? I doubt that is
allowed, but I'm not certain.
Cheers,
-F
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

[kx]

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

Post by Dario Ciccarone (dciccaro)
Hm. 10.10.209.18 *could be* the network address for subnet
10.10.10.209.108/30 - hosts being .109 and .110, broadcast .111 - still
wouldn't explain why .2 is replying. Funny.
Got the whole packet capture for this? The ICMP echo request should
include the whole content of the payload section of the ICMP echo
request. Can you add some payload and see what you get back ? see if it
also changes the data ?
I would theorized .2 has the wrong network mask for the subnet, the
router for .108/30 is translating the ping to a subnet-level broadcast
and .2 is replying - but using .30 implies a P2P link, not a broadcast
medium w/ multiple hosts on it . . .
Dario

-----Original Message-----
Sent: Thursday, October 25, 2007 5:23 PM
To: Swapnali
Subject: Re: Nmap says Host down when actually host is up.

Post by Swapnali
Following is verbose output.
Nmap says Host 10.10.209.108 seems to be a subnet broadcast address
(returned 1 extra pings)
D:\>nmap -sP -vv --packet-trace 10.10.209.108
Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-23

08:40 Central

Post by Swapnali
Daylight
Time
SENT ( 0.2340s) ICMP 10.205.42.40 > 10.10.209.108 Echo request
(type=8/code=0) ttl=56 id=10663 iplen=28
RCVD (0.2660s) ICMP 10.204.100.2 > 10.205.42.40 Echo reply

(type=0/code=0)

Post by Swapnali
ttl=249 id=10663 iplen=28

Are you sure this host is really up? If so, it is strange that it is
replying to the ping packet from a different IP than the one the ping
was sent to. I normally only see that with subnet-directed broadcast
addresses, so Nmap does not treat the machine as being up unless it
receives the response from the same address it sent to. It is also
interesting that this target host apparently didn't reply to the port
80 request. Again, are you sure it is actually up? What OS is it
running?
Does anyone know if the RFC even allows a machine receiving an ICMP
echo request to respond from a different IP address? I doubt that is
allowed, but I'm not certain.
Cheers,
-F
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org

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

[Brandon Enright]

On Fri, 26 Oct 2007 08:46:55 +0200 plus or minus some time kx

Post by kx
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

+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.

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?

Brandon

[Fyodor]

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

Hi Brandon. The response already has enough information (e.g. ICMP
sequence and ID numbers) for us to recognize it. But I think in most
cases where we get a response from a different IP than the target we
sent to, it is because the target host forwarded the request
(e.g. subnet-directed broadcast) to other machines, and one or more of
them answered. In that case, for us to mark the target as up would be
a false postive. For us to change that behavior and mark the host as
up, I would want some evidence that actual online hosts responding
with the wrong IP is a normal occurence.

Cheers,
-F

[Swapnali]

Thanks for all your response. Unfortunately, I am unable to completely solve
this mystery. When I did a traceroute to 10.10.209.108, it infact ended at
10.204.100.2. But because I do not have access on 10.204.100.2, I am unable
to see the configuration on it. 10.10.209.108 might be configured as
anything on that. Will have to wait till I see the config.

Thanks again.
Swapnali

Post by Fyodor

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

Hi Brandon. The response already has enough information (e.g. ICMP
sequence and ID numbers) for us to recognize it. But I think in most
cases where we get a response from a different IP than the target we
sent to, it is because the target host forwarded the request
(e.g. subnet-directed broadcast) to other machines, and one or more of
them answered. In that case, for us to mark the target as up would be
a false postive. For us to change that behavior and mark the host as
up, I would want some evidence that actual online hosts responding
with the wrong IP is a normal occurence.
Cheers,
-F

[Dario Ciccarone (dciccaro)]

Yeah, for what is worth, I kind of agree with this approach.

And even if someone came up with the full details (topology, packet
captures, device versions, etc) - would it make at all sense to add a
bunch of code to detect a corner case? Yes - if Fyodor is shooting for
perfection this week. Not, if it is some weird combination of OS/load
balancer/firewall/NAT/router/etc it is probably going to be seen in the
wilde once in a blue moon :)

Dario

-----Original Message-----
Sent: Friday, October 26, 2007 3:50 AM
To: Brandon Enright
Subject: Re: Nmap says Host down when actually host is up.

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

Hi Brandon. The response already has enough information (e.g. ICMP
sequence and ID numbers) for us to recognize it. But I think in most
cases where we get a response from a different IP than the target we
sent to, it is because the target host forwarded the request
(e.g. subnet-directed broadcast) to other machines, and one or more of
them answered. In that case, for us to mark the target as up would be
a false postive. For us to change that behavior and mark the host as
up, I would want some evidence that actual online hosts responding
with the wrong IP is a normal occurence.
Cheers,
-F

[Dario Ciccarone (dciccaro)]

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

Post by Brandon Enright

Post by kx
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.

Post by Brandon Enright
I haven't given it more than 2 seconds of thought, but we could try
something TCP SYNCOOKIE inspired for our ICMP ECHO requests.
<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
* 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

[Kris Katterjohn]

Post by kx
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