Using F5 Application Security and DoS Solutions with AWS Global Accelerator Part 1

F5 Security Services and AWS Global Accelerator

Many applications require network optimization and security services and are not optimized for caching. For these applications it is common to see them deployed with few to no optimization services and limited security. Let's examine the benefits of a network architecture that is optimized for security and performance and apply that context to how F5 and AWS Global Accelerator can address these applications.

We will explore how users can:

Increase network performance by minimizing loss, latency and jitter
Detect and prevent L3/L4 volumetric attacks such as connection floods, reflections, and TCP/UDP protocol validation
Detect and prevent malicious BOT attacks
Leverage signature and behavioral signals to prevent application attacks
Prevent L7 DoS attacks

A Brief Overview Networking Performance and how AWS Global Accelerator Helps

When two systems communicate they, generally, determine if they are going to use TCP or UDP. Independent of which transport protocol the majority of applications behave in a request and response pattern where a client requests something of a server and the server provides a response. This pattern means that variables of capacity, distance and network conditions will have material impact to how the user perceives application performance. By many measures this will be a leading factor in how on what user judges performance on.

AWS Global Accelerator provides many of the same benefits.

More than 104+ POPs globally, each able to present your accelerator to the Internet, providing endpoint diversity and proximity.
For TCP applications the initial termination points is moved closer to the user, increasing the network performance for TCP based applications.
Optimal network path to AWS Regions. By using the AWS backbone between the edge and the application much of the latency and jitter present the Internet is removed increasing network performance.

Click here more information on AWS Global Accelerator.

Attacking the Network and Transport Layers

When we architect an application to withstand a network layer attacks the most vectors will be amplifications (network) and transport layer (protocol). An attacker is looking to exhaust the system resources related to the network bandwidth, memory or processing of the targets network stack such as application servers, reverse proxies and firewalls. To address this attack we need to think about horizontal scale across multiple dimensions.

Defensive Measure	Description	How we will meet the challenge
Scale the application servers horizontally.	This can be achieved with use of a load balancing system. Normally load balancing systems are combined functionality with reverse proxies.	Global Accelerator provides abstraction of regions, availability zones, and application servers providing basic load balancing and simple persistence. Our security services will leverage Application layer constructs as necessary.
Scale the number network connection points	Increase the number of places our endpoint IP address is presented to the Internet. This may be referred to as IP anycast.	Global Accelerator provides BGP peering and a presents the network ranges at 104+ POPs globally
Increase network bandwidth	The amount of network bandwidth do we have to deal with reflections, floods and other traffic that can saturate traffic coming to our endpoint.	Each of the Global Accelerator POPs has large volumes of bandwidth to the Internet and on the AWS backbone connecting to our security services
TCP/IP protocol validation	Malformed transport protocols such as SYN floods and other half open connections consume memory on our network devices	Global Accelerator provides TCP/UDP endpoints that will validate the protocol characteristics and the POP diversity make resource exhaustion and bypass extremely complex

High Level AWS Global Accelerator Architecture

AWS Global Accelerator attracts traffic and passes it to the following objects inside of AWS such as EC2 Instances, ELB, or Elastic IPs.

For EC2 endpoints behind Global Accelerator F5 provides a Layer7 DDoS Solution to optimize your deployment for security and performance. Below are questions to consider.

Do I have a security solution?	Does my security only address known threats (IE based on signatures)?	Will my security solution detect BOTs?	What about malicious behavior?
Do I have the ability to mitigate by creating dynamic signatures?	Can I create stepped mitigation such as CAPTCHA, Rate Limit and Block?	Can my security solution learn my application?	Does my security solution evaluate threats on multiple vectors such as signature, behavior, protocol compliance?
How do I prevent credential stuffing attacks?	How do I mitigate AI, Automated CAPTCHA solving and Human attacker farms?	How do I prevent fraud?	How do I deal with the ever changing landscape of IP's that have attack reputations?
What can I do about emerging Threat Campaigns (current attack trends)?	Does my security solution help me score traffic for False Positive and False Negatives?	Does my security solution support web, mobile and API traffic?	Does my security solution support as code management and deployment?

At this point you will have two choices:

1. Build all of these services into each and every application endpoint

2. Deploy an automated, reusable, blueprinted solution that is focused on security

The choice that cannot be made is to do nothing and hope you do not become a story in the evening news.

Introducing Application Security and Application DOS Insertion Architecture

Most organizations do not want to keep reinventing the wheel when it comes to security, authentication, zero trust or other critical services for each application they must deploy. To address the challenge you will need to insert security into the data path. While the picture does not change much, it will allow us to answer yes to the questions above and more.

The security insertion point can be BIG-IP platforms or NGINX+ platforms. The correct choice will be a decision based on your needs around the security stack and influenced by the team(s) that own the cloud platform.

Putting the End to End Security Path Together

If we line up the traffic path we will see a pattern like this: Clients connect to the closes Global Accelerator Endpoint. The Global Accelerator will mitigate the volumetric and L4 protocol attacks passing common L7 traffic to the configured endpoints. F5 BIG-IP or NGINX endpoints will parse that L7 traffic based on security policy, traffic attributes and make a decision to permit, deny or rate limit traffic to the application endpoints.

Agility, Elasticity and Service Discovery

For an organization to the most value from public cloud agility is a requirement. Solutions that require repeated manual configuration steps, deployments that are static, or require other human intervention are an anti-patterns. This solution supports dynamic scale at the security layer, service discover at the application layer and the ability to use common cloud or enterprise logging targets such as CloudWatch, Splunk or ELK (to name a few).

We will look at logs and graphs later in the series.

Elasticity of the Security Layer

Yes. Yes. Yes. Elasticity is supported at the security layer. To properly address this solution we need to address this question at the security layer and at the Global Accelerator layer.

F5 has supported AutoScale solutions for years. With the release of our CloudFormation V2 solutions we have leveraged the F5 Automation Tool chain and their declarative interfaces to build solutions that support large scale horizontal deployments. When users deploy an F5 AutoScale group in AWS instances leverage template files to create the configuration. Every instance in the group will receive the same configuration. When users want to update the configuration they simply created a revision of the file and perform a CloudFormation stack update. You can read more about F5 AutoScaling here.

AWS Global Accelerator does not have a native integration to read AWS AutoScale groups. The good news is that this problem has already been solved and documented by AWS. Enter using EC2 lifecycle hooks and AWS Lambda. If we look at the following blog we can see that instances can be added to target groups based on scale in and scale out events. Cool.

We will explore AutoScaling in more detail in later parts of the article series.

What about Service Discovery of My Application?

Important question. TL;DR - yes. Both the BIG-IP and NGINX platforms support service discovery of all different types of AWS resources. The diagram above depicts applications on EC2 instances, EKS, ECS and Fargate. We could go one step further and simply say if the network can connect to it we can protect it and you can use it for you application.

Platform	Service Discovery Option
BIG-IP	DNS A Records
BIG-IP	AWS Instance Tags (example autoscalegroup tag)
BIG-IP	ENI Tag
BIG-IP Event Listener/API	Third party pushes pool information to BIG-IP
BIG-IP Container Ingress	Listens for containers and updates BIG-IP
NGINX	DNS A and SRV records
NGINX	AWS AutoScale groups

We will use service discovery of our demo application later in the article series.

Wrapping up

Now that we have an idea of why we need to do take action on security when using AWS Global Accelerator and we know what we are going to do we need to get our hands on experience and put things to the test. We will do that in part 2 of the series Here is a sneak peek at what we will build in the next session: