Delete state, Reject & Block rules work perfectly fine
-
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?
-
@cmb:
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.
Yeah, typical shoot the messenger…
-
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?
What do you see with these two matching states?
SERVER tcp 208.123.73.68:443 <- 192.168.50.51:53197 FIN_WAIT_2:FIN_WAIT_2 WAN tcp 92.29.120.48:65224 (192.168.50.51:53197) -> 208.123.73.68:443 FIN_WAIT_2:FIN_WAIT_2If you can work out the rule that matches the state, you can log the state for deletion, apply the new rules, then delete the logged states if they still exist.
Question is who should do this, PF/pfctl or pfsense?
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.
Not everyone has a network admin logged in 24/7 besides if they did why do schedules exist? Using your reasoning there would be no need for schedules to exist as the network admin can do it.
As to the importance its 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, hotel or even the internet access provided in a foreign country.
Admittedly its harder with ssl but if you can obtain the certs then its not impossible, its just another step in the hacking process which is why various certificate providers have been hacked for their certs. If it wasnt possible certificate companies would not get hacked.
-
@cmb:
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.
Yeah, typical shoot the messenger…
He doesn't like getting DDOS'd by the same questions. There's a lot to learn for advanced topics for PFSense, but it should be a priority to learn how the basics work. But the laws of large numbers are against him. Someone somewhere will ask the same question. I've done my fair share.
-
And there's a little clique of script kiddies running around these days with more to complain about than solutions to offer.
-
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.
It doesn't.
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?
That's just one example of many. It's impossible to do in a bug-free way. It's a hell of a lot of work to do in a way that would ultimately be buggy for a range of edge cases.
:D Its just because we are questioning basic design in pfsense.
s/pfsense/basically every firewall in the world/
Feature suggestions are always welcome. This wouldn't be an unreasonable feature request. But acting like it's the end of the world and everything is shit because things work the way basically every firewall works isn't going to get you far.
-
For what it's worth, Checkpoint firewalls have an option when creating a rule that allows you to set whether or not existing states are cleared when that rule is loaded. If you check "yes", then any time the firewall rules are updated (called "pushing policy" in Checkpoint speak) you have selective control over states that are cleared for rules. I don't know how Checkpoint does this internally in code, but I do remember the option being in the SmartConsole GUI application you use to manage rules on Checkpoint firewalls. It's been about two years since I last managed a Checkpoint device, but I think they called the option "keep existing connections" or something similar to that.
Obviously for a feature like that to work, the rule would have to be evaluated against all current states and a determination made of whether the new rule applies to a given state or not, then you check the option to see if that state should be killed.
Bill
-
The way ISA handled it was you have to restart the service, just like killing all states achieves in pfsense, but you couldnt do schedules in ISA and I dont know about the latest ones either as I've not looked at those.
Today I've been testing pfsense 2.1/freebsd 8 and pfsense2.2/freebsd 10, its more difficult testing with FF on windows because even when you dont use Google as the search provider in the FF toolbar, your web activity is still sent back to Google and the cloud servers they hire like from Amazon, which then further "compliments" their search business a trick MS seems to have missed but the way FF & Google works makes it harder to keep track of the states as its opens up so many to do a distributed download from youtube amongst other things. I'll be hooking into FF & Windows at some point to examine the memory and thus just what exactly is being sent back to Google as we have a concept called privacy over here in Europe.
So I will have to repeat the tests again with some other webbrowsers tomorrow but there is at least one minor change in behaviour in PF/pfctl between freebsd 8 & 10, but until I can come up with a test which can be repeated by others with more detailed steps its hard to prove the states killing isnt working properly using Windows or Linux with the technology most people have access to.
@cmb:
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?
That's just one example of many. It's impossible to do in a bug-free way. It's a hell of a lot of work to do in a way that would ultimately be buggy for a range of edge cases.
Nothing ventured nothing gained, but a problem shared is a problem halved, I'm sure there's plenty of people who would like to chip in with their views as to what would be ideal or the best way to handle the different situations to kill off states.
Even taking votes and having a discussion on what should happen and why is at least a democratic way to resolve & expedite some of the thought processes that will be involved in deciding how to handle some situations, which leaves the job of coding it an easier one as no one person can come up with all the ideas.
Can the forum do votes?
:D Its just because we are questioning basic design in pfsense.
s/pfsense/basically every firewall in the world/
Feature suggestions are always welcome. This wouldn't be an unreasonable feature request. But acting like it's the end of the world and everything is shit because things work the way basically every firewall works isn't going to get you far.
When its your business that keeps getting hacked, anyone who runs their own business knows its their baby and thus it can be for some the end of the world when you baby goes bust for reasons that are in other peoples or industry's hands.
Whether the industry is right or wrong about allowing or even accepting dangling states and dangling sockets in Linux is a debate for another day, but finding a solution to dangling states will certainly elevate ESF above the rest if the problem is to be tackled and users want it to be tackled.
