Amazon provides a number of security guides that can be leveraged by customers when deploying AWS instances. One of these guides walks the user through deploying Windows RDP management in a secure fashion. The gist of the advice is summarized in Figure 1. The idea is to only expose a single Windows server to RDP access, and to use that host as a gateway for reaching all other servers requiring RDP management. This way only the gateway is the only server required to expose its RDP port to the Internet.
While this deployment model does help to limit exposure, architecturally it has a number of problems. To start, it creates a single point of management failure. If the RDP gateway goes offline or is unreachable, you can no longer manage the servers sitting behind it. Granted you could modify your firewall rules to permit direct RDP access to the rest of your servers, but this may require the Windows Admin to have access to the Amazon AWS management interface. This could be a segregation of duties issue in some environments. Further, since the background servers are normally not exposed, configuration and patch management may have become lax such that direct Internet exposure could be a security issue.
Other problems may not become apparent until the configuration is deployed. For example bouncing through a gateway is going to add latency to the connection, thus making management sluggish at best. Also, how is the Admin going to keep track of all the back end servers to be managed? Most likely they will simply add shortcuts to the desktop of the gateway. This means that compromising the gateway will immediately reveal the location of all of your servers. If the Admin has chosen to have the shortcut save the login credentials, additional server access is a simple icon click away.
Finally, while this deployment may feel like it is adding another layer of security, in many ways it is really not. The gateway has its RDP port exposed. If an attacker can gain access (say through one of the two RDP attacks we’ve seen this year that yields Admin level access without the need of authenticating with the system), the same exploit will work on all of the servers sitting behind it. Further, if the vSwitch is compromised, the gateway can be circumvented thus permitting direct access to the servers sitting behind it.
One of the reasons we created Halo GhostPorts is that it can provide a higher level of security than the above configuration, with none of the architectural drawbacks. GhostPorts permits your Administrators to connect to each server directly, without the need of exposing the RDP port for administration. This removes any one server from being a single point of failure, and ensures none of the servers are exposed to attack. Administrators can trigger GhostPorts with Yubikey or SMS authentication, so there is no need to give them high level access to your cloud infrastructure management tools. This means it is much easier to maintain segregation of duties. Finally, GhostPorts is a cloud agnostic solution, which means it will work in any public or private cloud.