If you feel there’s something missing from this documentation, please do not hesitate to reach out to us on email@example.com
Fail2WP plugin settings
You will find the Fail2WP plugin settings under
Settings > Fail2WP in the WordPress administrator interface. It is visible only to users with the administrator role.
|The site name to use for logging, defaults to your site name if left empty. This does typically not need to be changed.
|Block user enum
|This will make Fail2WP block attempts to access
your.site/...?author=nnn. These requests can be used by external parties to find out more information about users and their usernames on your site.
|Block username login
|This will make Fail2WP disable the possibilities to login with usernames and instead require that the login credentials be an e-mail address.
|Secure login messages
|This will make Fail2WP alter the error messages displayed after unsuccessful login attempts. Typically, WordPress is quite “helpful” in telling users trying to login exactly what is wrong with the provided credentials. We don’t need to tell potential attackers what they’re doing wrong.
|Remove generator info
|If enabled, Fail2WP, will remove “WordPress” from the output of HTML pages, RSS feeds, etc.
|Disables the default RSS and Atom feeds on your site.
|Fail2WP will by default retain its settings when you uninstall the plugin. If you want Fail2WP to remove all its settings when you uninstall the plugin, you should enable this option. Settings are always retained when you deactivate the plugin.
|If enabled, Fail2WP will warn you about odd or possibly dangerous membership/user registration settings.
|Check for role
|Fail2WP will check the “New User Default Role” setting against this setting and warn you if there is a mismatch.
|This setting will make Fail2WP force the WordPress setting “New User Default Role” to whatever is configured here (below).
|Role to force
|If the “Force role” option is enabled, Fail2WP will use the “Role to force” setting to set the “New User Default Role” WordPress setting.
|Minimum username length
|This is the minimum number of characters (2-200) for usernames when new users sign up for membership on the site. Setting this value to zero disables the checking by Fail2WP. This does not affect already registered users.
|Usernames listed in this box, one per line, will not be allowed to sign up for site membership. The text is matched without regard for case, that is
admin and so on. The strings need to fully match to be banned, that is “admin” does not match “administrator”.
|E-mail must match
|Text specified here will be matched against whatever e-mail address new users enter when signing up for the site. At least one one of the entries must match the e-mail address entered by the user for the registration to be successful. Partial matching is done, that is
@mydomain.com will match
This is logged to the system’s authentication log (such as
/var/log/auth.log), which allows Fail2ban to dynamically block offending IP addresses. Configuration of the Fail2ban system daemon, or similar, must be done outside of WordPress for this to have any effect.
|This configures logging for successful logins for the various WordPress user roles. This is not meant for banning but for auditing. The sample Fail2ban configuration supplied with the Fail2WP plugin ignores these.
|This configures logging for unsuccessful logins for the various WordPress user roles. The sample Fail2ban configuration supplied with the Fail2WP plugin triggers Fail2ban actions for these. This should typically include any user role that can create content or change settings on the site.
|This setting will make Fail2WP create log entries similar to those for unsuccessful logins when unkown users are encountered.
|Log user enum
|This setting will make Fail2WP create log entries for user enumeration attempts (i.e.
your.site/...?author=nnn), which are often used to try to obtain information about users and usernames on the site. The sample Fail2ban configuration supplied with the Fail2WP plugin triggers Fail2ban actions for these.
These settings configure how Fail2WP should handle certain security aspects related to the WordPress REST API. Please make sure you understand how these settings can impact the operation of WordPress and other plugins before making changes to them.
|This setting will make Fail2WP refuse unauthenticated REST API calls. This is typically safe to do as there are few situations where this is valid.
|Log blocked requests
|Instructs Fail2WP to create a log entry for fail2ban to possibly act on when a REST API call is blocked according to other settings on this tab.
|Block index requests
|This setting will make Fail2WP refuse REST API calls to the REST API index. There’s rarely a need to allow this, so it’s typically safe to enable this.
|Block all requests
|This setting will make Fail2WP refuse all REST API calls to your site. This is typically not safe to do.
|Block specific namespaces
|This setting will make Fail2WP refuse REST API calls to specific namespaces on your site. You can use this to disable part of the available REST API.
|Block specific routes
|This setting will make Fail2WP refuse REST API calls to specific routes on your site. You can use this to disable part of the available REST API.
|Bypass blocks for IPv4
|This setting allows you to whitelist specific IPv4 addresses from the restrictions otherwise configured on this tab.
|Bypass blocks for IPv6
|This setting allows you to whitelist specific IPv6 addresses from the restrictions otherwise configured on this tab.
Please make sure you understand how these settings can impact the operation of the plugin before making changes to them.
|This setting changes the logging prefix from fail2wp to whatever you configure here. You may need to update your Fail2ban configuration to match this if you change it.
|Also log to PHP log
|This will make Fail2WP log the same information to the PHP log file, using the error_log() call, as it does to the system’s authentication log. Enabling this setting will not affect the operation of WordPress nor this plugin.
Configure Fail2WP to detect and manage requests from Cloudflare proxied sites and visitors. If you are not using Cloudflare, you can simply ignore these settings.
|Check for Cloudflare IP
|If enabled, this setting will make Fail2WP compare the visitor’s IP address with the addresses listed in the following configuration options. If a match is detected Fail2WP will use the IP address supplied from Cloudflare to identify the visitor’s actual IP address. This prevents Cloudflare servers from possibly being blocked by Fail2ban.
|IPv4 addresses Fail2WP should consider belonging to Cloudflare. An updated list of these addresses is available from Cloudflare
|IPv6 addresses Fail2WP should consider belonging to Cloudflare. An updated list of these addresses is available from Cloudflare
Allows you to import and export settings to easily deploy Fail2WP on multiple sites with identical or similar settings.
Some information about Fail2WP and WebbPlatsen i Sverige AB.
Fail2WP has functionality to allow the security daemon Fail2ban to block IP addresses from accessing websites on the server. It does this by writing entries to a system log, which is then scanned by Fail2ban. There is a sample Fail2ban configuration file distributed with Fail2WP. You can use it, more or less, out of the box, or customize it to suit your needs. The sample file is called
fail2wp.conf and should be placed in
Fail2WP does not interact with Fail2ban in any other way, it simply provides the data for Fail2ban to make decisions about possibly blocking remote IP addresses due to some sort of “error condition” caused by that remote IP address.The sample Fail2ban configuration file that is distributed with the Fail2WP plugin creates only one definition (“fail2wp”) for Fail2ban to act upon. You may want to split this up in several sections and thus allowing Fail2ban to ban different types of errors in different ways.