• Zielgruppen
  • Suche
 

SSH-Bruteforce-Abwehr

Alle, die einen weltweit erreichbaren SSH-Daemon auf Ihrem Rechner betreiben, kennen sicherlich die massenhaften Log-Einträge über fehlgeschlagene Login-Versuche. Wenn die Nutzernamen dabei auch in die Logs eingetragen werden, sieht man meist typische System-Accounts (guest, root) und gängige Vor- und Nachnamen, wie sie häufig dann auch als Account-Namen verwendet werden. Es handelt sich dabei um Bruteforce-Angriffe, bei denen Nutzernamen und Passwörter durchprobiert werden - mit dem Ziel, eine gültige Kombination zu erraten und damit einen Shell-Zugang zu erlangen.

Um dieses zu Verhindern, sollte man Gegenmaßnahmen ergreifen. Dabei gibt es viele Möglichkeiten, die letztlich immer auf eins der folgenden Dinge hinauslaufen:

  • Einschränkung der Zugriffe auf den SSH-Dienst (generell, zeitlich, Begrenzung der Versuchsanzahl),
  • Verwendung komplexer Passwörter oder Ausweichen auf Keys.

Zu der Problematik von Bruteforce-Angriffen auf SSH und zur technischen Umsetzung der o.g. Abwehrmaßnahmen wurde auf den Sicherheitstagen im Sommersemester 2006 vorgetragen (Vortragsfolien).

Beschränkung der Versuchsanzahl mit Fail2Ban

Eine grundsätzlich zu empfehlende Maßnahme ist die Einschränkung der Versuchsanzahl je anfragender IP-Adresse oder je Nutzer-Account. Dabei sind aber ein paar Dinge zu beachten:

  • Die zugelassenen Versuchszahlen und Sperrzeiten sind ausgewogen zu wählen: Verhinderung von Rateversuchen einerseits, Aussperrung von Nutzern andererseits.
  • Es kann auch für einen Denial-of-Service-Angriff missbraucht werden, da ggf. auch legitime Nutzer nach Fehlversuchen ausgesperrt werden.
  • Der administrative Zugriff oder solche aus den Institutsnetzen sollten deshalb aus der Sperrung ausgenommen werden.
  • Bei IP-Adressen ist an Natting zu denken, evt. verbergen sich alle Nutzer einer Einrichtung hinter nur einer IP. Auch wechseln IPs häufiger, z.B. im WLAN oder bei DSL-Anschlüssel (Aussperrzeiten nicht zu lang wählen).

Im Folgenden wird eine übliche Fail2Ban-Installation auf einem Debian-System beschrieben (Ubuntu ähnlich).

Fail2Ban unter Debian

Hier wird beschrieben, wie Fail2Ban für die alleinige Abwehr von ssh-Bruteforce-Angriffen eingesetzt werden kann. Dabei wird hier bewusst nicht die Personal-Firewall iptables oder direkt die hosts.deny-Datei verändert, sondern die zu sperrenden IP-Adressen in einer separaten Datei /etc/hosts.evil geführt. Neben dem hier beschriebenen Verfahren sind aber auch andere, teils bei Fail2Ban mitgelieferte Methoden möglich.

Zunächst muss das Fail2Ban-Debian-Paket mittels apt-get install fail2ban installiert werden. Das Paket sollte vor der Anpassung nicht laufen, daher mit invoke-rc.d fail2ban stop erstmal anhalten . Fail2Ban muss an drei Stellen angepasst werden:

  • die eigentliche Konfiguration des Programms (z.B. zugelassen Fehlversuchszahl),
  • die "Action" für die Erstellung und Pflege der Blacklist-Datei /etc/hosts.evil,
  • und im TCP-Wrapper für die Einbidung der Blacklist.

Konfiguration

