Web filtering for education using AWS Network Firewall

Managing access to websites and safeguarding users from harmful content is a critical component of a layered cybersecurity approach, especially in educational settings. Schools and institutions of higher learning have a responsibility to provide a secure online experience for their students and staff. Traditionally, this has been accomplished through on-site web filtering appliances.

Amazon Web Services ( AWS) Network Firewall allows customers to filter their outbound web traffic from on-premises environments based on fully qualified domain names (FQDN) or Server Name Indication (SNI) for encrypted traffic. AWS managed rule groups can be used to block access to known malware and botnet threats. These predefined rules are written and maintained by AWS and automatically update when new vulnerabilities and threats emerge.

This post will use AWS Client VPN to demonstrate routing and filtering traffic from external resources through Network Firewall. In real-world scenarios, AWS Site-to-Site VPN or AWS Direct Connect would typically be used for connecting on-premises networks to AWS. The concepts discussed here related to routing and filtering traffic with Network Firewall apply regardless of the specific connectivity method used.

Architecture overview

Figure 1. Architecture overview of the solution described in this post. The diagram depicts a virtual private cloud (VPC) with six subnets across two AWS Availability Zones. Each Availability Zone contains three subnets: the protected subnets contain the NAT Gateway, the filter subnet contains the Network Firewall, and the client subnet contains the Client VPN endpoint. On-site users are depicted connecting to the VPC using Client VPN.

This solution uses a single VPC. Resources are deployed across two Availability Zones to provide a level of fault tolerance. Three subnets are deployed within each Availability Zone:

1. Client – After successful authentication with AWS Client VPN, users will land in this subnet.
2. Network Firewall filter – Contains the AWS Network Firewall endpoints where traffic originating from the client subnet will be routed.
3. Protected – Contains the AWS NAT Gateway, which enabled outbound internet access. All traffic originating from the filter subnet will be targeted towards this NAT Gateway.

The traffic flow from our on-premises users following the path is shown in Figure 2.

Figure 2. Diagram of the traffic flow. The image shows traffic flow starting at on-premises users and moving left to right from AWS Client VPN to AWS Network Firewall to AWS NAT Gateway before ending at Internet Gateway.

Solution walkthrough

For this guide, a single Availability Zone will be used. This simplifies the creation of a proof of concept and reduces development cost. In a production system, use at least two Availability Zones for high availability of the Network Firewall endpoints.

Figure 3. Architecture overview diagram, highlighting the subnets within Availability Zone 1 and their route tables.

Some resources will be created as part of this solution:

• Amazon Virtual Private Cloud (Amazon VPC) and subnets
• AWS Network Firewall and endpoint
• NAT and internet gateway
• Route tables
• AWS Network Firewall policy

Out of scope

This post does not cover deployment details for AWS Client VPN or authentication. For more details on configuring AWS Client VPN and authentication, refer to the following resources:

• Documentation: Getting started with AWS Client VPN
• Blog post: Authenticate AWS Client VPN users with AWS IAM Identity Center
• There are various methods to connect on premises or remote locations with AWS. This post uses AWS Client VPN as an example. For static locations, AWS Direct Connect or AWS Site-to-Site VPN would typically be used. The configuration of these is not covered in this post.
• This solution can also be tested from within AWS by provisioning an Amazon Elastic Compute Cloud (Amazon EC2) instance in the Client Subnet. Figures 1 and 3 show a testing instance within the Client Subnet. Use EC2 Instance Connect with an Instance Connect Endpoint to securely connect to the instance in a private subnet and run the tests.

Create VPC resources

Start by creating a VPC from the Amazon VPC console. You can use the VPC and More wizard.

1.  Uncheck the Auto-generate box.
2. Specify a CIDR range that meets your requirements (default is fine for testing).
3. Set the Number of Availability Zones (AZs) to 1.
4. Increase the number of private subnets to 2.
5. Enable NAT Gateways 1 per AZ.
6. Change VPC Endpoints to None; they are not required for this example.
7. Rename the resources according to the following tables. This helps with identification later. The preview screen (Figure 4) can be used to validate.
8. Create the VPC and wait for the workflow to complete.

