[CentOS] [CENTOS ]IPTABLES - How Secure & Best Practice

[Ned Slider]

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 :-)