The Myth of RDP Insecurity
-
@jaredbusch I totally agree. I would rather deal with 1 port vs potentially 50 to 100.
-
Actually scratch that, I forgot I'm suppose to be pushing to get off of Quickbooks (LAN based) and move to Quickbooks Online. I personally don't like either, but at least with the online they do spend more time developing it and keeping it semi-modern.
-
@krisleslie said in The Myth of RDP Insecurity:
So Scott, in my network we use RDP (obviously) but I'm an open to using other tools such as Chrome Remote Desktop, Team Viewer and even CloudBerry Remote Assistant. They all do a good / decent job imho.
Nothing wrong with RDP, it works very well.
-
@krisleslie said in The Myth of RDP Insecurity:
@jaredbusch I totally agree. I would rather deal with 1 port vs potentially 50 to 100.
If that was the sole factor, yes.
-
@krisleslie said in The Myth of RDP Insecurity:
In my case I plan on having 2 RDS farms, one for the financial side and one for the staff side and eventually a 3rd for our students. In theory it's almost cheaper for me to work on handful of servers and add our proper licensing than to even consider doing VDI which by the way thank you for your advice early on, it's crazy expensive even with non profit provisions!
So this is RDS, which makes things much easier. With a gateway, you can make this all appear as one. Without a gateway, this would only appear as two ports. Still not much to manage. The example of having loads of different ports is when dealing with things like direct RDP to every individual's physical desktops.
-
@scottalanmiller I could still see how if you didn't setup a RDS server, a Powershell and remote access to the registry can accomplish this. Of course it would be "fun" to write it, but after that one hard time automating it wouldn't be so hard.
Just pull a list of all computers in AD and focus on a group, then change their ports. If there is a way to automate the usage of #'s then you could setup a string to change a list of pc's ports similar how we use MDT with computer naming conventions.
-
@krisleslie said in The Myth of RDP Insecurity:
@scottalanmiller I could still see how if you didn't setup a RDS server, a Powershell and remote access to the registry can accomplish this. Of course it would be "fun" to write it, but after that one hard time automating it wouldn't be so hard.
Just pull a list of all computers in AD and focus on a group, then change their ports. If there is a way to automate the usage of #'s then you could setup a string to change a list of pc's ports similar how we use MDT with computer naming conventions.
Don't need to change anything in Windows. Only need to change the port mapping on the firewall. So a simple script that talks to SSH on the Ubiquiti and you'd be good. You'd only need a trivial script and a simple list to maintain.
-
One thing to think about is that this might change who has access to create accounts that can access the system externally. i.e. now every local admin has that power, when with a VPN that power might be a bit more naturally contained. Also, depending on the VPN setup, IT will create VPN user passwords themselves and thus have direct control of their complexity. Although users tend to prefer a SSO VPN method.
However, there is often a disconnect in the VPN strategy. The LAN is trusted, but then unmanaged, untrusted systems are allowed full access to the LAN via the VPN. It doesn't make sense.
The bottom line is that any method used need to be thoroughly thought out and planned. Personally, I think would like to have at least 2 step authentication.
-
@flaxking said in The Myth of RDP Insecurity:
One thing to think about is that this might change who has access to create accounts that can access the system externally. i.e. now every local admin has that power, when with a VPN that power might be a bit more naturally contained.
Not really. Local admins can't open the outside firewall ports. And who is creating local admins? Any anyone that can create an RDP session because of their admin rights, can also create a VPN through those same rights.
-
@flaxking said in The Myth of RDP Insecurity:
Also, depending on the VPN setup, IT will create VPN user passwords themselves and thus have direct control of their complexity.
But that power exists with RDP, as well. Remember RDP has a VPN built in, so anything you can do with a VPN, RDP natively can do.
-
@flaxking said in The Myth of RDP Insecurity:
However, there is often a disconnect in the VPN strategy. The LAN is trusted, but then unmanaged, untrusted systems are allowed full access to the LAN via the VPN. It doesn't make sense.
Yes, there is a huge risk that the "add on" VPN actually become a security problem, rather than a security solution. If carefully managed, it can be "additional" security. But as commonly used, it is a massive risk.
-
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
One thing to think about is that this might change who has access to create accounts that can access the system externally. i.e. now every local admin has that power, when with a VPN that power might be a bit more naturally contained.
Not really. Local admins can't open the outside firewall ports. And who is creating local admins? Any anyone that can create an RDP session because of their admin rights, can also create a VPN through those same rights.
In a basic RDP setup, the ports are already open and mapped. The concern wouldn't be someone maliciously creating a way into the system, but someone accidentally doing it.
For example, if tier 1 support has local admin privileges on workstation, maybe they shouldn't be trusted with the power to accidentally create user accounts with external access permissions.
I would love to see a practical how-to on securely setting up external access with minimal resources.
-
@flaxking said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
One thing to think about is that this might change who has access to create accounts that can access the system externally. i.e. now every local admin has that power, when with a VPN that power might be a bit more naturally contained.
Not really. Local admins can't open the outside firewall ports. And who is creating local admins? Any anyone that can create an RDP session because of their admin rights, can also create a VPN through those same rights.
In a basic RDP setup, the ports are already open and mapped. The concern wouldn't be someone maliciously creating a way into the system, but someone accidentally doing it.
This may be true for the Windows desktop, but it is only true when administration rights have been given, and RDP is enabled. It requires two steps, the first of which is the actual problem (giving someone who is not a proper, trained admin the task of overseeing security on a system) and the second is very intentional.
But that's as far as it goes. The system would still not be accessible for actors outside of the LAN because it would not open ports on the network firewall.
-
@flaxking said in The Myth of RDP Insecurity:
I would love to see a practical how-to on securely setting up external access with minimal resources.
If you only need to expose a single RDP "server" to the outside, the necessary settings for a normal environment are trivial. Setup up RDP as normal, use proper password and account security, add singular port mapping from network firewall to RDP "server". That's it.
For more security, of course IP locking and such is not hard, but might not be warranted.
-
I also use Cyberarms Intrusion Detection.It works well
-
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
I would love to see a practical how-to on securely setting up external access with minimal resources.
If you only need to expose a single RDP "server" to the outside, the necessary settings for a normal environment are trivial. Setup up RDP as normal, use proper password and account security, add singular port mapping from network firewall to RDP "server". That's it.
For more security, of course IP locking and such is not hard, but might not be warranted.
I believe more security is required in order to mitigate the risks caused by things that are difficult to control.
For example, user created passwords. I'd guess that 80% of user passwords that user's aren't reusing from somewhere else contain the business name. Requiring long passwords might be a way to help mitigate this, but practically speaking, a lot of IT pros would get major push back from management if this was implemented. I'm not saying management would be right to push back since they're not providing the budget for a more secure solution, but that's the reality of many SMB. In their eyes, availability tanks.
In that situation I would not be comfortable with putting forth direct RDP as an option.
-
@flaxking said in The Myth of RDP Insecurity:
Requiring long passwords might be a way to help mitigate this, but practically speaking, a lot of IT pros would get major push back from management if this was implemented.
Right, but it is very important to understand then that the problem here is management determining that security is not to be implemented, not a problem with RDP.
If this policy is the case, then a VPN will not resolve it.
-
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
Requiring long passwords might be a way to help mitigate this, but practically speaking, a lot of IT pros would get major push back from management if this was implemented.
Right, but it is very important to understand then that the problem here is management determining that security is not to be implemented, not a problem with RDP.
If this policy is the case, then a VPN will not resolve it.
Right, agreed. Your main point in this thread is that RDP isn't the vulnerability. But practically speaking, you have to mitigate the risks surrounding it, and that's what I think a how-to would be good for, though it might need several different scenarios.
-
@flaxking said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
@flaxking said in The Myth of RDP Insecurity:
Requiring long passwords might be a way to help mitigate this, but practically speaking, a lot of IT pros would get major push back from management if this was implemented.
Right, but it is very important to understand then that the problem here is management determining that security is not to be implemented, not a problem with RDP.
If this policy is the case, then a VPN will not resolve it.
Right, agreed. Your main point in this thread is that RDP isn't the vulnerability. But practically speaking, you have to mitigate the risks surrounding it, and that's what I think a how-to would be good for, though it might need several different scenarios.
You do, but I think the point is that you can't mitigate them with a VPN, which is the normal assumption. RDP isn't really vulnerable, it's not RDP risks that need to be mitigated. And RPD contains an extremely secure VPN, so a VPN can't be the solution. There can be risks, but they are from other tech or organizational risks and mitigations are to those risks, not to RDP risks. Those risks remains, such as weak passwords, whether RDP is used or not.
-
@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...
Azure itself exposes RDP directly because it is considered extremely secure.The Azure portal says "RDP port 3389 is exposed to the Internet. This is only recommended for testing. For production environments, we recommend using a VPN or private connection."
I'm struggling to reconcile this statement with your post, unless I'm missing something?
