View source for MANUAL 0 8

== Introduction ==

=== The problem ===

Brute-force break-in attempts are quite frequent against an SSH server and other password protected internet-services (such as ftp,pop,...). Automated scripts try multiple combinations of username/password (brute-force, dictionary attack) and sometimes changing the port to something other than the default can't be done. Furthermore, scouring your log files yourself is not only time consuming, but can be difficult too.

{{Fail2ban}} attempts to alleviate these issues by providing an automated way of not only identifying possible break-in attempts, but acting upon them quickly and easily in a user-definable manner.

=== The solution ===

Log files contain interesting information, especially about failed logins. This information can be used to ban an offensive host. This is exactly what {{Fail2ban}} does. It scans log files and detect patterns which correspond to possible breakin attempts and then performs actions. Most of the time, it consists of adding a new rule in a firewall chain and sending an e-mail notification to the system administrator.

Here is a list of the most important features available in {{Fail2ban}}:

* client/server
* multithreaded
* [http://www.gnome.org/~veillard/gamin/ Gamin] support
* autodetection of the date/time format
* wildcard support in ''logpath'' option
* support for a lot of services (sshd, apache, qmail, proftpd, sasl, etc)
* support for several actions (iptables, tcp-wrapper, shorewall, mail notifications, etc)

The code has been completely rewritten since 0.6.x. {{Fail2ban}} is entirely written in Python and thus should work on most of the *nix systems.

== Installation ==

=== Requirements ===

In order to use {{Fail2ban}}, the following software are required:

* Python >= 2.4

The following software are optional but recommended:

* [http://www.netfilter.org/projects/iptables/index.html iptables]
* [http://www.shorewall.net/ shorewall]
* [ftp://ftp.porcupine.org/pub/security/index.html tcp-wrappers]
* a working ''mail'' command
* [http://www.gnome.org/~veillard/gamin/ Gamin] the File Alteration Monitor

You will probably need at least one firewall software like ''iptables'' or ''shorewall''. If you want a software which is not supported, please feel free to contact the author.

[http://www.gnome.org/~veillard/gamin/ Gamin] is a file alteration monitor. Gamin greatly benefits from a "inotify"-enabled kernel. Thus, active polling is no longer required to get the file modifications.

=== Installing from sources on a GNU/Linux system ===

You will need to obtain the latest version of the [http://sourceforge.net/project/showfiles.php?group_id=121032&package_id=132537 source code] in order to compile {{Fail2ban}} yourself. Once you have done this, change to the directory where you downloaded the source code and execute the following:

 tar xvjf fail2ban-x.x.x.tar.bz2

You will have the {{Fail2ban}} source code extracted to a directory under the current working directory. You must now move to the new directory.

Now run the installation script as root:

 ./setup.py install

{{Fail2ban}} should now be installed into ''/usr/share/fail2ban/'' and ''/usr/bin/''. You will also have to copy the content of ''config/'' into ''/etc/fail2ban/'' (not so in version 0.8.1). You are now ready to use the application.

'''Integrate fail2ban into your INIT-Process:'''

Go into the files-folder where you extracted the sources: 
<pre># cd /usr/local/src/fail2ban-0.8.1/files</pre>
and copy the init-script fitting your distribution to /etc/init.d. 
<pre># cp suse-initd /etc/init.d/fail2ban
# chmod 755 /etc/init.d/fail2ban</pre> 
* [the default-debian-script is missing in the source-files currently; but deb-package is available...]
Here's the one from the official deb-package (for those of you that want to install from source), hopefully it will be added or be replaced with a universal init-script in a future release...:
<pre>
#! /bin/sh
### BEGIN INIT INFO
# Provides:          fail2ban
# Required-Start:    $local_fs $remote_fs
# Required-Stop:     $local_fs $remote_fs
# Should-Start:      $time $network $syslog iptables firehol shorewall ipmasq
# Should-Stop:       $network $syslog iptables firehol shorewall ipmasq
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start/stop fail2ban
# Description:       Start/stop fail2ban, a daemon scanning the log files and
#                    banning potential attackers.
### END INIT INFO

# Author: Aaron Isotton <aaron@isotton.com>
# Modified: by Yaroslav Halchenko <debian@onerussian.com>
#  reindented + minor corrections + to work on sarge without modifications
#
PATH=/usr/sbin:/usr/bin:/sbin:/bin
DESC="authentication failure monitor"
NAME=fail2ban

# fail2ban-client is not a daemon itself but starts a daemon and
# loads its with configuration
DAEMON=/usr/bin/$NAME-client
SCRIPTNAME=/etc/init.d/$NAME

# Ad-hoc way to parse out socket file name
SOCKFILE=`grep -h '^[^#]*socket *=' /etc/$NAME/$NAME.conf /etc/$NAME/$NAME.local 2>/dev/null \
          | tail -n 1 | sed -e 's/.*socket *= *//g' -e 's/ *$//g'`
[ -z "$SOCKFILE" ] && SOCKFILE='/tmp/fail2ban.sock'

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
DAEMON_ARGS="$FAIL2BAN_OPTS"

# Load the VERBOSE setting and other rcS variables
[ -f /etc/default/rcS ] && . /etc/default/rcS

# Predefine what can be missing from lsb source later on -- necessary to run
# on sarge. Just present it in a bit more compact way from what was shipped
log_daemon_msg () {
	[ -z "$1" ] && return 1
	echo -n "$1:"
	[ -z "$2" ] || echo -n " $2"
}

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
# Actually has to (>=2.0-7) present in sarge. log_daemon_msg is predefined
#  so we must be ok
. /lib/lsb/init-functions

#
# Shortcut function for abnormal init script interruption
#
report_bug()
{
	echo $*
	echo "Please submit a bug report to Debian BTS (reportbug fail2ban)"
	exit 1
}

#
# Helper function to check if socket is present, which is often left after
# abnormal exit of fail2ban and needs to be removed
#
check_socket()
{
	# Return
	#	0 if socket is present and readable
	#	1 if socket file is not present
	#	2 if socket file is present but not readable
	#	3 if socket file is present but is not a socket
	[ -e "$SOCKFILE" ] || return 1
	[ -r "$SOCKFILE" ] || return 2
	[ -S "$SOCKFILE" ] || return 3
	return 0
}

#
# Function that starts the daemon/service
#
do_start()
{
	# Return
	#	0 if daemon has been started
	#	1 if daemon was already running
	#	2 if daemon could not be started
	do_status && return 1

	if [ -e "$SOCKFILE" ]; then
		log_failure_msg "Socket file $SOCKFILE is present"
		return 2
	fi

	start-stop-daemon --start --quiet --chuid root --exec $DAEMON -- \
		$DAEMON_ARGS start > /dev/null\
		|| return 2

	return 0
}


#
# Function that checks the status of fail2ban and returns
# corresponding code
#
do_status()
{
	$DAEMON ping > /dev/null
	return $?
}

#
# Function that stops the daemon/service
#
do_stop()
{
	# Return
	#	0 if daemon has been stopped
	#	1 if daemon was already stopped
	#	2 if daemon could not be stopped
	#	other if a failure occurred
	$DAEMON status > /dev/null || return 1
	$DAEMON stop > /dev/null || return 2

	# now we need actually to wait a bit since it might take time
	# for server to react on client's stop request. Especially
	# important for restart command on slow boxes
	count=1
	while do_status && [ $count -lt 60 ]; do
		sleep 1
		count=$(($count+1))
	done
	[ $count -lt 60 ] || return 3 # failed to stop

	return 0
}

#
# Function to reload configuration
#
do_reload() {
	$DAEMON reload > /dev/null && return 0 || return 1
	return 0
}

# yoh:
# shortcut function to don't duplicate case statements and to don't use
# bashisms (arrays). Fixes #368218
#
log_end_msg_wrapper()
{
	[ $1 -lt $2 ] && value=0 || value=1
	log_end_msg $value
}

case "$1" in
	start)
		[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
		do_start
		[ "$VERBOSE" != no ] && log_end_msg_wrapper $? 2
		;;
	stop)
		[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
		do_stop
		[ "$VERBOSE" != no ] && log_end_msg_wrapper $? 2
		;;
	restart|force-reload)
		log_daemon_msg "Restarting $DESC" "$NAME"
		do_stop
		case "$?" in
			0|1)
				do_start
				log_end_msg_wrapper $? 1
				;;
			*)
				# Failed to stop
				log_end_msg 1
				;;
 		esac
		;;

	reload|force-reload)
        log_daemon_msg "Reloading $DESC" "$NAME"
        do_reload
        log_end_msg $?
        ;;

	status)
		log_daemon_msg "Status of $DESC"
		do_status
		case $? in
			0)  log_success_msg " $NAME is running" ;;
			255)
				check_socket
				case $? in
					1)  log_warning_msg " $NAME is not running" ;;
					0)  log_failure_msg " $NAME is not running but $SOCKFILE exists" ;;
					2)  log_failure_msg " $SOCKFILE not readable, status of $NAME is unknown";;
					3)  log_failure_msg " $SOCKFILE exists but not a socket, status of $NAME is unknown";;
					*)  report_bug "Unknown return code from $NAME:check_socket.";;
				esac
				;;
			*)  report_bug "Unknown $NAME status code"
		esac
		;;
	*)
		echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload|status}" >&2
		exit 3
		;;
