Using F5 Application Security and DOS Solutions with AWS Global Accelerator - Part 4 Testing

Here we are in part 4. Thank you for taking the time to read part 1, part 2 and part 3. If you have made it this far you are interested in answering the following questions:

Creating attack traffic to validate the CloudWatch dashboard.
Hardening the deployment.
Using F5 NGINX Plus or F5 Distributed Cloud
Further reading

Generating Attack Signatures and Evaluating Dashboard Data

There are many tools that you can use to generate attack signatures and investigate WAF/DoS functionality. I would like to break this discussion down into two considerations efficacy and signature testing.

Efficacy Testing

If you are not familiar with F5 security solutions you will need to change your perceptions of how to validate if a WAF is effective. Many commercial and open source WAFs reply to any blocked traffic with an HTTP status code, with 403 being the most common. Some WAFs allow you to customize the response code, but default to 403 or a similar singular response code. By Default F5 security solutions do not always return 403 and many times when we block traffic the response code is still a 200 OK. While this behavior is customizable you need to be aware of it. When you are ready to use a WAF scanner to evaluate how effective your WAF is please customize the response codes to get a more accurate view.

A final note - an automated scanner can help you validate that a WAF is working and create custom security policies but it is not a replacement for actual pen tests.

For information on how to change Advanced WAF responses please see this article.

Generating Traffic - Signatures

In order to test our security deployment, we need to validate that signature matches are being logged and that the dashboards are seeing them. Strong script writers may choose to generate their own traffic generation tool by leveraging one of the numerous signature libraries you can find on GitHub. If you explore this path make sure you also experiment with different encoding within the requests, custom headers (x-my-header) and other bypass techniques such as:

mixed case
url encoding
unicode encoding
mixed encoding
double encoding
escape characters
variables
tab/line feed insertion
space insertion / removal
other ways to mess with the requests.

For those that aren't so inclined tools come into play, and Kali Linux is a phenomenal tool for this purpose (I hope this goes without saying, only run Kali against YOUR deployment or a deployment that you have legal authorization do do so).

Step 1 - validate that you can can get proper HTTP requests and responses.

curl http://<my site>

Example

Heath.Parrott@C02G10ABMD6R SSH_AWS % curl -vvv http://my-site
*   Trying x.x.x.x:80...
* Connected to my-site (x.x.x.x) port 80 (#0)
> GET / HTTP/1.1
> Host: my-site
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 1626
< ETag: W/"65a-DkVT0mEZFg6HJrZHh+PjVQ"
< Date: Tue, 20 Dec 2022 19:27:32 GMT
< Connection: keep-alive

If you are using the default F5 security policy you should be able to send a PUT request and receive a blocking response.

Heath.Parrott@C02G10ABMD6R SSH_AWS % curl -X PUT -vvv http://my-site
*   Trying x.x.x.x:80...
* Connected to my-site (x.x.x.x) port 80 (#0)
> PUT / HTTP/1.1
> Host: my-site
> User-Agent: curl/7.79.1
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< Cache-Control: no-cache
< Connection: close
< Content-Type: text/html; charset=utf-8
< Pragma: no-cache
< Content-Length: 247
< 
* Closing connection 0
<html><head><title>Request Rejected</title></head><body>The requested URL was rejected. Please consult with your administrator.<br><br>Your support ID is: 10525269545889829580<br><br><a href='javascript&colon;history.back();'>[Go Back]</a></body></html>%                                                                                                                                                                                                    Heath.Parrott@C02G10ABMD6R SSH_AWS %

You can see that my request above was blocked (in this example it was a 403, but it could have been a 200) and that a support ID was included in the response. You can look up this support ID in cloud watch with the following query:

{$.support_id = 10525269545889829580 }

Here is a screen shot of the search:

And we can see that the request is blocked and why (Illegal method).

Using Kali

Now that we have validated that we are operational it is time to look at the array of tools in Kali. The ones listed below and how I used them are just examples.

Tool	Use / Vectors
Commix	Command injection and exploits
Nikto	Web server scanner
Skipfish	Web app scanner and recon

Running these tools should cause us to see an array of signature matches in our logs. Since we have enabled BOT protections you may need to change the User-Agent to ensure that we are not blocking traffic based on the User-Agent header.

Compared to below where I see my user agent to CURL

Right after launching Commix I can see my violations increasing, a larger array of signatures and violations with different ratings. Here is an example from my AWS CloudWatch dashboard showing these violations.

Once everything is in order, logs are appearing and you are felling comfortable with the environment it is time to go from a lab to production deployment.

Hardening and Production

In our deployment we left Elastic IPs (EIPs) on our interfaces. This is not recommended or required. If you are going to production ensure that you remove them or properly secure the F5 management functions.
Review and implement the BIG-IP Hardening Guide
F5 instances do need internet egress to onboard, if you are not assigning Elastic IPs please ensure that you have NAT functionality on the network and have deployed EC2, S3 and CloudWatch endpoints into the VPC.
The script used to populate AWS Global Accelerator targets based on AWS AutoScale groups was provided to F5 via AWS blogging and is provided as an example. It is validated to work as of this writing.
F5 CloudFormation Templates are provided as examples of how do achieve a goal in AWS. Templates are community supported. The templates leverage supported components of our automation tool chain.
Use IAM roles assigned to BIG-IP instances to allow CloudWatch logging (role is created as part of the templates).

F5 NGINX App Protect WAF and F5 NGINX App Protect DOS

NGINX App Protect WAF combined with NGINX App Protect DOS can also be used for this use case. While it does have a different mechanism to configure and manage the system, support for advanced WAF services and L7 DOS security are available via the App Protect modules.

If you would like to get started with App Protect please see this article from Leon Seng. When it comes to scaling NGINX Plus via AutoScale groups please see this article in the NGINX Plus documentation. For logging and visualization please see the DevCentral GitHub repo nap-dos-elk-dashboards.

Currently (December 2022) F5 only offers NGINX Plus App Protect WAF in the AWS marketplace. For a flexible consumption program with both features please contact your F5 sales team.

F5 Distributed Cloud

For customers that are looking for a SaaS-delivered proxy solution F5 Distributed Cloud may be a better fit. F5 Distributed Cloud offers an array of services from Mutli Cloud Networking (MCN), Web App and API protection (WAAP), Application Infrastructure Protection (AIP) and many other services. To get started with Distributed Cloud in AWS please see details of an AWS site

Conclusion

Thank you for spending time with me over these 4 articles. I hope you have found the useful in understanding how F5 security offers can compliment AWS Global Accelerator.