Subscribe to receive notifications of new posts:

Protect Your Sites With Rapidly Deployed WAF Rules


4 min read

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 /index.php?2346354=-349087 WordPress/3.7.2
12/30 01:42:31 23.75.345.200 /index.php?7231344=4454226 WordPress/3.3.1
12/30 01:42:25 23.75.345.200 /index.php?1243847=9161112 WordPress/3.7.2
12/30 01:42:23 23.75.345.200 /index.php?8809549=4423410 WordPress/3.3.1
12/30 01:42:21 23.75.345.200 /index.php?1834306=3447145 WordPress/3.5.1
12/30 01:42:16 23.75.345.200 /index.php?-234069=6121852 WordPress/3.3.3
12/30 01:42:16 23.75.345.200 /index.php?-152536=6922268 WordPress/3.3.1
12/30 01:42:14 23.75.345.200 /index.php?3433701=7147876 WordPress/3.4.2
12/30 01:42:14 23.75.345.200 /index.php?6732828=-106444 WordPress/3.2.2

The attacker was using a botnet to hit the script /index.php on 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_URI matches /index.php\?-?\d+=-?\d+

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:

The rule for this one was simple:

rule 12345679 Anonymous attack
  REQUEST_URI begins /?msg=Nous%20sommes%20Anonymous

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

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.


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.

We protect entire corporate networks, help customers build Internet-scale applications efficiently, accelerate any website or Internet application, ward off DDoS attacks, keep hackers at bay, and can help you on your journey to Zero Trust.

Visit from any device to get started with our free app that makes your Internet faster and safer.

To learn more about our mission to help build a better Internet, start here. If you're looking for a new career direction, check out our open positions.
WAF RulesTech TalksWAFDeep Dive

Follow on X


Related posts

September 20, 2019 3:53 PM

When TCP sockets refuse to die

We noticed something weird - the TCP sockets which we thought should have been closed - were lingering around. We realized we don't really understand when TCP sockets are supposed to time out! We naively thought enabling TCP keepalives would be enough... but it isn't!...