Re: TTL patch buggy?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mer 07/01/2004 à 22:38, Ramin Dousti a écrit :
> 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).

Avoiding traceroutes can't be easily done by blocking consequences, as
they are numerous. I mean you can do a traceroute using TCP as well (see
tcptraceroute tool), or even using applications requests on UDP, such as
a DNS request (useful to traceroute microsoft.com DNS server), or
anything else that can trigger a valuable target response. In thoses
cases, you really can't block final answer as it is a valid one.

Moreover, if blocking echo-reply is no arm, blocking ICMP errors can
have really bad side effects. If we look a bit closer, a well configured
firewall should not let a packet destined to a closed UDP port go
through... Letting conntrack deal with ICMP error is to me the best
deal.

If you really want to prevent traceroute based discoveries, you just
should raise packets TTL so they don't expire within your network for
normal operations. So you'll add 2, 3, maybe 4 to the TTL, but not more.
Resetting TTL to 255 is far too much if a loop appears.
If you want to prevent discovery based on the TTL of packets you send,
reset TTL for outbound traffic to a default value such as 64.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread! 



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux