Re: SV: Best practice for packet filtering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux