WAF Deployment Overview

Document created by Steve McBride on Jan 19, 2015Last modified by Rémi Le Mer on Oct 26, 2017
Version 20Show Document
  • View in full screen mode

Qualys WAF is an on prem, virtual appliance designed for easy and flexible deployment and management. You can completely manage the configuration and monitor security events through the cloud-based Qualys Portal. Your website traffic never leaves your environment, because the content inspection and attack mitigation is managed by the virtual appliances deployed alongside your web applications.

These virtual appliances are horizontally scalable, require no special hardware, and can be deployed using type II or III hypervisor (VMware vCenter, Microsoft Hyper-V) or cloud based instances (AWS ; or Azure or Google Computing Engine as of December 2017). VMWare and Hyper-V images are available for download in the Qualys Suite portal while the AWS AMI is available in the AWS Marketplace. Our Getting Started Guide will walk you through the various technical aspects of the WAF deployment and configuration.

 

Resource Provisioning

For a proper sizing please refer to the matrix below. The numbers can change in the future.

 

Performance Level (TPS = Transactions Per Second, SSL based)vCPURAMHDDNotes
Poor (less than 50 TPS)12 GB5 GBOnly for Trials/POC
Extra Small (up to 100 TPS)24 GB10 GB
Small (up to 250 TPS)48 GB20 GBRecommended minimum
Medium (up to 500 TPS)816 GB30 GB
Large (up to 1000 TPS)1632 GB50 GB
Extra Large (up to 2000 TPS)3264 GB50 GB
Double Extra Large (2000 TPS and above)64128 GB50 GB

 

Other than the minimum requirements, the resource allocation is quite flexible. You can allocate resources as needed, based on the number of web applications, traffic volume and other criteria.

Our Subject Matter Experts can work with you to evaluate the needs of your application and deployment environment, and make further recommendations as appropriate. 

 

Proper planning, as with anything, is the key to simple deployment of the Qualys WAF service. To that end, below is a rough outlined plan that will help highlight the important portions of a deployment, and hopefully will allow you to better understand the complexity and customer requirements.

 

Information Gathering

As with any security project, proper upfront information gathering is crucial. For WAF, that means not only gathering technical details, but also making some general architectural and policy decisions that will help guide this and future deployments.

 

First, you need to decide which application(s) to deploy WAF to. Once identified, you need to gather some technical details to ensure that you have everything you need up front - mise en place, if you will.

  • URL of the application you want to protect
  • identify the web server layer along with the framework
  • load balancer details for this application (which LB, and load sharing configuration if it's readily available)
  • SSL/TLS certificates keychain if the website serves HTTPS traffic
  • IP addresses or FQDNs of the backend web servers that serve traffic for your website
  • logical flow diagram for the application
  • business purpose for the site (this will help drive creation of policy). Is it mission critical ? Does it bring revenue ?
  • understanding of the application, and which components are dynamic versus static

 

These details should be understood up front, in a consulting-style kickoff meeting if necessary.  From there, for each application we need to make some architectural and policy decisions:

  • does the application *require* end-to-end encryption?  If it does not, it is much more efficient to offload SSL services to the load balancer and to pass to the WAF in the clear.
  • are there Source IP ranges or source countries we would like to treat differently?  (Not only black/white list, but threat influence can also be modified based on these criteria)
  • traffic enforcement : will we be blocking traffic for this application?

 

Now, based on the purpose of the application and the policy decisions above, we should be able to come up with general criteria for creation of a security posture for the application, which will drive policy creation in the Qualys Portal.

 

WAF Deployment Design

Based on the architecture, we'll need to determine how many appliances need be deployed. This will depend on the number of applications being protected and the need for fault tolerance within each application deployed. Second, it depends on the location of the web servers across your datacenters/cloud instances.

 

After we've determined that number, we'll need to come up with a structure for WAF Clusters (by data center or location, by application, etc.) which will help us when we configure the Portal and deploy.  We also need to determine if the appliances have direct access to Qualys (https://rns.qualys.com/ for US Platform 1,  https://rns.qualys.eu/ for EU Platform 1), or if they need to be proxied through your Corporate solution.

 

Initial Implementation (no impact to Production)

In this phase we'll allocate virtual machine resources for our appliances, deploy the appliances, configure network settings, and register them to the Qualys Portal through the appropriate RNS  service url.

We'll also create WAF clusters, applications, and build security policies. Once complete, we will be able to determine that connectivity to all components is configured and working properly without yet touching the Production application.

 

Test Implementation (no impact to Production)

Now that our WAF footprint is deployed, we'll start running some test traffic through it. The easiest way to do this is by creating a DNS name for testing (www-test, for example, to test www.)  We'll then add this new DNS name to the application configuration in the Portal, and create an appropriate load balancer configuration for the new DNS name, as if it were a production application. We can then begin sending live traffic on this "dummy" DNS name through WAF to the production application. In this way, we can test the production application without actually having any impact on the app itself (as only traffic destined to our dummy DNS name will be proxied by WAF).

 

Production Deploy

Here, we'll take what we've learned from the test deployment phase and use that knowledge in production. We'll need to simply modify the production firewall (NAT) and/or load balancer configuration to start routing traffic to WAF, and then test thoroughly.

 

Tuning (no additional production impact)

Once WAF is deployed, we'll need to work on tuning : evaluate security events, understand their impact and threat on the environment, and make appropriate and necessary changes to the WAF security policies.

 

When we're comfortable that WAF is operating properly, we should clean up after our testing - remove the load balancer and DNS configurations for the test URL.

 

Configure Blocking, if required

At this point we're comfortable that we've got solid security policies in place, and we can simply enable Blocking mode on the application. Again, as always, we'll want to test thoroughly to ensure we're seeing expected behaviour.

 

This document was generated from the following discussion: WAF Deployment Overview

3 people found this helpful

Attachments

Outcomes