Prevent traceroutes

Prevent traceroutes

[Kenneth Kalmer]

Guys

How can I prevent users from doing a traceroute through my box using
iptables? Better still, how can I route a traceroute through a
different network than the default one?

Kind regards.

-- 

Kenneth Kalmer
kenneth.kalmer@gmail.com
http://opensourcery.blogspot.com

Re: Prevent traceroutes

[Jason Opperisano]

On Fri, May 20, 2005 at 12:07:11AM +0200, Kenneth Kalmer wrote:
> Guys
> 
> How can I prevent users from doing a traceroute through my box using
> iptables? Better still, how can I route a traceroute through a
> different network than the default one?

this is not 100% infallible; as anyone running the traceroute can change
the defaults, but you need to block both the UDP method of tracerouting
and the ICMP method of tracerouting:

  # standard UDP ports used by traceroute
  iptables -A INPUT -p udp --dport 33434:33523 -j DROP
  iptables -A FORWARD -p udp --dport 33434:33523 -j DROP

  # ICMP echo-req's w/ low TTL
  iptables -A INPUT -p icmp --icmp-type 8 -m ttl --ttl-lt 5 -j DROP
  iptables -A FORWARD -p icmp --icmp-type 8 -m ttl --ttl-lt 5 -j DROP

the choice of 5 as the min TTL to match on is purely arbitrary...you may
be able to choose a better value for your specific topology.

-j

--
"Brian: Congratulations, Peter. You're the Spalding Gray of crap."
        --Family Guy

Re: Prevent traceroutes

[Jason Opperisano]

On Thu, May 19, 2005 at 07:23:14PM -0400, Jason Opperisano wrote:
>   # standard UDP ports used by traceroute
>   iptables -A INPUT -p udp --dport 33434:33523 -j DROP
>   iptables -A FORWARD -p udp --dport 33434:33523 -j DROP
> 
>   # ICMP echo-req's w/ low TTL
>   iptables -A INPUT -p icmp --icmp-type 8 -m ttl --ttl-lt 5 -j DROP
>   iptables -A FORWARD -p icmp --icmp-type 8 -m ttl --ttl-lt 5 -j DROP

looking at that response--there's a situation screaming for a custom
chain:

  iptables -N DROP_TRACE
  iptables -A DROP_TRACE -p udp --dport 33434:33523 -j DROP
  iptables -A DROP_TRACE -p icmp --icmp-type 8 -m ttl --ttl-lt 5 -j DROP

  iptables -A INPUT -j DROP_TRACE
  iptables -A FORWARD -j DROP_TRACE

-j

--
"Announcer: Paw McTucket Beer. If you drink it, hot women will have
 sex in your backyard."
        --Family Guy

Re: Prevent traceroutes

[Taylor, Grant]

> looking at that response--there's a situation screaming for a custom
> chain:
> 
>   iptables -N DROP_TRACE
>   iptables -A DROP_TRACE -p udp --dport 33434:33523 -j DROP
>   iptables -A DROP_TRACE -p icmp --icmp-type 8 -m ttl --ttl-lt 5 -j DROP
> 
>   iptables -A INPUT -j DROP_TRACE
>   iptables -A FORWARD -j DROP_TRACE

I don't think that I could agree more about the need for a new chain.  I think I'd be tempted to do my match a bit differently though.

iptables -t filter -A DROP_TRACE -o eth0 -p udp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
iptables -t filter -A DROP_TRACE -o eth0 -p udp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
iptables -t filter -A DROP_TRACE -o eth0 -p icmp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
iptables -t filter -A DROP_TRACE -o eth0 -p icmp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP

This should match any traffic (UDP or ICMP) that is leaving your network with a TTL of 1 which *should* be first packet in a traceroute that your firewall / router would see.  Seeing as how this should match any traceroute traffic you should be able to change the DROP target to be any thing else that you would want to redirect the traffic out some other interface be it via the ROUTE target or the MARK target in conjunction with ip routes.

The only thing that I have not figured out as of yet how to do is DROP the first packet that the firewall sees as every attempt that I made, even a DROP policy on the FORWARD and OUTPUT chain, did not block the first "TTL Time Exceeded" response.



Grant. . . .

Re: Prevent traceroutes

[Taylor, Grant]

> iptables -t filter -A DROP_TRACE -o eth0 -p udp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
> iptables -t filter -A DROP_TRACE -o eth0 -p udp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
> iptables -t filter -A DROP_TRACE -o eth0 -p icmp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
> iptables -t filter -A DROP_TRACE -o eth0 -p icmp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
> 
> The only thing that I have not figured out as of yet how to do is DROP 
> the first packet that the firewall sees as every attempt that I made, 
> even a DROP policy on the FORWARD and OUTPUT chain, did not block the 
> first "TTL Time Exceeded" response.

