AWS Egress Controls

We’ve looked previously at whether or not it makes sense to use a Network Intrusion Detection device in AWS. Today, we’re going to look at the different controls available for outbound traffic leaving your environment.

Do we really need to control egress traffic?

As always, it’s vital to understand why you want to control egress so that you can choose a solution that meets your needs. Vague handwaving and mumbling about ‘best practice’ is unlikely to get you the right decision for the goals of your organization.

Outbound traffic controls are typically regarded as a lower priority than those on inbound traffic. This is logical - attackers need to get in to your systems for an attack to be successful.

Once an attacker has found some sort of gap in your environment, their next step will often be to call out from the compromised machine to a remote service. This might be because they initially don’t have full two way connectivity to the exploited endpoint, and they need to establish an outbound connection from your machine to get shell access. It could be that they have shell access, but want to download a toolkit that will allow them to cement and hide their access in your systems. It’s possible that the attack is actually a more straightforward worm, which has automatically exploited something in your environment, and now needs outbound connectivity to the botnet command and control centre.

If outbound access is tightly controlled, with only the minimum allowed, filtered by domain name, then it is highly probable that this attempt would be blocked. This might not be enough to entirely prevent a skilled attacker further compromising your systems, but it’s likely to give you extra time to react to alerts generated from the egress controls themselves, or a service like AWS GuardDuty.

Tightly controlled egress traffic is not without its downsides of course. It will be necessary to have a process, manual or automatic, via which teams can request outbound connectivity to specific destinations. Depending on the approach you use, it may be difficult to support more than just outbound HTTP/HTTPS traffic. Additionally, there will likely be cost implications around egress filtering, at least for anything more complex than IP based filtering.

With this in mind, some organizations may decide not to implement egress controls, but rely solely on alerts from services such as AWS GuardDuty to flag problematic outbound traffic without blocking it. I think this is a reasonable decision to make in some scenarios, particularly those where the attack surface is limited.

Connectivity to AWS services

Something to think about when deciding on an approach for outbound traffic filtering is how you will deal with access to AWS services. For high traffic and/or latency sensitive services like DynamoDB it is best to avoid sending traffic through an intermediary device.

Many services offer VPC endpoints which provide a relatively straightforward way to give access even to services without any outbound Internet access. Unfortunately the cost for these VPC endpoints can quickly mount up if you are deploying endpoints for multiple services in every VPC. I discuss this in more depth in my AWS Networking Blueprints article.

Available options

Security Group rules

The standard way to secure traffic in AWS is via security group rules, so it makes sense that this would be the first option to consider when looking at egress control.

The major problem with trying to use security group rules to control outbound access is that they work only based on IPs. This may be sufficient for some use cases, but it is likely to present an issue for many. For example, to reach a destination hosted in AWS you may end up needing to add the entirety of AWS to your allow-list, something that defeats much of the point of outbound traffic filtering.

AWS Network Firewall

AWS Network Firewall is a relatively new solution from Amazon which provides fine grained network controls. It has support for DNS based filter lists, as well as providing the ability to write custom rules using the same DSL as the open source Suricata IPS.

As with every other option listed here, you will need some sort of process for adding new entries to the allow list, whether manual or automated.

Explicit HTTP/HTTPS proxy

Before the release of AWS Network Firewall, the standard solution for egress filtering suggested by AWS Solution Architects was to utilize an explicit HTTP/HTTPS proxy - either in the form of an open source solution using Squid, or a third party marketplace proxy.

One obvious downside to these options is that they only support outbound HTTP/HTTPS connectivity. Whilst there are many situations in which this will be perfectly sufficient, this can be problematic limitation.

There is a reasonable amount of maintenance required when using this solution - not only will allow lists need to be maintained, but the proxy solution itself and the instances it runs on will too. Configuring applications to utilize the explicit proxy can sometimes be challenging, meaning this approach places an additional burden on developers and application support teams.

Suggested approach

In smaller environments, you may decide that you are comfortable letting developers decide the levels of outbound access that is appropriate for their application. This is particularly true in serverless environments, where the scope for deploying rootkits is limited or non-existent.

For everyone else, I would suggest that AWS Network Firewall makes the most sense to evaluate as the ‘default’ option. It offers good flexibility with the Suricata rule engine, and can easily be deployed throughout an environment.

It’s important to acknowledge that everything short of full outbound access is going to create a point of friction between the team with control over that outbound access and everyone using the environment. That doesn’t mean that it’s wrong to try and control outbound access, but it is vital to have the right team and processes in place to handle requests in a timely manner. If outbound access is restricted it is inevitable that at some point there will be an outage, possibly out of business hours, that will require additional outbound access to resolve. If outbound access is managed by a team that isn’t able to deal with this situation, it could have serious repercussions.