Increase Security in AWS without Rearchitecting your Applications - Part 3: Wednesday Afternoon

It is a good thing you took a lunch break!  This morning was busy on the F5 side, and now we'll dive into AWS. 

Deploy a Gateway Load Balancer

AWS Gateway Load Balancers are similar to other AWS Load Balancers.  They are EC2 constructs and use a target group. This target group will be based on the IP Addressee(s) of our SSLO Eth1 interface.   Let's look at the creation of a Gateway Load Balancer. Navigate to EC2 > Load Balancers > Gateway Load Balancers and deploy a GWLB to our Security VPC (across AZ LB should be enabled)

If you have not already created a target group, you will need to do so.  The target group uses the self IP and runs its health monitor outside of the tunnel.

On SSLO there is a port 80 virtual server listing on the same IP as used in the target group and responds to the health probes.

AWS GWLB can operate in IPv4 or dual stack IPv6.  The same geneve tunnel configuration we covered on Wednesday morning will work with both (and the addition of IPv6 configuration on BIG-IP virtual servers)) and has been validated against single security appliance use cases (Adv. WAF).  There is no reason to think that it would not work with SSLO.

Prior to use our GWLB needs to be published as an Endpoint Service. To create a VPC Endpoint Service navigate to VPC Endpoint Services > Create and follow the prompts selecting the name of your GWLB and other related information.

 

Application VPCs require VPC Endpoints. To create a VPC Endpoint you will need to navigate to VPC > Endpoint > create.   You will use the "other" category and the name of the GWLB endpoint service.

You will repeat this per AZ for a GWLB endpoint.  In the image below you can see two VPC Endpoints named GWLB-VPCE-MainVPC reflecting this requirement.

In summary the objects we need to bring VPC endpoint online for a protected VPC looks like this:

Once the VPC Endpoints are created in your application VPC you will need to update the route tables as necessary. 

Application VPC Traffic Flow

Every organization is interested in protecting one or more applications, and they could be in multiple VPCs. These Application VPCs provide the networks where we will use to intercept the traffic and inspect it via our security services.  An application VPC will generally have a structure along the following lines.  1 or more subnet(s) per Availability Zone for ELB, NLB endpoints.  1 or more subnets per AZ for application workloads such as EC2, EKS, etc.  One or more subnets to place service objects Transit Gateway attachments and other internal endpoints such as S3 and EC2.   To insert our security services we will need to create 1 subnet per AZ for the GWLB endpoint  (it should be on a different subnet from TGW endpoints).  If your goal is to inspect internet sourced/bound traffic this subnet will need to be in route table connected to an IGW.  

If we look at the ingress flow, we see that traffic enters our environment from a gateway (or ENI) and the route table intercepts the traffic sending it to a GWLB Endpoint in the application VPC.  By using the route table construct we can insert security services between network endpoints.  In the example below we have a solid black line representing the request and response from an internet source client and a dotted line that represents the request and response between two internal resources.

In the above diagram I would like to discuss a nuance.  Traditionally in AWS a public subnet is one that is in a route table with an IGW and a default route to the IGW.  In our topology we have instances and ELB endpoints that have mapped, and functional EIPs assigned to them but they are on a subnet and in a route table that points to the VPCE as the default route and does not have an IGW attached to it.  Above the compute public subnet is aligned to the second description.

Examples form my lab

Public Route Table – this hosts my ENIs for the GWLB service, an IGW and a default route for internet access.

Ingress Route Table – This has an Edge association with my IGW and steers traffic from the IGW to my “public” subnets for my applications such as instances and ELBs to the VPC endpoints.  There are not any subnets associated with this route table.

AZ Route Tables that my associated application subnets are associated with. If will have one per AZ.  These are all nearly identical except the VPC Endpoints used for the default route changes.  

In the above image you can see a route for 10.1.72.0/24 pointed to a VPC endpoint. This is another subnet in the same application VPC and demonstrates how to insert the security services for east/west intra VPC security. Looking at the route table that 10.1.72.0/24 is associated it with you will see that it is sending all traffic to other internal subnets to a VPC Endpoint.  

