Category Archives: WordPress

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
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.


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
 Allow from
 Allow from 2a02:fe80::/29
 Allow from

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.


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.


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.

Switching a WordPress site over to HTTPS/SSL, the official hosted version of WordPress have switched over to enforcing SSL, while this is mostly a political statement, there is some merit, firstly you might actually have some forms which should be secure, allowing users to communicate using the secure channel https provides, secondly there Google have started giving a slight boost to your PageRank when they see SSL in place.


But if you host your own server, you need to enable and provide a certificate yourself.

First check Apache is listening on 443

netstat -ntpl | grep 443

Create a Certificate Request

If all you need is secure forms and a green padlock as I have used here you can use a Rapid SSL Certificate @ $12.99 a year here.

You can also get a suitable free certificate from StartSSL, I have a walk through here for that. If you are able to use LetsEncrypt, they have a great free certificate thats generated from your server.

Here is a great walk through on enabling SSL and copying the certificate and key over to your server.

To redirect http URLs to https, do the following:

 Redirect /
 # ... SSL configuration goes here

Enable SSL for apache

a2enmod ssl

Enable the new SSL config


Test the new config

apachectl configtest


sudo /etc/init.d/apache2 restart

Quite often we see that while everything else is working, a firewall might be blocking port 443, check to see if IPTables is blocking

iptables -L -n

If not add the rule

iptables -I INPUT -p tcp --dport 443 -j ACCEPT
/etc/init.d/iptables-persistent save

check to see if UFW is blocking

ufw status

If you don’t see HTTPS or SSL listed

UFW allow https

If your padlock is broken, likely you have some non-ssl content that manually needs having it’s url altered. To check for non HTTPS content use this Why no Padlock tool.

This of course is another one of my reminder walkthroughs, that I will update as I find better instructions, and welcome any improvements.

Adding disclaimers on blog comments

I was asked a couple of days ago to add a disclaimer to the commenting section on a WordPress Blog, something like: “Commentators are asked to be polite, stay on topic. While we do monitor and moderate comments, they are the expression of the commentator and do not necessarily share the opinion of the Blog owner.”

Surprisingly at this time there is no comment disclaimer plugin for WordPress (Jump to the bottom of the page if you want to see how to do it). In fact there is really very little written on the subject.

Quite a few bloggers over the years have been sued or faced criminal charges for their own postings, basically using existing defamation and copyright law. And recently we are seeing the threat of terrorist charges for “disseminating” a video that I saw a huge number of blogs sharing at that time, I don’t know of any that were actually contacted by any authority.

BloggingBlue have a great Comment Policy & Disclaimer, but if you go to comment there, there your attention is not brought to this disclaimer when you actually comment, I guess it should say “by posting you agree…” I found another well worded document but again with no way for the commentator to confirm they have read or agree to the policy here at Monsanto, who I know face a lot of commenting abuse.

Looking for legal advice on this, all I found was an Australian lawyer who suggests that you should:

add a Creative Commons licence to your blog comments page stipulating that in posting comments they agree to license them to you.

Funnily enough, the much loved, decade old herche’s blog disclaimer does cover commenting quite well.

Comments on this website are the sole responsibility of their writers and the writer will take full responsibility, liability, and blame for any libel or litigation that results from something written in or as a direct result of something written in a comment. The accuracy, completeness, veracity, honesty, exactitude, factuality and politeness of comments are not guaranteed.

I think it is also important to warn aggressive trolls if you have a “Comment Kittening policy“.  Comment Kittening of course far more effective than the ban hammer or IP banning.

comment disclaimer

Adding the comment disclaimer, or whatever notice, will look like this is, and is done by adding the following to the custom.css or style.css.


#reply-title::after {
 content: "(your message to commentators)";
 font-size: 12px;
 text-transform: none;
 font-weight: 300;
 font-style: italic;

Of course if you do come across a better method, please let me know, just be polite, stay on topic…   😉