Linux: fail2ban

9. Juli 2025
Linux

fail2ban ist ein Python-basiertes Intrusion Prevention System (IPS), das Log-Dateien überwacht und automatisch IP-Adressen blockiert, die verdächtige Aktivitäten zeigen. Im Kontext von SSH-Servern analysiert das Tool kontinuierlich Authentifizierungsversuche und blockiert IP-Adressen nach wiederholten Fehlversuchen über die Firewall.

Nachdem mein Server, der in der Cloud steht, der aber eigentlich total unbekannt ist und nur SSH aktiv ist, in den letzten Tagen 25.493!! ungültige Logins erhalten hat, habe ich fail2ban auf diesem jetzt auch aktiviert. Kommt zwar eh niemand rein, da gut gesichert, aber dennoch erschreckend!

Funktionsweise bei SSH-Schutz

Das System überwacht die SSH-Authentifizierungs-Logs und identifiziert fehlgeschlagene Login-Versuche anhand vordefinierter Muster. Bei Überschreitung eines konfigurierbaren Schwellenwerts wird die betreffende IP-Adresse temporär über iptables (also die Firewall) blockiert.

Die Architektur umfasst drei Komponenten:

Filter definieren reguläre Ausdrücke zur Erkennung fehlgeschlagener SSH-Authentifizierungsversuche in /var/log/auth.log oder /var/log/secure.

Jails kombinieren Filter mit Aktionen und legen Parameter wie maximale Fehlversuche, Zeitfenster und Sperrdauer fest.

Actions definieren die Blockierungsmaßnahmen, standardmäßig über iptables-Regeln.

Installation

Ubuntu/Debian

sudo apt update
sudo apt install fail2ban
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

macOS

brew install fail2ban
sudo brew services start fail2ban

Die Konfigurationsdateien befinden sich in /etc/fail2ban/. Lokale Anpassungen sollten in jail.local vorgenommen werden, um Updates zu überstehen. In dieser Datei müssen nur Ergänzungen bzw. Ersatzwerte zur jail.conf angegeben werden.

SSH-Jail Konfiguration

Grundkonfiguration

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 5
bantime = 3600
findtime = 600

Parameter-Erklärung

  • maxretry: Maximale Anzahl Fehlversuche vor Blockierung
  • bantime: Sperrdauer in Sekunden (3600 = 1 Stunde)
  • findtime: Zeitfenster für die Zählung der Fehlversuche (600 = 10 Minuten)
  • logpath: Pfad zur SSH-Log-Datei (unter CentOS/RHEL: /var/log/secure)

Erweiterte SSH-Konfiguration

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 86400
findtime = 3600
ignoreip = 127.0.0.1/8 192.168.1.0/24 10.0.0.0/8
banaction = ufw

Diese erweiterte Konfiguration implementiert restriktivere Sicherheitsparameter:

  • maxretry = 3: Reduziert die tolerierte Anzahl Fehlversuche von 5 auf 3, wodurch potenzielle Angreifer schneller erkannt werden
  • bantime = 86400: Verlängert die Sperrzeit auf 24 Stunden (86400 Sekunden) statt der Standard-Stunde
  • findtime = 3600: Erweitert das Überwachungsfenster auf eine Stunde, wodurch verteilte Angriffe besser erfasst werden
  • ignoreip: Definiert Whitelist-Bereiche für lokale Netzwerke und Loopback-Interface
  • banaction: Standardmäßig wird iptables verwendet; damit ufw (sollte aber installiert sein 🙃)

Nach einer Änderung der Datei muss die Konfiguration neu geladen werden:

sudo fail2ban-client reload

Monitoring und Verwaltung

Status-Übersicht

sudo fail2ban-client status
sudo fail2ban-client status sshd

Manuelle IP-Verwaltung

# IP manuell sperren
sudo fail2ban-client set sshd banip 192.168.1.100

# IP entsperren
sudo fail2ban-client set sshd unbanip 192.168.1.100

# Jail neu laden
sudo fail2ban-client reload sshd

Log-Analyse

sudo tail -f /var/log/fail2ban.log
sudo grep "Ban" /var/log/fail2ban.log | grep sshd

Performance-Optimierung

Log-Rotation konfigurieren

# /etc/logrotate.d/fail2ban
/var/log/fail2ban.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    postrotate
        /bin/systemctl reload fail2ban || true
    endscript
}

Die Anpassung der Log-Rotation ist bei produktiven Systemen empfehlenswert, da Fail2ban kontinuierlich Log-Einträge generiert. Ohne angemessene Rotation können die Log-Dateien erheblich anwachsen und Speicherplatz verbrauchen. Die tägliche Rotation mit 30-tägiger Aufbewahrung stellt einen guten Kompromiss zwischen Verfügbarkeit historischer Daten und Speicherverbrauch dar.

Datenbank-Backend optimieren

[DEFAULT]
backend = sqlite

Für Server mit hohem SSH-Traffic kann die Verwendung einer SQLite-Datenbank statt der Standard-Pickle-Dateien die Performance verbessern.

Häufige Probleme und Lösungsansätze

False Positives reduzieren

[sshd]
enabled = true
filter = sshd
logpath = /var/log/auth.log
maxretry = 10
findtime = 3600
bantime = 86400

Die Erhöhung des maxretry-Werts kann bei Umgebungen mit legitimem, aber gelegentlich fehlerhaftem Zugriff sinnvoll sein. Dies betrifft insbesondere Entwicklungsumgebungen oder Systeme mit automatisierten Deployment-Prozessen, bei denen SSH-Schlüssel oder Passwörter häufig geändert werden. Ein höherer Schwellenwert reduziert die Wahrscheinlichkeit, dass legitime Benutzer versehentlich blockiert werden.

Firewall-Integration prüfen

sudo iptables -L -n | grep f2b
sudo ufw status

Best Practices für SSH-Schutz

Moderate Schwellenwerte zwischen 3-10 Fehlversuchen bieten einen ausgewogenen Schutz ohne übermäßige Einschränkungen für legitime Benutzer.

Angemessene Sperrdauern von 1-24 Stunden bieten ausreichenden Schutz vor Brute-Force-Angriffen, ohne dauerhafte Blockierungen zu verursachen.

Regelmäßige Log-Überwachung ermöglicht die Identifikation von Angriffsmustern und die Optimierung der Konfiguration.

Kombination mit anderen SSH-Sicherheitsmaßnahmen wie Key-basierte Authentifizierung, geänderter SSH-Port oder Firewall-Regeln erhöht die Gesamtsicherheit.

Backup der Konfiguration vor Updates verhindert Verlust angepasster Einstellungen.

Fazit

Fail2ban stellt eine effektive Lösung für die automatisierte Abwehr von SSH-Brute-Force-Angriffen dar. Die flexible Konfiguration ermöglicht die Anpassung an verschiedene Sicherheitsanforderungen, während die Integration in bestehende iptables-Infrastrukturen reibungslos funktioniert. Bei korrekter Konfiguration reduziert das Tool die Serverlast durch Angriffe erheblich und fungiert als wichtiger Baustein einer mehrschichtigen SSH-Sicherheitsstrategie.