Securing ingress using security solutions and AWS Transit Gateway

Introduction

Internet-facing applications, by their nature, have a larger attack surface and are exposed to categories of threats most other types of applications will never have to face. Having the necessary protection from attacks on these types of applications, and minimizing the impact of attacks, are a core part of any security strategy.

Traditional AWS firewall techniques, such as the use of security groups and Network Access Control Lists, limit the attack surface for potential attackers and deny traffic to and from the source and destination of the attack. AWS Web Application Firewall provides deep packet inspection for web traffic and filters malicious traffic like XSS and SQL injection.

In addition, one use case for the recently launched AWS Gateway Load Balancer is to expose network security “as a service.” In this case, Gateway Load Balancer provides high availability and scaling of third-party appliance fleets. This creates new ways to deliver Network Function Virtualization (NFV) solutions.

Some customers have additional requirements beyond the scope of these network security controls, such as deep packet inspection (DPI), application protocol detection, domain name filtering, and intrusion prevention system (IPS).

AWS Network Firewall addresses the aforementioned features and offers a scalable, stateful, managed, network firewall and intrusion prevention service for your VPC. Customers today might also choose to add third party host-based or inline IDS/IPS systems that use statistical/behavioral or signature-based algorithms—in order to detect and contain network attacks and Trojan-horse malware. You can choose from a variety of third-party firewall instances available in AWS Marketplace to monitor and analyze network traffic, log files, and access in order to spot any traffic generated by malware. As mentioned previously, you can use security groups and network ACLs to further minimize your attack surface.

Clearly there are a lot of options to consider. In this post, we look at one specific case: how to use third-party firewall instances to perform deep packet inspection for ingress workloads that use TLS for communication in a centralized manner. We review a tiered architecture using Application Load Balancer and an Auto Scaling group of firewall-instances. The application tier is spread across multiple accounts or VPCs, and is connected using Transit Gateway. It also enables you to scale your security inspection tier and the web front-end tier independently of each other.

Architecture

Let’s take a look at the target architecture and ingress inspection. In this approach we use three different VPCs, but the design can be extended to any number of VPCs and/or accounts. In the DMZ VPC, an auto scaling group of firewall instances with Internet facing Application Load Balancer are created. We centralize any traffic coming from internet in DMZ VPC. The DMZ VPC is connected to spoke VPCs using the Transit Gateway.

The listener rule on the internet facing load balancer is updated to segment application traffic. We use the same auto scaling group of firewall instances, creating unique target group ports for each application on the firewall. The application traffic flows through the internet facing Application Load Balancer on a listener port (for example, 80). Based on the host header in the request, the ALB rule determines which target group port (a custom port) it needs to forward the traffic. The firewall has NAT rules based on the incoming port that forwards the traffic to the destination service by performing port address translation (PAT). An example of this traffic flow is shown in the following diagram.

ALB rules to segment traffic flows through Application Load Balancer and Target groups

A message is published to an SQS queue present in a DMZ account upon creation of any new application. This message triggers a Lambda function that configures necessary NAT rules on the firewalls. Here, we are showing how this works with a Palo Alto firewall. We’ve decided to use Palo Alto because of our previous experience with Palo Alto–but the architecture presented in this post can be implemented with any partner firewall vendors listed in the Additional Resources section at end of this post.

Implementation

Overview of the templates used:

Firewall – firewall-template.yaml

• This template deploys an external load balancer and VM-Series Palo Alto firewalls. These firewalls are in an auto-scaling group across two Availability Zones.
• The external load balancer distributes incoming VPC traffic across the VM-Firewalls. In this case we are using Application load balancer.

Transit Gateway – transit-gateway.yaml, transit-gateway-attachment.yaml and transit-gateway-propagations.yaml

• These templates ensure the DMZ VPC and Spoke Application VPCs are connected.

Application – application-template.yaml

• This template deploys an internal application load balancer for your application instances in spoke VPC. You have a choice to create either an Application or a Network Load Balancer.

Listener rules – alb-rules.yaml

• The template creates the setup required for multi-application support. It updates the existing Load Balancer listener rule and forwards the traffic to a specific Target group. The forwarding is done based on host header feature as DNS name.

Since we are using Palo Alto in this case, these prerequisites are required for our deployment using Panorama:

• Panorama
• Panorama API key
• Panorama VM-Auth Key
• Bootstrap Files

Descriptions on prerequisites :

Panorama –

• Allows centralized management for VMs and can be configured as log collector.
• Panorama mode is used to manage multiple Palo Alto firewalls.
• Configure panorama network interfaces using DHCP.

Panorama API Key –

• Required for Lambda function to configure Panorama with template and device group option.
• This key is then used to authenticate APIs.
• Generate an API key with GET or POST request to the Panorama’s IP addresses using the administrative credentials and “type=keygen”. You can run this command from any host machine that has connectivity to the Panorama_IP_address.

curl -k -X GET 'https://<Panorama_IP_address>/api/?type=keygen&user=<username>&password=<password>'

or

curl -k -X POST 'https://<Panorama_IP_address>/api/?type=keygen&user=<username>&password=<password>'

Successful response will return with status=”success” along with the API key within the key element. More information can be found here.

Panorama VM-Auth-Key –

• This enables the bootstrapped firewalls to connect to Panorama and get their bootstrap configuration. More information can be found here.
  To generate the VM-Auth-Key, use the following command on Panorama CLI:

Request bootstrap vm-auth-key generate lifetime <1-8760>

Or

To generate the VM-Auth-Key, use the following API command:

https://<Panorama_IP_address>/api/?type=op&cmd=<request><bootstrap><vm-auth-key><generate><lifetime><number-of-hours></lifetime></generate></vm-auth-key></bootstrap></request>

Bootstrap Files –

• This provides a sample init-cfg.txt file from GitHub to help configure VM-Series firewall with basic configuration.
• Perform interface swap so the VM-Series firewall Untrust traffic uses AWS ENI for eth0.
• Connect to Panorama for device group and template configuration.
  For detailed information, please check the prerequisites.

Deployment steps

The deployment for our solution mainly consists of five steps. An overview of these steps are provided below :

1. Set up the Firewall Template

• In this step, we create the firewall instances in an Autoscaling group.
• We bootstrap the firewall instances with configurations required to register them with Panorama.
• We create an external application load balancer and associate it with the Autoscaling group of firewall instances.
• We create a SQS queue that monitors for the launch of any applications launched via the application template.
• We create a lambda function which monitors the SQS queue for any messages on creation of an application load balancer. Upon receipt of a message, the lambda function creates a new NAT policy rule on the VM firewall within the Autoscaling group.

2. Create TGW and share with spoke accounts/VPCs

• In this step, we create a transit gateway with two routing domains.
  • DMZ VPC routing domain
  • Spoke VPC routing domain
• The transit gateway is then shared with other AWS accounts via AWS Organizations.

3. Set up the Application Template

• In this step, we create the resources for running your application.
• We create an internal load balancer that load balances your application traffic.
• We also publish necessary messages to the SQS queue created in step 1 that creates NAT rules on the firewalls for each application.

4. Enable connectivity between spoke account/VPCs and DMZ VPC

• In this step, we enable connectivity between DMZ VPC and spoke VPCs that reside in an account/different accounts.
• The lambda function that is created by the template ensures that the TGW attachments are tagged, associated to the right routing domains, and the necessary propagations are made.

5. Update the Listener rule for existing Application Load Balancer

• In this step we configure with External Application load balancer listener rule to distinguish application traffic based on host URL.
• We create different target groups with the same set of firewalls in an autoscaling group, but map each application to a unique target group port.

The detailed deployment steps can be found on aws-samples-repository.

Clean up

After successful testing and validation, all resources deployed through CloudFormation templates should be deleted in order to avoid any unwanted costs. Simply go to the CloudFormation console, identify the appropriate stacks, and delete them.

Note: If you use a multi account setup, you must navigate through account boundaries and follow the above steps as needed.

Conclusion

In this post, we introduced a solution using a third-party firewall in an Autoscaling group and a AWS Transit Gateway to inspect encrypted inbound internet traffic and filter it according to your security policy requirements. We achieved this by creating the following resources:

• A DMZ VPC hosting the security instances that inspect any inbound traffic from the internet.
• A Transit Gateway that centralizes the communication between spoke VPCs and the DMZ VPC.

We used Palo Alto firewalls for traffic inspection, but you can deploy similar security solutions from many AWS Partner Network ISVs in AWS Marketplace. The ELB page also has a list of third-party solutions that might be helpful.

About the Authors