[Bug 282877] pfctl: [Feature request] Allow pfctl to reset statistics for an individual IP address

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 25 Nov 2024 10:15:09 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282877

Leonid Evdokimov <leon+freebsd@darkk.net.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |leon+freebsd@darkk.net.ru

--- Comment #4 from Leonid Evdokimov <leon+freebsd@darkk.net.ru> ---
Created attachment 255439
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=255439&action=edit
pfctl -T makezero

> An external tool like blacklistd or fail2ban (or something home-brewn)
> tracks the PF log, and resets the statistics for offending hosts
> that are already in table <blocked>.

That's certainly an existing pattern for pf table management. E.g.
https://forums.freebsd.org/threads/pf-firewall-expiretable.61827/ discusses
that as well.

I'd like to suggest one more patch, that makes alike pattern easier to
implement for home-brewers.

Feeding pflog to blacklistd is fine, but `pf` tables also have counters those
can be used for the same purpose. So this policy might be implemented using
either pflog or pf table counters and these solutions might have different
performance and reliability characteristics. As far as I understand, `counter`
is always incremented on a match, but pflog might be dropping packets in case
of consumer being somewhat slow.

So I suggest to add a table command "makezero" that combines semantics of
`make` (doing things incrementally and as-necessary) and `zero` clearing
statistics. :-)

In the case of table counters having an acceptable overhead, the cron-job would
be as simple as pfctl -t blocked -T makezero && pfctl -t blocked -T expire
1209600

-- 
You are receiving this mail because:
You are the assignee for the bug.