CloudFlare announced the introduction of firewall rules on October 3, 2018. Surprisingly, five firewall rules are even provided on the free plan. By comparison the Pro plan provides 20 firewall rules. Unlike Page Rules, additional firewall rules can *not* be purchased. I get five, that’s it – but as we will see a single firewall rule can do a bunch of different stuff provided that the final action is the same. Pretty generous of CF, I think, seeing as I use only their free tier.
Comprehensive Web Application Firewall (WAF) rule sets had long been available, but only on paid plans. Free plan users were previously limited to using the IP firewall.
CF provides two ways to enter a firewall rule, an easy Visual Editor and a more advanced Expression Editor. I’ll stick with the easy one. The Visual Editor includes blocks for:
- Actions, which indicate how to respond to a matched rule; and
- Fields and expressions, which define the criteria for flagging incoming requests.
So, what good are firewall rules? They are really flexible, and can be used for many things. CF provides several examples. Firewall rules can do some of the same things as page rules, although can also both do things the other can’t. I could potentially use firewall rules to free up one or more of my three precious Page Rules. Firewall rules, unlike Page Rules, even allow for a recaptcha. Example:
The result, when anyone accesses my Contact Kenny page on that site, looks … well, kinda shitty and really scary, with a big scary orange warning thingy next to the recaptcha …
A powerful feature of CF firewall rules is that little “Or” button. I can use it to make a single firewall rule do a bunch of different stuff, provided that the final action is the same. For example, if I want to block user access to … cPanel, xmlrpc.php, wp-login.php, user enumeration, install.php, wp-config.php, .htaccess, readme.html, and license.txt … no worries. I can use a single firewall rule with a bunch of “or”s:
(http.request.uri.path contains “/cpanel”)
(http.request.uri.path contains “/xmlrpc.php”)
(http.request.uri.path contains “/wp-login.php”)
(http.request.uri.path contains “/?author”)
(http.request.uri.path contains “/install.php”)
(http.request.uri.path contains “/wp-config.php”)
(http.request.uri.path contains “/.htaccess”)
(http.request.uri.path contains “/readme.html”)
(http.request.full_uri contains “/license.txt”)
There may be a limit to the number of “or”s, but if so it is more than 8. Except for cPanel access, I could also block these things in .htaccess. The beauty of the firewall rule is that these potentially malicious requests are blocked at the CF reverse proxy so they never get to my site or server.
Update 2019-01-30: I stumbled onto another great thing about CF firewall rules. Unlike page rules or htaccess, firewall events are logged. And … it’s pretty revealing. Lotsa bad guys/gals (I’m guessing mostly guys) out there doing bad web stuff. Just one of my sites is averaging about 100 events a day that I consider serious – in that the consequences would be significant if the hack succeeded. These are mostly admin logon attempts, but a bunch of other nefarious stuff mixed in. Those 100 events are in addition to roughly 250 to 300 a day that are less serious but still malicious and annoying – mostly attempted image hot links. Be careful out there.
WPPOV supports freedom from Net Neutrality and the GDPR. The Internet of the people, by the people, for the people, shall not perish from the Earth.