This blog post originally appeared as a guest post on the Rackspace blog
An attack on your site could be catastrophic. Even a small attack can have major implications. Responding quickly to an attack is imperative.
In August 2013, we at CloudFlare rolled out a new global Web Application Firewall (WAF) that runs common sets of firewall rules such as the open source OWASP rules that protect against SQL injection, cross-site scripting and more. But the WAF also has a custom rule language that CloudFlare’s support engineers use to write one-of-a-kind rules to protect specific customers or specific software.
Since the deployment of the new WAF we’ve rolled out many global and customer-specific rules to protect websites from attacks. This blog post looks at a few of them and the process of getting a custom rule deployed.
Custom Rules For Customers
Commonly, a customer will complain of an attack that’s hitting their web site and will provide us with their web server logs showing the attack (or by giving us permission to examine the traffic going to their web site). The logs will often show a common pattern. For example, here’s an anonymized attack against a customer web site showing up in their logs:
12/30 01:42:32 23.75.345.200 example.com /index.php?2346354=-349087 WordPress/3.7.2 12/30 01:42:31 23.75.345.200 example.com /index.php?7231344=4454226 WordPress/3.3.1 12/30 01:42:25 23.75.345.200 example.com /index.php?1243847=9161112 WordPress/3.7.2 12/30 01:42:23 23.75.345.200 example.com /index.php?8809549=4423410 WordPress/3.3.1 12/30 01:42:21 23.75.345.200 example.com /index.php?1834306=3447145 WordPress/3.5.1 12/30 01:42:16 23.75.345.200 example.com /index.php?-234069=6121852 WordPress/3.3.3 12/30 01:42:16 23.75.345.200 example.com /index.php?-152536=6922268 WordPress/3.3.1 12/30 01:42:14 23.75.345.200 example.com /index.php?3433701=7147876 WordPress/3.4.2 12/30 01:42:14 23.75.345.200 example.com /index.php?6732828=-106444 WordPress/3.2.2
The attacker was using a botnet to hit the script /index.php on example.com. To make each request different they are appending a query string in the form number=number where each number is randomly chosen. The User-Agent in the requests is spoofed to look like WordPress.
Although this attack doesn’t cause CloudFlare a problem it can cause the customer’s web server to become overloaded. The customer contacted us and we put in place a custom rule for them that blocks the attack. The rule looks like this:
rule 12345678 WordPress Numbers Botnet REQUEST_HEADERS:User-Agent matches ^WordPress\/ and REQUEST_METHOD is GET and REQUEST_URI matches /index.php\?-?\d+=-?\d+ deny
The support engineer wrote the rule (and an associated set of tests to make sure that it works correctly) and then pushed the rule to our git repository. From there it gets deployed to CloudFlare’s servers around the world in under 30 seconds.
The customer sees the rule appear in the Manage WAF page in CloudFlare Settings. They can turn the rule on and off and see how many times it has activated (i.e. blocked a request).
Another customer saw an attack that claimed to come from “Anonymous.” The attack hit the same page on their web server over and over again with a message from Anonymous (in French). A typical request looked like this:
example.com/?msg=Nous%20sommes%20Anonymous%20Nous%20sommes%20L%C3%A9g ion%20Nous%20ne%20pardonnons%20pas%20Nous%20n%E2%80%99oublions%20pas
The rule for this one was simple:
rule 12345679 Anonymous attack REQUEST_METHOD is GET and REQUEST_URI begins /?msg=Nous%20sommes%20Anonymous deny
Another simple attack that was very troublesome for the customer came in the form of a POST request to a URL that didn’t exist on the customer’s site. Once again, the request rate wasn’t troublesome for CloudFlare, but was for the customer, so we put in place a rule that would block all POSTs to that URL. This took the load off the customer web site: CloudFlare took the load for them.
The attack used a botnet to send the request POST /q to the customer’s web site. The rule to block that was very simple.
rule 1234567A Simple POST botnet REQUEST_METHOD is POST and REQUEST_URI is /q deny
As simple as that looks, it took the load off the customer’s web server and in the first 12 hours after deployment was activated over 27 million times!
Custom Global Rules
Other attacks are likely to be much more widespread and not focused on a single customer. These attacks are often directed at specific technologies such as WordPress, Joomla or other software.
Back in October a zero-day exploit for WHMCS (the popular web hosting management software) was released. CloudFlare patched that by deploying a complex WAF rule on the day the zero-day became public. The WHMCS maintainers also patched the problem.
Shortly after that, two new WHMCS vulnerabilities were found and we patched them as well by deploying or modifying WHMCS WAF rules.
We’ve also added custom rules to protect Plone-based web sites, a PHP 5.x remote code execution exploit, and a number of other rules to protect against common botnets and other attack software.
All those are on top of the generic protection offered by the 2,372 other rules that CloudFlare’s WAF runs to check every request.
Conclusion
The flexibility of the CloudFlare WAF language and the ability to deploy WAF rules in seconds means we can respond to attacks very rapidly. Visit our learning center to learn more about Web Application Firewalls.