Solved: Two factor authentication for admin login

emammadov

Is there a tutorial for this? I have another question. if there is no internet, can I still login into pfsense web gio with two factor authentication?

jimp

@emammadov said in Two factor authentication for admin login:

Is there a tutorial for this?

https://www.youtube.com/watch?v=n2Z3rr4W2xw
https://www.slideshare.net/NetgateUSA/radius-and-ldap-on-pfsense-24-pfsense-hangout-february-2018

I have another question. if there is no internet, can I still login into pfsense web gio with two factor authentication?

Google Authenticator does not actually contact Google for anything. It's a mathematically calculated OTP value based on your own key, date/time, etc. It isn't actually tied to any Google service/account/login/etc. It's basically a Google-branded equivalent to mOTP.

emammadov

Thanks. I tried and it worked. Along with the user created on Radius, I can also login with the user created on local database though I have chosen Radius in Authentication Server. You said it is a safety measure.
I have a question. I disabled webgui login for default local admin user "admin" and it works only on console. I wonder if Radius login fails, 1. can I add any user created on the local database to admins group on pfsense console and 2. enable webgui login for admin user?

jimp

The local user fallback will work for any local user, it doesn't need to be admin. You can grant that user whatever privileges you want them to have. If adding them to the admins group is what you want, that will work.

emammadov

I mean, I have disabled local admin user, so it can't login via webgui, it works only on ssh and console. If Radous server suddenly fails, how can I enable local admin user on SSH so that I can login via webgui!?

jimp

Yes, I know what you meant. What I'm saying is you can keep the actual "admin" account disabled and have some other local account you use instead that is always available for use.

Forcing yourself to re-enable admin when RADIUS is down is not a proper or reliable process. You can do it by resetting the admin password from the console which should re-enable it, or try pfSsh.php playback changepassword admin from the shell.

I wouldn't leave the firewall without some kind of active fallback authentication account though.

emammadov

Thank you very much.

M0L50N

@jimp Hi jimp.
I just implemented that setup, and if I let the local admin user enable to dont be locked out, the problem is that we can always login with that user without 2FA. My other admin user in freeradius with "Class := "admins"" work well, but the one local continue to works too!

I'm a little bit afraid to delete the local one. You said if Radius failed it will user local data base ... but if I dont have admin user in local database?!?!

Thanks!

jimp

It will always fall back to local database if RADIUS is down or rejects the login, for safety. If that's a concern, set the admin password to something suitably long/complex and store it somewhere secure in case of RADIUS failure, but don't give the password to anyone else.

Or just forget the password and reset it from the console if you ever need to get in locally.

M0L50N

@jimp
I understand, but for security reason, it it not better to dont have local admin user? My goal to create 2FA admin access is to securise Admin access. If the local user still exist, even with a strong password, the possibility to brute force it exist?!?!?!

Maybe I'm better dont use 2FA with my admin user, user really strong password and add rules to stop bruteforcing!?!?!

What is your vision about that?

Thanks for your advices!

jimp

You cannot delete the admin account as it's required for the firewall to function.

There is brute force protection already in pfSense that makes that kind of attack impractical.

If you set the password to a random long string >70 chars it's highly unlikely anything could practically brute force that. Especially if you have the GUI properly protected.

M0L50N

@jimp Thanks a lot. With you response, I can't find any advantage to put in place 2FA for the Admin account. I will only use a really strong password! However, I will use my freeradius for my OpenVPN client!
Thanks again and have a good weekend!

aaronssh

So I have this set up and working with Google Authenticator but I just noticed what I consider to me a major security flaw: any admin can reveal any other admin's PIN and INIT-SECRET.

This allows for any admin to easily impersonate any other admin. This means that it is not possible to be 100% sure that activity undertaken by any given admin was actually done by that admin. This makes pfSense non-complaint with basic security requirements for NIST/CMMC and probably many others with similar requirements to tie activity to a specific indiviual.

I suspect this was maybe just overlooked? Can a future update please fix this pretty serious and unnecessary risk?

NiDeMa

WARNING ABSOLUTE AMATEUR:
It did not work for me when I followed just these steps. It did work when I followed the steps and added the following:

SYSTEM->User management -> Edit admin user -> assign freeradius server certificate as user certificate.
SYSTEM->User management -> Authentication servers -> protocol assign as PAP (did not test if this is necessary)

It does work with google authenticator (PIN+generated passcode) BUT it also works with the old password that was set for admin. Is there a way to ensure that the old password does not work?

michmoor

@aaronssh did you open a redmine?
I suppose the mitigation would be to create a netadmin account that all your admins use to login with 2FA.
Agreed no one should see the PINs.

JeGr

@michmoor said in Solved: Two factor authentication for admin login:

Agreed no one should see the PINs.

How exactly should that be achievable? A TOTP base key for calculation is a stored secret that has to be used by the software to calculate the codes so AFAIR that can't be encrypted in any meaningless form. And as admin users normally are ADMINs - or root equivalents - they can simply get that info from the system, whatever barriers you put up in front of them can always be avoided. That's a "key to the castle" problem. Every admin that has a REAL admin access also has the tools to delete logs, impersonate other users etc. on any other system, may it be Linux, Windows etc. so I don't see how that should be non-compliant with any requirement that can't be reached other then making admins "not real admins" that only have a subset of administrative power? As I don't know the specifics of NIST/CMMC requirements, please correct me if I'm wrong as I'm just curious here. E.g. if I'm a Windows Administrator there's no problem in resetting the password of a fellow admin and logging in as him/her or looking up stored credentials that aren't/can't be further encrypted? Or Linux users having access to sudo/su that can login as another user and delete the logs afterwards?

