Re: Use "flow-table" (meter) to block IPs

[Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>]

On Tue, Feb 05, 2019 at 07:42:06AM +0100, Florian Westphal wrote:
> Thomas Luening <toml@xxxxxxx> wrote:
> > These are my Test-Rules how to understand "meter"... in a local
> > simulation against synflag-flooding. Regular Traffic will be
> > accepted, an unregular amount of packets will be dropped.
> > As you can see, for all unregular Packets (forced by me)
> > the SADDR is temporarly stored in the table "synflg-meter".
> > 
> > How can I use those entries to block the IP completely
> > until the timer is off. Is that even possible?
> 
> Yes, but not with meters.  Something like this might work:
> 
> table ip tfilter {
>   set synflood {
>     type ipv4_addr
>     flags timeout
>     timeout 15s
>     gc-interval 10s
>     size 100000
>   }
> 
>   chain input {
>      type filter hook input priority 0; policy accept;
>      ct state established,related accept
>      ip saddr @synflood drop
>      tcp flags syn limit rate 1/second burst 3 packets accept
>      tcp flags syn set add ip saddr @synflood reject with tcp reset
>   }
> }

I have added a few more exmaples to the wiki. Starting 4.18, we can
use native set / map syntax (so we can deprecate 'meter' at some
point).

Simple ratelimiting per source address:

% nft add table filter
% nft add chain filter input {type filter hook input priority 0\;}
% nft add set filter ssh-meter { type ipv4_addr\; flags dynamic\; }
% nft add rule filter input tcp dport 22 ct state new add @ssh-meter { ip saddr limit rate 10/second } accept

Using 'ct count' to do connlimit, again using native set syntax:

table ip filter {
       set connlimit {
               type ipv4_addr
               size 65535
               flags dynamic
       }

       chain y {
               type filter hook output priority filter; policy accept;
               ct state new add @connlimit { ip daddr ct count over 20 } counter packets 0 bytes 0 drop
       }
}

This example above also requires kernel >= 4.18.