I just figured it out and have tested it.  I *think* the reason that my first script did not work for the first router is b/c the raw routing code will send the ICMP TTL time exceeded message before any of the chains in the filter table have a chance to process the packet.  Hens my using the nat:PREROUTING chain.  I have also made the filtering process easier too as you do not have to filter in the filter:INPUT and filter:FORWARD chains, just the nat:PREROUTING now.

iptables -t nat -A PREROUTING -i $LAN -p udp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
iptables -t nat -A PREROUTING -i $LAN -p udp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
iptables -t nat -A PREROUTING -i $LAN -p icmp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
iptables -t nat -A PREROUTING -i $LAN -p icmp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP

This will prevent any traceroutes via the methods mentioned before from any computer coming in on interface $LAN.



Grant. . . .

Re: Prevent traceroutes

[Jason Opperisano]

On Fri, May 20, 2005 at 02:44:14AM -0500, Taylor, Grant wrote:
> I just figured it out and have tested it.  I *think* the reason that my 
> first script did not work for the first router is b/c the raw routing code 
> will send the ICMP TTL time exceeded message before any of the chains in 
> the filter table have a chance to process the packet.  Hens my using the 
> nat:PREROUTING chain.  I have also made the filtering process easier too as 
> you do not have to filter in the filter:INPUT and filter:FORWARD chains, 
> just the nat:PREROUTING now.
> 
> iptables -t nat -A PREROUTING -i $LAN -p udp -m recent --name 
> Drop_Traceroute --update --seconds 200 --rdest -j DROP
> iptables -t nat -A PREROUTING -i $LAN -p udp -m recent --name 
> Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
> iptables -t nat -A PREROUTING -i $LAN -p icmp -m recent --name 
> Drop_Traceroute --update --seconds 200 --rdest -j DROP
> iptables -t nat -A PREROUTING -i $LAN -p icmp -m recent --name 
> Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
> 
> This will prevent any traceroutes via the methods mentioned before from any 
> computer coming in on interface $LAN.

please do this in -t mangle PREROUTING and not -t nat.  filtering in
-t nat is poor form, and i know lots of people are probably emulating
your scripts.

-j

--
"Kevin: Dad, the fish got away.
 Joe Swanson: The hell it did. You get in there and you kick that
 fish's ass."
        --Family Guy

Re: Prevent traceroutes

[Taylor, Grant]

> please do this in -t mangle PREROUTING and not -t nat.  filtering in
> -t nat is poor form, and i know lots of people are probably emulating
> your scripts.

No problem.

You heard him people, the mangle table is a better place to do this, so here is an updated script:

iptables -t mangle -A PREROUTING -i $LAN -p udp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
iptables -t mangle -A PREROUTING -i $LAN -p udp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
iptables -t mangle -A PREROUTING -i $LAN -p icmp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
iptables -t mangle -A PREROUTING -i $LAN -p icmp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP

I have just tested this and found it to be fully functional on my home router too.  Have fun.  :)



Grant. . . .

Re: Prevent traceroutes

[Charlie Brady]

On Fri, 20 May 2005, Jason Opperisano wrote:

> please do this in -t mangle PREROUTING and not -t nat.  filtering in
> -t nat is poor form ...

Why is filtering in -t mangle not also poor form?

---
Charlie

Re: Prevent traceroutes

[Taylor, Grant]

> Why is filtering in -t mangle not also poor form?

I believe that you are really suppose to do the filtering in the filter table.  But seeing as how the kernel will respond to the traceroute packet that comes in before the rules in the filter table could DROP the packet we have to do this filtering elsewhere to beat the kernel to the punch.  Jason, do you have any additional comments / corrections?



Grant. . . .

Re: Prevent traceroutes

[Jason Opperisano]

On Fri, May 20, 2005 at 02:03:47PM -0500, Taylor, Grant wrote:
> >Why is filtering in -t mangle not also poor form?
> 
> I believe that you are really suppose to do the filtering in the filter 
> table.  But seeing as how the kernel will respond to the traceroute packet 
> that comes in before the rules in the filter table could DROP the packet we 
> have to do this filtering elsewhere to beat the kernel to the punch.  
> Jason, do you have any additional comments / corrections?

well--the different chains are there for a reason.  you have a filter
table for filtering packets, you have a nat table for translating
addresses...use them for their intended purpose.

one reason to not filter in nat is that not every packet traverses the
chains in the nat table, only --state NEW packets traverse the chains in
nat.  that alone should be enough of an argument that the nat table is
not intended for packet filtering.

another reason is maintainability.  i had a guy on IRC tearing his
hair out yesterday because he couldn't figure out why his packets
weren't getting through.  he added all the necessary rules to allow
the traffic, but no dice.  turns out he had a DROP rule in his nat
table...in POSTROUTING no less...  if he had just dropped the $%^#
packet in filter, it never would've gotten to nat POSTROUTING anyways.

