define() Constants¶
WP_FAIL2BAN_AUTH_LOG¶
New in version 2.2.0.
By default, WPf2b uses LOG_AUTH for logging authentication success or failure. However, some systems use LOG_AUTHPRIV instead, but there’s no good run-time way to tell. If your system uses LOG_AUTHPRIV you should add the following to wp-config.php:
define('WP_FAIL2BAN_AUTH_LOG', LOG_AUTHPRIV);
WP_FAIL2BAN_BLOCK_USER_ENUMERATION¶
New in version 2.1.0.
Brute-forcing WP requires knowing a valid username. Unfortunately, WP makes this all but trivial.
Based on a suggestion from @geeklol and a plugin by @ROIBOT, WPf2b can now block user enumeration attempts. Just add the following to wp-config.php:
define('WP_FAIL2BAN_BLOCK_USER_ENUMERATION', true);
WP_FAIL2BAN_BLOCKED_USERS¶
New in version 2.0.0.
The bots that try to brute-force WordPress logins aren’t that clever (no doubt that will change), but they may only make one request per IP every few hours in an attempt to avoid things like fail2ban. With large botnets this can still create significant load.
Based on a suggestion from @jmadea, WPf2b now allows you to specify a regex that will shortcut the login process if the requested username matches.
For example, putting the following in wp-config.php:
define('WP_FAIL2BAN_BLOCKED_USERS', '^admin$');
will block any attempt to log in as admin before most of the core WordPress code is run. Unless you go crazy with it, a regex is usually cheaper than a call to the database so this should help keep things running during an attack.
WPf2b doesn’t do anything to the regex other than make it case-insensitive.
If you’re running PHP 7, you can now specify an array of users instead:
define('WP_FAIL2BAN_BLOCKED_USERS', ['admin', 'another', 'user']);
WP_FAIL2BAN_HTTP_HOST¶
New in version 3.0.0.
This is for some flavours of Linux where WP_FAIL2BAN_SYSLOG_SHORT_TAG isn’t enough.
If you configure your web server to set an environment variable named WP_FAIL2BAN_SYSLOG_SHORT_TAG on a per-virtual host basis, WPf2b will use that in the syslog tag. This allows you to configure a unique tag per site in a way that makes sense for your configuration, rather than some arbitrary truncation or hashing within the plugin.
Note
This feature has not been tested as extensively as others. While I’m confident it works, FreeBSD doesn’t have this problem so this feature will always be second-tier.
WP_FAIL2BAN_LOG_COMMENTS¶
New in version 3.5.0.
WPf2b can now log comments. To enable this feature, add the following to wp-config.php:
define('WP_FAIL2BAN_LOG_COMMENTS', true);
By default, WPf2b uses LOG_USER for logging comments. If you’d rather it used a different facility you can change it by adding something like the following to wp-config.php:
define('WP_FAIL2BAN_COMMENT_LOG', LOG_LOCAL3);
WP_FAIL2BAN_LOG_PASSWORD_REQUEST¶
New in version 3.5.0.
WP_FAIL2BAN_LOG_PINGBACKS¶
New in version 2.2.0.
Based on a suggestion from maghe, WPf2b can now log pingbacks. To enable this feature, add the following to wp-config.php:
define('WP_FAIL2BAN_LOG_PINGBACKS', true);
By default, WPf2b uses LOG_USER for logging pingbacks. If you’d rather it used a different facility you can change it by adding something like the following to wp-config.php:
define('WP_FAIL2BAN_PINGBACK_LOG', LOG_LOCAL3);
WP_FAIL2BAN_LOG_SPAM¶
New in version 3.5.0.
WPf2b can now log spam comments. To enable this feature, add the following to wp-config.php:
define('WP_FAIL2BAN_LOG_SPAM', true);
The comment ID and IP will be written to WP_FAIL2BAN_AUTH_LOG and matched by wordpress-hard.conf.
WP_FAIL2BAN_OPENLOG_OPTIONS¶
New in version 3.5.0.
WP_FAIL2BAN_PROXIES¶
New in version 2.0.0.
The idea here is to list the IP addresses of the trusted proxies that will appear as the remote IP for the request. When defined:
- If the remote address appears in the WP_FAIL2BAN_PROXIES list, WPf2b will log the IP address from the X-Forwarded-For header
- If the remote address does not appear in the WP_FAIL2BAN_PROXIES list, WPf2b will return a 403 error
- If there’s no X-Forwarded-For header, WPf2b will behave as if WP_FAIL2BAN_PROXIES isn’t defined
To set WP_FAIL2BAN_PROXIES, add something like the following to wp-config.php:
define('WP_FAIL2BAN_PROXIES','192.168.0.42,192.168.42.0/24');
WPf2b doesn’t do anything clever with the list - beware of typos!
WP_FAIL2BAN_SYSLOG_SHORT_TAG¶
New in version 3.0.0.
Some flavours of Linux come with a syslogd that can’t cope with the normal message format WPf2b uses; basically, they assume that the first part of the message (the tag) won’t exceed some (small) number of characters, and mangle the message if it does. This breaks the regex in the fail2ban filter and so nothing gets blocked.
Adding:
define('WP_FAIL2BAN_SYSLOG_SHORT_TAG', true);
to functions.php will make WPf2b use wp as the syslog tag, rather than the normal wordpress. This buys you 7 characters which may be enough to work around the problem, but if it’s not enough you should look at WP_FAIL2BAN_HTTP_HOST or WP_FAIL2BAN_TRUNCATE_HOST too.
WP_FAIL2BAN_TRUNCATE_HOST¶
New in version 3.5.0.
If you’ve set WP_FAIL2BAN_SYSLOG_SHORT_TAG and defining WP_FAIL2BAN_HTTP_HOST for each virtual host isn’t appropriate, you can set WP_FAIL2BAN_TRUNCATE_HOST to whatever value you need to make syslog happy:
define('WP_FAIL2BAN_TRUNCATE_HOST', 8);
This does exactly what the name suggests: truncates the host name to the length you specify. As a result there’s no guarantee that what’s left will be enough to identify the site.
WP_FAIL2BAN_XMLRPC_LOG¶
New in version 3.6.0.
This is for debugging and future development.
Attackers are doing weird things with XML-RPC, so this logs the raw post data to the file specified:
define('WP_FAIL2BAN_XMLRPC_LOG', '/var/log/xml-rpc.log');