Brute-Force-Angriffe gezielt abblocken mit SSH Guard

Die Arbeitsweise von »sshguard« ist einfach, effektiv und ähnelt dem eines Intrusion-Detection-Systems: Das kleine Programm beobachtet ständig die Logfiles ausgewählter Dienste. Sollte es dabei fragwürdige Netzwerkzugriffe entdecken, blockiert es den mutmaßlichen Angriff vorübergehend mit einer entsprechenden Firewallregel (Abbildung 1). Hört der Angreifer trotzdem nicht auf, sperrt ihn »sshguard« immer längere Zeitspannen aus. Diese trickreiche Strategie hat den Vorteil, dass der Admin nicht versehentlich einen vergesslichen Benutzer aussperrt, dem automatisierten Passwort-Raten aber einen wirksamen Riegel vorschiebt.

Abbildung 1: Die Anfragen des Clients (1) protokolliert der SSH-Daemon in der auth.log-Datei (2). SSH Guard überwacht sie (3) und erstellt bei zu vielen Login-Versuchen eine Firewallregel (4), die den Client abblockt (5).

Pappenheimer

Wie sein Name andeutet, überwachte »sshguard« ursprünglich nur fehlgeschlagene SSH-Logins. Mittlerweile kennt es sämtliche im Kasten "Unterstützte Dienste" aufgeführten Services. Angriffsmuster für weitere Dienste kann man über ein spezielles Kontaktformular an die Entwickler senden, die es dann in eine der kommenden Versionen einbauen [2]. SSH Guard versteht sich selbstverständlich auch auf IPv6, steht unter der BSD-Lizenz, ist schnell eingerichtet und verzichtet sogar komplett auf eine Konfigurationsdatei.

SSH Guard kommt als kleines, schlankes C-Programm und läuft neben Linux auch unter weiteren Betriebssystemen mit Unix-Unterbau, darunter Mac OS X, verschiedene BSD-Varianten, Solaris und AIX. Einige große Linux-Distributionen halten es sogar in ihren Repositories vor. Während dort jedoch durchweg die über ein Jahr alte Version 1.4 schlummert, steht auf der SSH-Guard-Homepage bereits der verbesserte Nachfolger 1.5 in den Startlöchern. Bei Redaktionsschluss war noch der letzte Release Candidate aktuell, mit dem Erscheinen dieses Heftes sollte die finale Fassung vorliegen.

Da die Version 1.5 die Konfiguration weiter vereinfacht und die SSH-Guard-Homepage den Release Candidate bereits allen Anwendern empfiehlt, soll sie auch im Folgenden im Mittelpunkt stehen. Als bevorzugtes Betriebssystem kommt dabei Linux in den Geschmackrichtungen Debian 5.0.7, Ubuntu 10.10 und Open Suse 11.3 zum Einsatz, auf Linux-fremde Kollegen geht kurz der Kasten "Weitere Betriebssysteme" ein.

Um die aktuelle Version von »sshguard« zu über- und anschließend einzusetzen, installiert der Admin zuerst den GNU C-Compiler (in der Regel im Paket »gcc« ), GNU Make (Paket »make« ) und Autoconf. Anschließend angelt er sich von der SSH-Guard-Homepage im Download-Bereich unter »FROM SOURCES« die »latest release« [1]. Nach dem Entpacken des Archivs startet das »configure« -Skript die Konfiguration, unter Linux mit dem folgenden Parameter:

./configure --with-firewall=iptables

Dabei sollte der Admin gut die Ausgaben beobachten. Moniert »configure« ein nicht gefundenes »iptables« , gibt er ihm noch den Pfad zum gleichnamigen Werkzeug auf den Weg. Meist liegt es in »/usr/sbin« :

./configure --with-firewall=iptables --with-iptables=/usr/sbin

Unter Open Suse 11.3 und Debian ist der Befehl »iptables« ausschließlich dem Benutzer »root« zugänglich. Deshalb ist dort die Übersetzung und die komplette nachfolgende Einrichtung explizit als Administrator durchzuführen. Ein den Befehlen vorangestelltes »sudo« reicht hier nicht aus.

