Fail2ban:Community Portal

From Fail2ban
Revision as of 20:24, 10 June 2009 by 128.112.24.13 (Talk)

Jump to: navigation, search

User Suggestions

Bruteforce from Botnets

(by CorvusCorax)

Hi. I was recently experimenting with a simple perl script that does roughly the same as fail2ban, to deal with bruteforce attacks on my server. I run into memory issues doe to number of attacks, and searched for alternatives, but fail2ban doesn't meet the requirements due to the following characteristics of nowadays attacks:

Attack characteristics

  • Connections related to the same attack series (same or similar usernames are tested) come from hundreds of different IPs.
  • Each attacker IP makes a number of simultaneous connections and login attempts at the same time (usually between 5 and 8)
  • Each attacker IP does only one such attack, and then will not try again for a timespan reaching from 30 seconds to several hours.

Requirements for Countermeasures

  • Superb reaction speed: An IP must be blocked fast enough to prevent completing at least some of the several simultaneous login attempts from the same IP.
  • Low threshold: Even with high reaction time, the server must take countermeasures at the first breakin attempt of an IP, in order to have an impact on the attack success.
  • User friendlyness: Despite this harsh methods, the server must react in a way not penalizing users that accidently mistype passwords beyond reasonable means.

My approach for implementation:

  • I used the | (pipe) syntax in /etc/syslogd.conf, to write relevant log information into a fifo, read on the fly by the response script, that way increasing reaction time.
  • The response script has a whitelist of IPs that have succesfully logged in on the same day - from which failures will be tolerated.
  • Any login failure from a non whitelisted IP will result in immediate blocking. additionally firewall rules that mimic the old MIRROR iptables target will be put in place, making any further attacks by that IP target the attacking system itself
  • To not hit the accidental mistyping legitimate user too hard, the first login failure of an IP will only result in a relatively short BAN, however the IP is remembered, and each additional authentication failure (including simultaneous failures occuring before the block - usually of the 5 to 8 I was blocking all but 2 or 3) increases the length of the BAN - increasing in timejumps of something like 30 seconds, 5 minutes, one hour, one day, ...
  • Blocking IPs for more than one day usually isn't very effective, since most botnet participants are on dynamic/dialin IPs anyway which tend to change on a 24h interval - thus the ban would become useless and worse hit other, innocent users. So the maximum ban time is 24 hours from the last seen breakin attempt.

Possible extensions

  • Use iptables "log" feature to react to attempted access during the ban-time and increase the ban time in this case - only unbanning if an IP stays silent long enough

It would be cool to see this implemented in fail2ban, especially a configurable escalation strategy with dynamically extending ban times, and support for piped log fifos for better reaction speed would be a must.



Modify "apache-auth.conf" to allow banning on server using digest authentication

Hello, digest authentication is unaccounted for apache using digest instead basic authentication. So just edit the apache-auth.conf file and extend the regex to: 

 failregex = [[]client <HOST>[]] .* user .* authentication failure
             [[]client <HOST>[]] .* user .* not found
             [[]client <HOST>[]] .* user .* password mismatch

cheers Ralf

New Features

Hello, having to manage more than 20 servers a good feature to introduce in the next releases, it could be to allow to modify the email notification's header, setting one common parameter (i.e.<emailheader>=[Machine_name || IP xyz.xyz.yxz.xyz - Fail2ban]) in fail2ban.conf, once for all actions.


for example, the section: 

             [Definition]
             # Option:  actionstart
             # Notes.:  command executed once at the start of Fail2Ban.
             # Values:  CMD
             #
             actionstart = printf %%b "Hi,\n
             The jail <name> has been started successfully.\n
             Regards,\n
             Fail2Ban"|mail -s "[Fail2Ban] <name>: started" <dest>

could be modified into: 

             Fail2Ban"|mail -s "<emailheader> <name>: started" <dest>

This will allow to the webadmins to understand immediately which server is under attack even without having to open the mail message. It is extremely useful if you are receiving alarms on your mobile phone ;)

cheers ^_^

James

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, dest=john_with_big_doe@world.net, sender=fail2ban@my_servers.net] logpath = /var/log/messages maxretry = 2

Thanks, Klaus

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" 

iptables -L....

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: 

