The Myth of RDP Insecurity
-
@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?
-
Personally, I prefer to close RDP if possible and put it into VPN. Keep it open only if client insists, and even then try to limit to certain IPs only. Even though there is no documented case that RDP itself was to blame (other than recently discovered exploit, but for 2003 and XP, which are dead anyway), I just don’t like the idea of having it exposed. As @scottalanmiller said "the product is just believed to be insecure" and I feel that way.
Good read at https://blog.rapid7.com/2017/08/09/remote-desktop-protocol-exposure/ -
@carnival-boy said in The Myth of RDP Insecurity:
@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?
Azure always exposes RDP. They recommend you buy things from them, which is really just a vendor trying to upsell. MS' own documentation says that RDP is very secure. And since RPD has a VPN, it's a trick statement - they recommend a VPN, which RDP has so... voila. It's a handy way to promote selling their additional VPN service without actually stating that RDP is a risk or that RDP doesn't have VPN, they let people just assume.
Of course, I recommend not having any remote access open, and using state management which is way more secure than either.
-
@scottalanmiller said in The Myth of RDP Insecurity:
@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.
I'm not a big VPN fan, but they often can provide additional security that plain RDP does not. Client certificate authentication for example.
However, I agree that just wrapping RDP with a just password-secured VPN isn't providing additional value. -
Interesting topic.
I have wondered about this myself many times.
Would the VPN have mitigated these security exposures listed here:
https://blog.rapid7.com/2017/08/09/remote-desktop-protocol-exposure/
-
@spiral said in The Myth of RDP Insecurity:
Interesting topic.
I have wondered about this myself many times.
Would the VPN have mitigated these security exposures listed here:
https://blog.rapid7.com/2017/08/09/remote-desktop-protocol-exposure/
Probably, but so would proper maintenance. Essentially all real world RDP attacks are against unmaintained systems.
-
What's interesting with articles like this is they say things like "surely people aren't just exposing RDP, are there?" But let's ask that about VPNs. People aren't really exposing VPNs to the Internet, are they?
Of course they are. Why is it okay with VPNs?
-
Exactly.
That is why I was always curious about the argument.
Are "they" trying to make the argument that generally VPNs are developed using better security coding practices than Microsoft's development of RDP?
-
@spiral said in The Myth of RDP Insecurity:
Exactly.
That is why I was always curious about the argument.
Are "they" trying to make the argument that generally VPNs are developed using better security coding practices than Microsoft's development of RDP?
Something like that. It's a silly argument. Basically it's the "Windows people seem to distrust Windows" problem. People who use Windows the most start to develop this bizarre distrust of it. And the more that they become entrenched and feel that MS products are the only ones that you can use, the less that they trust them. It's a bizarre combination of things.
I'm not much of an MS fan, I use alternatives whenever possible. But mostly because I find them freeing, more flexible, cost savings, more polished; not because I think that MS products are bad or can't be trusted. I think that most MS products (Clippy not withstanding) are well made and very secure, but I choose what I find to be superior alternatives that cost less, that's all. So to me, to have people who are often religiously devoted to MS products also think that they are total garbage makes zero sense to me.
What's more, RDP is literally wrapped in a VPN so any logic as to the safety of a VPN applies to RDP as well.
-
@scottalanmiller said in The Myth of RDP Insecurity:
Something like that. It's a silly argument. Basically it's the "Windows people seem to distrust Windows" problem. People who use Windows the most start to develop this bizarre distrust of it. And the more that they become entrenched and feel that MS products are the only ones that you can use, the less that they trust them. It's a bizarre combination of things.
I’m on Linux side as much as possible. I deploy Windows servers only when there is no alternative solution. I might even say that I don’t trust Windows to that level to feel comfortable keeping RDP open.
So it’s quite opposite for me. -
@triple9 said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
Something like that. It's a silly argument. Basically it's the "Windows people seem to distrust Windows" problem. People who use Windows the most start to develop this bizarre distrust of it. And the more that they become entrenched and feel that MS products are the only ones that you can use, the less that they trust them. It's a bizarre combination of things.
I’m on Linux side as much as possible. I deploy Windows servers only when there is no alternative solution. I might even say that I don’t trust Windows to that level to feel comfortable keeping RDP open.
So it’s quite opposite for me.There are exceptions, of course, and people who avoid Windows and don't trust it, I understand.
-
@scottalanmiller said in The Myth of RDP Insecurity:
@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.
Agreed. The only thing I've changed in the past is port forwarding some random port, to 3389. Same reason why something like 2222 externally is forwarded to 22 internally.
-
@bbigford said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
@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.
Agreed. The only thing I've changed in the past is port forwarding some random port, to 3389. Same reason why something like 2222 externally is forwarded to 22 internally.
I don't even change that. It can lower the log count, but that's minor.
-
@scottalanmiller said in The Myth of RDP Insecurity:
@bbigford said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
@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.
Agreed. The only thing I've changed in the past is port forwarding some random port, to 3389. Same reason why something like 2222 externally is forwarded to 22 internally.
I don't even change that. It can lower the log count, but that's minor.
More preference than anything I think. One could say "but you could have attacks on a common port", but the same could be said for someone trying to attack 443; I'm definitely going to keep using 443.
There is one clear use case for port forwarding, and that's if you need to remote into many different hosts. But doing it that way is messy and I've only saw it worthwhile for education, where students remote into their workstations to complete classroom projects.
-
@bbigford said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
@bbigford said in The Myth of RDP Insecurity:
@scottalanmiller said in The Myth of RDP Insecurity:
@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.
Agreed. The only thing I've changed in the past is port forwarding some random port, to 3389. Same reason why something like 2222 externally is forwarded to 22 internally.
I don't even change that. It can lower the log count, but that's minor.
More preference than anything I think. One could say "but you could have attacks on a common port", but the same could be said for someone trying to attack 443; I'm definitely going to keep using 443.
There is one clear use case for port forwarding, and that's if you need to remote into many different hosts. But doing it that way is messy and I've only saw it worthwhile for education, where students remote into their workstations to complete classroom projects.
Yes, if you are using it for port management, then it makes sense.
-
Scott, in a previous thread you wrote "the general thinking in many cases is that you put a VPN aggregator at the edge and expose nothing else, only that. I'm not saying that's some magic answer, but it is the "LAN Security Model" that is why VPNs were really created."
Does that thinking apply here at all, or am I missing the point? Exposing an RDP port of a Windows Server directly to the internet - so there's no authentication at the perimeter? Why is that a good idea here? I accept that RDP is essentially the same as a VPN, but isn't the difference in where the authentication takes place rather than the model itself?
