I have done everything possible but nothing works. There is some documentation to work in Debian Squeeze with IPSConfig 3. I appreciate your feedback.
Yes i know that ... and write the filters for the diferent service too, but nothing work ... My jail.local file : [pureftpd] enabled = true port = ftp filter = pure-ftpd logpath = /var/log/syslog maxretry = 3 [sasl] enabled = true port = smtp filter = sasl logpath = /var/log/mail.log maxretry = 5 [courierpop3] enabled = true port = pop3 filter = courierpop3 logpath = /var/log/mail.log maxretry = 5 [courierpop3s] enabled = true port = pop3s filter = courierpop3s logpath = /var/log/mail.log maxretry = 5 [courierimap] enabled = true port = imap2 filter = courierimap logpath = /var/log/mail.log maxretry = 5 [courierimaps] enabled = true port = imaps filter = courierimaps logpath = /var/log/mail.log maxretry = 5 Thank you for your answer
similar problem here, I manually tried to trigger fail2ban logging in anonymously into pure-ftp: my fail2ban settings: The logs look like this: I tested it and it should pick up the attempts: I found this version somewhere, which one is the right one: ###edit### The problem is fail2ban does absolutely nothing , just sits there looking pretty :-(
What is in /var/log/fail2ban.log? If nothing try restarting/reloading it and check that log. (debian = /etc/init.d/fail2ban reload)
Hmm, no real idea. The easiest one to check is the ssh jail, generally /var/log/auth.log will show attempts. Perhaps you might like to check the default "banaction" you have set in jail.conf. Generally the iptables-multiport one is the one to use. You might also need to define it's action in the jail.local eg; [pureftpd] enabled = true port = ftp,ftp-data,ftps,ftps-data filter = pure-ftpd action = %(action_mw)s logpath = /var/log/syslog maxretry = 3
Not sure why I should check auth.log since THERE ARE attempts within syslog: the ban action is defined in jail.conf as follows: I just saw that fail2ban.conf has the option of raising the loglevel to debugging: Now lets see if anything interesting turns up in fail2ban's log file. Thanks for helping out so far!
I was referring to the ssh jail which uses the auth.log simply because this is the one that will get hit the most - more then ftp will. The fail2ban-regex is also just checking that the regex works. Having 19 successful matches doesn't indicate they occurred within the time frame for fail2ban to ban the attempts.
I rarely have any attempts on SSH since I moved it to another port. BUT I jsut tried to anonymously log in via FTP 5x and found this in auth.log: Feb 17 00:15:04 h2118175 pure-ftpd: ([email protected]) [WARNING] Authentication failed for user [anonymous] So that is ok and indeed in fail2ban.log I see: The settings for this jail are: So I should have been blocked :-(
No. You have maxretry = 3 You'll need to make a few attempts within the time frame. So, really on the 4th attempt you should be blocked.
Got me beat.. bet there is something simple somewhere in one of the config's that's causing the problem.. just a matter of finding it
Solved it by completely removing it: apt-get remove --purge fail2ban and now all of a sudden its log file shows: No idea what was wrong but its ok now
one other error randomly popping up: Found a couple of threads that suggested editing iptables-multiport.conf and inserting a sleep command: but that didn't help. Anyone any other ideas?
The sleep isn't added to the iptables-multiport.conf. You need to change the python code in the fail2ban-client. (/usr/bin/fail2ban-client) There are a few examples of how to do this on the web, you can see an example here: http://www.fail2ban.org/wiki/index....ban.actions.action_ERROR_on_startup.2Frestart
I got my info from the exact same page, scroll a bit down and find this: BUT I have now tried the other method you mentioned. Lets see how it goes.
You should notice if it works immediately.. once fail2ban-client is edited just reload fail2ban (/etc/init.d/fail2ban reload) and check the log (/var/log/fail2ban)
as I said above: and not when restarting fail2ban otherwise I'd have picked it up earlier. It jsut happened again, apparently at the first ban after it was restarted: