Re: TTL patch buggy?

[Ramin Dousti <ramin@cannon.eng.us.uu.net>]

On Wed, Jan 07, 2004 at 03:07:22PM -0500, John A. Sullivan III wrote:

> <snip>
> Thanks to all of you for such insightful replies.  As I synthesize them,
> I see some problems and a possible solution.
> 1) Incrementing does create the possibility of routing loops although
> this is minimal for end points.
> 2) Dropping packets with ttl < number_of_internal_hops may be safer but
> requires a knowledge of the internal environment and incurs an overhead
> with every internal change.
> 3) sysctl seems to provide no way to simply not send ttl expired
> messages
> 4) If the goal is simply to hide the firewall, could one just drop all
> packets where ttl == 1.

You can hide the firewall and the internal network if you reset the
TTL of these packets to the max (255) and drop the outbound ICMP
port unreachable (in case of UDP traceroute) and ICMP echo-reply
(in case of ICMP traceroute). But again, make sure you're not transit
and no-one inside is playing with stuff like MIRROR.

Ramin


> These packets would never make it only the
> internal network anyway; it does not require incrementing ttl and 
> requires no knowledge of the internal network.  I assume that, since one
> can prevent the ttl expired from being sent by incrementing, that
> netfilter will grab and drop the packet before the ttl expired
> notification is sent.  Is there a problem with this approach?
> -- 
> John A. Sullivan III
> Chief Technology Officer
> Nexus Management
> +1 207-985-7880
> john.sullivan@nexusmgmt.com
> ---
> If you are interested in helping to develop a GPL enterprise class
> VPN/Firewall/Security device management console, please visit
> http://iscs.sourceforge.net 
>