Simplied method of preventing inter-VLAN communication

[Stewart]

@jarhead The difference I see is that those are things we add in ourselves via the interfaces tab whereas these rules always exist and are automatically created by the system, but that's essentially what I'm suggesting. Just have them show up but limit what we can do with them. If they want to keep them hidden then tuck them behind an advanced button or maybe an expandable section at the bottom of the page.

[johnpoz]

@stewart said in Simplied method of preventing inter-VLAN communication:

could there be an exploit in the future that modifies or adds hidden rules and we wouldn't ever know since they don't show in the rule list.

While that is not out of the realm possibilities I guess.. if your pfsense was compromised in such a way that they were altering hidden rules.. What stops them from just not showing the rules they create in the first place, even if gui was set to show them ;)

My take, and this is just from a user point of view, and long time one at that is they hide the rules that just keep users from shooting themselves in the foot. Like the dhcp ones, there are some other hidden rules to make sure stuff works in the background - again keeping users from shooting themselves in the foot is my take.

While I agree I would like to see a button or something I could push to show all rules.. Anyone with enough skill to want to actually view the full rules list, and understand what they mean can for sure very easy seem them if they want to with the link I provided above.

[JeGr]

@johnpoz said in Simplied method of preventing inter-VLAN communication:

While I agree I would like to see a button or something I could push to show all rules.. Anyone with enough skill to want to actually view the full rules list, and understand what they mean can for sure very easy seem them if they want to with the link I provided above.

I agree with most of John's post.

Just for the record without following the link: Just run a cat /tmp/rules.debug in either the shell, via SSH or via Diagnostics/Command Prompt to see the full scale loaded ruleset (or use less instead of cat if you're on a real shell/SSH to view it without it scrolling past you).

Most that check the content of the file will understand, that displaying the full ruleset could be very confusing to users. E.g. OPNsense has that button to show hidden rules and most comments after they included it were "do I really need those, where can I disable XY, etc. " when try introduced it, not understanding, that those are indeed necessary for normal operations. I'm absolutely pro-button to show them, but I also can 100% understand to hide them / make them invisible to stop tampering. People get extremely creative when things won't work and more times then not I've seen configs tampered with and explained by "things didn't work and the switches didn't to what I wanted so I edited the config..." - yeah, no, that didn't work out either

Cheers

[Stewart]

@johnpoz

@johnpoz said in Simplied method of preventing inter-VLAN communication:

While that is not out of the realm possibilities I guess.. if your pfsense was compromised in such a way that they were altering hidden rules.. What stops them from just not showing the rules they create in the first place, even if gui was set to show them ;)

That appears to be along the lines of "Why implement this security if it can theoretically be bypassed?" I'd argue that the additional measures are worth it even if it could be bypassed. Maybe the "Button" would just run the 'cat /tmp/rules.debug' and display it in an embedded window.

@johnpoz said in Simplied method of preventing inter-VLAN communication:

My take, and this is just from a user point of view, and long time one at that is they hide the rules that just keep users from shooting themselves in the foot. Like the dhcp ones, there are some other hidden rules to make sure stuff works in the background - again keeping users from shooting themselves in the foot is my take.

I guess my next question would be, how does this compare to other vendors? I've not seen rules like these in other products (Cisco, Sonicwall, Fortinet) that I can recall and certainly not in soho devices. Is it normal to have hidden rules like that?

@johnpoz said in Simplied method of preventing inter-VLAN communication:

Anyone with enough skill to want to actually view the full rules list, and understand what they mean can for sure very easy seem them if they want to with the link I provided above.

I didn't even think that there would be other rules so I never went out to check to see if there was a process to run to look for them. I would think a great deal many people would be in the same boat which is why I would advocate for some form of visibility on the page. Sure, once we know then we know and can check, but until this thread I had no idea there would be hidden rules so I never would have gone to check for them.

[bmeeks]

@stewart said in Simplied method of preventing inter-VLAN communication:

I guess my next question would be, how does this compare to other vendors? I've not seen rules like these in other products (Cisco, Sonicwall, Fortinet) that I can recall and certainly not in soho devices. Is it normal to have hidden rules like that?