Im Fall von Open Suse 11.3 sorgt der »configure« -Parameter »--prefix=/usr« schließlich noch dafür, dass der fertige »sshguard« im Suchpfad von »root« liegt:

./configure --with-firewall=iptables--prefix=/usr

Meldet »configure« keine Probleme, übersetzt und installiert man SSH Guard via:

make
sudo make install

Bevor SSH Guard in Betrieb gehen kann, muss der Administrator unter Linux noch die Firewall vorbereiten. Dazu erstellt er zunächst eine neue IPtables-Kette mit dem Namen »sshguard« , in die SSH Guard später seine eigenen Regeln anhängt:

sudo iptables -N sshguardsudo ip6tables -Nsshguard

Der zweite Befehl deckt IPv6-Pakete ab. Als Nächstes erweitert der Admin die Input-Kette so, dass sie die Pakete durch die SSH-Guard-Kette schickt (Abbildung 2):

Abbildung 2: Unter Ubuntu fügen diese Befehle eine neue Kette hinzu, in die SSH Guard später seine Regeln injiziert.

sudo iptables -A INPUT -j sshguard
sudo ip6tables -A INPUT -j sshguard

Wer mit SSH Guard nur bestimmte Ports schützen möchte, hängt diese noch per »--destination-ports« -Parameter an. So würde etwa

sudo iptables -A INPUT -m multiport -p tcp --destination-ports 21,22 -j sshguard

später nur die Dienste an den Ports 21 und 22 (standardmäßig FTP und SSH) blockieren.

Wer selbst Firewallregeln erstellt oder eine andere Distribution nutzt, muss abschließend noch sicherstellen, dass keine »default allow« -Regel die Pakete weiter hinten in der Kette doch noch durchwinkt und keine »default deny« -Regel alle Pakete verwirft.

Eigensinniges Chamäleon

Im Fall eines frisch installierten Debian oder Ubuntu war dies bereits alles. Open Suse 11.3 kocht mit seiner Suse-Firewall2 wieder einmal ein eigenes Süppchen. Dort muss der Administrator die obigen Befehle in die Konfigurationsdateien einarbeiten. Dazu öffnet er als Erstes die Datei »/etc/sysconfig/scripts/SuSEfirewall2-custom« mit einem Texteditor. Vor dem »true« in der »fw_custom_before_port_handling« -Sektion fügt er die Zeile

iptables -N sshguard

hinzu, in die Sektion »fw_custom_before_denyall« setzt er vor das »true« die Zeile:

iptables -A INPUT -j sshguard

Als Nächstes entfernt der Admin in der Datei »/etc/sysconfig/SuSEfirewall2« die Raute »#« vor der Zeile

FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"

und setzt sie vor die Zeile:

FW_CUSTOMRULES=""

Abschließend startet er die Firewall neu:

/etc/init.d/SuSEfirewall2_init restart

Die Änderungen per »iptables« -Kommando gelten nur bis zum nächsten Neustart. Wie man sie speichert, hängt von der eingesetzten Linux-Distribution ab. Unter Ubuntu und Debian dienen dazu beispielsweise die Befehle »iptables-save« und »iptables-restore« (eine ausführliche Anleitung liegt unter [4] beziehungsweise [5]). Bei Open Suse ist mit den Einträgen in die Konfigurationsdateien dieser Punkt bereits abgehakt.

Mit Version 1.5 hält der so genannte Log Sucker Einzug. Dieser intelligente Programmteil beobachtet die ihm übertragenen Logs und liest automatisch jede neu hinzugekommene Zeile ein. Die Logdaten können dabei entweder als Datei vorliegen oder SSH Guard per Fifo beziehungsweise über eine Pipe erreichen. Der Log Sucker liest und erkennt die Logdatei-Formate Syslog, Syslog NG, Metalog, Multilog und direkt von den unterstützten Diensten geschriebene Dateien (Raw-Format). Er behält auf Wunsch mehrere Logdateien gleichzeitig im Auge und kann mit rotierenden sowie temporären Logdateien umgehen.