PF Dangling states problem

[AmbrSb]

Dangling states problem: pf consults its state table before the rule set (as it should). So even after adding a rule to block certain connections, the ones that have a corresponding entry in the state table will continue uninterrupted.

AFAIK, pf does not have any built-in/native mechanism to automatically terminate states that go against the current rule set.

Sifting through the states and manually "pfctl -k"ing unwanted states does not look like a sustainable solution to this problem.

I am writing a python script to automate this process, as much as possible.

My questions are:

Do you know any other projects aiming at this?

Is there anything on the roadmap for the pf project to address this issue?

Are there any major road blocks to implementing this directly in pf?


Can someone shed more light on this, please?
Thanks.

 

[Murph]

From my point of view, there really isn't a problem to solve here. There are two major obvious cases, both of which are essentially trivial to handle, and do not justify major effort (either to change pf itself, or for major scripting effort to police things).

The first major case is if pf's overload feature is triggered. That is automatically dealt with by adding flush or flush global to the rule in pf.conf.

The second major case is something like security/py-fail2ban. This is also very easy to deal with using the following configuration (or equivalent):

actionban = /sbin/pfctl -t <tablename> -T add <ip>
            /sbin/pfctl -k <ip>

To me, if something restrictive or blocking is being dynamically added to the firewall rules, it is always as a response to some form of abuse, so subtlety is not an issue and it is fine to just tear down all states associated with the abusive IP address (trip my anti-abuse filters, and you get blocked from all ports, with all states killed, not just the service you were abusing). If the firewall change is not in response to abuse, letting the existing states naturally expire should be just fine, and is arguably much better due to not essentially "crashing" the connection underneath the application layer. Suddenly blocking traffic at the firewall level is essentially a BadThing™ for legitimate, established, non-abusive connections / flows.

Based on that view of it, I see this as a non-issue and not something which needs or justifies additional complexity added to pf itself. I don't know for certain, but I'd guess that most OS developers would probably share something similar to that analysis.

Perhaps you have some other scenario in mind which I'm not seeing. If so, some detail on your scenario might help provoke some alternative thinking on the issue, and justify a need to add complexity to pf itself.