4 ms·

RDP uses a single port so opening a port on the public IP NAT for RDP is trivial, however it's always best to hide RDP behind a VPN. This security rule applies

RDP uses a single port so opening a port on the public IP NAT for RDP is trivial, however it's always best to hide RDP behind a VPN. This security rule applies to pretty much any remote access protocol, which you should avoid having listening on the open Internet.

hunter2_ 7y ago
I'm all for defense in depth generally, but if a use case demands the convenience of not having this extra step, can't various application protocols be made as tough as a VPN to crack? At that point the VPN just adds obscurity. Wrapping insecure legacy protocols, like SMB for example, with a VPN is absolutely required.
- Spivak 7y ago
  The step of flipping a switch to connect to a VPN isn’t that bad. Googles IAP is in a lot of ways more annoying since you end up having that step multiple times. It’s not really the protocol that people are worried about — it’s attack surface. VPNs have basically zero — everything is opaque and an attacker learns nothing except that you’re on a VPN by observing your traffic. An attacker doesn’t even know that the application you’re connecting to exists and can’t even reach it to break in it without first breaking into your VPN. You can call this obscurity but I think it’s better to say that you’re not leaking side-channel information about your network. Having a VPN isn’t an excuse to have poor network security internally but a single portal that’s internet facing is much more defensible than n different home-grown apps.
- Timothycquinn 7y ago
  I often maintain hard white list for remote services when VPN is not an option. A cool option that does not have much implementation out there is using port knocking to open ports on demand. If the scheme is dynamic, it could be virtually impenetrable. Another way to go is to have a web app on your network, behind some decent authentication scheme, that has a menu option to open a remote access session. This app then white lists your IP on your edge firewall for N time for service and presents a quick launcher link -or- send email with link etc. This would be a good option for an SMB with little tolerance for VPN.

hunter2_ 7y ago

I'm all for defense in depth generally, but if a use case demands the convenience of not having this extra step, can't various application protocols be made as tough as a VPN to crack? At that point the VPN just adds obscurity. Wrapping insecure legacy protocols, like SMB for example, with a VPN is absolutely required.

Spivak 7y ago
The step of flipping a switch to connect to a VPN isn’t that bad. Googles IAP is in a lot of ways more annoying since you end up having that step multiple times. It’s not really the protocol that people are worried about — it’s attack surface. VPNs have basically zero — everything is opaque and an attacker learns nothing except that you’re on a VPN by observing your traffic. An attacker doesn’t even know that the application you’re connecting to exists and can’t even reach it to break in it without first breaking into your VPN. You can call this obscurity but I think it’s better to say that you’re not leaking side-channel information about your network. Having a VPN isn’t an excuse to have poor network security internally but a single portal that’s internet facing is much more defensible than n different home-grown apps.
Timothycquinn 7y ago
I often maintain hard white list for remote services when VPN is not an option. A cool option that does not have much implementation out there is using port knocking to open ports on demand. If the scheme is dynamic, it could be virtually impenetrable. Another way to go is to have a web app on your network, behind some decent authentication scheme, that has a menu option to open a remote access session. This app then white lists your IP on your edge firewall for N time for service and presents a quick launcher link -or- send email with link etc. This would be a good option for an SMB with little tolerance for VPN.