MFA for pfSense GUI
-
Hi there,
I'm sure this question was asked before: Is there anyway to implement/enable MFA for pfSense web-gui login?
-S
-
I'm sure this question was asked before
Yes it has: https://forum.pfsense.org/index.php?action=search
-
Yes this question comes up now and then.
What I don't understand is why it matters.. Who exactly is accessing your web gui? Your web gui should not be open to such a large audience where MFA should come into play. If it is then your doing it wrong!!
-
It doesn't necessarily matter who has access to it. Sometimes there are requirements your company must meet when it comes to IT infrastructure in order to do business with certain clients. So if you want that contract, you meet their requirements, no matter how many people have access to it.
-
Sure I guess - such a requirement shows lack of understanding of security at a basic level to be sure. Personally would have no desire to do business with such a entity ;)
Since the gui is only available from specific physical connectivity. Have to be connected to the management network to access the gui.. Factor 1, then need password to access said web gui = factor 2. You now have MFA..
If you then say added some form of auth to get on said management network say 802.1x this is factor 3, etc..
But here per JimP last time this came up
https://forum.pfsense.org/index.php?topic=138601.msg758029#msg758029Install FreeRADIUS package. Setup users and Google Authenticator. Setup an entry in the Auth Servers for FreeRADIUS on Localhost. Set GUI to use the local RADIUS server for GUI auth. Done.
-
Sure I guess - such a requirement shows lack of understanding of security at a basic level to be sure. Personally would have no desire to do business with such a entity ;)
First of all, a 'password' is not a security, it's secret and it only works as long it kept secret within a group of people or yourself. It's a very outdated idea considering 'password' as a security measure. If the business thinking otherwise, they are actually doing better. It's the similar argument, if all the internal endpoints should also use SSL/TLS - it's a policy and for a number of good reasons, you like it or not.
Since the gui is only available from specific physical connectivity. Have to be connected to the management network to access the gui.. Factor 1, then need password to access said web gui = factor 2. You now have MFA..
Again, I think we are saying something, which s very outdated according to today's standard. What about internal threats from inside the network? what about a leaked password? What about the case when you need to give access to your management network to a number people from various part of the organization but all of them don't need to login to pfSense GUI? Another simple case, you running your VPN server from pfSense box, something happened out of hrs. and you need to access the pfSense console remotely? And when you say you can only have access to the GUI from VPN, what happens when VPN itself is down and you need to fix that going to web gui. Would you rely on just a password? And some organizations, simply don't just allow any web logins (internal or external) without MFA. I can give you a number of other examples, but that's a start if you really insist you donlt get the point.
Agin I think, you are confusing 'security' with 'secret'. A password CANNOT be the main sentry.
But here per JimP last time this came up
https://forum.pfsense.org/index.php?topic=138601.msg758029#msg758029Install FreeRADIUS package. Setup users and Google Authenticator. Setup an entry in the Auth Servers for FreeRADIUS on Localhost. Set GUI to use the local RADIUS server for GUI auth. Done.
Well that's definitely an option but not a native solution. Why people go through a comparatively harder way when a native solution can be developed and provided. The main reason, people try to bypass security b'cuz we make them so hard and complicated to implement. pfSence should really do the forward thinking rather holding on to some 80's security concepts, IMO.
-
" A password CANNOT be the main sentry. "
It isn't!!! The physical access to the management network is the MAIN security… Password is just one of the many factors involved in access to the web gui.
Physical control is always better than any sort of something you know or even have...
Lets add up the factors that might include. Enter the building. I can not enter my office without a fingerprint.. Something I AM... Just to get in the building.. Now to access the special network that can even access the firewall I have to HAVE my laptop.. This auths to network via 802.1x - so it has to be my laptop.. Something I have.. To login to MY laptop you have to have my tiks card.. So this is something else I have, but also something I know since you have to have the pin to access the certs on that card. Keep in mind that you can not just connect to any port in the building you have to be on the few limited admin ports. Only these ports once proper authed even have access to the management network.
You also need to know the password to my account to login to the laptop.
Now only then could you access the web gui of the firewall. Lets not forget you need to know its IP for management and port. Its not on any user network in the building that can access the web gui.
Then you need to know the gui password.
So how is that not MFA??? You want to add what Google authenticator to it? or some SMS text to your phone..
What I think is happening here is someone needs to check off some box that says MFA.. And doesn't really understand the whole concept of what that actually is.
Also that is built in.. Just install the package and set it up for whatever auth you want to use. its all just clickity clickity to set up.. If your checkoff sheet says oh you need to be able to do XYZ as your MFA then the sheet is pointless and doesn't understand the basic concept that makes up MFA...
If your web gui is accessible to even the normal internal network of your org then your doing it wrong in the first place..
-
Well that's definitely an option but not a native solution. Why people go through a comparatively harder way when a native solution can be developed and provided. The main reason, people try to bypass security b'cuz we make them so hard and complicated to implement. pfSence should really do the forward thinking rather holding on to some 80's security concepts, IMO.
What do you consider a native solution? Can you give an example?
-
Exactly… Like to hear this as well, since if you want to setup any sort of MFA on say cisco you need to point to a remote auth server and in this remote auth server you can setup different forms of MFA other than just a user name and password. Say some sort of fob like google auth, I personally use Authy myself where this sort of MFA make sense.
Ie services that have no access controls other than username/password - ie say your bank website, or your email site.. Ie the interface is open to the public..
Maybe the user would be happy with a walk through of how easy it is to say setup OTP to the gui? Even though I personally think its a waste of time - since the web gui to your firewall should always only be accessible via a controlled network.
Another way to accomplish MFA when remote to the firewall would be VPN as only way to access it. Where you now have multiple factors to access the vpn, even if remote.. Cert for example, even could setup OTP needed as well along with this, etc.
I have sneaky feeling only thing they might consider built in, is if you had a check box to click and it post up a QR code you could scan on your phone to setup your OTP.
-
I have sneaky feeling only thing they might consider built in, is if you had a check box to click and it post up a QR code you could scan on your phone to setup your OTP.
For Google Auth in the FreeRADIUS 3 package, it has exactly that. A QR code you can scan into the GA app.
Most other MFA setups require involving an external/central auth server or RADIUS specifically. It may be possible to bake in something like that without RADIUS but why reinvent the wheel when doing so offers no advantage?
It may happen eventually, but for the moment there isn't any compelling reason to spend manpower on reimplementing something that works fine as-is.
-
Yeah Jim but they have to do a bit of reading and click a few buttons ;)
And OMG they have to actually click the install for the freerad package.. So clearly its not built in… I think everyone should drop everything else they are working on and work on this. Because you know someone needs to check off a checklist that pfsense supports MFA without actually knowing what that actually means. But if there is a check box that gives them a QR code for their OTP then they can give it a checkmark ;)
Must be loosing 1000's of customers a day because of this...
Love to know what the OP thinks about the fact that google auth is just really another password.. But oh wait they call it a "shared secret key" ;) Be it a bit longer that is used for a math formula to generate a code based on time of day ;) So anyone with that "password" could generate the same code as well.. Not all that secure now is it when you think about it ;)
So when it comes down to it your talking about really just having 2 passwords vs 1.. So their MFA is just 2 things you know vs an actual other factor like something you have or are, or physical access, etc.
If I know the users password and whatever the super secret "shared secret key" is I have access.. Vs say having to have a physical access to a specific network that has multiple "passwords" you have to auth with. And something longer than than just a shared key..
Now I guess a cert could be seen as the same thing... But then your taking about a REALLY LONG password ;)
But hey have to check off that MFA check box now don't we... The 30 seconds you spend answering this thread you could of been working on setting up that check box ;)
-
Hi @ivor
Sorry for my silence. by 'native' I meant something like AWS Management Console, which you can enable/disable in the user settings area and once it enabled the only after MFA entry you get access to the console. Or something like ability to integrate some 3rd part application like DUO.I know you guys may not like the idea of having MFA but really like to see it's not just relying on a silly password only.
-San
-
This post is deleted! -
TOTP has become commonplace. sad this is still a reality in 2022...
RIP cybersecurity attestation forms as pfsense is natively uninsurable
-
You know you can do this via Freeradius using Google Auth or mOTP?
-
@stephenw10 I get that it's possible. It just feels unnecessary to have a dependency on the freerad package for this functionality.
-
@condescending_dev said in MFA for pfSense GUI:
@stephenw10 I get that it's possible. It just feels unnecessary to have a dependency on the freerad package for this functionality.
I don’t mean to stir up the discussion again, but it is a fact that cybersecurity insurance and company policies can become a pfSense showstopper because of MFA.
Yes, I know, install freeradius and do it that way, but you - like me - also know that there are several cases where that package stops running, doesn’t reinstall on upgrades and so on, and that just becomes a major problem if you are in uptime trouble as it is.
It would be nice if it was a backed in feature you could depend on in a standalone/isolated/no running packages situation as well.
-
@keyser said in MFA for pfSense GUI:
It would be nice if it was a backed in feature
I agree. I'll poke it further up the list if I can.
Steve
-
and just last week, we were stopped from using
pfSense
because we failed to demonstrate a meaningful MFA to login to the webConfigurator.We also failed to get Cyber Essential certificate (in UK) because of lack of MFA on the GUI.
We really need something sooner than later.
-San
-
If it were to be something considered in the future. Then please consider adding support for such things as FIDO/2. So that we could use hardware keys e.g. Yubikeys as well.
Please and thank you.
-
@macusers but why didnt you implement the suggestion asd outlined by @jimp
Use FreeRadius and Google Auth?I get where everyone is coming from - basically a standlone feature to do this but again....the feature technically exists now with the freeradius package. Im really not understanding the issue here. Use it or dont.
-
@michmoor said in MFA for pfSense GUI:
@macusers but why didnt you implement the suggestion asd outlined by @jimp
Use FreeRadius and Google Auth?I get where everyone is coming from - basically a standlone feature to do this but again....the feature technically exists now with the freeradius package. Im really not understanding the issue here. Use it or dont.
Because we have all tried doing upgrades :-)
Packages are supposed to install in the background, but that can occasionally fail - or cause issues, and then you are in big trouble if your physical console is a 1000 miles away.
Relying on a local installed 3rd party freeradius package for the second factor is a hen and the egg problem waiting to happen if you have any issues. -
@keyser if Radius fails isnt there a fallback to local auth then?
-
@michmoor said in MFA for pfSense GUI:
@keyser if Radius fails isnt there a fallback to local auth then?
and you back with no MFA again.
The thing, which is very hard for me understand: why it's so hard to acknwledge the issue and work towards a proper solution, rather than spending time convincinging people for a not-so-convenient work around.-San
-
@macusers ??? Im really not following here.
This is a problem enterprises have. I have TACACS and RADIUS deployed on my network gear. If my ClearPass servers fail, the fallback authentication method is local auth.
How is this any different here? Radius fails, local auth should be used. Is the assumption that no authentication should be used to manage a device if your central management platform fails? thats insane.. -
@michmoor said in MFA for pfSense GUI:
@keyser if Radius fails isnt there a fallback to local auth then?
If implemented correctly then yes, you should be able to configure that option. But as far as I remember, pfSense does not have this option - so the built-in admin either always works without MFA, or you do not have a fallback in case radius is down (because admin is disabled). I may be wrong here, but a couple of years ago I could not get it to work in a proper MFA certifiable way.
-
@keyser if pfsense does not have that ability then i agree in that MFA as implemented for the GUI portion is useless.
edit: i would argue that if i already have access to your firewall via https than the firewall having 2FA or not is moot. Im already in your environment and doing mysql dumps. -
@michmoor said in MFA for pfSense GUI:
edit: i would argue that if i already have access to your firewall via https than the firewall having 2FA or not is moot. Im already in your environment and doing mysql dumps.
I agree with that part, but again - it’s besides the point.
If you want cyber insurance, or it’s company policy, you need to demonstrate your Firewall is MFA auth only unless you have physical access. -
@keyser I will say this......
Palo Alto at my site and at most sites are set up the EXACT same way.
There is a radius account that your NetOps or Sysadmisn uses to log in. There is also a local account that you can use to log in that has nothing to do with radius. Both methods are permissible. I use local account sometimes because the way Panorama (Palo Alto) works is that some features are only available if you log into the device directly rather than using switching contexts
That being said what pfsense does is in no way different from how Palo Alto operates their software. Radius and Local auth are used at the same time. Nothing wrong with this.
edit: If the cyber insurance company doesnt understand the difference between 2FA and Local Account and how the software works then you are probably best not using that company anyway....
-
@michmoor said in MFA for pfSense GUI:
edit: If the cyber insurance company doesnt understand the difference between 2FA and Local Account and how the software works then you are probably best not using that company anyway....
That's not always an option.
What's the benefit of dictating the design?
-
@condescending_dev said in MFA for pfSense GUI:
That's not always an option.
What's the benefit of dictating the design?i dont understand your question?
Whats not an option? -
@michmoor going with another another company or forgoing compliance
-
OK...doesnt at all change the validity of my comment.
2FA operates correctly on pfSense.
Cyber insurance company thinks it doesnt. Sounds like a crappy cyber insurance company. -
What some of these folks need to understand is that most insurance and accreditation systems have some sort of compensating controls for when xyz is not 100% technically possible. Even when MFA is put in place...there is always some sort of disaster function that NEEDS to be simple username/password. Normal ops can be MFA 99.999% of the time; but technically there is a problem sometimes that requires a normal login. Disabling that normal login guarantees you that when hardware failures occur you will have a day/week of downtime instead of an hour of downtime.
I've worked 2FA for 17+ years. In my head it generally focuses around a chip card with a pin or some questionable biometric. I generally dislike the time based OTPs, even the good ones.
There is always still a password at some point. The biometric system is logged into by some trusted admin behind 3 locked doors...still a password in use. Chip cards that are linked against a private global authentication service tracking certificates for 3 million users ... still has some local login functions that utilize a simple password.
Stick a BIOS boot password on the device so it can't boot. Put that password on a piece of paper in a safe somewhere. Physical tokens don't necessarily have to be USB.
Then have a normal local console login.
The web gui for pfsense is a local console...it just looks nicer than the interface provided by ci$co switches. Protect it the same way.This comment from 4 years ago made me giggle then but I restrained myself then:
"What about the case when you need to give access to your management network to a number people from various part of the organization but all of them don't need to login to pfSense GUI?" ... this is both an organizational problem and a network engineering problem ... not a brute force accessibility or software problem.
-
Something like Duo is probably a better example here - where after using login ID/password you must also independently authorize the session - before actually being granted access. xOTP assumes that the init-secret+PIN and the means to generate the password haven't been compromised. (Plenty of malware/CNC to go around these days....). xOTP is nice but it provides no assurance that the owner authorized the use of their credentials at 3:47AM Thursday morning or use against an unrelated asset (from a process on one's corporate managed computer w/MDM and all the trimmings) while you were actually working on a VPN concentrator.
At the risk of stirring a hornets nest - if RADIUS is only serving the purpose of "enhanced" authentication, the configuration should be fairly vanilla. If it crashes under that circumstance - that's a whole different issue, otherwise there's always "Service Watchdog". (But yes - that does little for package re-installs. Came across the fact that BIND will not automatically re-install due to what appears to be some sort of naming issue when restoring a firewall config - going further to the point of re-install being viewed as a risk vs. something "built-in" being absolute).
Auditors would generally provide little quarter for the lack of password policy controls for local accounts (complexity, password expiration, history/re-use, etc.). Almost every modern platform that supports local accounts seems to have this functionality built-in to meet minimum compliance with corporate password policies (notably missing in pfSense). The fact that nothing prevents setting a password to a single character password, well.... Accounting for this in the built-in account subsystem should garner consideration for pragmatic reason (shouldn't require "justification").
As far as MFA, the topic could be debated at length. However, arguing a compliance requirement (especially if regulatory) with someone that has no "say", and is required to implement - serves no valuable purpose. Coming at things from an on-prem only perspective despite vast increases in work-from-home and movement to cloud, seems problematic to say the least (as it comes across as down-playing reality). Given jump box style access to control planes, often to prevent anything from being "brought in" or readily "extracted", combined with assets being placed on networks by bucket-ized purpose instead of "type" - yields potentially hundreds of admins with access to a given network. Not to mention the equally vast number of folks on the 'server' side that are responsible for the maintenance and security of those jump boxes. List goes on.. Such things as "physical security", 802.1x, "your laptop", etc. end up with little, if any meaningful value in such context, let alone if cloud-based. Do they help to cut down the noise - sure. Do they stop an intentional bad actor - no. (Those artifacts -might- have merit for some of the on-prem [only] environments, assuming that your account on your computer doesn't have any sort of malware/CNC that acts on your behalf running in the background, inherently bypassing all those factors once you're situated on the network). Even use of the 'correct' certificate doesn't provide assurance that you authorized the use of it. How would you know if some random asset had an access attempt, unless a separate process queried you via an alternate means to obtain grant/deny response for access to a resource (before actually granting access to the session)? Or are you keeping a personal record of intended logins and contrasting that with the auth logs of all reachable assets to determine (after it happened) that it happened? With the advent of so much critical infrastructure and so many applications being moved into the "cloud" from on-prem, it revealed new considerations - one of the benefits was transition of certain security aspects from [historically] reactive to proactive.
"On box" xOTP - the fact that the algorithm and keys would be stored in the same asset being accessed, in plaintext... At present, the granularity of permission and logging would be insufficient from an auditing perspective. The "mitigating controls" in that instance may likely be a bit horrifying. At a minimum, they'd need to be stored so that anyone else can't access/obtain them (including the PIN) and be user changeable without requiring admin permissions - its not "just" Administrators that require access these days, plus "Operators" should be limited to 'just' those permissions required for their role. Contrast that with a 3rd party broker where the control is authorization of "identity use" and handled via a separate process. Does FreeRadius answer the question - yes, but go a question deeper and it goes from being a solution to a significant finding.
In practice. authorization for "use of identity' occurs via an [unrelated] device using separate route/medium (example: cellular vs. through the firewall being accessed). The firewall connects to the broker awaiting response of grant/deny or time out (connection to broker is good but no grant/deny = deny) vs. no connection to broker may yield [failsafe] grant (or deny if so elected) - while the unrelated asset's app is notified (in the background) for user response within the app on the [unrelated] device, limited by a specific duration in which the user must respond for a "grant". Part of the protection is 3rd party record of the 'use of identity' authorization response - even the record of the request, in the first place. (auditability that can trigger review should a login occur without "use of identity" authorization)
Cloud introduces a litany of additional dynamics, where authorization of identity "use" inherently yields improved overall security posture vs. password "enhancements" (the ability to apply current, standard password policies should be sufficient for authentication purposes). OTP and related may look to improve (even simplify) authentication heuristics, but has no bearing on "Was that access actually initiated and intended by the purported party?" Thus, MFA in the common sense adds little to the equation [comparatively]. (In that regard, concur with the commentary on general MFA "value". However, the value of external authorization enhancements cannot be understated, especially with zero-trust).
Credentials and the litany of authentication factors serve to validate an identity or artifacts around the identity - they do nothing to express whether use of that identity for a given asset was intended by the owner of the identity.
-
Sometimes is difficult to understand the ask.
The ask for 2FA is not to have a 2FA as such, the ask is to be compliant.
We can argue all day long why it is stupid or irrational, but without 2FA it will not be compliant product period.
Without compliancy the insurance cost will be prohibitive and potential customers will be walking away.
Now see it from the manager point of view: Sysadmin is arguing that PFSENSE is the great product and better than any other in the market, but it is not compliant. You trust your sysadmin, but you cannot do what he is asking, due to business requirements.
And yes, if you are sysadmin and your preferable product is not compliant or it is very difficult to implement/support you will sadly agree with the manager and move on to Fortigate or so. -
@revamp said in MFA for pfSense GUI:
The ask for 2FA is not to have a 2FA as such, the ask is to be compliant.
How is it not compliant. Perhaps its the way you are explaining the requirement because we have gone back and forth on this. Maybe theres a miscommunication here?
-
2FA is required to be compliant regardless of the context. Even more, now is a trend to have 2FA also for console access(not only web UI).
-
@revamp LOL, Well as long as you are aware that Palo Alto, the number 1 security vendor in the world and Pfsense would fail your requirement. I guess Fortigate wouldn’t?
-
I can understand devs not wanting to dedicate time to something like mfa.. but with passwordless becoming hot and FIDO being one of the only truly hack resistant authentications these days it’s got be become a serious consideration. That or you’re not worth your weight any longer in this day and age.
I also wonder how some of these people became moderators reading their interactions on this thread. People like that only detract from the serious discussions about growing threats out in the wild today. Heaven forbid someone’s asset gets compromised on the inside by any number of means (want me to start listing the top ten right now that would bypass your precious ‘walled off security’ fallacy?) which totally opens your fracking gui to someone who shouldn’t have access.. the only way this arrogant moderator is correct in his statement about mfa being a waste of time and the restrict access to a management network makes sense even back in ‘18 let alone today is if your entire network is air-gapped.
Arrogant high horse know it alls like this guy are why people get misinformed these days. Leave your prehistoric assumptions back in 1999 where they belong and start paying attention to the new reality we live in. If a real hacker and not some random script kiddie wants in they will find a way in. Stop making it easier for them by wagging the dog..
Sorry for the rant.. but after three major incidents in five years I can no longer tolerate the ignorance people peddle out as greater knowledge. If it were not for FIDO adoption after the first attack I doubt there would still be a company standing.