iptables -nL....

See:

netfilter FAQ: iptables -L takes a very long time to display the rules

and

Docunext: fail2ban iptable.conf action

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.

Thanks, Phil.


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.

Suggestions

Ipset using iphash type

null routing

DNS blacklist


=== Regexp for vsftp

IP Addresses in Documentation

Hello, reading thru the docs and I just noticed that there are places where one should use 123.123.123.123 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.
--Trix

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..

(http://mochabomb.com/software/fail2ban-check.txt)

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 bear with me. Nevertheless here is an idea that struck me: If you implement an algorithm to "humanize" banning time, i.e. that calculates the time when that IP is not longer droped, would that hide some more information from a potential 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 unsuccessful 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 existing ones):

  • min-time-between-attempts-to-call-ban-action or range-between, e.g. range-between = 1s 10m
  • blur-by = x min
  • multiply-ban-time-by = x (or even exponentially?) and extend-bantime = true
  • comforting feature, nice-to-have: times in Xs = seconds, Xm = minutes.. like e.g. ddclient does

Thanks for your great work end effort! --88.191.80.227 12:48, 17 May 2008 (UTC)

pure-ftpd and apache ban fails with DNS error

Hi,

I'm running Fail2Ban v0.8.2 from fail2ban-0.8.2-14.fc7.rpm on FC7 (obviously). SSH is nicely blocked, but the pure-ftpd and apache logfiles lead to the error:

2008-06-24 17:33:17,657 fail2ban.filter : WARNING Unable to find a corresponding IP address for hostname.domain)

It's not surprising that "hostname.domain)" cannot be resolved due to the ending ")". A simple dns = dns.replace(")","") in filter.py solved the problem, but probably it's just a little typo in the filter regexp for pure-ftpd and apache? Maybe this problem is solved anyway and just apparent in the FC7 rpm?

Regards and thanks for this useful software!

Eike

A few notes

Hello and thanks for the nice script :)

I'm running Gentoo and fail2ban 0.8.2. I noticed that fail2ban didn't use the "POSSIBLE BREAK-IN ATTEMPT"-regexp at all and I think it's because my sshd puts an exclamation mark after the line, like "POSSIBLE BREAK-IN ATTEMPT!".

88.191.80.227 had some good ideas and I thought of something else too: a specific bantime for a certain regexp. At least I'm annoyed with the endless "connection from"-reports from sshd and most of them are caused by a bot. It would be nice to have that rule among the other sshd-rules, but with a lesser 'punishment'.


Question about persistant IP bans over restart

Hi, just started using fail2ban - love the software.

I have the ban time for postfix spamming IPs set to 1 month, but when logrotate does its thing from cron.daily I see that it restarts fail2ban. This seems to remove all currently banned IPs (for all rulesets) and fire out the usual collection of "Stopped...", "Started..." emails.

Is there any way to get currently banned IPs to persist over fail2ban restarts?

- Richard

I'm also interested in the ability to have bans persist over restarts. Can it be done with the post-ban scripts?

- Kevin

logrotate configuration must run 'fail2ban-client set logtarget /var/log/fail2ban.log' instead of 'invoke-rc.d --quiet fail2ban reload' (Debian installation).

- Eupalynos

Question how to ban hack attacks but not ban members

I see items in my logs like: 

     /admin/phpMyAdmin-2.2.3/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.2.6/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.1/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.4/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.5-pl1/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.5-rc1/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.5-rc2/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.5/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.6-rc1/main.php: 1 Time(s)
     /admin/phpMyAdmin-2.5.6-rc2/main.php: 1 Time(s)
     /phpMyAdmin-2.6.1-pl2/main.php: 1 Time(s)
     /phpMyAdmin-2.6.1-pl3/main.php: 1 Time(s)
     /phpMyAdmin-2.6.1-pl3/read_dump.phpmain.php: 1 Time(s)
     /phpMyAdmin-2.6.1-rc1/main.php: 1 Time(s)
     /phpMyAdmin-2.6.1-rc2/main.php: 1 Time(s)
     /phpMyAdmin-2.6.1/main.php: 1 Time(s)
     /phpMyAdmin-2.6.2-beta1/main.php: 1 Time(s)
     /phpMyAdmin-2.6.2-pl1/main.php: 1 Time(s)
     /phpMyAdmin-2.6.2-rc1/main.php: 1 Time(s)
     /phpMyAdmin-2.6.2/main.php: 1 Time(s)
     /phpMyAdmin-2.6.3-pl1/main.php: 1 Time(s)
     /phpMyAdmin-2.6.3-pl1/read_dump.phpmain.php: 1 Time(s)
     /phpMyAdmin-2.6.3-rc1/main.php: 1 Time(s)
     /phpMyAdmin-2.6.3/main.php: 1 Time(s)
     /phpMyAdmin-2.6.4-pl1/main.php: 1 Time(s)

