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:
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.p...rtup.2Frestart
and implemented the last recommended fix:
In /usr/share/fail2ban/server/action.py` (Debian) just add a sleep(1):
startCmd = Action.replaceTag(self.__actionStart, self.__cInfo)
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:
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.