Oberbegriff: ssh

Thema: Verteidigung gegen brute force ssh attacks

Thomas Arend, 21. März 2008

(Ich gebe zu, hier muss noch etwas gearbeitet werden.)

Schon seit acht - zehn Jahren wird über zunehmende Angriffe auf den Dienst Secure Shell (ssh) berichtet [7,8]. Mittels brute force (brutaler Gewalt) versuchen einige Zeitgenossen Rechner mit Nutzerkonten zu finden, für die ein schwaches, geheimes Kennwort vergeben wurde, und diese dann für ihre Zwecke zu nutzen. Bei einer brute force attack wird versucht mit Listen häufiger Kontennamen und trivialer Passwörter Zugang zu einem Rechner zu erhalten. Mit steigender Verbreitung virtueller Server oder über DSL ständig am Internet hängender Rechner, die über ssh verwaltet werden, werden diese Angriffe in Zukunft sicher nicht abnehmen. Ganz offensichtlich finden sich noch ausreichend Opfer, sonst würden diese Angriffe sicher lohnenderen Methoden weichen. Mein über DSL am Internet hängender Rechner erhält jedenfalls mehrmals täglich Besuch. Bei vielen Besuchern dürfte es sich um gekarperte Maschinen handeln.

In seinem Beitrag "Defending against brute force ssh attacks" [1] gibt Rainer Wichmann einen Überblick über Techniken, mit denen man sich gegen brute force ssh attacks verteidigen kann. Seine Liste habe ich ein wenig erweitert:

  • Sichere Kennwörter
  • RSA-Authentication
  • keine Anmeldung für nicht benötigte Nutzer
  • benutzen von pam zum Blockieren der User-IDs [2,3]
  • benutzen von iptables zum Blockieren der Adressen
  • benutzen des sshd-log zum Blockieren der Adressen
  • benutzen des tcp-wrappers zum Blockieren der Adressen
  • benutzen des knockd
  • austauschen der Adressen der Angreifer zwischen Rechnern (Bad Guys List)

Da ich nicht alles wiederholen will, empfehle ich seinen Beitrag [1] als Ergänzung zu lesen.

Was erwarte ich von einer guten Abwehr?

Wenn wir Strategien zur Abwehr bewerten oder entwickeln wollen, dann müssen wir uns im Klaren darüber sein, was wir von einer guten Abwehr erwarten. Je nach Einsatzgebiet des zu schützenden Servers kann es dabei Unterschiede geben. Eine gute Abwehr

  1. sollte Nutzer nicht fälschlich - z.B. aufgrund von Tippfehlern - aussperren.
  2. sollte Angriffe frühzeitig erkennen, unterbinden und vielleicht auch einen Administrator informieren.
  3. sollte - im Zeitalter der virtuellen Server für jeden - leicht zu installieren sein.

Ohne Maßnahmen zur Verzögerung oder Beschränkung der Verbindungen pro Zeiteinheit dauern die viele Angriffe auf meinen Rechner (angebunden mit DSL-6000) nur etwa 20 Sekunden, andere mehrere Minuten. Um einen akuten Angriff zu blockieren, muss er daher innerhalb weniger Sekunden erkannt werden. Nach 20 Sekunden ist es im Grunde genommen zu spät, auch wenn einige Server Tage oder Wochen später nochmals vorbeischauen. Um diese wiederholten Angriff zu unterbinden, kann man über iptables oder tcpwrapper (/etc/hosts.deny) die IP-Adressen der Angreifer eine Weile blockieren. Wenn es sich um Angreifer mit dynamischen Adressen handelt, dann könntes es natürlich sein, dass man selbst zu einem späteren Zeitpunkt diese Adresse zugewiesen bekommt und so sich selbst aussperrt - unwahrscheinlich, aber möglich.

Sichern des Rechners

Sichere Kennwörter

Die beiden ersten Methoden könnte man als passiv bezeichnen. Man kann es nicht oft genug wiederholen: Nichts geht über sichere Passwörter. Sichere Passwörter sind auch für alle Methoden zur Erkennung der Angriffe Voraussetzung. Wenn root kein Passwort hat, dann ist der Angreifer sofort drin.

