since 3 years I was noticing unhelpfully, what other little guys was trying to do with my servers. to try to break in. silly usernames, allmostly silly passwords. NOW we can stop this. I'm very keen on intelligently breaking attemps, lets see what "other little guys" can do in future. back to fail2ban. GREAT piece of software. thanx_very_much.
here's my try for webmin: I must to define explicit portnumber [port=webmin doesn't work] [webmin-iptables] enabled = true filter = webmin-auth action = iptables[name=webmin, port=10000, protocol=tcp] sendmail-whois[name=webmin, email@example.com, sender=fail2ban@my_servers.net] logpath = /var/log/messages maxretry = 2
I also love Fail2ban (great work guys), maybe I'm missing something but is there a way to unban an IP using fail2ban-client? If not could you add this feature?
Thank you :) You're right :/ You can't unban an IP address using fail2ban-client. This will be added in the next development branch (0.9). Be patient ;) --Lostcontrol 23:23, 21 March 2007 (CET)
Fail2ban is one of the best projects I've encountered - I love it! One suggestion: in 0.7 , the iptables.conf action uses pre-ban command"
Is there a reason for this? Maybe ip spoofing? At any rate, this can cause fail2ban to take forever in implementing its actions if the iptables chains are big, because it causes DNS lookups for each entry. I suggest adding the "n" flag to the command, to speed things up, like this:
Thank you. Added in the repository. --Lostcontrol 13:21, 14 December 2006 (PST)
I have found a problem in fail2ban 0.8.1. The regex for proftpd is incorrect. In the filter.d file, it reads:
failregex = USER \S+: no such user found from \S* ?\[<HOST>\] to \S+\s*$
\(\S*\[<HOST>\]\) - USER \S+ \(Login failed\): Incorrect password.$
The second line does not pick up a failed password. If you change it to:
\(\S*\[<HOST>\]\): USER \S+ \(Login failed\): Incorrect password.$
it will then pick it up. This has not been fixed in the nightly trunk as of 29-Oct-2007.
Seems that upon power failure, Fail2Ban fails to start when the computer reboots because the /tmp/fail2ban.sock file still exists. Perhaps this file could be removed automatically upon boot?
Fail2Ban output (like error messages) is sent to /dev/null when Fail2Ban is started during boot (at least on my Gentoo system), so it would be nice to at least be notified of the issue during bootup. Otherwise, it just says "Failed" during bootup, and it's hard to tell why. Just a thought.
=== Additional Actions for large ban tables (spam attacks)
When huge ban tables are formed something a little more efficient than iptables is needed.
Ipset using iphash type
=== Regexp for vsftp
IP Addresses in Documentation
Hello, reading thru the docs and I just noticed that there are places where one should use 22.214.171.124 as an IP Address for documentation.
Refering to http://tools.ietf.org/html/rfc3330 Section 2, Paragraph 12 please do use the TEST-NET assigned numbers. I think it would save quite a few users from misconfiguring their stuff (Just search for "TEST-NET" on the page and you'll be taken directly to the corresponding paragraph.
In short RFC3330 Special-Use IPv4 Addresses:
192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet.
I know this is a bit picky but personally I found that it eases use of documentation (also if you use example.com and example.net domains in documentation rather than some probably not so bogus hostname)
Thank you for the suggestion. I will adapt the documentation. --Lostcontrol 23:12, 18 April 2007 (CEST)
I installed the .80 branch on my fedora clarkconnect box. Unfortunatley clark uses python 2.3, so I had to rpm it to 2.4 I had two python libraries so once i downloaded and untarred the fail2ban source I ran "/usr/bin/python2.4 setup.py install" and everything ran fine, no complaints about @staticmod. I also note my main problem is errors in my proftpd as I'm being hacked by user "administrator" unknown. proftpd logs to /var/log/secure not /var/log/ftp/proftpd as set in the default configs. Once I set my email I allready nabbed a china hacker and got an email. Thanks, I run snort,snortsam, and fail2ban and feel pretty secure.
Could you try a nightly build from trunk? It should work with Python 2.3 which is the minimal requirement for the new development branch. I haven't done a lot of work on this branch yet (CHANGELOG) and your current configuration will work without any modifications. If you try it, please, could you give me feedback (mailing-list or e-mail)? Thank you. --Lostcontrol 09:52, 29 June 2007 (CEST)
- Thanks for this - it works perfectly on RHEL4, which is using Python 2.3. Just a suggestion: you may want to update the README that comes with the package so it doesn't talk about Python >= 2.4 any more.
High CPU wake-up in powertop
Using PowerTop (http://www.lesswatts.org/projects/powertop/), fail2ban seems to wake up the CPU a lot, draining laptop batteries.
Here is an ouyput of powertop under Ubuntu 7.10 (running in VirtualBox).
Principales causes de réveils : 58,6% ( 26,9) fail2ban-server : schedule_timeout (process_timeout) 12,9% ( 5,9) vboxadd-xclient : schedule_timeout (process_timeout) 5,7% ( 2,6) Xorg : do_setitimer (it_real_fn) 5,4% ( 2,5) multiload-apple : schedule_timeout (process_timeout) 4,4% ( 2,0) <kernel core> : clocksource_register (clocksource_watchdog) 2,2% ( 1,0) nm-applet : schedule_timeout (process_timeout) [...stripped...]
Could it be possible to investigate this ?
Hi. This is fixed in 0.9 branch (trunk). You can give it a try: http://www.fail2ban.org/nightly/fail2ban-trunk.tar.bz2 --Lostcontrol 12:10, 4 December 2007 (CET)
Created script to check fail2ban congfiguration
Created this script after I had several misconfigurations across many servers - this will use values from the config files for testing - a wrapper for fail2ban-regex and eliminating late-night, low-on-caffeine human errors in testing your config. Could also be used: after an update to verify the configuration, run weekly cron, create a fail2ban report..
This was written on Redhat+fail2ban 0.8 - with mild changes ought to work for and *nix system
Fail2ban is an incredibly valuable program. It ought to be included in all Redhat/Debian/FreeBSD/*nix distro's
ban for about xx min, config time between break-in attempts?
I don't know that much about the way fail2ban and breaking into systems works so bare with me. Nevertheless here is an idea that struc my mind: If you implement an algorythm to "humanise" banning time, i.e. that calculates the time when that IP is not longer droped, would that hide some more information from a potetial cracker? I'm thinking: If I can see that my IP is blocked for 1 min, for 3 min, for 8 min, but not 10 min after my last unsuccessfull try I might be able to guess (using maybe other info, too) that fail2ban is utilized? Or even better if fail2ban extends the period with every time this ip keeps trying? As I said, just brainstorming here :)
Config options would be nice, too (hopefully I haven't overlooked already existion ones):
- min-time-between-attempts or range-between...
- blur-by = x min
- comforting feature, nice-to-have: times in Xs = seconds, Xm = minutes.. like e.g. ddclient does
Thanks for your great work end effort! --126.96.36.199 12:48, 17 May 2008 (UTC)