Jede öffentlich zugängliche WHMCS-Installation wird innerhalb weniger Stunden nach dem Live-Gang mit Brute-Force-Login-Versuchen bombardiert. Fail2ban überwacht Ihre Logs, erkennt wiederholte Fehlversuche und blockiert die betreffenden IPs automatisch per Firewall. Diese Anleitung richtet es für WHMCS (und den umgebenden SSH- + Web-Stack) unter Ubuntu ein.

Voraussetzungen

  • Ubuntu 22.04 mit Root-Zugriff
  • WHMCS läuft hinter nginx oder Apache
  • WHMCS-Aktivitätsprotokollierung aktiviert (standardmäßig der Fall)

Schritt 1 — Fail2ban installieren

apt update
apt install -y fail2ban
systemctl enable fail2ban

Schritt 2 — Eine lokale Jail-Konfiguration erstellen

Bearbeiten Sie niemals jail.conf direkt (Updates überschreiben sie). Erstellen Sie /etc/fail2ban/jail.local:

[DEFAULT]
# Ban for 1 hour after 5 failures within 10 minutes
bantime  = 3600
findtime = 600
maxretry = 5
# Ignore your own IPs (office, home, monitoring)
ignoreip = 127.0.0.1/8 ::1 YOUR.OFFICE.IP

[sshd]
enabled = true
port    = 2222

Passen Sie port an Ihren tatsächlichen SSH-Port an und fügen Sie Ihre statischen IPs zu ignoreip hinzu, damit Sie sich niemals selbst aussperren.

Schritt 3 — Eskalierende Sperren für Wiederholungstäter aktivieren

Das recidive-Jail sperrt IPs, die nach Ablauf ihrer ersten Sperre immer wieder auftauchen — und zwar deutlich länger:

[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
banaction = iptables-allports
bantime  = 604800   ; 1 week
findtime = 86400    ; 1 day
maxretry = 3

Schritt 4 — Einen WHMCS-Filter erstellen

WHMCS protokolliert fehlgeschlagene Admin-Logins in seiner Datenbank, schreibt aber bei wiederholten Treffern auch in das Webserver-Log. Der sauberste Ansatz ist ein Filter für das eigene Fehlversuch-Log von WHMCS. Zeigen Sie WHMCS zuerst auf eine Logdatei — oder parsen Sie das Web-Zugriffslog nach dem Login-Endpunkt.

Erstellen Sie /etc/fail2ban/filter.d/whmcs.conf:

[Definition]
# Matches failed admin/client login POSTs returning to login page
failregex = ^<HOST> .* "POST /(dologin|admin/login)\.php.* 200
            ^<HOST> .* "POST /index\.php\?rp=/login.* 200
ignoreregex =

Dies ist ein Startmuster — passen Sie failregex an Ihre WHMCS-URL-Struktur und Ihr Template an. Der Schlüssel ist das Abgleichen des Login-POSTs von der Client-IP.

Schritt 5 — Das WHMCS-Jail hinzufügen

Fügen Sie /etc/fail2ban/jail.local hinzu:

[whmcs]
enabled  = true
port     = http,https
filter   = whmcs
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 600
bantime  = 7200

Richten Sie logpath auf Ihr tatsächliches nginx-/Apache-Zugriffslog für den WHMCS-Vhost aus.

Schritt 6 — Vorsicht vor dem Real-IP-Problem

Wenn WHMCS hinter einem CDN oder Reverse Proxy läuft, zeigt Ihr Zugriffslog die IP des CDN an, nicht die des Besuchers — Fail2ban würde das CDN sperren und Ihre gesamte Website lahmlegen.

Beheben Sie dies in nginx, indem Sie zuerst die echte IP wiederherstellen. Fügen Sie für SprintCDN oder Cloudflare deren Bereiche zu einer Real-IP-Konfiguration hinzu:

# /etc/nginx/snippets/realip.conf
set_real_ip_from 1.2.3.0/24;   # your CDN's ranges
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Fügen Sie es in Ihren Server-Block ein und stellen Sie sicher, dass das Log-Format $remote_addr verwendet (was nun den echten Client widerspiegelt). Nur dann wird Fail2ban die richtige IP sperren.

Schritt 7 — Starten und überprüfen

systemctl restart fail2ban
fail2ban-client status

Sie sollten Ihre aktiven Jails sehen: sshd, recidive, whmcs. Überprüfen Sie ein bestimmtes Jail:

fail2ban-client status sshd

Dies zeigt aktuell gesperrte IPs und Gesamtzahlen.

Schritt 8 — Funktion testen

Von einer Wegwerf-IP (ein Telefon mit mobilen Daten funktioniert) aus, scheitern Sie absichtlich 6 Mal beim SSH-Login oder WHMCS-Login. Dann auf dem Server:

fail2ban-client status sshd
# Should list the test IP under "Banned IP list"
iptables -L -n | grep <TEST_IP>

Entsperren Sie sie, wenn Sie fertig sind:

fail2ban-client set sshd unbanip <TEST_IP>

Schritt 9 — Benachrichtigungen über Sperren erhalten (optional)

Fail2ban kann Sie bei jeder Sperre per E-Mail benachrichtigen. In jail.local unter [DEFAULT]:

destemail = you@yourdomain.com
sender    = fail2ban@yourdomain.com
action    = %(action_mwl)s

action_mwl = Sperre + E-Mail mit Whois + Log-Zeilen, damit Sie den Kontext erhalten, wer angreift.

Mehrschichtige Verteidigung

Fail2ban kümmert sich um die Anwendungsschicht, aber volumetrische Angriffe (jemand, der 50 Gbit/s auf Ihre Login-Seite wirft) erfordern eine Verteidigung auf Netzwerkebene. Bei Hostfory absorbiert die DDoS-Bereinigung die volumetrische Schicht, bevor sie Ihre Box erreicht, und Fail2ban bereinigt die intelligenten, volumenarmen Brute-Forcer, die durchschlüpfen. Nutzen Sie beides.

Fehlerbehebung

Fail2ban sperrt niemanden: Ihr failregex stimmt nicht mit den Log-Zeilen überein. Testen Sie es: fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/whmcs.conf. Es zeigt an, wie viele Zeilen übereinstimmten.

Fail2ban hat mein CDN / meine gesamte Nutzerbasis gesperrt: Das Real-IP-Problem aus Schritt 6. Sie lesen die Proxy-IP. Beheben Sie die Real-IP-Wiederherstellung, bevor Sie es wieder aktivieren.

Sich selbst ausgesperrt: Wenn Sie Konsolen-/IPMI-Zugriff haben (auf allen Hostfory dedizierten Servern enthalten), melden Sie sich auf diesem Weg an und fügen Sie Ihre IP zu ignoreip hinzu. Deshalb ist IPMI wichtig.

Nächste Schritte

Kombinieren Sie dies mit einem WireGuard-Management-Tunnel, damit SSH gar nicht erst öffentlich zugänglich ist, und beschränken Sie den WHMCS-Admin-Pfad auf Ihre Büro-IP auf nginx-Ebene. Tiefenverteidigung schlägt jede einzelne Kontrolle.