Hacker News Reader

Comment by cerberusss | Hacker News Reader

My problem isn't really the protocol or the client. It's that the device is behind a NAT, a corporate firewall or otherwise not reachable at a public IP address.

I assume this project doesn't help with that?

For now I'm just sticking to products like TeamViewer.

View on HN

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.

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.

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.

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.

The Guacamole server needs to be reachable from the internet, but the desktops you're connecting to only need to be reachable from the Guacamole server. That helps with some but not all of the situations where desktops aren't reachable with a public IP.

you could install a opensource SDN like zerotier. The you can connect even if the device is behind NAT/firewall whatever!

Good tip, thanks!

Put the Guac instance in a public subnet with appropriate security group rules. Put the target instances in private subnets.

Add a NAT in the public subnet so that the target instances can get security updates and install new software.

It's not perfect but it works.

Reply on news.ycombinator.com