Re: firewalk meets nmap - TTL (advantages)

[Darren Reed <avalon () coombs anu edu au>]

In some mail from Lance Spitzner, sie said:
[...]
> Most firewalls only filter inbound traffic on the interfaces, not
> outbound.  For example, when a firewall initiates a connection by
> sending a packet, most firewall rulebases allow this connection because
> the firewall is trusted. 

mmm, most but not all :)
Depends on the competancy of the firewall builder, I'd say :)

> The same thing applies to the use of TTL settings during the scan.  You
> set the TTL to the same number of hops to the firewall.  You then scan
> the systems behind the firewall.  If the firewall does NOT filter the
> packet and allows it to go through, it will first decremet the TTL and
> then forward the packet.
> However, since the TTL will now be zero, the firewall initiates an ICMP
> Error message and sends it back to the source IP system (you).  This
> packet is most likely allowed outbound since the firewall itself is
> initiating the connection.

Or, because it is part of "error reporting", is recognised as being a part
of that connection.  I actually had this argument with someone recently -
are ICMP unreachables/time exceeds, etc, for a connection allowed through
just because they match ?  Yes, I'd argue, because they're part of the
"control channel" (for want of a better term).  So if you're letting in
SMTP connections to a mail relay and you do the stateful thing, the SYN
initiates the state and the retrun ICMP packet matches it (of course) so
is allowed.

If you're doing stateful filteirng, you can reduce this problem by just
letting the SYN packet in and triggering the state creation when it leaves
the box such that no time exceeds generated by the firewall are allowed
out "by default".  This doesn't negate the problem, however, as you can
(a) setup a "connection" to a known open service and then (b) use just ACK
packets with the right seq/ack #'s to do the right thing.

What you need to be able to do is (a) drop packets with a "too low" TTL
(1 or 2, basically) or (b) have a knob to disable allowing those packets
out or (c) be able to disable them matching state information.  All three
of these would be nice :)

> > But now if the firewall would accept icmp at least to outbound, this method 
> > should be reliable and should give us a good idea of what remote security 
> > rules look like but not in fact if really the target's port behind the 
> > firewall is open.
>
> Most firewalls deny ICMP coming in from the Internet or ICMP coming from 
> internal network.  Most firewalls do NOT block icmp initiated by the firewall 
> itself.

I wish I could work out how to generate packets in IP Filter, on Solaris,
that bypass filtering!

Cheers,
Darren

--------------------------------------------------
For help using this (nmap-hackers) mailing list, send a blank email to 
nmap-hackers-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).