CentOS - Oct 2012 - CentOS 6.3 - fail2ban not working properly + workaround

I recall others on this list are using fail2ban to block brute force
login attempts.
Packages are from the EPEL repo, so I'm just sharing some knowledge here.

For about two months now I've had a CentOS 6.3 box (web host) in
production that occasionally is ftp brute forced.
Oddly enough fail2ban wasn't nabbing the perpetrators.  I found that
the iptables chain for VSFTP isn't created for one.

I have finally come to find [0] that indicates there's a problem with
the inotify backend.
Setting backend=gamin in /etc/fail2ban/jail.conf gives me the iptables
chain I expect to find and one blocked host.

Hope this is helpful to somebody until a new version is commited to EPEL.

<quote>
yarikoptic:
ok -- that point was not yet good ;) now (0.8.6-95-gc0c1232) that
branch seems to work just perfect. If I hear no complaints or do not
see problem with my instance -- I will merge it into master tomorrow,
thus closing this issue
</quote>

[0] https://github.com/fail2ban/fail2ban/issues/44

---~~.~~---
Mike
//  SilverTip257  //

On 10/17/2012 05:51 PM, SilverTip257 wrote:
> I recall others on this list are using fail2ban to block brute force
> login attempts.
> Packages are from the EPEL repo, so I'm just sharing some knowledge
here.
>
> For about two months now I've had a CentOS 6.3 box (web host) in
> production that occasionally is ftp brute forced.
> Oddly enough fail2ban wasn't nabbing the perpetrators.  I found that
> the iptables chain for VSFTP isn't created for one.
>
> I have finally come to find [0] that indicates there's a problem with
> the inotify backend.
> Setting backend=gamin in /etc/fail2ban/jail.conf gives me the iptables
> chain I expect to find and one blocked host.
>
> Hope this is helpful to somebody until a new version is commited to EPEL.
>
> <quote>
> yarikoptic:
> ok -- that point was not yet good ;) now (0.8.6-95-gc0c1232) that
> branch seems to work just perfect. If I hear no complaints or do not
> see problem with my instance -- I will merge it into master tomorrow,
> thus closing this issue
> </quote>
>
> [0] https://github.com/fail2ban/fail2ban/issues/44
>
Thanks for the tip (I know it's a very old message).
I have updated recently to 6 and see that fail2band ssh dos no longer
works. Indeed after log rotate fail2ban seems to follow the old log file
instead of the newly created /var/log/secure.
I had backend = auto in /etc/fail2ban/jail.conf and gamin and pyinotify
are both installed. I now changed backend to gamin and give it another
try. The next log rotate is next week....
Anyone else using fail2ban with CentOS6 installed from epel?

fail2ban-0.8.8-2.el6.noarch on CentOS6.4

Theo

2013/3/12 Theo Band <theo.band at greenpeak.com>:
> On 03/12/2013 05:35 PM, Timothy Murphy wrote:
>> I'm running fail2ban on my server (under CentOS-6.4)
>> and it seems to be running according to
>> -------------------------
>> [tim at grover fail2ban]$ sudo service fail2ban status
>> Fail2ban (pid 31794) is running...
>> Status
>> |- Number of jail:      1
>> `- Jail list:           ssh-iptables
>> -------------------------
>> I have absolutely no idea how fail2ban works,
>> and I'm running it with the default /etc/fail2ban/fail2ban.conf ,
>> which seems to set the logfile to /var/log/fail2ban.log .
>> Should I actually study how it is meant to be configured?
>>
>> I just yum-installed it (from Epel, I assume)
>> and hope it does its job, whatever that is.
> It sets up iptables rules for every jail that is configured (iptables
> -L). You seem to have only the ssh-iptables configured. Check the date
> of the logfile. I noticed that SYSLOG is now used for logging. It used
> to be /var/log/fail2ban.log in the past. I removed the old log file.
> If ssh is the only public service you want to protect against brute
> force, then you don't need to setup anything. But have a look in
> /etc/fail2ban/jail.conf and add at least your email address to get a
> notification when it blocks access. There lots of other "jails"
that can
> be enabled.
> Normally I receive several messages a day. So not receiving them means
> that the service is no longer protecting. Simply because it watches a
> renamed no longer updated version of /var/log/secure:
>
> ls -l /var/log/secure*
> -rw------- 1 root root 2130892 Mar 12 18:25 /var/log/secure
> -rw------- 1 root root 1374710 Feb 17 01:31 /var/log/secure-20130217
> -rw------- 1 root root 1482646 Feb 24 03:09 /var/log/secure-20130224
> -rw------- 1 root root 1732930 Mar  3 03:13 /var/log/secure-20130303
> -rw------- 1 root root  656454 Mar 10 03:12 /var/log/secure-20130310
>
> Once a week fail2ban stops working as a new secure log file is created
> (logrotate) and it seems to watch the only old name. You will not see
> any error message and status show as running.
> But I have no proof that it keeps working with the gamin fix.
>
> Theo
>
I too have the same problem but couldn't figure where is the issue. It
stops working even if the service says all is right. I have to restart
the service to let it work again...

I will try to find through your idea.

Thanks,
Fabien