FEATURE TO OPT IN TO AUTOMATIC GENERATION OF RULES

[Patrick M. Hausen]

That's why a reverse proxy is just so much better. After I realised what the automatic NAT reflection mechanism created on all of my interfaces, I instantly disabled it 🙂

[cookiemonster]

> 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

Yes exactly. You're right the requested scope hasn't been clearly defined but since the intent behind what was written was:

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

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.

<snip>

therefore the "Strict mode" would create none as per the OP's request. As to how useful that'll be is a side debate but would IMHO take away this recurring question. I suspect 99% of new users would either not chose it or have to re-install after realising how well the gun was aligned with a foot.

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

I know I wouldn't want to take this path Cedrik. As before, I'm not advocating for it, but to have a thought for this reocurring question from those who think it is how they want it. If it is easy to implement, why not give them the dog's dinner they seem to crave?

[pfry]

[...]
If it is easy to implement, why not give them the dog's dinner they seem to crave?

Heh. I hadn't really considered that solution, but... I'd do it. But I know exactly what I'm doing. Or, more correctly, I would figure it out. Any guesses as to what my super-custom rule set would look like?

I'd be ready for that ICMPv6 unreachable attack that has never occurred (to my knowledge, although I've only audited ICMPv4, and the last unreachable attack that I saw was ~20 years ago) and would consume minimal resources on my public servers (that have a bit more significant attack surface and their own firewalls). Oh - once I get IPv6 connectivity, because it's not available. Note that I would have to manually ban any attacker, because I have blanket pass rules for unreachables. Yeah... I'd still do it.

[RMLNZ]

Thank you for the interesting and enlightening posts.

I agree there is immense value in the system generated rule sets to streamline enabling firewall features.

The examples showing the complexity the automated system encapsulates are very helpful.

I really like the way that some system rules are linked back to the enabling GUI fields.

Perhaps I could restate my suggestion as follows:

Add a new mode setting to OPNSENSE called Security Mode:

Default Security Mode - Current behaviour

Strict Security Mode - New behaviours/features to be:

• Default rule is that all traffic is blocked unless explicitly approved.
• The default system generated rule to pass any traffic from the firewall itself is removed.
• If a firewall service needs a rule to work, that rule must be created and approved by the firewall administrator.
• The system generated ruleset could include recommended rules required for firewall operation.
• The system generated rules are all created in a disabled state (except for the default administration access rules).
• The firewall administrator can choose to enable the system generated rules.
• If the firewall administrator wishes they can clone the system generated rules and edit them as they see fit.

Separately, it's suggested we have a new CLI command to "RecoverAdmin InterfaceName" to salvage administration access if a user locks themselves out. I guess this would inject floating, first in sequence quick rules limited to the specified interface.

Also, can we please expand on the description of how the quick / last match rules work ?

Also, can we add an option to the GUI to view the active rule set (eg view /tmp/rules.debug)

[RMLNZ]

Does QUICK operate within a section ?

If no QUICK match is found in the section then is the section processed again looking for the last match ?

OR

Does QUICK operate across the entire rule set first ?

If no QUICK match is found in the ruleset then is the ruleset processed again looking for the last match ?

[pfoo]

My two cents on this : my ISP force me to tag outbound icmpv6 RS/NS/NA to a certain COS priority, which I cannot do due to the automatic (quick) IPv6 RFC4890 rules. For now the only solution is to patch filter.lib.inc to add a rule before IPv6 RFC4890 automatic rules. Good thing with opnsense : you can patch some quite easy to read php files, still, it's a patch that might break after any opnsense update. I don't know if a per-interface opt-out setting for automatic rules or a way to add "advanced" rule before automatic rule is better, but I'd be happy with any of the two solution. It's not only about enabling/disabling rules but also about rule ordering +- quick flag. Automatic rule should however stay the default for at least basic firewall operation.

[pfry]

[...]
Strict Security Mode - New behaviours/features to be:

• Default rule is that all traffic is blocked unless explicitly approved.
• The default system generated rule to pass any traffic from the firewall itself is removed.
• If a firewall service needs a rule to work, that rule must be created and approved by the firewall administrator.
• The system generated ruleset could include recommended rules required for firewall operation.
• The system generated rules are all created in a disabled state (except for the default administration access rules).
• The firewall administrator can choose to enable the system generated rules.
• If the firewall administrator wishes they can clone the system generated rules and edit them as they see fit.

The first automatic rule is "Default deny / state violation rule":

Code Select Expand

block drop in [log] inet all label "ecd3a310894625657c6591b80daa956a"
block drop in [log] inet6 all label "ecd3a310894625657c6591b80daa956a"
...So there's your default deny. Just leave that one.

Some of your points are procedural, not functional.

Cloning the ruleset manually is pretty easy; I don't know how difficult it would be to provide the GUI "clone" button for automatic rules. I would create interface rules (mostly), but some prefer floating. Hm: Perhaps, as you have above, include the standard automatic ruleset as floating rules. The user can then disable or delete them as desired. No special administration required.

To be a little more clear, I would propose converting the automatic rules to floating. No other change should be necessary*. This would also place the onus of locking the user out entirely on the user, as it would take a bit of configuration to do so.

* I'm making a significant assumption here, as I haven't used floating rules. Also, there are elements outside of the regular "Firewall: Rules" UI that would need to be considered if the automatic rules are nixed, such as "Interfaces: [NAME]" -> "Generic configuration" -> "Block private networks", "Firewall: Settings: Advanced" -> "Logging", "Firewall: Settings: Advanced" -> "Miscellaneous" -> "Disable anti-lockout", or "Services: Kea DHCP: Kea DHCPv4" -> "Firewall rules", to name a couple.

("Interfaces: [NAME]" -> "Generic configuration" -> "Block bogon networks" already has issues. I should propose funding a fix for that.)

[...]
Also, can we add an option to the GUI to view the active rule set (eg view /tmp/rules.debug)

As in "Firewall: Diagnostics: Statistics" -> "rules"? Or something different?

[RMLNZ]

The idea of an option to make the system generated rules "floating" is excellent and would give me what I want which is at heart full control of MY firewall which runs on MY network. The base block all rule could be generated as the only system generated rule.

I do think there is benefit in always being able to see what the officially recommended system generated firewall rules are so you can see how you have varied them.

[pfry]

Thinking about the logic behind such a change, given a "[Some sort of appropriate label] - not recommended" checkbox, you'd want to be able to check it, apply it, uncheck it, apply it, repeat - without particularly adverse effects.

1) For ultimate simplicity, simply vanish the non-configurable automatic rules on "check" and unvanish them on "uncheck".

2) In addition to #1, add a "clone" button to the automatic rules, which would edit a matching floating rule. I like this one.

[I had a buncha goofy stuff here related to rule conversion, recreation, etc., but complexity=pain.]

The configurable automatic rule behavior would not need to change - they already vanish/unvanish through a checkbox.

How does the UI handle an empty automatic ruleset?

And, of course, what am I missing?