All posts by Patrick Duffy

Identifying publicly accessible resources with Amazon VPC Network Access Analyzer

Post Syndicated from Patrick Duffy original https://aws.amazon.com/blogs/security/identifying-publicly-accessible-resources-with-amazon-vpc-network-access-analyzer/

Network and security teams often need to evaluate the internet accessibility of all their resources on AWS and block any non-essential internet access. Validating who has access to what can be complicated—there are several different controls that can prevent or authorize access to resources in your Amazon Virtual Private Cloud (Amazon VPC). The recently launched Amazon VPC Network Access Analyzer helps you understand potential network paths to and from your resources without having to build automation or manually review security groups, network access control lists (network ACLs), route tables, and Elastic Load Balancing (ELB) configurations. You can use this information to add security layers, such as moving instances to a private subnet behind a NAT gateway or moving APIs behind AWS PrivateLink, rather than use public internet connectivity. In this blog post, we show you how to use Network Access Analyzer to identify publicly accessible resources.

What is Network Access Analyzer?

Network Access Analyzer allows you to evaluate your network against your design requirements and network security policy. You can specify your network security policy for resources on AWS through a Network Access Scope. Network Access Analyzer evaluates the configuration of your Amazon VPC resources and controls, such as security groups, elastic network interfaces, Amazon Elastic Compute Cloud (Amazon EC2) instances, load balancers, VPC endpoint services, transit gateways, NAT gateways, internet gateways, VPN gateways, VPC peering connections, and network firewalls.

Network Access Analyzer uses automated reasoning to produce findings of potential network paths that don’t meet your network security policy. Network Access Analyzer reasons about all of your Amazon VPC configurations together rather than in isolation. For example, it produces findings for paths from an EC2 instance to an internet gateway only when the following conditions are met: the security group allows outbound traffic, the network ACL allows outbound traffic, and the instance’s route table has a route to an internet gateway (possibly through a NAT gateway, network firewall, transit gateway, or peering connection). Network Access Analyzer produces actionable findings with more context such as the entire network path from the source to the destination, as compared to the isolated rule-based checks of individual controls, such as security groups or route tables.

Sample environment

Let’s walk through a real-world example of using Network Access Analyzer to detect publicly accessible resources in your environment. Figure 1 shows an environment for this evaluation, which includes the following resources:

  • An EC2 instance in a public subnet allowing inbound public connections on port 80/443 (HTTP/HTTPS).
  • An EC2 instance in a private subnet allowing connections from an Application Load Balancer on port 80/443.
  • An Application Load Balancer in a public subnet with a Target Group connected to the private web server, allowing public connections on port 80/443.
  • An Amazon Aurora database in a public subnet allowing public connections on port 3306 (MySQL).
  • An Aurora database in a private subnet.
  • An EC2 instance in a public subnet allowing public connections on port 9200 (OpenSearch/Elasticsearch).
  • An Amazon EMR cluster allowing public connections on port 8080.
  • A Windows EC2 instance in a public subnet allowing public connections on port 3389 (Remote Desktop Protocol).
Figure 1: Example environment of web servers hosted on EC2 instances, remote desktop servers hosted on EC2, Relational Database Service (RDS) databases, Amazon EMR cluster, and OpenSearch cluster on EC2

Figure 1: Example environment of web servers hosted on EC2 instances, remote desktop servers hosted on EC2, Relational Database Service (RDS) databases, Amazon EMR cluster, and OpenSearch cluster on EC2

Let us assume that your organization’s security policy requires that your databases and analytics clusters not be directly accessible from the internet, whereas certain workload such as instances for web services can have internet access only through an Application Load Balancer over ports 80 and 443. Network Access Analyzer allows you to evaluate network access to resources in your VPCs, including database resources such as Amazon RDS and Amazon Aurora clusters, and analytics resources such as Amazon OpenSearch Service clusters and Amazon EMR clusters. This allows you to govern network access to your resources on AWS, by identifying network access that does not meet your security policies, and creating exclusions for paths that do have the appropriate network controls in place.

Configure Network Access Analyzer

In this section, you will learn how to create network scopes, analyze the environment, and review the findings produced. You can create network access scopes by using the AWS Command Line Interface (AWS CLI) or AWS Management Console. When creating network access scopes using the AWS CLI, you can supply the scope by using a JSON document. This blog post provides several network access scopes as JSON documents that you can deploy to your AWS accounts.

To create a network scope (AWS CLI)

  1. Verify that you have the AWS CLI installed and configured.
  2. Download the network-scopes.zip file, which contains JSON documents that detect the following publicly accessible resources:
    • OpenSearch/Elasticsearch clusters
    • Databases (MySQL, PostgreSQL, MSSQL)
    • EMR clusters
    • Windows Remote Desktop
    • Web servers that can be accessed without going through a load balancer

    Make note of the folder where you save the JSON scopes because you will need it for the next step.

  3. Open a systems shell, such as Bash, Zsh, or cmd.
  4. Navigate to the folder where you saved the preceding JSON scopes.
  5. Run the following commands in the shell window: 
    aws ec2 create-network-insights-access-scope 
--cli-input-json file://detect-public-databases.json 
--tag-specifications 'ResourceType="network-insights-access-scope",
Tags=[{Key="Name",Value="detect-public-databases"},{Key="Description",
		   Value="Detects publicly accessible databases."}]' 
--region us-east-1

aws ec2 create-network-insights-access-scope 
--cli-input-json file://detect-public-elastic.json 
--tag-specifications 'ResourceType="network-insights-access-scope",
Tags=[{Key="Name",Value="detect-public-opensearch"},{Key="Description",
		   Value="Detects publicly accessible OpenSearch/Elasticsearch endpoints."}]' 
--region us-east-1

aws ec2 create-network-insights-access-scope 
--cli-input-json file://detect-public-emr.json 
--tag-specifications 'ResourceType="network-insights-access-scope",
Tags=[{Key="Name",Value="detect-public-emr"},{Key="Description",
		   Value="Detects publicly accessible Amazon EMR endpoints."}]'
--region us-east-1

aws ec2 create-network-insights-access-scope 
--cli-input-json file://detect-public-remotedesktop.json 
--tag-specifications 'ResourceType="network-insights-access-scope",
Tags=[{Key="Name",Value="detect-public-remotedesktop"},{Key="Description",
		   Value="Detects publicly accessible Microsoft Remote Desktop servers."}]' 
--region us-east-1

aws ec2 create-network-insights-access-scope 
--cli-input-json file://detect-public-webserver-noloadbalancer.json 
--tag-specifications 'ResourceType="network-insights-access-scope",
Tags=[{Key="Name",Value="detect-public-webservers"},{Key="Description",
		   Value="Detects publicly accessible web servers that can be accessed without using a load balancer."}]' 
--region us-east-1
    

    

    6. 



Now that you’ve created the scopes, you will analyze them to find resources that match your match conditions.


To analyze your scopes (console)


    

  1. Open the Amazon VPC console.
    2. 

  2. In the navigation pane, under Network Analysis, choose Network Access Analyzer.
    3. 

  3. Under Network Access Scopes, select the checkboxes next to the scopes that you want to analyze, and then choose Analyze, as shown in Figure 2.

    
Figure 2: Custom network scopes created for Network Access Analyzer
    

    Figure 2: Custom network scopes created for Network Access Analyzer
    

    

    4. 



If Network Access Analyzer detects findings, the console indicates the status Findings detected for each scope, as shown in Figure 3.



Figure 3: Network Access Analyzer scope status


Figure 3: Network Access Analyzer scope status




To review findings for a scope (console)


    

  1. On the Network Access Scopes page, under Network Access Scope ID, select the link for the scope that has the findings that you want to review. This opens the latest analysis, with the option to review past analyses, as shown in Figure 4.

    
Figure 4: Finding summary identifying Amazon Aurora instance with public access to port 3306
    

    Figure 4: Finding summary identifying Amazon Aurora instance with public access to port 3306
    

    

    2. 

  2. To review the path for a specific finding, under Findings, select the radio button to the left of the finding, as shown in Figure 4. Figure 5 shows an example of a path for a finding.

    
