Cloudflare Firewall Rules

2 March 2020 - 3 minutes read - 432 words

I found a website k6.io which allows you to load test websites and API’s using AWS. With a free account you can test from one location with 50 virtual units for up to 12 mins. Spinning up a load test of get requests, Cloudflare served up all the traffic no problem, leaving my minimal VPS web-server alone. Then I tried again with post requests and BAM… 100% CPU load, response time over 6 seconds.

What was happening? Shouldn’t Cloudflare stop things like this?

The Problem

Well, sort of. Get requests are used, unsurprisingly, to get data. Post on the other hand send some data before a result is returned, such as when logging in or posting a comment. Since Cloudflare can’t cache dynamic assets, the post request is passed onto the origin server. 50 continuous requests was too much for my poor little server.

While post requests are perfectly valid for things like logins and posting comments, a large volume of them are unlikely to be legitimate traffic. Loading pages are always severed via get requests, so limiting other types of requests seemed likely to work.

The Soloution

Cloudflare has a firewall feature allowing traffic to be blocked based on user defined rules, with options like allow, block, forcing a captcha or a JavaScript based browser check.

I have blocked all traffic to /xmlrpc.php, which is used to remotely upload to Wordpress and is a common attack vector. Any non get request will also be subjected to a JS browser check, which requires the browser to calculate some mathematical challenges. This effectively rate limits how quickly they can come through and in the case of an automated test like those k6 provide, 503 errors are returned.

Did it Work?

Yes

Running another set of non get requests, you can see the Cloudflare nicely handled all 3.38 million of them, blocking them using the JS check, while get requests were still served very quickly (10ms average).

For good measure I also simultaneously hit the website with get requests for every page on the site map. As you can see, the origin server is barely touched.

During the whole time the test was running (about 1 hour total) my server CPU, RAM and network usage barely changed at all. As an added benefit I can now see just how often automated login attempts are run against my website (presumably by hackers).

All this is being done on the Cloudflare free plan, which is pretty amazing when you consider the state of web development as little as 10 years ago. Once again Good Guy Cludflare!