Wo fail2ban aufhört zu genügen

Zuerst die Anerkennung

fail2ban liegt in den Repositories jeder Distribution, installiert sich mit einem Befehl und blockiert noch am selben Abend echte Angreifer. Wenn Sie einen exponierten Server haben, den nichts beobachtet, ist fail2ban zu installieren eine strikt bessere Position als die, in der Sie sind, und nichts weiter unten widerspricht dem.

Dieser Guide handelt von der Lücke zwischen „blockiert heute Abend echte Angreifer" und „ist in einem Jahr über einen ganzen Bestand hinweg noch korrekt", denn in dieser Lücke wohnen die Überraschungen, und sie steht selten geschrieben.

Keine der Grenzen unten ist ein Fehler. Sie sind Konsequenzen dessen, was fail2ban ist: ein Log-Parser-Daemon, entworfen in einer Zeit einzelner Server und einzelner Angreifer.

Grenze 1: es sperrt Adressen, keine Bereiche

Das ist die große. Angriffsverkehr kommt von Hosting-Anbietern, bei denen ein Betreiber einen ganzen Block hält. Sperren Sie 203.0.113.47, und das Botnetz zieht binnen einer Stunde auf .48, und Sie fangen eine weitere volle Runde Versuche ab, bevor auch die gesperrt ist. Über ein /24 sind das 256 Runden Ihrer konfigurierten Schwelle.

Sie können das mit einer eigenen Action annähern, die jede Sperre auf ihr /24 erweitert, aber dann pflegen Sie CIDR-Arithmetik in der Shell, und ein Fehler darin sperrt etwas, das Sie brauchten. Das Werkzeug kennt keinen Bereich als eigenständiges Objekt.

Der messbare Effekt: Auf einem Server unter Dauerbeschuss sieht eine bereichssperrende Abwehr die Versuchszahl einbrechen, während eine adresssperrende auf dem Niveau der Rotationsrate verharrt.

Grenze 2: Sperren laufen ab, Zustand überlebt nicht

Die voreingestellte bantime bemisst sich in Minuten. Das ist auf einem Shared Host, wo ein echter Nutzer hineingeraten kann, vernünftig, und auf einem Server im Internet falsch: Dasselbe Botnetz kommt heute Abend wieder und beginnt von vorn.

Sie können bantime auf -1 setzen, und das sollten Sie — dann erscheint das zweite Problem. Die Sperrliste liegt in fail2bans eigener Datenbank und in der laufenden Firewall; bauen Sie die Maschine neu, stellen Sie ein Image wieder her oder ziehen Sie auf einen neuen Host um, und alles, was der Server gelernt hat, ist weg.

Es gibt auch eine Variante dritter Ordnung: Ein Server, der zwei Jahre läuft, sammelt ein Firewall-Set mit zehntausenden Einträgen an, und niemand hat je überprüft, ob die ältesten noch einen Abgleich wert sind.

Grenze 3: jeder Server lernt allein

Diese ist strukturell, und keine Konfiguration behebt sie. Jeder Ihrer Server entdeckt jeden Angreifer eigenständig, und die Kosten dieser Entdeckung sind die Schwelle, die Sie gesetzt haben — fünf Versuche, zehn, wie viele auch immer.

Zehn Server, zehnmal derselbe Angreifer, zehnmal die Schwelle abgefangen. Und jeder dieser Versuche ist ein echter sshd-Fork, eine echte Protokollzeile und eine echte Chance, dass genau in diesem Durchlauf ein wiederverwendetes Passwort durchkommt.

fail2ban hat keinen Mechanismus, mit dem das Wissen eines Servers einen anderen erreicht. Es gibt Community-Blocklisten zum Abonnieren, die helfen, aber sie sind generisch und hinken Stunden bis Tage hinterher; nichts sagt Ihnen, dass die Adresse, die gerade Server drei trifft, dieselbe ist, die heute Morgen Server eins traf.

Grenze 4: es fällt lautlos aus

Diese Grenze kostet Leute tatsächlich Server, und sie bekommt die geringste Aufmerksamkeit.

fail2ban hängt daran, Protokollzeilen mit regulären Ausdrücken zu treffen. Ein Distributionsupgrade ändert ein sshd-Meldungsformat; der Filter trifft nicht mehr; das Jail „läuft" weiter und meldet null Sperren, was aussieht wie eine ruhige Woche. Paketupdates haben schon jail.local zurückgesetzt. Eine geänderte systemd-Anbindung lässt das Journal ungelesen. Der Dienst kommt nach einem Neustart nicht zurück.

In jedem dieser Fälle sagt das Monitoring, das Sie wahrscheinlich haben — läuft der Dienst? — ja. Die Frage, die es fangen würde, lautet: „Hat es kürzlich jemanden gesperrt, und sieht diese Zahl nach dem Angriffsvolumen aus, das ich im Protokoll sehe?" — und die stellt fast niemand.

fail2ban weiter treiben

Wenn Sie dabei bleiben wollen — für einen kleinen Bestand eine legitime Wahl —, sind das die wichtigsten Änderungen, grob nach Priorität:

• bantime = -1 setzen und findtime erhöhen, damit auch ein langsamer Angreifer gefasst wird. Darüber das recidive-Jail, damit Wiederholungstäter eskaliert werden.
• Eine eigene Action ergänzen, die eine Sperre auf ihr /24 ausweitet, und die Arithmetik zuerst sorgfältig gegen die eigenen Adressbereiche testen.
• Sperren über Neustarts hinweg erhalten: ein als persistent markiertes nftables-Set, oder beim Start aus der Datenbank wiederherstellen.
• Die Sperrzahl überwachen, nicht den Dienstzustand. Alarmieren, wenn sie null ist, während das Authentifizierungsprotokoll es nicht ist.
• Ihre Management-Adressen zuallererst in ignoreip eintragen und von einer zweiten Verbindung aus prüfen, dass Sie das richtig gemacht haben.

Was ein verwalteter Agent hinzufügt

Zwei Dinge, und das zweite ist in keiner Konfiguration allein baubar.

Das erste ist die betriebliche Grundlage: Subnetzsperren als eigenständiges Konzept, Sperren, die dauerhaft sind und beim Booten wiederhergestellt werden, der echte SSH-Port aus sshds Konfiguration statt angenommen, Ihre Adresse bei der Installation auf der Whitelist, und eine Konsole, die beantwortet, „läuft das noch" — der Fehlerfall, der tatsächlich beißt.

Das zweite ist geteilte Reputation. Jeder geschützte Server speist eine gemeinsame Datenbank, sodass eine Adresse, die gestern jemand anderen angriff, bereits gesperrt ist, wenn sie Sie erreicht, und Sie ihre ersten N Versuche nie abfangen. Ein Log-Parser auf einem Host kann nur aus Angriffen auf diesen Host lernen.

SSH Protector entscheidet lokal auf dem Agenten, der Schutz hängt also nicht an der Erreichbarkeit der Cloud — bricht die Verbindung ab, läuft die lokale Richtlinie weiter. Ein Server ist dauerhaft kostenlos, genug, um ihn eine Woche neben fail2ban laufen zu lassen und zu vergleichen, was jeder gefangen hat.