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.
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.
Unterstützte Dienste
SSH Guard kennt derzeit folgende Dienste:
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.
Weitere Betriebssysteme
Wer nicht Linux verwendet, muss zunächst herausfinden, welche Firewall auf seinem Betriebssystem läuft. Davon abhängig nutzt er bei der Übersetzung den passenden »configure
«
-Befehl aus Tabelle 1. Im Zweifelsfall wählt er den Parameter »hosts
«
, bei dem »sshguard
«
den Angreifer nicht über eine Firewallregel, sondern einen Eintrag in der Datei »/etc/hosts.allow
«
blockiert.
Die anschließend erforderliche Einrichtung der Firewall hängt wieder vom Betriebssystem ab. Unter Mac OS X und Free BSD mit der IP-Firewall nutzt »sshguard
«
beispielsweise Regeln mit IDs von 55000 bis 55050. Dort muss der Anwender gegebenenfalls mit dem »ipfw
«
-Kommando sicherstellen, dass nicht andere Regeln »sshguard
«
in die Quere kommen. Alternativ lassen sich auch über den zusätzlichen Configure-Parameter »--with-ipfw-rules-range=55000-55050
«
SSH Guard andere IDs zuweisen.Weitere Konfigurationshinweise für andere Betriebssysteme hält die Homepage von SSH Guard unter [3] im Bereich »BLOCKING BACKENDS
«
bereit.
Tabelle 1
Configure-Befehle je nach OS
Betriebssystem |
Firewall |
Befehl |
AIX |
AIX-Firewall |
./configure --with-firewall=aix |
Linux |
Netfilter/IPtables |
./configure --with-firewall=iptables |
Mac OS X, Free BSD |
Free BSD IP-Firewall |
./configure --with-firewall=ipfw |
Verschiedene BSD |
Open BSD Packet Filter |
./configure --with-firewall=pf |
Andere |
TCP-Wrapper |
./configure --with-firewall=hosts |
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):
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.
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.