Ich erzeuge meine Kennwörter unter Linux mit einem Kennwortgenerator (pwgen [5]). Zugegeben sie sind nicht sehr einfach zu merken, aber nach einer Weile geht es. Nur einen längeren Urlaub überdauert sie manchmal nicht. Aber hier hilft ein Password-Safe. Außerdem können Sie wirklich zufällige Kennwörter problemlos länger verwenden, da es fast unmöglich ist diese mit drei oder sechs Fehlversuchen zu erraten. Bisher meine Kennwörter allen Angriffen Stand gehalten.

Für Ihr eigenes Kennwort haben Sie die Kontrolle und alleinige Verantwortung. Haben Sie als Administrator jedoch ein System mit vielen Nutzern zu verwalten, können Sie sicher sein, dass mindestens ein Nutzer ein triviales Kennwort verwendet, wenn Sie die nicht bei der Kennwortvergabe verhindern.

RSA-Authentication

Wenn es möglich Ihnen möglich ist ausschließlich RSA-Authentication zu nutzen, dann laufen alle Angriffe auf die Passwörter ins Leere, da nur der Besitz eines gültigen geheimen Schlüssels den Nutzer authentisiert und nicht das Kennwort.

Der Vorteil liegt klar auf der Hand: Dies Sicherheit ist nicht von der Sorgfalt der Nutzer bei Vergabe von Kennwörtern abhängig, sondern nur von der ordentlichen Aufbewahrung der Schlüsseldatei.

Wollen oder müssen sie sich von verschiedenen oder auch fremden Rechnern - zum Beispiel in einem Internet Cafè auf ihren Servern anmelden, dann hat diese Methode den Nachteil, dass sie ihre geheime Schlüsseldateien auf mehrere Rechner verteilen oder auf einem Datenträger mitführen müssen.

Es ist zwar nicht sonderlich ratsam fremde Rechner zu nutzen, aber ich war schon mal genötigt einen Rechner während des Urlaubs von einem Internet-Cafè aus per ssh zu verwalten. Eine weitere Erörterung der Vor- und Nachteile und Risiken führt in diesem Beitrag jedoch zu weit vom Thema weg.

Keine Anmeldung nicht benötigter Nutzer über ssh

Der begehrteste Account ist natürlich root. Deshalb versucht natürlich jeder Eindringvesuch diesen Account zu knacken. Verbieten Sie daher root den Login und setzen Sie in der Datei /etc/ssh/sshd_conf "PermitRootLogin no". Sie können sich über einen anderen Account anmelden und dann mittels sudo oder su root-Rechte erlangen.

Wenn nicht alle Nutzer über ssh arbeiten müssen, dann können Sie Nutzer, die ssh benötigen, in der /etc/ssh/sshd_conf mit z.B "AllowUsers nx ..." freigeben.

Verbieten Sie root das ANmelden, können sie sicher sein, dass alle Anmeldeversuche mit root ein Angriff darstellen und die IP-Adresse, von der diese Anmeldung ausging, blockieren. Außer sie haben Nutzer "toot", "foot", oder "ropt", die sich vertippen könnten.

Erkennung der Angriffe

Es gibt einige Programme, die die Angriffe anhand der Log-Enträge des sshd nach unterschiedlichen Kriterien erkennen. Allen gemeinsam ist, dass sie das Log nach misslungenen oder verdächtig häufigen Anmeldeversuchen untersuchen, was natürlich nur funktioniert, wenn die Kennwörter zumindest so sicher sind, dass der Angriff nicht mit den ersten Versuchen zum Erfolg führt. Gegen ein leeres Kennwort für root ist kein Kraut gewachsen.

Christian Seifert berichtet über verschiedener Strategien der Angreifer [9]. ... tbc ...

Bei Verwendung sicherer Kennwärter könnten Sie sich eigentlich getrost zurücklehnen, aber die Angriffe kosten auch Resourcen und so macht es Sinn, ein wenig in die Erkennung zu investieren, um sie frühzeitig abzublocken. Außerdem ist es durchaus sinnvoll, Angriffe nach - sagen wir mal vier Fehlversuchen von einer IP-Adresse - zu blockieren, bevor der Nutzer deaktivert wird. Dem echten Nutzer verbleiben dann noch zwei Versuche um sich von einer anderen Adresse anzumelden.