Figure 5: Finding details showing access to the Amazon Aurora instance from the internet gateway to the elastic network interface, allowed by a network ACL and security group.
    

    Figure 5: Finding details showing access to the Amazon Aurora instance from the internet gateway to the elastic network interface, allowed by a network ACL and security group.
    

    

    3. 

  3. Choose any resource in the path for detailed information, as shown in Figure 6.

    
Figure 6: Resource detail within a finding outlining a specific security group allowing access on port 3306
    

    Figure 6: Resource detail within a finding outlining a specific security group allowing access on port 3306
    

    

    4. 



How to remediate findings


After deploying network scopes and reviewing findings for publicly accessible resources, you should next limit access to those resources and remove public access. Use cases vary, but the scopes outlined in this post identify resources that you should share publicly in a more secure manner or remove public access entirely. The following techniques will help you align to the Protecting Networks portion of the AWS Well-Architected Framework Security Pillar. 


If you have a need to share a database with external entities, consider using AWS PrivateLink, VPC peering, or use AWS Site-to-Site VPN to share access. You can remove public access by modifying the security group attached to the RDS instance or EC2 instance serving the database, but you should migrate the RDS database to a private subnet as well.


When creating web servers in EC2, you should not place web servers directly in a public subnet with security groups allowing HTTP and HTTPS ports from all internet addresses. Instead, you should place your EC2 instances in private subnets and use Application Load Balancers in a public subnet. From there, you can attach a security group that allows HTTP/HTTPS access from public internet addresses to your Application Load Balancer, and attach a security group that allows HTTP/HTTPS from your Load Balancer security group to your web server EC2 instances. You can also associate AWS WAF web ACLs to the load balancer to protect your web applications or APIs against common web exploits and bots that may affect availability, compromise security, or consume excessive resources.


Similarly, if you have OpenSearch/Elasticsearch running on EC2 or Amazon OpenSearch Service, or are using Amazon EMR, you can share these resources using PrivateLink. Use the Amazon EMR block public access configuration to verify that your EMR clusters are not shared publicly.


To connect to Remote Desktop on EC2 instances, you should use AWS Systems Manager to connect using Fleet Manager. Connecting with Fleet Manager only requires your Windows EC2 instances to be a managed node. When connecting using Fleet Manager, the security group requires no inbound ports, and the instance can be in a private subnet. For more information, see the Systems Manager prerequisites. 


Conclusion


This blog post demonstrates how you can identify and remediate publicly accessible resources. Amazon VPC Network Access Analyzer helps you identify available network paths by using automated reasoning technology and user-defined access scopes. By using these scopes, you can define non-permitted network paths, identify resources that have those paths, and then take action to increase your security posture. To learn more about building continuous verification of network compliance at scale, see the blog post Continuous verification of network compliance using Amazon VPC Network Access Analyzer and AWS Security Hub. Take action today by deploying the Network Access Analyzer scopes in this post to evaluate your environment and add layers of security to best fit your needs.


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


Want more AWS Security news? Follow us on Twitter.







Author



Patrick Duffy


Patrick is a Solutions Architect in the Small Medium Business (SMB) segment at AWS. He is passionate about raising awareness and increasing security of AWS workloads. Outside work, he loves to travel and try new cuisines and enjoys a match in Magic Arena or Overwatch.







Peter Ticali



Peter Ticali


Peter is a Solutions Architect focused on helping Media & Entertainment customers transform and innovate. With over three decades of professional experience, he’s had the opportunity to contribute to architecture that stream live video to millions, including two Super Bowls, PPVs, and even a Royal Wedding. Previously he held Director, and CTO roles in the EdTech, advertising & public relations space. Additionally, he is a published photo journalist.







John Backes



John Backes


John is a Senior Applied Scientist in AWS Networking. He is passionate about applying Automated Reasoning to network verification and synthesis problems.







Vaibhav Katkade



Vaibhav Katkade


