Einen SSH- oder RDP-Brute-Force in Sekunden erkennen, nicht beim nächsten Abruf

Warum Passwortangriffe auf dem Host erkannt werden müssen statt aus Metriken auf dem Server abgeleitet zu werden, und was sich dadurch ändert.

Veröffentlicht 2026-06-02

Ein Passwortangriff gegen SSH oder RDP ist eines der wenigen Sicherheitsereignisse, die ein Monitoring-Agent zuverlässig, günstig und früh erkennen kann. Er hinterlässt eine unverwechselbare Signatur im Authentifizierungsprotokoll und läuft schnell - ein paar tausend Versuche pro Minute sind normal.

Warum das Panel es nicht kann

Die naheliegende Architektur schickt das Authentifizierungsprotokoll an den Server und wertet es zentral aus. Das funktioniert, und es ist der falsche Kompromiss. Log-Versand ist teuer auf Hosts, die ohnehin unter Last stehen, und zentrale Auswertung schiebt ein Abrufintervall zwischen Angriff und Alarm. Kommen Metriken alle 60 Sekunden, ist ein Ausbruch, der innerhalb eines Fensters beginnt und endet, unsichtbar.

Also läuft die Erkennung dort, wo das Protokoll liegt. Der Agent beobachtet unter Linux journald//var/log/auth.log und unter Windows das Sicherheitsprotokoll, hält ein kleines Fenster von Fehlversuchen nach Quelladresse im Speicher und meldet in dem Moment, in dem das Muster eindeutig ist - vor dem nächsten Metriktakt und ohne das Protokoll irgendwohin zu senden.

Was als eindeutig gilt

Naive Schwellwerte auf die Zahl der Fehlversuche erzeugen ständige Fehlalarme, denn das öffentliche Internet ist ein durchgehender Scan auf niedrigem Niveau. Alles mit offenem SSH-Port sieht ein paar hundert Fehlversuche am Tag von unzusammenhängenden Adressen, und das ist schlicht Wetter, kein Vorfall.

Was einen Angriff vom Grundrauschen trennt, ist Konzentration:

  • viele Fehlversuche von einer Quelle in kurzer Zeit statt je weniger von vielen;
  • derselbe Benutzername wiederholt versucht oder ein Wörterbuchdurchlauf durch gängige Namen;
  • ein Erfolg unmittelbar nach einer Reihe von Fehlversuchen - der wichtigste Fall, und derjenige, den ein reiner Ratenschwellwert vollständig verpasst.

Was er bewusst nicht tut

Der Agent blockiert, sperrt und verwirft keinen Verkehr. Monitoring, das den Firewall-Zustand verändert, ist Monitoring, das einen Produktions-Host wegen eines Parsing-Fehlers vom Netz nehmen kann, und dieser Fehlerfall ist schlimmer als der Angriff. Er meldet; Sie entscheiden. Alles, was der Agent tut, ist lesend, er öffnet keine eingehenden Ports und hat keinerlei offensive Fähigkeiten.

Wenn Sie eine automatische Reaktion wollen, hängen Sie den Webhook an das System, das Ihre Firewall bereits besitzt. So bleiben Entscheidung und Schadensradius in einem System, das dafür entworfen wurde.