Network security should be a major focus for companies moving to the cloud. Cloud networks are exposed to the Internet and companies don’t have direct control of the hardware running them. When not configured correctly, networks in the cloud could be attacked and breached.
AWS helps you build networks in the cloud and take some of the burden upon themselves. In part one of this series, we discussed in some detail the AWS Shared Responsibility Model. AWS breaks its services up into three groups: infrastructure services, container services, and abstract services. Each group of services has responsibility for security divided between the customer and Amazon. Understanding what you’re responsible for as the customer helps you to know what security controls you need to stay secure.
In this post, we’ll discuss what you need to secure your network in AWS. This is the customer’s responsibility with infrastructure services (EC2, EBS) and container services (RDS, Elastic Beanstalk). Let’s dive in.
Network Infrastructure in AWS
It’s beneficial to begin with an overview of what networking in AWS actually looks like. Let’s discuss the major pieces of AWS network functionality to establish a baseline. Then we’ll tackle the major problems which lead to easy attack.
First, AWS offers Virtual Private Cloud, or VPC. VPC gives customers a small piece of AWS network infrastructure all to themselves. If the AWS network is a tree, your VPC is a treehouse just for you and your friends and you have to know the secret password to gain entry (not really, but we’ll see how that works for real in a minute). You have complete control over the VPC and the network controls inside, including IP addresses, subnets, and configuration of route tables. VPCs are part of AWS infrastructure services, which gives you close to the same control you would have in an on-prem environment.
Next up, we’ll discuss Network Access Control Lists, or ACLs. Network ACLs give customers access to stateless firewall rules to allow or block access to your VPC. Network ACLs are optional, but can be useful as defense-in-depth and as high-level guardrails for your network. For example, you could restrict access to your network to corporate IP addresses. You could block certain IPs you know could be dangerous if they connect.
If an EC2 instance needs access to the Internet to do its work, you can use a NAT Gateway. NAT Gateways provide Network Address Translation services to your EC2 instances. The internal IP address of the instance will be changed on the way out to the public Internet. When the request comes back, the NAT Gateway translates it back to the correct IP address. Another option is using NAT instances, which are essentially EC2 instances that serve as NAT routers. However, NAT Gateways are managed by AWS and provide better performance and throughput, so they are recommended.
Finally, Security Groups are the better alternative to network ACLs. A security group is a virtual stateful firewall that controls traffic to one or more instances. They are more configurable than network ACLs and can be applied to groups of EC2 instances. Traffic can be restricted based on protocol, port number, and IP address range. This allows you to have a security group for web servers with port 80 (HTTP) or 443 (HTTPS) open. You can create another group for application servers and database servers with the correct ports open and only allow web servers and application servers to connect, respectively.
That concludes the tour of AWS network infrastructure. Now let’s get to common mistakes made when configuring network resources and best practices to avoid them.
Network Misconfigurations Which Lead to Easy Attack
Network configuration can be complex in many enterprise environments. Here’s some common mistakes which make it easier for attackers to get into your network.
Don’t Leave the Front Door Open
Admins may leave EC2 instances open to communication from any machine on the Internet if the Security Group is not configured correctly. Specifically, allowing access to the IP address range 0.0.0.0/0 means allowing all IP addresses to connect. If you use 0.0.0.0/0 with the SSH protocol, and you’re allowing anyone on the Internet to connect to that instance using SSH. This is surprisingly prevalent.
This setting can be tempting for the sake of a speedy setup for an instance, but is extremely dangerous. Instead, restrict access to only the IP addresses which absolutely need to connect.
Another related misconfiguration is allowing internet access to your VPC. You don’t want VPCs, or the EC2 instances inside of them, to be accessible from the general Internet. Use network ACLs to restrict access to VPCs to corporate IP addresses and other VPCs within your infrastructure.
Enterprise networks can quickly to become complex. If this complexity is not managed correctly, you’ll leave holes for attackers to find. For example, an EC2 instance could be stood up outside of the officially sanctioned VPCs for use by your company. The principle of least privilege is needed here. Don’t allow just anyone to create instances in your AWS environment.
It’s also important to understand what you’re running in the cloud. Make sure you’re using CloudTrail logs to watch what is happening in your environment. Visibility is the only way to investigate issues or incidents when they appear. Don’t set up your network and then ignore it.
AWS Network Best Practices
We’ve discussed networking basics and mistakes that can lead to compromise. Now let’s see some best practices for networks built in AWS.
- Network Security Monitoring: Efficient monitoring is essential for network security. CloudWatch logs are generated by EC2 instances and tell you what network traffic is coming and going from EC2 instances. CloudWatch can help you find patterns and determine abnormal network traffic. VPC Flow Logs record the network traffic coming into and going out of your VPC and is also useful information. Check out VPC network and monitoring best practices on AWS for more detail.
- Use Network Ingress Controls: Watching who connects to your AWS network is key to security. Pay attention to who is connecting and what they’re doing. Use network ACLs and Security groups to control who can reach your network. Amazon also offers a WAF to stop common exploits against web applications.
- Use Network Egress Controls: Security groups can control traffic out of the VPC as well as into it. VPCs also offer route tables you can use to decide what traffic can go where. Using routing tables and private subnets, you can shield key EC2 instances from the public Internet while routing their traffic to approved outbound network gateways. This lowers attack surface while allowing only the instances which require internet access to have it. Check out Controlling VPC Egress Traffic for more details.
Protect Your Networks
The AWS Shared Responsibility Model assigns responsibility for network security onto the customer’s shoulders in two out of three service groups. Understanding how AWS network security works is paramount to keeping your network safe from intruders.
Use VPCs to create private networks only your organization can access. This can be configured with security groups and network ACLs. Never use 0.0.0.0/0, unless you want every computer on the public Internet to have access to your EC2 instances.
Always monitor your network, using VPC Flow Logs, CloudWatch, and CloudTrail. Use these logs to find anomalous network traffic and react to it quickly. Don’t underestimate the power AWS gives you. If you understand it, you can use it to lock down your network and keep attackers out.
If you’re curious how hacker-powered security can help you keep your network safe, get in touch. We’d be happy to help.