Vaibhav is a Senior Product Manager in the Amazon VPC team. He is interested in areas of network security and cloud networking operations. Outside of work, he enjoys cooking and the outdoors.














Protect your remote workforce by using a managed DNS firewall and network firewall



  






Post Syndicated from Patrick Duffy original https://aws.amazon.com/blogs/security/protect-your-remote-workforce-by-using-a-managed-dns-firewall-and-network-firewall/


More of our customers are adopting flexible work-from-home and remote work strategies that use virtual desktop solutions, such as Amazon WorkSpaces and Amazon AppStream 2.0, to deliver their user applications. Securing these workloads benefits from a layered approach, and this post focuses on protecting your users at the network level. Customers can now apply these security measures by using Route 53 Resolver DNS Firewall and AWS Network Firewall, two managed services that provide layered protection for the customer’s virtual private cloud (VPC). This blog post provides recommendations for how you can build network protection for your remote workforce by using DNS Firewall and Network Firewall.


Overview


DNS Firewall helps you block DNS queries that are made for known malicious domains, while allowing DNS queries to trusted domains. DNS Firewall has a simple deployment model that makes it straightforward for you to start protecting your VPCs by using managed domain lists, as well as custom domain lists. With DNS Firewall, you can filter and regulate outbound DNS requests. The service inspects DNS requests that are handled by Route 53 Resolver and applies actions that you define to allow or block requests.


DNS Firewall consists of domain lists and rule groups. Domain lists include custom domain lists that you create and AWS managed domain lists. Rule groups are associated with VPCs and control the response for domain lists that you choose. You can configure rule groups at scale by using AWS Firewall Manager. Rule groups process in priority order and stop processing after a rule is matched.


Network Firewall helps customers protect their VPCs by protecting the workload at the network layer. Network Firewall is an automatically scaling, highly available service that simplifies deployment and management for network administrators. With Network Firewall, you can perform inspection for inbound traffic, outbound traffic, traffic between VPCs, and traffic between VPCs and AWS Direct Connect or AWS VPN traffic. You can deploy stateless rules to allow or deny traffic based on the protocol, source and destination ports, and source and destination IP addresses. Additionally, you can deploy stateful rules that allow or block traffic based on domain lists, standard rule groups, or Suricata compatible intrusion prevention system (IPS) rules.


To configure Network Firewall, you need to create Network Firewall rule groups, a Network Firewall policy, and finally, a network firewall. Rule groups consist of stateless and stateful rule groups. For both types of rule groups, you need to estimate the capacity when you create the rule group. See the Network Firewall Developer Guide to learn how to estimate the capacity that is needed for the stateless and stateful rule engines.


This post shows you how to configure DNS Firewall and Network Firewall to protect your workload. You will learn how to create rules that prevent DNS queries to unapproved DNS servers, and that block resources by protocol, domain, and IP address. For the purposes of this post, we’ll show you how to protect a workload consisting of two Microsoft Active Directory domain controllers, an application server running QuickBooks, and Amazon WorkSpaces to deliver the QuickBooks application to end users, as shown in Figure 1.
   



Figure 1: An example architecture that includes domain controllers and QuickBooks hosted on EC2 and Amazon WorkSpaces for user virtual desktops


Figure 1: An example architecture that includes domain controllers and QuickBooks hosted on EC2 and Amazon WorkSpaces for user virtual desktops




Configure DNS Firewall


DNS Firewall domain lists currently include two managed lists to block malware and botnet command-and-control networks, and you can also bring your own list. Your list can include any domain names that you have found to be malicious and any domains that you don’t want your workloads connecting to.


To configure DNS Firewall domain lists (console)


    

  1. Open the Amazon VPC console.
    2. 

  2. In the navigation pane, under DNS Firewall, choose Domain lists.
    3. 

  3. Choose Add domain list to configure a customer-owned domain list.
    4. 

  4. In the domain list builder dialog box, do the following.

      

    1. Under Domain list name, enter a name.
      2. 

    2. In the second dialog box, enter the list of domains you want to allow or block.
      3. 

    3. Choose Add domain list.
      4. 

    

    5. 