Thanks & Cheers

jimp

In addition to the OTP calculation needing the PIN/secret, with how RADIUS works with OTP, it has to be set for PAP, which means the payload is sent in the clear. So it's best to keep that on the box if possible. If you must connect to a remote RADIUS system, wrap the connection in a VPN, stunnel, or similar.

aaronssh

@jegr said in Solved: Two factor authentication for admin login:

As I don't know the specifics of NIST/CMMC requirements, please correct me if I'm wrong as I'm just curious here. E.g. if I'm a Windows Administrator there's no problem in resetting the password of a fellow admin and logging in as him/her or looking up stored credentials that aren't/can't be further encrypted?

We're not allowed to know or reset users passwords, so we use a password portal that allows the user to self-reset after 2-factor via SMS. And as a Windows admin I have no way to retrieve a user's password, they are encrypted using non-reversible encryption (required by CMMC).

So if an admin did reset a password, it would immediately show up in the logs. CMMC requires that all logs are required to be centrally stored in a repository designed to store logs in a way that they can't be edited or modified by anyone. It would be possible to reset another Windows admin's password but would be easily traceable and alerts would go off.

In our 2-factor Windows solution (Authlite), keys CAN be exported and if you knew how to reverse engineer the export, you could probably find a way to get someone else's TOTP on a device somehow, but it would be some work and you'd still be missing their password -- its not anything like "click here to see PIN & key". And that's where the root of the concern is with pfSense. The PIN and key are just sitting there in plain text in the UI with zero obfuscation or encryption. It's WAY too easy and obvious to get that info. I agree with your premise that a sophisticated admin attacker could probably find a way somehow, my opinion is it just shouldn't be THAT incredibly easy and obvious.

We all know that obscurity is not security, but having some type of effort required to break in is sometimes enough. When it is easy and obvious how to break in, a disgruntled employee that might otherwise never bother might be tempted, because its SOOOO easy and obvious.

As a shop owner with a glass storefront, you don't just throw up your hands and leave the front door unlocked because anyone can break the glass anyway. There is still some common sense locking that takes place, even though the lock does not make the store invincible. Many people who would never break glass to steal something will walk in an open door to steal something; it's just an uncomfortable part of human nature that we all have to deal with at some level.

JeGr

@aaronssh said in Solved: Two factor authentication for admin login:

And as a Windows admin I have no way to retrieve a user's password, they are encrypted using non-reversible encryption

How? Is there any change in Windows itself about that? Because there were multiple ways to actually hack into/"retrieve" a user PW from AD as they are not encrypted but hashed and the hashing wasn't that good the last few times a MS patch came up. But perhaps they are safer now.

@aaronssh said in Solved: Two factor authentication for admin login:

So if an admin did reset a password, it would immediately show up in the logs. CMMC requires that all logs are required to be centrally stored in a repository designed to store logs in a way that they can't be edited or modified by anyone. It would be possible to reset another Windows admin's password but would be easily traceable and alerts would go off.

Ah so there would be logs about the PW reset and thus a breadcrumb to an admin to follow. Understandable.

@aaronssh said in Solved: Two factor authentication for admin login:

I agree with your premise that a sophisticated admin attacker could probably find a way somehow, my opinion is it just shouldn't be THAT incredibly easy and obvious.

But if a hacker could (very) probably find a way to it, WHY should you place security by obscurity and obfuscate the key? Again, every TOTP solution ever has the key saved in an easy to recover way. The only way they perhaps "protect" it better is by encrypting their configuration. But at the end, e.g. a phone app for TOTP stores the TOTP key in plain sight as it is needed to generate the token. Yes you can protect the app. But pfSense is a firewall so only admins have access - and in normal situations that is a "key to the castle" scenario. As root/admin you already have deepest levels of access. Compared with AD which is LDAP, Radius seems limited to the way it is - PAP to use TOTP. And other then Windows Logins - or pfSense local logins for that matter that are also encrypted via bcrypt - Radius needs various things in clear text to hand it over to services via PAP. So as far as my understanding of the service goes, that's not a pfSense problem per se but a limitation of Radius (protocol) and handling things - @jimp may correct me if I assume wrong.

but having some type of effort required to break in is sometimes enough

If you know that Radius needs things in clear text, and that is easy to check on, you can easily assume, that things are most likely not hashed but encrypted somehow and thus the code to do so would be in the open e.g. in the Radius or pfSense files. So the point would be a simple matter of reverse engineering, reading code and using the same decode part that pfSense/radius would be using and thus be rather pointless I assume.

@aaronssh said in Solved: Two factor authentication for admin login:

Many people who would never break glass to steal something will walk in an open door to steal something; it's just an uncomfortable part of human nature that we all have to deal with at some level.

I get the intention, but the comparison is bad. A storefront would also be in plain sight of others that would see it. And at night, at least there would be an alarm etc. added to the closed door. But implementing pointless encryption, that anyone can reverse with a few clicks (or build a tool to do it automatically) would be more like having already keys to the shop. It's not "a hacker" that can do the stuff, it's "the owners/workers that also tend the register". And yeah, those people could also take things from the register and simply go. That's why they're normally trusted.

But yes, I get your point, perhaps there are other measures that can be applied but in that case I think Radius + TOTP aren't the tools that match the use case to be covered.

Cheers :)