Linux Labs

Server security / Stage 5 of 10

Password brute force and fail2ban

Not running Starting usually ~20 s
Leave the lesson

Step 1 of 7 · on a machine · 6 min

The brute force is on, no bans

What you will learn

  • Read a jail's state with fail2ban-client status and understand the Total failed, Banned IP list, Journal matches lines.
  • Set a jail's record source with backend = systemd and journalmatch, and the parameters in jail.local.
  • Verify a ban and find the ban rule in nftables (nft list ruleset, the f2b-table table).

A networked server is constantly tested for weakness: someone guesses SSH passwords, login after login. fail2ban is installed for exactly this — it is meant to catch such addresses and ban them.

A password brute force from the neighbouring address 192.0.2.20 is hitting the lab sshd (the lab-sshd service, port 2222), and fail2ban is running. Look at whom it has banned and what is in the service log meanwhile.

Exercise · look

See whom fail2ban banned

A password brute force from the neighbouring address 192.0.2.20 is hitting the lab sshd (the lab-sshd service, port 2222), and fail2ban is running. Look at the sshd jail status and the latest refusals in the service log.

First, predict

fail2ban is running, and the lab-sshd journal shows a brute force. What will the Banned IP list line hold?

Now start the exercise, run the command and compare your prediction with the output.

Sign in and start The machine is available after signing in
Check yourself 1 question

The journal shows a brute force, yet the jail counted 0 attempts and banned nobody. Why?

  • The service is up — systemctl is-active fail2ban says active. It just reads the wrong service's journal.

  • ignoreip is not set here, and it would keep the address out of bans, not zero the counter: Total failed is 0 too — the jail saw no attempts at all.

The jail read the wrong service's journal, so it saw no attempts.

Ubuntu 24.04
Loading…