Figure 4. VPC preview showing resources that will be created according to the preceding tables.

Create AWS Network Firewall and firewall endpoints

Network Firewall endpoints are similar to AWS PrivateLink endpoints. They allow traffic to be routed to a network firewall for inspection and filtering before continuing to its destination. This provides an effective way to increase security and control over network traffic flows.

1. 1. 1. Create the Firewall from the Amazon VPC console Network Firewall section using a descriptive name, as shown in Figure 5.
         

         Figure 5. Describe firewall. Depicts the naming of the firewall during the creation wizard on the AWS console using the example name “network-firewall-content-filter.”

      2. On the Configure VPC and Subnets page, select the VPC that was created earlier.
      3. Define the Firewall subnets, where the Network Firewall endpoints will be created. Just one subnet was created earlier to host the endpoints, one for each Availability Zone, as shown in Figure 6.
         

         Availability Zone	Subnet	IP address type
         1a	filter-nfw-subnet-1a	IPV4

         

         Figure 6. Configure VPC and subnets. Depicts the selection of each of the subnets where the AWS Network Firewall endpoints will be deployed according to the preceding table.

      4.  Accept the Configure advanced setting default configuration.
      5. Select Create and associate an empty firewall policy and name it “content-filter-fw-policy.” By default, the policy will automatically be associated with the firewall but will not contain any rules.
      6. For Rule evaluation order, keep the default setting of Strict order – recommended.
      7. Leave the Drop Action setting with its default configuration of Drop established. This setting is required for the proper functioning of domain-based filtering when using both strict order and custom domain list rule groups. The Network Firewall service needs the layer 3 and 4 connection to be established first in order to evaluate whether to allow or deny packets based on domain lists. Maintaining the default Drop established configuration will enable support for domain-based rules.
         

         Figure 7. Associate firewall policy. Shows the default settings that are kept. The new firewall policy name field has been filled with “content-filter-fw-policy.”

      8.  On the final screen, review the configuration, then create the firewall.
      9. Once the firewall has been created, retrieve the Endpoint ID of the endpoint, as shown in Figure 9. This is required for the next step of configuring the routing tables. Find the Endpoint ID from the Amazon VPC console Network Firewall section, under Firewall endpoints.

Update the route tables

Next, update the client and protected subnet route tables. The filter subnet route tables are already correctly configured.

1. Navigate to the route tables section of the Amazon VPC console and select client-subnet-route-table-az1, then go to Actions and Edit routes.
2. Replace the NAT Gateway route with a Gateway Load Balancer Endpoint using the Firewall endpoint ID for Availability Zone 1. All outbound traffic is now directed towards the Network Firewall endpoint, as shown in Figure 10.
   

   client-subnet-route-table-az1
   Destination	Target
   10.100.0.0/16	Local
   0.0.0.0/0	Firewall endpoint AZ-A

   

   Figure 9. Client subnet route table showing the selection of the Gateway Load Balancer Endpoint and endpoint ID to replace the NAT Gateway route.

3. Also update protected-subnet-route-table-az1. Change the local route target to the Endpoint ID of the Network Firewall; this allows symmetric routing, where return traffic is sent back to the Network Firewall.
   

   protected-subnet-route-table-az1
   Destination	Target
   10.100.0.0/16	Firewall Endpoint AZ-A
   0.0.0.0/0	Internet Gateway

   

   Figure 10. Protected subnet route table showing the selection of the Gateway Load Balancer Endpoint and endpoint ID to replace the local route.

Configuration of Network Firewall policy

1. 1. First, as shown in Figure 11, edit the Stateless default actions. Find this setting under the Firewall policy settings tab within the Firewalls section of the Amazon VPC console. Update the setting for Default actions for fragmented packets to Forward to stateful rule groups.
      

      Figure 11. Stateless default actions edit screen shows that the rule action for fragmented packets has been updated to Forward to stateful rule group.

Create stateful rule groups