When you create a domain list, you can enter a list of domains you want to block or allow. You also have the option to upload your domains by using a bulk upload. You can use wildcards when you add domains for DNS Firewall. Figure 2 shows an example of a custom domain list that matches the root domain and any subdomain of box.com, dropbox.com, and sharefile.com, to prevent users from using these file sharing platforms.
   



Figure 2: Domains added to a customer-owned domain list


Figure 2: Domains added to a customer-owned domain list




To configure DNS Firewall rule groups (console)


    

  1. Open the Amazon VPC console.
    2. 

  2. In the navigation pane, under DNS Firewall, choose Rule group.
    3. 

  3. Choose Create rule group to apply actions to domain lists.
    4. 

  4. Enter a rule group name and optional description.
    5. 

  5. Choose Add rule to add a managed or customer-owned domain list, and do the following.

      

    1. Enter a rule name and optional description.
      2. 

    2. Choose Add my own domain list or Add AWS managed domain list.
      3. 

    3. Select the desired domain list.
      4. 

    4. Choose an action, and then choose Next.
      5. 

    

    6. 

  6. (Optional) Change the rule priority.
    7. 

  7. (Optional) Add tags.
    8. 

  8. Choose Create rule group.
    9. 



When you create your rule group, you attach rules and set an action and priority for the rule. You can set rule actions to Allow, Block, or Alert. When you set the action to Block, you can return the following responses:


    

  • NODATA – Returns no response.
    • 

  • NXDOMAIN – Returns an unknown domain response.
    • 

  • OVERRIDE – Returns a custom CNAME response.
    • 



Figure 3 shows rules attached to the DNS firewall.
   



Figure 3: DNS Firewall rules


Figure 3: DNS Firewall rules




To associate your rule group to a VPC (console)


    

  1. Open the Amazon VPC console.
    2. 

  2. In the navigation pane, under DNS Firewall, choose Rule group.
    3. 

  3. Select the desired rule group.
    4. 

  4. Choose Associated VPCs, and then choose Associate VPC.
    5. 

  5. Select one or more VPCs, and then choose Associate.
    6. 



The rule group will filter your DNS requests to Route 53 Resolver. Set your DNS servers forwarders to use your Route 53 Resolver.


To configure logging for your firewall’s activity, navigate to the Route 53 console and select your VPC under the Resolver section. You can configure multiple logging options, if required. You can choose to log to Amazon CloudWatch, Amazon Simple Storage Service (Amazon S3), or Amazon Kinesis Data Firehose. Select the VPC that you want to log queries for and add any tags that you require.


Configure Network Firewall


In this section, you’ll learn how to create Network Firewall rule groups, a firewall policy, and a network firewall.


Configure rule groups


Stateless rule groups are straightforward evaluations of a source and destination IP address, protocol, and port. It’s important to note that stateless rules don’t perform any deep inspection of network traffic.


Stateless rules have three options:


    

  • Pass – Pass the packet without further inspection.
    • 

  • Drop – Drop the packet.
    • 

  • Forward – Forward the packet to stateful rule groups.
    • 



Stateless rules inspect each packet in isolation in the order of priority and stop processing when a rule has been matched. This example doesn’t use a stateless rule, and simply uses the default firewall action to forward all traffic to stateful rule groups.


Stateful rule groups support deep packet inspection, traffic logging, and more complex rules. Stateful rule groups evaluate traffic based on standard rules, domain rules or Suricata rules. Depending on the type of rule that you use, you can pass, drop, or create alerts on the traffic that is inspected.


To create a rule group (console)


    

  1. Open the Amazon VPC console.
    2. 

  2. In the navigation pane, under AWS Network Firewall, choose Network Firewall rule groups.
    3. 

  3. Choose Create Network Firewall rule group.
    4. 

  4. Choose Stateful rule group or Stateless rule group.
    5. 

  5. Enter the desired settings.
    6. 

  6. Choose Create stateful rule group.
    7. 



