WAF Deployment Overview

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

Qualys WAF is a virtual appliance designed for easy and flexible deployment and management. The management of the configuration is done through the cloud-based Qualys Portal, while the deployment is done on premise. Your website traffic hence never leaves your environment, as the content inspection and attack mitigation is managed by the virtual appliance deployed alongside the web servers. This virtual appliance is horizontally scalable, require no special hardware, and can be deployed using regular virtualization technologies (VMware, Hyper-V, KVM), cloud based instances (AWS, Azure, GCP), or through containers (Docker). WAF images are available for download in the Qualys Suite portal while the cloud-based AMI are available on the marketplaces. Our Getting Started Guide will walk you through the various aspects of the WAF deployment and configuration.


Resource Provisioning


For a proper sizing please refer to the matrix below (numbers can change).


Performance Level (TPS = Transactions Per Second, SSL/TLS enabled)vCPURAMHDDNotes
Extra Small (up to 250 TPS)24 GB10 GBProof of Concept
Small (up to 500 TPS)48 GB20 GBRecommended Minimum
Medium (up to 1000 TPS)816 GB30 GB
Large (up to 2500 TPS)1632 GB50 GBSuggested Minimum (for peaks)
Extra Large (up to 5000 TPS)3264 GB50 GB
Double Extra Large (5000 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. 


Information Gathering


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. 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 to deploy WAF to. Once identified, gather as much technical details to ensure that you have everything you need up-front - mise en place, if you will.

  • URL(s) of the application(s) you want to protect
  • business purpose for the site (this will help drive creation of policy). Is it mission critical ? Does it bring revenue ?
  • IP addresses or FQDNs of the web servers (frontends, but also backend)
  • logical flow diagram for the application
  • identify web server's underlying framework/application
  • identify load balancer details for this application (load sharing configuration if available)
  • SSL/TLS certificates keychain if the website serves HTTPS traffic (for SSL/TLS offloading)


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* specific TLS encryption attribute? You can shape it at the TLS Profile level, and offload server-side if required.
  • are there source IP ranges or countries you would like to treat differently? You can create User Custom Rules prior to deploying the Web Application.
  • traffic enforcement : will WAF be blocking policy violations against this application? You can set this at the Web Application level.


Based on the purpose of the application and the material above, we should be able to come up with general criterias for the creation of a security policy in Portal.


WAF Deployment Design


Based on the architecture, we need to determine how many WAF appliances should be deployed. First, it depends on the number of hosting locations, whether physical or logical (datacenters, cloud instances, branch offices). Second, it depends on the number of applications being protected, and the need for fault tolerance within each application deployed. Third, it depends on the amount of traffic (TPS) and the size of the internet bandwidth, as one may prefer scaling the appliances rather than defining its amount statically (in which case WAF container is a good option, coupled with clustering and orchestration solutions).

After we've determined that number, we'll need to come up with a logic for WAF clusters (like, by hosting location, by application, etc.). This will help deploy our appliances effectively.  We also need to determine whether appliances have direct access to the Qualys platform or if they need to be proxied.


Initial Implementation (no impact to Production)

In this phase we shall

  • create WAF clusters on Portal
  • allocate virtual machine resources for our appliances
  • spin the appliances
  • configure network settings
  • register them to the Qualys Portal by declaring the "waf_service_url" and the "registration_code" environment variables (at the sensor level)
  • create applications, TLS profiles, server pools, healthchecks, custom pages
  • if proxying an HTTPS app, declare the "waf_ssl_passphrase" environment variable (at the sensor level) to decrypt certificate's private key
  • setup the initial WAF security policy (pick a template and an HTTP profile)

Once complete, we will be able to determine that connectivity to all components is effective without yet touching the Production application.


Test Implementation (no impact to Production)

Now that our WAF footprint is deployed, we start running 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 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 was a production application. We can then begin sending live traffic to this "dummy" DNS name through WAF to the production application. 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 take what we've learned from the test deployment phase and use that knowledge in production. We need to simply switch the production network address translation (NAT) rule on the firewall 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 (mainly dealing with exceptions/false-positives). 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 want to test thoroughly to ensure we are seeing expected behaviour. While ramping up with the product, you can review the event logs and get to understand application's inner mechanisms. And of course, you shall enable ScanTrust and run WAS scan regularly to assess your WAF protection and enforce it if needed, either by updating the policy (templates, http profile) or by using custom rules (virtual patches, or custom).


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

4 people found this helpful