Downsides of Direct RDP over Internet

Forums › IT Pro and developers › Downsides of Direct RDP over Internet

Paul1977

5047 posts

Uber Geek

#285970 28-May-2021 09:43

This is a followup from an earlier post about Wireguard VPNs, but it got me wanting to understand better why some things are considered best practice and others aren't.

The recommended approach for RDP is to use a VPN, and then RDP over that. Makes perfect sense. Wireguard is great for almost everything I need, but I have one scenario where it's a little problematic.

So I'm curious as to what the security implications of the following possible setup might be?

Perimeter firewall appliance forwards a non-standard port to 3389 on internal RDP host.
Perimeter firewall appliance drops all external connection attempts to the exposed port, except for known trusted public IPs.
RDP host requires NLA.
RDP host has account lock-out policy.

The consensus on Google and @michaelmurfy agree that it's not a preferred method, but I'm yet to find a full explanation of exactly why not.

I'm not looking for suggestions for alternatives (I know what they are), just a better understanding of the above.

Thanks

EDIT: 4000th post!

Home: Work:
Home Work

1 | 2 | 3

3867 posts

Uber Geek

ID Verified

Trusted

Lifetime subscriber

#2714354 28-May-2021 10:02

It's about the level of risk you are happy to accept, and layers of security to reduce that risk. If one layer fails due to a technical limitation or misconfiguration, you need something else to have your back.

Non-standard port is meh these days. RDP is relatively easy to discover on any port. I saw a machine in the last week on a non-standard port that had been under a brute force attack for days with one attempt every three seconds. The security log was full so the user had no idea how long the attack had been going for.
Limiting to known trusted IPs is excellent. If someone messes with the rules accidentally, there needs to be additional protection.
NLA - great but a shame it does not let you use something like RDPGuard to alert/block IPs trying to brute-force.
Lockout - great but does not apply to some domain admin accounts.

You have an above-average level of protection. I'd encourage you to put in place a 'how do I know this is still protected' strategy, particularly around the IP protection.

“Don't believe anything you read on the net. Except this. Well, including this, I suppose.” Douglas Adams

Referral links to services I use, really like, and may be rewarded if you sign up:
PocketSmith for budgeting and personal finance management. A great Kiwi company.

michaelmurfy

meow
13257 posts

Uber Geek

Moderator

ID Verified

Trusted

Lifetime subscriber

#2714357 28-May-2021 10:06

Take a look at Apache Guacamole instead: https://guacamole.apache.org/

This can run inside Docker but gives a way of having secure remote access. If you also add another layer of security on-top of it (eg - Cloudflare Access) or Mutual Auth Certificates this may be more what you're after.

Otherwise Anydesk is more secure than RDP as it doesn't require port forwarding.

The reason why I don't recommend anyone port-forward RDP is we've seen some rather serious exploits over the last few years and RDP is one of those things that shouldn't be exposed to the internet, ever. If you fudge a firewall rule for example and your RDP server gets pwned so does your host, and your entire network. This is why you should always use a VPN or a product like Apache Guacamole instead for RDP.

Michael Murphy | https://murfy.nz
Referral Links: Quic Broadband (use R122101E7CV7Q for free setup)

Are you happy with what you get from Geekzone? Please consider supporting us by subscribing.
Opinions are my own and not the views of my employer.

modcar

74 posts

Master Geek

#2714366 28-May-2021 10:17

Speaking from experience - I had a non-standard port forwarding to 3389 on my home office pc. Added it as a temp thing, forgot to remove it.

I have a domain controller with lockout after 3 incorrect passwords. Someone/something RDP'd to my pc, logged in as a user with an easy password, and encrypted everything on my pc. fortunatly I had backups of anything important, so I just reinstalled Windows.

Either connect by VPN first or use something like Anydesk or Teamviewer (though, teamviewer will boot you off after a while of using the free version)

Paul1977

5047 posts

Uber Geek

#2714461 28-May-2021 11:26

Thanks for the replies.

@Dynamic I know a non-standard on it's own port does very little these days, but wouldn't having it locked down to a trusted IP(s) prevent discovery of this port and any access to it? Wouldn't a brute force attack have to come from a trusted IP (very unlikely), and with a lockout policy would be ineffective anyway? This particular scenario wouldn't be using domain admin users, but I'll look into that just out of interest.

