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>
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
On Tue, Mar 12, 2013 at 11:51 AM, Theo Band theo.band@greenpeak.com wrote:
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>
Thanks for the tip (I know it's a very old message).
Happy you found it useful.
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've also recently noticed fail2ban choking on name resolution. By that I mean f2b determines the name of the connecting host and it complains indicating the pointer record doesn't match. Based on the number of login attempts it doesn't seem to be actually blocking the host either.
I have SSH locked down for my access only, but FTP is wide open for customer access. I let fail2ban keep tabs on logins with the vsftp-iptables jail.
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 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Theo Band wrote:
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?
I'm running fail2ban on my server (under CentOS-6.4) and it seems to be running according to ------------------------- [tim@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.
Incidentally, I am running shorewall on this server. Should I tell shorewall something about fail2ban, or vice versa?
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@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
On Tue, Mar 12, 2013 at 1:57 PM, Theo Band theo.band@greenpeak.com wrote:
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@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,
First off, as a good security practice do not let SSH open to the world unless you have to (and even then I'd go so far as to say restrict it the best you can). Fail2ban can become a band aid for good security practices.
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'd suggest at least checking out information on fail2ban's wiki and perusing the config files (especially jail.conf).
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
You can tweak things quite a bit to make sure logs are going where you want them to and that fail2ban is watching the right files.
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:
I'll add that if someone decides to restart iptables, your fail2ban chains will be removed. So you'll need to restart fail2ban and check that the chains and rules are present again. Otherwise fail2ban will report, but won't be able to actually add a firewall rule to block the brute forcing host.
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.
I've not seen any problems since I switched to the gamin backend some time ago. As you do, I generally get at least one daily notification email that my FTP daemon is being brute forced. So I'd say it's working fine.
Theo
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
SilverTip257 -
Theo Band -
Timothy Murphy