Best practice is just to use basic math , unless you ratio of blocked packets are "a lot" more than normally the first rule you create should always be :
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT ( some use optional -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu in front of this where needed )
If you assume a packet for a normal FORWARD packet goes through the following , and we have just 4 rules , just for "quick maths" purpose .
RAW(IN) - CONNTRACK - MANGLE(IN) - NAT(IN) - ROUTE - MANGE (FWD) - FILTER (FWD) - MANGLE (OUT) - NAT(OUT)
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -s BADHOST -j DROP -A FORWARD -m conntrack --ctstate NEW -p tcp -m tcp --dport 80 -j ACCEPT -A FORWARD -j DROP
So everything in the first and third rule would pass the all the "hops" , so it should not matter where in the chain the rules are for CPU usage in theory .
So the first rule would pass 9 "hops" and hit on first rule in forward , while third rule would pass same 9 "hops" but also "pass" 2 rules in front before the hit was found Second rule with single BADHOST being dropped would pass 6 "hops" and "pass" 1 rule before being DROPed .
IF you moved that ONE host to the MANGLE to be DROPed there first , you would save the 3 "hops" pluss the 1 FORWARD rule over
MANGLE(IN) - NAT(IN) - ROUTE - MANGE (FWD) - FILTER (FWD) BADHOST DROP - 1 - 2 - 3 - STATE ACCEPT
And now you would also , unintentionally black VALID return SYN,ACK packet from same host when port 80 traffic had BADHOST as destination , since the DROP rule now comes before the STATE ACCEPT rule !
More importantly you would ADD one rule for all valid traffic must pass in the path , which cost also CPU for your performance .
For statistical data from a "low performance" FireWall , you can see that it has quita a high ratio for valid traffic 9724 million packets vs 35 and 31 Millions . which is more than 100:1
9724M 9740G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
35M 1961M in-eth0 all -- eth0 * 0.0.0.0/0 0.0.0.0/0
31M 1670M in-eth1 all -- eth0 * 0.0.0.0/0 0.0.0.0/0
When I look at the stats for only the DROPed packets the ratio is closer to 10000:1 (aka less then 1Million packets was dropped for almost 10000 Millions packets ) If you assume the same ratio for the above examples rules It makes little sense to lower CPU usage for 1 packet by even a factor of 2 , and increase CPU usage for 10000 packet with a factor of 1.1 - 1.2 or more Even if I cannot tell how much exactly as CPU usage per packet + per "hop" In the Iptables chain , we already know that if the improvement was significat for the ONE packet , it would be similar decremental to the 10000 packets that would not need to pass this drop rule ( potensially losing you 1000 cylces for each cycle you saved ) ...
( Most likely more since DROPs from a SINGLE HOST would most likely be in the millions : 1, and for each host you add you will increase CPU usage for all valid traffic )
Best regards
André Paulsberg-Csibi
Senior Network Engineer
IBM Services AS
Sensitivity: Internal
-----Opprinnelig melding-----
Fra: darius <dram@xxxxxxxxxxx>
Sendt: mandag 2. juli 2018 17.55
Til: André Paulsberg-Csibi (IBM Consultant) <Andre.Paulsberg-Csibi@xxxxxxxx>; Neal P. Murphy <neal.p.murphy@xxxxxxxxxxxx>; netfilter@xxxxxxxxxxxxxxx
Emne: Re: SV: Best practice for packet filtering
I suppose suggestion (or best practice) is to filter unwanted packets in mangle table prerouting chain, not raw. Does the same apply to MANGLE/PREROUTING?
/Darius
On 02-07-2018 13:22, André Paulsberg-Csibi (IBM Consultant) wrote:
> Careful using the iptables RAW chain to block large lists of unwanted IPs .
> It is best practice is to "block" most in the FILTER chain , unless there is a FEW (low number of host) that have extensive traffic !
> The CPU cycles "saved" are a myth , as when you grow the RAW chain CPU used to process longer list for all traffic "costs" more then what you save by blocking these earlier .
>
> Then you also add complexity , as you now have to account for multiple sources that no longer reach your CONNRACK state engine .
>
>
>
> Best regards
> André Paulsberg-Csibi
> Senior Network Engineer
> IBM Services AS
>
>
> Sensitivity: Internal
>
> -----Opprinnelig melding-----
> Fra: netfilter-owner@xxxxxxxxxxxxxxx <netfilter-owner@xxxxxxxxxxxxxxx>
> På vegne av darius
> Sendt: søndag 1. juli 2018 23.15
> Til: Neal P. Murphy <neal.p.murphy@xxxxxxxxxxxx>;
> netfilter@xxxxxxxxxxxxxxx
> Emne: Re: Best practice for packet filtering
>
> Makes perfect sense. I'll update my firewall rules asap. Some sources on the inet do not provide detailed explanation on why one or another solution was chosen. Now I've got all the details needed. Indeed there is no meaning to pass packet up to INPUT/FORWARD if you already know, that it needs to be dropped. Thanks!
>
> /Darius
>
> On 01-07-2018 20:24, Neal P. Murphy wrote:
>> On Sun, 1 Jul 2018 18:49:12 +0200
>> darius <dram@xxxxxxxxxxx> wrote:
>>
>>> Hi. Out there in the net one can find two different 'best practice'
>>> suggestions on how to filter bad packets, bogons, DDoS atack and so on.
>>> One claims, that filtering rules must go into filter section (input,
>>> forward), other claims that best is to add rules to mangle table and
>>> prerouting chain. The only benefit explained for the latter was that
>>> it increase performance of iptables rules. Haven't found more
>>> benefits. I use nftables. Does the same apply? Is it still the best
>>> way to put blocking rules to mangle table? I currently use filter
>>> table. Are there any huge disadvantages in that?
>>
>> Huge disadvantages? I think not. Wasting CPU cycles that could limit the maximum throughput of your firewall? Certainly a disadvantage worth considering.
>>
>> Theory: drop packets you already know you don't want as early as possible.
>>
>> For Smoothwall Express (which still uses iptables), I use mangle:PREROUTING to:
>> - drop INVALID packets
>> - drop packets from blacklisted IPs
>> Reason: it is not worth spending even *one* CPU cycle more than is
>> needed to process or inspect these packets. I already know that
>> INVALID packets won't go anywhere and I already know that I don't
>> want blacklisted packets passing into or through my firewall. (I
>> should also have Express drop TEST NET packets there because I
>> already know that they should never be routed.)
>>
>> In iptables, mangle:PREROUTING allows limited actions; I don't know if nftables is more 'permissive'. For example, in mangle:PREROUTING, I can drop packets from internet that I don't want. But I have to use filter:{INPUT,FORWARD,OUTPUT} to reject packets I don't want to keep internal hosts from 'pausing' until the 'no response' timer expires.
>>
>> Suppose you decide you want no traffic from porn.com (94.199.252.153). You can drop these packets in mangle:PREROUTING. Or you can continue processing these packets through all the examinations and checks until they hit the INPUT|FORWARD policy DROP. That's potentially a lot of CPU cycles spent inspecting packets that you knew should be dropped before they even arrived. Remember the old English proverb, "Waste not, want not."
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter"
>> in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo
>> info at http://vger.kernel.org/majordomo-info.html
>>
��.n��������+%������w��{.n����z���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
