LowEndBox - Cheap VPS, Hosting and Dedicated Server Deals

How to Stiff-Arm Brutes and Protect Your Server with Fail2Ban

Tags: , , , , Date/Time: July 20, 2021 @ 12:00 am, by raindog308

fail2banBruce force attacks are attempts to guess common passwords by repeatedly trying to login to your server.  SSH is the most common target but FTP, IMAP, POP3, and other password-based systems can be targeted. While you, as perhaps a more sophisticated user, may choose strong passwords, your users may not.  Shared hosting servers with thousands of accounts are particularly vulnerable.  Many “script kiddies” will robotically probe, scan, and attack servers one after another, trying dozens of common passwords to move on.  All they need is a single user who’s chosen “monkey1” or “abc123” and they’re in.

You can defeat these attacks by using fail2ban.  This software watches your log files and if it sees a pattern of login failures, it inserts a firewall rule that blocks all connections from that IP.  Even if the block is temporary, this slows the attacker down from doing hundreds of attempt per minute to perhaps only 3 every 10 minutes.  This is all done automatically, so even when you’re sleeping, fail2ban is guarding your server.

In this tutorial, we’ll show you how to setup and configure fail2ban.

Prerequisite: Postfix (optional)

I’m going to install Postfix, a mail server, so that fail2ban can send me an email whenever an IP is blocked.  If you already have a functioning mail server (specifically, an MTA – Mail  Transfer Agent) on your system, you can skip this step.

On Debian, installing Postfix is as simple as:

apt-get install postfix

You’ll be asked how to configure it and you should probably answer Internet site.  There are tons of configuration possibilities with Postfix but this will get you going.  In this example, I’m using a server named secure.lowend.party:

Installing fail2ban

Once again, Debian makes it easy:

apt-get install fail2ban

Configuring fail2ban

fail2ban’s configuration lives in /etc/fail2ban.  Let’s set up fail2ban to handle simple sshd protection.

In /etc/fail2ban/jaild., create a file called local.conf and populate it as follows:

[DEFAULT]
destemail = "someone@example.com"
sender = "root@secure.lowend.party"
ignoreip = 127.0.0.1/8 1.2.3.4/32
action=%(action_mwl)s

[sshd]
enabled = true
filter = sshd
# port = 2222
logpath = /var/log/auth.log
findtime = 600
maxretry = 3
bantime = 600

Let’s walk through those.

First, you have a DEFAULT section that applies to all fail2ban sections.

  • destemail: Who receives fail2ban alerts
  • sender: Who alerts come from.
  • ignoreip: I’ve listed two IPs here.  The first is the entire /8 block of localhost.  The second is my home IP.  These IPs will never be blocked by fail2ban.  Note that many people’s home IPs change due to DHCP, so keep that in mind.
  • action: in this case I’ve selectd the “mwl” action, which means “mail with log”.  You can define your own actions – take a look at /etc/fail2ban/jail.conf to see other options, or Read The Fine Manual.

Next I’ve defined a section for sshd:

  • enabled: to toggle it on
  • filter: corresponds to a configuration in filter.d.  The config files (over 80 different services are shipped with fail2ban to easily enable) include things like regular expressions to match in logs and other info fail2ban needs to work.
  • I’ve commented out port but if you run with a custom port, define it here
  • logpath: the…you guessed it, it’s the path to the log
  • findtime and maxretry: fail2ban takes action if the number of failed logins exceeds maxretry times in findtime seconds.
  • bantime: how long the ban persists before it’s auto-removed

Once you’ve created the config file, you can check it with the command-line fail2ban client:

fail2ban-client -t
root@secure:/etc/fail2ban/jail.d# fail2ban-client -t
OK: configuration test is successful

fail2ban in Action

I went to another VPS and tried repeatedly to login to this server via ssh, entering the wrong password each time.  On my four attempt, this appeared in secure.lowend.party’s log file (/var/log/auth.log).  The IP has been anonymized:

2020-07-26 13:21:57,623 fail2ban.actions [10814]: NOTICE [sshd] Ban 1.2.3.4

For the next 10 minutes, I was unable to connect to anything on secure.lowend.party.  I couldn’t connect to the SSH port to retry.

On secure.lowend.party, I saw this in the iptables:

Chain f2b-sshd (1 references)
target prot opt source destination
REJECT all -- server.example.com anywhere reject-with icmp-port-unreachable
RETURN all -- anywhere anywhere

And I received this email:

The ban expired after ten minutes, but if I wanted to unban a client before that, I could use this command:

fail2ban-client unban 1.2.3.4

 

I'm Andrew, techno polymath and long-time LowEndTalk community Moderator. My technical interests include all things Unix, perl, python, shell scripting, and relational database systems. I enjoy writing technical articles here on LowEndBox to help people get more out of their VPSes.

1 Comment

  1. Brian:

    I’ve been using fail2ban for a while. It is good stuff.
    |- Currently banned: 6893
    |- Total banned: 9611

    July 20, 2021 @ 12:40 am | Reply

Leave a Reply

Some notes on commenting on LowEndBox:

  • Do not use LowEndBox for support issues. Go to your hosting provider and issue a ticket there. Coming here saying "my VPS is down, what do I do?!" will only have your comments removed.
  • Akismet is used for spam detection. Some comments may be held temporarily for manual approval.
  • Use <pre>...</pre> to quote the output from your terminal/console, or consider using a pastebin service.

Your email address will not be published. Required fields are marked *