On 30/06/16 18:49, Mike wrote: > On Wed, Jun 29, 2016 at 1:49 PM, Gordon Messmer > <gordon.messmer at gmail.com> wrote: >> >> By putting these rules first, before the "ESTABLISHED,RELATED" rule, you're >> applying additional processing (CPU time) to the vast majority of your >> packets for no reason. The "E,R" rule should be first. It won't match the >> invalid packets you're trying to drop. >> >> You're not specifying the "new" state in any of your input ACCEPT rules, >> which means that you're also ACCEPTing invalid packets that don't match the >> handful of invalid states you DROPped earlier. >> >>> 1. The drop commands at the beginning of each chain is for increase >>> performance. >> >> >> I understand what you're trying to do, but in the real world, this will >> decrease performance. >> > > Gordon, > > I appreciate your observations. > I've been using iptables for a long time and still don't really know > how to configure the order of rules to optimize performance while > providing thorough filtering as a component of security. > Can you share links and/or other sources and guides on this subject. > > Thank you. Hi Mike, If I may reply... The premise is simple, rules are located in chains. Chains of rules are evaluated from top to bottom, until the packet being evaluated matches a rule. You want to order your rules so that packets pass through as few rules as possible, i.e they are matched and either accepted or rejected as soon as possible. Each time a packet is evaluated against a rule it is using CPU cycles, so the fewer the better. Of course the number of rules evaluated will depend on the packet. For example, if you run a mail server receiving 1,000 emails per day, a web server with 10,000 hits per day and a DNS server with 100,000 queries per day, it makes sense to order your rules to accept the DNS queries first, followed by http traffic, and to accept the smtp traffic last. This ordering would cause 111,000 packets to be evaluated by the first rule, 11,000 by the second rule and 1,000 by the third rule giving a total of 123,000 times a packet was inspected by a rule. If we reversed the order we would see 111,000 for our first rule, 110,000 for our second rule and 100,000 for our third rule, giving a total of 321,000 examinations which is 2.6 times more than our first example. Don't forget it's only the initial (first) packet of each connection that is passing down through our chain of rules - all subsequent packets would be matched against our Established,Related SPI rule which is typically placed at the very top of the chain so our firewall doesn't have to examine every packet of that 100MB email you just received in the same way as it examines the first packet. This is the rule that will always by far match the most packets hence why it's always placed near or at the top of the chain. This is a very simplistic approach but you get the idea. As things get more complicated, you can create user-defined chains to filter off certain traffic for further examination, maybe logging action and/or rate-limiting, rather than subjecting all packets to that extra scrutiny where it is not applicable thus improving the overall efficiency. You want to make the flow of packets through the firewall as efficient as possible. This approach is only really needed where you want a given packet to be evaluated by two or more rules (e.g, log the packet then drop it). In reality most modern hardware is more than capable of achieving throughput that isn't going to be rate limiting even with quite complex rule sets, but we all like to optimise stuff anyway don't we :-)