Cloud Security
AWS Network Firewall
AWS Network Firewall Overview and Deployment Models
With Amazon Virtual Private Cloud (VPC) is possible to manage network security using Network Access Control Lists (NACL) and Security Groups (SG). In some cases, there is a need beyond the scope of these network security controls, such as deep packet inspection (DPI), application protocol detection, domain name filtering, and intrusion prevention system (IPS).
AWS Network Firewall (NF) is managed network firewall service for VPC. It enables the possibility to easily deploy and manage stateful inspection, IPS and IDS also web filtering to protect VPCs. Network Firewall automatically scales with traffic, ensuring high availability with no additional investment in security infrastructure.
NF makes firewall activity visible in real-time via CloudWatch metrics and offers increased visibility of network traffic by sending logs to S3, CloudWatch, and Kinesis Firehose.
NF is integrated with AWS Firewall Manager, giving customers who use AWS Organizations a single place to enable and monitor firewall activity across all VPCs and AWS accounts. NF is interoperable with some existing security ecosystems.
How it works
On the AWS resources level, the simplest setup depicted in Figure-1.
A more detailed explanation will be later.
The logical diagram (Figure-2 left)
The rule engine packet flow (Figure-2 right)
To apply traffic-filtering logic provided by NF, traffic should be routed symmetrically to the Network Firewall endpoint. This firewall endpoint is similar to the PrivateLink VPC interface endpoint. The key difference is that it can be a route table target. NF endpoint is deployed into a dedicated subnet of a VPC (Firewall subnet). Depending on the use case and deployment model, the firewall subnet could be either public or private. For high availability and Multi-AZ deployments, allocate a subnet per AZ.
Once NF is deployed, the firewall endpoint would be available in each firewall subnet. Firewall endpoint is similar to interface endpoint and it shows up as vpce-id in VPC route table target selection. To inspect any in/out traffic by NF, routing tables should be configured as shown in Figure-3
Deployment models for AWS Network Firewall
- Distributed AWS Network Firewall deployment model: AWS Network Firewall is deployed into each individual VPC for North-South (internet egress and ingress) traffic.
- Centralized AWS Network Firewall deployment model: AWS Network Firewall is deployed into centralized VPC for East-West (VPC-to-VPC) and/or North-South (internet egress and/or on-premises) traffic.
- Combined AWS Network Firewall deployment model: NF is deployed into centralized inspection VPC for East-West (VPC-to-VPC) and subset of North-South (internet egress and on-premises) traffic. Internet ingress is distributed to VPCs which require dedicated inbound access from the internet and NF is deployed accordingly.
Before discussing mentioned deployment models, single VPC deployment will be explained with HA (Multi AZ) and private/public subnets setup
(see Figure- 4).
NF is used to protect any internet-bound traffic. The workload subnet has the default route to the firewall endpoint in the corresponding AZ. The firewall subnet has a default route via IGW. Since NF doesn’t perform NAT, ingress and egress to the Internet depend on public IPs or EIPs associated to individual elastic network interfaces (ENIs) in the workload subnet. Finally, IGW has an ingress route table associated to it. Route table has entry for each protected subnet directing traffic to firewall endpoint in the corresponding AZ. This ensures that traffic is symmetrically returned to the right firewall endpoint to maintain stateful traffic inspection.
AWS Network Firewall can also be deployed to protect AWS services such (ALB) and NATgw. With ALB, backend targets could be deployed within private subnets. Any traffic between ALB and the internet is inspected by NF before delivery to backend targets. Similarly, NATgw could be placed in the protected public subnet. NATgw is a default route table target in the private subnet route table. Traffic between NATgw and the internet is inspected.
Distributed AWS Network Firewall deployment model:
For the distributed deployment model NF deployed into each VPC which requires protection. Each VPC is protected individually and the blast radius is reduced through VPC isolation. Each VPC does not require connectivity to any other VPC. Each AWS Network Firewall can have its own firewall policy or share a policy through common rule groups (reusable collections of rules) across multiple firewalls. This allows each AWS Network Firewall to be managed independently, which reduces the possibility of misconfiguration and limits the scope of impact (Figure-5).
Centralized AWS Network Firewall deployment model:
This case has many various cases and scenarios several cases will be discussed (best practices)
First simple scenario: This model covers requirements where there’s a need to inspect East-West traffic. For example, VPC to VPC in the same or different AWS Accounts using AWS Transit Gateway (TGW). In this model, two touting tables used for TGW. Routing table A and Routing table B within the same TGW ensure that all traffic between VPCs is passing through inspection VPC. All the spoke VPCs are associated to the Routing table A which has a default static route towards inspection VPC attachment. All spoke VPCs routes are propagated into TGW Routing table B which ensures the packets have a return path to spoke VPCs (Figure-6).
As already mentioned previously explained case on Figure-6 covers East-West (VPC-to-VPC) traffic inspection in the scope of a single AWS Region. Let's expand the previous model by adding to infrastructure traffic inspection between VPC and on-premises (via Direct Connect and VPN) and VPC in another region. Interconnection between mentioned parts implemented using TGW, TGW routing tables, and TGW Transit VIFs (see Figure-7). Spoke VPC1, TGW RegionB, Direct Connect Gateway (DXGW), and VPN attachments are associated to the Routing table A which has a default static route towards inspect VPC attachment. All spoke VPCs routes are propagated into TGW Routing table B which ensures the packets have a return path.
The next build- (see Figure-8 ) covers inspection for Internet-bound traffic from TGW attachments. For this model Inspect VPC will be expanded via adding configured NATgw in a public subnet with access to IGW. It is possible to use a dedicated central VPC for Internet egress traffic, but to avoid the complexity of traffic flow single VPC will be shown for inter VPC and VPC to Internet inspection. Traffic originating from spoke VPCs is forwarded to inspect VPC for processing.
Combined AWS Network Firewall deployment model:
This model (Figure-9) will be discussed case when traffic originated in Internet. In other words, Internet facing services need to be accessible from Internet and the goal is to inspect mentioned traffic using NF. There are several different possible architectures for this (an example is single centralized Ingress VPC for Internet ingress traffic).
Combined model: centralized for some type of traffic flows and distributed for other traffic flows and VPCs.
All traffic types discussed in previous models:
East-West/on-premises/egress Internet will remain the same flow and would be inspected by NF in centralized Inspect VPC.
Only some VPC that serves Internet ingress traffic would have their own NF endpoint in the VPC. It is important to mention that “own” NF would serve only Internet ingress traffic all types of East-West traffic inspection would be inspected as discussed in previous scenarios.
