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?
-
@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?
-
@carnival-boy said in The Myth of RDP Insecurity:
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?
Mostly because that's the LAN security model. He's advocating, here at least, for a LAN-less model in which you harden the endpoint and have zero trust to anything on the network.
-
@carnival-boy said in The Myth of RDP Insecurity:
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?
RDP does have authentication. It's SaaS. Secured like anything else that you would secure.
A VPN is the same as RPD (literally, they are identical technology for security both in encryption and authentication because RDP literally uses a VPN) so wither you are exposing RDP's own VPN directly to the Internet or some random third party VPN directly to the Internet, you are doing the same thing.
-
@carnival-boy said in The Myth of RDP Insecurity:
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?
No, not authentication in a different place. Under some circumstances the difference would be that you authenticate twice, which if we use two totally disconnected schemes, and two totally different technologies, is certainly going to increase security as long as your users don't rebel.
But using a VPN to do that requires a deep understanding of the RDP model and a specific approach designed to approach the security with that disconnection in mind. Then, at least, you can remove the "overlap" problem.
But you don't do this with any other technology, even ones not secured to the degree that RDP is. So this seems like something that doesn't make sense under any normal conditions and, if it did, there are way more effective ways to secure RDP even further (limiting login attempts, temporary IP locking, etc.)
The encryption portion of the second VPN is essentially worthless, that's not the concern. It's just "doubling up" the authentication piece, which can be improved, much more easily in other ways.
-
@coliver said in The Myth of RDP Insecurity:
@carnival-boy said in The Myth of RDP Insecurity:
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?
Mostly because that's the LAN security model. He's advocating, here at least, for a LAN-less model in which you harden the endpoint and have zero trust to anything on the network.
Correct. Just secure RDP properly, and then the secondary VPN is really pointless.
-
OK. I was only thinking in terms of the LAN and VPN authentication on the firewall, rather than just opening ports up on the firewall to let all traffic on those RDP ports through to the LAN.
-
@carnival-boy said in The Myth of RDP Insecurity:
OK. I was only thinking in terms of the LAN and VPN authentication on the firewall, rather than just opening ports up on the firewall to let all traffic on those RDP ports through to the LAN.
That's what the RDP system is doing already, just with the port open to it. A VPN needs a port open for it, or the equivalent (not all are TCP.) Any technology like this has to have the ports open in order for the initial authentication. Whether it is the RDP port, the VPN port, something has to be open for you to connect.
-
Well I am convinced now
VPN is not equal 
https://www.bleepingcomputer.com/news/security/many-vpn-providers-leak-customers-ip-address-via-webrtc-bug/ -
@dbeato said in The Myth of RDP Insecurity:
Well I am convinced now
VPN is not equal
https://www.bleepingcomputer.com/news/security/many-vpn-providers-leak-customers-ip-address-via-webrtc-bug/LOL, those are "VPN Providers" which is that weird "Consumer VPN" scam thing that everyone sells these days.
-
Personally, I always thought the OpenVPN certificate was good second factor to the RDP username and password access. Thinking this would reduce AD account lockouts in relation to AD accounts which also had RDP access.
Isn't there some value in using two separate authentication systems in a multi-factor arrangement?
-
@spiral said in The Myth of RDP Insecurity:
Personally, I always thought the OpenVPN certificate was good second factor to the RDP username and password access. Thinking this would reduce AD account lockouts in relation to AD accounts which also had RDP access.
Isn't there some value in using two separate authentication systems in a multi-factor arrangement?
Some value, certainly. But it there is specific value to that it seems that we must apply that universally and not tied to RDP in any way.
-
@spiral said in The Myth of RDP Insecurity:
Personally, I always thought the OpenVPN certificate was good second factor to the RDP username and password access. Thinking this would reduce AD account lockouts in relation to AD accounts which also had RDP access.
Isn't there some value in using two separate authentication systems in a multi-factor arrangement?
There is. But those are issues around the username and password being used for RDP. It has nothing to do with the security of the RDP session itself.
