HOWTO fail2ban 0.7.x

From Fail2ban
Revision as of 01:07, 18 August 2006 by Lostcontrol (Talk | contribs) (Updated howto to reflect latest changes)

Jump to: navigation, search

HowTo test the new development branch

For quite a long time now, a new branch is in development. This is almost a complete rewrite with a lot of new features and a better design. There is still a lot of work but this new branch is already functional and can be tested.

This HowTo will not delete or modify your current Fail2ban setup. You only have to turn off any previous version during the tests.

Getting the sources

There is two ways of getting the sources:

There is no official release of the 0.7 branch (trunk) yet. The best way for getting the sources is Subversion. The instructions are available here but here is a quick reminder:

svn co https://svn.sourceforge.net/svnroot/fail2ban/trunk fail2ban-trunk

The sources are now available in the directory called fail2ban-trunk. If you decide to use the tarball, simply run:

tar xvfj fail2ban-nightly.tar.bz2

You should have a directory called fail2ban-0.7.0-SVN.

Change your current directory to fail2ban-trunk or fail2ban-0.7.0-SVN.

Setup

The configuration folder should look like this:

config/
|-- action.d
|   |-- dummy.conf
|   |-- foo.conf
|   |-- hostsdeny.conf
|   |-- iptables.conf
|   |-- mail-whois.conf
|   `-- mail.conf
|-- fail2ban.conf
|-- filter.d
|   |-- apache-auth.conf
|   |-- sshd.conf
|   `-- vsftpd.conf
`-- jail.conf

The most important file is probably jail.conf. It contains the definition of your jails. A jails is the combination of one filter and one or several actions. More information about the jail concept are available here. You can override configuration files using a .local file. Per example, config/fail2ban.local overrides the settings in config/fail2ban.conf.

For this tutorial, we will setup a configuration similar to what previous versions do: parse SSH logs, ban hosts using iptables and send notification e-mails.

SSH filter setup

The default configuration for the SSH filter should not require too much changes. However, you could have to change the path of the logs file. Create config/filter.d/sshd.local and add the following content.

[Definition]

logpath=/var/log/pwdfail/current

Thus, we do not have to change config/filter.d/sshd.conf. This is quite useful when upgrading or if you want to save your own changes. Adapt the value of logpath to point to your SSH daemon log file.

Iptables action setup

The Iptables script should be fine. However, some settings have to be set in config/jail.conf.

Jail setup

We are now able to define our first jail. Actually, config/jail.conf is a bit messy... I suggest your erase all the sections in this file and add this.

[ssh]

enabled = true
filter = sshd
action = iptables[name=ssh,port=22,protocol=tcp]
         mail[name=SSH,dest=toto@titi.com]
maxretry = 3

The filter option is the name of a file in config/filter.d without the .conf extension. The action field is more interesting. Here, we set as first action the iptables script. Action script can have parameters. Have a look at config/action.d/iptables.conf. Please, be aware that no spaces are allowed in the parameters field. This will be fixed in the future. We define a second action. It will send a notification e-mail. Just replace the dest parameter with your e-mail address. Be aware that the mail script uses the mail command of the system. Ensure this command works on your box.

Client/Server

Fail2ban is now composed of two parts: a server and a client. The server listens on a socket and waits for commands. It monitors log files and executes actions. The client part is used to communicate with the server. It converts the config/ settings into commands which are sent to the server through a Unix socket.

For this tutorial, you will need root access. This is not necessary for testing but you will need it to access iptables on most systems.

We will first test whether the configuration directory can be parse correctly. Runs the following command:

# ./fail2ban-client -d

Check that no exceptions are triggered. Here you should get a lot of output like:

['set', 'loglevel', 3]
['set', 'logtarget', 'STDERR']
['add', 'ssh']
['set', 'ssh', 'bantime', 600]
['set', 'ssh', 'logpath', '/var/log/pwdfail/current']
['set', 'ssh', 'maxretry', 3]

These are the commands which will be sent to the server. You could send them manually with:

# ./fail2ban-client set loglevel 3

But it would be a bit annoying. The whole configuration is automatically sent to the server on startup. So, it is time to start it:

# ./fail2ban-client start

The server should now start monitoring the log file. Look at the server terminal. If you do not see anything, output are maybe redirected into the log file /var/log/fail2ban.log. You can change this in config/fail2ban.conf or, better, create your own config/fail2ban.local. You can also change this in realtime with:

# ./fail2ban-client set logtarget STDERR

All of this without restarting the server which is carefully watching your log files during the operation. Mmmmhhh... Three retries are a bit too agressive? Change the setting with:

# ./fail2ban-client set ssh maxretry 5

You do not need to restart anything. The changes are taken into account directly. Maybe you saw the RRDTool plot at the end of the Screenshots page. The information for this graph come from the following command:

# ./fail2ban-client status ssh
fail2ban.client : INFO   OK : [('filter', [('Currently failed', 0), ('Total fail
ed', 17)]), ('action', [('Currently banned', 0), ('Total banned', 2)])]

The output formatting of the client application in not yet really pretty. There is still lots of work in this area (any help is welcome).

You can stop the server with the following command:

# ./fail2ban-client stop

Warning

There is still a lot of work to do. Here are some known issues.

  • A lot of exceptions are not handled yet.


If you want to help with Python programming, documentation, etc, do not hesitate to contact me.