Eine falsche Kennworteingabe kann von einem Angriff oder von einem Tippfehler herrühren. Eine sofortige Blockade kommt daher bei einem falschen Passwort nicht in Frage. Es müssen schon mehrere falsche Passwörter bei mehreren Usern sein, um von einem Angriff zu sprechen und die IP-Adresse nicht fälschlich zu blockieren.

Log Einträge

Hier einige Bespiele für sshd-Log-Einträge aus meiner Log Datei.

/1/
Mar 17 08:54:53 k2 sshd[7089]: Did not receive identification string from 80.38.55.47
Mar 17 08:56:32 k2 sshd[7104]: User root from 47.red-80-38-55.staticip.rima-tde.net not allowed because not listed in AllowUsers
...
/2/
Mar 17 16:19:31 k2 sshd[9456]: Did not receive identification string from 87.116.122.33
Mar 17 16:48:14 k2 sshd[9612]: Address 87.116.122.33 maps to 33-122.balibg.com,but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Mar 17 16:48:14 k2 sshd[9612]: User root from 87.116.122.33 not allowed because not listed in AllowUsers
Mar 17 16:48:17 k2 sshd[9614]: Address 87.116.122.33 maps to 33-122.balibg.com,but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Mar 17 16:48:17 k2 sshd[9614]: User root from 87.116.122.33 not allowed because not listed in AllowUsers
Mar 17 16:48:19 k2 sshd[9616]: Address 87.116.122.33 maps to 33-122.balibg.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Mar 17 16:48:19 k2 sshd[9616]: Invalid user apple from 87.116.122.33
...
/3/
Mar 19 00:01:58 k2 sshd[5421]: Invalid user administrador from 81.8.50.12
Mar 19 00:01:59 k2 sshd[5423]: Invalid user publica from 81.8.50.12
Mar 19 00:02:00 k2 sshd[5425]: Invalid user rbecerril from 81.8.50.12
...
/4/
Mar 19 00:02:27 k2 sshd[5452]: refused connect from ::ffff:81.8.50.12(::ffff:81.8.50.12)
...
/5/
Mar 19 21:18:24 k2 sshd[12785]: Address 192.168.1.3 maps to k2.arend-whv.de, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 21:18:24 k2 sshd[12785]: User root from 192.168.1.3 not allowed because not listed in AllowUsers
Mar 19 21:18:27 k2 sshd[12785]: error: PAM: Authentication failure for illegal user root from 192.168.1.3
Mar 19 21:18:27 k2 sshd[12785]: Failed keyboard-interactive/pam for invalid user root from 192.168.1.3 port 15505 ssh2
...
/6/
Mar 19 21:22:35 k2 sshd[12801]: Accepted publickey for nx from 192.168.2.191 port 1936 ssh2
Mar 19 21:22:37 k2 sshd[12827]: Accepted keyboard-interactive/pam for thomas from 127.0.0.1 port 13462 ssh2
...
/7/
Mar 19 23:16:59 k2 sshd[4686]: Accepted publickey for thomas from 192.168.2.191 port 15974 ssh2

Programme oder Scripte zur Erkennung der Angriffe

Im folgenden möchte ich die Vor- und Nachteile der Programme untersuchen.

Netfilter

Das folgende Script block-ssh richtet einen Filter mittels iptables ein. Es basiert auf einem Vorschlag aus dem Block von Andrew Pollock. In der Regel verwenden diese Scripte den append-Befehl und fügen die Regeln am Ende ein, was dazu führen kann, dass sie nie ausgeführt werden. Deshalb nutze ich den insert-Befehl, der die Regeln an den Anfang der Kette setzt.

Das Script basiert auf der einfachen Annahme, dass es sich um einen Angriff handelt, wenn viele Verbindungsversuche von einer IP-Adresse stattfinden. Die Zahl der zulässigen Verbindungsversuche wird in der Variablen $MAXHITS festgelegt.

#!/bin/sh
#
# block-ssh
# Author: Thomas Arend; thomas\at\arend-whv.de
# basierend auf einem Vorschlag von Andrew Pollock
#
#
# Blockieren des ssh ports nach mehr als $MAXHITS-1 Verbindungsaufnahmen pro Minute.
#

iptables=/usr/sbin/iptables
MAXHITS=7

