Re: firewalk meets nmap - TTL (advantages)

[Lance Spitzner <lance () spitzner net>]

On Fri, 3 Nov 2000, gregory duchemin wrote:

> Firewall would have to be allowed to send icmp packet from itself, i don't 
> know what is the most common configuration actually used on the net, but 
> it's really much more secure to disable every icmp packet, ping and naturaly 
> icmp time exceeded in either bounds, and from firewall in particular.
> So in such a conf and even if the port is open, no icmp error response 
> should be sent back.

Gregory,

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

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

> Do u think of something special with this kind of scan ? ( something new 
> compared to nmap already does )

Definitely, two things come to mind.

1.  UDP scanning.  It can be difficult to determine what UDP packets a firewall
allows through.  A system has to be on the other side of the firewall to respond.
Also, if the port is open on the system on the other end, there is no response.
This process will make UDP port scanning much easier for firewall rulebases.

2.  TCP scanning.  It can be difficult to determine what TCP packets a firewall
allows through.  A system has to be on the other side of the firewall to respond
when nmap pushed the packet through.  With this new technique, no system needs
to be on the other side.

This option would greatly help me in the scanning/test of firewall rulebases.
Now, the option is not fool proof.  The firewall OS has to generate ICMP
error messages and the rulebase has to let them go outbound.  Based on my
experience with firewalls (such as CheckPoint FW-1), this is an extremely
large percentage of firewall.s

> > I'm not sure if anyone has thought of this, but this
> > would be a REALLY cool feature for auditing firewall
> > rulebases.  Say you want to determine what ports a
> > firewall allows through, what ports are NOT filtered.
> >
> > Have the option with nmap to set the TTL on the packets
> > it sends.  I set the TTL to be the same as the amount
> > of hops to the firewall I am scanning.  If the packet is
> > filtered by the firewall, then it is dropped and nothing
> > is sent back.
> >
> > However, if the packet is accepted by the firewall (and
> > the port is not filtered), the firewall will attempt to
> > forward it.  However, the TTL will now be zero and the
> > firewall will respond with ICMP TTL expired error message.
> > You can now map what ports are passed through the firewall
> > (i.e not filtered) without a packet ever passing through the
> > firewall.
> >
> > firewalk meets nmap
> >
> > thoughts?
> >
> > --
> > Lance Spitzner
> > http://www.enteract.com/~lspitz
> >
> >
> > --------------------------------------------------
> > 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).
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
> Share information about yourself, create your own public profile at 
> http://profiles.msn.com.

-- 
Lance Spitzner
http://www.enteract.com/~lspitz




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