In this scenario, the traffic flow for egress traffic is straightforward. Incoming traffic from the workload accounts goes via the AWS Transit-Gateway, which sends it to the firewall subnet. The AWS Network Firewall applies the configured rules and decides to drop or accept the traffic.
If it accepts the traffic, the AWS Network Firewall forwards it to the AWS NAT Gateway services in the public subnets, allowing the outgoing connection to pass to the internet.
For the AWS Network Firewall to check the acceptance criteria for traversing, you can configure multiple rules and group them for checking.
You can differentiate between stateless and stateful rules within the firewall.
Stateless rules are about allowing or dropping specific protocols or CIDR ranges. The AWS Network Firewall supports the standard stateless Five-Tuple (or 5-tuple) rule specification for network traffic inspection: Protocol, Source, Source-Port, Destination, Destination-Port.
Stateful rules, on the other hand, offer way more configuration options. They use the Suricata compatible intrusion prevention system (IPS) specifications. Suricata is an open-source network IPS that includes standard rule-based language for stateful network traffic inspection. The AWS Network Firewall supports Suricata version 6.0.2 as of now.
We used the Suricata rulesets to specify a whitelist of allowed domains to whitelist the traffic from the workload accounts.
You can configure the sample ruleset to allow whitelistedpage.com as follows:
pass tls $HOME_NET any -> any any (tls.sni; dotprefix; content:".whitelistedpage.com"; nocase;
endswith; msg:"matching TLS allowlisted FQDNs"; priority:1; flow:to_server, established; sid:1; rev:1;)
pass http $HOME_NET any -> any any (http.host; dotprefix; content:".whitelistedpage.com";
endswith; msg:"matching TLS allowlisted FQDNs"; priority:1; sid:2; rev:2;)
drop http $HOME_NET any -> any any (msg:"not matching any HTTP allowlisted FQDNs";
priority:1; sid:3; rev:1;)
drop tls $HOME_NET any -> any any (msg:"not matching any TLS allowlisted FQDNs";
priority:1; flow:to_server, established; sid:4; rev:1;)
This rule allows HTTP and HTTPS traffic to the whitelistedpage.com and its subdomains. Any other traffic for HTTP and HTTPS is dropped with appropriate log messages.
Of course suricata does allow other protocols besides http and https. For that please check the suricata online documentation.
It is important to note here that there is a variable called $HOME_NET which per default points to the cidr range of your VPC. If you want to pass traffic also from other VPCs via the network firewall you need to adjust this variable to fit your networks cidr range.
At the time of writing this document it was not yet possible via AWS console but you can use the AWS CLI to do this. Click here for further details.
You can easily extend this config to other domains you want to whitelist according to the needs of the backend applications in the workload accounts.
The Suricata rulesets also allow way more configurations than can be found in the Suricata documentation itself.
A central solution that can block traversing traffic is crucial to enable some form of logging.
You can configure the AWS Network Firewall for log alerts and flow logs. Valid options for the log destinations are:
- Amazon S3
- Amazon CloudWatch log groups
- Amazon Kinesis Data Firehose
For our use case, we configured CloudWatch Logs to forward the log messages to an attached SIEM solution.
The type of logs that you can utilize are
- VPC Flow Logs which do provide the network internet protocol (IP) traffic flow (characterized by a 5-tuple on a per network interface basis)
- Network Firewall alert log which covers all alerts configured in your suricata confing containing custom warnings that you have defined per rule.
We implemented the AWS Network Firewall after the initial network setup. We set up the firewall in ‘transparent mode’ between the workload traffic and the internet. Transparent mode means we implemented the firewall without any rules to block traffic.
Instead, we had a single rule (below) pointing to our AWS CloudWatch log group for logging all HTTP and HTTPS egress traffic to CloudWatch.
To get the first draft of the allowed domains, we collected the logs for a certain amount of time and used AWS Contributor Insights to create a visualization of the log events.
We used this visualization to verify the list before the solution go-live and check if we missed any important domains we needed to add.
We discussed the findings with the workload owners who sent the requests to the AWS Network Firewall. This meant we could eliminate almost all the problems that usually occur when disabling public internet access by adding a ruleset that allows whitelisted domains only.
The AWS Network Firewall is an easy-to-setup solution for controlling egress traffic to the internet.
The logs and metrics also support a seamless migration without users justifiably complaining about access problems they didn't have before the firewall was in place.