Fail2Ban für 3CX — die Host-Ebene zusätzlich absichern

3CX bringt bereits eine eingebaute Anti-Hacking-Funktion mit, die SIP- und Admin-Portal-Angriffe automatisch erkennt und blockiert (siehe Sicherheits-Übersicht). Fail2Ban ergänzt das auf einer anderen Ebene: dem darunterliegenden Debian-Betriebssystem, allen voran dem SSH-Zugang.

Wofür ist das und wann brauche ich das?

Relevant für jeden, der 3CX per Debian-ISO oder Debian-Repository selbst betreibt und SSH-Zugriff auf den Server hat. Wer eine Managed-Hosting-Lösung nutzt, muss sich um diese Ebene in der Regel nicht selbst kümmern — dort übernimmt das der Hosting-Anbieter.

Voraussetzungen

• Root- oder Sudo-Zugriff auf den Debian-Server
• SSH-Zugang aktuell mit Passwort oder Public-Key erreichbar
• Kenntnis der eigenen festen IP-Adressen (Büro, VPN) für die Ignore-Liste — sonst sperren Sie sich versehentlich selbst aus

Installation

sudo apt update
sudo apt install fail2ban

SSH-Schutz einrichten (wichtigster Teil)

Bearbeiten Sie nie jail.conf direkt — das wird bei Paket-Updates überschrieben. Legen Sie stattdessen jail.local an:

sudo nano /etc/fail2ban/jail.local

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 IHRE.BUERO.IP.ADRESSE

[sshd]
enabled = true
port = ssh
maxretry = 5
findtime = 600
bantime = 3600

Bei produktiven Servern empfiehlt sich zusätzlich, SSH generell auf Public-Key-Authentifizierung umzustellen und Passwort-Login zu deaktivieren — das reduziert die Angriffsfläche deutlich wirksamer als jede Fail2Ban-Regel allein.

Service starten und Status prüfen

sudo systemctl restart fail2ban
sudo systemctl enable fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

Optional: 3CX-eigene Logs einbinden

3CX protokolliert fehlgeschlagene Login- und Registrierungsversuche in eigenen Log-Dateien (unter Linux typischerweise unterhalb von /var/lib/3cxpbx/Logs). Der genaue Dateiname und das Log-Format unterscheiden sich je nach 3CX-Version und werden von 3CX nicht als stabile, öffentlich dokumentierte Schnittstelle garantiert. Bevor Sie eine eigene Fail2Ban-Filter-Regel dagegen schreiben:

1. Aktuellen Log-Pfad und ein Beispiel für eine fehlgeschlagene Anmeldung direkt auf Ihrem Server im 3CX Log Viewer oder per tail -f auf die tatsächliche Log-Datei prüfen — nicht blind eine Anleitung aus dem Internet übernehmen.
2. Eine Filter-Regel (/etc/fail2ban/filter.d/3cx.conf) exakt auf das gefundene Log-Format abstimmen.
3. Testen mit fail2ban-regex gegen die echte Log-Datei, bevor der Jail scharf geschaltet wird — sonst droht entweder gar kein Ban (Regex passt nicht) oder ein zu aggressiver Ban (Regex zu weit gefasst, sperrt legitime Nutzer aus).

In der Praxis ist der Mehrwert eines zusätzlichen 3CX-Log-Jails begrenzt, weil die eingebaute Anti-Hacking-Funktion SIP- und Admin-Portal-Angriffe bereits auf Anwendungsebene abfängt. Der grösste Sicherheitsgewinn durch Fail2Ban liegt beim SSH-Zugang.

Häufige Fehler und Lösungen

„Failed to start fail2ban.service"

Meist ein Syntaxfehler in jail.local oder einer Filter-Datei. Prüfen mit sudo fail2ban-client -d (Dry-Run, zeigt die geparste Konfiguration) oder journalctl -u fail2ban -n 50 für die genaue Fehlermeldung.

Sich selbst ausgesperrt

Passiert, wenn die eigene IP nicht in ignoreip steht und man sich beim Testen mehrfach vertippt. Lösung: Zugriff über die Server-Konsole des Hosting-Providers (z. B. Rescue-Console), dort sudo fail2ban-client set sshd unbanip IHRE.IP ausführen.

Jail bannt gar nichts trotz sichtbarer Angriffsversuche

Häufigste Ursache: Der Filter-Regex passt nicht auf das tatsächliche Log-Format der installierten Version. Mit fail2ban-regex /pfad/zur/logdatei /etc/fail2ban/filter.d/IHR-FILTER.conf gegen echte Log-Zeilen testen, bis Treffer erscheinen.

Legitime Nutzer werden gesperrt

maxretry zu niedrig oder findtime zu grosszügig gewählt (z. B. bei Nutzern mit gelegentlichen Tippfehlern im Passwort). maxretry auf 5 und bantime auf 1 Stunde sind ein vernünftiger Startwert für die meisten Umgebungen.

Fail2Ban überwachen statt nur einrichten

Ein einmal eingerichteter Jail, der danach nie wieder kontrolliert wird, ist wenig wert. Für den laufenden Betrieb hilfreich:

• sudo fail2ban-client status sshd regelmässig prüfen — zeigt aktuell gesperrte IPs und Gesamtzahl der Bans
• Bei ungewöhnlich vielen Bans: prüfen, ob es sich um einen gezielten Angriff handelt oder ob z. B. ein Monitoring-Tool fälschlich als Angreifer erkannt wird
• Log-Rotation nicht vergessen — /var/log/fail2ban.log wächst kontinuierlich und sollte in die bestehende Logrotate-Konfiguration eingebunden sein

Best Practices

• SSH-Public-Key-Authentifizierung statt Passwort — wirksamer als jede Fail2Ban-Regel
• maxretry = 3–5, bantime = 3600 (1 Stunde) als Startwert, bei Bedarf schrittweise verschärfen
• Eigene feste IP-Bereiche konsequent in ignoreip pflegen, besonders nach Standortwechseln
• Fail2Ban-Status regelmässig prüfen (fail2ban-client status), nicht nur einmalig einrichten und vergessen
• Fail2Ban als Ergänzung verstehen, nicht als Ersatz für die eingebaute 3CX-Anti-Hacking-Funktion, TLS/SRTP und starke Passwörter