Securing Your AWS VPC With a Next-Gen Firewall

According to Gartner, Infrastructure as a Service is the fastest growing segment in cloud adoption. And as more organization move entire infrastructures to the cloud, we need to know how to properly design our VPCs to use the benefits of a next gen firewall. 

The AWS shared responsibility models states that the customer is responsible for security in the cloud. This includes, protecting network traffic, firewall configuration and pretty much everything layer 3 and above. 

In this article, we’ll go over some VPC basics – along with how we can design proper segmentation and modern security concepts to our virtual private cloud.

Internet Gateways

Let’s start off with the most common entry and exit point into your VPC, and that’s the internet gateway. The internet gateway is a redundant virtual router that connect your VPC to the outside world. You can only have one attached per VPC, and you would typically make it your default gateway on any public subnets. 

The default VPC in AWS has preconfigured subnets with a routing table that routes through the IG. Any instance that you deploy in these default subnets are automatically given a public IP and accessible to the world. On a traditional network, you would never deploy an application or a server directly on the internet and the cloud should be no different – here’s why:  

These are some logs from my own AWS environment. Within minutes of deploying a new Windows instance with a new elastic IP, I received as many as 60 connections attempts a second by over 40 different IP addresses from all over the world. This is because AWS IP space is a known range, being constantly scanned by bots and script kiddies. 

At the time of this writing a botnet named ‘GoldBrute’ is sweeping the internet for live RDP host that are vulnerable to the BlueKeep RDP vulnerability. And this is a perfect example of why we need multiple layers of security. 

The traditional cloud approach is focused too heavily on application security. And seeing as how these attacks started before most organizations had a chance to patch them, if I didnt have proper protection – I easily could have probably been compromised. 

This is why our first security decision will be to segment our VPC into public and private zones. And since AWS doesn’t allow us to do this without the help of a 3rd party device, we’ll need a next gen firewall from the Marketplace to segment and inspect our traffic in between zones. 

But before we dive into our new design, let’s first cover some VPC basics. 

NACLs vs Security Groups

Internet traffic arrives from your IG and is processed by your routing table. The routing table then determines which subnet to route the packet to. Before traffic enters a subnet, it is inspected by the Network ACLs, which are stateless filters looking only at the IP and port of  packets. 

Security Groups

Once it passes the network ACL, traffic enters the subnet and is inspected by security groups before going to the instance. Security groups are very basic layer 4  firewalls that do not look at anything in the application layer.. Relying on security groups as your firewall puts your security posture back at least 20 years when you consider even the most basic modern firewalls allow you to do things like application identification, Malware and threat protection, IPS and much more. 

This is why even AWS recommends using a 3rd party firewall when you have requirements beyond basic packet filtering. A NextGen firewall provides thousands of features we wont cover today, but most importantly for our design – it provides the segmentation we need to split up our applications into public and private zone. 

## https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html

## AWS Recommends Using 3rd-party Security “If you have requirements that aren’t met by security groups, you can maintain your own firewall on any of your instances in addition to using security groups.”

North/South/East/West

In our new, secure VPC design – we’re going to deploy a Next gen firewall EC2 instance from the market place with at least network interfaces. one interface on the public subnet with the internet gateway attached and at least another interface on a private subnet where our applications will reside. We’ll also want to create a new routing table for our private subnets which point all traffic to the inside vNIC of the firewall. In this way, all northbound traffic is always routed through the firewall for content inspection and policy checking (word?). That means we’ll have at least two routing tables in our VPC. A public one that points to our Internet Gateway – this one should only be for our public / Internet facing instances like our firewall. And another routing table for our private subnet which points to the inside vNIC of the firewall as it’s gateway. 

Northbound traffic should be tightly controlled and firewall policies should be locked to known FQDN or IPS to known  destinations your application requires . If your FW supports it, you can also monitor outbound connections for botnet signaling, C&C servers and other indicators of compromise. 

Incoming traffic destined to your applications will now hit the firewall’s public interface and route south to your application. This is where firewall tools like reverse proxies, Application inspection, IPS and DDoS can help protect your application from inbound request. Because your servers are in private IP space, the public IP your users would connect to actually belongs to the firewall on it’s public interface. Request to that external IP are then routed or DNAT’d to the internal resource according to your firewall policy. 

Equally as important, we need to consider traffic that flows laterally or within the same boundaries, also called East-to-West traffic. This could be a web app talking to a DB, or a custom application talking to a file share. While AWS has limitations to what we can actually do, we can work around some of these limitations by micro-segmenting our internal servers into different subnets. For this scenario to work correctly, we’ll distribute our applications across different subnets. The gateway for each subnet is going to be vNIC of the firewall. This ensures that traffic always goes to the firewall first in order to apply proper content inspection, filtering and auditing. 

Breach containers 

Designing this level of segmentation not only gives us more granular policies within our application but it also acts as ‘breach containers’ incase an application gets compromised. By inspecting east – west traffic, you can detect and contain potential breaches from causing further damage to your environment. (3 min). This means if a web server is compromised, the damage would be contained and not spread across to your other instances. 

Resiliency

While we’ve made our VPC more secure, we’ve also introduced a single point of failure by only deploying one stance on one availability zone. This is why we need to deploy a firewall on at least two AZ’s within all the regions we are operating in – with a minimum of two firewalls per regions. An availability zone = a datacenter , so if we need to tolerate the loss of one datacenter, we’ll need to deploy our firewall instance into at least two different zones. 

Any instance on AWS can only have its vNICS in the same AZ that the instance is deployed. Which means you can’t have vNICs in two different AZ. Make sure your routing tables are configured in such a way that applications can reach the backup firewall in a failover scenario. 

As you look for potential firewall vendors, make sure you understand how HA works for them. Some vendors HA mechanism is completely seamless, where traffic is automatically routed to the backup firewall with no downtime. Other vendors may rely on scripts to move default gateway and elastic IPs between instances. 

Closing

Because HA varies by vendor, we wont go over the technical details of how the firewall will accomplish. But it is important to know how your preferred vendors handles a failover and what, if any, limitation you should be aware of. 

Some basic questions you may want to research are things like 

• How are policies and sessions are synced between an HA group? 
• How are elastic IPs are handled during a failover? 
• How will private instances route to the backup in a failure? 
• How much downtime should I expect? 
• What (if any) are the dependencies on other AWS services. Some vendors rely on Cloudwatch, Lambda or small ec2 instances to work properly. All of which will incur an additional cost.