Fail2ban error

[BesnierS]

Hi,

Since the last update I perceived that Fail2ban no longer working.
All jails are listed as inactive.
When I try to reactivate I get this kind of error:

Unable to activate selected jail: f2bmng failed: ERROR No file(s) found for glob /var/www/*/logs/access_log
ERROR Failed during configuration: Have not found any log file for apache-badbots jail
ERROR:f2bmng:Command '['/usr/bin/fail2ban-client', 'reload', 'apache-badbots']' returned non-zero exit status 255
ERROR:f2bmng:Failed to reload following jails due to errors in configuration: apache-badbots


Do you have an idea of the solution to make that Fail2ban can work again without worries?

This is really problematic in terms of security.

Thank you.

 

[UFHH01]

Well.... problematic? ^^

Please review your fail2ban configuration regarding the jail "apache-badbots". You find these settings over the Plesk Panel in: Start > Tools & Settings > Block of IP addresses

The jail - tab shows all available jails currently configured and pre-defined. If you updated or freshly installed fail2ban, your old configurations might now being located at "/etc/fail2ban.previous" As you may have noticed, the Plesk pre-configuration named the standard "apache-badbots" to "plesk-apache-badbots", so please make sure, that you change any previous existing configurations to the existing jails within the Plesk - Fail2ban extension. You certainly may add additional jails to fit your needs, which is as well pretty easy over the Plesk Panel.

 

[SteveL132]

I have the same problem, also after the latest Plesk update. UFHH01, your answer doesn't seem to be relevant. I have not updated or freshly installed fail2ban, and there is no "previous" configuration. It looks to me as if Plesk incorrectly updated the file that tells fail2ban where logs are. For example, I see it looking for a "mail.log" for dovecot where the file is really maillog. The apache jails are looking for /var/www/*/logs/access_log where it should be looking in /var/www/vhosts/*/logs/access_log

I tried to fix this in jails.conf but it didn't seem to take. I'm reluctant to try to fix it on my own further.

 

[UFHH01]

Actually, since Plesk 11.5, the directory "/var/www/vhosts/system/*/logs/" is used for all domain specific logs and for the mail - logs, both destinations ( "mail.log" and "maillog" ) work, because they are both existent ( Ubuntu ) and contain the same entries. It has to be admitted, that the KB - article http://kb.odin.com/111283 ( Parallels Plesk Panel for Linux services logs and configuration files ) should be updated with the complete paths to the domain specific logs, but I am sure, that Plesk will do that pretty soon, so that Plesk users don't get confused.

To be sure, that the apache-badbot - filter as well monitors the access_ssl_log, you could as well modify the filter with this path:

For SuSe,Debian,Ubuntu:

