WAFs -v- Endpoint Plugins

I’ve been reading some misleading articles on the subject of Endpoint vs Cloud Security, most notably this from Wordfence . Ironically I have used Wordfence a lot, their free plugin is often my first choice as a recommendation for someone with a $10 a month hosting account that doesn’t want to spend an equal amount on security, it does a great job at protecting most sites from the most common brute force attacks and blocking vulnerability scanners. Godaddy actually pre-install a similar but lightweight (no bloatware) plugin, Limit Login Attempts on all new installations of WordPress, great for purpose.

But this latest post of theirs, discussing bypassing, is disingenuous in the extreme, we all know that’s easily mitigated and is actually quite rare to even see it. “Security” plugin vendors only like to talk about Layer 7 ddos attacks, which is obvious as that is the niche they have carved out for themselves and they really don’t handle them at all well which is quite ironic. And they offer zero answers for layer 3/4 attacks and again rely on the host, Where as a WAF (Website Application Firewall) such as Sucuri’s sucks it all up (L7 & 3/4) for you, often with clients never knowing anything about it. While relying on a “security” plugin alone, your host could be taking you offline or charging you for extra bandwidth.

You have to remember that any “security” plugin is using your sites precious resources for any of their filtering and mitigation, sometimes slowing the site down during regular browsing, which should be a worry for anyone concerned with SEO as Google, prefers faster sites.

But just so I had some evidence to back this up, I ran some tests, setting up 2 Ubuntu 16.04 servers at DigitalOcean with private networking enabled, one with a default install of WordPress, the Genesis theme and no other plugins and the other an attack platform with wrk installed, easily setup and run:

apt-get update
apt-get install git
apt-get install make
apt-get install gcc
apt-get install luajit
git clone https://github.com/wg/wrk.git
cd wrk
make ./scripts/WITH_LUAJIT=/usr ./scripts/WITH_OPENSSL=/usr
./wrk -t32 -c100 -d30s http://10.128.26.XX

Emulating a classic DDoS attack, here is how the attacks played out, rebooting between each attack, firstly before the attack was launched, I am showing 654260 available memory.

victim-no-load

Firstly I tried an attack by blocking all but Sucuri’s IPs using UFW (my prefered method), the attack had zero effect on the victim, available memory stayed the same, wrk just gave up, Then I tried again under load with Sucuri Firewall’s bypass prevention code added to the .htaccess,

<FilesMatch ".*">
 Order deny,allow
 Deny from all
 Allow from 192.88.134.0/23
 Allow from 185.93.228.0/22
 Allow from 2a02:fe80::/29
 Allow from 66.248.200.0/22
</FilesMatch>

in it’s simplicity it’s most peoples prefered option to prevent bypass and works in nearly all situations, unlike UFW/IPTables which wont. It wasn’t pretty, but the site stayed up, with available memory dropping to 561380, whilst serving 129279 403 block messages in 30 seconds.

victim-load-with-bypass-prevention

Then I removed the bypass prevention codes and hit the site with WordFence only in it’s default installation, and crashed the site in the first few seconds, responding to only 29 requests, before server timeout errors were served. With available memory dropping to 114228. notice also how the database is being effected, unlike where the bypass prevention codes were used.

victim-load-with-wordfence

I did run an attack head on at the site while it was behind the Sucuri firewall, the website didn’t see a thing, after a few 403 errors were served by the firewall, the IDS kicked in, and the victim would never have noticed. I also ran an attack against the “naked” site, this went down in 4 seconds.

For fun I attacked the WordFence alone protected site, but increased the time to 120 seconds, mySQL needed restarting to recover site function.

This was not a real DDoS attack of course, I only launched a single application from a single server, but a very good replication of one, it was crippling against Wordfence, as if it wasn’t even installed, it even behaved slightly worse than the naked site, while their suggestion is to pass that mitigation onto the host works, they do charge for that as an additional service, and in many cases just shut your site down due to excess resource usage, that would be the case for any hosting less than $30 a month.

I’d suggest that Wordfence have no understanding of the concept of defence in depth, and rather than complementing a real firewall, they are trying to make out that their plugin is the answer to all your WordPress security concerns, which it just is not, Daniel Cid, CTO of Sucuri discusses this dangerous marketing method.

Disclaimer, I do work for Sucuri as the Sucuri Firewall support team lead.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.