Block/reject rules are not working anymore…(would better say "as expected")
-
Please refer to the previous threads about this subject. Anytime someone brings this up it turns into one big honken flame fest and we are not going there again.
More than enough has been communicated in our prior threads on why the decisions have been made they way they are now.
Yer flippin' god, Scott, don't take it too hard :)
I'm searching the forum and ml archives, but without success on explanation why exactly is the way as it is… any usefull hints for me, where to search/read?
I read the Voami's point of view and must say, that I must agree with him...
http://forum.pfsense.org/index.php/topic,1434.0.htmlJust protecting stupid (newbie) users from themself?
Keep up with good work, mate :)
/jan
-
You can find the lovefest in this thread:
http://www.mail-archive.com/support@pfsense.com/msg05808.html
I should warn you, it gets ugly.
-
You can find the lovefest in this thread:
http://www.mail-archive.com/support@pfsense.com/msg05808.html
I should warn you, it gets ugly.
Hmm… read through, strongly agree with per-interface rulebases style and approach.
What is missing is just a little pull-down menu in rule creation page, allowing you to select the direction of the rule - in/out/both. That would solve lots of trouble in bigger network security design and rules creation and administration.
Currently I have 10 VLAN's (...and growing) and I'm starting to fall in total mess with "in-only" rules...
Anyway, how was hackatron? Exhausting?
/jan
-
We'll have a blog post about the hackathon shortly. I enjoyed it very much.
-
FYI only…
Just today I started to tighten the security policy design and after I wrote all wishes on the piece of paper, things looked promising, but when I converted ideas to in-only rules, I figured out, that this is turning into nightmare, a very long and huge nightmare...
Where can I write by hand out-rules and add them to valid policy without changes being overwritten on reboot?
I studied /tmp/rules.debug and it was tempting not to edit it properly, but I'm afraid that that file is for debug only and not input for valid policy...
So, where?
Thnx, /jan
-
rules.debug is what gets created by the webgui and gets frequently overwritten and reloaded. Changes you make there will be lost sooner or later. There is no good way for what you want to do.
-
rules.debug is what gets created by the webgui and gets frequently overwritten and reloaded. Changes you make there will be lost sooner or later. There is no good way for what you want to do.
I thought so…
Can somebody explain to me, which .php files creates which rule files, that are fed to pf as valid ruleset? Any usefull info would be appreciated.
Maybe I'll go and bugger our php developer on monday, that he changes pfsense web gui for me and add in/out rules functionality...
/jan
-
Check out /etc/inc/filter.inc
-
Check out /etc/inc/filter.inc
I should start thinking about changing lines 1145 and 1146, for a start, right?
1145 /* ensure the direction is in */
1146 $line .= " in ";Will have a look. My idea is to add a small and quite invisible button "Advanced rules config" in Rules page, that should allow you to do more advanced stuff.
/jan
-
Its far more than that. Every portion of filter.inc is designed for incoming assumptions.
This is quite a large project.
-
Its far more than that. Every portion of filter.inc is designed for incoming assumptions.
This is quite a large project.
I thought about adding a field <direction>(with value "in" or "out") to xml inside the part, just below <type>definition. Based on that, filter.inc should decide, whether this is "in" or "out" and write apropriate word into /tmp/rules.debug, instead of "in" every time. If <direction>directive is not present, assumption can be made, that this is "in" filter.
I dont need to change any other portion of filter creation, just User-defined part.
Any thougts or ideas?
It's always good to have spare host with pfsense installed, that nobody uses and cares about :)
/jan</direction></type></direction>
-
I got my fellow php developer Rudi online and we fixed firewall_rule_edit behaviour…
Scott, you got 2 files changed in your mailbox :)
/jan
-
I have no comment. You need to get Bill and Chris Buechler to sign off before I can commit such of a major design change.
-
I have no comment. You need to get Bill and Chris Buechler to sign off before I can commit such of a major design change.
True. I will test this changes for few days and will report the success/failure ;D
I wouldn't say it's a design change… default setting is "in" anyway :) Just another option added in user defined rules space :)
For pfctl it's all the same, in or out, it just works like you tell him to :)
/jan
-
I have no comment. You need to get Bill and Chris Buechler to sign off before I can commit such of a major design change.
True. I will test this changes for few days and will report the success/failure ;D
I wouldn't say it's a design change… default setting is "in" anyway :) Just another option added in user defined rules space :)
For pfctl it's all the same, in or out, it just works like you tell him to :)
/jan
I admit, I haven't read this thread, but why would I want to create two rules for one again?
–Bill
-
I admit, I haven't read this thread, but why would I want to create two rules for one again?
–Bill
Why would you like to do that? Absolutely no need for that…
All rules are created like before (incoming) by default (pre-selected in pull-down menu).
If you change pull-down menu to "Out" in rule creation, you can block all trafic to one host with rule in one place (interface) and not with N-1 rules (N=number of interfaces).
Look, this is not idealistic, philosophic or bohemic suggestion/solution, this one comes from real world. I manage a network with 10 VLANs (lots of hosts) and as I posted before, tightening of security design looked promising on paper while drawing circles, lines and red crosses, but when I started to convert this design to in-only rules, it turned out to a massive nightmare.
Please read back this thread, maybe it will give you some ideas, why medium to large network configs can't live without out-rules, and even sacrifying the idea of "never letting the unwanted packet into firewall" seems reasonable for the sake of manageability and better control over rules and packets.
Scott, on monday we will add some cosmetic changes to the other php files, like showing "direction" with small arrow on firewall_rules page or something and then provide you with diff patches.
Thanx for the audience and all the patience ;D
/jan
-
Scott, I believe you got all the patches, including last version of filter.inc.patch, right?
I'm now testing this on our production firewalls under heavy traffic and everything seems to work fine. I applied my security tightening design idea, but before that I converted some "in" rules to "out" rules on right interfaces and reduced the ruleset list nearly by 70% 8)
Some snapshots of changed interfaces (from my test box, just not to make my security policy public :) )
http://haktar.select-tech.si/pfsense/rules_edit.jpg
http://haktar.select-tech.si/pfsense/rules.jpgAny info, what's the status of this patches? I'm now extremly happy with my patched boxes, but I believe, that this is the end of upgrades for me for some time, right?
/jan
-
As I have told you before it is not up to me.
I would get busy emailing Bill and Chris asking what their opinions of this are.
-
I'm now extremly happy with my patched boxes
Oh nice, this will save so much hassle. Is it available for embedded versions yet? -
I suggest supplying inofficial unsupported patches for this atm. Everybody who's using it can report back here. That gives us at least an overview how well this is working if we consider implementing that later.
Janz, can you do that?