The example in Figure 4 uses standard rules to block outbound and inbound Server Message Block (SMB), Secure Shell (SSH), Network Time Protocol (NTP), DNS, and Kerberos traffic, which are common protocols used in our example workload. Network Firewall doesn’t inspect traffic between subnets within the same VPC or over VPC peering, so these rules won’t block local traffic. You can add rules with the Pass action to allow traffic to and from trusted networks.
   



Figure 4: Standard rules created to block unauthorized SMB, SSH, NTP, DNS, and Kerberos traffic


Figure 4: Standard rules created to block unauthorized SMB, SSH, NTP, DNS, and Kerberos traffic




Blocking outbound DNS requests is a common strategy to verify that DNS traffic resolves only from local resolvers, such as your DNS server or the Route 53 Resolver. You can also use these rules to prevent inbound traffic to your VPC-hosted resources, as an additional layer of security beyond security groups. If a security group erroneously allows SMB access to a file server from external sources, Network Firewall will drop this traffic based on these rules.


Even though the DNS Firewall policy described in this blog post will block DNS queries for unauthorized sharing platforms, some users might attempt to bypass this block by modifying the HOSTS file on their Amazon WorkSpace. To counter this risk, you can add a domain rule to your firewall policy to block the box.com, dropbox.com, and sharefile.com domains, as shown in Figure 5.
   



Figure 5: A domain list rule to block box.com, dropbox.com, and sharefile.com


Figure 5: A domain list rule to block box.com, dropbox.com, and sharefile.com




Configure firewall policy


You can use firewall policies to attach stateless and stateful rule groups to a single policy that is used by one or more network firewalls. Attach your rule groups to this policy and set your preferred default stateless actions. The default stateless actions will apply to any packets that don’t match a stateless rule group within the policy. You can choose separate actions for full packets and fragmented packets, depending on your needs, as shown in Figure 6.
   



Figure 6: Stateful rule groups attached to a firewall policy


Figure 6: Stateful rule groups attached to a firewall policy




You can choose to forward the traffic to be processed by any stateful rule groups that you have attached to your firewall policy. To bypass any stateful rule groups, you can select the Pass option.


To create a firewall policy (console)


    

  1. Open the Amazon VPC console.
    2. 

  2. In the navigation pane, under AWS Network Firewall, choose Firewall policies.
    3. 

  3. Choose Create firewall policy.
    4. 

  4. Enter a name and description for the policy.
    5. 

  5. Choose Add rule groups.

      

    1. Select the stateless default actions you want to use.
      2. 

    2. For any stateless or stateful rule groups, choose Add rule groups to add any rule groups that you want to use.
      3. 

    

    6. 

  6. (Optional) Add tags.
    7. 

  7. Choose Create firewall policy.
    8. 



Configure a network firewall


Configuring the network firewall requires you to attach the firewall to a VPC and select at least one subnet.


To create a network firewall (console)


    

  1. Open the Amazon VPC console.
    2. 

  2. In the navigation pane, under AWS Network Firewall, choose Firewalls.
    3. 

  3. Choose Create firewall.
    4. 

  4. Under Firewall details, do the following:

      

    1. Enter a name for the firewall.
      2. 

    2. Select the VPC.
      3. 

    3. Select one or more Availability Zones and subnets, as needed.
      4. 

    

    5. 

  5. Under Associated firewall policy, do the following:

      

    1. Choose Associate an existing firewall policy.
      2. 

    2. Select the firewall policy.
      3. 

    

    6. 

  6. (Optional) Add tags.
    7. 

  7. Choose Create firewall.
    8. 



Two subnets in separate Availability Zones are used for the network firewall example shown in Figure 7, to provide high availability.
   



Figure 7: A network firewall configuration that includes multiple subnets


Figure 7: A network firewall configuration that includes multiple subnets




After the firewall is in the ready state, you’ll be able to see the endpoint IDs of the firewall endpoints, as shown in Figure 8. The endpoint IDs are needed when you update VPC route tables.
   



Figure 8: Firewall endpoint IDs


Figure 8: Firewall endpoint IDs




