Rate-limiting in PF

Max maximos at als.nnov.ru
Mon Oct 9 04:28:51 UTC 2017


man pf.conf:

      For example, the following    rules will protect the webserver 
against hosts
      making more than 100 connections in 10 seconds.  Any host *which 
connects
      faster than this rate* will    have its address added to the 
<bad_hosts> ta-
      ble and have all states originating from it flushed.  Any new packets
      arriving from this    host will be dropped unconditionally by    
the block
      rule.

        block quick from <bad_hosts>
        pass    in on $ext_if proto tcp    to $webserver port www keep 
state \
            (max-src-conn-rate 100/10, overload <bad_hosts> flush global)


Check the output of "pfctl -sS".


07.10.2017 8:51, Dave Horsfall пишет:
> On Thu, 5 Oct 2017, Dave Horsfall wrote:
>
>>> is anything added to the table (pfctl -t woodpeckers -T show)
>>
>> I have lots of them because I've been adding them by hand, but this 
>> time I'll hold back and observe, just to be sure.
>
> No, they are not being added; here's an extract from the mail log:
>
> Oct  7 15:21:28 aneurin sm-mta[6908]: v974LI1n006908: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:21:48 aneurin sm-mta[6909]: v974Lcwj006909: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:21:59 aneurin sm-mta[6910]: v974LnTe006910: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:22:13 aneurin sm-mta[6923]: v974M2QU006923: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:22:24 aneurin sm-mta[6924]: v974MGKm006924: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:22:35 aneurin sm-mta[6925]: v974MOQW006925: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:22:45 aneurin sm-mta[6926]: v974MZOZ006926: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:22:56 aneurin sm-mta[6927]: v974MkO2006927: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:23:07 aneurin sm-mta[6928]: v974MvjQ006928: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:23:18 aneurin sm-mta[6930]: v974N7c3006930: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:23:38 aneurin sm-mta[6931]: v974NRZM006931: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
> Oct  7 15:23:49 aneurin sm-mta[6932]: v974NcYF006932: [37.49.224.104] 
> did not issue MAIL/EXPN/VRFY/ETRN during connection to IPv4
>
> "pfctl -t woodpeckers -T show | grep 37.49.224.104" is empty.
>
> But wait...
>
> It looks for all the world like they are deliberately stopping after 
> 5/m without getting blocked, waiting a bit, then starting up again...  
> Either that, or the block is not "sticking" for some reason.
>
> Hence my question: can anyone state unequivocally that the rate 
> limiting does indeed work (pref. with proof) and that I am doing 
> something subtly wrong, and if so what is it?
>
> In the meantime, I've enabled logging on the rate-limited packets, to 
> see if that sheds a little more light.
>
> If/when confirmed as a PF bug I'll report it accordingly, as I prefer 
> to eliminate my own stupidity first :-)
>



More information about the freebsd-pf mailing list