<![CDATA[[Undeadly] Automatic expiry at timeout for pf(4) overload tables]]>

Network-oriented readers will be familiar with the concept of overload tables, commonly used with state tracking options to create adaptive rulesets for such things as punishing password-guessing botnets.

A downside to tables that would tend to fill up indefinitely is that at some point they will be quite full, and the administrator would need to either manually run pfctl expire or set up a crontab entry to weed out old entries at intervals.

ping: https://framapiaf.org/@openbsdjournal@mastodon.social/116565993077076112

]]>https://billboard.bsd.cafe/topic/168/undeadly-automatic-expiry-at-timeout-for-pf-4-overload-tablesRSS for NodeWed, 13 May 2026 13:21:18 GMTWed, 13 May 2026 08:06:52 GMT60<![CDATA[Reply to [Undeadly] Automatic expiry at timeout for pf(4) overload tables on Wed, 13 May 2026 08:16:02 GMT]]>That’s an interesting idea, though I’m not sure if it’s relevant.

The question I’m asking myself is: why is it problematic to use the expire option, which is designed for this very purpose? because sysadmins forget to configure it, which causes the relevant tables to grow?!

I think this is more relevant:

The "feature request" wish I have is to be able to backup/restore tables
preserving the counters and timestamp for each entry.

Currently I do a "pfctl -T show" and save to file on server shutdown.
Then I do a "pfctl -T add" from filename to reload table on boot.
Obviously this resets all the timestamps to the current boot time.
I know, don't reboot.

seen on: - https://undeadly.org/cgi?action=article;sid=20260513064948

This seems me a good idea: save with good informations when rebooting is needed, as instance a "new" rebuilded kernel

]]>https://billboard.bsd.cafe/post/450https://billboard.bsd.cafe/post/450Wed, 13 May 2026 08:16:02 GMT