Block/reject rules are not working anymore…(would better say "as expected")

JanZ

Hi gang…

Strange problem happening here...

block rules stopped working in some point in time between upgrading via CVS (btw, why is CVS now closed?)

Simply, even if I put block rule as first rule on the interface VLAN11 (opt9) and explicitly block for example from host 10.1.0.229 (on VLAN10 - opt8) to whole network (10.0.0.0/24) on VLAN11, I can freely ssh from 10.1.0.229 to any host in 10.0.0.0 network...

<rule><type>block</type>
<interface>opt9</interface>
<max-src-nodes><max-src-states><statetimeout><statetype>keep state</statetype>
<os><source>

<destination><any></any></destination>
<descr>block 229 host</descr></os></statetimeout></max-src-states></max-src-nodes></rule>
<rule><type>pass</type>
<interface>opt9</interface>
<max-src-nodes><max-src-states><statetimeout><statetype>keep state</statetype>
<os><source>
<any><destination><any></any></destination>
<descr>allow any in-out</descr></any></os></statetimeout></max-src-states></max-src-nodes></rule>

on VLAN10 (opt8) I allow any<->any.

Why this block rule is not working? When I ssh to host in 10.0.0.0 network and run "who" command, I see, that I'm connecting from 10.1.0.229 IP...

Any ideas?

/jan

JanZ

Ok, solved the issue… I must block traffic on "wrong" interface...

If I want to block traffic from 10.1.0.229 to VLAN11 network, I must put this rule on VLAN10 interface (outgoing) and not on VLAN11 (incoming).

That's exactly how I don't like it, because I would like to have all rules that applies to one network in one place and not spread all over interfaces rules...

This means, if I want to block access to a single host, I must write block rules on all interfaces in the system "block from this subnet to that host", instead of creating block rule on 1 interface (incoming), saying "block from any to that host".

weird...

/jan

hoba

Traffic is always blocke incoming at an interface. That has always been this way, so I don't understand then "anymore" :P
There has been a discussion about that at the ml. See the archive if you are interested but this behaviour won't change for quite some time if at all.

JanZ

@hoba:

Traffic is always blocke incoming at an interface. That has always been this way, so I don't understand then "anymore" :P
There has been a discussion about that at the ml. See the archive if you are interested but this behaviour won't change for quite some time if at all.

Sorry, I would better say "as expected" than "anymore".

Untill now we didn't have any need to explicitly block a single host…

So, you are suggesting, that if I want to block access to a single host billy1 (security policy for, let's say, billing server), situated in network subnet on interface opt10, I need to write all this:

wan -> block src any proto any dst billy1
lan -> block src any proto any dst billy1
opt1 -> block src any proto any dst billy1
opt2 -> block src any proto any dst billy1
opt3 -> block src any proto any dst billy1
opt4 -> block src any proto any dst billy1
opt5 -> block src any proto any dst billy1
opt6 -> block src any proto any dst billy1
opt7 -> block src any proto any dst billy1
opt8 -> block src any proto any dst billy1
opt9 -> block src any proto any dst billy1

instead of:
opt10 -> block src any proto any dst billy1

what is behind the decision, that only one way of traffic should be affected by the rules policy?

This is first time that I see solution like that, and, frankly speaking, I suspect, that design was done looking from perspective of this firewall being used for users accesing the outside world, more than having servers behind pfsense and protecting them from users coming from outside... Am I on the right track?

thnx, /jan

sullrich

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.

JanZ

@sullrich:

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.html

Just protecting stupid (newbie) users from themself?

Keep up with good work, mate :)

/jan

sullrich

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.

JanZ

@sullrich:

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

hoba

We'll have a blog post about the hackathon shortly. I enjoyed it very much.

JanZ

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

hoba

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.

JanZ

@hoba:

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

sullrich

Check out /etc/inc/filter.inc

JanZ

@sullrich:

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

sullrich

Its far more than that. Every portion of filter.inc is designed for incoming assumptions.

This is quite a large project.

JanZ

@sullrich:

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>

JanZ

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

sullrich

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.

JanZ

@sullrich:

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

billm

@JanZ:

@sullrich:

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