Elastic Load Balancers and Servers with Public IPs

One of the benefits of using F5 security in combination with GWLB is that a security team can provide security services for applications that area already or will be deployed with an ELB.  Below you an see there is a subnet in each AZ that I am using for this purpose (10.1.62.0/24 and 10.1.162.0/24). I have also deployed two subnets to host servers (10.1.10.0/24 and 10.1.110.0/24). In the image below we can see AZ A subnets that are protected by GWLB and if you look above at the Route section you will see a default route pointing to a VPC Endpoint.

Here you can see that my ELB has listeners on 10.1.62.0/24 and 10.1.162.0/24 subnets

Please note that when you use a subnet for an ELB that is protected in this manner you will get a a warning from the AWS console. The logic in the console is related to the presence of an IGW in the subnets route table and does not currently check of the route is going through a VPC Endpoint.

Why would I put my ALB on this subnet?  Here are a couple of examples

- Inspect ALB traffic prior to SNAT to backend instances 

- Drop undesirable traffic before processing 

- Support security systems that cannot use XFF

- Client certificate Auth

Understanding the Network End to End

Let’s look at what this whole thing looks like when we have a protected Application VPC and a Security VPC and follow the traffic flows.

 

Application VPC Subnet to Route Table Mapping	Application VPC Route Table
10.1.52.0/24, 10.1.152.0/24	GWLB Public Subnet Route Table
10.1.10.0/24, 10.1.100.0/24, 10.1.62.0.24, 10.1.162.0/24	Compute “Public” Subnet Route Table
10.1.72.0/24	Private Subnet Route Table - Internal or East/West applicability (examples include TGW, VPN or DC)
None	Ingress Route Table, Edge association to IGW in Public Route table. Not pictured below. Logical construct to steer internet related traffic.

Ingress/North to South

IGW > GWLBE  > SSLO > Security Services > SSLO > GWLBE >  ELB/Instance. 

Reverse path on the way out.

Egress/South to North

Instance > GWLBE > SSLO > Security Services > SSLO > GWLBE > Internet Endpoint.

Reverse path on the way in.

East to West

Instance A > GWLBE > SSLO > Security Services > SSLO  > GWLBE >  Instance B.

Reverse path on the way back.

AWS Route Table Constructs – Both VPCs

As you can see there are many components that need to be placed in the route tables and subnets to align. To help with this here is a table. This pattern is at the AZ level.

Route Table Function	IGW Attached	Associated Subnets	Default Route Path	Known Address Space Path - Inspected	known Address Space Path - Non Inspected	Notes
Protected VPC Public	True	Public Subnets, GWLB Subnets	Internet Gateway	GWLBE in AZ	Local Route, TGW attachment, VGW Attachment	Use as the Edge association with other route tables in the VPC.
Protected VPC Edge Association	False	None	Edge Association with IGW	GWLB Endpoint in AZ	N/A No subnets are associated	Edge association creates the rule that intercepts and steers the traffic.
Protected VPC Private Networks	False	All not in public route table	GWLB Endpoint in AZ	GWLB Endpoint in AZ	Local Route, TGW attachment, VGW attachment, Peering
Security VPC Public	True - see notes Public subnets	Internet Gateway	Do not use route tables for inspected traffic	Local Route, Does not need path to VPCs via TGW or Peering	A public route table is not required in the security VPC. Security path should not have public access
Security VPC Private	False	Can be all	NAT Gateway if devices need access to onboard.	N/A - You do not use AWS route table constructs to steer traffic between instances	N/A - This VPC does not need access to the protected VPCs via TGW or Peering. If other VPCs as part of the security service - TGW or Peering

A note about AWS API Endpoints: one should leverage EC2 and S3 endpoints in your VPC and ensure that traffic patterns between instances and the endpoints are not intercepted. As an example, these endpoints could be in the same subnet that the TGW attachments are located and leverage the local route to access them.

Conclusion

Thank you for taking the time to learn more. On Thursday we will look at scalability, resiliency and and common troubleshooting scenarios.