AWS — Security Groups, NACLs and Network Firewall Part 3 — AWS Network Firewall
I must first start with an apology to everyone that reads these posts and there lack of frequency recently, I wanted these to be sent out in quick fire succession but unfortunately life and work had other ideas.
So just to give you a little background to the absence of my posts since my last blog post…
Well after my last blog post I moved house… YAY!! very stressful and time consuming especially with the Market in the UK last year (say no more!!) My daughter then had her exams so my spare time was spent supporting her (she did very well, smart little cookie must take after her mum), I then had a little holiday, followed by a job interview (I was successful and have just started said job this week :-) ) After handing in my resignation around October time I found myself on the bench (No No this wasn't a petty response to me handing my resignation in… just a coincidence) I then made the decision to attempt the AWS Certified Architect Professional Exam by the end of the year, I took the exam in early December and to my surprised I passed (Huge sigh!!!) so all in all a bit of a busy time.
So lets crack on with looking at the AWS Network Firewall…
So what is the AWS Network Firewall… Well in short it is AWS’s answer to a traditional firewall in the cloud, well actually probably not traditional these days, it probably sits closer to the NextGen firewall family with built in open source IPS (Intrustion Prevention System) service Suricata.
The official extract from AWS is
AWS Network Firewall is a stateful, managed, network firewall and intrusion detection and prevention service for your virtual private cloud (VPC) that you create in Amazon Virtual Private Cloud (Amazon VPC).
So stateful is good.. we discussed this previously , its managed this is also good as it means there is nothing for us to worry about apart from getting traffic to it and the rules..
So why would I want to use AWS Network Firewall? Good question…
AWS Firewall is used to filter traffic at the perimeter of your VPC(s) something that NACLs and Security Groups dont do… Remember? NACLs apply to Subnets and Security Groups to ENI’s both of which are inside of the VPC.
But what does filter at the perimeter mean? lets look at a very simple setup in AWS to allow an EC2 Instance in a Public Subnet to access the internet.
As you can see from the above we have a VPC with an Internet Gateway Attached, a single public subnet, with an EC2 instance with Public IP Assigned with an attached security group permitting HTTP and HTTPS inbound from any destination and All outbound access to any destination, There is a NACL configured but with the default All in and All out permitted rules, and a Route table with a default route pointing to the Internet Gateway. Now assuming that I had a simple website running on this EC2 instance I could access it from the internet and the EC2 instance could access anything on the internet it needed. A very very simple setup I agree but serves a purposes for the moment.
So what protections do we have??
So our first line of defense is the NACL the one in the example is not really doing anything it permits everything in and out, so any bad actors can already reach our subnets (not ideal)..
Next is the Security Group, so remember before I said this is like a personal firewall for an EC2 instance, so here we have some protection we are only allowing http and https inbound and everything out… great for things to work, but that is about as much as we can do to provide security.
While we do have protections here there is nothing meaningful until we reach the EC2 instance itself where the Security Group is, this means for instance that if a bad actor try to initiate SSH to the EC2 instance those packets will reach all the way to the EC2 Instance ENI before being dropped. In the real world we don’t want those types of packets reaching that far into our environment before being dropped.
Now we could tighten up our NACLs yes… but as the number of subnets grows and the number of services grows NACLs become increasingly difficult to manage well and they also have limits on the number of rules allowed to be configured (at last check it was 40 Inbound and 40 Outbound max) that might seem like a lot but when you start adding them in it will soon grow, so its best to keep NACL’s simple.
Lets look at how the AWS Network Firewall could improve this setup and provide some additional protection.
Now dont panic this is not a complicated as it might seem… So we still have our “Public” Subnet with our EC2 instance etc… I say “Public” as it is now what we would class as Protected due to the insertion of the AWS Network Firewall. In the bottom half of our infrastructure the only update is that instead of the the route pointing directly to the Internet Gateway it now points to the Firewall Endpoint in the Firewall Endpoint Subnet.
So what is the Firewall Endpoint for? this allows for traffic to traverse the AWS Network Firewall to be processed.
The Firewall Endpoint Subnet has a route table and has two entries, one is a default route out via the Internet Gateway, and the other is a route to the Public Subnet via the Firewall Endpoint.
Now we have our new setup in place lets return to our scenario with our bad actor.
Our naughty person now initiates an SSH connection inbound to our EC2 Instance, previously the packets would have reached the ENI of the EC2 instance before being denied, what about now??? Yes you guessed it, now the packets are inspected at the AWS Network Firewall and it determines that in fact SSH is not permitted according to its rules so it is stopped in its tracks at the edge of the VPC before it can even make any progress into the VPC. Obviously with the added bonus of the AWS Network Firewall having some IPS/IDS capability we can also take protection a little further should you wish to, and lets be honest if you work with those smart cookies from the security team you are going to be….lol
The Network Firewall is a lot more powerful when it comes to the types of controls you can put in place, Network Firewall can support thousands of rules that can be based on a domain, port, protocol, IP address, or pattern matching.
These different elements provide great flexibility in rule creation and have some distinct advantages over traditional IP and Port based rules :-)
For example rules based on a domain are gold, for instance if you have a third party that has a service that you wish to access, previously you would ask your contact nicely for the Public IP addresses or Range of IP addresses that the service used so you could setup of strict rules appropriately… for some services this would work no issue, however as companies have grown and services have got more complex and larger you could be talking a huge number of different ranges and addresses, you also have the added complication now that services can move IP address without warning meaning access issues etc, domain rules remove this issue as you can specifiy the FQDN (Fully Qualified Domain Name) i.e. apps.example.com you want to target, this means that it doesn't matter if the IP changes, as long as you are trying to contact the permitted FQDN the firewall will permit the traffic.
I hope you find this useful as a simple look at AWS Network Firewall
Next time we will complete this series of four blog entries to look at the the best practice architecture deployments for Network Firewall and the round up what we have been through.
Again thanks for reading till next time :-)
