MFA for pfSense GUI
-
@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. -
TrueNAS supports 2FA natively, so it doesn't seem that hard to implement assuming it meets "requirements."
Not sure why there is so much resistance by Netgate and/or its "representatives." The only problem is most MFA methods assume you have cell service and/or physical access.
-
You can set up static IP access also. Mine only specific IP/MAC addresses can access the firewall GUI
-
@ivor one that does not allow you to skip the MFA part and still allows you to login with admin account without MFA
-
All,
FYI, OPNsense currently offers support for multiple forms of MFA authentication throughout the entire system (with one notable exception being console/ssh access).
Supported services are:
-OPNsense Graphical User Interface
-Captive Portal
-Virtual Private Networking - OpenVPN & IPsec
-Caching ProxySince the PFSense devs seem to think that because you login to your laptop with a username/password and the PFSense GUI interface also requires a username/password, that counts as MFA (no that does not).
Guess it's time to switch?Can't believe that this is even a discussion.
-
It isn't, this thread is over a year old.
-
S stephenw10 locked this topic on
