Brute-Force-Angriffe gezielt abblocken mit SSH Guard

Andrii IURLOV, 123RF

Torwart

Versucht ein Angreifer in einen Server einzudringen, sollte der Admin ihn nicht nur davon abhalten, sondern künftige Versuche verhindern. Diese Aufgabe übernimmt das schlanke Werkzeug SSH Guard. Es überwacht im Hintergrund jeden Login-Versuch und setzt ertappte Bösewichte auf die schwarze Liste.
Thematischer Schwerpunkt dieser Ausgabe ist die kontinuierliche Überwachung von Servern, Clients und anderen Geräten im Netzwerk: mit dem IPMI-Plugin, dem ... (mehr)

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.

Unterstützte Dienste

SSH Guard kennt derzeit folgende Dienste:

  • SSH
  • Sendmail
  • Exim
  • Dovecot
  • Cucipop
  • UW-Imap (IMAP, POP)
  • WS-FTPD
  • Pro-FTPD
  • Pure-FTPD
  • Free-BSD-FTPD

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):

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.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite