cancel
Showing results for 
Search instead for 
Did you mean: 
Login & Join the DevCentral Connects Group to watch the Recorded LiveStream (May 12) on Basic iControl Security - show notes included.
Mikhail_Fedoro1
F5 Employee
F5 Employee

Introduction

Everybody needs a WAF. However, when it gets to a deployment stage a team usually realizes that production-grade deployment going to be far more complex than a demo environment. In the case of a cloud deployment VPC networking, infrastructure security, VM images, auto-scaling, logging, visibility, automation, and many more topics require detailed analysis. Usually, it takes at least a few weeks for an average team to design and implement a production-grade WAF in a cloud. That is the one side of the problem. Additionally, cloud deployment best practices are the same for everyone, therefore most of well-made WAF deployments follow a similar path and become similar at the end. The statements above bring us to an obvious conclusion that proper WAF deployment can be templatized. So a team doesn’t spend time on deployment and maintenance but starts to use a WAF from day zero. The following paragraphs introduce a project that implements a Cloud Formation template to deploy production-grade WAF in AWS cloud just in a few clicks.

Project (GitHub)

On a high level, the project implements a Cloud Formation template that automatically deploys a production-grade WAF to AWS cloud. The template aims to follow cloud deployment best practices to set up a complete solution that is fully automated, requires minimum to no infrastructure management, therefore, allows a team to focus on application security. The following picture represents the overall solution structure.

0151T000003uuN8QAI.png

The solution includes a definition of three main components.

  • Auto-scaling data plane based on official NGINX App Protect AWS AMI images.
  • Git repository as the source of data plane and security configuration.
  • Visibility dashboards displaying the WAF health and security data.

Therefore it becomes a complete and easy-to-use solution to protect applications whether they run in AWS or in any other location.

Data Plane: Data plane auto-scales based on the amount of incoming traffic and uses official NGINX App Protect AWS AMIs to spin up new VM instances. That removes the operational headache and optimizes costs since WAF dynamically adjusts the amount of computing resources and charges a user on an as-you-go basis.

Configuration Plane: Solution configuration follows GitOps principles. The template creates the AWS CodeCommit git repository as a source of forwarding and security configuration. AWS CodeDeploy pipeline automatically delivers a configuration across all data plane VMs.

Visibility: Alongside the data plane and configuration repository the template sets up a set of visibility dashboards in AWS CloudWatch. Data plane VMs send logs and metrics to CloudWatch service that visualizes incoming data as a set of charts and tables showing WAF health and security violations.

0151T000003uuN5QAI.png

Therefore these three components form a complete WAF solution that is easy to deploy, doesn't impose any operational headache and provides handy interfaces for WAF configuration and visibility right out of the box.

Demo

As mentioned above, one of the main advantages of this project is the ease of WAF deployment. It only requires downloading the AWS CloudFormation template file from the project repository and deploy it whether via AWS Console or AWS CLI.

0151T000003uuN2QAI.png

Template requests a number of parameters, however, all they are optional.

0151T000003uuN3QAI.png

As soon as stack creation is complete WAF is ready to use. Template outputs contain WAF URL and pointer to configuration repository.

0151T000003uuN7QAI.png

By default the WAF responds with static page.

0151T000003uuNDQAY.png

As a next step, I'll put this cloud WAF instance in front of a web application. Similar to any other NGINX instance, I'll configure it to forward traffic to the app and inspect all requests with App Protect WAF.

As mentioned before, all config lives in a git repo that resides in the AWS CodeCommit service. I'm adjusting the NGINX configuration to forward traffic to the protected application.

0151T000003uuNCQAY.png

Once committed to the repo, a pipeline delivers the change to all data plane VMs.

0151T000003uuN4QAI.png

Therefore all traffic redirects to a protected application

(screenshot below is not of a real company, and used for demo purposes only).

0151T000003uuN9QAI.png

Similar to NGINX configuration App Protect policy resides in the same repository. Similarly, all changes reflect running VMs.

0151T000003uuNHQAY.png

Once the configuration is complete, a user can observe system health and security-related data via pre-configured AWS CloudWatch dashboards.

0151T000003uuN5QAI.png

Outline

As you can see, the use of a template to deploy a cloud WAF allows to significantly reduce time spent on WAF deployment and maintenance. Handy interfaces for configuration and visibility turn this project into a boxed solution allowing a user to easily operate a WAF and focus on application security.

Please comment if you find useful to have this kind of solution in major public clouds marketplaces.

It is a community project so far, and we need as much feedback as possible to steer one properly. Feel free to give it a try and leave feedback here or at the project's git repository.

P.S.: Take a look to another community project that contributes to F5 WAF ecosystem: WAF Policy Editor

Version history
Last update:
‎07-Sep-2021 08:25
Updated by:
Contributors