Delete state, Reject & Block rules work perfectly fine
-
Confirmed in 2.1.5 as well.
-
Wonder if this could be spread to other basic functions of pfsense??
Handling packets, blocking and response?
-
I'm about to test a long free film from youtube and let it run all the way this time as the first test I did using youtube stopped the rules from reloading as it didnt stop the youtube, however the youtube file does have a buffer of a few minutes worths I need to leave this running for a longer time to be sure as I could still see data coming in from the wan, but the fw log only shows the rule match once for a session.
A simple webpage is no enough data and so a socket session (windows speak if its different in Linux) is what I suspect is stopping the rules from working properly. A film will keep a long socket session open, an online newspaper wont be enough data to keep the socket open for long and javascript can open new sockets as can Ajax, plus the browser is essentially stateless anyway unlike Pinger which will run a session until its stopped, so webpages are harder to test, but so far I have seen https from youtube delay the loading of rules for a few minutes.
-
Well changing the rules to block, reject, allow and alot of other settings like restricting source and destination with an accompanying click of the Apply Changes button did nothing for the 2hrs 20mins the youtube film ran for.
With regard to states, deleting the outward bound state did nothing either for all the various rule changes I had tried.
The only time deleting a state stopped the film from playing was when I deleted the inward bound state and then the rules work as expected, but lets face it who goes through their state table and deletes the relevant state?
So thats the low down so far.
Its been confirmed in 2.1, I wonder if this problem goes back further than 2.1 and I also wonder if its something exclusive to pfsense or something in FreeBSD which will affect other firewalls also using FreeBSD as its OS, and/or is it related to a package being used by pfsense which ports to other Linux OS's.
Potentially there could be an awful lot of firewalls from various suppliers & not just pfsense affected by this for this simple reason:
Killing the outward bound state doesnt let the rules work as expected. With this in mind, any malware on an internal system could initiate a state which is kept open, perhaps even the Keep Alive in http(s) might do the trick ( I havent tested yet)?
One obvious way is by monitoring some API's in the OS, could be enough for any malware/botnet/whatever-you-want-to-call-it on a system behind the firewall to initiate a state kept open before downloading new instructions/payload in which to evade further capture from AV & AntiMalware software and/or carry out any other nefarious operation, but do bear in mind it can take weeks/months/years before some unknown communicating software is reverse engineered and considered good or bad, just look at how long it took AV companies to find Stuxnet and Flame for some examples.
Anyway workaround is to reset the entire state table after applying any rules changes just to increase your piece of mind.
Off to test some other firewalls and versions now to see how big this bug is.
-
Confirmed issue in OPNSense latest version as well.
-
2.2.2 AMD 64 (Latest release version)
Set up a pinger to ping something continuously, in my case I was using the wan IP address assigned by the ISP to my bridged modem.
Initially the default block rule is in effect and will block the pinger.
#1
Add rule:
Action: pass
TCP/IP Version IPv4
Protocol Any (havent tried anything more restrictive}
Source Any
Destination WAN net
Log: TickedSave rule & click Apply Changes button.
Pinger starts getting TTL's back and logs show ping is passing through in the fw logs
Now repeat #1 but change the rule from pass to block, save and click Apply Changes Button.
Pinger still getting TTL's back and still shows ping passing through in the fw logs.What was running a "pinger"? Which interface was it connecting through? Which interface is the rule added to?
I assume the rules on your LAN interface and pinging from a network device and attempting to ping your WAN IP.
So the issue seems to be adding a block rule for ICMP then manually clearing the individual states doesn't seem to stop the ping from still getting through?
I wonder if it has to do with how ICMP "states" are being handled. ICMP is stateless protocol with no ports. The network stack may be misrepresenting what a state really is for ICMP just to keep the format the same.
Try setting your ping to only ping once every 10 seconds, giving you enough time to delete all of the related states. It could be that as long as ANY ICMP state for the target rule exists, the firewall can't tell the difference. The default ping rate of once per seconds may not be enough time to let you delete all relevant states.
Summary is my guess is this is something specific to ICMP and as long as any related ICMP state still exists, it'll continue to let "new States" to be created.
-
Even if you delete the rule, it keeps responding to ICMP.
-
Is ICMP handled in the networking stack before handing packets off to PF or anything that has hooks in?
-
Its a network layer protocol so IMHO it should be.
-
Everyone knows deleting/changing rules doesn't kill existing states. Not a bug.
-
@mer:
Is ICMP handled in the networking stack before handing packets off to PF or anything that has hooks in?
ICMP can be blocked, so it has to go through PF.
Even if you delete the rule, it keeps responding to ICMP.
This is a guess, but this is what I was getting after.
With TCP or UDP, it's not an issue because all states are a combination of IP and port and destroying a state actually destroys the flow. ICMP may internally map multiple flows through the same state and make it look like there are multiple states when there is really only one. You might be destroying pseudo-states, but not actually destroying the underlying state, which means new flows can be created. Resetting the state table forces all states to be destroyed, so it's not an issue.
My guess is if you do a "ping -t 8.8.8.8", then create a rule to block pings to 8.8.0.0/16, then attempt to ping 8.8.4.4, you won't be able to ping 8.8.4.4, but will be able to continue pinging 8.8.8.8 because a state already exists. But making "new" pings to 8.8.8.8 will work because of the magic happening that makes ICMP look like it actually has ports.
PF represents ICMP states in a strange way that looks like they have ports. My guess is it has something to do with how ICMP does not have a real layer4 and ICMP states are misrepresented to make you think you're destroying the underlying state.
LAN icmp 8.8.8.8:11309 <- 192.168.1.2:11309 0:0
LAN icmp 8.8.8.8:1 <- 192.168.1.2:1 0:0Since ping defaults to every one second, if you destroy one of those states, but not both, with in one second, a new ping will go out and create a new pseudo state. Try setting ping to every 10 seconds, giving you enough time to destroy all of the ICMP states before another ping goes out.
I'd test it out myself, but I once made changes to the firewall that I forgot to apply, and a long while later created some other rules, applied them and broke the Internet for a few moments. Wife was furious because she was in the middle of something. Well, she's been in the middle of something non-stop, so I can't risk testing myself.
-
But wouldnt it be great if the script actually took all states with either DST or SRC and killed every last one of them when you pressed apply when you change the rule?
I think thats what we actually want to happen when doing so.
Everyone knows deleting/changing rules doesn't kill existing states. Not a bug.
-
It doesn't do that. That would be a new feature request, not a bug.
-
i don't think i would want it to kill related states when creating a new rule …. this "feature' has saved me a couple of times when i did something stupid. (not locking myself out when i made a typo)
anyhow, i prefer to clear the states myself
-
Summary is my guess is this is something specific to ICMP and as long as any related ICMP state still exists, it'll continue to let "new States" to be created.
Its not just ICMP, HTTPS which I have tested with the long youtube film that ran for over 2hrs 20mins despite various rules was also affected. As its WAN states that need to be deleted the recent change to unbound/ DNS resolver ie the change to the DNS service also means lots of WAN states kept open which means lots of firewall rules wont be updated. I've got over 2000 wan states open to various name servers since I started this thread all of a sudden and my CPU load has gone up to just under 50% load which will further prevent any rule changes from working properly unless I reset all states.
Everyone knows deleting/changing rules doesn't kill existing states. Not a bug.
I didnt and I dont see any mention of deleting states in numerous online blogs detailing how to do XYZ, nor is it in the pfsense book and I dont see it mentioned often in the forums either. So whether "everyone" knows is a matter of opinion.
With ISA server we used to just restart the service which had the same effect of deleting the states, but if anything the Apply Changes button in the pfsense gui is a little misleading imo.
I will say that in the Reset States webpage in the gui, there is some text which says it may be neccessary to reset the states so if anything that text could also be reiterated on the rules webpage for safety sake although not my preferred option which is below.
i don't think i would want it to kill related states when creating a new rule …. this "feature' has saved me a couple of times when i did something stupid. (not locking myself out when i made a typo)
anyhow, i prefer to clear the states myself
A new rule perhaps, but if you change an existing rule or even simply disable/enable an existing rule what then? Jump through some more hoops just to get the change to work, not everyone gets to charge by the hour.
And what if you have hundreds or thousands of states to delete one by one, it could be a never ending process because as you delete one state another could pop up from another device when a network and various devices have all been compromised with malware, ergo you never get to delete ALL the states so the new rules can never take effect.
So this leads you to one course of action, resetting all states in one go, which then renders the argument for a new rule perhaps mute point.
I've done similar but with multiple windows programs that check for the existence of each other, if one is not running, one of the running apps fires it up, if its been deleted it restores it, so not only can you not stop the various apps from running you cant even delete them, a similar technique is used with malware & viruses which you may or may not have had the pleasure of trying to fix for customers.
Besides there is also the point of inconsistent behaviour, why does deleting outward bound states not work, but deleting inbound states does work?
Inconsistent behaviour and misleading wording is the undoing of any good system.
But wouldnt it be great if the script actually took all states with either DST or SRC and killed every last one of them when you pressed apply when you change the rule?
I think thats what we actually want to happen when doing so.
It doesn't do that. That would be a new feature request, not a bug.
How about this for a feature request. Two or three buttons that pop up when a rule change has occurred which can be:
1. Apply Changes - No State changes
2. Apply Changes - reset only affected states
3. Apply Changes - reset all states.I would suggest it would be easiest and quickest to do buttons 1 & 3 for now because the code already exists in the existing Apply Changes button and the same for Reset Button in Diagnostics:Show States, Reset States tab so I doubt it would be too time consuming or difficult to merge the code together.
At least this way the gui becomes a reminder for breaking old habits and improves the experience for novice users who want to use pfsense in anger. I know CLI's have their fans, but Apple havent got to where they are to day by ignoring the gui experience.
I still havent got to the bottom of where this problem stems from though, as its been confirmed in OPNsense we still dont know if this is restricted to freebsd or a package used by freebsd which means other firewalls in other OS which use the package have this "backdoor" weakness, but might explain why the NSA were recommending opensource firewalls a while back if they have had their grubby mits over some code in advance.
Edit.
One other thought, is if the rules are only reset when the inward bound wan state is deleted, what if you are using an OPTx for an additional internet connection?
Do deleting the states not work for those interfaces as this appears to be the case currently when deleting outward bound states on OPTx interfaces. This could potentially be a bigger headache still unless all states are reset after every rule change. -
Summary is my guess is this is something specific to ICMP and as long as any related ICMP state still exists, it'll continue to let "new States" to be created.
Its not just ICMP, HTTPS which I have tested with the long youtube film that ran for over 2hrs 20mins despite various rules was also affected. As its WAN states that need to be deleted the recent change to unbound/ DNS resolver ie the change to the DNS service also means lots of WAN states kept open which means lots of firewall rules wont be updated. I've got over 2000 wan states open to various name servers since I started this thread all of a sudden and my CPU load has gone up to just under 50% load which will further prevent any rule changes from working properly unless I reset all states.
The original discussion was about how the block rule was not taking effect and allowing new ICMP states. Now that the discussion is changing into "how to kill existing states for a block rule", the topic has changed.
I think they already have a script for this and use it for scheduled rules. Maybe we just need a "kill all states" button under the edit window screen, allowing you to kill existing states for the current rule.
-
Its simple. When changing one specific rule, all states for that rule should be killed. On all interfaces.
Only way the integrity of the firewall is kept.
-
I didnt and I dont see any mention of deleting states in numerous online blogs detailing how to do XYZ, nor is it in the pfsense book and I dont see it mentioned often in the forums either. So whether "everyone" knows is a matter of opinion.
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting#Dangling_States
"Did you clear your states?" is asked like 5000 times a week here.
-
Thats really nice if you run a production scenario and altering 1 rule blows the connection to the rest….
Including one self in a remote datacenter....! :-[
-
Exactly why states should not be automatically cleared.
-
I still havent got to the bottom of where this problem stems from though
what problem?
-
They should….for that specific rule and not the entire state tale ;)
Exactly why states should not be automatically cleared.
-
Submit a feature request. It's not a bug.
-
I didnt and I dont see any mention of deleting states in numerous online blogs detailing how to do XYZ, nor is it in the pfsense book and I dont see it mentioned often in the forums either. So whether "everyone" knows is a matter of opinion.
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting#Dangling_States
"Did you clear your states?" is asked like 5000 times a week here.
That appears to be the only reference, besides do you know how many references there are to the phrase "Dangling State" in the forums?
Answer is here. http://bfy.tw/6mC
The quick answer is 0 (thats zero) reference to Dangling States in the forums and its certainly not mentioned in many many online how to's in websites & blogs. Thats alot of pfsense firewalls and others out there which can easily be compromised when combined with other methods to gain control of systems & networks.
Its also interesting there is only one link to this page which is here,
https://doc.pfsense.org/index.php/Special:WhatLinksHere/Firewall_Rule_TroubleshootingQuite why you feel the need to exaggerate the fact its refered to 5000 times, I can only go and consult the handbook here: http://pastebin.com/irj4Fyd5
It seems to me the significance of a Dangling State is not recognised or being played down.
The first mention of it captured by the Wayback Machine was on Sun May 17 2009
http://web.archive.org/web/20090501000000*/https://doc.pfsense.org/index.php/Firewall_Rule_TroubleshootingIt seems this problem exists in all versions of pfsense going back to 1.x which explains alot regarding how many times I have been hacked since I started using pfsense 1.2
I think they already have a script for this and use it for scheduled rules. Maybe we just need a "kill all states" button under the edit window screen, allowing you to kill existing states for the current rule.
Heres a test scenario you can do where the scheduled rules dont work which is probably best explained now as a "dangling state" as mentioned by Derelict, but is where the Inward bound wan states are not killed off.
Create your normal rules, in my example I have a Pass everything out rule.
FIrewall:Schedules webpage, Create a schedule that will take place in the future. For now I used 1st June (today), and set the time window for 15mins so if the time was 7am, the schedule would be 07:15 to 07:30.
Firewall:Rules web page select the right interface if you have more than Wan & Lan, and just above your Pass everything out rule create a new rule which Blocks everything out, scroll to the bottom of the edit rule webpage & click the Schedule button and select your time schedule from the drop down.
Save and apply changes.Now go watch a long free youtube video that will run for a few hours.
By now it should be getting closer to 07:15 the time at which the Block Everything rule will kick in.Find out what the ip address is from the interface with the Pass Everything and find out what IP address the youtube stream is coming from, once you have that go to the Diagnostic:States window and look up the youtube IP address, you should see two entries for both directions and they should both say Established : Established, if you have the traffic graphs for the interfaces on your dashboard you should also see the youtube traffic coming In on the Wan and Out on the interface where the device playing the youtube video is playing.
At 07:15am you will see in Firewall:Rules the Block Everything rule has become active as the icon in the Schedule column goes from a greyed out icon to a bold coloured icon indicating its gone from disabled to active. Likewise you can also visit the Firewall:Schedules webpage and see a clock icon next to the 07:15am to 07:30 time span. If you visit the Status: System Log: Firewall webpage, select Firewall tab and then Normal tab and filter on the interface by typing in Lan or whatever your interface is called before clicking the Filter button, any newly established traffic going out will be blocked by your now inforce Block Everything rule, whilst the already established youtube stream carries on unhindered.
You can verify the youtube stream is still active by continuing to watch the film or visit the Diagnostics: States webpage and look up the IP address of the youtube server streaming the film to you that you previously found and see the two states are still present, they maybe in a different location in the list but as long as they both have Established : Established in the state column then the "Dangling State" is letting the traffic through as it will for any malware or virus that is currently in your system and has established a connection with the outside world.
Exactly why states should not be automatically cleared.
Submit a feature request. It's not a bug.
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.
The fact its mentioned in the docs does not legitimise the problem, it simply acknowledges the problem exists.
The question is, can the dangling states be fixed?
However considering this goes back to pfsense 1.x I can no longer consider pfsense a firewall due to this Dangling State bug, so how many users have been duped and forked out money for something that it isnt?
-
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.
-
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."
-
They work fine. Like everywhere else, when you set a rule it doesn't affect existing states and they have to be cleared either organically or by force.
Feature request.
-
Thats cool man!
Schedule rules doesnt really work if they are actually beeing used :D
Mikrotik here I come :D
-
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.