@michaelmurfy I'll have a look into Guacamole, but my Linux isn't great. I fully understand not recommending port-forwarded RDP because of the number of exploits that have been discovered (I generally wouldn't recommend it either). However, as above, if it's locked down to trusted IPs doesn't that effectively block the ability to take advantage of any exploit (except by an attacker at the trusted site - again very unlikely)?

@modcar I wasn't considering port-forwarding (non-standard or otherwise) that would be available to any host on the Internet.

Don't get me wrong, I'm definitely a proponent for VPNs. But (assuming I don't mess up the firewall rules) I still don't understand why a port-forward in the manner I described is less secure. Is it simply because there's more potential for a configuration error on the firewall leaving it vulnerable? Or are RDP exploits still somehow exploitable?

Anydesk or Teamviewer are certainly options, but at the moment I really just want to understand the drawbacks of port-forwarded RDP as described above (just for my knowledge if nothing else). Other than possible firewall misconfiguration, I'm still not understanding where the vulnerability lies?

Andib

1364 posts

Uber Geek

ID Verified

Trusted

#2714463 28-May-2021 11:31

Directly exposing RDP to the internet is never going to be "safe". The correct way to do it using native Windows tools without a VPN is an RD Gateway as this removes the (vulnerable) RDP protocol from being directly exposed.

If you're happy with the risk of having it exposed, Whitelisting to specific IPs using the firewall (NOT Windows Firewall) is probably the safest option.
Install 2FA like DUO so that if you are brute forced you have another layer of protection.
NLA & Non standard ports aren't going to help you much from an internet perspective.

<#
.DISCLAIMER
Anything I post is my own and not the views of my past/present/future employer.
#>

Paul1977

5047 posts

Uber Geek

#2714475 28-May-2021 11:55

Andib:

@ Andlid Directly exposing RDP to the internet is never going to be "safe". The correct way to do it using native Windows tools without a VPN is an RD Gateway as this removes the (vulnerable) RDP protocol from being directly exposed.

If you're happy with the risk of having it exposed, Whitelisting to specific IPs using the firewall (NOT Windows Firewall) is probably the safest option.
Install 2FA like DUO so that if you are brute forced you have another layer of protection.
NLA & Non standard ports aren't going to help you much from an internet perspective.

Yes, everything I read agrees with what you're saying, but I can't find an explanation of why. Obviously just exposing it to the whole Internet would be very vulnerable, but what vulnerabilities are left if it's locked down to specific IPs?

I couldn't begin to decide if I'm "happy with the risk" when I don't understand what risk is left.

Isn't the argument basically that port-forwarded RDP is vulnerable becuase of XYZ reasons, but I don't see how what I've suggested hasn't eliminated those reason. So why is it still vulnerable?

jjnz1

1363 posts

Uber Geek

Lifetime subscriber

#2714511 28-May-2021 12:57

For those technically savvy I used to use direct RDP over port 65315, with a very strong password, until I found a more secure way.

Use reverse proxy so that port 443 is used
(Ie https://remote.yourdomain.com)
Use APACHE GUACAMOLE service (rdp over https)
Use strong password for Guacamole
ALSO tie Google authentication to your Web service (you need to be logged in to your google account, which includes 2FA, and this token is passed to your web service for authentication which then grants a specified user access to Guac)

Once set up, I have found it’s pretty good. Gets past most corporate firewalls too because it’s standard https traffic (including wifi at libraries)

Sharesies

Trade NZ and US shares and funds with Sharesies (affiliate link).

gehenna

8510 posts

Uber Geek

Moderator

Trusted

Lifetime subscriber

#2714513 28-May-2021 13:06

michaelmurfy:

Take a look at Apache Guacamole instead: https://guacamole.apache.org/

Any particular docker repo you recommend for this one on UnRAID? I see linuxserver has one called guacd. The other three options are repos I've not heard of.

michaelmurfy

meow
13257 posts

Uber Geek

Moderator

ID Verified

Trusted

Lifetime subscriber

#2714518 28-May-2021 13:22

@gehenna I would use the Linuxserver one on the first instance. It should be up-to-date.

Paul1977

5047 posts

Uber Geek

#2714520 28-May-2021 13:31

I'm going to have a better look at Apache Guacamole. Hopefully it's easy to setup and there's no issue putting on the same Raspberry Pi that already has Pi-Hole and PiVPN.

Would still love a clearer explanation of why my proposed RDP setup in the original post isn't considered as secure though.

Waspnz

3 posts

Wannabe Geek

#2714589 28-May-2021 14:09

My take on it is that it is because unauthenticated requests (including login requests) should never be allowed to reach your server/pc/device

This is due to the possibility that the protocol could be exploited due to a vulnerability (including future ones) or weak configuration. Yes this could be mitigated in other ways, such as patching, smart firewalls, bruteforce account lockout etc but these mitigations cannot ever be 100% guaranteed to work for the future (e.g. zero day vulnerabilities). There have been many high profile RDP vulnerabilities over the years, some fairly recently

The thinking is that the VPN service will be less likely to be vulnerable than RDP (and I agree with this) but a in-house VPN server can still be attacked - so there are more modern/better vpn ways nowadays

So, the current/new ideology is that you should authenticate yourself before being able to send data - hence the VPN, you log on and now you're trusted. But what if the VPN has a vulnerability? You also have to keep the VPN server up to date etc etc... so using a cloud managed service where the provider patches and maintains the VPN service instead of you. Also if the VPN service is under attack then your server/network (raspberry pi) isn't affected. Typically you authenticate with the provider before getting access to your servers - i.e. M$'s security gets beaten before a single packet gets to your server

Yes the VPN service provider could also be hacked, there could be some vulnerability that could be exploited but really that is a far better proposition than your home server being attacked. Make sure you have multi-factor authentication enabled so even should your password be stolen the attacker cannot log in. Also, as the VPN service has other customers, likely you will be a small target

Nothing is completely bulletproof/guaranteed but you can reduce your level of risk/likelihood of being compromised to a level acceptable to your budget/desired peace of mind

Edit: I see even though I've had this account for a long time it is actually my first post! For reference I'm a network engineer but focused on enterprise security these days

SpartanVXL

1317 posts

Uber Geek

#2714617 28-May-2021 14:20

Ok so the ‘why’ can’t be answered in this specific point of time, but if you want historic evidence look at CVE’s for RDP. Directly forwarding RDP leaves you exposed no matter how you set it up to whatever CVE that hasn’t been found out yet.

So the answer is to not directly expose RDP. As said before use something like Guacamole which exposes https instead or a VPN to connect in.

The whitelist of IP’s is just changes the level of security. It can significantly lower the chance of an issue happening as you drop a wide scope of entry, but there is still an avenue of attack which is the ‘trusted’ IP’s. If you consider how easy it is to avoid geoblock, it’s the same manner if somebody figures out you have a whitelist.

Beccara

1469 posts

Uber Geek

ID Verified

#2714622 28-May-2021 14:27

One of the major issues with exposing anything to the internet even if you have authentication on it etc etc is an underlying vulnerability that makes all that moot, in RDP's case think BlueKeep. 2nd/3rd/4thing the whole non-standard port thing is not really effective. If I had a gun to my head and had to put RDP on the net it would be with port-knocking in front of it so *something* was in front of it

Most problems are the result of previous solutions...

All comment's I make are my own personal opinion and do not in any way, shape or form reflect the views of current or former employers unless specifically stated

Yoban

447 posts

Ultimate Geek

#2714639 28-May-2021 15:17

gehenna:

michaelmurfy:

Take a look at Apache Guacamole instead: https://guacamole.apache.org/

Any particular docker repo you recommend for this one on UnRAID? I see linuxserver has one called guacd. The other three options are repos I've not heard of.

@gehenna (and others) here is a good video https://www.youtube.com/watch?v=TTFB2XEQQUU from SpaceInvader One on Unraid Setup of Guacamole

Waspnz

3 posts

Wannabe Geek

#2714640 28-May-2021 15:22

So was re-reading your original post and focussed more on this bit "except for known trusted public IPs". Assuming you mean to configure your router's firewall to only allow connections from your known public IP (whitelist):

Specifically I would still not use RDP in this case because there is malware (older, now supposedly patched, vulnerabilities but likely there will be more in the future too) that can spread via RDP to your network should that trusted IP become infected. A malicious actor could get inside the trusted IP's network, observe the RDP connections and decide to attack you too

Regarding the VPN server, if you host your own I would still restrict access to just the trusted IP and use multi-factor authentication

1 | 2 | 3