PCI Compliance, Penetration Testing, and the Sucuri WAF

Our support team is often asked, “Can we test our site through the Sucuri Web Application Firewall?”

The answer is always yes, with a caveat. Tests that are intended to cause a disruption of the service, such as DoS attacks, are not allowed. We are there to help you if you do come under a DoS attack, but not if you cause it intentionally.

Should you whitelist the PCI compliance or penetration test IPs?

The approval to run a PCI compliance or penetration test throws up a question: Do you want to whitelist the testers’ IP addresses or not? Both have their advantages, and we do have clients who go to that trouble of running two tests.

Whitelisting an IP address will allow all behavior from that location where it would otherwise be blocked with a 403 response. Too many 403 responses in a short period of time will cause the IP address to be banned by our systems.

Not whitelisting the PCI compliance or penetration test IPs

Firstly, not whitelisting the tester’s IP address requires the tester to rate limit their test to a reasonable speed that would not be seen as abusive of our service. You are testing the Sucuri WAF and it will work as intended, blocking all known vulnerabilities.

Whitelisting the PCI compliance or penetration test IPs

Then we have the option of whitelisting the tester’s IP address. You would not be testing the WAF, but the web application itself, so you can run the test at a much faster rate. There is a lot of value in that.

Maybe you have staff or other applications that access the web application that bypasses the WAF. It might be good to know what vulnerabilities exist in the site’s code. But this does not test the site as the public or an attacker would see it.

Bypassing the WAF

Some penetration testing solutions have an option to bypass the WAF entirely, setting the host IP address as the target which gives you a third option. This can be very useful when you might have a load balancer in play and want to test multiple hosting servers.

Personally as a best practice, I like the idea of testing from a whitelisted IP, listing any flagged vulnerabilities, and then testing those specifically using a proof of concept method through the WAF to confirm all is well. The bad behavior is blocked, but I still have the developers fix the site code. That would be a best practice, but maybe overkill for most site owners. Nevertheless, this is a popular testing methodology for some of our enterprise customers.

Why test the WAF?

But why test? I can understand wanting to run a penetration test  through the WAF to confirm we really are blocking all the bad behavior. Maybe you, the client, have whitelisted some path that makes you vulnerable or bypassed testing it in some way to confirm the site code is good.

It might be a bit extreme to run a PCI compliance test of the WAF, apart from intentionally setting the WAF to forward traffic to HTTP from HTTPS. It would not be possible for a site behind the WAF to fail a PCI compliance test, regardless of the condition of the site code.

Will Sucuri work with the testers?

Sucuri will work alongside you, with whatever reasonable test you chose to run. But sometimes we need to explain why the specialist a client hired got it wrong. I’ll share a few examples from some of the reports clients have shared with us in the last few months.

Examples of awkward WAF penetration test results

On this report, we can see that they did in fact scan the WAF by confirming the IP address. The WAF is clearly identified in the response headers as being based on NGINX, so a vulnerability in Apache would be irrelevant. The Sucuri WAF removes the headers that identify the site from running on anything other than NGINX. There is no valid test which could show the client was at risk of CVE-2019-0215, even if the client was running this older version of Apache.

Both parts of this example have no CVE. Tthe first they have identified an obscure vulnerability in the WAF that relates to a consumer home WIFI router.

The second relates to a Windows web server which was discontinued some 17 years ago. If you were really running that for an ecommerce solution, that would be the least of your problems. And to make matters worse, the WAF blocks the mentioned OPTIONS method by default, as was the case on this website.

And my last example, from our WAF logs…

Here the testers did not see a 403 block message, but 301 redirect messages. If they had followed the 301, as would any bad actor, they would have seen the 403 block. They would never have seen a 200 response (allowed).

I did speak to them, and they said their scanner was unable to follow redirects. I asked them to scan https:// rather than http://, avoiding the redirect requirement. The scan was completed successfully, but it really does call into question whether the tester understands what the testing was for.

Tests generally are great. If we had more responsible testing, there would be a lot less breaches. I should point out that my first two examples were from firms who have carried out thousands of tests on sites behind the Sucuri WAF. They do rarely get it wrong if you consider the scale.

PCI compliance and the Sucuri WAF

I doubt the Sucuri WAF is the only one that by default makes a website PCI compliant. In a perfect world, the PCI compliance testers would check if such a WAF was in place first. In fact, in many cases a PCI compliance test is not required of the website, with the client only needing to pass on our AOC document which we can supply on request. Feel free to chat with us if you have any questions about the Sucuri WAF.