RDP/RDS hardening (borrowed from another topic)
-
@scottalanmiller said in Production KVM server "hardening"?:
@Dashrender said in Production KVM server "hardening"?:
@scottalanmiller said in Production KVM server "hardening"?:
@Dashrender said in Production KVM server "hardening"?:
@scottalanmiller said in Production KVM server "hardening"?:
@Dashrender said in Production KVM server "hardening"?:
Doesn't his setup allow for two different authentications to be required? Assuming I'm right there, wouldn't that be another layer?
i.e. layer one creds (cert likely) at VPN
layer two creds (cert likely) at SSHYes, it has MFA. But you can have MFA on just SSH too. So while yes, you are correct that it does that, but not that it adds something special.
Well - MFA adds a third thing to the list of what I said.
No, it's already MFA. MFA is not an additional thing. You literally said "doesn't this allow for two different authentications", that's literally MFA.
Well then I meant three - the first logon to VPN (which is actually two verifications - creds and MFA) and then a - well I guess - third which is creds to SSH.
But then add three to SSH. Using totally unrelated technologies to layer authentication is valid, but a weird brute force method to get there. If your goal is just MFA, just do MFA in an elegant, efficient, easy way. Want two factor, do a key and passkey. Want a third, add Duo or Google Auth or Authy. Want a forth, text your phone or send an email. Want a fifth, do whatever forth one you didn't do. Want a sixth, have a script check that you are clocked in and at your desk. Want a seventh, do IP locking.
You can get more MFA factors from any one mechanism than you can use. VPN is often used to get MFA without someone realizing that that is what they were trying to accomplish or without realizing that that is where they are seeing the benefit. And because of that, because it's often done without any evaluation of what is really wanted, it rarely fits the need well. Is it MFA? Yes. Is it a good way to get that MFA? Not really. It's okay, but it isn't great. Lots of overhead to do something fundamentally pretty simple. And it makes the MFA location dependent (in most deployments.) You can bypass the MFA by changing your physical location. In most companies that do this, because they don't realize it is MFA that they are trying to do, they make it really easy to bypass the MFA for most people.
So how does this all fare against RDP/RDS?
Many don't want to publish RDP/RDS directly to the internet these days because the protocol has been bent over so badly several times.
Toss in the fact that a denial of service attack could be placed against users assuming a tie in to a centralized auth system with account lockout after x tries... -
@Dashrender said in RDP/RDS hardening (borrowed from another topic):
Many don't want to publish RDP/RDS directly to the internet these days because the protocol has been bent over so badly several times.
It has not, that's a myth to the best of my knowledge. RDP is super solid and secure. The issues come from clueless IT deployments blindly of something that they don't understand. As much as I'm not a Windows fan, I'm unaware of any specific vulnerability in RDP, only in people deploying it wrongly.
-
@Dashrender said in RDP/RDS hardening (borrowed from another topic):
Toss in the fact that a denial of service attack could be placed against users assuming a tie in to a centralized auth system with account lockout after x tries...
That's not a "toss in", that's the actual issue. Deploy RDP without that, and voila, key problems gone. Add proper MFA and voila, all problems gone.
We use RDP directly on the Internet all of the time, no issues. Because we know how to deploy it (e.g. we don't think of it as a magic black box and skip normal security oversight.) I still don't want to directly expose ANY key system, that goes without saying. But anytime you'd be okay exposing SSH, VPN, or other direct access method RDP is in the same ballpark.
-
@Dashrender said in RDP/RDS hardening (borrowed from another topic):
So how does this all fare against RDP/RDS?
It's the rule of general cases. There is no special case. RDP, SSH, HTTPS, VPN... they are all VPNs, just the payload is different. All rules always apply.
-
@scottalanmiller said in RDP/RDS hardening (borrowed from another topic):
It has not, that's a myth to the best of my knowledge.
Not a myth. It has been exploited more than once. Here is one I had a link for. Unauthenticated attacker could run code. Sure it is patched. Sure if you are up to date, you are likely very secure. But it most certainly is not a myth that RDS has not had issues.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0708
-
@JaredBusch said in RDP/RDS hardening (borrowed from another topic):
@scottalanmiller said in RDP/RDS hardening (borrowed from another topic):
It has not, that's a myth to the best of my knowledge.
Not a myth. It has been exploited more than once. Here is one I had a link for. Unauthenticated attacker could run code. Sure it is patched. Sure if you are up to date, you are likely very secure. But it most certainly is not a myth that RDS has not had issues.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0708
You beat me to it.
It's definitely been bent over, and more than just once I'm pretty sure. That in and of itself isn't an issue - nearly nothing software wise is perfect.
-
@scottalanmiller said in RDP/RDS hardening (borrowed from another topic):
@Dashrender said in RDP/RDS hardening (borrowed from another topic):
Toss in the fact that a denial of service attack could be placed against users assuming a tie in to a centralized auth system with account lockout after x tries...
That's not a "toss in", that's the actual issue. Deploy RDP without that, and voila, key problems gone. Add proper MFA and voila, all problems gone.
We use RDP directly on the Internet all of the time, no issues. Because we know how to deploy it (e.g. we don't think of it as a magic black box and skip normal security oversight.) I still don't want to directly expose ANY key system, that goes without saying. But anytime you'd be okay exposing SSH, VPN, or other direct access method RDP is in the same ballpark.
How does adding MFA prevent the lockout problem? Doesn't MFA only come into account if the correct password is entered?
Are you saying then - that you don't put account lockouts on login attempts because you have MFA as the safeguard against stuffing attacks? I mean, I guess - supposedly that should help (of course users become numb to phone notices and just approve anything there just like they click on anything that pops in a browser and infect themselves)...
Do you have a post on the proper way to deploy it and not have these issues?
-
@Dashrender said in RDP/RDS hardening (borrowed from another topic):
How does adding MFA prevent the lockout problem? Doesn't MFA only come into account if the correct password is entered?
That's not a factor of MFA. That's a factor of how the MFA is set up.
-
@Dashrender said in RDP/RDS hardening (borrowed from another topic):
Are you saying then - that you don't put account lockouts on login attempts because you have MFA as the safeguard against stuffing attacks?
No, I'm saying I don't authenticate RDP against the central master account system so that attacking the edge network is an attack against shared core accounts. This is one of those "people with AD see huge security problems that non-AD users often don't even realize would be there" type issues. Imagine a system without AD, account lockouts are typically trivial. It is AD, most of the time, that makes the idea of an account lockout a big problem.
-
@Dashrender said in RDP/RDS hardening (borrowed from another topic):
Do you have a post on the proper way to deploy it and not have these issues?
It's more of "there's a textbook 'how not to deploy it'" which is basically, don't deploy anything on an exposed edge that authenticates against a common core service. If you do that, you have to have many additional layers of protection on the edge. Otherwise, you can have the layers closer to the core. You still need the layers, but the issue with RDP is that typically people deploy it where it is not meant to be deployed and use it to bypass many layers of security.
-
@JaredBusch said in RDP/RDS hardening (borrowed from another topic):
Sure if you are up to date, you are likely very secure. But it most certainly is not a myth that RDS has not had issues.
I don't consider unpatched an issue - at least not an RDP issue. That's intentional. Everything... every VPN, SSH, you name it has some issues and if you decide not to patch them, those issues can't be blamed on the tech. Now, of course, all issues are unpatched at some time. But has patched RDP been exploited at some point? That's what I'm not aware of, and that's all that matters.
Running unpatched is the same or similar as using common Password123 type stuff. You can make anything insecure if that's the goal. And patching and good passwords I would say are so simple, so basic, and so beyond anyone being able to make an excuse to say that they didn't know that they needed to (even home users) that not doing them to me is the same as not closing the front door when you go to dinner or leaving the keys in the ignition. It's not the door or keys that failed.
-
@scottalanmiller said in RDP/RDS hardening (borrowed from another topic):
I don't consider unpatched an issue - at least not an RDP issue.
That one had an exploit live before it was patched.
-
@JaredBusch said in RDP/RDS hardening (borrowed from another topic):
@scottalanmiller said in RDP/RDS hardening (borrowed from another topic):
I don't consider unpatched an issue - at least not an RDP issue.
That one had an exploit live before it was patched.
oh okay, that's a serious issue then, for sure.
