Best practices for opnsense firewalling? How do you do firewalling?

Started by bimbar, November 05, 2021, 12:32:13 PM

Previous topic - Next topic
I did ask this in another thread, but maybe it deserves its own.

I'll start with my personal universal firewall concept. Maybe someone else wants to share as well.

I divide networks into a few standard zone types (clients, servers, backend, dmz, admin, restricted, internet) with a standard communications matrix.
For example, clients are allowed to access servers, dmz and the internet.
I create a netgroup for each of those zone types with a standardized name (netgroup_dmz).
Then I create a second netgroup for each zone which contains all networks that are allowed to access it, called accessgroup_dmz.
More of those groups can be created for special needs according to the same scheme.

In my firewall rules there are only rules of the form "Allow quick accessgroup_XXX -> netgroup_XXX" .
For internet access there is a rule "Allow quick accessgroup_internet -> !netgroup_internet_inverted".
netgroup_internet_inverted contains all internal networks and net_blocked. Net_blocked is basically firehol L1.

For access from outside to inside there are interface rules on WAN of the form Allow quick !net_blocked -> PORTS -> This Firewall .

Importantly, there are no drop rules except the default drop. That makes the ruleset easier to understand and the order of rules is irrelevant.
If this ruleset is implemented somewhere else, all that is necessary is usually to add the local networks to the right aliases and create a few special rules for DMZs.

This is exactly what I have done with Gauntlet, Sidewinder and now with OPNsense for almost three decades.

My main take that I have repeatedly voiced on this forum, too: if you rely on "static IP addresses" to control anything but ingress, you are doing it wrong. Put devices that share a policy into the same zone, set up policies matching zones.

Ingress (public services) from the internet of course needs to adress IP addresses and ports.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Now I feel validated ;) .

For services reachable from the internet I am aiming at client certificate authentication where possible, but that's a bit of a different topic than firewalling.

Quote from: bimbar on November 05, 2021, 12:55:05 PM
For services reachable from the internet I am aiming at client certificate authentication where possible, but that's a bit of a different topic than firewalling.
Still you need to open port 443 for the reverse proxy implementing that. That's what I was referring to.

Yes, reverse proxy for a single point of SSL termination is definitely recommended and can do much much more.
Did I mention Apache Guacamole for remote access of SSH/VNC/RDP? Can do 2FA, too.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: pmhausen on November 05, 2021, 01:09:13 PM
Quote from: bimbar on November 05, 2021, 12:55:05 PM
For services reachable from the internet I am aiming at client certificate authentication where possible, but that's a bit of a different topic than firewalling.
Still you need to open port 443 for the reverse proxy implementing that. That's what I was referring to.

Yes, reverse proxy for a single point of SSL termination is definitely recommended and can do much much more.
Did I mention Apache Guacamole for remote access of SSH/VNC/RDP? Can do 2FA, too.

I don't see any prebuilt packages for that and I can't sell compiling it myself to the company.

There is a pre-built package for FreeBSD. And I bet there are for Linux, too. Set up a dedicated Gucamole VM - or even better a jail, if you have FreeBSD based infrastructure. Nothing mandates your reverse proxy, SSL VPN, or similar to run on your firewall device.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)