Setting up Fail2ban: block brute-force attacks automatically

After a few days on the internet, take a look at journalctl -u ssh: hundreds of login attempts from foreign IPs, one every second. As long as your SSH is switched to key login, none of them gets in – but it clutters the log and eats resources. Fail2ban reads along with these logs and bans automatically whoever tries too often without success.

What are we building?

By the end, Fail2ban 1.1 on your Debian 13 monitors the SSH logins and, after too many failed attempts, bans the attacking IP for a defined time – via a firewall rule. Your own IP is on a whitelist so this never hits you. You can view bans, set them manually and lift them again.

Prerequisites

• A hardened server (key login) with an active firewall
• Your own public IP – find it e.g. via wieistmeineip.de or curl -s ifconfig.me from your local machine

Step by step

Before we configure, three terms that explain the whole tool:

• Filter – a pattern that detects a “failed login” in the log (for SSH, Fail2ban brings this ready-made).
• Jail – connects a filter with a log source and the rules “how often in what time frame”. The sshd jail monitors the SSH logins.
• Action – what happens when it’s exceeded: by default a firewall rule that blocks the IP for bantime.

In short: filter detects failed attempts → jail counts them → action bans. Everything you configure below is one of these three knobs.

Step 1: Install Fail2ban

sudo apt update
sudo apt install -y fail2ban

Check the version:

fail2ban-client --version

Fail2Ban v1.1.0

Step 2: Your own configuration in jail.local

Create the file:

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
# How long the ban lasts
bantime = 1h
# Time window in which the failed attempts count
findtime = 10m
# This many failed attempts are allowed, then a ban
maxretry = 5
# Your own IP(s) – will NEVER be banned
ignoreip = 127.0.0.1/8 ::1 YOUR_OWN_IP

[sshd]
enabled = true

Line by line:

• bantime = 1h – ban duration. For stubborn cases, see the escalation in step 5.
• findtime + maxretry – “5 failed attempts within 10 minutes → ban”.
• ignoreip – the most important line: enter your own IP here so you don’t lock yourself out. If you have a changing IP at home, better use access via a fixed point (a VPN later) instead of a broad allowance.
• [sshd] enabled = true – activates the SSH jail. On Debian it is already on via defaults-debian.conf; having it in your own file does no harm and makes visible what is running.

Step 3: Apply the configuration

First check that the file is syntactically correct – that saves you a service that won’t come back up after the reload:

sudo fail2ban-client -t

OK: configuration test is successful

Now apply the new configuration:

sudo systemctl reload fail2ban

The reload is the decisive step. The service has been running since installation – a systemctl start (or enable --now) does nothing at all on an already running service, your jail.local would stay ignored and Debian’s defaults would still apply. So after every change to jail.local, run reload again.

That Fail2ban comes back on its own after a reboot has already been set up by the package – checking costs nothing:

systemctl is-enabled fail2ban

enabled

If this says disabled, catch up with sudo systemctl enable --now fail2ban. And a look at the service itself:

sudo systemctl status fail2ban

You should see active (running).

Step 4: Check the status

This is how you see which jails are active:

sudo fail2ban-client status

Status
|- Number of jail:	1
`- Jail list:	sshd

And the details of the SSH jail:

sudo fail2ban-client status sshd

Status for the jail: sshd
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	0
|  `- Journal matches:	_SYSTEMD_UNIT=ssh.service + _COMM=sshd
`- Actions
   |- Currently banned:	0
   |- Total banned:	0
   `- Banned IP list:

The Journal matches line confirms that Fail2ban reads the systemd journal. Currently banned rises as soon as someone gets it wrong too often – and it adds up: on our test server, Fail2ban counted 9,494 failed attempts and 481 bans over eleven days of runtime – around 860 login attempts and 44 bans per day, without us having to do anything for it.

To see whether your values really apply and not Debian’s defaults any more, ask directly:

sudo fail2ban-client get sshd bantime

3600

3600 seconds is the hour from your jail.local. If it still says 600, the reload from step 3 is missing – Fail2ban then keeps running with the defaults.

Step 5: Manage bans – and escalate them

Manually unban an IP (e.g. when a colleague mistyped):

sudo fail2ban-client set sshd unbanip 203.0.113.45

Ban an IP immediately:

sudo fail2ban-client set sshd banip 203.0.113.45

Both commands answer with the number of IPs they actually touched:

1

If a 0 comes back, nothing happened – when unbanning, that usually means the IP wasn’t banned at all (a typo in the address).

Against especially stubborn attackers, an escalating ban time pays off: whoever comes back is banned for longer. Add to the [DEFAULT] block:

bantime.increment = true
bantime.maxtime = 1w

With that, Fail2ban doubles the ban time each time the same IP reoffends – up to a maximum of one week. After the change, sudo systemctl reload fail2ban. That the escalation is really active is confirmed – as in step 4 – by a direct query:

sudo fail2ban-client get sshd bantime.increment

True

When things go wrong

Maintenance & backups

• Keep an eye on bans: sudo fail2ban-client status sshd shows at any time how many IPs are currently banned. The history is not in the journal but in a file of its own – per logtarget in /etc/fail2ban/fail2ban.conf, Fail2ban logs to /var/log/fail2ban.log:

  Terminal

  sudo grep -E "Ban|Unban" /var/log/fail2ban.log | tail -5

  Ausgabe

  2026-08-16 01:36:52,583 fail2ban.actions        [326875]: NOTICE  [sshd] Ban 203.0.113.45

  journalctl -u fail2ban, by contrast, only shows the service’s start, reloads and errors.

• More jails: as soon as services with their own login are added (e.g. a web app), you can activate matching jails – following the same pattern as [sshd].

• Back up jail.local: your configuration is quickly restored but belongs in the backup of your server configuration.

• Next step CrowdSec: Fail2ban protects your host based on your logs. The modern successor CrowdSec adds collaborative intrusion prevention (shared block lists) to this and evaluates the access logs of your reverse proxy – worthwhile as soon as web apps come into play. To get started, Fail2ban is exactly right.

With that, the security foundation is complete: key login, two firewall layers (UFW + netcup firewall), automatic updates and active brute-force protection. Your server is now not just set up, but solidly secured.