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

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
   
   

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. In the navigation pane, under Network Analysis, choose Network Access Analyzer.
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

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

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

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.

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

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.