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.
At the time of your first installation and activation of this plugin, you can see the following configuration at “Validation target settings”. This is a set of minimum configuration which doesn’t protect your site against the attacks targeted at the vulnerble plugins and themes in your site.
Setting for “XML-RPC”
The WordPress core file
xmlrpc.php is an endpoint for not only Remote Procedure Call but also pingbacks. As for the RPC, it’s used by Jetpack and mobile apps to provide their services. But it’s also abused as login attempts by the attackers.
“Block by country” for this target can accept the useful requests while reducing the risk of exploiting your site from forbidden countries. And “Completely close” works more effectively than WordPress 4.4 and later or Disable XML-RPC especially against the brute force amplification attacks by
Setting for “Login form”
You can choose “Block by country (register, lost password)” which enables anyone to login from anywhere but disables registering a new user and reseting one’s password.
You should also know about the “limiting login attempts” functionality. If you enable this target (e.g. not “Disable”), the “limiting login attempts” will work for you. It also affects the target “XML-RPC” which can be used for login attempts.
For example, Sucuri News had already unvailed the brute-force attempts using xmlrpc which requires hundreds of authentication attempts only by one HTTP request. This plugin can also effectively protect your site against this kind of attacks.
Limit login attempts
You can change “Max number of failed login attempts per IP address” which is 5 by default at the bottom of “Validation rule settings”. If you select “0” as for it, then users can not fail to login.
Note that the lockout time is same as the expiration time of cache.
Setting for “Admin area”
Normally, php files under the
wp-admin/ should be accessed only by the administrator except Ajax call. So the best practice for this target is enabling both “Block by country” and “Prevent Zero-day Exploit” (e.g. WP-ZEP).
But WP-ZEP potentially blocks some of admin actions because it can’t track the multiple redirections. If you find such a case, you shall uncheck it.
Setting for “Admin ajax/post”
wp-admin/admin-(ajax|post).php can provide services for both visitors and admins, and those can be abused as an entrance to exploit aiming at the vulnerable plugins or themes. So the configuration for those is slightly delicate than others.
The corresponding set of validation can be shown as follows:
If you want to serve ajax to every one (even if requested from forbidden countries), you should uncheck the “Block by country”.
Note that WP-ZEP will carefully identify the request which provides services only for admin regardless of the country code. Although there’s a possibility to block something because of the same reason as the “Admin area”, enabling the “Prevent Zero-day Exploit” is always recommended.
Setting for “Plugins / Themes area”
Setting for this area is almost the same as “Admin ajax/post”. The only difference is that WP-ZEP can’t distinguish the services whether for visitors or for admin. It means that WP-ZEP will block all the request except from the admin dashboard.
So if you use a plugin which provides download services on the public facing pages for example, and the download link is directly pointed to the php file in that plugin’s directory, you should uncheck the “Prevent Zero-day Exploit”
Force to load WP core
It’s better to configure rewrite rules for both “Block by coutnry” and “Prevent Zero-day Exploit” to block certain types of attack. Currently this plugin supports to setup a specific
.htaccess into those areas for Apache. Please refer to this article for more details.
If you have something to ask, please feel free to open your issue at the support forum.