I Simulated an SSH Brute-Force Attack on My Ubuntu Server — Here’s How Fail2Ban Stopped It

Building a simple attack lab to understand how Fail2Ban detects and blocks repeated SSH login attempts.

Photo by Esther Jiao on Unsplash

This time, I wanted to simulate the implementation of one of the most common SSH protection mechanisms: Fail2Ban.

I briefly mentioned Fail2Ban in one of my previous articles [ACCESS IT], but I don’t like stopping at theory. I prefer seeing things in action. So instead of just talking about it, let’s put it to the test.

Setup Lab

For this experiment, I did not use the same lab environment as my penetration testing setup [ACCESS IT]. Instead, I built a simple Ubuntu Server environment and used my own computer as the attacker.

To make administration easier, I accessed the server through SSH. At this point, the server did not have Fail2Ban installed or configured.

Attacker tool

To make this article more interesting, I created a small tool to support the demonstration. In short, this tool performs a basic SSH brute-force attack using a custom wordlist.

[embed]GitHub - theDreamer911/ssh-brute-force-attack: Just a simple SSH Brute Force Attack Just a simple SSH Brute Force Attack. Contribute to theDreamer911/ssh-brute-force-attack development by creating an…github.com

To launch the attack, you only need to modify the target IP address and username according to your environment.

Since this is only a controlled simulation, I also added the correct password to the wordlist.txt file.

Note: We are not learning how to brute-force systems. We are learning how defensive mechanisms work. Before understanding how to defend against an attack, it helps to understand how that attack happens in the first place.

Once everything was configured, I executed attack.py. As expected, the attack was successful and the tool eventually discovered the user’s password.

Without Fail2Ban, I could repeatedly attempt different passwords without any restrictions. Since there was no rate limiting or automatic blocking mechanism, the attack continued until the correct password was found.

This demonstrates why password-based SSH authentication can be dangerous when additional protections are not in place.

With that background established, let’s implement one of the most popular SSH protection mechanisms against brute-force attacks: Fail2Ban.

Installing fail2ban

As always, let’s start by updating the system packages.

sudo apt update

Next, install Fail2Ban using the following command.

sudo apt install fail2ban -y

Once the installation is complete, verify that the service is running.

sudo systemctl status fail2ban

If the output shows:

active (running)

then Fail2Ban has been installed successfully.

Configuration

Fail2Ban stores its default configuration in jail.conf. For production environments, it is recommended to create a separate jail.local file instead of modifying the default configuration directly.

You can create the file by copying the default configuration.

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Alternatively, for this demonstration, you can create a new file from scratch.

sudo nano /etc/fail2ban/jail.local

In my case, I skipped the copy step and created a new file directly. The following minimal configuration is sufficient for SSH protection.

[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
backend = systemd

This configuration means:

• An IP address will be banned for 1 hour.
• Failed login attempts are counted within a 10-minute window.
• After 5 failed attempts, the source IP will be banned automatically.

Save the file and restart the Fail2Ban service.

sudo systemctl restart fail2ban

Then verify its status.

sudo systemctl status fail2ban

If everything is configured correctly, the service should be running normally.

Verifying the Configuration

Next, check the Fail2Ban client status:

sudo fail2ban-client status

The expected output should look similar to this:

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

For more detailed information about the SSH jail.

sudo fail2ban-client status sshd

From this output, we can see the active filters, the number of failed attempts, and any IP addresses that have been banned.

Once Fail2Ban detects suspicious activity, it automatically blocks the offending IP address.

Re-Simulating the Attack

Now that Fail2Ban is configured, let’s run the attack again. This time, the result is very different.

Instead of eventually discovering the correct password, the attack is interrupted after several failed login attempts.

Even though we already know that the correct password is admin123, we can no longer continue testing passwords because our IP address has been detected as malicious and automatically blocked.

The SSH connection is terminated before the script reaches the correct password in the wordlist.

This is exactly the behavior we want to see.

Verifying the Ban

To confirm that the IP address has been blocked, check the SSH jail status again:

sudo fail2ban-client status sshd

Example output:

Status for the jail: sshd
|- Currently banned: 1
`- Banned IP list: 192.168.1.15

As shown above, the attacker’s IP address has been banned successfully.

No matter how persistent we are, we will not be able to establish another SSH connection from that IP address until the ban expires or is removed manually.

Fortunately, every security control should also have a recovery process.

Let’s look at how to remove a ban safely.

Unbanning an IP Address

The easiest way to remove a banned IP address is by using the following command.

sudo fail2ban-client set sshd unbanip YOUR_IP

For example, in my lab environment, the attacking machine used the IP address 192.168.56.1

sudo fail2ban-client set sshd unbanip 192.168.56.1

Once the IP address is removed from the ban list, SSH access is restored immediately.

You can then reconnect to the server normally.

Simple, right?

Conclusion

Fail2Ban is one of the easiest and most effective ways to strengthen SSH security on an Ubuntu server.

With only a few configuration steps, it can automatically detect and block brute-force attacks, significantly reducing exposure to common automated threats.

This experiment clearly demonstrates the difference between an unprotected SSH service and one protected by Fail2Ban.

While Fail2Ban is not a replacement for strong authentication practices such as SSH keys, it provides an additional layer of defense that every internet-facing Linux server should have.

Whether you are running a homelab, a VPS, or production infrastructure, Fail2Ban deserves a place in your default server-hardening checklist.