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
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on Feb 04 2007
Intro
