FEATURE TO OPT IN TO AUTOMATIC GENERATION OF RULES

[RMLNZ]

A firewall administrator should have explicit control over all of the rules defined in a firewall they manage.

OPNSENSE should NOT automatically generate firewall rules.

It is especially poor for one of those rules to be the base rule that says pass any traffic to any destination where that traffic originates from the firewall.

There are two assumptions behind that which says that (i) all traffic from the firewall is traffic the firewall administrator would wish to allow to pass and (ii) a bad actor, knowing the nature of the system generated rules, would be incapable of duping the firewall to do things not intended by the firewall administrator or its designers.

[franco]

Uh, no, not this again. Please.


Cheers,
Franco

[pfry]

Uh, no, not this again. Please.

Ah, but why would it continue to show up? So yes! Read it all again!

A firewall administrator should have explicit control over all of the rules defined in a firewall they manage.

Agreed, but there is a bit of nuance. I'd be happier with the ability to simply add my own (namely a block rule at the top of the list). The design of pf makes this a bit of a pain in the ass to do cleanly, and of course there are legacy considerations.

Realistically the only inbound vulnerability is IPv6 ICMP. Now, I permit lots of ICMP as a matter of course, but it would be nice to cover it with a block. The actual chance of a meaningful exploit (DoS or resource consumption) is pretty minimal (address space under attack must be accessible to the attacker). Still, firewalls are a numbers game.

[...]
It is especially poor for one of those rules to be the base rule that says pass any traffic to any destination where that traffic originates from the firewall. [...]

Yeah, here again, you could get very detailed with the outbound filter, but, yet again, it's difficult to impossible to do cleanly. And realistically you must trust your firewall. You can nitpick services, but the chance of a real exploit of the firewall that would be meaningfully affected by an outbound filter on the firewall itself is pretty small.

If I was designing a network filter, I'd plug the holes, because I could. And really for no other reason.

I might consider promoting alterations to the automatic rules (again), but I'd expect to have to fund and/or contribute (the code) to them. And, of course, they'd have to be accepted. I don't know that I have enough liquor, hookers, and bribe money.

[RMLNZ]

So you have the awful rule "anything from the firewall may pass".

Point your PC clients at the firewall's DNS for DNS services.

The DNS server is part of the firewall and therefore its traffic is passed automatically.

Any rule you define at the floating or interface level filtering traffic on the outbound WAN to a defined external DNS server address [eg OpenDNS] will fail to filter your outbound DNS traffic because it is passed based on the fundamentally flawed, higher priority, system generated "permit all from the firewall itself" rule.

I'll bet that the KGB/CCP just loves the fact that OPNSENSE runs an open gateway on the internal DNS server by default and you can't seem to delete that stupid base rule.

Oh yes, plenty of malware uses DNS to exfiltrate data by talking to its preferred DNS server. Nicht wahr ?


A key point is that a firewall should obey its own rules.

If there are missing rules and firewall stuff won't work, then the fix is to add or modify the rules so that it does work.


The ONLY rule that should exist by default at a system level on a firewall is:

• Block Everything on Every Interface whether Inbound or Outbound

Thereafter, traffic can only be passed by explicit approval of the firewall administrator.

Why ? A firewall is NOT meant to be a router. It is meant to be an obstruction first, foremost and always.



There is a need to define a new mode of OPNSense called "Strict Security Mode" which enforces one base rule of:

• Block Everything on Every Interface whether Inbound or Outbound

An installation step will require you to nominate a management interface so inbound SSH and HTTPS can be permitted on that interface (assume LAN).

A life saving console command should be available to "permit management access on interface x" in case you mess up your rules and find yourself in need of resurrection :)



OPNSense should also consider the risk of changes in its software introducing new "system generated rules" that contradict user (firewall administrator) wishes.

[Monviech (Cedrik)]

Please look at how the automatic generated rules are created.

Let's take the automatic out rule for example:

Code Select Expand

pass out log all flags S/SA keep state allow-opts label "1232f88e5fac29a32501e3f051020cac"

As you can see, pass out has no "quick" option defined, which means its a last matching rule - "AFTER" your already existing ruleset.

Which means, go to "Firewall - Rules - Floating" and create a rule like this:

Code Select Expand

block out quick log all flags S/SA keep state allow-opts label "1232f88e5fac29a32501e3f051020cac"

Quick matches first, you can overrule most of these automatically generated "last match (non quick)" rules with your own quick rules in Floating like this.

No need to get dramatic.

