Introduction

A brute force attack against administrative accounts can trigger account lockout policies, effectively locking out legitimate administrators from the systems they manage. This is a double-impact attack: the attacker attempts to guess credentials while simultaneously denying legitimate access through lockout mechanisms. Recovery requires out-of-band access, careful investigation of the attack source, and strengthening authentication controls.

Symptoms

  • Admin accounts locked with Account locked due to too many failed login attempts
  • /var/log/auth.log shows hundreds of failed login attempts from a single IP
  • fail2ban or similar tool has blocked IPs but legitimate admin is also affected
  • PAM tally shows maximum failed attempts reached
  • Application admin panel shows Account temporarily locked

Common Causes

  • SSH or web login exposed to the internet without rate limiting
  • Weak or default admin passwords easily guessed by automated tools
  • No IP-based access restrictions on admin login endpoints
  • Account lockout threshold too low (3-5 attempts) without automatic unlock
  • Botnet-based distributed brute force from many source IPs

Step-by-Step Fix

  1. 1.Unlock the admin account:
  2. 2.```bash
  3. 3.# For PAM-based lockout (faillock)
  4. 4.sudo faillock --user admin --reset

# For PAM tally2 sudo pam_tally2 --user=admin --reset

# For application-level lockout (check the specific application) # Django: python manage.py shell -c "from django.contrib.auth.models import User; u=User.objects.get(username='admin'); u.is_active=True; u.save()" ```

  1. 1.Identify the attack source and scope:
  2. 2.```bash
  3. 3.# Find the top attacking IPs
  4. 4.sudo grep "Failed password" /var/log/auth.log | \
  5. 5.awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# Check the time range of the attack sudo grep "Failed password" /var/log/auth.log | head -1 sudo grep "Failed password" /var/log/auth.log | tail -1 ```

  1. 1.Block the attacking IPs:
  2. 2.```bash
  3. 3.# Block individual IPs
  4. 4.for ip in $(grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort -u); do
  5. 5.sudo iptables -A INPUT -s $ip -j DROP
  6. 6.done

# Or block entire subnets if the attack is from a specific region sudo iptables -A INPUT -s 185.220.101.0/24 -j DROP ```

  1. 1.Install and configure fail2ban for automated protection:
  2. 2.```bash
  3. 3.sudo apt install fail2ban
  4. 4.sudo nano /etc/fail2ban/jail.local
  5. 5.`
  6. 6.Add:
  7. 7.```ini
  8. 8.[sshd]
  9. 9.enabled = true
  10. 10.maxretry = 3
  11. 11.bantime = 3600
  12. 12.findtime = 600

[nginx-http-auth] enabled = true maxretry = 3 bantime = 3600 `` bash sudo systemctl enable fail2ban sudo systemctl start fail2ban

  1. 1.Strengthen admin authentication:
  2. 2.```bash
  3. 3.# Disable password authentication for SSH
  4. 4.sudo nano /etc/ssh/sshd_config
  5. 5.PasswordAuthentication no
  6. 6.PubkeyAuthentication yes
  7. 7.PermitRootLogin no
  8. 8.sudo systemctl restart sshd

# Enable MFA for web admin panels # Implement IP whitelisting for admin access ```

  1. 1.Implement account lockout policies that do not enable denial-of-service:
  2. 2.```bash
  3. 3.# Use progressive delays instead of hard lockouts
  4. 4.# Configure PAM with pam_faillock:
  5. 5.sudo nano /etc/security/faillock.conf
  6. 6.# deny = 5
  7. 7.# unlock_time = 900 (15 minutes, not permanent)
  8. 8.# even_deny_root (protect root too)
  9. 9.`

Prevention

  • Use SSH key-only authentication for all admin accounts
  • Implement MFA for all administrative access
  • Restrict admin login endpoints to specific IP ranges (VPN, bastion hosts)
  • Use fail2ban or cloud-based WAF rate limiting for automated brute force protection
  • Implement progressive lockout delays (exponential backoff) instead of permanent lockouts
  • Monitor authentication logs for brute force patterns and alert on threshold exceedance