$iptables -N SSH_WHITELIST
$iptables -A SSH_WHITELIST -s 192.168.0.0/16 -m recent --remove --name SSH -j ACCEPT


$iptables -I INPUT 1 -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
$iptables -I INPUT 2 -i eth1 -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
$iptables -I INPUT 3 -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount $MAXHITS --rttl \
--name SSH -j LOG --log-ip-options --log-prefix "SSH_brute_force "
$iptables -I INPUT 4 -i eth1 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount $MAXHITS --rttl \
--name SSH -j DROP

Unter SuSEfirewall2 besteht auch die Möglichkeit dies in die Custumrules einzufügen. Beispiel siehe hier

Beispiel: Log-Einträge eines Angriffes

Mar 24 17:15:14 k2 kernel: SFW2-INext-ACC-TCP IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=42372 DF
	PROTO=TCP SPT=57801 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT
	(020405AC0402080A7FA449550000000001030302)
Mar 24 17:15:16 k2 kernel: SFW2-INext-ACC-TCP IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=5407 DF
	PROTO=TCP SPT=57973 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT
	(020405AC0402080A7FA450840000000001030302)
Mar 24 17:15:18 k2 kernel: SFW2-INext-ACC-TCP IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=19974 DF
	PROTO=TCP SPT=58126 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT
	(020405AC0402080A7FA4576A0000000001030302)
Mar 24 17:15:19 k2 kernel: SFW2-INext-ACC-TCP IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=41449 DF
	PROTO=TCP SPT=58291 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT
	(020405AC0402080A7FA45E2C0000000001030302)
Mar 24 17:15:21 k2 kernel: SFW2-INext-ACC-TCP IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=15016 DF
	PROTO=TCP SPT=58439 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 OPT
	(020405AC0402080A7FA464EC0000000001030302)
Mar 24 17:15:25 k2 kernel: SSH_brute_force IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=6593 DF
	PROTO=TCP SPT=58741 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 24 17:15:28 k2 kernel: SSH_brute_force IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=6594 DF
	PROTO=TCP SPT=58741 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Mar 24 17:15:34 k2 kernel: SSH_brute_force IN=eth1 OUT=
	MAC=00:50:22:e8:2f:6f:00:15:0c:ef:71:32:08:00 SRC=190.144.35.210
	DST=192.168.1.3 LEN=60 TOS=0x10 PREC=0x00 TTL=52 ID=6595 DF
	PROTO=TCP SPT=58741 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0

Nach wenigen Versuchen ist der Angreifer gebannt.

Vorteile

Der Filter ist transparent für den Nutzer und einfach zu installieren; die notwendigen Kenntnisse vorausgesetzt.

Der Filter reagiert durch die Einbindung in die Firewall sehr schnell auf massive Angriffe, d.h. der Angreifer versucht es mit mehr als $MAXHITS Verbindungen pro Minute, was in der Regel bei Werten zwischen drei und zehn der Fall sein dürfte.

Whitelist der eigenen oder bekannter Adressen möglich.

Nachteile

Der Filter unterscheidet nicht zwischen erfolgreichen und nicht erfolgreichen Anmeldungen.

Der Filter muss individuell in die eigene Firewall eingepasst werden und erfordert Kenntnisse über Netfilter.

Die Liste der zu blockierenden Adressen geht bei einem Neustart der Firewall verloren.

pam abl

pam abl ist ein Tool, das mit Hilfe von pam automatisch eine Blacklist anhand falscher Kennworteingaben generiert. Die Anfragen werden in einer Berkley DB gespeichert und der Zugriff bei überschreiten eines Schwellwertes fehlerhafter Anmeldeversuche von einem Host / User in einer bestimmbaren Zeitspanne blockiert.

tbc

Vorteile
Nachteile

sshdfilter

sshdfilter blockiert die SSH Angriffe mittels Netfilter. Im Gegensatz zu den einfachen Mitteln des block-ssh script wertet das Script die Log-Eintrage des sshd aus. Dazu wird das Loging per named pipe über den Filter gelenkt, der so ereignisgesteuert reagieren kann.

tbc

Vorteile

Da der Filter direkt die Log-Einträge des sshd erhält reagiert sehr schnell ereignisgesteuert auf die Angriffe. Bestimmte Aktionen führen sofort andere nach wenigen Versuchen zum Bann des Angreifers.