[franco]

Automatic rules exist to get the firewall up and running quickly by offering minimal invasive rules for each protocol like DHCP -- should we expect everyone to go to the docs page and copy a rules block into their firewall?

> So you have the awful rule "anything from the firewall may pass".

One simple problem that Cedrik mentioned the fix for.

> Oh yes, plenty of malware uses DNS to exfiltrate data by talking to its preferred DNS server.

Disable DNS if you don't need it and/or deem it is not safe enough?

I'm not quite understanding the scope of this issue.

[pfry]

[...]As you can see, pass out has no "quick" option defined [...]

Ha! I keep missing that. I'm so accustomed to simple rule systems.
Note that I have no outbound rules, nor do I plan to create any. I simply log everything, and the default outbound rule is quite chatty (good old pf logging).

[...]
I'm not quite understanding the scope of this issue.

This forum is just too convenient. I don't think discussion of this is entirely wasted bandwidth, but perhaps meyergru would be willing to add a "point 24": "Stop worrying and love the automatic rules - they are better considered than you think." I don't believe there is a single concise explanation of this in the docs (correct me if I'm wrong). The rule design, behavior, and actual risks are non-obvious, particularly to new users.

In my experience commercial firewalls tend to be much worse in this respect. Local rules tend to be fully or partially hidden and/or read-only, and logging is often at least partially suppressed. Only routers (e.g. Cisco, Juniper) offered full control, but I can't say if that's the case now, as their firewall architectures have evolved considerably since I used them.

[franco]

> This forum is just too convenient.

Which is good :)

> Local rules tend to be fully or partially hidden

Interestingly enough the complaints for bad automatic rules started to rise with the fact that we made them visible in the GUI in OPNsense 19.7. It wasn't possible to review them before that and not sure how pfSense fares in this nowadays either. At one point someone blamed us for silly automatic rules threatening to rather use pfSense. It's difficult to make such stories up even if one tried.


Cheers,
Franco

[cookiemonster]

I did worry the return of this topic would create another mini storm but didn't, which is good.
That said, the lines that caught my eye and got me wondering are these:

There is a need to define a new mode of OPNSense called "Strict Security Mode" which enforces one base rule of:

    Block Everything on Every Interface whether Inbound or Outbound

Is there any merit in considering very quickly if such an option can be considered IF is as simple as Option A (strict security mode) or B (default) and all option A does is skip the code that has the rules generation ?
What I mean is that if it's "easy" and low maintenance i.e. does not require to maintain two code sections, then it might provide what some people want to see.
And I get it that the current rules are very sensible and there is no actual need of this, but for the sake of allying the recurring queries.

[Monviech (Cedrik)]

I dont want another spot that can break access completely xD

People can lock themselves out with firewall rules if they want to.

People just love to check every setting that exists even if multiple warning popups warn them not to.

[cookiemonster]

Fair enough.

[Patrick M. Hausen]

Anyone who can create rules for ARP and ND from the top of their head and get it right without referring to the docs? Every firewall has automatic rules (like for these two protocols), OPNsense just decided to show them.

[franco]

> Is there any merit in considering very quickly if such an option can be considered IF is as simple as Option A (strict security mode) or B (default) and all option A does is skip the code that has the rules generation ?

Good question. The basic design decision is scoping... globally or per interface? Default value of the pass out should be created, so you'd add one opt-out setting to each interface.

That's based on Cedriks assumption because the OP did not say clearly (although I suspect this is mainly for local services which only ever see the out direction of an interface since they originate on the firewall) of which rule we talk about. And now we only need a use case so we can explain it easily -- "do not allow all services on the firewall to reach out this interface"?


Cheers,
Franco

[franco]

> Anyone who can create rules for ARP and ND from the top of their head and get it right without referring to the docs?

As a technical person it would maybe take at least an hour getting a very simple WAN - LAN IPv4 ready (DHCP outside, DHCP inside, routing ok) if no automatic rules were provided. If you then wanted to add them to the docs it would be a lengthy exposition dump and perhaps a typo or two getting them inserted. Everybody would ask them to be moved to the GUI as automatic settings because it seems like the best thing to do.  :)


Cheers,
Franco

[Monviech (Cedrik)]

A good example to show where a lot of people struggle is NAT Reflection.

The documentation must go into a lot of detail.

This would be the exposition dump every single automatic rule would need that has a toggle to enable or disable. And the below is just for a single concept.

https://docs.opnsense.org/manual/how-tos/nat_reflection.html