Restricting SSH on Certain Interfaces: Automatic Firewall Rules?

[Sinister Pisces]

Hello,

I'm working on hardening my OPNSense installation. I have a management VLAN set up, and an out of band management port with its own dedicated ethernet interface, so essentially I have two management networks. My goal is to have the firewall accessible via SSH and HTTPS only on those two networks.

The guide I was using described the process of manually writing rules in the VLANs to accomplish this, but after starting on this, I'm seeing SSH rules being auto-generated and now I'm confused. I want to make sure I understand what's going on before going further.

I've only adjusted the SSH service so far, which has led to confusion, so I'll start with that.

I already successfully adjusted the SSH listen interfaces (Settings > Administration) to only listen on the two interfaces I want, and I've tested that it works: clients attempting to connect via SSH to the firewall's IP address on other VLANs and the actual parent LAN interface cannot connect via SSH. Success.

However, all the VLANs still have a pair of sshlockout auto-generated rules on them: one for my custom SSH port and one, oddly, for my custom HTTPS port for the web GUI. There's also a matching floating rule. They look like this:

Code Select Expand

Source: * ; [Source] Port: *; Destination: Self; [Destination] Port: As Configured; Gateway: *; Schedule: *; Number of Interfaces Rule Applies to: *; Description: sshlockout

The part that's really confusing me is that these auto-generated rules look the same on interfaces where SSH is allowed as where it's blocked, so I can't tell the difference. Since I successfully restricted SSH access in the GUI, shouldn't I be seeing different auto-generated rules on the interfaces that allow SSH to OPNSense versus those that don't?

This little adventure is making me feel like I misunderstand something fundamental.

[pfry]

Those are block rules applied to sources contained in the sshlockout alias. I block external access, so I haven't seen any action triggering population of this alias, but I assume it operates on a fail2ban-type concept (where a certain number of auth failures from a particular source get stuck into sshlockout for a period of time). So: default security stuff, which likely won't apply to you (unless you have some internal leak, like a nosy roommate). Funny, I don't see a mention of it offhand in the wiki/docs. You could test it if you're bored. (I have the anti-lockout rules disabled - does the sshlockout precede or follow...?)

[hharry]

the anti-lockout rule automatic rule is created when the Firewall: Settings: Advanced 'disable antilock-out' parameter is not selected, as below


WARNING: When this is unchecked, access to the web GUI or SSH on the LAN interface is always permitted, regardless of the user-defined firewall rule set. Check this box to disable the automatically added rule, so access is controlled only by the user-defined firewall rules. Ensure you have a firewall rule in place that allows you in, or you will lock yourself out.

[Sinister Pisces]

Thanks!

(Aside: This sounds like the sort of thing where I want to take a snapshot before fooling around ... :P )

Just to make sure I'm correctly understanding:
Right now:

• The default anti-lockout rule is still enabled (I haven't touched this yet).
• I have restricted SSH to two interfaces using the GUI.
• SSH is accessible on those interfaces.
• Attempts to connect via other interfaces, including the Primary LAN interface, currently fail.
• I have not added any allow rules for SSH to the management VLAN or the out of band management interface (physical NIC).

I suspect, based on what y'all wrote, that the default anti-lockout rules are allowing me to access SSH on my chosen interfaces right now, and if I disabled the anti-lockout without putting in firewall rules, I'd be locked out.

Is that right?

EDIT: I think what tripped me up here is that the two interfaces I've designated are a VLAN whose parent is the primary LAN interface, and a physical NIC that isn't my primary LAN interface, but rather is a secondary LAN.

So, I read the warning on the disable anti-lockout option and saw "the LAN interface," and assumed it meant that access is always available specifically on the Primary LAN physical interface. I think I was being too literal, and instead, when anti-lockout is on, any LAN interface (including the two physical LAN interfaces I have, and any VLAN children they have) are covered. That would explain why my current setup is working without any firewall rules in place.

Is that correct?

[hharry]

I suspect, based on what y'all wrote, that the default anti-lockout rules are allowing me to access SSH on my chosen interfaces right now, and if I disabled the anti-lockout without putting in firewall rules, I'd be locked out.

Is that right?

Correct, so you must first ensure you add a manual Management LAN interface F/W rule, to permit inbound both ssh (dst tcp port 22) and https ( dstp tcp port 443 ) to your desired management interface / address, then confirm it is configured properly, before considering disabling the automatic anti-lockout rule.

Then make sure to never delete the manual Management LAN interface F/W rule, to permit inbound both ssh and https....

[EricPerl]

The sshlockout rule blocks access so it is irrelevant in this thread.

You may have noticed that the anti-lockout rule applies to a single interface (that you can't choose).
https://forum.opnsense.org/index.php?topic=22640.0
I no longer have a 'lan' so opt1 is used. It's not exactly an optimal choice for me but I leave it there as a backup (which is what it is).

The rule itself is defined in Firewall > NAT > Port Forward.
It's not exactly the easiest one to understand.
The ports are the SSH and TCP ports defined in System > Settings > Administration. 80 is included if HTTP redirect is not disabled.

Listening on all interfaces is generally recommended.
Access is controlled via FW (anti-lockout and/or custom rules).

[Sinister Pisces]

Thanks, everyone. I think I've got a pretty solid handle on this now. I'm working on my first-non-default set of firewall rules for my management VLAN--I need to get that done correctly before I go further messing with what ports OPNSense is listening on.

So, I'm going to make a separate thread about that and make sure I understand what I'm doing before I push forward with this.

So far, I haven't broken anything. :P