Free to read – no sign-up

UFW + fail2ban

You set up a basic server firewall with UFW (default deny + whitelist) and protect SSH against brute-force attempts using fail2ban. 6 tasks, about 55 minutes.

Duration: 55 minLevel: BeginnerExercises: 6

Switch on firewall and arm fail2ban

What is a firewall — and what is fail2ban?

This module combines two protection layers for a Linux server:

UFW (Uncomplicated Firewall) is an easy-to-use firewall. Based on fixed rules it decides which ports are reachable from outside. A firewall is static: "port allowed or not".
fail2ban is an intrusion prevention system (IPS). It continuously reads the log files and automatically blocks IP addresses that behave suspiciously (e.g. many failed SSH logins). fail2ban is dynamic: "reacts to behaviour".

The two complement each other: the firewall provides the baseline, fail2ban fends off active attackers.

The default-deny principle

A secure firewall blocks everything by default and then explicitly allows only what is needed (default-deny + whitelist). The opposite — allow everything, block individuals — is insecure.

Your goal in this lesson

You set up UFW with default-deny, allow SSH, enable the firewall, start fail2ban, protect the SSH service with a jail, and prove the protection with a controlled attack test.

⚠️ Order matters: allow SSH first, then enable the firewall — otherwise you lock yourself out on a real server. On this practice VM it is harmless.

Exercises

1. Switch on default-deny
Concept: default policy. The default policy defines what happens to traffic with no matching rule. The safe choice: deny everything incoming, allow outgoing. Outgoing must stay allowed, otherwise the server can no longer do DNS lookups or updates.

Set the default policy:
```
sudo ufw default deny incoming
sudo ufw default allow outgoing
```
Check: sudo ufw status verbose shows deny (incoming) and allow (outgoing).
2. Allow SSH port 22
Concept: opening a port. Before you arm the firewall, you must explicitly allow SSH (port 22) — otherwise the firewall cuts your own connection in the next step.

Allow TCP port 22:
```
sudo ufw allow 22/tcp
```
⚠️ If you skip this and enable the firewall anyway, you lock yourself out for the rest of the session on a real server. On the lab VM the validator has its own access — you do not.

Check: sudo ufw status lists a rule for 22/tcp.
3. Enable UFW
Concept: arming the firewall. Only with ufw enable do the default policy and rules actually become active — before that they are merely prepared.

Enable the firewall:
```
sudo ufw --force enable
```
--force skips the interactive prompt (needed in the lab). Verify beforehand with sudo ufw status that port 22 is allowed.

Check: sudo ufw status reports Status: active.
4. Start fail2ban service
Concept: a service. fail2ban runs as a background service. A service must be started (running now) and enabled (starts automatically at boot). enable --now does both in one step.

Start and enable fail2ban:
```
sudo systemctl enable --now fail2ban
```
Check: systemctl is-active fail2ban reports active.
5. Enable sshd jail
Concept: a jail. A jail tells fail2ban which log file to watch and when to ban. The [sshd] jail observes SSH logins: too many failed attempts from one IP → that IP is temporarily banned.

Create /etc/fail2ban/jail.local (sudo nano /etc/fail2ban/jail.local) with:
```
[sshd]
enabled = true
```
Then reload fail2ban:
```
sudo systemctl reload fail2ban
```
⚠️ Do not change the whitelist in /etc/fail2ban/jail.d/00-validator-whitelist.conf — otherwise you lock out the platform validator.

Check: sudo fail2ban-client status sshd works (the jail is active).
6. Run brute-force test
Concept: verify, don't trust. "Looks done but isn't" is the worst trap in IT security. Instead of just looking at the config, you test live that fail2ban really bans.

Run the built-in, purely defensive brute-force simulator (it only attacks localhost — no real target), then check the jail status:
```
sudo /usr/local/bin/lab-bruteforce-simulator
sudo fail2ban-client status sshd
```
In the output Total banned must be at least 1 — fail2ban has banned the simulated attacker.

Check: fail2ban-client status sshd shows at least one banned IP (Total banned: 1 or more).

Now practice it yourself

Reading is good – doing is better. Start this course on a real Linux VM, right in your browser. A free account is all it takes.

Start for free

Switch on firewall and arm fail2ban

What is a firewall — and what is fail2ban?

The default-deny principle

Your goal in this lesson

Exercises

1. Switch on default-deny

2. Allow SSH port 22

3. Enable UFW

4. Start fail2ban service

5. Enable sshd jail

6. Run brute-force test

Now practice it yourself