Password brute force and fail2ban

Not running Starting usually ~20 s

Step 6 of 7 · lab · 30 min

The brute force goes on

Someone on the neighbouring machine keeps trying to log in to the server's SSH. fail2ban is installed and running, a colleague has even tuned it, and still there is no ban. Find out why and make sure the attacker gets banned and the administrator never does.

Situation

Someone on node2 keeps trying to log in to node1's SSH: every twenty seconds there are new attempts under made-up user names. They show up in the login journal: sudo journalctl -u ssh -f. node1 has fail2ban for exactly this: the service is enabled and running, the sshd jail is started, and last week a colleague went over its settings once more. node2 has still not been banned.

The administrator's laptop admin-pc (its address: getent hosts admin-pc) logs in to node1 every day and sometimes gets the login wrong. fail2ban must not ban that address.

node1 is your terminal; reach node2 with ssh node2. sudo works without a password on both machines.

Task

node2's address is banned by the sshd jail: sudo fail2ban-client status sshd lists it, and node1's SSH is closed to node2.
Any other address on the network gets banned by itself after five failed SSH logins within ten minutes, with no manual commands.
The jail skips failed logins from admin-pc, and that address does not get banned.
The settings are saved in the /etc/fail2ban files: after sudo systemctl restart fail2ban the jail works the same. The fail2ban service is enabled.

The lab has no internet access, only the network between node1 and node2. Everything you need is installed on both machines. There is no need to stop the attacker on node2: the task is in fail2ban on node1.

Lab · on your own

No commands are given in this lab: type them in the terminal yourself. Goals are checked on the machine after every command.

Goals

0 of 4

node2's address is banned by the sshd jail — node1's SSH is closed to node2 — not done yet
A new address on the network gets banned by itself after five failed SSH logins — not done yet
The jail skips failed logins from admin-pc and does not ban it — not done yet
The settings are saved in /etc/fail2ban — after fail2ban restarts the jail works the same; the service is enabled — not done yet

Ctrl+Enter

Starts the machine node1 · Ubuntu 24.04

The machine is starting

Hints

0 of 3

Report a problem

Lab goals

0 of 4

node2's address is banned by the sshd jail — node1's SSH is closed to node2 — not done yet
A new address on the network gets banned by itself after five failed SSH logins — not done yet
The jail skips failed logins from admin-pc and does not ban it — not done yet
The settings are saved in /etc/fail2ban — after fail2ban restarts the jail works the same; the service is enabled — not done yet

node1 Ubuntu 24.04

Lab goals

0 of 4

node2's address is banned by the sshd jail — node1's SSH is closed to node2 — not done yet
A new address on the network gets banned by itself after five failed SSH logins — not done yet
The jail skips failed logins from admin-pc and does not ban it — not done yet
The settings are saved in /etc/fail2ban — after fail2ban restarts the jail works the same; the service is enabled — not done yet

Security · picked for this lab

fail2ban

Cheat sheet

$_ — insert into the terminal

sudo fail2ban-client status jails
sudo fail2ban-client status sshd banned IPs
sudo fail2ban-client set sshd unbanip 1.2.3.4 unban
sudo fail2ban-regex /var/log/auth.log sshd test a filter
jail.local: bantime, findtime, maxretry, ignoreip, backend

Setup

Don't edit jail.conf — create jail.local (it survives package updates):

ini

# /etc/fail2ban/jail.local
[DEFAULT]
bantime  = 1h          # how long to ban for (accepts 10m, 1h, 1d)
findtime = 10m         # the window over which attempts are counted
maxretry = 5           # how many failures before a ban
ignoreip = 127.0.0.1/8 10.0.0.0/24    # allowlist (your own networks!)
backend  = systemd     # on Ubuntu, SSH logs are often in journald

[sshd]
enabled = true

[recidive]             # ban repeat offenders for a long time
enabled  = true
bantime  = 1w
findtime = 1d
maxretry = 5

bash

sudo systemctl restart fail2ban

Your own jail/filter

For your own service: a filter (a regex with an <HOST> group) plus a jail:

ini

# /etc/fail2ban/filter.d/myapp.conf
[Definition]
failregex = ^.*authentication failed from <HOST>.*$

