All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Opperisano <opie@817west.com>
To: netfilter@lists.netfilter.org
Subject: Re: Prevent traceroutes
Date: Fri, 20 May 2005 15:37:16 -0400	[thread overview]
Message-ID: <20050520193716.GA12584@bender.817west.com> (raw)
In-Reply-To: <428E3493.4040505@riverviewtech.net>

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


  reply	other threads:[~2005-05-20 19:37 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-19 22:07 Prevent traceroutes Kenneth Kalmer
2005-05-19 23:23 ` Jason Opperisano
2005-05-19 23:33   ` Jason Opperisano
2005-05-20  6:39     ` Taylor, Grant
2005-05-20  7:44       ` Taylor, Grant
2005-05-20 15:20         ` Jason Opperisano
2005-05-20 15:34           ` Taylor, Grant
2005-05-20 18:44           ` Charlie Brady
2005-05-20 19:03             ` Taylor, Grant
2005-05-20 19:37               ` Jason Opperisano [this message]
2005-05-23  7:01                 ` Jozsef Kadlecsik
2005-05-20  8:01       ` Kenneth Kalmer
2005-05-20  1:12 ` Sertys
2005-05-20 19:17 ` Sebastian Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050520193716.GA12584@bender.817west.com \
    --to=opie@817west.com \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.