If you host apps in the cloud, then you need security in the cloud. The Imperva SecureSphereWeb Application Firewall (WAF) identifies and acts upon dangers maliciously woven into innocent-looking website traffic, both on-premises and in the cloud, such as:
Blocking technical attacks such as SQL injection, cross-site scripting and remote file inclusion that exploit vulnerabilities in web applications;
Business logic attacks such as site scraping and comment spam;
Botnets and DDoS attacks; and
Preventing account takeover attempts in real-time, before fraudulent transactions can be performed.
In this post, we’ll walk through the steps needed to deploy a SecureSphere WAF to protect an existing Azure-based web environment. Imperva also provides a quick-start Azure Resource Manager (ARM) deployment template which could be useful as a reference for automating the deployment process (for more details see “Deployment Kit ARM Template” below).
Deploying SecureSphere WAF on Azure
A typical deployment of SecureSphere WAF on the Azure platform includes the following elements (see Figure 1):
SecureSphere Management Console (MX): The MX is required to specify networking rules, manage security configurations, handle security violations and produce reports.
Layer of SecureSphere WAF Gateways: These are the WAF instances that process the traffic and apply the security.
External Load Balancer: The load balancer will distribute the traffic between the deployed WAF gateway instances.
Internal Load Balancer: The WAF load balancers distribute traffic from the WAF among the deployed web servers.
Figure 1: Typical Azure deployment environment with SecureSphere WAF
Before You Begin
Make sure you have the following prerequisites on hand/in place before you begin deployment:
Imperva License File. The license can be obtained through Imperva.
Virtual Network and Subnets, in which the WAF instances will be deployed.
Deploying SecureSphere Management Server
The first step in deploying the Imperva SecureSphere WAF is to deploy the SecureSphere Management Server. Below are the steps.
From the tiles, select Marketplace (or select Browse > Marketplace), and search for Imperva. Select the latest version of SecureSphere Web Application Firewall.
Create a new deployment. Specify the required parameters, including:
Deployment name; user name; authentication details; resource group.
Hint: Make sure that the MX is not accessible from the internet.
Select the desired machine type. Instance type A3 and above is recommended. More powerful instance types may improve the WAF performance.
Launch the “First Time Login” operation:
Once the virtual machine is ready, connect to it using SSH.
Operation is launched by typing ftl in the command prompt. Follow the instructions on screen. Make sure to select component type Management. For detailed information on the FTL process consult the SecureSphere deployment guide.
After the FTL operation finishes successfully, upload the license:
Login to the web console: point your browser to https://<Your Management IP address>:8083.
Hint: Accessing the web console may require using a hop server if access from the internet is not allowed.
Enter admin username credentials.
Upload the license file in the license window.
Deploying SecureSphere WAF Gateways
After you’ve completed the steps above, you follow these steps to deploy a highly-available stack of SecureSphere WAF gateways.
Deploy SecureSphere WAF Gateway instances. Repeat steps 1-4 from the “Deploying SecureSphere Management Server” section.
To ensure high availability add all WAF Gateways to Availability Set.
Azure guarantees that machines that are in the same Availability Set are in totally separate fault domains, and therefore are not vulnerable to the same local failure.
Launch the “First Time Login” operation on each Gateway machine:
Once the virtual machine is ready, connect to it using SSH.
Operation is launched by typing ftl in the command prompt. Follow the instructions on screen.
Make sure to select component type Gateway.
This operation will also bind the Gateway and the Management Server (by specifying the MX IP address). For detailed information on the FTL process refer to the SecureSphere deployment guide.
After the SecureSphere WAF MX and Gateways are in place, it’s time to configure the networking and allow the traffic to flow from the External Load Balancer to the Internal Load Balancer(s):
Access SecureSphere console via a web browser using the following path: https://<Your Management IP address>:8083 and log on.
Place the Gateways in the same Gateway Group, this way all the gateways will apply the same routing and security policies.
For each Gateway in the Gateway Group, create an alias – a mapping of network interfaces. Give all the aliases in the same Gateway Group the same name. The alias will be used when configuring networking rules.
Within the Site Tree configurations, create Server Group and HTTP Service.
Server groups are a representation of one or more servers located in a specific site.
Web services represent the services that SecureSphere monitors.
In the HTTP Service Reverse Proxy configuration, create Reverse Proxy rules. Every rule created will direct the traffic to a different destination (for example, a different Internal Load Balancer). For detailed information on the configuration process refer to the SecureSphere deployment guide.
Testing the Deployment
Once the deployment process is finished, you then validate that everything is configured properly.
To test the deployment, generate valid HTTP calls to the external load balancer and make sure you receive the expected response from the web servers.
To test the security configuration, generate malicious HTTP requests. Log into the SecureSphere MX and look at the alerts dashboard, to check if new violations are generated. This is the time to tune the security configuration.
Hint: make sure that the security policies are applied to the web services you created.
When security is properly tuned, you can switch to “active” mode and start blocking malicious traffic.
Consider these helpful hints for your deployment:
Auto-Scaling: It’s possible to deploy an Auto-Scaling SecureSphere Environment. Auto-scaling allows you to automatically launch new WAF instances as the load increases. More information is available in the SecureSphere documentation.
Static IP Addresses: By default, new machines in Azure are created with a dynamic private IP address. Since this can cause communication problems between the different SecureSphere elements if the IP address changes after restart, you must configure the IP address assignment as static after the machine is deployed.
External Load Balancers and Session Stickiness: As the SecureSphere WAF Gateway is sensitive to session state, it is highly recommended that you enable session stickiness on the external load balancer.
VNet-to-VNet Connection: In a situation where there is more than one VNet, and there are Gateways on all the VNets but only one Management Server on one of the VNets, you may use a VNet-to-VNet connection to enable communication between the VNets to enable the Management Server to connect with all the Gateways. For more information, see the Microsoft Azure documentation.
TLS/SSL Termination: TLS/SSL termination can have a major impact on the performance. Terminating the encryption before the WAF will significantly improve the performance. For that purpose, Azure Application Gateway could be used (or any other load balancing solution).
Automated Deployment: The deployment process can be automated. Azure Resource Manager or any other orchestration tool can be used. SecureSphere provides vast REST API support for automation purposes.
Deployment Kit ARM Template: Imperva provides a Deployment Kit ARM template for quick deployment. The kit will create a virtual network, SecureSphere management console and scalable WAF, including a Load Balancer. This template could be useful as a reference for automating the deployment process. To deploy the Deployment Kit: