As far as I can tell, I have set up the plugin’s default filters/jails already. I’ve also setup a custom filter and jail that has already banned some IPs already, but Site Health tells me that it isn’t running, per the following:
[WP fail2ban] fail2ban is not running
fail2ban is not running - your server is unprotected.
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2023-08-09 14:46:37 CST; 1 weeks 5 days ago
Docs: man:fail2ban(1)
Main PID: 349237 (code=exited, status=0/SUCCESS)
Did I screw up some setting? Is this something I need to worry about?
Well, let’s start with the facts: based on the status info fail2ban
isn’t running.
Why it’s not running is another question. I assume you checked your config with fail2ban-client --test
?
Thanks for the reply. The configuration is OK, it seems:
~$ fail2ban-client --test
OK: configuration test is successful
~$ sudo fail2ban-client status
[sudo] password for root:
Status
|- Number of jail: 4
`- Jail list: sshd, wordpress-hard, wordpress-soft, wp-xmlrpc
~$
I think I have the plugin setup properly now; it successfully blocked a login attempt on admin
.
It took a while for me to track down exactly how to configure wp-config.php
, which I don’t think the documentation explains clearly enough. And this is before I found your default configs file in /wp-content/plugins/wp-fail2ban/conf.d
which would have saved me some time (There’s a default config file?). I can imagine people installing the plugin without making the necessary configurations so it just sits there without actually doing any good.
And after all that, the Site Health still tells me that fail2ban isn’t running. I’m left wondering if this is actually a bug.
Hope all this info helps you make clearer documentation.
Cheers
Out-of-the-box, WPf2b blocks all the “bad” things that are common to all sites. Yes, there are lots of other things it can do and block, but they all need careful consideration before enabling them - what works for one site can break others.
For example, blocking user enumeration. It used to be the case that the majority of sites would benefit from it, but with recent Gutenberg-based themes there seems to be a drift back to author profile pages; the better option is to force logins with email addresses only, but enabling that has the potential to lock people out of their site. Neither option is right for every site, so neither is enabled by default.
What’s in wp-config.php
doesn’t affect how fail2ban
runs, only what gets logged for fail2ban
to process; if fail2ban
isn’t running it’s not because of what’s in wp-config.php
.
A running fail2ban
service looks like this:
root@example:/var/log# systemctl status fail2ban
● fail2ban.service - Fail2Ban Service
Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2023-08-22 05:49:49 UTC; 1 day 9h ago
Docs: man:fail2ban(1)
Main PID: 568088 (fail2ban-server)
Tasks: 9 (limit: 1115)
Memory: 17.4M
CPU: 1min 55.759s
CGroup: /system.slice/fail2ban.service
└─568088 /usr/bin/python3 /usr/bin/fail2ban-server -xf start
root@example:/var/log#
That says it was running, but has exited for some reason. fail2ban
is usually quite good at telling you why it’s unhappy - /var/log/fail2ban.log
should provide some info.