Fail2ban is a free, open-source intrusion prevention framework that monitors system log files for repeated authentication failures and automatically blocks offending IP addresses using the host firewall. It is widely used to protect SSH, FTP, HTTP, and other services against automated brute-force and credential-stuffing attacks. While platforms like Wazuh detect and log SSH brute-force attempts, detection alone does not stop an attack in progress. Fail2ban addresses this by automatically modifying iptables firewall rules to drop traffic from an attacker the moment an attempt threshold is exceeded, shifting the defensive posture from observation to prevention. In this lab, you will build a three-machine GNS3 network consisting of an Ubuntu Server running Fail2ban and SSH, an Ubuntu Desktop acting as a legitimate SSH client, and a Kali Linux machine acting as a brute-force attacker. You will observe the difference in how Fail2ban treats the two. The legitimate client connects freely, while the attacker is automatically banned after exceeding the failure threshold.

SSH is one of the most frequently attacked services on the Internet. Automated bots continuously scan for systems with port 22 open and attempt thousands of username-password combinations per minute. Without protection, a server with a weak password is highly vulnerable to compromise. Fail2ban acts as a log-watching daemon. It reads /var/log/auth.log on a timer and applies configurable rules called jails to count failed login attempts per IP address within a rolling time window. Once that count exceeds a threshold, Fail2ban inserts a DROP rule into iptables to silently discard all further traffic from that IP for a defined duration. Critically, Fail2ban acts on individual IP addresses. A ban on the attacker’s IP has no effect on any other machine on the network.

Estimated time for completion: unknown

LEARNING OBJECTIVES

• Configure a three-machine GNS3 environment for defensive testing
• Install and configure Fail2ban on a Linux server
• Simulate an SSH brute-force attack and observe Fail2ban ban the attacker in real time
• Demonstrate that legitimate client traffic is unaffected while an attacker is banned
• Inspect and interpret Fail2ban jail status output and log entries

PREREQUISITES

• Create a GNS3 Environment
• Create a Linux Server
• Create a Ubuntu Desktop
• Create a Kali Linux VM

DELIVERABLES

• 5 Screenshots:
  • GNS3 topology showing all three VMs running and connected
  • Ubuntu Desktop successfully logged in to the Ubuntu Server via SSH
  • Fail2ban jail status showing Kali’s IP banned, with the Desktop IP absent from the ban list
  • Relevant entries from /var/log/fail2ban.log showing the ban event
  • Hydra output showing the transition from login failures to connection refused errors

RESOURCES

• fail2ban Github

CONTRIBUTORS AND TESTERS

• TBD

Phase I – Building the GNS3 topology for this lab

NOTE: Working on this lab should mean you have familiarity with what things should look like. Screenshots are less frequent than in other labs.

This section will walk you through making our defensive test environment. For this example, we will be using the following machines.

Machine	IP Address	Role
Ubuntu Server	10.0.0.1	SSH Target /fail2ban host
Ubuntu Desktop	10.0.0.2	Legitimate client
Kali Linux	10.0.0.3	Attacker

1. Open Oracle VirtualBox
2. Take a snapshot or clone of each VM used in this lab
   1. Kali Linux
   2. Ubuntu Desktop
   3. Ubuntu Server
3. Ubuntu Server Configuration
   1. Ensure the VM network adapter is attached to NAT or NAT Network
   2. Start the VM
   3. Change the hostname
      1. Check current hostname

         hostnamectl

      2. Change the hostname

         sudo hostnamectl set-hostname server

   4. Verify SSH
      1. Ensure SSH is present and running

         sudo systemctl status ssh

      2.  If it is not running, try

          sudo systemctl enable --now ssh

      3. Check the status again
   5. Install fail2ban
      1. Update the system

         sudo apt update

      2. Upgrade the system

         sudo apt upgrade

      3. Install fail2ban

         sudo apt install fail2ban -y

      4. Verify installation

         fail2ban-client -version | less

         use q to quit

      5. Enable fail2ban to start at boot

         sudo systemctl enable fail2ban

   6. Shutdown the VM
   7. In VirtualBox, change the network adapter to Generic Driver
   8. Start the VM
   9. Verify that fail2ban is running

      sudo systemctl status fail2ban

      

   10. Close the VM
4. Open GNS3 to build the environment
   1. Import the three devices into the GNS3 environment
   2. Drag a GNS3 generic, unmanaged switch to the workspace
   3. Drag the three devices to the workspace
   4. Connect cables from the switch to each device
   5. Start all devices
   6. It should look similar to Figure 1
5. Navigate to the Ubuntu Desktop VM and open a terminal
   1. Stop the network manager so your IP address will stick

      sudo systemctl stop NetworkManager

   2. Look up the NIC name

      ip -a

   3. It should be enp0s3, eth0, or something similar, but it may vary. Adjust your commands as needed
   4. Change the IP address by typing

      sudo ip addr add 10.0.0.2/24 dev enp0s3

   5. Check that the IP address was set by typing

      ip -a

      NOTE: Some testers had to change the IP address twice before it took effect.

6. Repeat this process for the other two devices
   1. Kali Linux should be 10.0.0.3/24
   2. Ubuntu server should be 10.0.0.1/24
7. Ping between the devices to ensure connectivity. An example command is:

   ping -c 4 10.0.0.1

8. Navigate to the server
   1. Password authentication must be enabled for this lab. Fail2ban detects failed logins by reading /var/log/auth.log. If password auth is disabled, Hydra’s attempts are rejected at the protocol level before any log entry is written, and Fail2ban will never trigger!!!
   2. View/edit the SSH configuration file

      sudo vi /etc/ssh/sshd_config

   3. Ensure that the PasswordAuthentication line is not commented out with a # and is set to yes. It should look like the following:
      

      

   4. Save and close the file

      :wq

   5. Verify SSH is up and running

      sudo systemctl status ssh

   6. Reset if necessary,

       sudo systemctl enable --now ssh

