• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue Fail2Ban Jails don't work until manually turned "on"

gbotica

Regular Pleskian
Hi,

I have a (relatively) new Plesk Onyx (Version 17.5.3 Update #7) install (all going very nicely so far...), however I have discovered a strange issue with some Fail2Ban jails, in particular the plesk -wordpress jail.

I noticed that some jails weren't working after a server restart. All jails show as "on" in the Plesk F2B UI, but the plesk-wordpress jail wasn't working. I have not edited the plesk-wordpress jail or filter at all.

I also have another custom jail & filter I use for WordPress XMLRPC which is also affected -- after restart or F2B deactivate / reactivate, the jail stops working.

I then noticed that if I go to the Plesk "Jails" page, select the plesk-wordpress jail and then click "Swtich On" (even though it's already "on"), the jail then starts working as expected.

I can replicate this
  1. turning off F2B in Plesk UI, then turn it back on.
  2. Test: plesk-wordpress doesn't work.
  3. Select plesk-wordpress in Plesk UI
  4. click "Turn on" (even though it's already "on", with green "tick").
  5. Test: plesk-wordpress jail works again.
Interestingly, the proftpd jail doesn't seem to be affected.

Anyone else have this issue?

Thanks for your time.
 
Last edited:
How about your log file?

Does it show you the jail is enabled when you turn off then on?

Also PLEASE NOTE when you turn off and then on it takes some time to F2B to load all the log and error files. You can monitor this using 'top' command. You will see high CPU usage by F2B for some time. Give it a try when it goes down to normal.
 
Last edited:
Hi,

Thanks for the helpful suggestions. I have done further testing and there does appear to be an issue or bug with how Plesk activates Fail2Ban.

Firstly, I checked fail2ban.log thoroughly. The only errors were to do with sending email.

Email Notifications on Onyx with MSMTP and SELinux


Going a little off topic, but hopefully it might help someone...

I am using MSMTP relay with mailgun external SMTP to send email.

Fail2Ban sets the recipient as "root" by default. I just needed to create a sendmail-common.local file and set the dest email to an actual email address. I have another server with Plesk using local postfix for sending mail, and using the default 'root' recipient works fine, so presumably that is translated to the actual root user's email address at some point.

After this, email notifications still weren't working, and I noticed that SELinux was blocking access to MSMTP for Fail2Ban.

I discovered this post: SELinux preventing Fail2Ban from emailing notification via msmtp

The solution for me was very simple, from the very last line of the above post:

Code:
setsebool -P nis_enabled 1

With this change, email notifications from Fail2Ban started working correctly.

Jails not working issue remains...

However, my original issue remained:

From a server restart, or deactivate / activate of Fail2Ban in Plesk UI causes some jails to not work, until manually turned "on" from the Plesk UI Jails page.

Next I tested restarting fail2ban at the command line and tested if all jails worked as expected after reload:

Code:
fail2ban-client reload

Result: OK - fail2ban reloads and all jails work as expected.

Observing the fail2ban.log as it reloads testing both Plesk UI and command line alerted me to the issue: jails with multiple log files assigned were not loading properly when starting fail2ban via Plesk UI.

For testing, I'm using a simple jail I have to block access to WordPress' xmlrpc:

Code:
[wp-xmlrpc]
enabled = true
filter = wp-xmlrpc
action = iptables-multiport[name=wp-xmlrpc, port="http,https"]
    sendmail[name="wp-xmlrpc"]
logpath = /var/log/httpd/*access_log
    /var/www/vhosts/system/*/logs/*access*log
bantime = 3600
maxretry = 1

Reload fail2ban via commandline (edited to remove actual website paths):

Code:
2017-06-02 13:21:11,512 fail2ban.jail           [8637]: INFO    Creating new jail 'wp-xmlrpc'
2017-06-02 13:21:11,512 fail2ban.jail           [8637]: INFO    Jail 'wp-xmlrpc' uses pyinotify {}
2017-06-02 13:21:11,519 fail2ban.jail           [8637]: INFO    Initiated 'pyinotify' backend
2017-06-02 13:21:11,520 fail2ban.filter         [8637]: INFO    Added logfile = /var/log/httpd/ssl_access_log
2017-06-02 13:21:11,521 fail2ban.filter         [8637]: INFO    Added logfile = /var/log/httpd/access_log
2017-06-02 13:21:11,521 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_log
2017-06-02 13:21:11,522 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_log
2017-06-02 13:21:11,523 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_ssl_log
2017-06-02 13:21:11,524 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_ssl_log
2017-06-02 13:21:11,525 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_log
2017-06-02 13:21:11,526 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_log
2017-06-02 13:21:11,527 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_ssl_log
2017-06-02 13:21:11,527 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_ssl_log
2017-06-02 13:21:11,528 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_log
2017-06-02 13:21:11,529 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_log
2017-06-02 13:21:11,530 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_ssl_log
2017-06-02 13:21:11,531 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_ssl_log
2017-06-02 13:21:11,532 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_log
2017-06-02 13:21:11,533 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_log
2017-06-02 13:21:11,534 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_ssl_log
2017-06-02 13:21:11,535 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_ssl_log
2017-06-02 13:21:11,536 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_log
2017-06-02 13:21:11,537 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_log
2017-06-02 13:21:11,538 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_ssl_log
2017-06-02 13:21:11,539 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_ssl_log
2017-06-02 13:21:11,540 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_log
2017-06-02 13:21:11,542 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/access_log
2017-06-02 13:21:11,543 fail2ban.filter         [8637]: INFO    Added logfile = /var/www/vhosts/system/.../logs/proxy_access_ssl_log
2017-06-02 13:21:11,658 fail2ban.filter         [8637]: INFO    Set maxRetry = 1
2017-06-02 13:21:11,660 fail2ban.filter         [8637]: INFO    Set findtime = 600
2017-06-02 13:21:11,660 fail2ban.actions        [8637]: INFO    Set banTime = 3600

Reload fail2ban via Plesk UI:

Code:
2017-06-02 13:19:04,705 fail2ban.jail           [8637]: INFO    Creating new jail 'wp-xmlrpc'
2017-06-02 13:19:04,705 fail2ban.jail           [8637]: INFO    Jail 'wp-xmlrpc' uses pyinotify {}
2017-06-02 13:19:04,710 fail2ban.jail           [8637]: INFO    Initiated 'pyinotify' backend
2017-06-02 13:19:04,711 fail2ban.filter         [8637]: INFO    Added logfile = /var/log/httpd/ssl_access_log
2017-06-02 13:19:04,712 fail2ban.filter         [8637]: INFO    Added logfile = /var/log/httpd/access_log
2017-06-02 13:19:04,712 fail2ban.filter         [8637]: INFO    Set maxRetry = 1
2017-06-02 13:19:04,714 fail2ban.filter         [8637]: INFO    Set findtime = 600
2017-06-02 13:19:04,715 fail2ban.actions        [8637]: INFO    Set banTime = 3600

So, it appears that if a jail has multiple log files set for logpath, then when Plesk loads fail2ban, not all logs are included in the jail configuration.

I tried reversing the order of the log paths, but this made no difference.

As before, turning the jail on via the Plesk UI Jails page, or reloading fail2ban on the command line resolves the issue, temporarily.

I'm not really sure whether this is an issue with fail2ban itself, or Plesk (I did find this on fail2ban Github issues page: Multiple Logpaths prevent starting when action_mwl is used · Issue #976 · fail2ban/fail2ban · GitHub).

Is anyone else able to replicate this issue? Could this be a bug in Plesk?

Thanks for your time.
 
Last edited:
Back
Top