RDP/RDS hardening (borrowed from another topic)
-
@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.
