The Myth of RDP Insecurity
-
@nashbrydges said in The Myth of RDP Insecurity:
One benefit that's overlooked in your comment is that, when accessing RDP via a VPN, you can eliminate a lot of "noise" from logging and IPS/IDS platforms if you can eliminate all of the random attempts at accessing RDP once it's exposed to the internet. Sometimes, that's enough benefit to make VPN very nice to have. The alert fatigue is very real and with the VPN wrapper method, at least when you get a hit on an attempt at RDP, you know it may be worth investigating.
Are those logs you really need to watch, though? What are you looking for there? Anything worth watching for should be automated.
-
@nashbrydges said in The Myth of RDP Insecurity:
If you have fixed remote IP addresses accessing RDP then you can choose to mute the alerts from those IPs to reduce alert fatigue but not likely something I'd recommend.
I would always recommend. Never get alerts you then ignore. Not in volume. If you ever feel alert fatigue, you have a problem that must be addressed. Too many alerts is worse than none, because both result in inaction but one is free and one is costly.
-
@scottalanmiller said in The Myth of RDP Insecurity:
@nashbrydges said in The Myth of RDP Insecurity:
One benefit that's overlooked in your comment is that, when accessing RDP via a VPN, you can eliminate a lot of "noise" from logging and IPS/IDS platforms if you can eliminate all of the random attempts at accessing RDP once it's exposed to the internet. Sometimes, that's enough benefit to make VPN very nice to have. The alert fatigue is very real and with the VPN wrapper method, at least when you get a hit on an attempt at RDP, you know it may be worth investigating.
Are those logs you really need to watch, though? What are you looking for there? Anything worth watching for should be automated.
Totally agree. They are automated. Alerts are difficult to automate when your source IP is dynamic so when you get a hit that there are attempted logins to RDP, I tend to want to be sure to look at what's happening.
-
Things like port locking will stop the logs, too.
-
@scottalanmiller said in The Myth of RDP Insecurity:
port locking
That's not always a viable solution though so, what else would you suggest can be done to reduce alerts in those cases?
-
@scottalanmiller What about directly exposing RDP for a user's desktop computer?
Say for instance CEO or COO dont like using vpn, open rdp to their desktop on firewall? -
@scottalanmiller said in The Myth of RDP Insecurity:
I know the
site there is this persistent myth that RDP is insecure and that the solution to its insecurity is to wrap it in a VPN. This seems very silly as RDP is natively VPN'd already. If a VPN provided security, surely the very well researched and secured VPN that is integrated with RDP would be the best choice. That VPN is already completely "shrunk" to expose nothing but RDP, which of course you can do manually with some other VPN solution, but requires much more work and is a "one off" rather than a well known, battle tested configuration.Azure itself exposes RDP directly because it is considered extremely secure. It's roughly identical to SSH in security. Of course, exposing "nothing" is better than exposing "something", but the option there is to close down the services completely, not to wrap either in "yet another VPN." Things like port locking, port knocking, only opening when needed, and so forth add some serious security on top of the existing security mechanisms, but a VPN wrapper is just redundant.
Where does this idea come from? This feels, to me, to be one of those "Windows Admins who distrust Windows" myths where there is an irrational distrust of Microsoft and the product is just believed to be insecure. We hear stories, on the spicy site of course, of people constantly getting hacked through RDP... of course they are, if you expose it with common usernames and weak passwords, any VPN will get hacked. But, as people usually do, they accept no blame and no one is willing to point out the obvious faults in the setup as professional review is discouraged there, and people point fingers at an innocent vendor who could only defend themselves by throwing customers under the proverbial bus.
But honestly, has anyone ever heard of an actual hack of RDP? One where the end users didn't leave it wide open in a way that would have compromised any service? VPNs are only as secure as the passwords that you put in front of them.
RDP is very secure and there is no need for additional security around it. Just standard good security practice and it is as secure as anything is reasonably going to get. If you need something more secure, you can't be exposing anything like this to the outside world.
What would you describe as an actual hack of RDP? What does that mean, end users leaving it wide open?
-
I have always open RDP to WAN externally through firewalls but only reducing to location that need access (whitelisting) instead of using VPN, VPN for anyone else has been recommended by me since I have no idea what type of security they will have.
-
RDPGuard is the only solution that allows some kind of rate limiting functionality on RDP that I'm aware of. Any other solutions?
-
@nashbrydges said in The Myth of RDP Insecurity:
RDPGuard is the only solution that allows some kind of rate limiting functionality on RDP that I'm aware of. Any other solutions?
It is same as what SSHguard, a lot of protocols get brute force attacks.
-
How practical is this?
Setting up a vpn and turning on rdp for user desktops = easy.
Setting up policies in firewall for each Remote Desktop user = PITA. -
@nashbrydges said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
port locking
That's not always a viable solution though so, what else would you suggest can be done to reduce alerts in those cases?
What makes it not always viable?
I know Sodium is working on a solution specifically to make that "always viable"
-
@momurda said in The Myth of RDP Insecurity:
@scottalanmiller What about directly exposing RDP for a user's desktop computer?
Say for instance CEO or COO dont like using vpn, open rdp to their desktop on firewall?Absolutely. The VPN makes no difference. RDP already has a VPN, so if a VPN was good enough, RDP is good enough.
-
@scottalanmiller What about things like Chrome Remote Desktop which does this in a web browser?
-
@dbeato said in The Myth of RDP Insecurity:
What would you describe as an actual hack of RDP? What does that mean, end users leaving it wide open?
An actual RDP hack would be one where RDP was hacked (broken in through a vulnerability or breaching the encryption), not one where the users used "password" as their password, didn't have account lockouts, or published the login info, for example.
-
@nashbrydges said in The Myth of RDP Insecurity:
RDPGuard is the only solution that allows some kind of rate limiting functionality on RDP that I'm aware of. Any other solutions?
Your firewall can potentially do that, too.
-
@dbeato said in The Myth of RDP Insecurity:
@nashbrydges said in The Myth of RDP Insecurity:
RDPGuard is the only solution that allows some kind of rate limiting functionality on RDP that I'm aware of. Any other solutions?
It is same as what SSHguard, a lot of protocols get brute force attacks.
And fail2ban.
-
@momurda said in The Myth of RDP Insecurity:
How practical is this?
Setting up a vpn and turning on rdp for user desktops = easy.SO practical.
Just... don't set up the VPN. It's that easy. What is the VPN doing? You already have a VPN, the extra VPN just confuses users.
-
@momurda said in The Myth of RDP Insecurity:
@scottalanmiller What about things like Chrome Remote Desktop which does this in a web browser?
Totally different technology, but pretty secure from what I know. That it uses a web browser really isn't much of a factor as it is just using the browser for display purposes. You can do that with RDP, too.
-
You have to make a separate firewall policy for each computer using RDP.
I have 40 users. Some of them refuse to use vpn so i have setup RDP this way for awhile.
It certainly isnt practical.
