On Sunday, 3 de July de 2005 23:24, Paul Gear wrote: > Daniel Pittman wrote: > > It also tends to encourage "shortcuts" in the firewall, like accepting > > any RELATED/ESTABLISHED packets, > > Am i right in understanding that you consider accepting > RELATED/ESTABLISHED packets a bad thing? It simplifies the deployment of handcrafted firewalls, but it can strike back when you want to control certain things. Specially when allowing R/E packets is the first thing you do. For example, time dependant rules like "allow navigation/ftp from 14 to 16 hours" translate into allowing NEW connections like "allow new ftp connections from 14 to 16, and let them stay open for ever". Obviously, that's not what you probably meant when writting those time based rules. Problems would also arise with individual packet logging. You could move all those "weird" rules before the R/E packet acceptance, but that would make the handcrafted firewall unmantainable. Leaving the R/E packets acceptance to the end should solve all this problems, but that would mean that your R/E packets would be traversing all your firewall rules, so extra care should be taken. Also some people will have something to say about performance and delays, but with current typical horsepower it shoudn't matter. So, probably, the best way to go is allowing the R/E packets alongside their "new state" counterparts. It also clarifies where the packets are accepted and WHY. Also, "iptables -v" should be a lot more useful than before. Regards, Eloi Granado
Attachment:
pgpikeZSbEeEK.pgp
Description: PGP signature