Apache on a shared hosting server.
WordPress 4.6.1-ja / Theme: Twenty Twelve
PHP: PHP-5.2.14 (it’s too old!!) / MySQL-5.5.21
Here’s the list of activated plugins.
- IP Location Block:
Version: 0.3.0.0 and later.
The Validation timing
shoule be set as "init" action hook
. If you set it as "mu-plugins" (ip-location-block-mu.php)
, P3 would fail to measure the performance of this plugin because Must-use plugins
would be into the race condition.
P3 (Plugin Performance Profiler) can investigate WordPress plugins’ performance by measuring their impact on your site’s load time.
This awesome tool has two mode to measure the performance. One is “Auto scan” which will access to both admin area and public facing pages under the confition of logged in as an admin. On the other hand, “Manual scan” mode can make it possible to freely access. So in this report, “Manual scan” had performed only by accessing front-end pages.
The following results were measured with a private window.
- Use case 1: - “Auto scan” (admin area + public facing pages)
- Use case 2: - “Manual scan” (only public facing pages)
Compatibility with cache plugins
Definitely we need not only hardening security but also speeding up the site. So you may want to use IP Location Block with a caching plugin.
This is a big challenge to make this plugin compatible with cache plugins, because they would respond the requested content without executing any PHP codes at the very beginning of WordPress core process or even before the core starts.
Requirements for compatibility
To achieve the demand for both security and speed, the cache plugins need to support the following requirements.
Do not cache page
One of the most important thing for this plugin is to prevent caching an error page where an access denied message is rendered. For this purpose, this plugin defines
DONOTCACHEPAGE constant and set the flag for
On a cache plugin side, one of the followings needs to be supported.
- Support “Do not cache 404 page”
For example, WP Super Cache supports both of them by default, while many other plugins have 2. in their setting options.
IP Location Block provides the option “Validation timing” which kick off this plugin at an earlier phase than other typical plugins.
In correspondence with it, a cache plugin need to support the option for “deferred execution” or “late initialization” to give this plugin a chance to render an error page before the cached page is responded against the requests from blacklisted countries (or IPs).
Here’s a list of supported requirements mentioned above.
This list shows that:
The followings are the options setting in each plugin.
Some users reported that WP Rocket's feature "Critical CSS" triggers error while using IP Location Block. This is because WP Rocket is trying to reach the site but their server IPs are not on the whitelist.
To solve this issue please read the following article by WP Rocket:
Troubleshooting Critical CSS generation issues
WP Super Cache
W3 Total Cache
Swift Performance Lite
A must-use plugin is a plugin that will always be activated by default and be loaded prior to other typical plugins when you install it into your
You must select
"mu-plugins" (ip-location-block-mu.php) as Validation Timing in “Validation rule settings” section to install this plugin as “must-use plugin”.
ip-location-block-mu.php has following restrictions mainly because of its execution timing which is before
after_setup_theme action hook:
Please refer to “Validation timing” for more details.
What will become of my site if I use other plugin?
Well, it would not be so serious. Let’s think about WP Fastest Cache for example.
If someone requests a page where a cache hit occurs, no PHP code would be executed but static contents in the cache would be responded. In this case, this plugin has no chance to block anything.
If someone requests a page where a cache miss occurs, then WordPress would start to handle the request. In this case, this plugin would have a chance to validate the request.
So a visitor from forbidden countries sometimes gets cached contents and sometimes gets blocked. This means attack from forbedden countires would fail. As a consequence, blocking by country can still reduce the risk of infection.
How about Object Cache plugins?
WP_Object_Cache is a core class that implements an object cache. It stores all of the cache data to memory and makes them reusable within a request, but it does not make them reusable between different user agents even for the same content.
Unlike the full page cache plugins mentioned above, object cache plugins like LiteSpeed Cache on OpenLiteSpeed Web Server and Redis Object Cache using Redis make the “object” persistent. So the mechanism of persistent object cache is suitable for dynamic contents, and should be compatible with IP Location Block.
Customizing the response code and message
When this plugin blocks a request, it behaves differently depending on the setting of the “Response code”. This document explains about the details and also how to customize the error page for human.
UA string and Qualification
For SEO, you must be sure to grant permission against search engine bots or crawlers such as google, yahoo and being while shut out the bad bots. This feature is possible to fulfill your wishes by giving a pair of “UA string” and “Qualification” separated by an applicable rule which can be “
:” (pass) or “
Syntax and Synopsis
UA string : [ ! ] Qualification
UA string # [ ! ] Qualification
You can specify a part of user agent string (case sensitive). An asterisk “
*” matches all user agents.
Currently, you can obtain 7 types of qualification listed bellow:
||True if the request is the feed url.
||True if the result of host name is available.
||True if the host name includes string.
||True if the HTTP referer includes string.
||True if the request comes from the specified country.
|IP address (CIDR)
||True if the IP address is within the specific range.
||True if the AS number is matched.
The host name
HOST corresponding IP address will be retrieved via DNS reverse lookup which is disabled by default.
A negative operation “
!” can be placed just before a qualification. It inverts the meaning of qualification.
DNS reverse lookup
DNS reverse lookup will attempt to fetch a dns PTR record for an IP address. Its cost against the server’s resources is relatively high. For example, the following picture shows the result of 1st and 2nd time which is available at “Installation information” in “Plugin settings” section. It means that the fetched result would be cached in your server.
If “DNS reverse lookup” is disabled, then
HOST=... will always return true. For example,
Google:HOST would be converted to
Google:*. In this case, only user agent string would be checked. If the converted result is one of
*#!*, it would be eliminated.
||Pass if an IP address is within the range.
||Pass if UA includes “Google” and host name is available.
||Block if UA includes “Google” and host name is unavailable.
||Block if UA includes “Yandex”.
||Block all UA if host name includes “amazonaws”.
Note: The rules in "UA string and Qualification" will be processed in order. For example, when
bot:HOST appears before
xyz-bot#HOST, then all the bots will be passed whose user agent string includes "bot" and its host name is available.
Normally, a plugin will be loaded at a certain phase during WordPress boot process and will typically do its jobs after
init action hook. It means that a plugin will be kept waiting until almost all plugins have finished to be loaded.
But it’s wasteful to give spams and attackers those resources of your server.
The “Validation timing” at “Validation rule settings” can help to drastically reduce load on server especially against brute-force attacks.
The best practice for target settings
At the “Validation target settings”, you can enable the option, “Block by country” for each target as a basic configuration. Additionally, “Prevent Zero-day Exploit” can be enabled as an extended option. This document helps you to configure those options to fit for your site.