How do I ban bad guys without banning members who just mis-type pages or try to rip it and just specify out of range pages? I just want to keep the BAD GUYS OUT!

- Tom

Add a action : Log packet with NFLOG

I made a modification based on iptables-multiport-log.conf : 


     # Fail2Ban configuration file
     #
     # Author: Guido Bozzetto
     # Modified: Cyril Jaquier
     # Modified: Cyril Lopez
     # make "fail2ban-<name>" chain to match drop IP
     # make "fail2ban-<name>-nflog" chain to log and drop
     # insert a jump to fail2ban-<name> from -I INPUT if proto/port match
     #
     #
     #
     
     [Definition]
     
     # Option:  actionstart
     # Notes.:  command executed once at the start of Fail2Ban.
     # Values:  CMD
     #
     actionstart = iptables -N fail2ban-<name>
                   iptables -A fail2ban-<name> -j RETURN
                   iptables -I INPUT 1 -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
                   iptables -N fail2ban-<name>-nflog
                   iptables -I fail2ban-<name>-nflog -j NFLOG --nflog-group 10 --nflog-prefix "$(expr fail2ban-<name> : '\(.\{1,23\}\)'):DROP " -m limit --limit 6/m --limit-burst 2
                   iptables -A fail2ban-<name>-nflog -j DROP
     
     # Option:  actionstop
     # Notes.:  command executed once at the end of Fail2Ban
     # Values:  CMD
     #
     actionstop = iptables -D INPUT -p <protocol> -m multiport --dports <port> -j fail2ban-<name>
                  iptables -F fail2ban-<name>
                  iptables -F fail2ban-<name>-nflog
                  iptables -X fail2ban-<name>
                  iptables -X fail2ban-<name>-nflog
     
     # Option:  actioncheck
     # Notes.:  command executed once before each actionban command
     # Values:  CMD
     #
     actioncheck = iptables -n -L fail2ban-<name>-nflog >/dev/null
     
     # Option:  actionban
     # Notes.:  command executed when banning an IP. Take care that the
     #          command is executed with Fail2Ban user rights.
     # Tags:    <ip>  IP address
     #          <failures>  number of failures
     #

Permanently Ban Persistent IP Addresses

I would love to see a way for Fail2Ban to permanently ban IPs that receive a temporary ban x number of times. For instance, if an IP attempts to break into SSH 5 times and fails, it gets a temporarily ban of 10 minutes. If that same IP tries and fails again 5 more times after the temporary ban is lifted, it gets another temporary ban. If that same IP cycles through this process 5 times in a span of 6 hours, create a firewall rule that is either permanent or covers a much longer time frame. I don't want to extend the number of minutes for a single ban in case a legit user just fails to log in too many times, but I don't want to receive the Fail2Ban emails for the same IP 300 times before I manually create a new firewall entry permanently blocking that IP.

Is this possible or can this functionality be easily added to Fail2Ban?

Thanks for such a great and useful tool!

Mike

Add regex tag for count

I have a couple services who will sit on failed attempts for a little bit, then release them all with something like "Failed login from <HOST>, X times" where X is of course variable. I don't see an easy way to add a new tag to the parser that could be used in a regex to pull that number in like one does with the <HOST> tag, so if someone could tell me where to do it that would be great. If someone wants to send me a diff, that would be even greater! :> 128.112.24.13 18:24, 10 June 2009 (UTC) (domain astro.princeton.edu, user huston)

Retrieved from "https://www.fail2ban.org/wiki/index.php?title=Fail2ban:Community_Portal&oldid=2425"