Using Fail2Ban to prevent Brute Force Attacks

Sat, Jan 31, 2009 (Linux, Servers)

lock screen Has your SOHO server been seeing a lot of failed ssh attempts from ipaddresses unknown to you? If so, you might be suffering from a brute force attack. These types of attack attempt to break into your box by trying to guess usernames and passwords. They are typically run on zombified computers from all over the world. What can you do about it you ask? Well, fortunately there are programs out there that read failed authentication attempts and modify your firewall to ignore requests from those locations. One such nifty application is called Fail2Ban. I’m going to give you a quick run through on how to setup Fail2Ban to protect against brute force attacks on your Ubuntu ssh server.

To install, you can grab the source code, or use apt:

~$ sudo apt-get install fail2ban

Next we need to modify the config files to suit our needs a little better. Go into your /etc/fail2ban folder and make a copy of the jail.conf. Name it jail.local:

~$ cd /etc/fail2ban
~$ sudo cp jail.conf jail.local

There are a couple of things I want to change from the default settings. The first would be increasing the bantime from 10 minutes to an hour. Then I want to change the max number of tries to 3. This will go for all services that are currently protected by fail2ban. So, lets go ahead and edit the [Default] section of the jail.local that we just copied to look like this:

[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1
bantime  = 3600
maxretry = 3

Now lets give it a go! Save the file, and lets restart the fail2ban process.

~$ sudo /etc/init.d/fail2ban restart

For the sake of the article I’ve tested the setup, and you can see what I’ve found. In the top screenshot below I tried logging into my local ssh server, and in the bottom screenshot you’ll see the fail2ban.log and auth.log’s tailed output from the SSH server.

Bad ssh client! fail2ban.log and auth.log on ssh server

Normally, I don’t think a box on my network is going to fail authentication a bunch of times, or, rather, I don’t want to ban any boxes on my network.  What do we do? If you go back into the /etc/fail2ban/jail.conf file, you should notice the ignoreip option. You can modify this file again to ignore all bans for a 192.168.0.x IP by setting this option:

[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1 192.168.0.0/24
bantime  = 3600
maxretry = 3

Save the file, and restart the fail2ban process again, and you are in business. This should keep script kiddies and brute force attacks away. Happy Hacking!

Share This on Your Favorite Social Network:
  • Facebook
  • MySpace
  • Twitter
  • Digg
  • StumbleUpon
  • LinkedIn
  • Reddit
  • FriendFeed
  • Tumblr
  • Suggest to Techmeme via Twitter
  • Technorati
  • Mixx
  • Propeller
  • Fark
  • Slashdot
  • del.icio.us
  • Google Bookmarks
  • Yahoo! Buzz
  • Print
, , ,

This post was written by:

Ray Gomez - who has written 46 posts on kallasoft.

Ray, a Linux and Unix nut, spends a majority of his daily ritual programming and testing for Big Blue. In his free time he manages to tweak the currently running thinkpad+KDE4 (WHOA) setup, read, and he occasionally gets out of the fluorescent lights to play roller hockey.

Contact the author

2 Responses to “Using Fail2Ban to prevent Brute Force Attacks”

  1. Elvis Says:

    Hi Ray, when setting the “ignore” part of your howto, you said to modify the jail.conf. Does it matter if you add that to the jail.local or jail.conf? I am just wondering why you need the two files and what significance they each have.

    Regards

    Reply

  2. b0ul Says:

    # This file was composed for Debian systems from the original one
    # provided now under /usr/share/doc/fail2ban/examples/jail.conf
    # for additional examples.
    #
    # To avoid merges during upgrades DO NOT MODIFY THIS FILE
    # and rather provide your changes in /etc/fail2ban/jail.local
    #

    -from jail.conf

    Reply

Leave a Reply