One of the most common ways for WordPress security plugins to block malicious requests is to do so based on the visitor IP address.
As we’ve discussed before, we don’t advocate this approach to website security – it simply doesn’t scale and doesn’t actually make sense as a security principle.
That said though, we’ve received feedback on our approach that made a lot of sense and it got us to thinking. With this in-mind, we’ve released an important upgrade to our Shield Security plugin. This feature blocks the IP addresses of malicious visitors in a scalable, and fully automated way.
Say hello to F.A.B.L.E. – Fully Automatic Black List Engine
Our Shield Security plugin does a lot of things well, but until now it has never considered 1 area – the observation of visitor request patterns.
Imagine a visitor to your site tries to log in repeatedly to your website. Our plugin will block repeated login attempts using the login cooldown features, as an example.
This works because the system doesn’t care who the visitor is, it just blocks repeated login attempts and thwarts brute force logins regardless of IP.
But, there is no relationship between a block of this nature, and at the same time noticing the same visitor also tried to post a SPAM comment. What if the same user tries to access your WP admin area even though you’ve renamed the WP login page?
The point I’m trying to make is that the Shield Security plugin doesn’t currently link “naughty” actions together. It just handles them on a per-request basis.
And this is a good thing! Why?
– There is no logic to be tricked; no back-door to take advantage and all requests will always be checked for validity.
This is a hard line to take, and it’s worked great so far.
We see a potential optimization to our approach, however. Without moving away from the principle of per-request analysis, we can also capture multiple “potentially malicious” requests and recognize that a particular individual visitor is not in-fact a legitimate one.
We could say that if a given visitor attempts a number of actions on our site, or the same action several times then we don’t want them having any further access to our site to try it again.
So they’ll be immediately blocked – and we use their IP address to temporarily identify them.
Our Fully Automatic Black List Engine does exactly this. It tracks bad behaviour over a set period of time and as soon as it reaches our threshold, we block it.
No more lengthy and unmaintainable IP black lists!
How we address performance implications of IP black lists
I’ve mentioned before that we don’t, in principle, like the use of IP black lists as a basis for website security. This goes against current convention in the WordPress security world, but then we’ve never been conventional …
I can spout marketing nonsense to you about how black listing IPs now “increases” your site security, but honestly, it doesn’t. Rather, it works as more of an optimization than anything else.
It’s a great optimization because it will reduce your site work load – black listed IPs are detected early in the WordPress page load and further page processing is immediately terminated.
An IP address lookup table introduces a performance penalty with 1 extra SQL lookup than you had before. The larger your table of IP addresses, the longer the look up takes.
Don’t worry though, we’ve optimized this in several keys areas:
- automatic black listed addresses are single IPs and not ranges. This means our SQL query is highly targeted to the IP address in question.
- we use the WordPress cron to automatically clean out the stale black list entries. This reduces the pool of data within which the SQL executes making the queries, again, highly optimized.
- we use an auto-expiration timeout for IP entries – see the next section.
Auto-expiration of black listed IP addresses
A glaring reason that is often overlooked (re: ignored) for not using IP addresses as a foundation of WordPress security is that IP addresses change; they can change a lot – even more so with the increased uptake of IPv6.
Furthermore, if your site is being hammered by a distributed network of bots, blocking IPs is futile. That’s where our per-request approach to security and login cool-down features serve as great examples on how to tackle brute force attacks.
The changeability of IP addresses means that while you have blocked an IP address today, the same computer/bot/host may have a different address tomorrow (or in 5 minutes). If your black list system “retains” a record of all IP addresses, the time and resources used to look up against this database on every page request will soon balloon far out of control.
The solution? Make sure those IP addresses expire!
Automatic expiration timeout is baked right into our auto black list system. We default the expiration time to 1 minute. That’s plenty of time for a given visitor to stay blocked. If they come back and try their antics again, they’ll get blocked. Again.
Once an IP address entry has expired and that host hasn’t attempted to access the site again within the timeout period, the daily WordPress Cron will clean it out from the table, keeping the entire pool of lookup addresses nice and small.
You are free to change this timeout period. You can set it to:
- 1 minute
- 1 hour
- 1 day
- 1 week
I highly recommend keeping it to 1 day or less. The longer you retain these blacklisted IPs, the larger your IP address look-up table can potentially grow.
Don’t worry… if a particular IP is a repeat offender, then they’ll be repeatedly blocked! 🙂
What about manual IP address blocking?
If someone can present a good case for storing IP addresses to block in a manual fashion, we will provide this feature. As it stands, we have never seen a good reason for this.
The automatic system should easily suffice to keep your site from processing unwanted and malicious requests without you having to lift a finger or review logs.
Please leave us comments below if you feel very strongly about this, and if so, the reasoning and logic behind it. If we agree, we’ll definitely consider it… we’re always open to feedback and ideas to improve the system.
What about manual IP address white listing?
The plugin currently supports this, but it doesn’t use the same storage database as the automatic black listing data.
We intend to consolidate this data and provide a better interface for handling IP address white listing. This will come in time.
How can I get this awesome, amazing, fantastic feature on my WordPress site?
Easy. Install the Shield Security plugin and activate it.
This feature comes turned-on by default with the plugin so you don’t have any configuration steps. You can of course tweak the settings – look for the “IP Manager” sub-menu item within the Shield plugin menu on the left.
Thoughts, questions, feedback or attacks?
Your feedback has helped us with developing what we feel is one of our best optimizations to our Shield Security plugin. As we’ve said, this doesn’t improve your site security as much as it optimizes it…
Please leave us comments below if you have any comments or suggestions.
Everything works perfectly.
Best Protection plugin out there
Great plugin with great options! Thank you!
Simply the best
Easy to use, well thought out, a couple unique features, even 2-factor authentication through email, richly documented, dedicated support, … This may well be the best security plugin around. One drawback is that it’s not entirely compatible with multisite yet. This makes me a little uncomfortable, so I’ll move on…
Im Amazed :)
WordPress and security can be a hassle to protect your website from other it´s nearly impossible but you can do serval things to make it harder to crack. this plugins gives you alot of useful ways to protect it,constant updates and a´lot of effort hope to see it in the…
- Say hello to F.A.B.L.E. – Fully Automatic Black List Engine
- How we address performance implications of IP black lists
- Auto-expiration of black listed IP addresses
- What about manual IP address blocking?
- What about manual IP address white listing?
- How can I get this awesome, amazing, fantastic feature on my WordPress site?
- Thoughts, questions, feedback or attacks?