OPNsense Forum

English Forums => General Discussion => Topic started by: Neo on March 17, 2021, 09:41:11 PM

Title: OpnSense Security and Hardening Best Practice Guide
Post by: Neo on March 17, 2021, 09:41:11 PM
Hello,

I'm wondering if there is a guide or check list (or set of bullet point recommendations) around securing OpnSense for full production deployment. There are obvious things like not turning on SSH (or making sure it is setup to be super secure and only accessible via the LAN), setting a strong password on root, possibly setting up MFA, etc. but I'm wondering if there are more considerations and/or if anyone has or knows of content that addresses this question specifically.

Also curious if most of you access the OpnSense using 'root' or if you tend to lock that down and access the firewall using a separate admin login once in production?
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: lfirewall1243 on March 21, 2021, 02:25:29 PM
Nothing more than on any other firewall system.

No web UI form WAN, no SSH from WAN,...
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Mks on March 21, 2021, 03:52:19 PM
Hi,

usually infrastructure components should only be accessed for administrative purposes via a "Management LAN" and not via WAN.
Nonetheless access only via MFA, dedicated Admin Account (not root), WebGUI proper TLS settings (certificate, Ciphers). SSH Key auth -> no password login, proper ciphers
Lock-Down the console if necessary.

The base system is anyway a "HardenedBSD" Image.

Not an exhaustive list  ;)

br
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Neo on March 23, 2021, 05:17:22 AM
So what is the general practice for 'root'? Since the ID cannot be changed (as far as I can tell) and I'd tend to 'assume' you want at lest one account that is not tied to TOTP just in case that fails... Do you just set a really complex random password? I've already done that and setup a separate admin login for myself (have not fully tested with TOPT, yet)... On other systems I've generally changed 'root' (or factory default admin account) to some other ID whenever possible...
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Mks on March 23, 2021, 07:14:37 AM
Hi,

QuoteSo what is the general practice for 'root'?
I've deactivated root.
If I need to SSH (only key Auth) into Opnsense I'm using a different account, if root privileges are required -> sudo.

MFA is activated for all accounts. If it fails -> Console.

br
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Neo on April 12, 2021, 01:13:13 AM
@MKS - sounds like a good approach. thanks for the tips!
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: vlorentz on June 14, 2021, 01:33:06 AM
Is there any way to let root active, but force the following for SSH login:
- user login over SSH with TOTP
- after successfull user login, switch to root by using standard password (without TOTP)?

Further, could somebody confirm that if no seeds is configured for "root" and only the TOTP server is allowed under System --> Settings --> Administration --> Authentication --> Server ; then if using "sudo", the root password must contain also the TOTP code... but if there is no seeds configured for root, the password will never be valid?

Actually, I would like to reach following situation: user logging with TOTP, switch to root with standard password, after user login was validated successfully. (for SSH).

For WebGUI, I would like that root is not enabled at all.

Maybe there is a more elegant way: in this case, I would be very interested in listening to other strategies.

Best regards
Vincent
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Greelan on June 14, 2021, 02:13:43 AM
I only allow a separate user (not root) to login via SSH, with key authentication only. Then "sudo su -" to switch to root, authenticating with the user password and TOTP
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: vlorentz on June 14, 2021, 09:25:47 AM
Thank you.

Some weeks ago, I had the issue that NTP could not access the time servers anymore... because Unbound DNS was not able to resolve the server names... bacause an error in the configuration, that appeared after a reboot. The consequence was, that the date and time was back in 2017 and TOTP was hindering any login.

In such a case, the console saved me (which was not protected with a password).

In consequence, I would prefer to have the root not dependent on the TOTP, but actually, I do not have any ideal solution.

Thanks for sharing yours, Greelan.
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Greelan on June 14, 2021, 09:46:00 AM
The other thing to think about is not exposing the GUI or CLI to the WAN at all. I just use a WireGuard VPN to tunnel in and then connect to the GUI or via SSH locally
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Mks on June 14, 2021, 08:44:14 PM
Hi,

QuoteIn consequence, I would prefer to have the root not dependent on the TOTP, but actually, I do not have any ideal solution.
In that case you have to

br
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: thogru on June 14, 2021, 11:42:30 PM
Hi Mks,

But for booting into single user mode you need access directly to the machine? Through a serial console or attached keyboard and display if running in VGA mode? Don't you?

Edit/Addition: Is there a command to start FreeBSD in single user mode entered at the prompt (e.g. ssh)?

Kind Regards
Thomas
Title: Re: OpnSense Security and Hardening Best Practice Guide
Post by: Mks on June 15, 2021, 01:32:53 PM
Quote from: thogru on June 14, 2021, 11:42:30 PM
Hi Mks,

But for booting into single user mode you need access directly to the machine? Through a serial console or attached keyboard and display if running in VGA mode? Don't you?

Edit/Addition: Is there a command to start FreeBSD in single user mode entered at the prompt (e.g. ssh)?

Kind Regards
Thomas

Hi, yes access to the machine. This is my "Break the glass" scenario.

To enter Single User Mode push "2" on the boot screen.

br
Manuel