Major security flaw! : Invert Match rules not working as intended with DNSBL enabled

[keyser]

Hi.

I have stubled upon what i consider a MAJOR security flaw in PFsense:

I have been diagnosing an issue with my VLAN’s suddenly being able to access each other after I enabled DNSBL.

After reading the below thread,

Re: Invert match doesn't work

it turns out it was because I’m using an inverted Match rule to allow internet access - and by that using the default deny rule to block access between Internal VLANS.
I like the idea of a rule saying:
PASS - Source: Any-IP/Any-Port - Destination: ! RFC1918/Any-Port
As that is not an any any allow rule but only an allow access to public IP’s rule.
The extra - and beautiful - catch is, since it only allows access to public IP’s, access between my internal RFC1918 subnet interfaces do not match this allow rule and falls into the default deny instead.

This has been working fine for years, but after enabling DNSBL in PFBlockerNG and getting a VIB address for the dummy Webservice to block adds, all INVERT MATCH rules no longer works as intented as the invert part becomes an any rule instead - In my case make the rule an actual any any rule.

This is in my opinion a MAJOR MAJOR security flaw in PFsense as rules that used to work - and logically should work - has a seemingly non related feature i PFsense that disables them without notice.

While I can read and understand what derelict is saying - and hence why you should’nt use invert match rules, I still find that a VERY dubious argument since you need to FIND this exemption yourself as it makes no sense.
PFsense should either remove the INVERT MATCH option all together or make it work even if you have VIB’s on your system. It’s not good practice to have the rules option available when undescribed dependencies decides if it works as intended or not.

What is the argument to allow the invert match rules in the GUI even though they won’t work in some cases?

[johnpoz]

It is up to you to verify your rules you create are working as intended..

It is also up to you to validate your rules are still working after installing new services, like a package that creates it own rules, etc.

[Derelict]

Complete explanation of what is happening:

https://redmine.pfsense.org/issues/6799

Bottom line, don't block traffic with pass ! rules. If you want to block it, block it, then pass the rest. People will still defend the use of pass ! rules for convenience's sake. I will never use them in my firewalls. Block rules block traffic, not pass rules.

[keyser]

@johnpoz: I understand it's my task to test my rules, and I do, but you have to agree it makes VERY little sense to have a very clear GUI option for a rule setting that could - depending on an unrelated service - mean something entirely different than what it clearly states.

@Derelict: I understand that's your stance, but you have to agree that to me - and I would guess a LOT of other users - I didn't make a block rule, I made a pass rule to a subset of IP-adresses. Only thing is, because of a non related setting that subset of IP-adresses is now ANY instead.

I'm not blocking here, I'm selectively passing.

[johnpoz]

Putting a VIP from a different L3 is bad idea as well..

The ! does what it says, if you create state that causes a problem with that by creating a VIP from a different L3 on your interface, etc.. That is where the problem is, not with the ! rule itself.

Where there should be HUGE warnings in the package that does this..

[Derelict]

Except you're not.

I do understand where you're coming from, which is why 6799 was created.

But I had this stance BEFORE this came to light. This issue simply proved my point.

If you want to block traffic, block it.

[Derelict]

The pfBlockerNG VIP should be on localhost. Doesn't change the fact that blocking traffic with pass rules is a BAD IDEA

reject destination RFC1918
pass destination any

Is that so hard?

[johnpoz]

I do agree with Derelict point about creating specific block rules... The ! rule allowing access is a convenience, but you have to be sure to validate its doing what you think its doing.

[keyser]

Well. we could argue semantics all day on whether I'm blocking or passing with a pass rule to a subset of IP's.
But I'll bet you that ANY user interface expert would clearly agree with me that when I create a PASS rule to a subset of IP's, I should expect the firewall to handle it as a PASS rule - and not a "hidden Block everything else" rule :-)

I probably can't convince you on this, but my stance and point remains :-)

On another note I completely agree that PFblockerNG's design to add a second Layer 3 address on an existing Layer 2 Interface is VERY VERY poor design and that It should listen on Loopback instead. But that is currently not an option - I will start a new thread with @BBcan177 on this issue :-)
But please note the same problem seems to exist if I manually add a VIB address to an interface. So I would clearly argue it's a design flaw in how ! rules are interpreted by the rule engine.

I will obviously change my firewall rules now, and thanks for the discussion. I hope this will open other users eyes for this problem, and perhaps have you guys push for correcting how this is handled in PFsense.

You guys are doing a GREAT job, and thank you very much for what I consider the best freely available product of all time :-)

Happy new year!

[Derelict]

It would require a change upstream in pf. Proper firewall rule design should be adhered to.

I probably can't convince you on this, but my stance and point remains :-)

Right, which is why I created 6799.