Nmap Development mailing list archives

Re: [Exp PATCH] Call port closed in any protocol with ICMP Port Unreach


From: Kris Katterjohn <katterjohn () gmail com>
Date: Sun, 04 Feb 2007 21:20:44 -0600

Fyodor wrote:
On Sun, Feb 04, 2007 at 07:53:13PM -0600, Kris Katterjohn wrote:
Does this not test to see if this packet is coming from the host and not
a separate device?

Well, the problem is that the firewalls often forge the source address
so it looks like the packets are coming from the machine you are
targetting.  Or the firewalls can be systems such as iptables which
actually are running on the target host itself, so they don't have to
forge packets at all.  So determining what is really going on requires
TTL checking and similar advanced investigations.

Of course these firewalls sometimes forge RST packets, which gives
Nmap the opposite problem.

But like I said, I'm open to the change if you find that a significant
number of hosts (not firewall software) send icmp-port-unreach
responses to TCP probes.

Cheers,
-F


Good points. In my initial set of scans which ran for a little while
(with -iR like I usually do), I only got one ICMP Port Unreachable for
TCP.  I did some googling, and it seems that only firewalls do tend to
do this.  I wasn't able to determine whether or not this one was a
firewall or not.

I didn't really expect to find many sending these since they could just
use RST.  I just thought that it might be better than saying "filtered",
since the Host Requirements said things could respond like this.  What
we could do is set the state to "closed|filtered" as with the Idle Scan,
but that'd probably be too confusing since in this case it's "possibly
closed, but most likely filtered".  Although, since it doesn't happen
very often, it could be a good state to put it in.  If there are any
other weird, rare (but valid) responses that we could get like this, we
could just call them "closed|filtered".


Thanks,
Kris Katterjohn

Attachment: signature.asc
Description: OpenPGP digital signature


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

Current thread: