WordPress site security is a hot topic these days.
But what’s all the fuss about, why do you need to care, and what can you do about it?
Why is WordPress so vulnerable?
WordPress sites are particularly vulnerable to attacks and security breaches… not because it’s inherently insecure. Far from it!
When you’re running the latest version of WordPress, you have quite a secure platform on your hands.
The problem is ubiquity. WordPress is everywhere, and it makes the potential surface area of attack much larger… and therefore more appetizing to attackers.
As a hacker, if I want to do a mass, non-targeted attack against a lot of sites, I want to maximise my chances of success – so I try to find a weakness in a platform that is practically everywhere.
By using WordPress you don’t make your site less secure, you just make your sites more vulnerable to being the target of an attack.
How can you make WordPress more secure?
This particular article will cover methods for keeping your site secure… the scope of that topic exceeds what a single article can cover.
Fundamentally, security of your WordPress sites falls into 2 broad categories:
- Explicit / Enforced Security
- Passive / Obscurity Security
We recognise the need of many people, and ourselves, to add explicit security principles to our WordPress sites.
To this end, we created our own WordPress security plugin – The Shield Security plugin.
Shield Security Plugin – What does it do exactly?
The Shield Security plugin works primarily by analysing the request parameters that have been sent to your WordPress site, looking for certain patterns in the values.
For example, when you submit a form to a site, you normally submit things like your name, email address and things like that. We normally call this POSTing to a site, and the alternative method is GET, and this plugin handles both.
Some attack vectors attempt to submit values that contain dangerous content, that bypasses the “normal” processing of the forms to achieve the attack it wants to make.
Shield Security analyses all these values for some of these dangerous elements and when it finds one, it blocks the request.
It’s that simple.
There are around 6 different types of values that the plugin checks for, and you can turn on and off each one individually. You see there’s no way to be completely 100% compatible with every website configuration and many plugins themselves can use forms to submit values that might trigger the firewall.
The Shield plugin allows you to see clearly what has been blocked using its logging feature. In this way you can see what part of the firewall is being triggers, and you can turn on/off the plugin easily from the configuration page – you don’t need to disable the whole plugin.
Other features the plugin includes:
- Add a list of accepted, whitelisted IP addresses that are never subject to the firewall rules
- Add a list of restricted, blacklisted, IP address that are always blocked – a ban list.
- Restrict access to wp-login.php to whitelisted IP addresses.
- Full activity logging so you can review visitor access and debug the plugin.
- Turn on and off the Shield with a single plugin option (no need to disable the plugin).
- Option to force turn-off and turn-on the Shield using FTP – very useful feature in case you can’t access your WordPress site directly.
- Option to change how the firewall block responds – it can die (kill the request), send a 404 page, or redirect to home.
- Option to send an email to the blog admin when a block occurs.
This is just version 1.0 of the plugin… there’s more coming!
Why did we build the Shield plugin?
Simple… because ultimately we will integrate it into our iControlWP service to provide a centralized security management dashboard.
Configuration security principles on individuals sites is fine, if you only have a few sites to manage, but how about when you have 10s and 100s of them?
Would it be ideal pool the data from all your sites together into 1 place? Setup whitelists and blacklists in 1, centralized control system? That’s exactly where we’re headed…
Grab the Shield Security plugin and let us know what you think, and what you’d like to see. We can only make the best WordPress security system with your help.
How can i download that plugin?
Hi David,
Your best bet is to grab it directly from the WordPress.org plugins repository:
http://wordpress.org/plugins/wp-simple-firewall/
From within the plugins section of your WordPress site, just search for simple firewall and it’ll come up first in the list.
Thanks!
Paul.
1 Shouldn’t the firewall be turned on by default when first installed? I installed on a test site and left the config for later, only to find that it wasn’t yet even turned on.
2 No pressure, but any idea when we’ll be able to manage the configuration from within iControlWP?
Hi Russell,
Thanks for the suggestion. The reason we don’t turn it on by default is performance as we intend to eventually add more features (as we have done just this week with Login Protection).
What we could do is add a notice to say that the plugin is activated, but the Firewall is not turned on yet. I’ll look at doing this for a release very soon.
Thanks!
Paul.
We are evaluating Simple Firewall plugin on a test website before implementing on our normal site. Your 2-factor authentication states that once verified (through email login), the user won’t have to go through that step unless the IP address changes. That is not what we are observing. Logging in on subsequent days (or many days later) from same machine and same network IP address forces you back through the email link. The emails I received contain the same IP address (so it did not change). Not a huge deal for our customers but this not what your plugin advertises.
Care to comment?
thanks,
Roger
Hi Roger,
I haven’t heard reports of this until now, but I’ll check the code as the only thing I can think of here is that there’s a potential bug in the automatic cleanup code I put into the last release – it might be actually cleaning out valid authentications as well.
As you say, not the worst thing in the world and if anything makes it all the mores resilient as it forces re-authentication, but yes, a bit of a pain to say the least. I’ll look into the code and get back to you…
Thanks for raising this.
Paul.
When am I supposed to receive emails? I have “Login Protect Logging” turned on and I can see I’m blocking login attempts but I never receive an email… I left the email field blank on the dashboard so I’d have the emails sent to my admin email address… (which works for all my other plugins that send emails…)
Also, maybe I don’t understand “Limit login attempts to every X seconds”? I have it set to 60 (one login every 60 seconds) but I’m still getting login attempts every few seconds…
Hi AnnaBella,
Thanks for the comment and the questions.
The plugin is not configured to send out email when logging attempts are blocked. There has been no need to program such a feature. The logging system will show these, as you’ve seen. If such a feature was enabled and you get a huge hit on your wp-login, you’ll get a massive surge in emails. I’m inclined to not provide such a feature when the logging system displays these quite clearly already.
Also, the limit login attempts doesn’t stop people from actually going to your wp-login page and trying to login. What it does is prevent any WordPress processing of the login attempt. There’s no way to actually prevent access or submission to your wp-login.php, so we block all processing on the backend, during the cooldown period.
I hope that helps to explain this all a little better.
Thanks!
Paul.
on your last reply. There is option to change login address, so you can prevent try to login on default login site/wp-login simply
anyway, I have a question about compatibility with other plugins like wordfence. Thank you
Admin Access Restriction: how to recover password?
Please use the technique outlined here to disable the plugin and enter a new admin access key:
https://icontrolwp.freshdesk.com/support/solutions/articles/3000000959
Thanks
Last your update crashed whole my website and it was in such state over than an hour, until I checked it.
Fatal error: Call to undefined method RecursiveDirectoryIterator::setFlags() in …/wp-content/plugins/wp-simple-firewall/src/common/icwp-wpfilesystem.php on line 113
In last update You used PHP class method which is not supported on my PHP 5.2.17 version web hosting server, while I an unable currently to switch to newer version. Method: setflags (http://php.net/manual/en/filesystemiterator.setflags.php ) introduced since PHP 5.3.0 version. You should add PHP version check (http://php.net/manual/en/function.phpversion.php ) to your module to at least 5.3.0. So I think is time to say good bye.
Hi
Sorry for the trouble you had there. These things happen and it’s unfortunately easy for something like this to slip through the net.
We’ve released an update to address this problem for any other php 5.2 users.
And if it’s “time to say good-bye”, absolutely no problem at all. We had a good run… great memories. 😀
Paul.