[Bug 282877] pfctl: [Feature request] Allow pfctl to reset statistics for an individual IP address
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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.