AWS Bastion Host - How to create it?

Security is a prime concern for almost any company, which use the services to store their own data. Even though Amazon provides excellent security with its services, it is strongly suggested by Amazon to use SSH access to further secure the services and their instances. This is when bastion host comes into the picture.

A bastion host can be thought of as a special purpose machine, which has been configured to work against attacks. The machine contains a single application only, which it hosts. It has access to the public network, and it also known as a ‘Jump Box’. It is a powerful server, which provides high-level network security, since it is the only host that is granted permission to access the public network.

This machine can be used by system administrators to connect to other instances of service, which happens in the infrastructure backend. This usage place with the help of many authentication mechanisms making sure that the system is safe.

These hosts are accessed with the help of SSH or RDP protocols. After a connectivity (remotely) is established with the bastion host, it allows using SSH or RDP to log in to other instances (thereby behaving like a ‘jump server’), that are present within the private network/subnet.

Once the connection is properly configured with the help of security groups and network ACLs (NACL), bastion host behaves like a bridge between the private instances of the service and the internet, thereby protecting the instances from attacks outside.

When is a bastion host needed?

If a user is confused whether they need a bastion host or not, ponder over the question- Do I need remote connection to my private instance of a service, through the public internet? If the answer to this question is ‘Yes’, then a bastion host is required, otherwise it is not needed.

The below snip shows how a bastion host can be used to connect to a private instance of the AWS infrastructure:

Designing a bastion host for AWS infrastructure

A bastion host designed to work with a specific infrastructure should work with that unit only, and nothing else. The reason behind limiting the usage of bastion host to a specific instance/requirement is to avoid formation of unnecessary security loopholes.

Steps to create a bastion host for a specific AWS infrastructure

Following are the steps to create a bastion host:

• Sign into your AWS account.
• Create an EC2 instance or launch an EC2 instance which was previously defined.
• Harden the OS, which basically refers to increasing the security which has been provided by the OS.
• Specify appropriate security groups or create a security group for the bastion host.
• This will open up the port 22 which is usually used with SSH.
• Select a source, which is done to ensure that relevant people (who have access to add their IPs) have access to the Bastion host.
• The security groups of the current instances have to be changed to make sure that inbound SSH (if any) can be accessed through the Bastion Host’s IP address only.
• The local ~/.ssh/config file has to be edited to reflect the bastion host name, username, and a ‘Yes’ value for the ForwardAgent field. This is used to set up the SSH forwarding via the local machine to the bastion host so that the file used to access the EC2 instance is made available only when the user tries to connect to one of the servers.
• Username refers to the person who has the rights to login to the server. Hostname refers to the IP address of the bastion host.
• This makes sure that the user can SSH into the Bastion server by just typing ‘ssh bastion’ from the command line interface.
• Bastion Host needs to be accessed with the help of SSH. into an existing server instance, and this way, a much tighter security would be built into the servers, by making these servers accessible only through a Bastion host.

Security groups play a vital role in maintaining the security and making sure the Bastion host doesn’t fail. A security group is created so that it can be used to allow the connection of a bastion host to a private instance (the instance is owned by the user).

This security group should only have the ability to accept inbound requests from SSH or RDP (Remote Desktop Gateway), which would come from the bastion host which is across the user’s Availability Zone. The rules of this security group should be applied to all the private instances of the user, which need tighter security, and which need to be able to connect to the internet via a Bastion Host.

The same security group needs to be applied to the bastion host.  The incoming requests should only accept connections from an SSH or RDP connection, which comes from specific IP addresses only (like those from administrators, or those who have been granted permission by an admin, to have the ability to connect to the instance). On the same lines, the outgoing connection should be able to access private instances via SSH or RDP only.

Make sure to avoid access to IP addresses like 0.0.0.0/0. SSH and RDP connections can be authenticated with the help of private and public keys. Logging in to the private instances via the bastion host will require the bastion host to have the private keys. But storing private keys on a remote instance isn’t considered a safe security method. Because of this reason, AWS recommends implementing the RDP (to connect to instances on Windows) or the SSH agent forwarding technique (to connect to instances on Linux). These solutions remove the need to store private keys on the bastion host.

It is highly recommended to deploy a bastion host within a public Availability Zone which is currently being used. It should be made sure that the services are resilient to failures and are highly available most of the time.

In case the hosting in a specific availability service goes down or fails, the connection to the private instance in other availability zones will also fail.

Conclusion

In this post, we understood how a Bastion Host can be used to protect instances from potential attacks.