# AWS Network Firewall Proxy Developer Guide Network Firewall Proxy Guide ## Overview of Network Firewall Proxy **Note** Network Firewall Proxy is in public preview release and is subject to change. AWS Network Firewall proxy is an AWS managed service that offers granular security controls to inspect and filter your AWS Virtual Private Cloud (VPC) outbound connections to prevent data exfiltration and malware intrusion. For more information on Virtual Private Clouds, see [here](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html). The proxy acts as an intermediary between your workloads and the internet, inspecting and filtering traffic to comply with your security policies. You can configure your applications to route HTTP and HTTPS traffic via the Proxy. You can set appropriate security policies in your proxy to define the trust perimeter for your clients and describe what response is acceptable from the destinations. Your proxy filters both the outbound requests from your clients and the inbound response from the allowed destinations based on the security policies you set. You can choose to configure your proxy to decrypt HTTPS traffic and filter it based on any of the header attributes including the URL path, header verb, and other attributes. Network Firewall proxy is a fully managed system that is built with scale and resilience. You can use it to eliminate the operational overhead of maintaining custom DIY proxy solutions and complex logging systems. It provides centralized control and visibility into all outbound web and inter-network communication. ## Key benefits and Use Cases 1. Security Compliance & Auditing - Addresses security and compliance requirements for outbound web and inter-network traffic. Provides comprehensive visibility into traffic VPC outbound traffic. 1. Provides tight access control by verifying source clients using VPC ID, VPC endpoint ID, account ID, and IP CIDR. 1. Manages which domains and subdomains applications can be accessed by workloads, including allowlisting and denylisting capabilities. Blocks unnecessary outbound traffic. Provides HTTP method restrictions. 1. Actively blocks DNS tunneling attempts to prevent unauthorized data exfiltration, while implementing robust domain validation to guard against SNI spoofing attacks. 1. Filters response traffic based on content type and length. 1. Provides TLS interception capabilities. 1. Reduces maintenance and scaling overheads of maintaining DIY proxy solutions. ## Glossary and key terms Understanding these key terms will help you work effectively with Network Firewall Proxy. **AWS NAT Gateway** AWS service that allows resources in your private subnets to securely communicate with external destinations, including the internet, while protecting them against any unsolicited traffic. **Virtual private cloud (VPC)** A logically isolated virtual network to host your resources. **Proxy configuration** A Proxy Configuration defines the monitoring and protection behavior for a Proxy. The details of the behavior are defined in the rule groups that you add to your configuration. **Phases** Evaluation points in the traffic flow where rules are applied. There are three phases in a traffic where the rule match is applied. They are: 1. Pre-DNS - before domain resolution. 1. Pre-request - after DNS, before request. 1. Post-response - after receiving response. **Rule Groups** Collections of related proxy filtering rules. Rule groups help you manage and reuse sets of rules across multiple proxy configurations. **Rules** Individual rules that define match conditions and actions for application-layer traffic. Rules specify what to inspect (domains, headers, methods) and what action to take (allow, deny, alert). Evaluation of rules happens in this same order as phases. **Proxy** Attaches a Proxy configuration to a NAT Gateway. **Conditions** Match criteria that specify what traffic attributes to examine. Conditions include operators (StringEquals, StringLike) and values to match against. **Insert Position** The priority order of rules within each phase type. Lower numbers have higher priority and are evaluated first. **Private Link endpoints** AWS PrivateLink is a highly available, scalable technology that you can use to privately connect your VPC to services and resources, as if they were in your VPC. For more information, check [here](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html). **DNS Exfiltration** A technique used to transfer data out of a secured network by encoding that data into DNS queries. **SNI (Server Name Indication)** An extension of the TLS protocol that indicates the hostname being contacted by the client during the TLS handshake, allowing servers to present the appropriate SSL certificate when hosting multiple domains on a single IP address. **TLS Intercept** The process of decrypting and re-encrypting TLS traffic for inspection and filtering on HTTP headers. **Trust Perimeter** The boundary between trusted internal networks and untrusted external networks. **URI Path** The specific location of a resource within a domain. # How does Network Firewall Proxy work? **Note** Network Firewall Proxy is in public preview release and is subject to change. ## Core components of each Proxy A Network Firewall Proxy deployment consists of several key components that work together to provide application-layer filtering. 1. **Proxy Configuration** – A Proxy Configuration is a top level container that defines the monitoring and protection behavior for a Proxy. The details of the behavior are defined in the rule groups that you add to your configuration. Each proxy configuration has a unique identifier, You can use a single proxy configuration across multiple proxies. While setting up a Proxy configuration, you need: + Configuration name and description + Associated rule groups + Default action for unmatched traffic 1. **Rule Group** – A collection of filtering rules organized in order of your desired priority. Your traffic is matched against these rules in the order of their priority. Depending on the match action, the proxy either stops the evaluation (if the action is terminal - allow or deny), or continues evaluation (if the action is alert) until it matches a rule with a terminal action. Each proxy configuration includes a default empty rule group, and individual rule groups support up to 1,000 rules maximum. 1. **Filtering Rules** - Filtering rules are the fundamental components of proxy configuration, controlling how traffic is processed and managed. Each rule operates as part of a systematic traffic evaluation process, combining specific match conditions with defined actions. You can configure your rule to evaluate the traffic in three different phases - pre-DNS, pre-request and post-response. **Rule Processing Logic -** The proxy evaluates rules sequentially in order of priority. Rules are processed in order based on their insert position, with lower numbers receiving higher priority. Within each phase, evaluation continues until the first matching rule is found. When a rule matches, the outcome follows strict patterns: a deny action immediately blocks traffic and terminates all further rule processing; an allow action stops processing in the current phase but requires and continues evaluation in subsequent phases; and an alert action logs the event while allowing evaluation to continue. For example, if a rule in the early phase matches and allows traffic, the proxy proceeds to evaluate rules in the next phase. However, a deny action at any point immediately blocks the traffic, regardless of any remaining rules. **Proxy Endpoint** – It is a PrivateLink interface endpoint that carries traffic between the client and the Proxy. ## Traffic flow management and inspection Network Firewall Proxy manages and inspects traffic through multiple phases, providing comprehensive filtering and security controls at each step. When your client sends a CONNECT request to the proxy, the proxy evaluates the filtering rules in the pre-DNS phase of the associated Proxy Configuration, using the client identity and destination domain metadata available to it. This protects your workloads against any exfiltration via the DNS. If the request is allowed to proceed based on the filtering rules defined for this Proxy,the Proxy then performs a DNS query with the requested domain and resolves the destination IP address. The Proxy then establishes a TCP connection with the end destination and sends a response to the client acknowledging the request. When the client sends the TLS traffic to the proxy, the proxy then filters it based on IP address, or header attributes (only if TLS interception is enabled). Finally, the Proxy inspects the response from the destination and filters based on content type or length (only when TLS interception is enabled). **Note** Network Firewall proxy preview supports only HTTP/1.1 protocol. HTTP/2 (H2) and HTTP/3 (H3) traffic will not be supported – these connections may be dropped or result in timeouts. Ensure your applications use HTTP/1.1 when routing through the Network Firewall proxy during the public preview timeframe. ### Traffic Flow Phases Understanding how traffic flows through the proxy helps you design effective filtering rules. The proxy intercepts egress traffic at multiple points in the connection lifecycle: **Pre-DNS Phase** Triggered when a request from an application would require the Proxy to resolve a domain name. At this stage, you can examine the requested domain, source IP address, source VPC, and source AWS account.These rules can allow or deny the connection request before the Proxy makes the DNS query. Example PreDNS use cases: + Block access to known malicious domains + Implement domain allow-lists for approved external services + Restrict DNS resolution based on source account or VPC **Pre-request Phase** Triggered after successful DNS resolution but before the HTTP request is is sent to the end server. At this stage, you can examine the resolved IP address, the destination ports and header attributes including HTTP method, URL path, etc. Rules can allow or deny the request based on these attributes. Without TLS decryption, you can only filter based on IP in the pre-request phase. Rules which match on HTTP fields will not match for HTTPS requests unless you have turned on TLS intercept. Example Pre-request use cases: + Block HTTP POST requests to prevent data uploads (Turn on TLS intercept) + Require specific authentication headers (Turn on TLS intercept) + Restrict access to specific IP ranges or ports **Post-response Phase** Triggered after receiving the HTTP response but before returning it to the client. At this stage, you can examine response headers, HTTP status codes, and response content types. Rules can allow or deny the response based on these attributes. Example Post-response use cases: + Block responses containing specific content types (images, executables) Rules are evaluated in order within each phase. The first matching rule determines the action. If a rule denies traffic at any phase, the connection is terminated and subsequent phases are not evaluated. However, if the traffic is allowed or alerted in the pre-DNS phase, it will still be evaluated against pre-Request and post-response phase rules. # Architecture overview **Note** Network Firewall Proxy is in public preview release and is subject to change. This section provides a high-level view of simple architectures that you can configure with AWS Network Firewall Proxy. AWS Network Firewall Proxy is configured on your NAT Gateway and inspects traffic from your workloads in your VPC before the network address translation is performed. To implement the service, associate your proxy configuration with the NAT Gateway that handles your outbound traffic. To access the Proxy, you must set up the HTTP\$1PROXY, HTTPS\$1PROXY, and NO\$1PROXY environment variables appropriately on your applications. The proxy comes with a fully qualified domain name which resolves to the IP address of a PrivateLink interface endpoint that is used to carry your traffic to and from the proxy for inspection before it reaches the internet. For more information on setup, see details in [Pre-requisites](proxy-pre-requisites.md). **Note** The proxy uses the DHCP options of the VPC that it is present in. You can either configure the Network Firewall Proxy in the same VPC as your applications or centrally in a separate VPC. When configured centrally in a separate VPC, it can be accessed using PrivateLink endpoints or Transit Gateway. We will discuss these three architecture below. 1. Dedicated VPC Model: Deploy individual Network Firewall Proxies within each VPC for isolated, per-VPC traffic control and security policies. 1. Centralized Proxy Model: Configure a single, central proxy serving multiple VPCs through proxy endpoints, enabling consistent security policies across your infrastructure. 1. Transit Gateway Deployment: Leverage AWS Transit Gateway for connecting multiple VPCs with non-overlapping CIDR blocks to a centralized proxy, providing scalable network security for complex multi-VPC architectures. ## 1. Dedicated VPC Proxy Architecture When the Network Firewall Proxy and the Applications are in the same VPC. This architecture provides complete isolation and independent control over proxy configurations for each VPC. Traffic from applications within a VPC flows through its designated proxy before reaching the NAT Gateway for internet access. ![\[alt text not found\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/dedicated-vpc-proxy.png) **Note** When you create a VPC endpoint, AWS automatically creates a private hosted zone that resolves the FQDN of the proxy to the IP address of the endpoint. ## 2. Centralized Proxy Architecture With Proxy Endpoints This architecture implements a centralized AWS Network Firewall Proxy that serves multiple VPCs through proxy endpoints. The proxy resides in a dedicated security VPC, while proxy endpoints are automatically created in each connected application VPC. Traffic from all application VPCs flows through these endpoints to the central proxy before reaching the internet. ![\[alt text not found\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/centralized-proxy.png) ## 3. Transit Gateway Integration Architecture For environments with non-overlapping CIDR ranges, you can leverage AWS Transit Gateway (TGW) to connect multiple VPCs to a centralized proxy. This architecture extends the centralized proxy model by using TGW as the connectivity layer between application VPCs and the security VPC hosting the proxy. ![\[alt text not found\]](http://docs.aws.amazon.com/network-firewall/latest/developerguide/images/tgw-proxy.png) # Pre-requisites ## Related services and prerequisites **Note** Network Firewall Proxy is in public preview release and is subject to change. NFW proxy operates as an explicit proxy. No routing rules are required, but workloads need to be configured to route traffic through the proxy. Before implementing Proxy, ensure you have the following prerequisites in place ### NAT Gateway You must have an existing NAT gateway configured in your VPC. The proxy attaches to NAT gateways to inspect egress traffic. For information about creating a NAT Gateway, see [Creating a NAT Gateway](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-creating). In addition, make sure that these are configured in the VPC that you are setting up the NAT Gateway. In addition to creating the NAT Gateway, customers need to ensure that their VPC has these fields enabled, if not proxy creation will fail asynchrously today.VPC attributes: enableDnsSupport and enableDnsHostnames. Otherwise, the proxy setup will fail. . Error message/failure seen when proxy provisioning fails today on describes: VPC attributes enableDnsSupport and enableDnsHostnames should be set to true to allow proxy on NAT Gateway ### IAM permissions You need appropriate IAM permissions to create and manage proxy configurations, attach them to NAT gateways, and view logs and metrics. See [Proxy Permissions](#proxy-permissions) for detailed permission requirements. ### Proxy endpoints When a proxy is created and attached to a NAT Gateway, a Private Link endpoint is automatically created in the same subnet as the associated NAT Gateway. 1. For applications hosted in the same VPC as the Proxy, there is no need to create a Private Link endpoint. 1. For applications hosted in a different VPC than the Proxy, a Private Link endpoint needs to be created in each VPC that needs outbound traffic filtering through the Proxy. This is only needed when the other VPC can't route traffic to the proxy endpoint **Create a VPC endpoint to access Proxy** Use the following procedure to create a VPC endpoint that connects to Proxy. **Prerequisite** Create a security group for the VPC endpoint that allows traffic to and from the Proxy to the VPC. Add a rule that allows HTTPS traffic, TCP traffic and the required port range from the VPC CIDR block. For more information on setting up policies in security groups, [visit here](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html). **To create a VPC endpoint for Proxy:** 1. In the AWS NFW proxy console, after you create the proxy, click on the proxy to view details. You will be able to see the VPC service endpoint service name here. Note the VPC service endpoint service name and that it will come in handy. 1. Open the Amazon VPC console. 1. Now, In the navigation pane, choose **Endpoints**. 1. Choose **Create endpoint**. 1. For **Name tag**, enter a name for the endpoint. 1. For **Service category**, choose **AWS services**. 1. Under Endpoint settings -> **Service type**, select the **Endpoint services that use NLB and GWLB** 1. Under **Service settings,** put in the name that the Proxy provides them. You can obtain this name by looking at the VPC endpoint service name under the Proxy details page that you took from step 1. 1. Under **additional settings**, enable **Private DNS name.** 1. For **VPC**, select your VPC. 1. For **Subnets**, select the Availability Zone and then select the private subnet. 1. For **Security group**, select the security group for the VPC endpoint. 1. For **Policy**, select **Full access** to allow all operations by all principals on all resources over the VPC endpoint. 1. (Optional) To add a tag, choose **Add new tag** and enter the tag key and the tag value. 1. Choose **Create endpoint**. The initial status is **Pending**. Before you go to the next step, wait until the status is **Available**. This can take a few minutes. ### Setup Trust between your applications and the Proxy If you plan to do TLS interception and filter on header attributes using the Proxy, you will need to setup trust between your applications and the Proxy. NFW Proxy supports Private Certificate Authority as a mechanism for you to provide a CA certificate. You can either create a Private CA using AWS Private Certificate Authority (PCA) or bring your own external enterprise CA and use it to sign a subordinate CA on AWS PCA. In either case, please ensure to include the root certificate to the trust store of your applications. The proxy presents PCA-signed certificates which applications trust through the same root, establishing a secure and consistent trust model for encrypted communication. For more information on how to manage certificates using PCA, check here - https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html **First give Proxy access to PCA through these steps:** 1. Go to AWS console → cert authority → the PCA console. 1. Go to managed resource shares. 1. Create new resource share. 1. Add a name. 1. Select the resource type as Private CA. 1. Select the resource from the drop down menu Under managed permissions, select AWSRAMSubordinateCACertificatePathLen0IssuanceCertificateAuthority. 1. Click Next. 1. Grant access to service principle. 1. Enter the service principal name. It should be proxy.network-firewall.amazonaws.com. **Important** Do not skip the below step. Skipping this step may expose your system to confused deputy attacks. To restrict this permission to a specific proxy ARN, use the PCA put-policy API to create a policy with the service principal. In order to ensure your PCA resource is used only in the context of your Network Firewall Proxy resource, we recommend attaching a resource policy that is appropriately scoped to your PCA resource, using the `aws:SourceArn `or `aws:SourceAccount` global condition keys. See below: ``` aws acm-pca put-policy \ --resource-arn arn:aws:acm-pca:us-east-2::certificate-authority/ \ --policy file:///path/to/policy.json \ --region us-east-2 ``` See below for an example policy: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "proxy.network-firewall.amazonaws.com" }, "Resource": "arn:aws:acm-pca:us-east-2::certificate-authority/", "Action": [ "acm-pca:GetCertificate", "acm-pca:DescribeCertificateAuthority", "acm-pca:GetCertificateAuthorityCertificate", "acm-pca:ListTags", "acm-pca:ListPermissions" ], "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:network-firewall:us-east-2::proxy/" } } }, { "Effect": "Allow", "Principal": { "Service": "proxy.network-firewall.amazonaws.com" }, "Action": [ "acm-pca:IssueCertificate" ], "Resource": "arn:aws:acm-pca:us-east-2::certificate-authority/", "Condition": { "StringEquals": { "acm-pca:TemplateArn": "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1" }, "ArnEquals": { "aws:SourceArn": "arn:aws:network-firewall:us-east-2::proxy/" } } } ] } ``` For more details, see [Securely configuring your PCA resource for use with AWS Network Firewall Proxy](proxy-security.md#proxy-pca-configuration). 1. Click next. 1. Review the details and click on create. Then, during the Proxy creation or modification, you need to select the checkbox for TLS intercept and enter the ARN of the PCA. Also, make sure you have setup your application to trust the PCA. Note: Console based permission setup should only be used using test PCA resources. ### Proxy variables You must set up the proxy variables on your applications to route HTTP and HTTPS traffic through the proxy for inspection. Make sure to setup the proxy endpoints first. To set up proxy variables, you can use the fully qualified domain name of the proxy. You can find the domain name in the console under details of the proxy. This domain name resolves to the IP address of the proxy endpoint in your VPC and allows your traffic to be routed via the proxy. For instructions on how to setup variables on workloads, you can refer this. https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-proxy.html The most common way to route traffic to an explicit proxy is by using proxy environment variables. You can use http\$1proxy, and https\$1proxy variables to route http and https traffic to the proxy. You can combine it with no\$1proxy variable to exclude private and other trusted destinations that can bypass the proxy. As an example: ``` HTTP_PROXY=http://proxy-server-hostname:port HTTPS_PROXY=https://proxy-server-hostname:port NO_PROXY='amazonaws.com,127.0.0.1,localhost' ``` ## Setting up This tutorial is covered in the Network Firewall firewall documentation under Setting up and covers topics such as signing up for an AWS account, creating a user with administrative access and setting up tool access. For more details, please refer [here](https://docs.aws.amazon.com/network-firewall/latest/developerguide/setting-up.html). ## Proxy Permissions To work with Proxy, you need specific IAM permissions for creating configurations, managing rules, and attaching proxies to NAT gateways. For details on how to add IAM permissions, please check IAM documentation [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-managing-iam.html). ### Proxy management permissions The following permissions are required for creating and managing proxy configurations: **Important** For production deployments, follow the principle of least privilege and restrict permissions to specific resources using resource ARNs instead of wildcards. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "network-firewall:CreateProxyConfiguration", "network-firewall:UpdateProxyConfiguration", "network-firewall:DeleteProxyConfiguration", "network-firewall:DescribeProxyConfiguration", "network-firewall:ListProxyConfigurations" ], "Resource": "*" } ] } ``` ### Rule management permissions The following permissions are required for creating and managing proxy filtering rules: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "network-firewall:CreateProxyRulegroups", "network-firewall:ModifyProxyRulegroups", "network-firewall:DeleteProxyRulegroups", "network-firewall:DescribeProxyRulegroups", "network-firewall:ListProxyRulegroups" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "network-firewall:CreateProxyRules", "network-firewall:ModifyProxyRules", "network-firewall:DeleteProxyRules", "network-firewall:DescribeProxyRule" ], "Resource": "*" } ] } ``` ### NAT Gateway attachment permissions The following permissions are required for attaching proxy configurations to NAT gateways: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "network-firewall:CreateProxy", "network-firewall:DeleteProxy", "network-firewall:DescribeProxy", "network-firewall:ListProxies", "ec2:DescribeNatGateways", "ec2:AttachApplianceOnNatGateway", "ec2:DetachApplianceFromNatGateway" ], "Resource": "*" } ] } ``` ### Monitoring and logging permissions The following permissions are recommended for monitoring proxy activity and viewing logs: ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "cloudwatch:PutMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics" ], "Resource": "*" } ] } ``` ### VPC Endpoint permissions Create/delete and describe permissions on VPC Endpoints. Note: Proxy creation will fail if these permissions for VPC endpoints are not provided. ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoint", "ec2:DescribeVpcEndpoints" ], "Resource": "*" } ] } ``` # Getting started with Network Firewall Proxy **Note** Network Firewall Proxy is in public preview release and is subject to change. AWS Network Firewall Proxy provides network traffic filtering and protection for your applications hosted in Amazon VPCs and on-premises environment. This tutorial provides steps for getting started with Network Firewall Proxy using the AWS Management Console. You can also use Network Firewall API operations to create and manage your firewalls. For more information about working with Network Firewall API operations, see the *AWS Network Firewall Proxy Reference.* ## Before you begin This tutorial walks you through the steps required to configure your Proxy in the same VPC as your application., like the one depicted in the [Architecture overview](proxy-architecture-overview.md). To follow this tutorial, you'll need a test VPC where you want to configure a Network Firewall Proxy . Additionally, ensure you have set up all the prerequisites until pre-requisite step 4 (setting up trust) as mentioned in the [Pre-requisites](proxy-pre-requisites.md). ## High-level steps for implementation Setting up Network Firewall Proxy involves the following main configuration steps: 1. **Create Rule Groups** – Create rules to define your security controls, specifying which phase each rule should be applied in (pre-DNS, pre-request, or post-response). You can create multiple rules within each rule group to handle different security requirements. 1. **Configure Proxy Configuration** – Set up your proxy configuration by defining default (catch-all) rules for each phase (pre-DNS, pre-request, or post-response) and attaching the relevant rule groups created in step 1. This configuration establishes the processing order and priority for rule evaluation. 1. **Create Proxy** – While creating the proxy, you must select the NAT Gateway that it is created on. The Proxy uses this NAT Gateway for network address translation 1. Test and validate the proxy behavior 1. Monitor logs and metrics for proper operation These steps work together to create a complete proxy configuration that processes and secures your outbound traffic according to your security policies. ## Step 1. Creating Rule Groups A Rule Group in VPC proxy is a reusable collection of ordered access control rules (ACLs) used to evaluate and filter HTTP/s traffic. For information about Rule Groups, see [Managing Your Rule Groups](managing-proxy-rule-groups.md). **To create a Rule Group** 1. Sign in to the AWS Management Console and open the Amazon VPC console. 1. In the navigation pane, under **Network Firewall Proxy**, choose **Proxy rule groups**. 1. Choose **Create rule group.** 1. Enter a name. 1. Optionally enter the description for your Rule Group and add a tag. 1. Click Next. 1. Enter the phase to which this rule would apply. If you want the rule to apply to all 3 phases, select all 3 phases (Note: This will create 3 different rules for each phase). 1. Next, enter the action that you would like to take on the traffic. This can be allow, deny or alert. 1. Optionally, enter a description for the rule. 1. Enter the conditions, operators and values. Condition operators will be used to define how to perform a match. This is similar to how conditions are defined in AWS IAM service. For more details, look [here](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html). Condition keys define what is to be matched. Condition value specifies the exact value that needs to be matched against. For example, if you want to deny traffic for certain social media sites, you would define the following: + Rule group name: Deny social media. Create a rule with the following + Action: deny. + Description: Rule that will deny if requests attempt to go to social media websites. + ConditionOperator: "StringLike" + ConditionKey: "request:DestinationDomain" + "ConditionValues": [ \$1facebook.com, \$1instagram.com, wa.com, whatsapp.net, whatsapp.com, x.com ] 1. Click next 1. Review the details and click Create ## Step 2. Creating Proxy Configuration Proxy configurations use rule groups and other settings to define the traffic filtering behavior for a Proxy. In this procedure, you'll create a Proxy configuration using the rule groups that you created in the previous step. For information, see [Managing Your Proxy Configuration](managing-proxy-configuration.md). **To create a Proxy configuration** 1. Sign in to the AWS Management Console and open the Amazon VPC console. 1. In the navigation pane, under **Network Firewall Proxy**, choose Proxy configuration 1. Choose Create Proxy configuration 1. Enter a name, optionally enter a description 1. Under default action, choose an action for each phase of the traffic. This will determine what will happen to traffic incase it does not match any rules. 1. Optionally add a tag 1. Click next 1. Click on attach rule group 1. Set a priority for the rule group. Lower the number means higher the priority. 1. Select the rule group that you created in the last step from the drop down. 1. Click Attach. 1. Check to make sure your rule group shows up in the attach rule group screen and click next. 1. Review the details and click create. ## Step 3. Creating Proxy Configure and deploy Proxy with NAT Gateway associations. A proxy configuration serves as the container for your filtering rules and settings. You create the configuration first. Then you attach it to one or more NAT gateways to enable traffic inspection. Note: If the proxy creation fails and you need to attach another proxy to the NAT Gateway, you will need to delete the proxy resource that failed and then try to attach a new proxy. **To create a Proxy** 1. Sign in to the AWS Management Console and open the Amazon VPC console. 1. In the navigation pane, under **Network Firewall Proxy**, choose Proxy 1. Enter a name. 1. Add the proxy configuration that you created in the previous step from the dropdown. 1. Attach to the right NAT Gateway. 1. Optionally, if you want to perform TLS interception on your traffic to filter on attributes in the HTTP header, check the box to enable TLS intercept mode. These are optional values you can enter: 1. TLS interception \$1 PCM 1. Listener ports 1. AWS account number 1. Logging configuration 1. Tags 1. Select a certificate (in PCA) from the dropdown with which the Proxy can establish trust with your applications. 1. Under VPC settings, select the NAT GW ARN from the dropdown that you want to associate the Proxy with. 1. Next, Enter the listener ports, usually it would be 8080 and 443 for HTTP and HTTPS traffic. 1. Next, enter your AWS account number. 1. Optionally, add tags. 1. Click Next. 1. Review the details and click Create. Your configuration is now complete. You can setup your proxy variables on the workloads as mentioned in [Pre-requisites](proxy-pre-requisites.md) and send traffic from your VPCs and test out the proxy. # Managing Your Rules **Note** Network Firewall Proxy is in public preview release and is subject to change. **Proxy Rules** - proxy rules are the fundamental components of proxy configuration, controlling how traffic is processed and managed. Each rule operates as part of the traffic evaluation process, combining specific match conditions with defined actions. Each rule must be associated with exactly one rule group and defines the core logic for filtering, inspecting, and handling HTTP/HTTPS traffic. ## Rule Structure A filtering rule requires these components: + Rule name - The name serves as a unique identifier (such as "block-social-media" or "allow-aws-apis"), while the description documents the rule's purpose and function. + Phase - The phase type determines the processing stage (PreDNS, PreREQUEST, or PostRESPONSE). Match conditions establish the criteria for traffic evaluation with operators and values. + Action - The action specifies the response to matching traffic (allow, deny, or alert) + Position - The insert position determines priority ordering within the rule sequence. The rules within a rule group have priority + The rule groups within a proxy configuration have priority. + Rule Conditions - Conditions are specified as an array where all criteria must be met for the rule to trigger (logical AND). Each rule can belong to only one rule group at a time, ensuring clear organizational structure and preventing conflicts. **Condition keys:** `request:SourceAccount` `request:SourceVpc` `request:SourceVpce` `request:Time` `request:SourceIp` `request:DestinationIp` `request:SourcePort` `request:DestinationPort` `request:Protocol` `request:DestinationDomain` `request:Http:Uri` `request:Http:Method` `request:Http:UserAgent` `request:Http:ContentType` `request:Http:Header/CustomHeaderName` `response:Http:StatusCode` `response:Http:ContentType` `response:Http:Header/CustomHeaderName` **Note** Without TLS decryption, you can only filter based on IP in the pre-request phase. Rules which match on HTTP fields will not match for HTTPS requests unless you have turned on TLS intercept. ## Rule operations Network Firewall Proxy provides several operations to manage your proxy rules effectively. These actions allow you to create, modify, delete, and monitor rules within your rule groups. On the console, all the above rule operations can be performed only within a rule group. On the AWS console, click on rule groups and select the rule that you want to perform the operation on. Here are the available rule management actions: + Create Rules - Adds new rules to an existing rule group. + Delete Rules - Removes specified rules from a rule group. + Modify Rule - Updates existing rule, including the action or conditions for a specified rule. + Describe Rule - Retrieves detailed information about a specific rule. + List Rules - Displays all proxy rule resource names associated with an account. ## Managing proxy rule priority and evaluation order Understanding rule evaluation order is crucial for creating effective proxy policies. Rules are evaluated in a specific sequence. This sequence determines which rules take precedence. **Traffic Phases evaluation order** Rules are evaluated in the following traffic phase order, and this sequence cannot be changed: 1. Pre-DNS – Evaluated before domain name resolution 1. Pre-request – Evaluated after DNS resolution but before sending the HTTP/s request 1. Post-response – Evaluated after receiving the HTTP/s response **Note** If a rule in an earlier phase denies traffic, subsequent phases are not evaluated for that connection. **Within-phase priority** Within each phase type, rules are evaluated by insert position in ascending order (0, 1, 2, 3, etc.). The first rule that matches determines the action taken. Lower insert position numbers have higher priority. Example rule evaluation sequence: ``` PreDNS Rules: 1. insertPosition: 0 - Allow *.amazonaws.com (matches. action: ALLOW) 2. insertPosition: 1 - Deny *.com (not evaluated - previous rule matched) PreREQUEST Rules: 1. insertPosition: 0 - Deny POST methods (no match) 2. insertPosition: 1 - Allow GET methods (matches. action: ALLOW) PostRESPONSE Rules: 1. insertPosition: 0 - Alert on 5xx status codes (matches. action: ALERT + ALLOW) ``` In the above sequence, traffic to \$1.amazonaws.com is first evaluated by Pre-DNS rules, where it matches and is allowed by the first rule. In the Pre-request phase, since it's a GET method (not POST), it doesn't match the first rule and matches the second rule allowing GET methods. Finally, if this traffic returns a 5xx status code, it will trigger an alert in the Post-response phase while still being allowed through. If a new rule is added to the list of rules, then the rules get down shifted. If a rule is added to a certain position where another rule already exists, then the rules automatically be re-ordered, existing rules will move down the priority order. ## Example filtering rules These examples demonstrate common proxy filtering patterns that address typical security and compliance requirements. **Account-based access control** Restrict DNS resolution to specific AWS accounts: ``` { "proxyRuleName": "allow-trusted-accounts", "description": "Allow DNS resolution from trusted AWS accounts only", "action": "allow", "insertPosition": 1, "conditions": [ { "conditionKey": "request:SourceAccount", "conditionOperator": "StringEquals", "conditionValues": ["&ExampleAccountNo1;", "&ExampleAccountNo2;"] } ] } ``` **VPC-based blocking** Block requests from specific VPCs: ``` { "proxyRuleName": "block-untrusted-vpcs", "description": "Block requests from untrusted VPCs", "action": "deny", "insertPosition": 2, "conditions": [ { "conditionKey": "request:SourceVpc", "conditionOperator": "StringEquals", "conditionValues": [ "vpc-094feb95245dfde25", "vpc-0b8f8319f8db21ba1" ] } ] } ``` **Custom header validation** Require specific authentication headers: ``` { "proxyRuleName": "require-auth-token", "description": "Allow requests with valid authentication token", "action": "allow", "insertPosition": 1, "conditions": [ { "conditionKey": "request:Http:Header/x-auth-token", "conditionOperator": "StringEquals", "conditionValues": ["valid-token-value"] } ] } ``` **Port-based monitoring** Alert on connections to high-numbered ports: ``` { "proxyRuleName": "monitor-high-ports", "description": "Alert on connections to ports above 8000", "action": "alert", "insertPosition": 10, "conditions": [ { "conditionKey": "request:DestinationPort", "conditionOperator": "NumericGreaterThan", "conditionValues": ["8000"] } ] } ``` **Error response monitoring** Alert on server error responses: ``` { "proxyRuleName": "alert-server-errors", "description": "Alert on HTTP 5xx server errors", "action": "alert", "insertPosition": 1, "conditions": [ { "conditionKey": "response:HttpStatusCode", "conditionOperator": "NumericGreaterThanEquals", "conditionValues": ["500"] } ] } ``` # Managing Your Rule Groups ## Creating Rule Groups **Note** Network Firewall Proxy is in public preview release and is subject to change. A Rule Group in VPC Proxy is a reusable collection of ordered access control rules (ACLs) used to evaluate and filter HTTP/s traffic. **To create a Rule Group** 1. Sign in to the AWS Management Console and open the Amazon VPC console. 1. In the navigation pane, under **Network Firewall Proxy**, choose **Proxy rule groups**. 1. Choose **Create rule group**. 1. Enter a name. 1. (Optional) Enter a description for your rule group and add a tag. 1. Choose **Next**. 1. Enter the phase to which this rule applies. To apply the rule to all three phases, select all three phases. This creates three different rules for each phase. 1. Enter the action that you want to take on the traffic. This can be allow, deny, or alert. 1. (Optional) Enter a description for the rule. 1. Enter the conditions, operators, and values. Condition operators define how to perform a match. Condition keys define what is to be matched. Condition values specify the exact value that needs to be matched against. 1. Choose **Next**. 1. Review the details and choose **Create**. ## Rule group operations Network Firewall Proxy enables you to organize and manage collections of rules through rule groups. These rule groups can exist independently of proxy configurations and provide efficient rule management. Here are the available rule group management actions: **Create rule group** Creates a new rule group that can contain multiple rules. The rule group can exist independently without requiring a proxy configuration. **Modify rule groups** Remove/ add rules to a rule group. **Modify rule priorities** Reorders rules within a rule group based on phase type. This allows you to adjust rule priorities, where rules with lower index positions receive higher priority. **Delete rule group** Removes the specified rule group and all its associated rules. 1. Make sure your rule groups is not being used in any proxy. If rule group is being used, you will receive an error. 1. Click on rule group. 1. Click on the delete button. 1. It will take a while for this rule group to get deleted but the rule group cannot be used anymore. **Describe rule group** Retrieves detailed information about a specific rule group configuration. 1. On the AWS console, click on rule groups. 1. Select the rule group to list all the rules under that rule group. **List rule groups** Displays all proxy rule group resource names present in an account. # Managing Your Proxy Configuration **Note** Network Firewall Proxy is in public preview release and is subject to change. Proxy configurations use rule groups and other settings to define the traffic filtering behavior for a Proxy. In this procedure, you'll create a Proxy configuration using the rule groups that you created in the previous step. For information, see [Managing Your Rule Groups](managing-proxy-rule-groups.md). ## To create a Proxy configuration **To create a Proxy configuration** 1. Sign in to the AWS Management Console and open the Amazon VPC console. 1. In the navigation pane, under **Network Firewall Proxy**, choose **Proxy configuration**. 1. Choose **Create Proxy configuration**. 1. Enter a name and optionally enter a description. 1. Under **Default action**, choose an action for each phase of the traffic. This determines what happens to traffic if it does not match any rules. 1. (Optional) Add a tag. 1. Choose **Next**. 1. Choose **Attach rule group**. 1. Set a priority for the rule group. Lower numbers indicate higher priority. 1. Select the rule group that you created in the previous step from the dropdown menu. 1. Choose Attach. 1. Verify that your rule group appears in the attach rule group screen and choose **Next**. 1. Review the details and choose **Create**. ## Proxy configuration operations A Network Firewall proxy configuration contains the rules that the proxy uses to filter your traffic. Here are the available proxy configuration management operations: **Create configuration** Creates a new proxy configuration to manage network traffic. **Delete configuration** Allowed only if the proxy configuration is not attached to a proxy. Proxy configuration cannot be deleted until all associated proxies are detached from it. **Describe configuration** Retrieves detailed information about a specific proxy configuration for an account. **List configurations** Displays all proxy configuration resource names present in an account. **Modify configuration** Updates attributes of an existing proxy configuration such as priority of the rule groups, excluding rule group modifications. Cannot attach a different proxy configuration when one proxy configuration has already been attached. You can modify the currently attached proxy configuration if needed. **Modify rule group priorities** Adjusts the priority order of rule groups within the proxy configuration. **Attach rule groups** Adds rule groups to a configuration at specific positions or appends them to the end of the list. Includes explicit priority settings for simplified user experience. Steps to attach rule groups: 1. On AWS console, click on proxy configuration. Select the proxy that you want to make the change to. 1. Click on attach rule group. 1. Add a priority for the rule group. 1. Click on attach. **Detach rule groups** Removes rule groups from a configuration without deleting them. The rule groups continue to exist and must be deleted separately using the delete-egress-proxy-rule-group action. Steps to detach rule groups: 1. On the AWS console, click on proxy configuration. Select the proxy that you want to make the change to. 1. Select the rule group. 1. Click on detach on the right top. 1. Type detach to confirm. 1. Click on detach. # Logging and Monitoring **Note** Network Firewall Proxy is in public preview release and is subject to change. Logging provides detailed information about network traffic, including the time that the proxy received a packet, detailed information about the packet, and any rule action taken against the packet. The logs are published to the log destination that you configure, where you can retrieve and view them. Steps to configure logging: 1. Go to the proxy page on the AWS console. 1. Click on proxies. Choose the proxy you want to configure logging on. 1. Click on Log delivery tab. 1. Click on the add log delivery. 1. Choose the destination for delivering the logs - CloudWatch, S3 or Kinesis. 1. We will go through the steps for CloudWatch logs here. 1. Select the type of log between allow log, deny log and alert log. You can only select one at a time. If you need multiple logs, create multiple subscriptions by going through the steps above again. 1. Select the cloudwatch log group. Note: This log group will need to be created beforehand on Cloudwatch. For more details, check [here](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html#Create-Log-Group). 1. (Optional) Select the log fields that you require to be shown in the log. **Note** There are some mandatory fields that cannot be unselected if you choose to configure logging. These include - event\$1timestamp, proxy\$1name and final\$1action. Some log fields will be selected by default and if you do not make changes, these will be included in the logs. You can enable/ disable fields to customize the fields that will appear in your log. 1. (Optional) You can also configure other fields such as output format and field delimiter. 1. Click Add. Log delivery is now successfully created. ## Contents of a proxy log Proxy provides comprehensive logs that include details of each request it receives from the client and each response it sends back to the client. The logs contain the following information: **Basic Request Information** + Proxy name + Event timestamp + Client source IP and port + Source VPC and VPCE identifiers + AWS account ID **URL Components** + Destination domain + URL scheme (http/https) + Authority + Path + Query parameters + URL fragments **Connection Details** + HTTP method (e.g., GET, POST) + Destination IP and port + HTTP status code **Rule Evaluation Information** + First alert match + All matching rules, including: + Rule IDs + Hook points (pre\$1dns, pre\$1request, post\$1response) + Actions taken (alert, allow) + Final action + Final rule name + Final rule group name This logging structure allows for detailed tracking and analysis of all proxy traffic, providing ability for effective monitoring and troubleshooting of network requests. ## Example alert log entry The following example shows an alert log entry for Network Firewall Proxy. ``` { "proxy_name": "my-awesome-proxy", "event_timestamp": 1717171, "client_src_ip": "192.168.10.1", "client_src_port": 123, "src_vpc": "vpc-aabbccdd", "src_vpce": "vpce-xxyyzz", "account_id": "1122334455", "dest_domain": "www.amazon.com", "url": { "scheme": "https", "authority": "www.amazon.com", "path": "/xyz", "query":"crid=U7M9K3I5QT25&dib", "fragment": "" }, "http_method": "GET", "dest_ip": "205.251.242.103", "dest_port": 443, "http_status_code": 200, "first_alert_match": "rule-that-alerts-if-it-goes-to-amazon.com", "all_matches": { "matches": [{ "rule_id": "rule-that-alerts-if-it-goes-to-amazon.com", "hook": "pre_dns", "action": "alert" }, { "rule_id": "default", "hook": "pre_dns", "action": "allow" }, { "rule_id": "default", "hook": "pre_request", "action": "allow" }, { "rule_id": "rule-that-alerts-if-it-returns-html", "hook": "post_response", "action": "alert" }, { "rule_id": "default", "hook": "post_response", "action": "allow" }] }, "final_action": "allow", "final_rule_name": "", "final_rule_group_name": "" } ``` # Security in your use of the AWS Network Firewall service ## Considerations on creating Proxy endpoints in a VPC with Block Public Access (BPA) enabled **Note** Network Firewall Proxy is in public preview release and is subject to change. If you host applications in a separate VPC with BPA enabled and create a Proxy VPC endpoint in that VPC, such applications will now potentially have access to public internet through Proxy's VPC, assuming that the Proxy configuration allows such traffic. Therefore, it's important to ensure the Proxy is appropriately configured before creating the VPC endpoints in isolated VPCs to avoid unintended outbound (to IGW) access. ## Ensuring clients do not bypass Proxy When you create a new Proxy, a VPC endpoint is automatically created in the same subnet as your NATGW. Application resources need to be guarded with Security group rules to prevent direct routing of traffic via the NAT GW instead of being evaluated via Proxy first. If a potential Proxy client is part of a security group that allows outbound to anywhere and belongs to a subnet with a route to IGW via the NAT GW, then they can bypass proxy. ## Reachability of resources co-located with the NATGW - Same VPC Any traffic processed by the Proxy attached to your NATGW respects your VPC route tables. Any clients using the Proxy to send traffic to destinations that resolve to local IPv4 addresses within the VPC will be able to do so. Additionally, if you create Proxy VPC Endpoints in other VPCs, clients in those VPCs may now be able to access resources in the NATGW VPC depending on how the security groups or NACLs are configured in the NATGW VPC. To avoid unintended access by resources in either of the VPCs, ensure that the security groups are configured to allow only relevant clients to use the Proxy VPC endpoint, as well as ensuring that the NATGW subnet is sufficiently isolated using route tables or NACLs. ## Securely configuring your PCA resource for use with AWS Network Firewall Proxy AWS requires that any PCA resource used with Network Firewall Proxy allows the service principal `proxy.network-firewall.amazonaws.com` to perform `acm-pca` actions listed in this policy: `arn:aws:ram::aws:permission/AWSRAMSubordinateCACertificatePathLen0IssuanceCertificateAuthority` In order to ensure your PCA resource is used only in the context of your Network Firewall Proxy resource, we recommend attaching a resource policy that is appropriately scoped to your PCA resource, using the `aws:SourceArn` or `aws:SourceAccount` global condition keys. An example policy: ``` { "Version": "2012-10-17" "Statement": [ { "Effect": "Allow", "Principal": { "Service": "preprod.proxy.network-firewall.amazonaws.com" }, "Resource": "arn:aws:acm-pca:us-east-1:123456789012:certificate-authority/CA_ID", "Action": [ "acm-pca:GetCertificate", "acm-pca:DescribeCertificateAuthority", "acm-pca:GetCertificateAuthorityCertificate", "acm-pca:ListTags", "acm-pca:ListPermissions" ], "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:network-firewall:us-east-1:123456789012:proxy/PROXY_NAME" } } }, { "Effect": "Allow", "Principal": { "Service": "preprod.proxy.network-firewall.amazonaws.com" }, "Action": [ "acm-pca:IssueCertificate" ], "Resource": "arn:aws:acm-pca:us-east-1:123456789012:certificate-authority/CA_ID", "Condition": { "StringEquals": { "acm-pca:TemplateArn": "arn:aws:acm-pca:::template/SubordinateCACertificate_PathLen0/V1" }, "ArnEquals": { "aws:SourceArn": "arn:aws:network-firewall:us-east-1:123456789012:proxy/PROXY_NAME" } } } ] } ``` # Limits of the proxy service for the public preview in US East (Ohio) region only **Note** Network Firewall Proxy is in public preview release and is subject to change. **Service resource limits** + Number of Proxies per account - 1 + Number of Proxy configuration per account - 50 + Number of Proxy rule groups per account - 500 + Number of proxy configuration shared with proxies - 5 + Maximum size of condition-key:condition-value map per rule group - 30 MB + Maximum size per condition-key:condition-value map per rule - 30 KB + Maximum condition value - 1 KB + Number of EgressProxyRules per rule group - 1000 + Number of EgressProxyRuleGroups per Proxy Configuration - 10 + Network Firewall proxy preview supports only HTTP/1.1 protocol. HTTP/2 (H2) and HTTP/3 (H3) traffic will not be supported – these connections may be dropped or result in timeouts. Ensure your applications use HTTP/1.1 when routing through the Network Firewall proxy.