Securing your cloud with a Bastion host

Originally posted on The Curve’s blog.

Using a Bastion or gateway host can be one of the quickest security measures that you can use to reduce the attack surface of resources running within your cloud environment.

The idea of a Bastion host is fairly simple. A Bastion host is used to allow operational or internal access to resources within your cloud account, without requiring you to publicly expose these resources to the internet.

Whilst we’ll pick a specific example to illustrate the usefulness of a Bastion host, it is worth noting that these techniques can be applied to any of the major cloud providers such as Amazon AWS, Microsoft Azure and Google Cloud Platform.

The Scenario

Let’s assume you have 4 servers running in an AWS account, and that you need to provide your developers with SSH access to these servers.

An insecure deployment

One way that you can provide your developers with SSH access, will be to ensure that each server has a public IP address and runs SSH so that a developer can directly connect to each server.

This approach has a number of drawbacks:

• Each server is publicly exposed to the internet via the public IP
• Every one of these servers could be used by an attacker to try and gain access to your cloud infrastructure. If an attacker is able to gain unauthorized access to one of these servers, what else will they be able to access?
• Because each of these four servers are exposed to the internet they should be security hardenered and have additional security measures in place such as audit logging and firewall rules

Whilst this approach could be considered the most convenient as the setup is minimal, this is achieved at the risk of having a larger than necessary attack surface and requiring each individual resource to be hardened against external threats.

Increasing security: using a Bastion host

Another way to approach this same scenario is to use a Bastion host.

Instead of providing each server with a public IP, we can instead have a single server which has a public IP, and the job of this server is to provide SSH access to the other servers within the cloud account.

This is a more secure setup because only one server is publicly exposed to the internet, therefore all SSH connection have to go via this one server. This then makes it easier for us to harden and secure this entrypoint to the cloud network against attack. We should still secure and harden all of the resources within our cloud network regardless of whether we use a Bastion or not. Afterall, introducing layers of security will provide an overall more secure setup, and layered security provides a level or redundancy in the event that a security measure is compromised.

If we look closely at this more secure scenario, we ensured that SSH access to our servers has to go through a Bastion host, and the individual servers do not have a public IP address. If we look closely however, our server resources were created in a public subnet, so in theory, someone could come along and assign a server a public IP.

In order to protect against this, we can take this a step further and ensure that any resources that don’t need to be exposed directly to the internet are creating in a private subnet, this will ensure that they cannot be assigned a public IP by mistake:

Conclusion

Like with any security measure, a Bastion host on its own is no silver bullet, but it can go a long way to reducing the attack surface of a cloud account. And we would always recommend using a Bastion host alongside other security measures, such as security groups and firewall rules.

This post was originally publish on The Curve’s blog:
https://thecurve.io/securing-your-cloud-with-a-bastion-host/