Re: Best practice for packet filtering

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

 



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



[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