MFA for pfSense GUI
-
@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
pfSensebecause 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?
Firewall: NetGate,Palo Alto-VM,Juniper SRX
Routing: Juniper, Arista, Cisco
Switching: Juniper, Arista, Cisco
Wireless: Unifi, Aruba IAP
JNCIP,CCNP Enterprise -
@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?
