IPTables SSH Brute Force blockieren – Teil 2

By | 13. Februar 2016

Im ersten Teil hatte ich ja eine recht simple Methode beschrieben, wie man BruteForce-SSH-Attacken recht simpel mit IPTables blockieren kann, ohne sich weiter um das Thema kümmern zu müßen.

In diesem Artikel wird es jetzt etwas kniffliger. Es ist zwar schön, wenn man BFAs (Brute Force Attacke) abwenden kann, die innerhalb kurzer Zeitspannen reinkommen, aber was passiert denn nun, wenn jemand gezielt dieses Zeitfenster umgeht und trotzdem zig tausende von Anfragen über einen bestimmten Zeitraum schickt ?
Meine IP-Tables config in /etc sieht zunächst einmal so aus:

Also nichts weltbewegendes. 🙂 Ich lasse SSH, HTTP, HTTPS und SMTP zu, der Rest wird gedropped.
Wie man unschwer erkennen kann, ist der BFA-Blocker aus dem ersten Teil ebenfalls Bestandteil der Basiskonfiguration von IP-Tables.

Bei einem meiner Server fiel mir nach recht kurzer Zeit auf, daß von einem chinesischen IP-Block aus versucht wurde einen verzögerten BFA über mehrere IPs und mit variablen Zeitabständen zu versuchen. Mal waren die Abstände zunächst innerhalb einer Minute, weswegen der Trick aus dem ersten Teil half. Dann hörten diese Versuche „innerhalb einer Minute“ für den gesamten IP-Block auf einmal auf. Die Chinesen schienen gemerkt zu haben, daß sie so nicht weiterkamen.

Danach kamen neue Versuche aus dem selben chinesischen IP-Block, mit variablen Zeitverzögerungen, die nun nicht mehr in den 60-Sekunden-Trick fielen.

Da mein root-Passwort größer 30 Zeichen ist und aus einer illustren Kombination aus Groß-/Kleinschreibung, Zahlen und Sonderzeichen besteht, zudem noch eine 2-Wege-Authentifizierung stattfindet, habe ich mir um das „Knacken“ meines PWs keine wirklichen Sorgen gemacht 🙂
Aber es nervt halt schon, wenn einem die Logs zugemüllt werden.

Es stand zunächst die Idee im Raum, eines von den vielen auf dem Markt verfügbaren Tools zu nutzen, aber ich vertraue auf Unix-Ebene zunächst grundsätzlich keinem Code den ich nicht selbst geschrieben habe oder innerhalb 15 Minuten verstehe. (Alte Admin-/Hacker-Krankheit).

Also was eigenes Schreiben.
Herausgekommen sind 98 Zeilen Shell-Script, die IP-Tables dynamisch, über cron gesteuert, konfigurieren 🙂
Ob diese 98 Zeilen jeder sofort innerhalb 15 Minuten versteht, kann ich nicht beurteilen, aber ich werde hier jetzt einfach zeigen wie ich vorgegangen bin und am Ende das fertige Script zum Download zur Verfügung stellen.

Mein betroffener Server läuft auf Debian GNU/Linux 7 (wheezy) und sollte daher, mal von einigen File-Locations abgesehen, als Referenz herhalten können.

Der erste Ansatz, um herauszufinden, wie man das Ganze nun dynamisch macht, ist ersteinmal herauszufinden, was man denn nicht blocken möchte ^^
Sämtliche Informationen die wir zum blocken oder nicht-blocken brauchen, finden wir unter Debian in dem File „/var/log/auth.log“.
Wenn man sich die Datei genauer anschaut, findet man darin auch Zeilen wie diese:

CRON mag ich nicht blocken 🙂

Für mich habe ich den Weg genommen, daß ich grundsätzlich nur alles blocken möchte, was einen „Failed password“ im auth.log hat und nicht zu meinen Ausnahmen gehört.

Ein „Invalid user“ ist zwar auch nicht nett, kann aber auch mal von einem Fehler vor der Tastatur kommen.

Wenn man jetzt mal ins „/var/log“ schaut, sieht man, daß die Logfiles rotiert und die wegrotierten, bis auf den auth.log.1, gezipped werden, also muß das Script auch diese Files entzippen, nach Mustern durchsuchen, dynamisch zur IPTables Blockliste hinzufügen und das ganze brav wieder zippen (manuelle Option, geeignet, um initial eine Blockliste aufzubauen).

Da ich ein unfreundlicher Admin bin, bleiben geblockte IPs für immer geblockt – also bis zum Sankt Nimmerleinstag. Ungeachtet Dessen, ob sie momentan noch im auth.log oder in den rotierten auth.logs drin sind. Daher muß das Script noch eine Historie führen, die man zur Not manuell bearbeiten kann. 🙂

Dann zur Umsetzung.

In THRESHOLD steht die maximale Anzahl an Versuchen, die zugelassen werden, bevor eine IP geblockt wird. Dies gilt über alle eingelesenen auth.log, also auch die gezippten. Taucht also die selbe IP in den gezippten Logs mehr als THRESHOLD-mal mit einem Fehler auf, geht diese IP in die IP-Tables-Blocklist.

Da das Script sowohl in einem FULL-SCAN (manuell) oder einem SHORT-SCAN (z.B. per CRON) läuft, sind die nächsten beiden Zeilen der maximale Linecount, der im entsprechenden ScriptModus verwendet wird. Bei einem FULL-SCAN können das durchaus mehr Zeilen werden, weswegen der Wert auf 50.000.000 Zeilen steht.

GREPVPATTERN ist das Argument, was an grep übergeben wird, um Sachen aus den Logs auszufiltern, die ich nicht blocken mag.

GREPVIPTABLES dient dazu, um im Log mitzuteilen, was wir jetzt tatsächlich in IPTables an geblockten IPs haben. (Es wird beim finalen Script deutlich)

GUNZIPARGBEFORE und GZIPARGAFTER stehen für die Files gezipped sind und bei einem FULL-SCAN mit einbezogen werden sollen und danach wieder gezipped werden müßen.

LOGLISTFULL und LOGLISTSHORT stehen für die Dateien, die bei einem Scan im FULL-SCAN oder im SHORT-SCAN durchsucht werden sollen.

PERMBLOCKLIST ist nun noch das File, wo sämtliche geblockten IPs abelegt werden sollen, die auch nach einem Restart des Rechners oder Reset der IPTables dynamischen Konfiguration wieder hinzugefügt werden sollen.

Hier nun das ganze Script (block_attack.sh):

Bei Fragen oder Anregungen -> Einfach einen Kommentar schreiben 🙂

 

Kommentar verfassen