Re: filtering in which rules?

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

 



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.




[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