esac

:
</pre>

Finally after editing the file, and adjusting the paths to fail2ban-client and fail2ban-server run chkconfig or update-rc.d or create the symbolic links manually...
<pre>chkconfig -a fail2ban</pre>
or 
<pre>update-rc.d fail2ban defaults</pre>
or 
<pre>ln -s /etc/init.d/fail2ban /etc/rc2.d/S20fail2ban ...</pre>

'''Integrate fail2ban into logrotate:'''

create file "/etc/logrotate.d/fail2ban":
<pre>
/var/log/fail2ban.log {
    weekly
    rotate 7
    missingok
    compress
    postrotate
      /usr/local/bin/fail2ban-client reload 1>/dev/null || true
    endscript
}
</pre>

The path to your fail2ban-client needs to be adjusted (# whereis fail2ban-client)

=== Debian ===

Installing {{Fail2ban}} on a Debian based system is very straightforward. Execute the following code as the '''root''' user on an ''unstable'' version of Debian:

 apt-get install fail2ban

Or get the package for all debian versions at http://packages.debian.org/sid/fail2ban/all/download and install manually:

 dpkg -i fail2ban_0.8.1-1_all.deb

=== Gentoo ===

{{Fail2ban}} is available in [http://packages.gentoo.org/packages/?category=net-analyzer;name=fail2ban Portage]. To install it, just run:

 emerge fail2ban

The [[FAQ]] have a more detailed explanation of installing using distributions such as [http://debian.org Debian], [http://redhat.com RedHat] and [http://gentoo.org Gentoo]


== Usage ==

=== Definitions ===

Before we begin, it is important to clarify some terms used in the following sections.

{|
| ''filter'' || : || a filter defines a regular expression which must match a pattern corresponding to a log-in failure or any other expression
|-
| ''action'' || : || an action defines several commands which are executed at different moments
|-
| ''jail'' || : || a jail is a combination of one filter and one or several actions. {{Fail2ban}} can handle several jails at the same time
|-
| ''client'' || : || refers to the script '''fail2ban-client'''
|-
| ''server'' || : || refers to the script '''fail2ban-server'''
|}

=== Server ===

{{Fail2ban}} is composed of 2 parts: a client and a server. The server is multi-threaded and listens on a Unix socket for commands. The server itself knows nothing about the configuration files. Thus, at start-up, the server is in a "default" state in which no jails are defined. The following options are available for '''fail2ban-server''':

 -b                   start in background
 -f                   start in foreground
 -s <FILE>            socket path
 -x                   force execution of the server
 -h, --help           display this help message
 -V, --version        print the version

'''fail2ban-server''' should not be used directly except in case of debugging. The option '''-s <FILE>''' is probably the most important one and is used to set the socket path. Thus, it is possible to run several instances of {{Fail2ban}} on different sockets. However, this should be not required because {{Fail2ban}} can run several jails concurrently.

If '''fail2ban-server''' crashes (does it?), it is possible that the socket file has not been removed correctly. The '''-x''' option tells the server to delete the socket file before start-up. If the socket file of a running server is removed, it is not possible to communicate with this server anymore.

The server handles the signals ''SIGTERM'' and ''SIGINT''. When receiving one of these signals, '''fail2ban-server''' will quit nicely.

=== Client ===

'''fail2ban-client''' is the frontend of {{Fail2ban}}. It connects to the server socket file and sends commands in order to configure and operate the server. The client can read the configuration files or can simply be used to send a single command to the server using either the command line or the interactive mode (which is activated with the '''-i''' option). '''fail2ban-client''' can also start the server. The following options are available for '''fail2ban-client''':

 -c <DIR>                configuration directory
 -s <FILE>               socket path
 -d                      dump configuration. For debugging
 -i                      interactive mode
 -v                      increase verbosity
 -q                      decrease verbosity
 -x                      force execution of the server
 -h, --help              display this help message
 -V, --version           print the version

As for '''fail2ban-server''', the option '''-s <FILE>''' can be used to set the socket path. Notice that this command line option overrides the '''socket''' option set in ''fail2ban.conf''. The default configuration directory is ''/etc/fail2ban'' but can be override with the '''-c <DIR>''' option. The '''-x''' option is simply forwarded to '''fail2ban-server''' when starting the server.

A useful option for debugging is '''-d'''. This prints the configuration parsed by '''fail2ban-client'''. The output corresponds to the stream sent to the server. If the output of '''-d''' shows:

 ['set', 'loglevel', 1]
 ['set', 'logtarget', 'STDERR']

It is possible to achieve the same with:

 $ fail2ban-client set loglevel 1
 $ fail2ban-client set logtarget STDERR

Everything set in the configuration files can be configured manually. The configuration is just a simple and efficient way to configure the server. '''fail2ban-client''' only translates the configuration into a suite of commands. However, '''fail2ban-client''' has 2 more commands for its internal use. The first one is '''start'''. When typing:

 $ fail2ban-client start

the client will first try to fork a server instance. The client then waits for the server to start-up by sending ping requests to it. Once the server responds to these requests, '''fail2ban-client''' parses the configuration and sends the corresponding commands to the server. The second one is '''reload'''. When typing:

 $ fail2ban-client reload

the client will tell the server to stop all jails, parses the configuration files again and send the commands to the server. This is useful when a new configuration must be loaded without shutting down the server. This is also very useful when debugging the server. It is possible to start the server with '''fail2ban-server -f''' in one terminal and to load the configuration by typing '''fail2ban-client reload''' in an other one. Thus, client and server output will not be mixed up.

Any other commands are simply sent to the server without any specific treatment. However, most of the time, only the 2 above commands and '''stop''' will be used.

There is probably one last useful command: '''status [jail]'''. Without a jail name, the global status of the server is returned. If jail corresponds to an existing jail, the status of this jail is displayed.

A list with all commands is available [[Commands|here]].

== Configuration ==

The standard path for the configuration is in ''/etc/fail2ban''. This can be set with the '''-c''' option of '''fail2ban-client'''. A typical configuration looks like this:

 /etc/fail2ban/
 ├── action.d
 │   ├── dummy.conf
 │   ├── hostsdeny.conf
 │   ├── iptables.conf
 │   ├── mail-whois.conf
 │   ├── mail.conf
 │   └── shorewall.conf
 ├── fail2ban.conf
 ├── fail2ban.local
 ├── filter.d
 │   ├── apache-auth.conf
 │   ├── apache-noscript.conf
 │   ├── couriersmtp.conf
 │   ├── postfix.conf
 │   ├── proftpd.conf
 │   ├── qmail.conf
 │   ├── sasl.conf
 │   ├── sshd.conf
 │   └── vsftpd.conf
 ├── jail.conf
 └── jail.local
 
Every ''.conf'' file can be overridden with a file named ''.local''. The ''.conf'' file is read first, then ''.local'', with later settings overriding earlier ones.  Thus, a ''.local'' file doesn't have to include everything in the corresponding ''.conf'' file, only those settings that you wish to override.

Modifications should take place in the ''.local'' and not in the ''.conf''. This avoids merging problem when upgrading. These files are well documented and detailed information should be available there.

=== General settings ===

The file ''fail2ban.conf'' contains general settings for the '''fail2ban-server''' daemon, such as the logging level and target. You can also specify here the socket path used for communication between the client and the server.

=== Jails ===

The most important file is probably ''jail.conf'', which contains the declaration of your jails. By default, some sections are inserted as templates. You must enable the sections of interest and adapt to your local configuration. Here is an example of the ssh-iptables section:
<pre>[ssh-iptables]
#enabled  = false
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
#          mail-whois[name=SSH, dest=yourmail@mail.com]
#logpath  = /var/log/sshd.log
logpath  = /var/log/auth.log
maxretry = 5
</pre>
:With these settings a few things will happen:
:# the section <nowiki>ssh-iptables</nowiki> is ''enabled'';
:# the filter ''sshd''.conf in sub-directory ''filter.d'' will be processed;
:# the action(s) described in ''iptables''.conf (sub-directory ''action.d'') will be executed if the outcome of the filter process is true. In this example, the additional action ''mail-whois''.conf is commented out. 
:# the log file to be scanned by the filter is ''auth.log''.

Filter and actions are combined to create jails. Only one filter is allowed per jail, but it is possible to specify several actions, on separate lines. For example, you can react to a SSH break-in attempt by first adding a new firewall rule, then retrieving some information about the offending host using ''whois'' and finally sending an e-mail notification. Or maybe you just want to received a notification on your Jabber account when someone accesses the page ''/donotaccess.html'' on your web server.

{{Fail2ban}} is not limited to SSH. It contains default filters and actions for many daemons and services. You can easily modify them or create new ones.
If you take a look in the filter.d you will notice a few default filters that don't occur in the standard jail.conf that come with the sources. In this example we take the "sshd-ddos.conf". To integrate the filter into fail2ban edit your jail.conf:

 [ssh-ddos]
 
 enabled = true
 port    = ssh,sftp
 filter  = sshd-ddos
 logpath  = /var/log/messages
 maxretry = 2

Always remember to adjust $logpath to your log-file as mentioned above.

=== Filters ===

The directory ''filter.d'' contains mainly regular expressions which are used to detect break-in attempts, password failures, etc. Here is an example for ''filter.d/sshd.conf'' with 3 possible regular expressions to match the lines of the logfile:
<pre>
failregex = Authentication failure for .* from <HOST>
            Failed [-/\w]+ for .* from <HOST>
            ROOT LOGIN REFUSED .* FROM <HOST>
            [iI](?:llegal|nvalid) user .* from <HOST>
</pre>
In the above example the default regex has been changed to allow the absence of ''user'' in a line such as:
<pre>
Jan 10 07:02:37 homebrou sshd[18419]: Failed password for root from 222.76.213.151 port 55236 ssh2
</pre>

If you're creating your own failregex expressions, here are some things you should know:

* A failregex can have multiple lines, any one of which may match a line of the log file.

* In every line of failregex, the part that matches the host name or IP address must be wrapped in a <code>(?P<host> ... )</code> sandwich.  This is a [http://www.amk.ca/python/howto/regex/regex.html#SECTION000530000000000000000| Python-specific regex extension] that assigns the contents of the match to the name <host>.  The <host> tag is how you tell fail2ban which host was connecting, so it has to be present in every line of failregex.  If it's not, fail2ban will issue an error message about "No 'host' group".

* As a convenience, you can use the predefined entity <code><HOST></code> in your regexes.  <code><HOST></code> is an alias for <code>(?:::f{4,6}:)?(?P<host>\S+)</code>, which matches either a hostname or an IPv4 address (possibly embedded in an IPv6 address).

* In the action scripts, the tag <code><ip></code> will be replaced by the IP address of the host that was matched in the <code><host></code> tag.

* In order for a log line to match your failregex, it actually has to match in two parts:  the beginning of the line has to match a timestamp pattern or regex, and the remainder of the line has to match your failregex.  If the failregex is anchored with a leading <code>^</code>, then the anchor refers to the start of the remainder of the line, ''after'' the timestamp and intervening whitespace.

* The pattern or regex to match the time stamp is currently not documented, and not available for users to read or set.  See [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491253| Debian bug #491253].  This is a problem if your log has a timestamp format that fail2ban doesn't expect, since it will then fail to match any lines.  Because of this, you should test any new failregex against a sample log line, as in the examples below, to be sure that it will match.  If fail2ban doesn't recognize your log timestamp, then you have two options:  either reconfigure your daemon to log with a timestamp in a more common format, such as in the example log line above; or file a bug report asking to have your timestamp format included.

As an example of the above points, run the following commands in your console and compare the results:

 fail2ban-regex 'Jul 18 12:13:01 [1.2.3.4] authentication failed'     'authentication failed'
 fail2ban-regex 'Jul 18 12:13:01 [1.2.3.4] authentication failed'     '\[<HOST>\] authentication failed'
 fail2ban-regex '18-07-2008 12:13:01 [1.2.3.4] authentication failed' '\[<HOST>\] authentication failed'

The 1st command fails, with a "No 'host' group" error message.  The 2nd command succeeds, and finds the host address 1.2.3.4.  The 3rd command fails.  It doesn't tell you why---it just says "No match"---but clearly it's not able to match the unusual timestamp format---which is ''not'' part of your failregex.

=== Actions ===

The directory ''action.d'' contains different scripts defining actions. The actions are executed at well-defined moments during the execution of {{Fail2ban}}: when starting/stopping a jail, banning/unbanning an host, etc.

== Testing ==

Many things can be tested after configuration but the following commands can help to verify your settings:

 # fail2ban-client -d

will dump the current configuration.

 # fail2ban-regex "line" "failregex"

will test a ''single'' regular expression '''failregex''' (such as given in ''sshd.conf'') with a ''single '' line of your logfile. Don't forget the double quotes around your ''line'' and ''failregex'' definitions.

'''fail2ban-regex''' accepts files too. Thus, it is easier to test and debug your own regular expressions.

 # fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

You can use a combination of both:

 # fail2ban-regex /var/log/auth.log "Failed [-/\w]+ for .* from <HOST>"

== Limitations ==

=== Reaction time ===

First of all, remember that {{Fail2ban}} is a log parser. It cannot do anything before something is written in the log files. Lots of syslog daemons buffer their outputs. This can impact performance of {{Fail2ban}}. Thus, it could be good to disable buffering of your syslog daemon.

It is quite difficult to evaluate the reaction time. {{Fail2ban}} waits 1 second before checking for new logs to be scanned. This should be fine in most cases. However, it is possible to get more login failures than specified by '''maxretry'''.

Here is an excerpt of a ''/var/log/auth.log'':

 Jan 15 15:28:46 homebrou sshd[29778]: Invalid user recruit from 81.74.87.66
 Jan 15 15:28:46 homebrou sshd[29778]: error: Could not get shadow information for NOUSER
 Jan 15 15:28:46 homebrou sshd[29778]: Failed password for invalid user recruit from 81.74.87.66 port 47672 ssh2
 Jan 15 18:33:27 homebrou sshd[2156]: Did not receive identification string from 88.191.23.27
 Jan 15 19:23:37 homebrou sshd[3418]: Invalid user test from 88.191.23.27
 Jan 15 19:23:37 homebrou sshd[3418]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:37 homebrou sshd[3418]: Failed password for invalid user test from 88.191.23.27 port 41017 ssh2
 Jan 15 19:23:38 homebrou sshd[3420]: Invalid user test from 88.191.23.27
 Jan 15 19:23:38 homebrou sshd[3420]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:38 homebrou sshd[3420]: Failed password for invalid user test from 88.191.23.27 port 41096 ssh2
 Jan 15 19:23:38 homebrou sshd[3422]: Invalid user test from 88.191.23.27
 Jan 15 19:23:38 homebrou sshd[3422]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:38 homebrou sshd[3422]: Failed password for invalid user test from 88.191.23.27 port 41162 ssh2
 Jan 15 19:23:38 homebrou sshd[3424]: Invalid user test from 88.191.23.27
 Jan 15 19:23:38 homebrou sshd[3424]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:38 homebrou sshd[3424]: Failed password for invalid user test from 88.191.23.27 port 41209 ssh2
 Jan 15 19:23:39 homebrou sshd[3426]: Invalid user test from 88.191.23.27
 Jan 15 19:23:39 homebrou sshd[3426]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:39 homebrou sshd[3426]: Failed password for invalid user test from 88.191.23.27 port 41267 ssh2
 Jan 15 19:23:39 homebrou sshd[3428]: Invalid user test from 88.191.23.27
 Jan 15 19:23:39 homebrou sshd[3428]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:39 homebrou sshd[3428]: Failed password for invalid user test from 88.191.23.27 port 41323 ssh2
 Jan 15 19:23:40 homebrou sshd[3430]: Invalid user test from 88.191.23.27
 Jan 15 19:23:40 homebrou sshd[3430]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:40 homebrou sshd[3430]: Failed password for invalid user test from 88.191.23.27 port 41376 ssh2
 Jan 15 19:23:40 homebrou sshd[3433]: Invalid user test from 88.191.23.27
 Jan 15 19:23:40 homebrou sshd[3433]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:40 homebrou sshd[3433]: Failed password for invalid user test from 88.191.23.27 port 41433 ssh2
 Jan 15 19:23:41 homebrou sshd[3435]: Invalid user test from 88.191.23.27
 Jan 15 19:23:41 homebrou sshd[3435]: error: Could not get shadow information for NOUSER
 Jan 15 19:23:41 homebrou sshd[3435]: Failed password for invalid user test from 88.191.23.27 port 41484 ssh2
 Jan 16 12:13:43 homebrou sshd[32249]: Did not receive identification string from 209.126.131.150

Looking at ''/var/log/fail2ban.log'' around the corresponding period of time:

 2007-01-15 15:38:47,142 fail2ban.actions: WARNING [ssh-iptables] Unban 81.74.87.66
 2007-01-15 19:23:41,175 fail2ban.actions: WARNING [ssh-iptables] Ban 88.191.23.27
 2007-01-15 19:23:42,373 fail2ban.actions: WARNING [ssh-iptables] 88.191.23.27 already banned
 2007-01-15 19:33:41,508 fail2ban.actions: WARNING [ssh-iptables] Unban 88.191.23.27
 2007-01-16 12:29:50,496 fail2ban.actions: WARNING [ssh-iptables] Ban 209.126.131.150

Thus, you can see that between 19:23:37 and 19:23:41, i.e. within 4 seconds, 9 login (ssh) attempts (instead of only 3) from 88.191.23.27 have been recorded in ''auth.log'' before it has been banned by {{Fail2ban}}.