Re: ICMP Port Unreachable in Host Discovery

[Will Cladek <william.cladek () nrl navy mil>]

Kris,

The host can be pinged as well, but you're right, there's no way of knowing for sure if it's the host or an external 
firewall on its behalf.  It does seem odd not to just be using a RST or simply ignoring it completely.

The thing that drew my attention to this is that normally I throw in a -PE flag to do a ping as well, and even though 
the host is pingable, occasionally the scan will just end and say the host is down.  I haven't been able to recreate 
this is a controlled fashion, or else *that* would be what I'd post about.  Maybe the host is just being inconsistent 
in replying to echo requests.  I was just kind of hoping changing this ICMP port unreachable behavior would be a 
simpler solution.  I guess I'll just wait and try to recreate the original situation and try to post about that.

-Will

Kris Katterjohn wrote:
> Will Cladek wrote:
> > Hi,
> >
> > I've encountered an issue with nmap not identifying a host on my 
> > network as being up when I attempt to scan it.  This particular host 
> > is apparently configured to have its firewall send ICMP port 
> > unreachable messages for its filtered tcp ports.  However, when the 
> > nmap host discovery receives this it will still say the host is down.  
> > An example scan and tcpdump:
> >
> > > sudo nmap -sP -PA21,22,25,80,443,445,1723 -PS21,22,25,80,443,445,1723 
> > > 192.168.2.3
> >
> > Starting Nmap 4.20 ( http://insecure.org ) at 2007-06-14 12:55 EDT
> > 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.113 seconds
> >
> >
> > 12:55:14.530550 IP 192.168.2.2.46215 > 192.168.2.3.21: . ack 
> > 1876403038 win 3072
> > 12:55:14.530583 IP 192.168.2.2.46215 > 192.168.2.3.22: . ack 
> > 1876403038 win 3072
> > 12:55:14.530595 IP 192.168.2.2.46215 > 192.168.2.3.25: . ack 542614366 
> > win 4096
> > 12:55:14.530607 IP 192.168.2.2.46215 > 192.168.2.3.80: . ack 
> > 3742868318 win 4096
> > 12:55:14.530618 IP 192.168.2.2.46215 > 192.168.2.3.443: . ack 
> > 3889668958 win 4096
> > 12:55:14.530631 IP 192.168.2.2.46215 > 192.168.2.3.445: . ack 
> > 1473749854 win 3072
> > 12:55:14.530641 IP 192.168.2.2.46215 > 192.168.2.3.1723: . ack 
> > 3025642334 win 3072
> > 12:55:14.530651 IP 192.168.2.2.46215 > 192.168.2.3.21: S 
> > 4095189854:4095189854(0) win 4096 <mss 1460>
> > 12:55:14.530661 IP 192.168.2.2.46215 > 192.168.2.3.22: S 
> > 1540858718:1540858718(0) win 4096 <mss 1460>
> > 12:55:14.530670 IP 192.168.2.2.46215 > 192.168.2.3.25: S 
> > 2568463198:2568463198(0) win 4096 <mss 1460>
> > 12:55:14.530680 IP 192.168.2.2.46215 > 192.168.2.3.80: S 
> > 1222091614:1222091614(0) win 3072 <mss 1460>
> > 12:55:14.530689 IP 192.168.2.2.46215 > 192.168.2.3.443: S 
> > 4288127838:4288127838(0) win 3072 <mss 1460>
> > 12:55:14.530699 IP 192.168.2.2.46215 > 192.168.2.3.445: S 
> > 2182587230:2182587230(0) win 1024 <mss 1460>
> > 12:55:14.530709 IP 192.168.2.2.46215 > 192.168.2.3.1723: S 
> > 2425856862:2425856862(0) win 4096 <mss 1460>
> > 12:55:14.530980 IP 192.168.2.3 > 192.168.2.2: icmp 48: 192.168.2.3 tcp 
> > port 21 unreachable
> > 12:55:14.531014 IP 192.168.2.3 > 192.168.2.2: icmp 48: 192.168.2.3 tcp 
> > port 22 unreachable
> > 12:55:14.531024 IP 192.168.2.3 > 192.168.2.2: icmp 48: 192.168.2.3 tcp 
> > port 25 unreachable
> > 12:55:14.531033 IP 192.168.2.3 > 192.168.2.2: icmp 48: 192.168.2.3 tcp 
> > port 80 unreachable
> > 12:55:14.531041 IP 192.168.2.3 > 192.168.2.2: icmp 48: 192.168.2.3 tcp 
> > port 443 unreachable
> > 12:55:14.531050 IP 192.168.2.3 > 192.168.2.2: icmp 48: 192.168.2.3 tcp 
> > port 445 unreachable
> >
> > Maybe this is by design, but I'm of the opinion that if the target 
> > host itself is sending an ICMP port unreachable message, nmap should 
> > consider the host as "up".
> >
> > Thanks,
> >
> > Will
>
> Hey Will,
>
> I wrote a patch before to label TCP ports as 'closed' when it receives 
> an ICMP Port Unreachable, as this is what the Host Requirements RFC 
> (1122 I believe) says it should do, even though TCP has a mechanism for 
> this (RST).  But Fyodor suggested that most of the time these are 
> received, it is actually a separate firewall sending them, possibly 
> spoofing it's source address to look like the other host's.
>
> Are you sure it's the actual host sending these?
>
> I never received any responses like this that I was sure was coming from 
> the target host rather than a separate firewall.
>
> Of course, even if you are sure it's the target host, Fyodor (to me) is 
> right in general because why would a host use this when it can use a TCP 
> RST? It sure sounds like a firewall-esque thing to do there :)
>
>
> Thanks,
> Kris Katterjohn

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