On Tue, Mar 12, 2013 at 1:57 PM, Theo Band <theo.band at 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 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, > 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos > -- ---~~.~~--- Mike // SilverTip257 //