Whether you in the Cloud or on on-premises, the need for solid network security doesn’t stop. Fortunately, there are a whole heap of services in AWS that you can use to manage your networks. For this post, we are focussing on key approaches and configurations that you can adopt.
Network design
The same principles of network segregation apply in AWS. Segregation provides isolation of traffic. There are 3 main levels of segregation in AWS that you should consider.
- AWS account level provides the highest level of segregation including at the IAM account level. If you really need to provide total segregation, such as for a PCI compliant environment, then consider using seperate accounts. This is also a good approach to seperate Production and non-Production accounts. Note that you can still interconnect VPCs in different account if required using Transit Gateway;
- VPCs are the classic segregation layer. All network traffic in a VPC is fully isolated unless you explicitly connect it via a VPN, the Internet (using an Internet Gateway) or a connection to another VPC (through peering). Organisation often have multiple VPCs in a Production account to segregate workloads;
- Subnets are the smallest unit of segregation. All workloads should use subnet level segregation as a minimum.
Using subnets
Workloads often use a classic 3-level model for network security. There are some standard patterns you should adopt.
- Subnets should be created across at least 2 AZs for public, application and data subnets;
- NACLs should be applied at the subnet level. We recommend using NACLs as a catch-all blacklist. Note that NACLs are stateless. That means that you need to define inbound and outbound rules for each connection. This is why we like to use them as blacklists as blocking one direction will cause a TCP connection to fail;
- In general, the data subnets should not have access to the Internet;
- Instances in the application subnet should use a NAT Gateway to access the Internet (outbound) with no inbound direct access;
- Only instances in the public subnets should have public IPs and you really want to think about whether that is required! From a security and availability perspective, you may want to put any Internet facing instances behind a load balancer (or potentially the CloudFront CDN);
- Route tables are used to control network flow from the subnet. They allow you to isolate a subnet so that it can’t access the Internet.
Remote access
EC2 instances are often provided with public IPs for remote access, via RDP or SSH. However, with AWS that isn’t necessary! There are 3 different ways that you can remotely access your instances.
Session Manager
The first method is to use Session Manager. It gives you the ability to connect to an EC2 instance using the CLI or EC2 console. The beauty of Session Manager is that you don’t need to open up RDP or SSH ports or manage SSH keys.
On a Windows host Session Manager gives you a PowerShell session. For Linux, you get shell access. Access to use Session Manager should be managed through IAM policy. Session Manager requires the AWS SSM agent which is included in the standard AWS managed AMIs. It also allows you to specify which local OS user to use on Linux hosts.It’s as easy as tagging an IAM user or role with the tag SSMSessionRunAs and specifying the OS user as the value. We also recommend setting up session logging to S3 for auditing purposes. This should be done in the Session Manager section of the Systems Manager console under Preferences.
EC2 Instance Connect
Another option for Linux instances is EC2 Instance Connect. This service uses IAM to manage SSH access to instances. It still requires network level access to SSH but SSH keys are managed by the service. In general, we recommend Session Manager over Instance Connect.
CloudShell
Finally, if you only use an instance for access to your AWS services through the CLI, AWS CloudShell is your friend! CloudShell gives you a shell within the AWS console that is pre-configured with the most common AWS CLI tools. It uses your console IAM permissions in the shell. It makes it very easy to run AWS CLI commands without having to managed that locally or running up an EC2 instance.
Security groups
Security groups are a critical tool in managing the network security of your AWS environments. They can be used to control inbound and outbound traffic in your VPCs and can be applied to instances and many services. It is a stateful virtual firewall. Security groups allow you to use allow rules only. This means that by default any other traffic is denied by a security group! You should always apply a security group(s) to your EC2 instances. If you don’t, the default security group for the VPC will be associated with the instance.
Out of the box, that default group allows all traffic from anything associated with the default security group. It also allows outbound access to anywhere on any port! We recommend that you delete these rules from the default security group so that it therefore denies all traffic. Think of this as a safety net if someone forgets to add a security group to an instance.
Like firewall rules or IAM policies, security groups should be dialled down to only provide the access requires. You can use automation (such as via AWS Config) to detect undesirable rules. More on this in a later blog!
One of the really neat features of security groups is that you can allow access from other security groups. This allows you to adopt a functional, not network location, based approach to controlling your network security. For example, you might create a security group for your database that allows access from the security group related with the application instances. If an instance is relaunched in a different subnet, the access will still be allowed.
Although not covered here, if you want to manage your security groups centrally you can use AWS Firewall Manager. It also supports a multi-account Organizations based setup.
Internet network security
You are very likely to want to deliver some of your services over the Internet. This means that you need to provide inbound access from the Internet via an Internet Gateway. There are a variety of services that can help you protect your Internet facing assets.
Load balancing
The AWS Load Balancer can be used to not only provide high availability but also provide a further layer of protection.
Although they are primarily used to distribute traffic, they also offer a number of security benefits. The AWS load balancer actually come in four flavours. However, we are only considering the Application Load Balancer (ALB) and Network Load Balancer (NLB) here. The Classic Load Balancer can be considered a legacy service. The new Gateway Load Balancer is really a management shell for virtual appliances. It is actually used by the AWS Network Firewall (see below), for example.
The ALB is a layer 7 load balancer whereas the NLB is layer 4 – it is designed for speed! From a security perspective, both provide SSL offloading. This allows management of certificates via AWS Certificate Manager. They both also act as transparent proxies for network flow. Both load balancers allow you to log access requests to S3.
The ALB adds the ability to apply a security group. It also allows re-write and redirect rules as it acts as a true HTTPS listener. The NLB in contrast is purely acting at the TLS level. The ALB also allows you to integrate the AWS WAF into it for additional protection. Finally, ALB even supports authenticated access using popular social identity providers such as Google or corporate identities through SAML, LDAP and Microsoft AD. That’s a heap of options so you need to plan your intent before you start!
AWS WAF
Network firewalls operate at the network packet layer. They aren’t intended to inspect the payload of web application. In contrast, a web application firewall is designed to protect your web applications or APIs against common web exploits.
The AWS WAF uses security rules that block common attack patterns such as SQL injection or cross-site scripting. You can configure the WAF to use a selection of AWS and third party managed rules to address issues like the OWASP Top 10 security risks. You can also define your own custom rules to match your web application. Rules can be added at creation of the WAF or added later.
Make sure that you monitor your traffic to look for any unintended blocking of traffic! You can setup WAF to stream logs to an S3 bucket via Kinesis Firehose.
The AWS WAF can be used with an ALB, CloudFront or AWS API Gateway.
Amazon CloudFront
Amazon CloudFront is a content delivery network. Although it is designed to reduce latency by putting content closer to end users, it also provides some security features. These include protection against DDoS (through AWS Shield) and SSL termination. It also supports content restriction through signed URLs and signed cookies. Finally, you can implement geo-restriction for access.
If you need to deliver your services to a geographically diverse customer base, then CloudFront makes sense. In Australia and NZ, there are CloudFront edge locations in Auckland, Melbourne, Perth and Sydney.
AWS Network Firewall
What if you need more control of network security than NACLs and security groups? You might want to consider using the AWS Network Firewall. It provides a high availability, managed network firewall. It’s features include stateful inspection, intrusion prevention and detection, and web filtering to protect your virtual networks on AWS. The Network Firewall is delivered as a fully managed service. This means that it automatically scales with traffic, ensuring high availability for the service.
With a Network Firewall, you could centralise all your network egress and ingress through the firewall using Transit Gateway. Network Firewall isn’t the cheapest service but if you do centralise it, you can remove the requirement for NAT Gateways in your accounts and centralise that too!
Keeping it internal
Keeping your traffic internal is a good way to reduce the attack surface. For some VPCs, you may not want to enable an Internet Gateway at all, as all the services are internal to your organisation. In order to manage EC2 instances (and other services), access is needed from the VPC to AWS API endpoints. By default, these endpoints are public endpoints, requiring Internet access. How can you manage that?
VPC Endpoints
VPC Endpoints (also know as AWS PrivateLink) provide private access to AWS API endpoints in your VPC. By setting up endpoints to specific AWS services, your instances use a local private IP instead of the public IP. As the endpoints appear as a virtual network interface, you can setup routing to them and apply security groups to protect access. In addition, you can apply an Endpoint IAM policy to control access. VPC Endpoints are supported by a broad set of AWS services.
Of course, endpoints come at a cost. If you were to enable an endpoint for a service across 3 AZs, it would cost you roughly $28 a month. If you did this for a number of services across multiple accounts, this can add up quickly. The solution is to use a shared services model where you setup endpoints in a centralised VPC and route traffic to these endpoints via Route 53 DNS. This would work well with the centralised AWS Network Firewall described above.
We certainly recommend that you look closely at your services and make use of VPC Endpoints where it makes sense. For most of our customers, our minimum recommended set of VPC Endpoint enabled services is for Systems Manager, EC2 and S3.
com.amazonaws.ap-southeast-2.ssm com.amazonaws.ap-southeast-2.ssmmessages com.amazonaws.ap-southeast-2.ec2messages com.amazonaws.ap-southeast-2.ec2 com.amazonaws.ap-southeast-2.s3 com.amazonaws.ap-southeast-2.cloudformation
Hybrid connectivity
Many customers will be operating with on-premises components for many years. They often want to retain existing Internet services and route traffic from AWS through this service. Connecting your AWS VPCs to on-premises can be achieved using an Internet based AWS VPN or via a private network link using AWS Direct Connect. Direct Connect has the obvious advantage of it being a private network connection, not traversing the Internet and providing a more consistent bandwidth and latency. VPNs have the advantage of lower cost and speed to implement. Even though they traverse the Internet, VPNs use end to end encryption.
If you have a multi-account or multi-VPC solution, you can use Transit Gateway to provide connectivity between on-premises and all (or a subset) of your VPCs. With this hybrid connectivity, you can also use the VPC Endpoints to provide access to AWS API endpoints from on-premises, include to S3 Cloud storage.
If you need the extra network security and performance consistency, Direct Connect is the way to go – you can even run a VPN over it for an additional layer of security.
Wrapping up
As you can see, the AWS Cloud offers a rich set of options for your network security. As a result, there are lots of things to consider when designing and managing your VPCs. We’ve only looked at some of the keys areas to focus on and there and many more options to consider!
If you would like to dive deeper into your VPC design, please get in contact with us at RedBear. Look out for our next instalment in our AWS Security Foundations series next week!
