Goal

To simulate an SSH brute-force attack within an isolated KVM lab environment and validate:

  • Detection of repeated failed authentication attempts
  • Automated banning of malicious IPs using Fail2Ban
  • Log visibility and response confirmation
  • Proper configuration of a defensive control mechanism

The objective was to observe the full attack -> detection -> enforcement lifecycle.

Setup

Environment:

  • Hypervisor: KVM/libvirt
  • Target VM: lab-ssh-1 (Ubuntu Server)
  • Network: isolated lab-net
  • Attacker: Kali
  • Log source: /var/log/auth.log

Fail2Ban Configuration:

Created in /etc/fail2ban/jail.local

[sshd]

enabled = true

port = ssh

logpath = /var/log/auth.log

maxretry = 3

findtime = 60

bantime = 600

Policy Explanation:

  • maxretry = 3 -> Ban after 3 failed attempts
  • findtime = 60 -> Within 60 seconds
  • bantime = 600 -> 10-minute ban duration

Walkthrough

  1. Baseline Check (Before Attack)

    Checked SSH jail status with:

    sudo fail2ban-client status sshd

    Result:

    • Currently failed: 0
    • Total failed: 0
    • Currently banned: 0
    • Total banned: 0

  2. Attack Simulation

    From kali, multiple failed SSH login attempts were initiated against lab-ssh-1.

    Authentication failures appeared in /var/log/auth.log:

  3. Detection and Enforcement

    Fail2Ban rechecked:

    The attacking IP was automatically added to the banned list.

    The ban was enforced via iptables rules generated by Fail2Ban

Results

Observed Indicators

  • Authentication failures logged in /var/log/auth.log
  • Fail2Ban counter incremented correctly
  • IP banned after exceeding retry threshold
  • Active enforcement confirmed in jail status

Key Evidence

  • Total failed attempts recorded: 3
  • IP added to banned list
  • Automatic mitigation triggered within the defined findtime

The control worked exactly as configured.

Lessons

  1. Detection is Log-Dependent

    • Fail2Ban relies entirely on log parsing. If log paths are misconfigured, detection fails silently.

  2. Threshold Tuning

    • maxentry at 3 is aggressive and suitable for lab testing. In production, tuning must balance:

      • User lockout risk
      • False Positives
      • Real attack frequency

  3. Isolation Simplifies Testing

    • Using an isolated lab network:

      • Eliminated external noise
      • Made the log correlation clear
      • Reduced unintended exposure

  4. Next Iteration Improvements

    • If repeating this lab:

      • Add ignoreip for trusted internal hosts
      • Export logs for timeline analysis
      • Perform a distributed brute-force simulation
      • Test evasion attempts