SSH und Brute Force

Was er liest#

Auf systemd-Servern liest der Agent die SSH-Authentifizierungsmeldungen aus dem Journal (Facilities auth und authpriv), daher sind auch Distributionen ohne rsyslog abgedeckt. Anderswo oder in einem Container liest er /var/log/auth.log oder /var/log/secure. AUTH_LOG_PATH verweist ihn auf eine Datei an einem anderen Ort. Das Agent-Log nennt die Quelle: reading authentication messages from ….

Die 15 Muster#

Neun Muster erfassen fehlgeschlagene Authentifizierungen: falsche Passwörter und Schlüssel, ungültige oder unzulässige Benutzer, PAM-Authentifizierungsfehler, maximum authentication attempts exceeded, Verbindungsabbrüche wegen fehlgeschlagener Authentifizierung, nicht zugelassene Benutzer, abgewiesene root-Logins, Ablehnungen durch TCP Wrappers und Verbindungsabbrüche ungültiger Benutzer vor der Authentifizierung.

Sechs weitere erfassen Scans vor der Authentifizierung: kein Identifikationsstring, falsche Protokollversion, gescheiterte Schlüsselaustausch-Aushandlung, Fehler beim Banner-Austausch, vor der Authentifizierung geschlossene oder zurückgesetzte Verbindungen und Zeitüberschreitungen vor der Authentifizierung.

Wann eine Adresse gesperrt wird#

Eine Adresse wird gesperrt, wenn ihre Fehlversuche innerhalb des Zeitfensters die Schwelle erreichen: standardmäßig 5 Versuche in 60 Sekunden, einstellbar unter Einstellungen › Agent (Brute-Force-Schwelle (Fehlversuche), Brute-Force-Zeitfenster (Sekunden)). Jede Sperre wird dem Dashboard als kritisches Ereignis brute_force gemeldet.

Eine Adresse aus einem Land, das du sperrst, wird beim ersten Versuch gesperrt. Eine Adresse auf der Whitelist wird nie gesperrt.

Wie lange eine Sperre dauert#

Einstellungen › Agent › Sperrdauer:

• Steigend: 24 Stunden, 7 Tage, 30 Tage, dann dauerhaft (die Voreinstellung): Jede neue Sperre derselben Adresse dauert länger;
• oder immer 1 Stunde, 24 Stunden, 7 Tage, 30 Tage oder dauerhaft.

Eine Sperre beginnt sofort auf dem Server und dauert 24 Stunden, bis das Dashboard ihr endgültiges Ablaufdatum festlegt. Sperren laufen auf dem Server pünktlich ab, auch wenn das Dashboard nicht erreichbar ist, und überstehen Neustarts.

Im Tab Netzwerk des Servers kannst du für jede aktive Sperre Dauer ändern, Jetzt entsperren oder Zur Whitelist hinzufügen. Ist Auf allen Servern sperren eingeschaltet, wird eine auf einem Server gesperrte Adresse auf jedem Server der Organisation gesperrt.

Wie die Sperre angewendet wird#

Sperren kommen in das ipset infrafence-bans, das in der eigenen Kette INFRAFENCE des Agenten verworfen wird, auf die INPUT springt (und DOCKER-USER, für Container-Ports). Mit ipset hält der Agent bis zu 65.000 Sperren; ohne ipset eine Firewall-Regel pro Adresse, bis zu 500. Ist die Kapazität erreicht, machen die ältesten Sperren Platz, mit einer Warnung.

Der Agent sperrt nie Loopback-, Link-Local- und private Adressen, die eigenen Adressen des Servers, die Adresse des Dashboards oder Adressen auf der Whitelist, auch nicht auf Anweisung.

Mail, Datenbank und FTP#

Dieselbe Erkennung deckt die anderen Dienste ab, die Logins annehmen, mit einer festen Schwelle von 5 Fehlversuchen in 5 Minuten:

MAIL_LOG_PATH, DB_LOG_PATH und FTP_LOG_PATH überschreiben die erkannten Dateien. Ein Watcher, der nichts zu lesen hat, schreibt das ins Log, zum Beispiel [mailwatcher] no mail service found — mail attack detection disabled.

Überwachungsmodus#

Mit eingeschaltetem Überwachungsmodus wird jeder Versuch weiterhin erkannt und gemeldet, aber nichts gesperrt.