You can configure alert logs, flow logs, or both to be sent to Amazon S3, CloudWatch log groups, or Kinesis Data Firehose. Administrators configure alert logging to build proactive alerting and flow logging to use in troubleshooting and analysis.


Finalize the setup


After the firewall is created and ready, the last step to complete setup is to update the VPC route tables. Update your routing in the VPC to route traffic through the new network firewall endpoints. Update the public subnets route table to direct traffic to the firewall endpoint in the same Availability Zone. Update the internet gateway route to direct traffic to the firewall endpoints in the matching Availability Zone for public subnets. These routes are shown in Figure 9.
   



Figure 9: Network diagram of the firewall solution


Figure 9: Network diagram of the firewall solution




In this example architecture, Amazon WorkSpaces users are able to connect directly between private subnet 1 and private subnet 2 to access local resources. Security groups and Windows authentication control access from WorkSpaces to EC2-hosted workloads such as Active Directory, file servers, and SQL applications. For example, Microsoft Active Directory domain controllers are added to a security group that allows inbound ports 53, 389, and 445, as shown in Figure 10.
   



Figure 10: Domain controller security group inbound rules


Figure 10: Domain controller security group inbound rules




Traffic from WorkSpaces will first resolve DNS requests by using the Active Directory domain controller. The domain controller uses the local Route 53 Resolver as a DNS forwarder, which DNS Firewall protects. Network traffic then flows from the private subnet to the NAT gateway, through the network firewall to the internet gateway. Response traffic flows back from the internet gateway to the network firewall, then to the NAT gateway, and finally to the user WorkSpace. This workflow is shown in Figure 11.
   



Figure 11: Traffic flow for allowed traffic


Figure 11: Traffic flow for allowed traffic




If a user attempts to connect to blocked internet resources, such as box.com, a botnet, or a malware domain, this will result in a NXDOMAIN response from DNS Firewall, and the connection will not proceed any further. This blocked traffic flow is shown in Figure 12.
    



Figure 12: Traffic flow when blocked by DNS Firewall


Figure 12: Traffic flow when blocked by DNS Firewall




If a user attempts to initiate a DNS request to a public DNS server or attempts to access a public file server, this will result in a dropped connection by Network Firewall. The traffic will flow as expected from the user WorkSpace to the NAT gateway and from the NAT gateway to the network firewall, which inspects the traffic. The network firewall then drops the traffic when it matches a rule with the drop or block action, as shown in Figure 13. This configuration helps to ensure that your private resources only use approved DNS servers and internet resources. Network Firewall will block unapproved domains and restricted protocols that use standard rules.
   



Figure 13: Traffic flow when blocked by Network Firewall


Figure 13: Traffic flow when blocked by Network Firewall




Take extra care to associate a route table with your internet gateway to route private subnet traffic to your firewall endpoints; otherwise, response traffic won’t make it back to your private subnets. Traffic will route from the private subnet up through the NAT gateway in its Availability Zone. The NAT gateway will pass the traffic to the network firewall endpoint in the same Availability Zone, which will process the rules and send allowed traffic to the internet gateway for the VPC. By using this method, you can block outbound network traffic with criteria that are more advanced than what is allowed by network ACLs.


Conclusion


Amazon Route 53 Resolver DNS Firewall and AWS Network Firewall help you protect your VPC workloads by inspecting network traffic and applying deep packet inspection rules to block unwanted traffic. This post focused on implementing Network Firewall in a virtual desktop workload that spans multiple Availability Zones. You’ve seen how to deploy a network firewall and update your VPC route tables. This solution can help increase the security of your workloads in AWS. If you have multiple VPCs to protect, consider enforcing your policies at scale by using AWS Firewall Manager, as outlined in this blog post.


If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the AWS Network Firewall forum or contact AWS Support.


Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.







Author



Patrick Duffy


Patrick is a Solutions Architect in the Small Medium Business (SMB) segment at AWS. He is passionate about raising awareness and increasing security of AWS workloads. Outside work, he loves to travel and try new cuisines and enjoys a match in Magic Arena or Overwatch.