I managed Checkpoint firewalls for several years, and they have some normally hidden rules on their managed firewalls. They are called "Implied Rules". The Implied Rules are automatically created and allow basic communications to happen between the firewall itself and the remote management server called a SmartCenter server. You can toggle them into view, but normally they are hidden. In Checkpoint land "Explicit Rules" are the ones created by the admin, and these are normally displayed. Although even those can be hidden by the admin if desired in some situations.

I suspect this is not as uncommon as you think. Take a simple SOHO router/firewall box. It for sure would need automatic DHCP rules on the WAN interface or else it could never obtain an IP from your ISP when using DHCP. Those may or may not be visible in their web GUI. Never really messed with such devices much in my career, so I don't recall what they typically display.

[Stewart]

@bmeeks I know if I purchase a Netgear or Asus it doesn't have any rules. We don't use them for commercial clients but I come across them at peoples houses.

[bmeeks]

@stewart said in Simplied method of preventing inter-VLAN communication:

@bmeeks I know if I purchase a Netgear or Asus it doesn't have any rules. We don't use them for commercial clients but I come across them at peoples houses.

It may simply not have rules that you can see. Some hidden ones may be created by default. How would DHCP on the WAN port work out of the box otherwise? Same issue pfSense would have without the automatic hidden DHCP rules.

[johnpoz]

@bmeeks such devices are maybe default allow.. But any firewall that is default deny out of the box is going to have some default rules out of the box.. Palo's have their own implicit rules, that are not shown out of the box in either the cli or the gui..

There are almost always some required rules to be allowed even a default deny firewall - or how would you even connect to it when you turn it on, etc.

Complete deny all firewall without any rules on it at all would be a pita the ass to get going out of the box, so you would have console in? Setup basic rule to be even able to get to the gui? For dhcp to work, etc.

there would be hidden rules so I never would have gone to check for them.

How did you think dhcp worked without creating of rules on say your vlan you just fired up.. How is the firewall allowed to check for updates and packages then..

The default any any rule on the lan wouldn't even allow for dhcp discover, since discover is going to come from a non lan net source, etc..

The maker is going to put in rules to make sure their product has some basic functionality out of the box, be it you understand that or thought about it is part of the point to be honest.

the comment on that other distro that I will not name having so many people bringing up questions on them, pretty much stresses the point about some rules just make more sense to hide from the typical user..

the dhcp rule is a good one for example - I can promise you many users be asking why isn't dhcp working, they would put in some rules that are either to lenient or not correct can promise you that. Look at the acls in unbound, the default acls it creates out of the box are hidden.. Most users don't have any need for anything other than the default ones, etc and don't even know that there are acls in unbound, etc.

While I agree, it would be nice to be able to see all rules in the gui - but I can also understand the problems that could bring forth.. Its not like hiding the full rules is some state secret. Anyone that looks over the documentation would find the way to view the full rules lists.

[Stewart]

@bmeeks Absolutely. What I was trying to imply was that there are no visible default rules for those. They certainly must already be there.

[Stewart]

@johnpoz To me it's the old adage "You don't know what you don't know". I've wondered in the past how DHCP works without any rules but never dove into it and just chalked it up to some sub-process of DORA. Now I'm sure there are a whole host of processes that do things behind the scenes that have exclusions I don't know about. I've just never stopped to consider it. Now that I have, it makes me wonder (and a little paranoid) that there are allow rules I don't know about. Personally I would have considered my lack of knowledge in the area if there were a "Show All" button or something like that for me to understand which rules are built in and which ones are explicitly created by me.

Over the years I've sat through many Cybersecurity courses, seminars, and videos, gone through Net+ and Sec+ (and other) training, and have touched many different vendors routers and I've never seen it brought up. I've worked with 3rd party companies who come in after a breach who need to see the firewall rules but they've never asked to see any hidden rules. We switched from installing Untangle to Pfsense in 2013 during the 2.1 era so we've been using it for over 10 years now. It's realizations like this that make me feel I'm always at the peak of the Dunning-Kruger curve and it's all downhill from here.