Delete state, Reject & Block rules work perfectly fine
-
Mikrotik here I come :D
I thought you switched to OPNsense recently…
P.S. Schedule rules do work just fine - the allow ones. (I for one certainly do not want to kill everyone's working connections just because I have been playing with some rules. If desired, I can do that manually once I am done with the work. Not e.g. 30 times in an hour...)
-
What you want is pretty irrelevant.
What should happen when running a schedule is another thing and it doesnt work.
Its like captive portal. When the time is up, youre done. No matter what you are doing…
-
Still not a bug. Maybe it could best be described as a limitation. A well-known one at that. You should probably move on to that free firewall that's better than pfSense.
Yes, it would be nice if schedule triggers cleared states for just that rule. Submit a feature request.
As this dangling state issue appears in the first instances of pfsense [edit]
it would appear to be an issue with the package bundled with FreeBSD called Packet FIlter which might also be known as the Berkeley Packet Filterhttps://en.wikipedia.org/wiki/Berkeley_Packet_Filter They are two different packages [edit]https://www.freebsd.org/cgi/man.cgi?query=pf&sektion=4&apropos=0&manpath=FreeBSD+10.1-RELEASE
So it would appear at this stage that any stateful firewall on xyzBSD both opensource or commercial has the bug unless specific measures have been taken to address the problem (which I have yet to see advertised in my searches), but the source of the problem still has not been identified [edit]
as it could implicate the Libpcap libraries IF Packet Filter is the same thing as the Berkeley Packet Filter.[edit]WRT to PF ported to other OS's the closest comparison could be considered NetFilter in Linux but is considered more complicated due to it working on sets of rules that work in chains unlike the top down match listing of PF, and Linux has a comparable problem called Dangling Sockets.
The situation is further not helped as Chemlud points out pfctl is broken in this thread
https://forum.pfsense.org/index.php?topic=93336.msg518298#msg518298No problem to me, as long as the -k worked properly, in the pre-2.2 era. But now I have to kill all states to make it really work. Dunno why. Always the states with
re1 tcp routerIP(localIP) -> remoteIP ESTABLISHED…
in the states tab survive the -k procedure.
That's not fair. :-(
Update: selective killing of states with option -k is broken, leaves a lot of states in place, as pointed out above. No way around kicking off all users by killing all their states.
Maybe identify the version where pfctl works at killing selective states would be a work around assuming bugs in the corresponding PF are not too compromising.
I thought you switched to OPNsense recently…
P.S. Schedule rules do work just fine - the allow ones. (I for one certainly do not want to kill everyone's working connections just because I have been playing with some rules. If desired, I can do that manually once I am done with the work. Not e.g. 30 times in an hour...)
It wouldnt make any difference as this problem goes back to early versions of xyzBSD including pfsense 1.x as mentioned above.
Whilst you may not want to kill off one or more peoples active connections, would you say the same if it were some malware/virus/botnet established connection?
I have to say, I'm shocked at the widespread acceptance and such long running measured in years of the Dangling States or Dangling Sockets issue/bugs, no wonder bad actors find it so easy to compromise systems.
I'm beginning to wonder if there is any firewall out there that is capable of performing as requested.
Likewise with what I have discovered above, we cant even expect ESF to fix the problems as its core xyzBSD code unless one or more in ESF also code at the OS/package level? Are there any ESF employees who can code the affected packages?
-
Yeah, whole BSD is broken, pf is broken, everyone can hack it on a whim, it's full of viruses and botnets that love the buggy shit, and so we are all doomed… What users want is also irrelevant because it's much better to cut them off instead of letting them do it at proper time.
Another shitty thread waiting for a press of LOCK button.
-
You really need to see a shrink mate…
ANY thread you comment is not good enough for you. Something is ALWAYS wrong with the topic, content, OP or just about anything else you might seem to dislike...
Geesus.
-
P.S. Schedule rules do work just fine - the allow ones. (I for one certainly do not want to kill everyone's working connections just because I have been playing with some rules. If desired, I can do that manually once I am done with the work. Not e.g. 30 times in an hour…)
So you admit by omission that the Block & Reject dont work. Two out of the three conditions (Pass, Block & Reject) seems to be the majority of the options not working as expected, ergo a bug.
With regard to the whole of BSD is broken, depending on how you view a dangling state, some see it as acceptable, others see it as not acceptable, I fall into the latter and find dangling states not acceptable for the reasons I have previously cited, namely I want a firewall to block traffic irrespective of if its trying to get into a private system or network or out.
Data leakages is not viewed favourably by most businesses so how would CEO's, shareholders and others like it if their [insert whatever private data is important to them and/or you] is leaked all because some dont view a dangling state in xyzBSD as important or as a bug?
As I have said before, you cant legitimise a bug by documenting it. Fortunately this is not just a bug in pfsense code, but is still a bug for anyone who happens to use PF on xyzBSD.
However it would be nice if ESF could come up with a solution to address this problem as I'm sure it would increase their kudos in the firewalling community and earn them more users and revenue. At the same time it would be nice if the PF maintainers could address the problem of dangling states by perhaps introducing a switch which could kill affected states for those instances where a rule has changed on reload and/or by fixing pfctl. As long as the BSD maintainers could do the job, I'm sure it would elevate the status of BSD as a firewalling solution instead of the current what I consider to be a design flaw in PF wrt dangling states.
-
IMO "Dangling States" are a bug as it makes it easy for bad actors & bad programs to get in and out of your system. Another way to look at this is, by asking this question, when is a firewall not a firewall? When it cant clear states down according the rules and/or by the schedules set up.
It's working as intended, aka, a feature, not a bug. It doesn't make anything easy because the rules still work, for new connections. It's not like firewall rules change all the time, mostly set in stone except for opening ports.
I'm pretty sure they fixed the scheduling issue. Even with schedules, it's not a security issue, it's a bandwidth issue. People want to block high bandwidth services during the day. If it was a security issue, they'd never open the rules in the first place.
-
See:
https://forum.pfsense.org/index.php?topic=93336.23
intuitively I would call this behaviour a bug.
I may cite you, Derelict:
" Re: Firewall: Scheduling block game console
« Reply #4 on: May 04, 2015, 02:49:18 am »And all your ssh and other persistent sessions go with it. Yuck."
Further to this issue where Chemlud states pfctl doesnt work
https://forum.pfsense.org/index.php?topic=93336.msg518298#msg518298
No problem to me, as long as the -k worked properly, in the pre-2.2 era. But now I have to kill all states to make it really work. Dunno why. Always the states with
re1 tcp routerIP(localIP) -> remoteIP ESTABLISHED…
in the states tab survive the -k procedure.
That's not fair. :-(
Update: selective killing of states with option -k is broken, leaves a lot of states in place, as pointed out above. No way around kicking off all users by killing all their states.
I checked the freeBSD bug report and could only find the reports that pfctl wasnt working back in 2006,2007 & 2008.
https://bugs.freebsd.org/bugzilla/buglist.cgi?order=Importance&query_format=advanced&short_desc=pfctl%20-k&short_desc_type=allwordssubstr
So I tried the command pfctl -k network ie pfctl - k 1923.168.1.0/24 and sure enough it does kill the states on the lan side, however as the dangling state is an inward bound wan side state pfctl -k would need to kill the opposite side state in this case the wan side inward bound state.
pfctl -s states gives a dump of states and matches what is seen in the Diagnostic: State webpage but the requirement to get the dangling states cleared up still needs to be addressed.
Having looked at the switches for pfctl commands
https://www.freebsd.org/cgi/man.cgi?query=pfctl(8)&sektion=
One approach might be the use of Anchors…
https://www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5&apropos=0&manpath=FreeBSD+10.1-RELEASE#ANCHORSBut I cant see anything in pfctl to handle flushing anchors so the two PF & pfctl seem incomplete as a package.
https://www.freebsd.org/cgi/man.cgi?query=pfctl(8)&sektion=It seems initially working on the basis of existing functionality in PF & pfctl, labels maybe the way to go wrt getting the relevant states on both sides flushed, but then the problem occurs where scheduled rules kick in like the test example I posted earlier so it would not work as they would have different labels thus requiring additional functionality still.
There isnt any easy fix with this problem, so I'm going to have to have a think what would be the best approach, because even if pfctl could delete both the inward and outbound corresponding states it still wouldnt address the scheduled rules kicking in. Searching for states to delete on both sides could be too slow if having to run down a sizable list of rule changes.
Somewhere either in pfsense or in PF/pfctl there would need to be new functionality to address the dangling states issue, but where and what to tackle the problem in a reasonable manner is a tricky one.
IMO "Dangling States" are a bug as it makes it easy for bad actors & bad programs to get in and out of your system. Another way to look at this is, by asking this question, when is a firewall not a firewall? When it cant clear states down according the rules and/or by the schedules set up.
It's working as intended, aka, a feature, not a bug. It doesn't make anything easy because the rules still work, for new connections. It's not like firewall rules change all the time, mostly set in stone except for opening ports.
I'm pretty sure they fixed the scheduling issue. Even with schedules, it's not a security issue, it's a bandwidth issue. People want to block high bandwidth services during the day. If it was a security issue, they'd never open the rules in the first place.
Working by design but I would say a flawed design when considering the issue of dangling states. Where I differ perhaps to others is I consider a bug anything thats not working as the user expects, so I could say the Apply Changes button when making a rule change is a bug as it misleads the user into thinking the new rules are ineffect when they may not be. Thats a dangerous situation to be in with security products, but I could also hilight weaknesses in various AV software as well. Likewise its too easy to say its working as programmed because technically every bug is working as programmed ergo bugs wouldnt exist by the working by design definition would they?
I posted an example earlier this morning where scheduled rules kicking in dont stop existing states from rules no longer in effect.
-
Just to add: BEFORE 2.2 (i.e. 2.1.5) flushing the states with pfctl -k IP worked in both directions. I get an email with the states after the scheduled block rule kicks in and the cron job kills the states. Prior to 2.2 the email showed no states at all, after installing 2.2 (fresh nano 386 copy + config file) always the states specified above persisted. Therefore I had to switch the cron job for killing states from pfctl -k to pfctl -F states.
-
… why does deleting outward bound states not work, but deleting inbound states does work?
By default pfSense allows all outgoing traffic from firewall host itself (try 'pfctl -sr | grep itself'). So when you delete states firewall rules come into play and those deleted outward bound states are recreated again.
So I tried the command pfctl -k network ie pfctl - k 1923.168.1.0/24 and sure enough it does kill the states on the lan side, however as the dangling state is an inward bound wan side state pfctl -k would need to kill the opposite side state in this case the wan side inward bound state.
There is no need to kill the opposite side states . Even if inbound traffic from the WAN side can reach a host in the LAN the host can't reply.
-
@chemlud
It appears by the change of wording a change in behaviour has probably occurred.pfsense 2.1 FreeBSD 8.3 Release
https://www.freebsd.org/cgi/man.cgi?query=pfctl&apropos=0&sektion=8&manpath=FreeBSD+8.3-RELEASE&arch=default&format=html
"Kill all of the state entries originating from the specified host or network. "pfsense 2.2 FreeBSD 10.1 Release
https://www.freebsd.org/cgi/man.cgi?query=pfctl(8)&sektion=
"Kill all of the state entries matching the specified host,network, label, or id."I could interpret 8.3 as including the wan side inbound states as the lan side outbound states would have originated the wan side states.
This could explain the change in behaviour you have observed.
… why does deleting outward bound states not work, but deleting inbound states does work?
By default pfSense allows all outgoing traffic from firewall host itself (try 'pfctl -sr | grep itself'). So when you delete states firewall rules come into play and those deleted outward bound states are recreated again.
I'm working on OPTx interfaces I only use lan to access pfsense everything else is blocked by a rule and I lock everything down so even things like netbios & dns needs an allow rule for each device before it can get out, and things like windows updates are allowed out on a schedule, but yes by default like virtually all fw's in their default settings, allow unrestricted access out from the lan to internet which imo is dangerous,hence why I lock things down.
So I tried the command pfctl -k network ie pfctl - k 1923.168.1.0/24 and sure enough it does kill the states on the lan side, however as the dangling state is an inward bound wan side state pfctl -k would need to kill the opposite side state in this case the wan side inward bound state.
There is no need to kill the opposite side states . Even if inbound traffic from the WAN side can reach a host in the LAN the host can't reply.
The Host can reply because the lan side state are recreated automatically by PF.
Have you tried the pinger test and youtube test on say a scheduled block although it will work with any non-allow ie a disabled, reject or block rule change, provided a wan side inbound state exists when any Allow rule was in effect?
Put it like this, if you did the test, how does the pinger continue to send out pings and how come you can pause and resume the youtube film if the host cant reply when the lan side states have been deleted but not the wan side states? Only when the wan side states have been removed which wont occur if all ready established before a scheduled block rule comes into force, or a blocking rule has been added/changed to/enabled and Apply Changes button clicked?
Nice pic. ;D
-
Working by design but I would say a flawed design when considering the issue of dangling states. Where I differ perhaps to others is I consider a bug anything thats not working as the user expects, so I could say the Apply Changes button when making a rule change is a bug as it misleads the user into thinking the new rules are ineffect when they may not be. Thats a dangerous situation to be in with security products, but I could also hilight weaknesses in various AV software as well. Likewise its too easy to say its working as programmed because technically every bug is working as programmed ergo bugs wouldnt exist by the working by design definition would they?
I posted an example earlier this morning where scheduled rules kicking in dont stop existing states from rules no longer in effect.
As designed does not mean as programmed. It's working within spec, as intended, not as written. If you design a wheel to pop off when 100lbs of force is applied and only ever expect 50lbs of force to be applied from normal driving conditions, then someone has a driving condition that causes the wheel to pop off because 100lbs of force so happens to get applied, it's working as intended. The wheel was meant to easily come off under very certain circumstances and those criteria where met.
I do agree that it should properly support killing all existing rules that match a block rule, or possibly any rule for that matter, but my main point is by default all traffic is blocked. If traffic is getting through in the first place, it's because you passed it. Don't pass it, no problem. I've changed my pass rules once in 2 years, not like one needs to worry about getting their blocking rules to work ASAP, unless you're doing something strange, like changing your rules all the time.
-
Here is a link to the pfctl Man Page:
https://www.freebsd.org/cgi/man.cgi?query=pfctl%288%29&sektion=
Specifically, about killing states. So its important to use the correct arguments to kill the states in question whether they be Inbound or Outbound States.
-k host | network | label | id
Kill all of the state entries matching the specified host,
network, label, or id.For example, to kill all of the state entries originating from
``host'':# pfctl -k host
A second -k host or -k network option may be specified, which
will kill all the state entries from the first host/network to
the second. To kill all of the state entries fromhost1'' tohost2'':# pfctl -k host1 -k host2
To kill all states originating from 192.168.1.0/24 to
172.16.0.0/16:# pfctl -k 192.168.1.0/24 -k 172.16.0.0/16
A network prefix length of 0 can be used as a wildcard. To kill
all states with the target ``host2'':# pfctl -k 0.0.0.0/0 -k host2
-
So a rewrite of the GUI would result in this working?
-
It all works as it should, or at best reasonably can (without massively over-killing states, or seriously enhancing pfctl's ability to selectively kill states).
Pass rules that are out of schedule have states deleted for connections that rule passed. Block rules with schedule are added to the ruleset during the schedule. No states are killed because it's impossible to do so reliably without over-killing states.
If you have a scenario where you can use pfctl -k to kill as desired, cron it at the time(s) your block schedule rule kicks in.
-
Another shitty thread waiting for a press of LOCK button.
Yes. Very, very close. My patience for "OMG bugs!!!" shit storms resulting from a fundamental lack of understanding of the basics of the topic has run very thin.
-
:D Its just because we are questioning basic design in pfsense.
You could kill the states attached to that specific rule when changed from pass -> block.
Its better than nothing happening and we have to run cron jobs on the side to make sure its actually happening.
In the future the reasoning could also be applied to, say a DDoS hitting a port. If it hits a customizable limit of states, it closes and kills all states belonging to that rule.
Buit this is the standard response from ESF. Everytime…
Since we are so stupid, we lack fundamnetal understanding of whats going on. Bugs are not bugs....its just stupidity. We are so stupid that questioning a way of handling things ends up in bickering. Again.
What the users want when changing the rules to BLOCK is NOT happening. Then dont look for an excuse to why its NOT happening.
MAKE IT HAPPEN! HELP US GET THERE! WORK WITH YOUR COMMUNITY!! INstead of calling us idiots and morons....
-
@cmb:
It all works as it should, or at best reasonably can (without massively over-killing states, or seriously enhancing pfctl's ability to selectively kill states).
Pass rules that are out of schedule have states deleted for connections that rule passed. Block rules with schedule are added to the ruleset during the schedule. No states are killed because it's impossible to do so reliably without over-killing states.
If you have a scenario where you can use pfctl -k to kill as desired, cron it at the time(s) your block schedule rule kicks in.
Its not impossible to kill the states reliably, it involves more work either on PF/pfctl's part or pfsenses part but I would be interested in why you say its not reliable.
Pass rules that are out of schedule have states deleted for connections that rule passed.
Only when the existing wan side state is killed off but not if the lan side states are killed off as seen in the ping & youtube tests of which the timeout is controlled by System:Advanced:Firewall & Nat, Firewall Optimization Options drop down set to Aggressive for a short time out.
New attempts will be blocked.
I'm going to create another internet connection through an OPTx interface as its own independent internet access with a gw and see if PF treats the return state ie wan side states in the ping/youtibe tests, the same way because for the same reason its important to log out of websites when finished instead of just closing the browser (ie its possible in a compromised network environment to come in on the coattails and continue sessions) so the same applies with states that pass through to devices behind firewalls.
A comprised network environment could be freeloading off someone elses wifi, a college campus internet access, wifi with or without isolation in a fast food place or even the internet access provided in a foreign country.
At the moment it seems that PF will only kill the existing state after rules have been loaded up if the wan side/return leg of the states is removed. The issue of split second windows of opportunity between rules being engaged or disengaged is separate.
-
Pass rules that are out of schedule have states deleted for connections that rule passed.
I did not know this. No wonder my kid is so adamant I add time before the schedule fires. boom
I have an ASA on the bench at work. I'm curious if it kills existing states just because you change a rule. I'm guessing not.
If I have a pass rule that passes, say, source 192.168.1.0/24 to an ssh server. Then I change the rule to pass 192.168.1.0/25 and Apply Changes. Should the firewall kill all states for source addresses 192.168.1.128-255 but not sources 192.168.1.0-127? Are YOU going to write that code?
Much easier, if it's SO IMPORTANT to the network admin that the states be cleared, he can just go in and clear them. He's already in the firewall making changes for a reason anyway.
Or, maybe, the advice can be propagated that after every rule change the firewall is rebooted. That'll do it too. The users we're talking about expect it anyway.
-
:D
Do that in a company or other production scenario :D
And yes it should kill states for a /25 subnet compared to a /24. Otherwise what would be the point?
