Hints for Securing Network Traffic To and From AWS VPCs

Featured article by Frank Cabri, Aviatrix

Security in AWS is a shared-responsibility model. AWS assumes responsibility for the underlying infrastructure, hardware, virtualization layer, facilities, and staff. But when it comes to securing your VPCs, the subscriber organization — that’s you — is, among other things, responsible for:

* Securing data in motion
* Blocking illegitimate ingress and egress traffic
* Building policies to allow traffic between VPCs when needed
* Controlling who can access each VPC

This article provides some hints for addressing each of these responsibilities of network security within your AWS environment.

Encrypting data in motion between your data center and the AWS Global Transit VPC

If you have connectivity with one or more data centers, you are likely using the AWS recommended Global Transit Network architecture. In this design, organizations typically use AWS Direct Connect or IPSec VPN connectivity to enable traffic from their private, on-premises data center to their AWS cloud, and specifically to their Global Transit Hub VPC. AWS Direct Connect is a private link into AWS regions that provides bandwidth, but the service is not natively encrypted. Encrypting this traffic can be accomplished by following the steps AWS outlines in its Create a VPN Direct Connect Knowledge Center article.

If you use an IPSec VPN rather than Direct Connect to connect to your Transit Hub VPC, then this link is already encrypted. Be aware, however, that the AWS Virtual Private Gateway, where the VPN will terminate, can support only 10 connections per VPC — so if you have more than that, you’ll need to plan accordingly.

The links connecting a Transit Hub VPC to its Spoke VPCs are encrypted by default when following the guidelines of the AWS Global Transit Architecture. However, it’s important to point out that if you are using AWS peering to connect any of your spokes to other, non-spoke, VPCs, the traffic may not be encrypted. By default, AWS intra-region peering is not encrypted.

Once you have traffic from your data center fully encrypted, you need to consider what traffic should be allowed in and out of your VPCs.

Securing VPC ingress and egress traffic

Ingress traffic refers to the traffic coming into a VPC from the internet, and egress refers to the traffic leaving the VPC for the internet.

In addition to security groups, AWS provides two services for securing ingress traffic:

* AWS WAF, a web application firewall
* AWS Shield, a managed distributed denial of service (DDoS) protection service

Securing egress traffic is trickier, because most instances need outbound internet access for basic operation, including for software patches and updates. In addition, applications often need to send or receive data to and from a third-party service or SaaS application.

Because the majority of cloud workloads are server applications (i.e., non-user), the list of hosts, protocols, and ports being accessed by each application is typically known in advance. As a result, a simple and cost-effective model for securing egress traffic is to allow traffic only to this list of known, trusted sites. These sites can be vetted by a security team ahead of each release, which effectively stops a hacker or malware from uploading your data to a nefarious site. It also allows you to keep an eye on where your applications are communicating.

Filtering can be accomplished by one of the following methods:

Security Groups

Security groups support IP address filtering, allowing you to block access right at the instance. However, you’ll need to translate the host name(s) to IP address(es) manually. Additionally, there are limits on the number of rules allowed in a security group (currently defaults to 60 outbound rules). And, potentially more important, IP addresses of hosts can change, so you will need to set up a process to keep these in sync. Because of these constraints, this option is often not a realistic option for large-scale enterprise application deployments.

Egress through your data center

This method backhauls your internet-bound traffic that originates from the cloud to your primary data center for filtering by your on-premises firewall. This is the simplest option; however, it introduces latency, complexity, and additional unnecessary cost of sending traffic outside the VPC that would otherwise be filtered.

Shared security VPC

Instead of sending all VPC egress traffic back to your data center, this approach sends the traffic to a single global shared security VPC or multiple regional shared security VPCs. Each shared security VPC contains a large instance firewall to handle filtering for many application VPCs. While this method keeps your data within the cloud, it still incurs additional unnecessary data transfer from the VPC to the shared security VPC. These central security VPCs require peering from the application VPC and also require more complex filtering rules if the filters are different per application or per VPC.

Inline VPC filtering

This method relies on a small gateway instance (a t2.micro instance, for example) to be deployed inline in each VPC. It is the most cloud-friendly design as it keeps the filtering closest to the source, and it also allows you to have very fine-grained control over where each VPC can egress. When combined with a solution offering centralized management and control, this method becomes the easy choice.

With internet (inbound and outbound) traffic covered, you next need to consider the traffic flowing from one VPC to another within AWS.

Securing network traffic between VPCs

As the number of VPCs for a typical customer grows into the hundreds, cross-VPC firewalling has become an important design consideration.

AWS offers two native ways to implement security policies across VPCs: network access control lists (ACLs) and security groups. Network ACLs offer subnet-level access control for inbound and outbound traffic, while security groups operate as a firewall for one or more associated EC2 instances. The entire list of differences is outlined in AWS’ VPC Security User Guide. Additionally, VPC Flow Logs allow you to capture and monitor traffic flow.

These native methods are difficult to manage for large-scale deployments. Instead, consider partner solutions like such as the one from Aviatrix, which has a stateful firewall built into the software-defined cloud router — allowing you to easily manage security policies for access between VPCs.

Securing remote user access to AWS VPCs

Securing user access to VPCs is often overlooked by organizations when it comes to securing their AWS environment. Allowing uncontrolled access by users can lead to data breaches, especially if users with access privileges move laterally to gain access to resources or data that they should not access.

For remote access, AWS has long recommended a bastion host solution, which had its roots when AWS operated as more of a developer’s world. However, this solution is no longer considered sufficiently secure for remote user access.

Instead, you should look for a remote access solution that includes:

Multi-factor authentication

Enforce two-factor authentication based on something the user has (such as a mobile device) and something the user knows (such as a password).

Authorization

This should be user- or profile-based rather than based on IP addresses. Mobile workers in a coffee shop often use different IP addresses than when they’re in the office.

Auditing

Ensure that you can report on which users accessed what resources. This is critically important if your organization falls under specific regulations such as HIPAA or PCI-DSS. Just as important as achieving compliance is your ability to prove compliance.

No single point of failure

Look for a solution that delivers high availability, is not limited to a single instance, can run behind a load balancer, and can scale out. Keep in mind that many data center-based user VPN solutions don’t support this capability in public cloud environments.

Operationalizing AWS connectivity and security

The need to segment applications depending on security rules, business units, cost centers, and mission criticality points to a preference for more VPCs. As a result, you need comprehensive connectivity across these VPCs, along with central security enforcement that implements firewall policies for cross-VPC traffic.

To maximize cloud infrastructure agility, you should be able to:

– Orchestrate and automate connectivity, route table updates and, firewall policies through CloudFormation, Terraform, and SDKs.
– Provide active monitoring of your cloud network with automatic fail-over when problems occur.
– Use non-shared keys for encryption.
– Visualize and log packet statistics for mission-critical application traffic.
– Troubleshoot easily with advanced capabilities such as packet capture.

Conclusion

Network security in public cloud environments presents challenges not encountered in on-premises data center environments. As more of your organization’s business is conducted in public clouds — and considering that AWS currently has the lion’s share of public cloud business — knowing how to secure network traffic to and from AWS VPCs is crucial.

AWS partners such as Aviatrix provide solutions to complement the AWS native services. Aviatrix, an AWS networking competency partner, provides a software-defined (SD) cloud router that automates and monitors your entire cloud network. This solution maintains a “security by design” approach that keeps traffic segmented and encrypted by default. And it does all of this with a simple, cloud engineer-friendly interface.

Learn more about how the Aviatrix software-defined cloud routing solution can help you achieve the network security and regulatory compliance required to support your public cloud computing strategies.