Die lokale Anpassung des Fail2Ban-Paketes erfolgt in der Datei /etc/fail2ban/jail.local. In der Datei wird neben der Zahl der zugelassen Fehlversuche und Timeouts auch gesteuert, welche Action aufgerufen wird und damit, was mit einer als angreifend eingestuften IP passieren soll. Dieses kann für verschiedene Dienste unterschiedlich erfolgen, hier wird nur ssh geschützt.

# /etc/fail2ban/jail.local
# 20130502-RRZN
# Anpassung zur SSH-Bruteforce-Abwehr unter Debian

[DEFAULT]
bantime = 600
maxretry = 5
usedns = no
banaction = hostsevil

[ssh]
maxretry = 5

Action

Das Paket Fail2Ban bringt keine vorgefertigte "Action" mit, die eine IP-Liste in einer Datei pflegt. Das ist aber leicht implementierbar, in dem die von uns angelegte Datei hostsevil.conf in /etc/fail2ban/action.d abgelegt wird (diese Datei und obige in fail2ban-ssh-hostsevil.tgz zum Download).

Die Action legt wenn nötig die Datei /etc/hosts.evil an, pflegt dort die auffälligen IP-Adressen und prüft, ob die Datei in hosts.allow oder hosts.deny eingebunden ist.

TCP-Wrapper

Im TCP-Wrapper kann die hosts.evil Datei in hosts.allow oder hosts.deny eingetragen werden (vgl. Kommentare am Anfang der Action-Datei hostsevil.conf). Es ist aber auch dringend zu empfehlen, feste IP-Bereiche, aus denen heraus die Systemadministration erfolgt oder die den eigenen Nutzern gehören, aus der möglichen Aussperrung herauszunehmen. So bietet sich für die LUH eine Eintragung in /etc/hosts.allow wie folgt an:

# in /etc/hosts.allow
sshd: 130.75., 10.
sshd: ALL EXCEPT /etc/hosts.evil

Das Gleiche ließe sich aber auch über /etc/hosts.deny erreichen:

# in /etc/hosts.deny
sshd: /etc/hosts.evil EXCEPT 130.75., 10.

Danach wird Fail2Ban mit invoke-rc.d fail2ban start wieder gestartet. Die aktuell gesperrten IPs stehen in /etc/hosts.evil, ein Logging erfolgt nach /var/log/fail2ban.log

Falls Sie das oben Beschriebene auf einem anderen Unix-System einsetzen wollen, beachten Sie bitte, dass libwrap und damit der Mechanismus über hosts.allow/hosts.deny nicht mehr überall unterstützt wird. Prüfen Sie, ob der SSH-Daemon gegen libwrap gebaut wurde, folgender Befehl muss (außer bei statischem Linken) die dynamische Library auflisten:
ldd /usr/sbin/sshd |grep libwrap

Bisher kam auch häufig das Paket DenyHosts zum Einsatz. Das Paket wird aber zukünftig nicht mehr bei Debian enthalten sein (vgl. Bug-Report zum Removal).

Einschränkung der zugelassenen SSH-User

Hat das System mehrere Nutzer, womöglich Dienste-Nutzer mit gültigem Passwort, so sollte man den SSH-Daemon nur für klar benannte, möglichst wenige Nutzer öffnen. Dieses geht am besten über eine Gruppe, nur Mitglieder sollen sich per ssh aufschalten können.

Im Folgenden werden die Schritte am Beispiel eines Debian-/Ubuntu-Systems dargestellt.

  • Anlegen einer (System-) Gruppe sshusers mit
    addgroup --system sshusers
  • Die zugelassenen SSH-User der Gruppe zufügen, je Nutzer mit
    adduser nutzerkennung sshusers
  • Den Zugriff in der SSH-Daemon-Konfiguration einschränken, indem in der Datei /etc/ssh/sshd_config eine Zeile AllowGroups sshusers ergänzt wird (reicht bei unveränderter Standard-Konfiguration, ggf. restliche Konfigurationseinstellungen beachten, da diese sich gegenseitig beeinflussen können).