How to protect WordPress with Fail2Ban

Together, WP Cerber and Fail2Ban can stop brute-force attacks before they reach your WordPress at all. WP Cerber detects failed logins at the application level; Fail2Ban acts on them at the OS level, blocking offenders with iptables. That combination stops brute-force and DoS attacks with minimal overhead.

What is Fail2Ban

Fail2Ban is a log-monitoring service that runs on your server. It watches log files for patterns that signal an attack, such as repeated authentication failures from the same address, and once a host crosses a threshold you set, it bans that address at the system firewall for a chosen period. On its own it knows nothing about WordPress; it acts purely on what it finds in the logs. That’s where WP Cerber comes in: it monitors and records failed logins in a format Fail2Ban can parse, giving the service the events it needs to act on.

Note: you’ll need root access to your Linux server to set up Fail2Ban.

With WP Cerber you have three options to use Fail2Ban

Using HTTP 403 response headers if you want to monitor Apache access log
Using syslog files to monitor failed login attempts
Using a custom log file to monitor failed login attempts

Monitor Apache access log for HTTP 403 responses

When a login attempt fails, WP Cerber returns a 403 status in the HTTP header. Apache records that response in its access log, where Fail2Ban can read it. This behavior is enabled by default. The tradeoff is that Fail2Ban has to parse the entire access.log to find those attempts, which is inefficient on a busy site.

Using syslog to monitor failed login attempts

By default, WP Cerber logs failed attempts to syslog under the LOG_AUTH facility. To use a facility of your own, define the CERBER_LOG_FACILITY constant with an integer value. Either way, writing to syslog or to a custom file (see below) only happens once you enable Write failed logins to a log file in the main plugin settings.

define('CERBER_LOG_FACILITY', LOG_AUTHPRIV);

Using a custom file to monitor failed login attempts

To send every failed attempt to a log file of your choosing, set its absolute path with the CERBER_FAIL_LOG constant. Don’t forget to give your web server write permission on the folder or file, and to enable Write failed logins to a log file. WP Cerber creates the log file if it doesn’t exist. Once CERBER_FAIL_LOG is defined, WP Cerber stops writing to the default syslog. It’s worth noting that a custom CERBER_FAIL_LOG file keeps the data under your control, unlike syslog, where storage follow server or hosting environment policies.

define('CERBER_FAIL_LOG','/var/log/wp-cerber-auth.log');

Make sure your web server’s PHP process has write access to the specified file.

Aligning timestamps with the server clock

A timezone mismatch is the usual reason Fail2Ban records attempts but never bans anyone, so it’s worth understanding even when everything else is configured correctly.

Fail2Ban only acts on an event that falls inside its findtime window, and it decides that by comparing each log line’s timestamp against your server’s local time. WordPress keeps its own clock in UTC, regardless of the timezone you set on the site. So on a server running, say, Europe/Madrid, every line WordPress writes looks an hour or two old. Fail2Ban discards those events as stale and never fires a ban, even though the attempts are recorded in the log.

WP Cerber sidesteps this by writing its timestamps in your server’s system timezone rather than the WordPress clock, so they match what Fail2Ban expects out of the box. On most servers this is automatic and needs nothing from you.

When WP Cerber can’t resolve the system timezone on its own, set it yourself with the CERBER_LOG_TIMEZONE constant, using any valid timezone identifier:

define('CERBER_LOG_TIMEZONE', 'Europe/Madrid');

This value overrides automatic detection, so it’s the reliable way to pin the timezone down if you ever see timestamps drifting. Any identifier from the standard timezone database works, for example ‘America/New_York’ or ‘Asia/Tokyo’. This constant is available starting with WP Cerber version 9.7.4.

What gets logged

This log records personal data, so if your site falls under a privacy regime such as the GDPR, it concerns you directly. Here is what goes into it.

Each failed login writes one line: the source IP address, the username that was submitted, the server hostname, the process ID, and a timestamp. Passwords are never logged, in any form, and no other account data is recorded.

Two of these fields are personal data under the GDPR: the IP address (the Breyer ruling settled that an IP counts) and the username. Since WordPress allows email logins, the username may also be a user email address. This applies even to failed attempts, which still record that a specific person was targeted.

That makes you the controller for this data, with a few practical consequences. Include these logs in your retention policy and rotate or purge them instead of letting them grow without limit. Keep track of where the records are stored and forwarded: a custom CERBER_FAIL_LOG file keeps the data under your control, while syslog may send the records to centralized or external servers where storage and processing follow system wide policies you may not set. Data subject requests for access or erasure also apply to these logs

WP Cerber deliberately does not support purging these logs itself because it cannot control what syslog does with the records or how the server OS process log files. A cleanup feature built into WP Cerber would cover only part of the picture and could falsely suggest that the data was removed when it was not.

This is a practical summary, not legal advice. If you handle data from EU, UK, or similar jurisdictions, treat the IP address and username as personal data and check your obligations with whoever handles compliance for your business.