In my last post I wrote about securing your AWS lab environments by using Managed Microsoft Active Directory as an authentication provider and configuring that active directory with randomly created passwords. This is a great first step in helping to configure your lab environments and making sure that you do not have static, hard coded, passwords lying around for people to exploit.
However, as always, security isn’t a single stop shop, and you should consider multiple layers to help reduce the chances of someone gaining access to your infrastructure. In this blog post we are going to look at another way to help secure access to the virtual machines that you are creating in your environment, by preventing access to the machine via RDP. Traditionally the idea of blocking access to RDP presents some challenges…
“How do I log into my machine to do stuff if I am blocking RDP?”
“What’s my ‘break glass in the event of an emergency’ strategy?”
In a traditional data center, you always have the ability to grab a ‘crash cart’ and hook up a keyboard, monitor and a mouse to that machine you accidentally configured to block all access to. However, in AWS there is no such crash cart. Thankfully, the crash cart has been replaced with the AWS Systems Manager functionality.
Fun Fact: Systems Manager is sometimes referred to as SSM. The extra leading ‘S’ in typical AWS fashion stands for Simple. This goes all the way back to when Simple Systems Manager was little more than the ‘Run’ service. These days, Systems Manager has a huge amount of functionality that can help manage infrastructure in AWS, on prem, in a CoLo or even infrastructure running in other cloud providers. So… The leading ‘S’ isn’t really appropriate anymore. With systems manager you can manage patching, install software, monitor the state of instances, and even remote control your machines.
The last item on the list, Remote control your machines is what we are going to look at in this post. We are going to use Systems Manager to get RDP access into a Windows Instance, without opening ports on the machine that would expose RDP to the world… or in fact anyone that doesn’t have systems manager access.
Blocking RDP at the firewall level
Every instance that is running in AWS has a security group attached to it. Think of a security group as the instances own private fire wall that runs without a performance hit on the machine. (Security groups operate at the hypervisor level, so they do not consume host resources.) Preventing RDP access is as simple as removing any security group entries that allow RDP traffic (Port 3389). As you can see in this image, there is no allow rule for port 3389.
If you were to attempt to connect to the instance with Remote Desktop:
The RDP connection will fail because the hypervisor is blocking traffic to RDP at the hypervisor level. The traffic never actually reaches the instance.
Logging in via Systems Manager
The first step in allowing you to connect to the instance via Systems Manager is to enable the Systems Manager agent on the instance that you are trying to control. The good news here is that if you are using an instance created from an AMI provided by AWS, the systems manager agent is already installed and running for you with no additional work. If, however, you are creating instance from an AMI created from your own media, or ths instance was created from migrating an existing virtual machine, you will have to install the Systems Manager plug in manually.
You can find details here on how to install the Systems Manager agent here: https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-install-win.html
The next step to enable Systems Manager access for instances running in AWS, is to give the instance permissions to access the Systems Manager service on your behalf. Once again, AWS makes this very simple to do. You will need to create an IAM role for your EC2 instance.
Details on the creation of AIM roles can be found here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html
Once you have created the role, add the AmazonSSMManagedInstanceCore policy to that role.
Basically, an IAM role grants permissions to the specific thing that they are attached to. In this case, because you are attaching the role to an EC2 Instance, you are providing that instance permissions to interact with your AWS Account. We use IAM roles in this case to increase the security for the environment. With IAM roles there is no need to store credentials on the machine, no need to worry about compromised passwords, and no need to update credentials in accordance with a security policy. As with any time that you are dealing with security, it is important to use the Least Privilege concept. Give the role only the permissions that it needs to accomplish the tasks that it is required to do. In the case above, I am providing permissions only to the Systems Manager service, as well as the Cloud Watch Logs service so that I can export logs. This will be covered in a later blog post.
Once you have set up the IAM role attach it to the instance via the EC2 console. Next head over to the Systems Manager service in the AWS console. You can access this from the main console by typing SSM into the universal search box. Once in the Systems Manager service area, have a look along the left hand navigation bar. Towards the bottom you will find an item called Fleet Manager.
Inside fleet manager you can see a list of “Managed Instances.” Managed Instances are all the instances in your account that are currently communicating with Systems Manager. Connections to Systems Manager are outbound from the instance, so there is no need for any inbound connectivity through the security group or the firewall. If the instance you are trying to connect to is not showing up in this list, then you want to double check that the SSM agent is installed and running, and that the instance has outbound access to the internet.
If all is well and your instance is listed in Fleet Manager, you can then use the option to connect to the instance. Connecting to the instance will give you two options. The first option is to connect to the instance using normal login credentials for the machine. You can use a local user name and password, or if the instance is domain joined, you can use any domain credentials that have permissions to log into the instance. The second option is to use a security key that is associated with the instance. These keys must be associated when the instance is created. If you use this option, you must provide your portion of the key pair to log in.
Once you have provided the required details, eith the username and password, or the key file, you then click the connect button. Once the connection is established you will get a web view of the RDP session into your instance. This is all done without the need for any inbound ports to be open or configuring any port forwarding. At the top right of the RDP session is a four point star, clicking on that allows your RDP window to open into full screen, and gives you a real desktop experience.
Summary
By enabling Systems Manager, you can get RDP access into your instances, from anywhere in the world, without the need for VPN access and without needing to open up RDP access. This can provide you with that “Break Glass In Emergency” access that you need to your instances, without the need to compromise on security.
Using this you can complete all the management functions you normally would without increasing your attack surface area.
If you have any feedback, please feel free to drop me a line at:
tom@basementprogrammer.com
