Few Rookie Questions

[ohioyj]

So I know just enough to be dangerous. I've had this box up and running for a while now and I've come across a few questions. Hopefully these are easy enough someone can point me in the correct direction:

• Login to the actual device? I disabled the root account, and made a new account for login to the GUI. Now I seem to have no available logins to the actual device itself. I disabled the root account originally, as an extra layer of security. However perhaps now looking at my new user account, it doesn't have the same exact permissions as root. I can do everything from the GUI, I just can't seem to log into the shell at the device itself. Should I care?


• The devices I use do actually get frequent BIOS updates. Do I still need the os-cpu-microcode-intel / Intel microcode updates Plugin?
• I've been messing with one of my opnsense boxes recently, and so that's been leading my to swap in my backup. This got me to thinking is there a "HA" type setup for the opnsense box that I can setup? Rather than swapping the boxes physically, if one went down, the other would take over?
• From reading, it appears usually only inbound stuff is blocked. When I did all my rules, I blocked stuff in both directions. For example
  
  
  
  • Block INCOMING Traffic from IOT_VLAN to KID_VLAN
  • Block OUTGOING Tracffic from IOT_VLAN to KID_VLAN
  I figured I didn't want any traffic going in either direction between these networks. Did I do something wrong?

[nodakbarnes]

So I can help with the first two questions, the others are beyond the scope of my current knowledge.

For question #1:

Did you add the new user login account to the admins group? If so, you should have all the permissions that root did.

When you say you have no available logins to the device I assume you mean SSH logins.

For SSH logins to work you need to activate a shell under the user preferences (change the setting from /sbin/nologin to /bin/csh).

Also, for SSH to work, you need to go to System --> Settings --> Administration and put a check in "Enable Secure Shell". The login groups I choose are "wheel, admins" and then you need to check "Permit password login" if you're not going to place a public certificate in the user settings.

Lastly under Sudo I select "Ask password" so that I can sudo su if need be for full root privileges.

With all that done you should have SSH access to the box with the new user (and keeping root disabled).

For question #2:

If you are having consistent BIOS updates then I presume you are running a newer processor and/or motherboard chipset. With this in mind, I would recommend that you do run the Intel microcode plugin as the BIOS updates may not incorporate all the enhancements that the plugin does.

I do not have a HA setup and while I understand VLANS I am barely literate with firewall rules so I'll let others chime in there.

[meyergru]

1. Login to the actual device? I disabled the root account, and made a new account for login to the GUI. Now I seem to have no available logins to the actual device itself. I disabled the root account originally, as an extra layer of security. However perhaps now looking at my new user account, it doesn't have the same exact permissions as root. I can do everything from the GUI, I just can't seem to log into the shell at the device itself. Should I care?

There are two ways that someone could get account privileges:

1. By logging in via standard mechanisms (Password or SSH private key)
2. By circumventing the login via some security hole in an application or in the kernel.

By using 2FA you would raise the bar to a very high level for #1. The second problem cannot be solved by disabling legitimate access for any user. Ergo: Your approach is unsuited and only leads to additional inconvenience.

2.  The devices I use do actually get frequent BIOS updates. Do I still need the os-cpu-microcode-intel / Intel microcode updates Plugin?

It won't hurt, either, and if your manufacturer ceases to support your device in the future (which he will), you will still be safe.

3. I've been messing with one of my opnsense boxes recently, and so that's been leading my to swap in my backup. This got me to thinking is there a "HA" type setup for the opnsense box that I can setup? Rather than swapping the boxes physically, if one went down, the other would take over?

Yes. See documentation. If you are on fiber, you could even use two redundant ONTs on the same fiber.

4. From reading, it appears usually only inbound stuff is blocked. When I did all my rules, I blocked stuff in both directions. For example

• Block INCOMING Traffic from IOT_VLAN to KID_VLAN
• Block OUTGOING Tracffic from IOT_VLAN to KID_VLAN

I figured I didn't want any traffic going in either direction between these networks. Did I do something wrong?

No, But you you not have to do that unless you have some other rules allowing traffic to the internet, which typically is VLAN to "any". This is the only place where I use outgoing rules of the type "Block Outgoing from <INSECURE_VLAN> to <SECURE_VLAN>" at all. You do not need blocking rules otherwise, because there is a default BLOCK rule after any other rule.

More often than not, you will need access from LAN to IoT, but not vice-versa, for example if you have web-administrable IoT devices you want to access from your LAN.

[dseven]

I think it might be important to remind what the in/out direction for rules means - i.e. the direction of the traffic with respect to the firewall at the point where it's being inspected (on the given interface). An attempted connection from IOT_VLAN to KID_VLAN will arrive at the firewall (*inbound*) on the IOT_VLAN interface. If there was a rule that allows it (an *inbound* rule on the IOT_VLAN interface), it would pass through the firewall and then be sent *outbound* (from the firwall) on the KID_VLAN interface. In this case, it would have been blocked before it got that far, so there's really no point in having another rule to block it outbound.

Rules to allow/block are usually done on the inbound interface because it's more efficient to make those decisions as early as possible, rather than waste time processing the traffic only to decide to block it later.

Outbound rules are generally used to apply some policy to traffic originating from the firewall itself.

[ohioyj]

Thanks to everyone for their responses!

Yes. See documentation. If you are on fiber, you could even use two redundant ONTs on the same fiber.

I'm not thinking two ONTs (WANs), I'm thinking two opnSense boxes (Firewalls). Backwards of the way I normally think of HA working.

I think it might be important to remind what the in/out direction for rules means - i.e. the direction of the traffic with respect to the firewall at the point where it's being inspected (on the given interface). An attempted connection from IOT_VLAN to KID_VLAN will arrive at the firewall (*inbound*) on the IOT_VLAN interface. If there was a rule that allows it (an *inbound* rule on the IOT_VLAN interface), it would pass through the firewall and then be sent *outbound* (from the firwall) on the KID_VLAN interface. In this case, it would have been blocked before it got that far, so there's really no point in having another rule to block it outbound.

Rules to allow/block are usually done on the inbound interface because it's more efficient to make those decisions as early as possible, rather than waste time processing the traffic only to decide to block it later.

Outbound rules are generally used to apply some policy to traffic originating from the firewall itself.

Thank you so much for this explanation. This was sort of my "light bulb" moment. What I needed to actually understand it.

[dseven]

Speaking of lightbulbs ;D - https://docs.opnsense.org/manual/hacarp.html

[ohioyj]

Speaking of lightbulbs ;D - https://docs.opnsense.org/manual/hacarp.html

Doh... It's literally in the first couple sentences...

Two or more firewalls can be configured as a failover group.

I looked through there quickly, and saw the traditional diagram that I would expect, with the two ONT style. Reading fail on my part. Thank you.