OPNsense Forum
English Forums => General Discussion => Topic started by: z0rk on September 14, 2018, 09:34:28 pm
-
I want to enable 2fA for authentication when logging into the admin GUI. I've followed all steps here:
https://wiki.opnsense.org/manual/how-tos/two_factor.html
I succeeded for steps 1 - 5. But when trying to log into the admin GUI with token + password authentication fails. Using the plain password works. What am I missing?
Thanks
-
Hi,
Step 6 is a bit unclear. You need to change the appropriate service (IPsec, Captive Portal, Web Proxy, OpenVPN or web GUI) to use the TOTP server.
For the web GUI the setting is under System: Settings: Administration: Authentication Server.
Make sure you are able to use TOTP correctly (step 5) and then also disable "Local Server", because otherwise you could always log in using the plain password which defeats the purpose of TOTP-based login.
Cheers,
Franco
-
Ok, thanks Franco I will test it out. I do have a follow up questions though about best practice in case of TOPT scenarios, i.e. what's the best way to implement a failsafe in case TOPT is unavailable or human error. How do I ensure, I don't lock myself out of the system?
i.e. once I select 'Disable integrated authentication' than how do I log in with another admin account at the console to fix things? or is the only recourse to do a reinstall and restore configurations from backup? That seems laborious. I am not sure, if I am expressing myself clearly. Do you have any thoughts / recommendations?
Thx
-
Use SSH with keys instead of password login to ensure access.
Unlock the console menu if your physical access is secure. It's the best way to recover as the console menu gives you several recovery options.
Only use "Disable integrated authentication" if you know what you are doing. It takes you back to the dark ages of OPNsense where TOPT can't be used for console and SSH login, possibly other subsystems relying on password-based user authentication so you bypass your security.
Cheers,
Franco
-
I've SSH access disabled and I allow Web GUI access only on LAN. I am not concerned about physical access, so I could disable 'Password protect the console menu' under System: Settings: Administration. Thanks for this suggestion!
If I understand your other feedback correctly, I should then select 'TOPT Server" under System: Settings: Administration: Server and not enable 'Disable integrated authentication'.
Ok, so now with these setting in place, I can reset to defaults or restore settings from backup at the console without having to worry about TOPT. What I am still struggling with though is, let's say I have TOPT enabled and over time make other configuration changes to the system, if then for whatever reason my TOPT enabled admin account gets hosed or the TOPT service is unavailable, how do I go back to a system that has all of my current system configuration settings in place (as of latest backup), but won't require TOPT service at the GUI? Would I have to disable TOPT at the console and create a new administrator account to get back into the GUI?
Sorry this may sound like I am getting lost in the weeds, but I am new to this level of router / firewall security and to OPNsense in particular. Basically I want to have an action plan in place in case something goes awry with TOPT / my admin account, so my family won't burn me at the stake should they loose internet access. :P
-
Hello z0rk, just some additions, franco already said most if not all of it..
You should not disable SSH access, at least I won't, but instead of a password use KEY authentication, like franco said.
This can prove a way in if nothing else works, even if the console is locked up (it shouldn't I know).
There is a very good wiki about that on Arch https://wiki.archlinux.org/index.php/SSH_keys.
About TOTP ( not TOPT you guys ) ;D, don't use it unless you know it's workings.
The downside of using this tool is you can lock yourself out to never gain access again also after restoring a backup (which is a feature not a bug).
That is, depending on further actions you took to 'secure the building', which you should of course, otherwise what would be it's purpose...
Be sure everything on the TOTP authenticator device (smartphone) is setup and working correctly before you set it to be the only way to log in.
I happened to get myself in this nasty situation where the smartphone was not able to get a timeserver update, there is a 30 second window...
Before I was able to anticipate to that fact I had already restored a backup, so keep that in mind.
Btw. if setup correctly you'll never look back, and the family will be happy once again. ;)
Greetings, mark
-
Hey Mark... I am familiar with public key authentication and have it in place on other systems. SSH access is disabled by default on OPNsense and I don't see a particular reason why I would want to enable it at this time, if I have access at the console. Keep the attack surface small, right?
I did follow the steps for the setup for TOTP (thanks for the catch ::)) and did the test as suggested under step 5, so it appears to be working. My concern is to have an action plan in place that I can test out in advance in case there are issues with TOTP itself. Since I've never used TOTP as a primary authentication mechanism for a homespun system I have no experience with it and therefore feel wary what to do in case something goes wrong with the account as described below. Hope this makes sense. Maybe this is not an easy thing to do or one needs advanced skills at the CLI for such a plan, so I don't know, that's why I am asking. And maybe the message here is there is no easy way, so better not to enable TOTP?
Cheers
-
Well, what you could do after you have tested if TOTP works you make a backup without it being enabled.
Then you enable TOTP and there is at least a backup you know works.
You can always diff the non-TOTP- vs. TOTP-config.xml and strip it out in case of problems.
Just, I run it for a few months now and it's running fine since.. :)
Greetings, mark
-
I think stripping out the TOTP settings from the config.xml may be the way to go. Thanks Mark
-
Your welcome, and to be clear on this, especially to future readers:
You normally install a backup with TOTP enabled, and this of course works :P
Greetings, mark
edit: if you would, please add solved to your post, thanks.
-
I only wrote "TOPT" once out of 4 tries. :D
There's no attack surface of SSH really: not reachable from a non-LAN by default. But you can also bind to LAN-only. It beats access to the console if it's a serial one somewhere I a room where you walk longer than type "ssh to.my.server".
I have to second Mark's experience: while it's true that TOTP can fail you if NTP is not syncing it rarely (if ever) happens.
As for contingency... if you now have access to the root menu either through console or SSH and TOTP doesn't work just choose option "3" from the menu to reset the root password. It'll ask you:
>>> Do you want to set it back to Local Database? [y/N]:
To which you input "y" and afterwards change the root password, but it can be the same password as before.
Cheers,
Franco
-
I only wrote "TOPT" once out of 4 tries. :D
That's enough .. ;D
[zapp] it rarely (if ever) happens.
Once I know of... :P
Btw. @z0rk, maybe revise your idea about SSH a little?
Greetings, mark
-
As for contingency... if you now have access to the root menu either through console or SSH and TOTP doesn't work just choose option "3" from the menu to reset the root password. It'll ask you:
>>> Do you want to set it back to Local Database? [y/N]:
To which you input "y" and afterwards change the root password, but it can be the same password as before.
Cheers,
Franco
That's the ticket. It really addresses all of my previous concerns. Got TOTP enabled now. Thanks Cheers
-
Btw. @z0rk, maybe revise your idea about SSH a little?
Greetings, mark
Thanks for your feedback help, Mark. Cheers