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