In this example, the Domain-Filter-List denies access to amazon.com and amazon.co.uk domains for both HTTP and HTTPS traffic. These filter rules apply to any traffic from the client subnets CIDR ranges as specified in the Stateful-Rule-Set.

1. Create a Domain-filter-list stateful rule group from the firewall policy console Network Firewall rule groups tab with the following configuration changes, as shown in Figure 12. Leave everything else as default. This creates a new stateful rule group that blocks traffic to the specified domains while allowing all other traffic according to the default settings.
   

   Domain-Filter-List stateful rule group
   Name	Domain-Filter-List
   Capacity	10
   Traffic to inspect and action	HTTP, HTTPs DENY

   

   Figure 12. Domain-Filter-List summary page showing the settings configured in previous steps.

2. Create a Stateful-Rule-Set stateful rule group. This rule group contains rules for outbound traffic from the client subnet that Network Firewall should allow. Change the following settings, leaving everything else as default. You can locate the client subnet CIDRs from the Subnets section of the Amazon VPC console.

Figure 13. Stateful-Rule-Set variables, showing the configuration in the console according to the table.

Within the AWS console the Network Firewall stateful rule group should look like the example shown in Figure 14. The stateful rules can be further customised to meet your traffic filtering requirements.

Figure 14. Stateful-Rule-Set rules configuration in the console showing configuration according to the table.

Test the solution

Now test outbound filtering.

1. First, connect into the client subnet through the method you provisioned (such as client VPN or Amazon EC2 instance) and confirm traffic is routing out of the NAT gateway. A simple test is to check your external IP address. If traffic is successfully routing out of the VPC, then it will be the IP of the NAT gateway.

Figure 15. Check public IP. Depicts the output of the curl ifconfig.me command and the NAT Gateway console.

2. Once confirmed traffic from a local device or a device within the client subnet is routing out the NAT gateway in AWS, check that the domain filtering rules are working. Run two curl commands from the terminal on your local device:

a) curl -v https://amazon.de ; expect a TLS handshake and successful connection

b) curl -v https://amazon.co.uk ; expect Operation timed out

[ec2-user@ip-10-100-173-7 ~]$ curl -v https://amazon.de

* Trying 176.32.108.185:443…

* Connected to amazon.de (176.32.108.185) port 443

* ALPN: curl offers h2,http/1.1

* TLSv1.3 (OUT), TLS handshake, Client hello (1):

* CAfile: /etc/pki/tls/certs/ca-bundle.crt

* CApath: none

* TLSv1.3 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256

* ALPN: server accepted http/1.1

* Server certificate:

* subject: CN=*.peg.a2z.com

* start date: Jul 15 00:00:00 2023 GMT

* expire date: Mar 22 23:59:59 2024 GMT

* subjectAltName: host “amazon.de” matched cert’s “amazon.de”

* issuer: C=US; O=DigiCert Inc; CN=DigiCert Global CA G2

* SSL certificate verify ok.

* using HTTP/1.1

> GET / HTTP/1.1

> Host: amazon.de

> User-Agent: curl/8.3.0

> Accept: */*

>

[ec2-user@ip-10-100-173-7 ~]$ curl https://amazon.com

curl: (28) SSL connection timeout

Cleanup

To avoid ongoing charges, remove resources that were created as part of this walkthrough. Resources that should be deleted if applicable are (in order):

1. Client VPN endpoint. You must first remove all associations that were created for the endpoint.
2. Network Firewall; including rule groups, policies, and endpoints.
3. Internet gateway
4. NAT gateways
5. Subnets and route tables
6. VPC

Conclusion

In this post, we demonstrated how AWS Network Firewall can provide outbound web filtering and stateful packet filtering for external traffic, including remote users and on-premises resources.

Using AWS Network Firewall enables the creation of a resilient, scalable cloud-based filtering solution, reducing the need for on-premises equipment. Combining custom domain and stateful filtering rule groups with AWS managed rule groups helps save time and stay current with the constantly evolving security landscape. AWS automatically updates the managed rule groups as new vulnerabilities and security issues emerge.

If you have feedback about this post, submit comments in the comments section. If you have questions about this post, contact AWS Support.