Tutorial
How To Protect SSH with fail2ban on Ubuntu 12.04
Not using Ubuntu 12.04?Choose a different version or distribution.
Status: Deprecated
This article covers a version of Ubuntu that is no longer supported. If you are currently operate a server running Ubuntu 12.04, we highly recommend upgrading or migrating to a supported version of Ubuntu:
- Upgrade to Ubuntu 14.04.
- Upgrade from Ubuntu 14.04 to Ubuntu 16.04
- Migrate the server data to a supported version
Reason: Ubuntu 12.04 reached end of life (EOL) on April 28, 2017 and no longer receives security patches or updates. This guide is no longer maintained.
See Instead:
This guide might still be useful as a reference, but may not work on other Ubuntu releases. If available, we strongly recommend using a guide written for the version of Ubuntu you are using. You can use the search functionality at the top of the page to find a more recent version.
About Fail2Ban
Servers do not exist in isolation, and those virtual private servers with only the most basic SSH configuration can be vulnerable to brute force attacks. fail2ban provides a way to automatically protect virtual servers from malicious behavior. The program works by scanning through log files and reacting to offending actions such as repeated failed login attempts.
Step One—Install Fail2Ban
Use apt-get to install Fail2Ban
sudo apt-get install fail2ban
Step Two—Copy the Configuration File
The default fail2ban configuration file is location at /etc/fail2ban/jail.conf. The configuration work should not be done in that file, however, and we should instead make a local copy of it.
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
After the file is copied, you can make all of your changes within the new jail.local file. Many of possible services that may need protection are in the file already. Each is located in its own section, configured and turned off.
Step Three—Configure the Defaults in Jail.Local
Open up the the new fail2ban configuration file:
sudo nano /etc/fail2ban/jail.local
The first section of defaults covers the basic rules that fail2ban will follow. If you want to set up more nuanced protection on your virtual server, you can customize the details in each section.
You can see the default section below.
[DEFAULT]
# "ignoreip" can be an IP address, a CIDR mask or a DNS host
ignoreip = 127.0.0.1/8
bantime = 600
maxretry = 3
# "backend" specifies the backend used to get files modification. Available
# options are "gamin", "polling" and "auto".
# yoh: For some reason Debian shipped python-gamin didn't work as expected
# This issue left ToDo, so polling is default backend for now
backend = auto
#
# Destination email address used solely for the interpolations in
# jail.{conf,local} configuration files.
destemail = root@localhost
Write your personal IP address into the ignoreip line. You can separate each address with a space. IgnoreIP allows you white list certain IP addresses and make sure that they are not locked out. Including your address will guarantee that you do not accidentally ban yourself from your own server.
The next step is to decide on a bantime, the number of seconds that a host would be blocked from the VPS if they are found to be in violation of any of the rules. This is especially useful in the case of bots, that once banned, will simply move on to the next target. The default is set for 10 minutes—you may raise this to an hour (or higher) if you like.
Maxretry is the amount of incorrect login attempts that a host may have before they get banned for the length of the ban time.
You can leave the backend as auto.
Destemail is the email that alerts get sent to. If you have a mail server set up on your droplet, Fail2Ban can email you when it bans an IP address.
Additional Details—Actions
The Actions section is located below the defaults. The beginning looks like this:
# # ACTIONS # # Default banning action (e.g. iptables, iptables-new, # iptables-multiport, shorewall, etc) It is used to define # action_* variables. Can be overridden globally or per # section within jail.local file banaction = iptables-multiport # email action. Since 0.8.1 upstream fail2ban uses sendmail # MTA for the mailing. Change mta configuration parameter to mail # if you want to revert to conventional 'mail'. mta = sendmail # Default protocol protocol = tcp [...]
Banaction describes the steps that fail2ban will take to ban a matching IP address. This is a shorter version of the file extension where the config if is located. The default ban action, "iptables-multiport", can be found at /etc/fail2ban/action.d/iptables-multiport.conf
MTA refers to email program that fail2ban will use to send emails to call attention to a malicious IP.
You can change the protocol from TCP to UDP in this line as well, depending on which one you want fail2ban to monitor.
Step Four (Optional)—Configure the ssh-iptables Section in Jail.Local
The SSH details section is just a little further down in the config, and it is already set up and turned on. Although you should not be required to make any changes within this section, you can find the details about each line below.
[ssh] enabled = true port = ssh filter = sshd logpath = /var/log/auth.log maxretry = 6
Enabled simply refers to the fact that SSH protection is on. You can turn it off with the word "false".
The port designates the port that fail2ban monitors. If you have set up your virtual private server on a non-standard port, change the port to match the one you are using:
eg. port=30000
The filter, set by default to sshd, refers to the config file containing the rules that fail2ban uses to find matches. sshd refers to the /etc/fail2ban/filter.d/sshd.conf.
log path refers to the log location that fail2ban will track.
The max retry line within the SSH section has the same definition as the default option. However, if you have enabled multiple services and want to have specific values for each one, you can set the new max retry amount for SSH here.
Step Five—Restart Fail2Ban
After making any changes to the fail2ban config, always be sure to restart Fail2Ban:
sudo service fail2ban restart
You can see the rules that fail2ban puts in effect within the IP table:
sudo iptables -L
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
author
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Become a contributor for community
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
DigitalOcean Documentation
Full documentation for every DigitalOcean product.
Resources for startups and SMBs
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
The developer cloud
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Get started for free
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.
Goyal,
UFW and iptables-multiport are completely compatible, however UFW will not show you banned IP addresses. You can still manage your basic firewall with UFW.
If you need to see banned IP addresses you have multiple options. iptables --list -n | fgrep DROP or fail2ban-client status ssh
Either will show you currently banned IP addresses. the fail2ban-client will show you the IP addresses it is managing (via bantime limits).
Hope that helps.
After following these instructions I tested fail2ban but it would not ban me after multiple wrong passwords. I need to do this also:
http://www.fail2ban.org/wiki/index.php/Fail2ban:Community_Portal#Count_.22Last_message_repeated_N_times.22_correctly
"It seems Fail2ban undercounts entries from syslog files such as /var/log/syslog and /var/log/auth.log, since it doesn’t seem to be aware that syslog may log “last message repeated N times” instead of the full message. For example, if an ssh attack occurs several times in quick succession, there may be only one entry “Failed password for someuser from 1.2.3.4 port 4307 ssh2” followed by “last message repeated 10 times”.
GNU/Linux distributions rsyslog solution: Tested in Ubuntu 10.04, should also work Centos/RHEL 5.9 or 6.X if rsyslog is used.
1.open /etc/rsyslog.conf 2.find RepeatedMsgReduction and change on to off 3.After that, restart rsyslog and fail2ban"
Like @services, I also tried to lock a new test user out by typing its password wrong quite a few times. My maxretry is 3, and yet after 10 wrong passwords I could still log in if I typed the right one.
Something’s not right about this tutorial
How do I know if it’s actually working? How can I test this out?
Apologies to those unfamiliar with aliases. The next three aliases will tell you where the file is. After edits to the alias file it must be reloaded too. The next two aliases make that quite easy. Just paste these aliases on your command line to use them in your current session. Then add them to your bash aliases file so they will always be available each time you log on.
The br alias ‘bash reload’ looks a bit over complicated below, all it is doing is “source $HOME/.bashrc” with the username reloading the file shown in red. Seeing the username makes a difference for me when I traverse the server as various users.
Thank you for the article Etel. I’ve added your ideas to my .bash_aliases file for easy reuse. Copying the .bash_aliases file to new droplets makes the tasks quite easy. Thanks again for the article!
Since the aliases can be easy to forget the next alias allows ‘alias listing’ via a quick grep of all aliases in the .bash_aliases file. Very handy.
hence ‘ag fail2’ will give me a list of all fail2ban aliases. quick and easy. And so will ‘ag f2b’
It’s critical to protect SSH. Just look at all the login attempts on my server! https://www.hexhound.com/the-top-15-account-names-used-for-malicious-ssh-login-attempts/ This is on a server that only accepts private keys and not password logins, AND it has a warning banner. Many of those attempts are from foreign IPs - China, Russia, and Mexico have all appeared frequently in my logs.
This comment has been deleted
This comment has been deleted
Thanks mucho Etel. Great simple help. My cloud server lately has been the target of pesky brute forced ssh, was pissing me off. And then I decided, ok dude, no more laziness, fail2ban. Then I find your article and “smoothness” to success. Thank you very much.
I think it’s totally awesome that thee are of the female gender. We need more of you in technology. After all, it was females who gave us the ability to figure out the chemical makeup of far off planets. It will likely be a woman who saves us from ourselves too.
Again, thx mucho grande.
Oh, by the way, 2 seconds after fail2ban restart, thar be a pest from China, blocked after 3 attempts… Ha, take that you pesky lamer (image of my middle finger cranking up in that goons direction… wherever that is :-).
Oh, one last thing that helps with ssh. /etc/ssh/sshd_config
AllowUsers user1 user2 … userN
That helps alot with ssh too. Sometimes also changing from port 22 to some other port is cool too (just remember if you have reverse-tunnels to reconfigure/reset them to that new port).