Whenever new WAF clients are brought aboard, there’s a procedure they must follow in order to properly configure their servers to work behind the WAF protection.
You can find an example of the Imperva Cloud WAF onboarding procedure here.
Sometimes, however, customers can miss important procedures leaving them exposed, and sending them – and the WAF’s support team – on wild goose chases after false malicious activities.
By solving the misconfiguration problems described below, clients will maximize the gain from the WAF’s protection and prevent false alerts.
The misconfigurations can be split into two types:
- Configurations on the Customer side (the protected web server)
- Configurations of the WAF itself
Client’s server IP exposure and direct access bypassing the WAF
To protect a client’s assets, traffic coming to the clients’ servers must first go through the WAF for an inspection procedure. This is fundamental since a WAF must see malicious HTTP requests in order to sanitize them.
To do that, a change must be made to a client’s site settings. Routing, the traffic through the cloud WAF requires the client to change its server’s DNS settings to have a CNAME (alias) pointing to the WAF service that is bound to its origin IP, while the origin IP itself (the A and AAAA fields) should be removed from the DNS record.
The first issue is caused by leaving traces of the site’s original IP address in the DNS settings or SSL certificates, for example. In such cases, attackers can find this address and access the website directly, bypassing the WAF and sending a malicious payload without any restrictions.
It’s common practice to have more than one service running on the same IP address, such as an FTP or mailing service. In such a situation, the DNS record contains not only A or AAAA records but also additional records, such as MX, that alias to subdomains. Those subdomains often point to the same IP address as a web server, however. So, by simply “digging” in DNS records and trying to access the IP directly the attacker will find unprotected web servers.
The best practice is to separate WAF-protected resources from unprotected resources, and have different IP addresses to prevent exposure of the protected services’ origin IP.
But, even if the IP is used only by the webserver it still can be found in DNS history. There are many web resources that track changes in DNS records and log the results. A simple search on such a service will lead to all IP addresses ever bound to a specific domain.
To avoid this nasty scenario our suggestion is to change the IP address after WAF deployment. This will prevent DNS trackers following the changes, as the IP address will already be hidden by the WAF network.
Another common method used by attackers to find an origin IP address is by searching in services such as Shodan or Censys. These services are constantly scanning the web, and grabbing every response from the IP/Port tuple. Once it accesses port 443, a server responds with an SSL certificate which contains the domain it’s assigned to. This data is stored and indexed, and a simple string search will lead to the IP that contains this domain in the certificate.
The issue of direct IP access can be mitigated by restricting the access to a server’s firewall configuration. Any IP address except Imperva’s [link] should be blocked. This will isolate the webserver not only from potential attackers, but also from undesirable web scanners.
WAF configuration is not set properly
The recommended way to onboard a WAF is to set its configuration to alert-only mode. Thereafter, traffic should be forwarded through the WAF and analyzed for any false positive alerts that should be excluded from the WAF configuration. Then, once there are no false alerts, WAF configuration should be changed to blocking mode.
In practice, though, after the initial onboarding process, customers often forget to change the WAF to blocking mode, which means their websites aren’t protected against malicious activities.
We strongly recommend setting a reminder and finishing the most important part of the onboarding process by validating that all WAF settings are set correctly, that there are no false alerts, and that no malicious traffic is passing. In addition, we highly recommend conducting a penetration test to validate the WAF configuration. In case some custom scenarios aren’t blocked out-of-the-box, it’s possible to set manual rules – in alert mode first, and in blocking mode after the validation has been done.
DDoS threshold not set correctly
First, let’s go through a brief description of how DDoS mitigation works. The WAF has a setting called DDoS threshold, which represents the number of requests per second (RPS) that, when reached, will cause the DDoS policy to work. The DDoS policy consists of a set of rules to identify a DDoS attacker and perform an action, such as challenge with a captcha or block the request.
Learn more about DDoS protection.
When a client adds WAF protection, they need to set different settings related to the DDoS protection including the threshold, to ensure DDoS mitigation kicks in time. The DDoS threshold must be set near the site’s maximum request rate capacity.
For example, let’s look at the traffic of the site in the image above. If the normal traffic ranges between 3-23 RPS, and let’s assume the origin server and backend network can handle up to 150 RPS, the DDoS threshold should be set to 100. If the threshold set too low – below the normal traffic or too close to the upper spikes – DDoS mitigation will create false alarms as it will try to detect and mitigate attackers during peacetime. On the other hand, if the DDoS threshold is set too high (200RPS in our example), the mitigation will start too late, and the server will have to handle extra requests above its capacity, which means it can go down for some time.
To set a correct threshold, the client should analyze how much traffic the server gets during peacetime using the appropriate dashboard, as well as checking the maximum capacity of the origin server. To handle external factors such as successful marketing campaigns, the final threshold should be at least 50 percent above the maximum amount of legitimate requests over the past 30 days, and below the weakest part of the origin server and backend network.
In this blog post, we’ve discussed WAF misconfigurations that can either leave a client unprotected or without trustworthy alerts. Preventing these issues is in the client’s – and the WAF support’s – best interest.
Following the onboarding checklist will cover all these – and other – cases and ensure the WAF is set to the maximum protection level.
Try Imperva for Free
Protect your business for 30 days on Imperva.