if you desire to maintain large numbers of large-scale firewalls without
spending every waking moment caring for them, you need to do things in
an easy-to-maintain way.  filtering packets in a table not intended for
that purpose doesn't fall into this methodology.

so like i said, "it's poor form."  i'm not saying it's wrong, or that
you can't do it, but in my opinion; as a guy who's dealt with firewall
systems for a good long while now--it's not "best practice."

especially considering that we all have the wondrous mangle table
available to us, which *is* traversed by every packet, and gives us an
opportunity to do some pre-filter table scrubbing.

-j

--
"Stewie: Met her on my CB / said her name was Mimi / Sounded like
 an angel'd come to earth (come to earth) / When I went to meet her /
 Man, you should have seen her / Twice as tall as me, three times
 the girth."
        --Family Guy

Re: Prevent traceroutes

[Jozsef Kadlecsik]

Hi Jason,

On Fri, 20 May 2005, Jason Opperisano wrote:

> especially considering that we all have the wondrous mangle table
> available to us, which *is* traversed by every packet, and gives us an
> opportunity to do some pre-filter table scrubbing.

That was a very nice summary. I have to mention the 'raw' table only as an
excellent place to pre-filter the traffic, with the bonus that traffic
filtered out in 'raw' won't burden conntrack at all. (With the restriction
that only stateless rules can be used in 'raw'.)

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@sunserv.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: Prevent traceroutes

[Kenneth Kalmer]

On 5/20/05, Taylor, Grant <gtaylor@riverviewtech.net> wrote:
> > looking at that response--there's a situation screaming for a custom
> > chain:
> >
> >   iptables -N DROP_TRACE
> >   iptables -A DROP_TRACE -p udp --dport 33434:33523 -j DROP
> >   iptables -A DROP_TRACE -p icmp --icmp-type 8 -m ttl --ttl-lt 5 -j DROP
> >
> >   iptables -A INPUT -j DROP_TRACE
> >   iptables -A FORWARD -j DROP_TRACE
> 
> I don't think that I could agree more about the need for a new chain.  I think I'd be tempted to do my match a bit differently though.
> 
> iptables -t filter -A DROP_TRACE -o eth0 -p udp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
> iptables -t filter -A DROP_TRACE -o eth0 -p udp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
> iptables -t filter -A DROP_TRACE -o eth0 -p icmp -m recent --name Drop_Traceroute --update --seconds 200 --rdest -j DROP
> iptables -t filter -A DROP_TRACE -o eth0 -p icmp -m recent --name Drop_Traceroute --set --rdest -m ttl --ttl-eq 1 -j DROP
> 
> This should match any traffic (UDP or ICMP) that is leaving your network with a TTL of 1 which *should* be first packet in a traceroute that your firewall / router would see.  Seeing as how this should match any traceroute traffic you should be able to change the DROP target to be any thing else that you would want to redirect the traffic out some other interface be it via the ROUTE target or the MARK target in conjunction with ip routes.
> 
> The only thing that I have not figured out as of yet how to do is DROP the first packet that the firewall sees as every attempt that I made, even a DROP policy on the FORWARD and OUTPUT chain, did not block the first "TTL Time Exceeded" response.

Thanks Taylor, I followed Jayson's example and it worked for Windows.
It blocked the first three or for hops in most my tests. I'll try your
rules as well but I first want to read up on the recent match. I don't
like using something I don't understand properly.

Regards

> 
> 
> 
> Grant. . . .
> 
> 


-- 

Kenneth Kalmer
kenneth.kalmer@gmail.com
http://opensourcery.blogspot.com

Re: Prevent traceroutes

[Sertys]

In fact you can do it partially - windows tracert tool is based on ICMP  
and is easily preventable and routable. *nix traceroute and mtr are based  
on udp and all you can do is redirect all yer traffic over the other  
network, which is purely incorrect. The trick is that the user can point  
any port for udp connection and it still will work and trace. Sorry 4 the  
disappointment.



On Fri, 20 May 2005 00:07:11 +0200, Kenneth Kalmer  
<kenneth.kalmer@gmail.com> wrote:

> Guys
>
> How can I prevent users from doing a traceroute through my box using
> iptables? Better still, how can I route a traceroute through a
> different network than the default one?
>
> Kind regards.
>



-- 
www.supportivo.org

I can't stop myself checking for pigs in the outlets. Everybody thinks i'm  
a punk, cause of the hairstyle(220V).
end

Re: Prevent traceroutes

[Sebastian Siewior]

On Fri, May 20, 2005 at 12:07:11AM +0200, Kenneth Kalmer wrote:
> Guys
> 
> How can I prevent users from doing a traceroute through my box using
> iptables? Better still, how can I route a traceroute through a
> different network than the default one?
> 

iptables -t mangle -A PREROUTING -j TTL --ttl-inc 1

this would make your router invisible :)

-- 
regards
Sebastian Siewior