Der Filter unterscheidet zwischen erfolgreichen und nicht erfolgreichen Anmeldeversuchen.

Nachteile

Fail2Ban

Fail2Ban

tbc

DenyHosts

DenyHosts läuft als Daemon oder kann per Hand oder Cron Job gestartet werden. Es nutzt den tcpwrapper (/etc/hosts.deny) um Angriffe zu blockieren. Als Daemon gestartet durchsucht das Scropt in der Standardeinstellung alle 30 Sekunden das Log nach sshd Einträgen. Diese Zeitspanne ist jedoch länger als ein durchschnittlicher Angriff. Eine kürzere Zeitspanne würde jedoch die Systemlast erhöhen, auch wenn sich DenyHosts merkt, bis zu welcher Stelle das Log durchsucht wurde.

tbc

Vorteile

Erkennt Angriffe anhand der Log-Einträge des sshd und unterscheidet zwischen erfolgreichen und nicht erfolgreichen Anmeldungen.

Transparent für den Nutzer.

Nachteile
Wird zeitgesteuert aufgerufen um das Log-File auszuwerten. Reagiert daher zeitverzögert auf Angriffe. Der Angreifer ist zwischen zwei Aufrufen ungestört und könnte bei schwachen Passwörtern vor dem nächsten Aufruf zum Ziel kommen.

sshblock.sh

Das Shell Script sshblock.ssh von Rainer Wichmann nutzt den tcpwrapper und wird bei jedem ssh-Verbindungsversuch aufgerufen. Dies macht es möglich, Angriffe frühzeitig ereignisgesteuert zu erkennen. Es wertet jedoch nicht die Log-Einträge des sshd aus.

Das Script nimmt an, dass ein Angriff vorliegt, wenn innerhalb einer bestimmbaren Zeitspanne (Default 60 Sekunden) mehr als eine bestimmbare Anzahl (Default 5) Verbindungsversuche unternommen werden. Dies mag in vielen Fällen ausreichend sein, aber es unterscheidet nicht zwischen erfolgreichen Verbindungen und nicht erfolgreichen. Durch seine Einbindung in den tcpwrapper reagiert es jedoch sehr schnell auf Angriffe. Zur Bestimmung optimalen Zeitspanne sollte man die Log-Einträge (natürlich ohne aktiven sshblock.sh)auswerten und die durchschnittliche Dauer der Angriffe ermitteln. Nach einer bestimmbaren Zeit (Default 3600 Sekunden / 1 Stunde) werden die IP-Adressen wieder frei gegeben.

Bad Guys List

Ein Angriff muss bei den meisten Techniken vom Rechner selbst erkannt werden. Wer mehrere Server im Internet betreibt, sollte die Informationen über die Angriffe auf die anderen Server übertragen und sich so einen Vorsprung vor dem Angreifer verschaffen. Nachdem der ersten Angriff erkannt ist, wären alle anderen Rechner geschützt.

Ein schneller, allgemeiner Austausch der IP-Adressen der bösen Buben über Listen würde die Angreifer nach wenigen Minuten ins Leere laufen lassen.

In der Datei badguys.txt stelle ich meine aktuelle Liste der Badguys bereit, die von "DenyHosts" aus den Angriffen auf meinen Server erstellt wird. Die Datei können Sie herunterladen an Ihre /etc/hosts.deny anhängen.

Links

1. Rainer Wichmann: "Defending against brute force ssh attacks" >

2. tech.tolero.org: ssh password brute force protection >

3. Andy Armstrong (hexten.net): Pam abl (Wiki) >

4. Andy Armstrong (hexten.net): The Auto Blacklist Module: pam_abl (Dokumentation) >

5. pwgen (Linux) >

6. PWGen (Windows) >

7. cert.uni-stuttgart.de: Increase in SSH scans >

8. www.derkeiler.com Steady increase in ssh scans>

9. Christian Seifert (2006-09-11): Analyzing Malicious SSH Login Attempts >

10. Brian Hatch (2004-11-03): SSH User Identities >

11. Brian Hatch (2004-11-23):SSH and ssh-agent >

12. Andrew Pollock: Blog Entry from 02-16-2005 >

Beschreibungen oder Download

sshdfilter