Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Daniel Lopes <lopsch@lopsch.com>
Cc: netfilter@lists.netfilter.org
Subject: Re: filtering in which rules?
Date: Sat, 21 May 2005 03:11:30 +0200	[thread overview]
Message-ID: <428E8AC2.8090005@lopsch.com> (raw)
In-Reply-To: <Pine.LNX.4.60.0505202018220.12153@darkstar.sysinfo.com>

R. DuFresne schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Jason et. al.,
> 
> 
> I wacthed the discusion today on leaving filtering to the filter chain 
> and leave nat to nat and routing to the pre/post chains.  But, when one 
> reads other documentation and it has paramaters to iptables like this;
> 
> 
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT ACCEPT
> iptables -t nat -P PREROUTING DROP
> iptables -t nat -P POSTROUTING DROP
> 
> 
> It g9ives one the impression that matters of filtering and decision 
> making for a packet are not as carved in stone as implied in the 
> discusion today. Jason makes some great points about complexity of 
> rulesets and trying to maintain that accross a number of firewalls 
> overtime.  But, that seems to implay that others have adopted complexity 
> and feel fine with all it brings to the maintainace table.  Unless I'm 
> reading the DROP defaults for the pre/post routing above.  So for 
> clarification one more time, should one read these docs with a grain of 
> salt and alter acordingly, perhaps placing a default ACCEPT in the 
> pre/post chanins and then doing what filtering is required in the 
> 'proper' filter chains for clarity? I direct this to Jason in 
> particular, though Grant as well as others may wish to input again 
> <cause Jason and Grant seem to know their stuff when it comes to iptables>.
> 
> Thanks,
> 
> 
> Ron DuFresne

Hmm I do filtering, mangling and natting in the appropriate tables for 
better arrangement and because afaik some things can only be done in the 
responsible tables. For example the outgoing interface shouldn´t be 
known in the PREROUTING chain of the nat table unless iptables uses it´s 
own routing algorithm for finding it out or a hook to the existing one I 
don´t really know.
I think it´s difficult to find a way so that the filtering will be 
effective. For example should DROP be as soon as possible so the packet 
won´t traverse all needed chains.
e.g.:
 > iptables -P INPUT DROP
 > iptables -P FORWARD DROP
 > iptables -P OUTPUT ACCEPT
 > iptables -t nat -P PREROUTING DROP
 > iptables -t nat -P POSTROUTING DROP
Let´s assume a packet destined to the machine no forwarding necessary.
If you don´t want that packet (no ACCEPT rules in the nat PREROUTING for 
that type) it will be dropped.
With this set
 > iptables -P INPUT DROP
 > iptables -P FORWARD DROP
 > iptables -P OUTPUT ACCEPT
 > iptables -t nat -P PREROUTING ACCEPT
 > iptables -t nat -P POSTROUTING ACCEPT
the packet also would have to traverse the INPUT chain until it would be 
dropped.
Only as an example.
I also think positioning the rules in an order within the chains 
depeding on the frequency you expect a packet has an effect on 
effectiveness. The deeper you have to traverse a chain the more time it 
takes to handle the packet. For alot of packets it can have an effect.


  reply	other threads:[~2005-05-21  1:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <42889941.5060507@griffous.net>
2005-05-16 18:35 ` Combined Internal/External DNAT question Taylor, Grant
2005-05-16 19:27   ` R. DuFresne
2005-05-16 19:50     ` R. DuFresne
2005-05-16 21:06       ` Taylor, Grant
2005-05-21  0:28         ` filtering in which rules? R. DuFresne
2005-05-21  1:11           ` Daniel Lopes [this message]
2005-05-21  2:37           ` Taylor, Grant
2005-05-21 19:24           ` Jason Opperisano

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=428E8AC2.8090005@lopsch.com \
    --to=lopsch@lopsch.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox