Architecting for Cloud Security: Bastion Hosts

When it comes to cloud security there are a number of concerns that come up. These can be broadly classified into two categories. The security threats faced by the customers who have their applications and data on the cloud and the threats faced by the cloud vendors. The later is beyond the control our control and most cloud providers today go through a rigorous compliance and certification process to address these. As such cloud security is almost always a shared responsibility between the cloud vendor and the customer.

This post is the the first part on our series focusing on cloud security from a customer perspective where we cover secure access. More specifically we will look at a effective way to tighten the access to your resources on the cloud.

Bastion Hosts – A bastion host is an instance that resides within a public subnet or DMZ within your cloud network. These are typically accessed using SSH or RDP. Once you connect to your bastion host, the bastion host then establishes secure connectivity to other other instances with your private network.

In order for the bastion hosts to provide an effective security layer we need to properly configure the security groups and Network ACLs. In a typical scenario a bastion host acts as a bridge to allow you a secure access path to other instances within your private subnet. The image above is a representation of a bastion host architecture.

Private Keys and SSH Forwarding – By default, Linux instances in EC2 use SSH key files for authentication instead of SSH usernames and passwords. We strongly recommend our customers to use key pairs as they can reduce the chance of hackers trying to guess the username and passwords. This however, presents a challenge with bastion hosts as the private keys are typically stored on the client laptops securely and are needed to access the instances over ssh. It would not be a prudent solution to transfer these keys to the bastion hosts either.

One solution would be to enable ssh forwarding. This will allow the ssh keys to be transfer to the bastion hosts and from there on be used to login to the remote machines.

Most ssh clients have the ssh forwarding enabled by default. Before you can use that, you will need to add your private keys to your ssh agent as below

Adding private keys to your SSH agent

myMBP:~ samx18$ ssh-add -k MyCTREC2Key.pem

You can list the keys that are add to your agent as below

myMBP:~ samx18$ ssh-add -l 2048 41:f7:54:7d:41:26:99:26:b0:3c:09:62:6a:3d:70:42 /Users/XXXXXXXXXX/MyOregonEC2Key.pem (RSA) 2048 e2:bb:2c:6a:69:0f:93:09:43:83:f7:f8:2a:36:89:52 /Users/XXXXXXXXXX/MyCTREC2Key.pem (RSA) 2048 cd:9e:1f:99:a2:c1:9a:e0:5d:80:11:c1:0e:65:9a:79 /Users/XXXXXXXXXX/SamOregonEC2.pem (RSA) 2048 e6:d6:78:13:2e:6b:e0:e5:3f:83:f6:f8:c7:54:c3:d7 /Users/XXXXXXXXXX/RealEBSKey.pem (RSA)

Now you can use the -A option to forward your keys to the bastion hosts

myMBP:~ samx18$ ssh –A ec2-user@<bastion-IP-address>

Once connectivity is established to the bastion host, you can ssh to the instances within your private network via a simple ssh as below

ssh ec2-user@<IP-private-subnet-instance>

The ssh-agent will automatically cycle through all the keys available in its key chain including the one that was forwarded to it from your laptop until it finds a match with with it can log on to the instance.

Lastly as with everything else in your architecture, make sure you build in redundancy for your bastion hosts to ensure that you do not lose access to your instances in case you lose the bastion host.