astaro fw visible in traceroute

So, are you wondering why your firewall is still visible to traceroute from the "internet" or are you wondering why internal users cannot send out traceroutes?  If you are wondering about the first, there are configuration options to make your fw non-visible to traceroute commands and they work great.  Infact I believe "firewall is visible to traceroute" is disabled by default. If you can clarify a little you can probably get some more help.. 

my firewalls are visible in a traceroute (udp AND icmp traceroutes) coming from the internet.
as i wrote above, all icmp options are disabled. 
i can see that the traceroute packets are dropped and logged by the firewall, but the firewall still sends out icmp: time exceeded in-transit - packets, which makes it visible.

thanx,

gnjb
  

Using forged packets with intentionally modified TTL is a type of attack that enables an attacker which knows he's dealing with a firewalled environment to gather info or even guess the structure of the network behind the firewall. This technique is called firewalking. Do a search on Google. The best solution is to put a specific drop rule on top Any ---> TTL Exceeded ---> Any Drop Log 

Using forged packets with intentionally modified TTL is a type of attack that enables an attacker which knows he's dealing with a firewalled environment to gather info or even guess the structure of the network behind the firewall. This technique is called firewalking. Do a search on Google. The best solution is to put a specific drop rule on top Any ---> TTL Exceeded ---> Any Drop Log 

Interesting to read
http://www.packetfactory.net/firewalk/firewalk-final.html 

Even more detailed....
http://www.sans.org/rr/firewall/firewalk.php 

i know firewalk, tcptraceroute and stuff like  that.
i am just asking why a configuration option in asl is not working as said/expected.

can somebody from astaro give a comment, please !


thanxs,

gnjb  

Hi there, 

just a short explanation.

An icmp TTL exeeded in transit packet is only sent, 
when the initial packet has been allowed by the packet filter.

Means, if the initial UDP packet has been ACCEPTED by the packet filter, 
the firewall declares the ttl icmp packets as RELATED, and lets it through.

If you thighten your packetfilter to not allowing the probe packages to be
accepted, this beahivor should go away.

best rgds, 
Gert

 

ok, then why are udp (port 34xxx up) and icmp packets accepted at the external firewall interface if i do a traceroute to host in the dmz ?

i know you can not see my policy :-( but...
- all icmp options are disabled
-there is no other "allow" rule with some udp port in the packet filter policy (and of course no udp port range) 
- no explicit "allow icmp" rules are in the packet filter policy

again, the firewall is only visible when i do traceroutes to hosts in the dmz.  traceroutes (both udp and icmp) to the external interface of the firewall are dropped.

any ideas ?? some one out there who tested this on asl 4.006 ???
am i the only one with that effect ?

 thanxs in advance,

gnjb