IMHO Fail2ban should have an option to enable automatic bantime, which increases each time an IP gets blocked. Other ways, an attacker could get to guess how many tries he can do in a given time and exploit your services without reaching that limit.

See http://www.sshguard.net/docs/faqs/#why-addresses-released for more info.

I've written a port of fail2ban for Mac OSX:
http://www.macports.org/ports.php?by=name&substr=fail2ban

It would be nice to update the fail2ban download page:
http://www.fail2ban.org/wiki/index.php/Downloads
as the mac osx link is broken

Should be really easy to implement AFAIK

Related reports: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407404

windows does not allow the pipe "|" char inside filenames.

Therefore i am not able to clone the fail2ban repos on windows.

see https://github.com/fail2ban/fail2ban/blob/master/files/ipmasq-ZZZzzz|fail2ban.rul

I try to add rules for manual ban, so first i added a new jail in /etc/jail.local

[blocklist]
enabled  =  true
port     =  all
filter   =  none
logpath  =  /etc/fail2ban/empty.log
maxretry =  1
bantime  =  3600
action   =  %(action_)s

fail2ban-client status seems fine

|- Number of jail:      8
`- Jail list:           blocklist, proftpd, ssh-ddos, apache-overflows, ssh, dovecot, apache, sasl

So heres my filter:

[Definition]

failregex =



ignoreregex =

Here's the output:

server1:/etc/fail2ban/filter.d# fail2ban-client set blocklist banip "22.22.22.22"
22.22.22.22

Result in iptables seems empty:

Chain fail2ban-blocklist (0 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Any idea?

Hi,

The problem is located in server/filter.py.

You Import the class MyTime, but in the addBannedIP function, you use "time.time" instead "MyTime.time".

Best regards

The regex:

failregex = [[]client <HOST>[]] File does not exist: .*/~.*

doesn't match against the error lines in logs.
The correct regex should be:

failregex = [[]client (?P<host>\S*)[]] File does not exist:

Update REGEX for fail2ban/config/filter.d/apache-overflows

I added this into the end of the failregex:

|request failed: error reading the headers

failregex = [[]client <HOST>[]] (Invalid (method|URI) in request|request failed: URI too long|erroneous characters after 
protocol string|request failed: error reading the headers)

I get error log lines like:

[Fri Nov 11 09:31:11 2011] [error] [client 2.220.201.22] request failed: error reading the headers
[Fri Nov 11 09:31:12 2011] [error] [client 189.25.100.125] request failed: error reading the headers

From these access log lines:

2.220.201.22 - - [11/Nov/2011:09:31:11 -0600] "\x06M\x13C\xce\x948'\xbd7\xdcj\xd7[\xf5\xf6\x8e\x058\xdf\x9aR\x9ed\xb2\xb3\xfbY\xc5\x0eV\xa7\xc4H\x91\x89\xe9\xfa@\xb1V\x10!@\xd4\xcf\xa4\x8f\xe1\xa5\xde\xfdb\xaf\xaaX\xc4\x1c\xf6\x91\x1f\r{X\xb4\xbah\xab\xce\xa3&:\xeaC\xaf\x86b\x11\xfa\x86<\xc8\x1f\xea=\x80\x9b&\xca\x14\x9b0\xaa\x83h\xdc\xf0\xbb\xd6\xbd\xb5\x85\x15\x8b\xc3[\xf1uOzL#\xc2\x85\xd3\x91\x9c\x9a\xf8\x14l\xcau^[\x1c\xc6\x18\x10\x02\x92\x9b\t\x1e\x1a\b\x96\x92\x89xZ\xaaF\xf4\xa8'\xf8\xda\xff\xf9\xaf\xb0\v\xcf\xb0\xb0o\x90Q\xee\xe0\x04\x0fI\xda\xb1\x90\xf0\xc4\xe9R#\xd5\xcdY.`\xce\xcc\x18\xaa\xbd\xe4\x92u\xcc\xcb\xad\x82CR|fv\xcf*\x1a\xe0\x94\xac\x94x~\x02\x1f\x16\xa1d\xb3.\xf7{t5)s\xb8~\xf8\x98\xd4>\xa776\x1b\xe7\xa8\x82{!C\xea\xabQ\x9f\x85\xd7\xd9\x1e\x0e\xae\x9f\x84\x15\xef\xbe\x1e\xbc\xfc8Q\x86\xdd\x9a\xaf\xcd\x04\xb2+" 400 470 "-" "-"
189.25.100.125 - - [11/Nov/2011:09:31:01 -0600] "\xfbl\xf0\xc3\x80\x02\x99\x80\xb82\x85\xf1\x16\vO\x03\x16N\xeat\xb1/\xd8\x82\xc1\x1e2ef\xaa\xd0U|\xb2\x0cy4yZ=Q\xd7T)\x951jx\x84a\x93\xcc\x1bg\xb3<\rD\x04]A\xb2\xfd]\xad!m\x1a#\xcff\x9a\x0cLk\x9c\x17" 400 403 "-" "-"

According to conf file, protocol=all should be an acceptable entry (and actually what I want). This "validates" according to fail2ban-client -d. However, when restarting fail2ban, the respective sub-chain is not created for the jail-rule-entry. If you choose protocol=tcp or protocol=udp, the sub-chain is created on startup as expected.

Without the actionstart correctly working, I do not believe the actionban will work, but to be honest, did not get to test that far.

As I wrote in:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669063

I think it would be useful to add to sshd filter
(/etc/fail2ban/filter.d/sshd.conf) following failregex:

^%(__prefix_line)sUser .+ from not allowed because listed in
DenyUsers$

For the case when you have defined DenyUsers in sshd_config. So, as I
do. It's just a thought...

I'm sorry if I entered my request to the wrong place and the wrong way.

-----[diff for /etc/fail2ban/filter.d/sshd.conf]-----
31a32

        ^%(__prefix_line)sUser .+ from <HOST> not allowed because listed in DenyUsers$

-----[diff for /etc/fail2ban/filter.d/sshd.conf]-----

-----[auth.log]-----
Apr 16 22:01:14 al-ribat sshd[5154]: Set /proc/self/oom_score_adj to 0
Apr 16 22:01:14 al-ribat sshd[5154]: Connection from 46.45.128.3 port 46256
Apr 16 22:01:15 al-ribat sshd[5154]: User root from 46.45.128.3 not allowed because listed in DenyUsers
Apr 16 22:01:15 al-ribat sshd[5154]: input_userauth_request: invalid user root [preauth]
Apr 16 22:01:15 al-ribat sshd[5154]: Received disconnect from 46.45.128.3: 11: Bye Bye [preauth]
-----[auth.log]-----

(Posted here based on discussion through the fail2ban-users mailing list)

I have fail2ban monitoring a couple of BB error logs that are causing some havok with its logfile tracking. Specifically, the YaBB error logs aren't arbitrary-length, constant-append logs like most error logs (e.g. apache error log), but are instead fixed-length, constantly-overwritten logs - they are capped at N lines (say N = 100) and every new (last) line written to the file causes the oldest (first) line to be deleted.

Fail2ban's log rotation detection is barfing on this kind of log - it thinks the log is being rotated every time it sees a new line being written. As a result, it basically "rescans" the file every time, but without resetting the hack-attempt counter, causing each line to be counted multiple times.

As an example:
Say the maxretry for this jail is set to 10 attempts. Fail2ban notices the first matching hack attempt in the error log, and sets the counter to 1. A new hack attempt is written to the file; upon the next scan, fail2ban thinks the logfile got rotated, and rescans the entire file - it now sees 2 entries, and adds BOTH entries to the counter, which is now at 3 attempts. The same thing happens on the 3rd attempt, whereupon the counter is now set to 6, and for the 4th, where the counter now hits 10 and fail2ban locks out the offending IP. In this way, fail2ban thinks it sees 10 matching lines even though it actually saw only 4, because it rescanned the logfile after each "rotation" without resetting the counter.

The one obvious workaround for this type of file is to set maxretry to the correct "n-sum" number, where if n is the number of attempts we actually want to catch, we set maxretry = n + (n-1) + (n-2) + ... + 1. This is rather a poor hack but it'd work.

One possible solution is to disable logrotation detection for this type of log, whereupon fail2ban would ignore logrotation and simply look at the latest lines being written. Unfortunately, since the file is of "constant" length, it would be difficult to keep track of how many new lines were added and which ones they are.

Another potential (possibly best) solution is to reset the attempt counter when log rotation is "detected" for this type of log; thus, when fail2ban rescans the entire logfile after "rotation," it will still see the correct number of matching errors instead of accumulating them the way it does now. The reset action would need to be a user-settable flag for only this type of logfile, since it would not be desirable to do such a reset on regular rotating logs; thus, one could add a flag such as "cyclinglog = true" to the jail configuration, and if this flag is true, the attempt counter is reset upon rotation detection, but if false (default), everything would continue as normal.

It's a rare use case but IMHO should be treated.

Thanks!

I'm calling fail2ban-client from action to pass jail status to monitoring server(Zabbix). When I do '/etc/init.d/fail2ban stop' or 'fail2ban-client stop', it hangs forever: socket is still alive, but fail2ban server is not responding to fail2ban client, and so unban action is never completed. IMHO fail2ban-server should be able to answer the fail2ban-client during shutdown process, at least at ping request, and may be that requested jail does not exist anymore.

Hi,

I see some weird behavior on some of our CentOS (5.x and 6.x) boxes running fail2ban (from EPEL).
After some investigation it turns out that out-of-the-box it fails to handle the log rotation of /var/log/secure (sshd logs).

So I took a look at my logs and the fail2ban sourcecode, and noticed the following:

• on the servers where fail2ban works like clockwork it's using gamin (fail2ban-0.8.4-23.el5)
• where it's not working it's using inotify (fail2ban-0.8.4-28.el6.noarch)

By default CentOS does not use "copytruncate" while rotating /var/log/secure, but "create". The result is that the "full" logfile is moved and a new file with the original name is created. This applies to both types of servers.

Looking at the source code of fail2ban I see that in server/filter.py (class FileContainer) it checks for a rotated log file as indicated by a different first line or inode number.
Next, I see that FilterGamin listens for GAMCreated, GAMChanged and GAMExists.
FilterPyinotify listens for IN_MODIFY;

Now not being an expert on Gamin and Inotify I assume this is why it is no longer working:

• With Gamin we get a GAMCreated event after the file is moved; The FileContainer then notices a different hash and inode and thus a rotated file
• With Inotify the log file is moved and no longer written to when it's rotated. IN_MODIFY is not emitted for the file since it's contents have not changed.

A simple solution appears to be to also monitor for IN_MOVED_SELF, but according to https://github.com/manos/python-inotify-tail_example this does not work with pyinotify on files.

First I've tried on superuser.com but nobody reply to it and now I think this is the best place to do it. So can someone look on the issue below and give me some suggestion what should I do? If you need more info plese just right a comment here or in superuser page..

http://superuser.com/questions/461575/fail2ban-console-error-message

Just ran into sshguard which has such a nice feature
http://www.sshguard.net/docs/log-validation/
which could be easily implemented in fail2ban for the syslog's which carry pid information which we already match but do not use.

So it would require specification of pidfile for the process (usually under /var/run/**.pid) + logic to monitor for their possible updates upon those services restarts (to avoid re-reading it every time) and that is pretty much it I guess.

Hi There,

We are receiving the following warning message while starting or restarting fail2ban,

Starting fail2ban: /usr/share/fail2ban/server/filter.py:430: DeprecationWarning: the md5 module is deprecated; use hashlib instead
import md5

and in fail2ban log file,

fail2ban.comm : WARNING Invalid command: ['set', 'ssh-iptables', 'addlogpath', '/var/log/secure']

In this case, fail2ban started normally and sending an email. But no filters are working due to this warning.

We are using fail2ban version 0.8.2-3.el5.rf. How we can fix this issue.. Please help.

Thank you.

I'v succesfuly integrated fail2ban with Zabbix monitoring system. Each time actionban/actionunban happens, external script is called to pass parameters to Zabbix server. Different jails have different triggers in Zabbix, because I want to know not only from which ip attack happend, but also what service was attacked. actionban/actionunban doesn't know, for which jail it was called, so I need to write separate action scripts for each service. If <jail> tag will be added, single script for all actions may be used. If <num_banned_ips> tag will be added(I mean number of banned ips in current jail), external script with call to fail2ban-client will not necessary.

If this changes will be made, integrating with different monitoring services will be as easy as configuring mail warnings and may become out-of-the-box fail2ban ability. I can provide actions configuration, Zabbix template and how-to insruction for wiki.

There's an annoying chinese bot which is already banned in hosts.deny due to falied sshd attempts. Despite that fail2ban keeps sending notification emails. Is there a possibility – or do you consider it as an feature request – to check for an active ban in iptabels and/or hosts.deny before sending notifications?

Kind regards
Mike

Hi,

I switched my server to centos 6.2 (fresh install) 2 months ago and i realized today, fail2ban stopped sending mails..
I am new on server management and dont know how to identify problem.
Saw this issue:
#44
and changed backend = gamin now but still i cant be sure its working or not.. how can i identify its working properly?

Source distributions from 0.8.4 until 0.8.6 (exclusive) looked straight into the last line in the logfile, thus ignoring all possible errors back (VCS still had "look at the whole file" upon restart). in 0.8.6 behavior changed to look through whole file banning while encountering matching entries. That is an expensive operation if log files are not rotated frequently. Ideally upon restart f2b should look only in the tail of the file as far back in time as as 'bantime'.

Probably it is ok to just read them in the reversed order.

The easiest and least inefficient implementation could use 'reversed()' while reading whole file into RAM, thus might be prohibitively inefficient. For smarter implementations see

http://stackoverflow.com/questions/2301789/read-a-file-in-reverse-order-using-python/2301867#2301867
http://stackoverflow.com/questions/260273/most-efficient-way-to-search-the-last-x-lines-of-a-file-in-python

At least as an option or additional command, I'd be delighted if fail2ban would do some combination of:

a: maintain a state database on disk (jail statuses, current bans)
b: re-scan jail logfiles and re-apply
c: restore jail banks after reboot

Awesome project!

Hi,

The tarballs are currently available in the tag section. The problem is this is not a static link to the archive. So the download could not be automaticaly done with tools such as wget or aria2c.

Please could you push tarballs in the download section in github or on sourceforge (http://sourceforge.net/projects/fail2ban/files/fail2ban-stable/)

Thanks.

I have this issue at random intervals. Typically on a seldom used jail. here is a sampling of log entries from the latest failure:

Oct 3 20:23:50 localhost imapd: LOGIN FAILED, user=admin, ip=[::ffff:81.169.154.91]
Oct 3 20:23:50 localhost imapd: LOGIN FAILED, user=webmaster, ip=[::ffff:81.169.154.91]
Oct 3 20:23:50 localhost imapd: LOGIN FAILED, user=user, ip=[::ffff:81.169.154.91]
Oct 3 20:23:50 localhost imapd: LOGIN FAILED, user=test, ip=[::ffff:81.169.154.91]
Oct 3 20:23:50 localhost imapd: LOGIN FAILED, user=web, ip=[::ffff:81.169.154.91]
Oct 3 20:23:50 localhost imapd: LOGIN FAILED, user=www, ip=[::ffff:81.169.154.91]
Oct 3 20:23:50 localhost authdaemond: pam_unix(imap:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=root
2012-10-03 20:23:51,678 fail2ban.actions: WARNING [courierauth] Ban 81.169.154.91
2012-10-03 20:23:51,745 fail2ban.actions: WARNING [courierauth] 81.169.154.91 already banned
Oct 3 20:23:51 localhost imapd: LOGIN FAILED, user=administrator, ip=[::ffff:81.169.154.91]
Oct 3 20:23:51 localhost imapd: LOGIN FAILED, user=oracle, ip=[::ffff:81.169.154.91]
Oct 3 20:23:51 localhost imapd: LOGIN FAILED, user=sybase, ip=[::ffff:81.169.154.91]
Oct 3 20:23:51 localhost imapd: LOGIN FAILED, user=informix, ip=[::ffff:81.169.154.91]
Oct 3 20:23:51 localhost imapd: LOGIN FAILED, user=oracle8, ip=[::ffff:81.169.154.91]
Oct 3 20:23:51 localhost imapd: LOGIN FAILED, user=root, ip=[::ffff:81.169.154.91]
Oct 3 20:23:51 localhost authdaemond: pam_unix(imap:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=backup
Oct 3 20:23:53 localhost imapd: LOGIN FAILED, user=backup, ip=[::ffff:81.169.154.91]
2012-10-03 20:33:51,746 fail2ban.actions: WARNING [courierauth] Unban 81.169.154.91

These were pulled from multiple logs and assembled. Since timestamps are limited to seconds the exact order of occurrence may not be correct. As you can tell abuse continued after after the ban was supposedly setup. Then there is a an "already banned" message, which would seem impossible if they were indeed banned. The ban was lifted 10 minutes later as configured but there was one failure at least two seconds after the ban was put into place.

I'm running Debian 5 on PPC Macs and standard Intel PCs. I've had this problem with many versions of fail2ban and am currently running 0.8.6 with Python 2.5.2. I had this problem on SuSE 9. I've been hoping this would get addressed for a long time.

Snippet of config:

[DEFAULT]
ignoreip = 127.0.0.1/8
ignoreip = 192.168.0.0/22
bantime = 600
maxretry = 3
backend = auto
banaction = iptables-multiport
protocol = tcp
chain = INPUT
action = %(banaction)s[name=%(name)s, port="%(port)s", protocol="%(protocol)s", chain="%(chain)s"]

[courierauth]
enabled = true
port = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter = courierlogin
logpath = /var/log/mail.log

Here's the filter config:
[Definition]
failregex = LOGIN FAILED, .*, ip=[]$
ignoreregex =

ATM banip command is directed to the corresponding filter which adds a failure, thus banip command must be issued "maxretry" times for ban to occur.

It should instead ban immediately, probably by manufacturing corresponding ticket and providing it to BanManager (didn't look myself yet either current design allows for that). (Sure thing there is easier solution -- just to loop for MaxRetry times, but imho that is not ideal ;) )

I'm using fail2ban version on debian stable, version 0.8.4-SVN. For some reason fail2ban declines to ban ips with banip. If I try IP addresses that are already banned I see a warning in fail2ban.log telling me that the IP is already banned. But if I try to ban new IPs then nothing is happening, not even when I ban them multiple times.

On /var/log/fail2ban.log I get:

2012-04-01 19:54:26,324 fail2ban.actions.action: ERROR  iptables -N fail2ban-Dovecot
iptables -A fail2ban-Dovecot -j RETURN
iptables -I INPUT -p tcp -m multiport --dports 110,995,143,993 -j fail2ban-Dovecot returned 100

2012-04-01 19:59:31,103 fail2ban.actions.action: ERROR  iptables -N fail2ban-Named
iptables -A fail2ban-Named -j RETURN
iptables -I INPUT -p tcp -m multiport --dports domain,953 -j fail2ban-Named returned 100

It doesn't show any error executing the same line on terminal:

# iptables -I INPUT -p tcp -m multiport --dports domain,953 -j fail2ban-Named

According to: /etc/fail2ban/action.d/iptables-multiport.conf

[Definition]

# Option:  actionstart
# Notes.:  command executed once at the start of Fail2Ban.
# Values:  CMD
#
actionstart = iptables -N fail2ban-
              iptables -A fail2ban- -j RETURN
              iptables -I INPUT -p  -m multiport --dports  -j fail2ban-

# Option:  actionstop
# Notes.:  command executed once at the end of Fail2Ban
# Values:  CMD
#
actionstop = iptables -D INPUT -p  -m multiport --dports  -j fail2ban-
             iptables -F fail2ban-
             iptables -X fail2ban-

Changing iptables-multiport to iptables config for each port works fine:

2012-04-01 20:14:53,246 fail2ban.actions: INFO   Set banTime = 600
2012-04-01 20:14:53,253 fail2ban.jail   : INFO   Jail 'dovecot-pop3imap' started
2012-04-01 20:14:53,256 fail2ban.jail   : INFO   Jail 'postfix' started
2012-04-01 20:14:53,259 fail2ban.jail   : INFO   Jail 'ssh-iptables' started
2012-04-01 20:14:53,262 fail2ban.jail   : INFO   Jail 'postfix-tcpwrapper' started
2012-04-01 20:14:53,266 fail2ban.jail   : INFO   Jail 'named-refused-udp' started
2012-04-01 20:14:53,269 fail2ban.jail   : INFO   Jail 'named-refused-tcp' started
2012-04-01 20:14:53,272 fail2ban.jail   : INFO   Jail 'proftpd-iptables' started
2012-04-01 20:14:53,275 fail2ban.jail   : INFO   Jail 'dovecot' started
2012-04-01 20:14:53,278 fail2ban.jail   : INFO   Jail 'sasl-iptables' started

I have iptables multiport support:

# cat /proc/net/ip_tables_matches
icmp
udp
tcp
iprange
multiport
multiport

# iptables --version
iptables v1.3.5

# fail2ban-client --version
Fail2Ban v0.8.4

# cat /etc/redhat-release 
CentOS release 5.8 (Final)

With cPanel 11

So I don't understand why fail2ban fails with iptables multiport

Dear developer,

Any plan to support OpenBSD and its packet filter (PF)?

e.g.

[asterisk]

enabled  = true
filter   = asterisk
action   = iptables-multiport[name=asterisk-udp, port="5060,5061", protocol=udp]
           iptables-multiport[name=asterisk-tcp, port="5060,5061", protocol=tcp]
           sendmail-whois[name=Asterisk, [email protected], [email protected]]
logpath  = /var/log/asterisk/messages
maxretry = 10

would result only in asterisk-tcp chain setup -- it is due to actions taking the 'name' of the jail. Simple patch

diff --git a/client/jailreader.py b/client/jailreader.py
index f66dc01..247216f 100644
--- a/client/jailreader.py
+++ b/client/jailreader.py
@@ -87,7 +87,9 @@ class JailReader(ConfigReader):
                        for act in self.__opts["action"].split('\n'):
                                try:
                                        splitAct = JailReader.splitAction(act)
-                                   action = ActionReader(splitAct, self.__name)
+                                 # YOH: action takes name specified in options if available
+                                 action = ActionReader(splitAct,
+                                                                           splitAct[1].get('name', self.__name))
                                        ret = action.read()
                                        if ret:
                                                action.getOptions(self.__opts)

is insufficient since it brakes logic somewhere in jails.py (I believe) which relies on action name to correspond to jail name. So more TODO (may be action name could be jail_name:action_name_option)?

I saw this posted in the fail2ban community wiki, and I thought this would be a very good addition to the fail2ban standard filters. Many hackers/spammers like to hit the same server repeatedly; these are almost always completely malicious, and in many cases it would be a good idea to ban these guys long-term, to reduce load on the server since they are known to be repeat offenders.

Thus, one can have fail2ban monitor its own logfile, to see if it is banning a repeat offender and, if so, to implement a long-term ban. The implementation below has its drawbacks, namely in that it works only with iptables, or if you use a different blocking mechanism for this jail versus others (e.g. shorewall for most and iptables for this one).

The filter file (fail2ban.conf) is as follows:

# Fail2Ban configuration file
#
# Author: Tom Hendrikx, minor modifications by Amir Caspi
# See http://whyscream.net/wiki/index.php/Fail2ban_monitoring_Fail2ban
#
# $Revision: 1 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = fail2ban.actions:\s+WARNING\s+\[(?:.*)\]\s+Ban\s+<HOST>

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex = fail2ban.actions:\s+WARNING\s+\[fail2ban\]\s+Ban\s+<HOST>

And my particular configuration in jail.conf is:

[fail2ban]

enabled  = true
filter   = fail2ban
action   = iptables-allports[name=FAIL2BAN]
           sendmail-whois-lines[name=FAIL2BAN, dest=root, [email protected], logpath=/var/log/fail2ban.log]
logpath  = /var/log/fail2ban.log
maxretry = 3
# Find-time: 1 day
findtime = 86400
# Ban-time: 1 week
bantime = 604800

While it has its limitations, I think this would be a good thing to include in the default set of filters, to allow users an easy access to a method to long-term block repeat offenders.

I've setup a few rules on my Debian Lenny (old, I know, soon to be replaced by Ubuntu Server 12.04 LTS) with fail2ban v0.8.3 and ipfw got confused while startup:

2012-05-07 09:31:47,167 fail2ban.actions.action: ERROR  iptables -N fail2ban-HTTP
iptables -A fail2ban-HTTP -j RETURN
iptables -I INPUT -p tcp --dport 80,443 -j fail2ban-HTTP returned 200

Google helped and found this: https://forum.blocklist.de/viewtopic.php?p=104&sid=cb11fad81fc4afe83b8a87a105dd0a2c#p104

The trick is to add a sleep here:

    def __processCmd(self, cmd, showRet = True):
        beautifier = Beautifier()
        for c in cmd:
            time.sleep(0.1)
            beautifier.setInputCmd(c)
            try:

This slows down the startup, but it's always better than an error ;-).

so it would not be necessary to play with sys.path in the scripts

would be beneficial for testing as well

This directory should be automatically created if not present. It doesn't seem to be.

Feel free to give me a wiki login and tell me to DIY :). [email protected].

"Syslog entries can be 'forged' by a regular user". https://github.com/fail2ban/fail2ban/blob/debian-devel/debian/README.Debian. But it references an old FAQ page. The old FAQ page is no longer accessible, and the question has been removed.

I would at least make sure it is mentioned under the "Limitations" section of the manual. (Whether or not it belongs in the FAQ, I think it should definitely be mentioned in the reference documentation).

Apparently authentication is one of the issues that caused Lennart Poettering to write the "journal" logging system. So maybe the issue will even get fixed, one of these days :). https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs

Thunderbird think, that mail came from 1970 year.

To solve this problem, you should change in config files:

• Date: `date -u +"%%a, %%d %%h %%Y %%T +0000"`
  

• Date: `date --rfc-2822 -u +"%%a, %%d %%h %%Y %%T +0000"`
  

This can save new users hours of frustration. Not a serious error at all,
just something that might save people hours of looking around :)

After spending hours trying to figure out why my fail2ban was not banning, I
thought to myself, why not run verbose mode, and maybe some extra info
might appear (the following run from the command line) :

fail2ban-client -v start

Doing so revealed the following error ERROR :

fail2ban-client start

WARNING 'action' not defined in 'php-url-fopen'. Using default value
WARNING 'action' not defined in 'lighttpd-fastcgi'. Using default value
ERROR No file found for /var/log/mail.log
2012-07-13 10:10:57,284 fail2ban.server : INFO Starting Fail2ban v0.8.5
2012-07-13 10:10:57,287 fail2ban.server : INFO Starting in daemon mode

Post Note : turns out you don't need verbose (-v) to get the above info.

This ERROR does not appear if you use the normal way of starting fail2ban :

/etc/init.d/fail2ban start

Unfortunately the ERROR is not written to log or anywhere else I can see.

I only found it after running the fail2ban client on the command line.

Maiko Langelaar
IT Physics and Astronomy
University of Manitoba

It had been a long requested feature to allow parsing log files where entries would consist of multiple lines

Originally it was scheduled by Cyril for 0.9.0 release

It looks to me like "/etc/fail2ban/filter.d/sshd.conf" does not have a correct REGEX string for Fedora 17.

The Fedora 17 secure log looks like this:

Oct 2 17:53:39 myhost sshd[13058]: input_userauth_request: invalid user test1 [preauth]
Oct 2 17:53:41 myhost sshd[13058]: pam_unix(sshd:auth): check pass; user unknown
Oct 2 17:53:41 myhost sshd[13058]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.23

I noticed there wasn't a filter available for imapd/ipop3d, the IMAP/POP3 daemons from uw-imap. These are still relatively common, so I made a filter for them. If one's system is using PAM then the standard PAM filter could be used instead, but this allows for a standalone filter based purely on uw-imap.

The filter file (uw-imap.conf) is as follows:

# Fail2Ban configuration file
#
# Author: Amir Caspi
#
# $Revision: 1 $

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = (?:ipop3d|imapd)

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#
failregex = ^%(__prefix_line)sLogin (?:failed|excessive login failures) user=\S* auth=\S* host=.*\[<HOST>\]\s*$ 

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex = 

The jail settings I use in jail.conf, for reference, are:

[ipop3d]

enabled  = true
filter   = ipop3d
action   = iptables-multiport[name=IPOP, port="pop3,pop3s,imap,imaps", protocol=tcp]
           sendmail-whois-lines[name=IPOP, dest=root, [email protected], logpath=/var/log/messages]
logpath  = /var/log/messages
maxretry = 5

Please feel free to incorporate this into the next release; hopefully this will be useful for other uw-imap users.

Hi There,

When adding two are more jails with the same filter and have a different bantime and findtime, the jails are started perfectly and working fine. But any one of the enabled jail with same filter will block the IP address. And other jails are not working properly.

While verifying the status of each jails, any one of the jail have "Currently failed" and "Total failed" list and all other jails status having zero in "Currently failed" and "Total failed" list.

My jail.conf configuration are as follows,

[ssh-iptables]

enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=root, sender=fail2ban@localhost]
logpath = /var/log/secure
bantime = 600
findtime = 300
maxretry = 3

[ssh-frequent]

enabled = true
filter = sshd
action = iptables-allports[name=SSH-FREQUENT, protocol=all]
sendmail-whois[name=SSH-FREQUENT, dest=root, sender=fail2ban@localhost]
logpath = /var/log/secure
bantime = 86400
findtime = 604800
maxretry = 20

Is this above jail configuration have any problem?. If yes, please suggest configuration to block the IP with different bantime and findtime for same filter and jail.

My Fail2ban version: Fail2Ban v0.8.6
My Python version: Python 2.6.8

Regards,
Vella

should spit out WARNING in the log, happened while testing running it as non-root user

When Apache logs turnover they are replaced and the naming changes. Consequently the log is no longer found by fail2ban and the jail is set to idle. The only way to reset the jail is either to add the new logfile, not really knowing the name, or by restarting fail2ban. As my logfiles are set to turnover when they reach a certain size this has been problematic.

I've got a solution but it's less than elegant. It involves running a couple of launchd processes to run a script that looks to see if a jail has been set to idle and restarting fail2ban.

Is there someway that if, after a logfile turnover and jail set to idle, the jail could automatically stop/start. Does fail2ban-client start <JAIL> reload the logfiles?

following a question brought up on the mailing list and memories about http://sourceforge.net/projects/tripwire/, it might be cool to get a simple action + filter + jail tandem to implement a simple tripwire by making iptables log accesses to otherwise unused commonly probed ports.

Original report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=410077

if external command (like mail) doesn't return but stalls, -server
would stall as well and would stop responding to -client requests like
status or stop, which makes it necessary to manually kill that command
and/or fail2ban.

It would be very useful to make the filters case-insensitive by configuration.

Support other date/time formats or create date profiles.

Fail2ban error:
2011.07.11 21:09:40 host(daemon.debug) fail2ban.filter : DEBUG Found a match for '2011.07.11 21:09:39 host(auth.info) sshd[19750]: Invalid user serial from 202.102.52.202 2011.07.11 21:09:40 host(user.notice) ' but no valid date/time found for '2011.07.11 21:09:39 host(auth.info) sshd[19750]: Invalid user serial from 202.102.52.202 2011.07.11 21:09:40 host(user.notice) '. Please contact the author in order to get support for this format

I use syslog-ng with:
destination d_messages { file("/var/log/messages" template("$R_YEAR.$R_MONTH.$R_DAY $R_HOUR:$R_MIN:$R_SEC $HOST($FACILITY.$PRIORITY) $MSGHDR$MSG\n") ); };

Sample line of syslog:
2011.07.11 21:09:39 host(auth.info) sshd[19750]: Invalid user serial from 202.102.52.202

References:

http://sourceforge.net/tracker/?func=detail&aid=3071865&group_id=121032&atid=689044

grep -ir fail2ban /var/log/messages

Sep 20 05:16:06 loghost <28>fail2ban.actions: WARNING [ssh] Ban 78.129.232.126
Sep 20 13:22:41 loghost <28>fail2ban.actions: WARNING [ssh] Ban 93.205.114.146
Sep 20 13:22:41 teg <28>fail2ban.actions: WARNING [ssh] Ban 93.205.114.146

"" is, according to http://wikipedia.org/wiki/Byte_Order_Mark, the Byto Order Mark for UTF8, not sure where "<28>" is from.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657286

Jan 25 02:13:08 ppc624 <U+FEFF>fail2ban.actions: WARNING [ssh] Ban 62.217.123.133
Jan 25 02:23:08 ppc624 <U+FEFF>fail2ban.actions: WARNING [ssh] Unban 62.217.123.133

hexdump -C shows prior "fail2ban.actions": 'ef bb bf'

syslog-ng

Discussion on the list:
https://sourceforge.net/mailarchive/forum.php?thread_name=B578CE00-D5F7-4D44-AD0A-44D1DB338E2B%40gmail.com&forum_name=fail2ban-users

Myself I have failed to reproduce it yet which complicates figuring out WTF

fail2ban doesn't appear to have any IPv6 support. With lots of networks (and thus hosts) trying to turn it on for World IPv6 Launch on June 6[1], this is a blocker.

http://www.worldipv6launch.org/

There don't appear to be any default filters for sendmail, so I thought I'd contribute a couple. The first one is to ban people who attempt to brute-force SMTP AUTH. This doesn't work wonderfully since not all brute-force attempts can be captured by the particular regex I'm using, but it catches a few. Ideally, one would use some other method (e.g. checking saslauthd logs) which would do a better job, but this is not always possible - for example, CentOS servers default to using saslauthd via PAM, and the current CentOS-packaged version of saslauthd (in all current CentOS dists) does not properly pass the "remotehost" parameter to PAM, so the saslauthd PAM errors are useless for fail2ban monitoring. Thus, in the default configuration, the only way to use fail2ban to kick out sendmail brute-force hackers is the following. (Another alternative is to set saslauthd's syslog level to "debug," but that adds a lot of length to logfiles and is not an out-of-the-box configuration.)

The second filter is to lock out spammers who are looking for open relays. Many spammers don't bother to "test the waters" on a server to check for an open relay - they usually just attempt to flood the server with dozens, even hundreds, of spam messages, simply hoping that the server is an open relay and will pass it on, and not caring if it's not. The filter included below checks for repeated "open relay" probes and locks out the offenders who are trying to use the server as a spambot. (Of course, this works only if you've actually locked down your server and disabled relaying without auth.)

sendmail brute-force hack filter - sendmail.conf:

# Fail2Ban configuration file
#
# Author: Jamie Morrison; minor modifications by Amir Caspi
# See http://theether.net/kb/100141
#
# $Revision: 1 $
#

[Definition]

# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values: TEXT
#
failregex = \[<HOST>\]: possible SMTP attack: command=AUTH

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex = 

sendmail spam relay filter - sendmail-relay.conf:

# Fail2Ban configuration file
#
# Author: Amir Caspi
#
# $Revision: 1 $
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = sm-acceptingconnections

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>[\w\-.^_]+)
# Values:  TEXT
#
failregex = ^%(__prefix_line)s\S*: ruleset=check_rcpt, arg1=\S*, relay=\S*\s*\[<HOST>\], reject=550 5.7.1 <\S*>... Relaying denied. Proper authentication required.\s*$

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex = 

And, the relevant jail.conf settings that I happen to use are:

[sendmail]

enabled  = true
filter   = sendmail
action   = iptables-multiport[name=SENDMAIL, port="smtp,smtps,submission", protocol=tcp]
           sendmail-whois-lines[name=SENDMAIL, dest=root, [email protected], logpath=/var/log/maillog]
logpath  = /var/log/maillog
# Once is enough for these jerks!
maxretry = 0

[sendmail-relay]

enabled  = true
filter   = sendmail-relay
action   = iptables-multiport[name=SENDMAIL, port="smtp,smtps,submission", protocol=tcp]
           sendmail-whois-lines[name=SENDMAILrelay, dest=root, [email protected], logpath=/var/log/maillog]
logpath  = /var/log/maillog
maxretry = 4

I hope these can be added to the default set of filters, as I think they would be quite useful - many still use sendmail and this has really helped to keep my sendmail hacks down to a minimum (particularly by tarpitting the damn spammers!).

Hope this helps.

From the mailing list:
http://sourceforge.net/mailarchive/forum.php?thread_name=50143F62.6050904%40whyscream.net&forum_name=fail2ban-users

> On 28-07-12 16:18, Gerry Magill wrote:
> > VoIP has to go through a SIP aware firewall in My scenario to resolve
> > NAT-traversal issues with the SIP protocol. So my SIP Registrar sees all
> > connections as coming from my SBCs IP. Each new distinct user appears to
> > me as traffic from a new port. This port binding never changes until my
> > SBC is rebooted.

> > I can identify SIP SPIT and SPAM using snort but blocking the whole IP
> > would kill my SBC.

> > So I am looking to black list IP port bindings I identify as being
> > malicious and release them after 3 days in jail.

So this use case would require to track not only by IP but by (IP, port) pair. We could implement this based on the named groups in the failregex (ATM only P<host> is utilized) and pass all those to the actions complementing the variables defined in Init and passed into the jail definition