Hello, I realize that this problem may not be ISPConfig-specific, but I'd like to eliminate that possibility, if nothing else. I'm using ISPConfig 3.0.4. I've installed fail2ban 0.8.4, with minimal configuration changes, on Ubuntu 10.04-2 LTS. I installed fail2ban from the Ubuntu repository using apt-get. My goal is to cover Apache authentication first, and then extend the fail2ban configuration to other services, such as ftp, dovecot, etc. The default fail2ban configuration seems to be adequate, and the only change I made was to create the file /etc/fail2ban/jail.local and insert the following: Code: [apache] enabled = true logpath = /var/log/ispconfig/httpd/*/error.log Likewise, the default regular expressions appear to be functioning as expected: Code: # fail2ban-regex /var/log/ispconfig/httpd/example.com/error.log /etc/fail2ban/filter.d/apache-auth.conf Code: Running tests ============= Use regex file : /etc/fail2ban/filter.d/apache-auth.conf Use log file : /var/log/ispconfig/httpd/example.com/error.log Results ======= Failregex |- Regular expressions: | [1] [[]client <HOST>[]] user .* authentication failure | [2] [[]client <HOST>[]] user .* not found | [3] [[]client <HOST>[]] user .* password mismatch | `- Number of matches: [1] 48 match(es) [2] 119 match(es) [3] 0 match(es) Ignoreregex |- Regular expressions: | `- Number of matches: Summary ======= Addresses found: [1] xxx.xxx.xxx.xxx (Fri Sep 09 11:26:18 2011) ... [etc] ... Date template hits: 9836 hit(s): MONTH Day Hour:Minute:Second 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year 0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second 0 hit(s): Year/Month/Day Hour:Minute:Second 0 hit(s): Day/Month/Year Hour:Minute:Second 0 hit(s): Day/Month/Year Hour:Minute:Second 0 hit(s): Day/MONTH/Year:Hour:Minute:Second 0 hit(s): Month/Day/Year:Hour:Minute:Second 0 hit(s): Year-Month-Day Hour:Minute:Second 0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond] 0 hit(s): Day-Month-Year Hour:Minute:Second 0 hit(s): TAI64N 0 hit(s): Epoch 0 hit(s): ISO 8601 0 hit(s): Hour:Minute:Second 0 hit(s): <Month/Day/Year@Hour:Minute:Second> Success, the total number of match is 167 However, look at the above section 'Running tests' which could contain important information. In my attempts to trigger a ban, I've entered invalid Apache credentials as many as two dozen times over the course of several minutes, yet the iptables rules are never modified accordingly (even though fail2ban is parsing the log entries correctly, per the above output). Nothing significant is written to the fail2ban logs when I intentionally fail Apache authentication a dozen or so times. When I start the service, the following output is written to fail2ban's log: Code: 2011-11-23 13:49:35,406 fail2ban.server : INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.4 2011-11-23 13:49:35,407 fail2ban.jail : INFO Creating new jail 'ssh' 2011-11-23 13:49:35,407 fail2ban.jail : INFO Jail 'ssh' uses poller 2011-11-23 13:49:35,425 fail2ban.filter : INFO Added logfile = /var/log/auth.log 2011-11-23 13:49:35,425 fail2ban.filter : INFO Set maxRetry = 6 2011-11-23 13:49:35,427 fail2ban.filter : INFO Set findtime = 600 2011-11-23 13:49:35,428 fail2ban.actions: INFO Set banTime = 600 2011-11-23 13:49:35,519 fail2ban.jail : INFO Creating new jail 'apache' 2011-11-23 13:49:35,519 fail2ban.jail : INFO Jail 'apache' uses poller 2011-11-23 13:49:35,520 fail2ban.filter : INFO Added logfile = /var/log/ispconfig/httpd/sub1.example.com/error.log 2011-11-23 13:49:35,521 fail2ban.filter : INFO Added logfile = /var/log/ispconfig/httpd/sub2.example.com/error.log 2011-11-23 13:49:35,521 fail2ban.filter : INFO Set maxRetry = 6 2011-11-23 13:49:35,522 fail2ban.filter : INFO Set findtime = 600 2011-11-23 13:49:35,523 fail2ban.actions: INFO Set banTime = 600 2011-11-23 13:49:35,532 fail2ban.jail : INFO Jail 'ssh' started 2011-11-23 13:49:35,533 fail2ban.jail : INFO Jail 'apache' started Where should I be looking next? Am I overlooking something obvious? Thanks for any insights!
Thank you for the reply, pititis. I tried adding that line in jail.local, and restarting fail2ban, but I am still unable to trigger a ban by failing Apache authentication. And, technically speaking, the suggested line should already have been active due to its presence in jail.conf. As I understand it, all configuration directives from jail.conf apply until they are overridden (optionally) in jail.local. From the documentation: Code: # Optionally you may override any other parameter (e.g. banaction, # action, port, logpath, etc) in that section within jail.local Here is the relevant section of jail.conf, which I have not modified: Code: [apache] enabled = false port = http,https filter = apache-auth logpath = /var/log/apache*/*error.log maxretry = 6 And again, the contents of jail.local: Code: [apache] enabled = true logpath = /var/log/ispconfig/httpd/*/error.log So, the only configuration change I've made is to override the "enabled" and "logpath" values via jail.local. Any other thoughts? Thanks again!
I realized that fail2ban stopped working for SSH, too, at some point during this process. I thought that perhaps I'd butchered a configuration value somewhere while attempting to implement banning for Apache authentication. But after comparing all files in /etc/fail2ban with those on a similarly-configured server on which SSH banning works as intended, I ruled-out that possibility: all files were identical. So, I elected to remove fail2ban (with apt-get remove fail2ban) and reinstall it (with apt-get install fail2ban)... Apache banning now functions (at least somewhat... more on that in a moment). In jogging my memory, it occurred to me that, at some point, I modified a core fail2ban python file to solve a race-condition that appears to be Debian-specific. I was receiving these types of messages in the log when I first attempted to implement banning for services other than SSH: Code: 2011-11-23 10:48:56,713 fail2ban.actions.action: ERROR iptables -N fail2ban-postfix iptables -A fail2ban-postfix -j RETURN iptables -I INPUT -p tcp --dport smtp -j fail2ban-postfix returned 200 2011-11-23 11:15:29,932 fail2ban.actions.action: ERROR iptables -D INPUT -p tcp --dport smtp -j fail2ban-postfix iptables -F fail2ban-postfix iptables -X fail2ban-postfix returned 100 I found discussion of the issue at http://www.fail2ban.org/wiki/index....ban.actions.action_ERROR_on_startup.2Frestart and implemented the last recommended fix: Code: def execActionStart(self): startCmd = Action.replaceTag(self.__actionStart, self.__cInfo) sleep(1) return Action.executeCmd(startCmd) After reinstalling fail2ban, which presumably undid the change to the python file, Apache banning works, as mentioned above, but I still receive errors like this in the fail2ban log: Code: 2011-12-01 14:20:16,994 fail2ban.server : INFO Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.4 2011-12-01 14:20:16,995 fail2ban.jail : INFO Creating new jail 'ssh' 2011-12-01 14:20:16,995 fail2ban.jail : INFO Jail 'ssh' uses poller 2011-12-01 14:20:17,015 fail2ban.filter : INFO Added logfile = /var/log/auth.log 2011-12-01 14:20:17,016 fail2ban.filter : INFO Set maxRetry = 6 2011-12-01 14:20:17,018 fail2ban.filter : INFO Set findtime = 600 2011-12-01 14:20:17,019 fail2ban.actions: INFO Set banTime = 600 2011-12-01 14:20:17,104 fail2ban.jail : INFO Creating new jail 'apache' 2011-12-01 14:20:17,104 fail2ban.jail : INFO Jail 'apache' uses poller 2011-12-01 14:20:17,105 fail2ban.filter : INFO Added logfile = /var/log/ispconfig/httpd/site1.example.com/error.log 2011-12-01 14:20:17,107 fail2ban.filter : INFO Added logfile = /var/log/ispconfig/httpd/site2.example.com/error.log 2011-12-01 14:20:17,108 fail2ban.filter : INFO Set maxRetry = 6 2011-12-01 14:20:17,110 fail2ban.filter : INFO Set findtime = 600 2011-12-01 14:20:17,110 fail2ban.actions: INFO Set banTime = 600 2011-12-01 14:20:17,125 fail2ban.jail : INFO Jail 'ssh' started 2011-12-01 14:20:17,126 fail2ban.jail : INFO Jail 'apache' started 2011-12-01 14:20:17,218 fail2ban.actions.action: ERROR iptables -N fail2ban-ssh iptables -A fail2ban-ssh -j RETURN iptables -I INPUT -p tcp -m multiport --dports ssh -j fail2ban-ssh returned 400 Further, it seems that only one of any number of jails is able to write to the iptables configuration at a time. In other words, if Apache banning functions as expected, SSH banning does not -- and vice versa. At this point, it's worth mentioning that I believe that the following bug describes this very issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554162 So, I'll wait until fail2ban_0.8.5-2_all.deb is the latest stable release and see if the issue is resolved. And I'll report back at that time.
Well, I just couldn't wait, so I installed the latest .deb package. The problem appears to be resolved.