# /etc/fail2ban/jail.local
[myapp]
enabled  = true
logpath  = /var/log/myapp/access.log
maxretry = 4

Test the regex before enabling it: fail2ban-regex <log> <filter> (shows how many matches it caught).

File order

fail2ban reads jail settings in order, and the last value wins:

jail.conf — from the package, do not edit;
jail.d/*.conf — alphabetically, defaults-debian.conf among them;
jail.local;
jail.d/*.local — alphabetically.

maxretry = 6 in jail.d/aa.conf, 4 in jail.local and 3 in jail.d/zz.local give 3. fail2ban-client -d prints the result for a jail:

text

student@ubuntu:~$ sudo fail2ban-client -d | grep "'sshd', '"
['set', 'sshd', 'maxretry', 3]
['set', 'sshd', 'findtime', '10m']
['set', 'sshd', 'bantime', '10m']
['set', 'sshd', 'addignoreip', '127.0.0.1/8', '192.0.2.20']

An error in any file keeps the service from starting — fail2ban-client -d shows it too.

What Ubuntu sets

On the lab machine the fail2ban service is off. The package ships jail.d/defaults-debian.conf:

ini

[DEFAULT]
banaction = nftables
banaction_allports = nftables[type=allports]
backend = systemd

[sshd]
enabled = true

backend = systemd means the jail reads the systemd journal and needs no logpath. fail2ban-client status sshd shows what it looks for: Journal matches: _SYSTEMD_UNIT=sshd.service + _COMM=sshd (+ means "or"; on Ubuntu 24.04 the service is called ssh.service, and the lines are found by _COMM=sshd).

A ban is an address in a set of the inet f2b-table table, and the rule answers with reject:

text

table inet f2b-table {
	set addr-set-sshd {
		type ipv4_addr
		elements = { 192.0.2.20 }
	}
	chain f2b-chain {
		type filter hook input priority filter - 1; policy accept;
		tcp dport 22 ip saddr @addr-set-sshd reject with icmp port-unreachable
	}
}

The banned address sees port 22 as filtered (see nmap); after unbanip it is open again.

Management

bash

sudo fail2ban-client status               # all jails
sudo fail2ban-client status sshd          # who's banned, counters
sudo fail2ban-client set sshd unbanip 1.2.3.4   # unban
sudo fail2ban-client set sshd banip 1.2.3.4     # ban manually
sudo fail2ban-client get sshd bantime     # a parameter's current value
sudo fail2ban-client reload               # reload the config
sudo fail2ban-regex /var/log/auth.log sshd  # test a filter
sudo tail -f /var/log/fail2ban.log        # decisions: Found, Ban

I banned myself

From the console (hypervisor/serial) or from an allowed IP: fail2ban-client set sshd unbanip <your IP>. Add your network to ignoreip.

The jail isn't banning anyone

Is enabled = true? Does fail2ban-client status show the jail?
Is logpath correct and the filter matching your log format? On Ubuntu, SSH is often in journald — you need backend = systemd.
Test the filter: does fail2ban-regex on the real log catch the lines?

The address is not banned: Ignore by ip

The address is in ignoreip: failures from it are not counted, Total failed stays 0, and /var/log/fail2ban.log writes for every journal line:

text

fail2ban.filter [3147]: INFO    [sshd] Ignore 192.0.2.20 by ip

Without the address in ignoreip the same attempts give Found and a ban:

text

fail2ban.filter  [3147]: INFO    [sshd] Found 192.0.2.20
  - 2026-10-21 05:50:02
fail2ban.actions [3147]: NOTICE  [sshd] Ban 192.0.2.20

The administrator's network belongs in ignoreip, the attacker's address does not. After an edit, run sudo fail2ban-client reload.

It's banning, but the attack continues from other IPs

That's a distributed brute force. Enable recidive, tighten maxretry/findtime, consider a geo/ASN block at the firewall level (see whois for CIDR ranges).

Not sure whether it's working at all

fail2ban-client status sshd → Total/Currently failed and banned. The Found, Ban and Unban lines are in /var/log/fail2ban.log.

Password brute force and fail2ban

Situation

Task

Signing in is needed to start the machine

Management

I banned myself

The jail isn't banning anyone

The address is not banned: Ignore by ip

It's banning, but the attack continues from other IPs

Not sure whether it's working at all