9. Navigate to the desktop and try to SSH into the server
   1. Open a terminal
   2. Type the command to SSH (use your appropriate username and IP address for the server)

      ssh student@10.0.0.1

   3. We haven’t uploaded a key, so we will get a warning. Just type ‘yes’ at the warning
   4. You should see your prompt change from “Student@desktop” to “Student@ubuntuserver,” showing that you are now logged into the server from the desktop
      

      

1. Navigate to the server and configure the SSH Jail. The three most important jail parameters are:
   

   Command/Parameter	Meaning
   maxretry	Number of failures allowed before  a ban is issued
   findtime	The rolling time window (in seconds) in which failures are counted
   bantime	How long (n seconds) the ban lasts; -1 means permanent

   1. Create a new override file by typing

      sudo vi /etc/fail2ban/jail.d/sshd-custom.conf

   2. This will open a blank configuration file. Type the following EXACTLY
      

      

       

      Command/Parameter	Meaning
      [sshd]	The settings below belong to the SSH daemon jail
      enabled = true	Activates this jail. Without this, the jail is defined but never enforced.
      port = ssh	Applies the ban to TCP port 22, the SSH default.
      filter = sshd	Points to the regex filter at /etc/fail2ban/filter.d/sshd.conf that parses log lines.
      logpath = /var/log/auth.log	The log file Fail2ban monitors for authentication failures.
      maxretry = 5	An IP is banned after 5 failed attempts within the findtime window.
      findtime = 300	The rolling 5-minute window in which failures are counted.
      bantime = 600	The offending IP is banned for 10 minutes (600 seconds).
      action = iptablesmultiport[name=sshd, port=”ssh”, protocol=tcp]	The action taken when an IP needs to be banned.

      NOTE: These values are intentionally low so the ban triggers quickly during the lab. In production, you would increase findtime and bantime significantly, and consider setting bantime = -1 to more permanently ban repeat offenders.

   3. Save and close the configuration file by pressing escape, followed by

      :wq

   4. Add your custom overrides to allow fail2ban to use systemd for its backend for faster recognition of changes in the auth.log file

      sudo vi /etc/fail2ban/jail.local

       

      

   5. est the configuration; if there is no output, there are no errors.  Otherwise, read the error message and resolve the issue before moving on

      sudo fail2ban-client -t

      NOTE: If you are having a difficult time resolving the issue, you can view the exact error in the logs

      sudo journalctl -u fail2ban -f

      NOTE: if you are really stuck, you can delete the configuration files and begin again

      sudo rm /etc/fail2ban/jail.local

      sudo rm /etc/fail2ban/jail.d/sshd-custom.conf

   6. Restart fail2ban to load the new configuration

      sudo systemctl restart fail2ban

   7. Verify the SSHD jail is active

      sudo fail2ban-client status

       

      

   8. Inspect the detailed status of the SSHD jail

      sudo fail2ban-client status sshd

      

1. Establish a legitimate SSH session from the Ubuntu Desktop to the Ubuntu Server. This session will remain open throughout the attack to demonstrate that the ban only affects the attacker’s IP. This session will remain open throughout the attack to demonstrate that the ban only affects the attacker’s IP
   1. Navigate to the Ubuntu Desktop VM
   2. Establish the SSH connection

      ssh student@10.0.0.1

   3. Enter the password for the server when prompted
   4. Leave this session open and visible. You will be monitoring this connection
      

      

2. Prepare the rockyou.txt Wordlist. This is the most widely used real-world password list. It contains about 14 million real-world passwords from 2009 and works very well today.  Trust me, your password is not that unique
   1. Navigate to Kali Linux VM
   2. Verify the rockyou wordlist is loaded

      ls -lh /usr/share/wordlists

   3. Decompress the wordlist

      sudo gunzip /usr/share/wordlist/rockyou.txt.gz

   4. Confirm the txt file is now present and check its size (~134MB)
      

      

3. Launch the brute force attack
   1. Staying on the Kali VM, launch Hydra targeting the Ubuntu Server’s SSH service (replace user name and IP address for your server as necessary)

      hydra -l student -P /usr/share/wordlists/rockyou.txt ssh://10.0.0.1 -V -w 1

      Command/Parameter	Meaning
      hydra	A network login cracker
      -l student	Use this login username to make login attempts
      -P /usr/share/wordlists/rockyou.txt	the password list to cycle through (use captial P)
      ssh://10.0.0.1	Target protocol and IP address
      -V	verbose mode (captial V) : print each attempt to the terminal
      -w 1	wait one second between attempts

   2. Watch the Hydra output on the Kali VM.  After enough failed attempts, Fail2Ban on the server will ban Kali’s IP address (10.0.0.3 in our example)
      

      

1. Navigate to the Ubuntu Server
2. Check the sshd jail status:

   sudo fail2ban-client status sshd

   

3. If you want to run the test again without waiting for the jail timer, you can run the command on the server:

   sudo fail2ban-client set sshd unbanip 10.0.0.3

Career connection

Brute-force attacks against remote services are a constant threat in enterprise environments. Systems administrators and cybersecurity professionals routinely deploy tools such as Fail2ban to monitor authentication logs, identify repeated login failures, and automatically block malicious hosts before they gain unauthorized access. The skills developed in this chapter reflect common enterprise security practices where automated detection and response improve system resilience, reduce administrative workload, and provide an additional layer of defense for Internet-facing services.

end of Lab