logpath  = /var/www/vhosts/system/*/logs/error*log
           /var/log/apache2/*error*log
           /var/www/vhosts/system/*/logs/*access*log
           /var/log/apache2/*access*log

For Redhat,Centos,etc.:

logpath  = /var/www/vhosts/system/*/logs/error*log
           /var/log/httpd/*error*log
           /var/www/vhosts/system/*/logs/*access*log
           /var/log/httpd/*access*log

As you can see, I suggest "*" in the paths, to avoid different operating system - specific declarations, or upcoming changes to equal all systems.

 

[SteveL132]

Let's not lose sight of the fact that a Plesk minor update broke this. Any changes I make to the configuration files will get overwritten the next time Plesk updates. I don't think this is something individual site owners can or should try to fix.

 

[UFHH01]

Oh, you probably missed, that you can create your very own jails and filters, which are untouched on each update/upgrade/patch. I for myself find it much easier to do this directly in "/etc/fail2ban/jail.local" ( for the jails and I manually created filters in a separate folder "/etc/fail2ban/filter.d.local/", just to be sure, that Plesk don't mess up my configurations.
But it is as well possible to create and edit new jails and filters over the Plesk Panel, which are untouched by Plesk as well. With this scenario, Plesk creates new jails in the folder "/etc/fail2ban/jail.d" and new filters have to be named in a different way, than the existing ones, because they are stored in the main filter - folder "/etc/fail2ban/filter.d". Plesk updates/upgrades/patches only change standard configurations and never individual ones.

 

[SteveL132]

Ok, now I see what is going on. What the Plesk update did was add a bunch of new jails with different names, all starting with "plesk". When you go to view the jails., it shows them by default in alphabetical order, so you don't notice that the active jails are on the third page! Sorting by Status brings the active jails to the front.

So, the jails are working - it's just not obvious when looking at the display compared to how it looked before.

 

[SteveL132]

On the other hand, the Logs tab under Banned IP Addresses is now empty. There used to be bunches of logs here...

 

[Stephan1]

I have exactly the same problem. No log files in the tab! Even no logging in /var/logs/fail2ban.log
Did you succeed to solve the problem?

 

[SteveL132]

No, I never did solve it and I can't tell if fail2ban is working as I don't see any IPs listed as banned, where I used to see quite a few.

 

[SteveL132]

Interesting clue - when I restart fail2ban, I get an email about the recidive jail starting but none others.

 

[UFHH01]

If you experience issues/problems, which you don't actually see in the fail2ban.log - file at /var/log/fail2ban.log you might consider using another mode for the loglevel. The loglevel is defined at /etc/fail2ban/fail2ban.conf

 

[SteveL132]

The problem is that the log is completely empty. loglevel is set at 3 (INFO) which should show everything. I get some warnings if I restart the service from the console:

Starting fail2ban: WARNING 'ignoreregex' not defined in 'Definition'. Using default one: ''
WARNING 'logpath' not defined in 'ssh'. Using default one: '/var/log/messages'
WARNING 'filter' not defined in 'ssh'. Using default one: ''
WARNING 'action' not defined in 'ssh'. Using default one: ''
WARNING No filter set for jail ssh
WARNING No actions were defined for ssh
WARNING 'ignoreregex' not defined in 'Definition'. Using default one: ''

I tried to find where jail ssh was defined but couldn't spot it - it's not in jail.conf but it is "enabled" in jail.local. (There are many other jails with names starting with ssh defined, though.) Turning jail 'ssh' off, though, doesn't change the symptom. I can remove jail 'ssh' (which is ok for me as I have that set for IP restriction), and the warnings about jail ssh go away, but not the one about 'Definition' and the log is still empty. I even tried setting the log level to 4 (DEBUG) and nothing shows in the log.

 

[UFHH01]

To start... " Starting fail2ban: WARNING 'ignoreregex' not defined in 'Definition'. Using default one: '' " is really nothing you should worry about, because Fail2ban is clever enough to use the global "ignoreregex" ( which is none )... Please have a closer look on how jails and filters are defined, to understand the warning. For example, the filter "plesk-courierlogin.conf" has an absolut correct filter - definition:

# Fail2Ban filter for courier authentication failures
#
# based on filter courierlogin.conf from fail2ban-0.8.13

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = (?:courier\-?)?(?:imapd?|pop3d?|imaps?|pop3s?)(?:login)?(?:-ssl)?

failregex = ^%(__prefix_line)sLOGIN FAILED, (user|method)=.*, ip=\[<HOST>\]$

ignoreregex =

# Author: Christoph Haas
# Modified by: Cyril Jaquier

If a filter misses the line "ignoreregex =" , Fail2ban will post a warning, as you can see in your log.


Second... if you don't define the correct SSH - log - path in a SSH - jail, Fail2ban can't work correctly, because it doesn't know WHERE to look for SSH - intruders. A standard SSH - jail definition would be:

enabled  = false
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/auth.log
maxretry = 5

This jail depends on your very own system - configuration. So please investigate yourself, WHERE SSH - authenfications are logged ON YOUR system and define the correct log in the jail.
The standard SSH - jail is configured in the "jail.conf" or in a separate jail at "/etc/fail2ban/jail.d", or if you use your own configurations at "/etc/fail2ban/jail.local"
You mentioned

(There are many other jails with names starting with ssh defined, though.)

which is rather confusing.... there is ONLY ONE standard - SSH - jail... if you have several more SSH - jails, please don't wonder yourself about issues/problems, because misconfigurations can always lead to failures.

 

[SteveL132]

All of the jails are defined by Plesk - I didn't create any of them. I just selected fail2ban from the available modules Plesk offered and installed it. It was working fine until 12.0.18 - and clearly I am not the only one experiencing this.

Plesk's installation of fail2ban creates fifteen jails with "ssh" in their names. One is "ssh", others include "ssh-iptables", "ssh-ddos" and "ssh-route" (all but the first of these are disabled by default.) A closer look tells me that "ssh-iptables" is the one I want. Your suggested definition of "ssh" is pretty much what ssh-iptables does.

By the way, on my CentOS/Plesk system, /var/log/auth.log does not exist. A bit of research tells me that it is /var/log/secure

 

[UFHH01]

...
This jail depends on your very own system - configuration. So please investigate yourself, WHERE SSH - authenfications are logged ON YOUR system and define the correct log in the jail.
...

Please be sure that you don' mix JAILS, FILTERS and ACTIONS. They are not at all the same.

 

[SteveL132]

I understand it well. Please note that I said that Plesk defined everything - I didn't change it. It was all working great until 12.0.18. Don't be distracted by the definitions of the jails - the bigger problem is that none of the jails seem to be doing anything and the log file is empty. Before 12.0.18 it would record the starting and stopping of the service and the active jails. Now, nothing. The log file is there but has zero bytes.

 

[UFHH01]

A very special solution for SteveL132:

Please follow these steps:

Go to your command line and use the following commands:

service fail2ban stop
iptables --flush
/usr/local/psa/admin/bin/autoinstaller --select-product-id plesk --select-release-current --remove-component fail2ban
mv /etc/fail2ban /etc/fail2ban.old
yum clean all && yum update
/usr/local/psa/admin/bin/autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component fail2ban
service fail2ban start

If you would like to configure Fail2ban now over the Plesk Control Panel, please move there. If you rather prefer using the command line, please configure the fail2ban - configuration now to your very special needs / system configuration and keep in mind, to have a look at the documentation if you are unsure about some settings.

If you experience issues/problems/failures, please include the depending log - entries or/and command outputs which point to the issue/problem/failure , so that further investigations are easier and further suggestions will be more accurate.​

 

[SteveL132]

Not very nice - that "iptables --flush" locked me out of SSH as it deleted the rule that allowed my IP in. Luckily I figured out how to recover from Plesk Panel. Also, the yum commands are unnecessary (I had done a yum update this morning anyway.)

You seem to be under the misconception that I configured fail2ban from the command line - I did not. As I wrote earlier, I added it using Plesk Panel and configured it there. It worked fine until 12.0.18 at which time the logs were empty. I went through the reinstall steps you suggested and it had no effect (other than that I no longer see warnings when I start fail2ban.) The log file is still empty. I had to reenable the various plesk- jails.

I know you're trying to help, but please stop making unwarranted assumptions about our environment. I am NOT the only one reporting this problem.

 

[SteveL132]

Ok, I found a solution for the missing log.

fail2ban's default location for the log is SYSLOG, but I can't find documentation on what that means, exactly. This used to generate fail2ban.log in /var/log - it no longer does.

So I created /etc/fail2ban/fail2ban.local with the following content:

[description]
logtarget = /var/log/fail2ban.log

and I restarted the fail2ban service (this can be done in Plesk Panel > Tools and Management > Services Management > IP Address Banning , or from the command line with "service fail2ban restart".

Now I have the log created where Plesk expects it to be. Time will tell if it starts telling me about jail activity.