SSH Angriffe blockieren

[vgwort line=“29″ server=“vg08″ openid=“cfaaeb96a2d34038b09111bf59848af2″]

Thema: Verteidigung gegen brute force ssh attacks / ssh-Angriffe abwehren

Thomas Arend, 21. März 2008
Update: 21. September 2011

Schon seit über 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 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. Trotz zahlreicher Hinweise, wie man seinen Rechner gegn solche Angriffe schützt,finden sich offensichtlich noch ausreichend Opfer, sonst würden diese Angriffe lohnenderen Methoden weichen. Mein VServer und mein über DSL am Internet hängender Rechner erhält jedenfalls mehrmals täglich Besuch.

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 nur wenige Angriffe auf meinen Rechner (angebunden mit DSL-16000) länger als 20 Sekunden, einige jedoch auch 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 weinige Server Tage oder Wochen später nochmals vorbei schauen. 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önnte 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.

Verwendet der Provider des Angreifers einen privaten Adressraum (10.0.0.0/8), wie viele Mobilfunk-Provider, dann kommen die Angriffe über einen Proxy Server und würden alle Kunden des Providers ausgesperrt, wenn man die Adresse des Proxies blockiert. Nicht unbedingt wünschenswert. Ist man selber Kunde eines Providers, von dem auch Angriffe ausgehen, kann die Verwaltung des eigenen Servers über Mobiltelefon, Netbook oder Tablet auf ein selbst produziertes Hindernis stoßen.

Sie kommen selten zweimal

Geht davon aus, dass der Angreifer für eine erste Prüfung des Port 22 etwa 1 Sekunde benötigt, so dauert es etwa 1000 Tage oder gut drei Jahre um 100 Millionen Rechner zu scannen. Ein Rechner greift daher selten zweimal an. Dennoch habe ich in seltenen Fällen beobachtet, dass mein Server nach einigen Tagen von der gleichen IP-Adresse ein zweites Mal angegriffen wurde. Ursache könnte ein Programmneustart sein oder mehrere Angreifer, die über einen Proxy ins Internet gehen. Die gute Nachricht: Da die Angriffe meist alle nach dem gleichen Strickmuster erfolgen, wird ein Server, wenn er den ersten Angriff überstanden hat, auch alle weiteren überstehen.

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. Es trainiert das Gedächtnis und nach einer Weile kann man sich sogar mehrere merken. Nur einen längeren Urlaub überdauert sie manchmal nicht, zumindest wenn ich gezwungen werde, sie laufend zu ändern. Zugegeben in solchen Fällen verwende ich ein Kennwort mehrfach, allerdings nie im Internet die gleichen wie zu Hause oder auf der Arbeit. Zu Hause und im Internet hilft ein Password-Safe (kwallet, firefox). Wirklich zufällige Kennwörter können problemlos länger verwenden, da es fast unmöglich ist diese mit drei oder sechs Fehlversuchen zu erraten. Bisher haben 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.

Dazu muss der Nutzer ein Schlüsselpaar erzeugen und der öffentliche Schlüssel in ~/.shh/authorized_keys auf dem Server speichern. Der geheime Schlüssel wird auf dem lokalen Rechner und ~/.shh/id_rsa gespeichert. Grundsätzlich können über dieses Verfahren auch mehrere Nutzer Zugang zu einem Account haben, ohne das Passwort des Accounts auf dem Server zu kennen. Aber mittels sudo gibt es bessere Möglichkeiten, dass mehrere Nutzer einen Server verwalten.

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. Ob dies ein Vorteil ist?

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 Eindring 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 Datei /etc/ssh/sshd_conf mit z.B „AllowUsers nx …“ freigeben. Achtung: Setzen Sie „nx“ von NoMachine ein, müssen Sie nx hier erlauben.

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ück lehnen, aber die Angriffe kosten auch Ressourcen und so ist es sinnvoll, ein wenig in die Erkennung zu investieren, um sie frühzeitig, d.h. mit möglichst wenig eigenen Ressourcen, abzublocken. Außerdem ist es durchaus sinnvoll, Angriffe nach – sagen wir mal vier Fehlversuchen von einer IP-Adresse – zu blockieren, bevor der Nutzer deaktiviert 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 User 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. [Je nach Konfiguration des syslog-ng in /var/log/messages oder /var/log/auth]

/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

Seit einiger Zeit laufen die Angriffe koordiniert von mehren Host wie im folgenden Listing. In diesem Fall sind Gegenmaßnahmen recht schwer zu treffen. Jeder Host versucht es nur einmal mit einer Userid. Die gängigen Maßnahmen sind unwirksam. Die Zeiten zwischen den Login-Versuchen variiert. So ein Angriff kann einige Stunden dauern und es ist dabei nicht einmal klar, ob es ein oder mehrere Bot-Netze sind, die hier angreifen oder zusammenarbeiten.

Sep  4 18:02:01 h1383963 sshd[11956]: Invalid user asterisk from 85.14.218.104
Sep  4 18:03:10 h1383963 sshd[12013]: Invalid user asterisk from 71.244.86.168
Sep  4 18:03:52 h1383963 sshd[12024]: Invalid user asterisk from 119.113.0.4
Sep  4 18:04:17 h1383963 sshd[12041]: Invalid user asterisk from 208.191.112.212
Sep  4 18:04:37 h1383963 sshd[12276]: Invalid user portage from 76.221.76.129
Sep  4 18:05:15 h1383963 sshd[13368]: Invalid user portage from 62.38.242.231
Sep  4 18:05:39 h1383963 sshd[13376]: Invalid user portage from 69.27.242.70
Sep  4 18:06:06 h1383963 sshd[13390]: Invalid user portage from 190.12.83.137

Sep  4 18:06:24 h1383963 sshd[13402]: Invalid user portage from 62.72.110.203
Sep  4 18:07:05 h1383963 sshd[13419]: Invalid user portage from 216.26.140.77
Sep  4 18:08:13 h1383963 sshd[13463]: Invalid user dovecot from 216.197.204.76
Sep  4 18:08:38 h1383963 sshd[13475]: Invalid user dovecot from 81.80.90.88
Sep  4 18:08:55 h1383963 sshd[13481]: Invalid user dovecot from 69.60.118.191
Sep  4 18:09:37 h1383963 sshd[13736]: Invalid user dovecot from 69.64.166.23
Sep  4 18:09:48 h1383963 sshd[13760]: Invalid user dovecot from 189.43.21.244
Sep  4 18:10:47 h1383963 sshd[13815]: Invalid user fax from 190.12.83.137
Sep  4 18:12:18 h1383963 sshd[13886]: Invalid user fax from 123.232.103.130

Sep  4 18:12:39 h1383963 sshd[13904]: Invalid user fax from 119.113.0.4
Sep  4 18:13:47 h1383963 sshd[13950]: Invalid user cyrus from 62.60.136.250
Sep  4 18:14:15 h1383963 sshd[13958]: Invalid user cyrus from 192.150.194.1
Sep  4 18:14:28 h1383963 sshd[14189]: Invalid user cyrus from 82.247.17.134
Sep  4 18:14:56 h1383963 sshd[14204]: Invalid user cyrus from 194.84.60.1
Sep  4 18:15:36 h1383963 sshd[14238]: Invalid user cyrus from 193.226.122.94

Gegen diese Angriffe sind die meisten der folgenden Maßnahmen machtlos, weil sie bisher davon ausgingen, dass der Angriff nur von einem Rechner stattfindet. Hier hilft aber schon mal der Parameter AllowUsers oder AllowGroup in sshd_config. Zusätzlich gibt es noch DenyUsers oder DenyGroup.

Programme oder Scripte zur Erkennung der Angriffe

Im Folgenden beschreibe ich einige Programme und untersuche ihre Vor- und Nachteile.

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
#
# Author: Thomas Arend, Rheinbach 
# Stand: 21.09.2011
# Blockieren des ssh ports nach mehr 
# als n Verbindungsaufnahmen pro Minute.
#

# Program IP-Tables
iptables="/usr/sbin/iptables"

# Zu schützendes Interface
NETDEV="vnet0:0"

# Whitelisten der eigenen Adressen
# Meine (dynamische) IP-Adresse feststellen.
WHITELIST=`host my-dynamic-name.homelinux.net | sed 's#.* ##'`

# Versuche (n+1)
trials=7

[ ! -e "$iptables" ] \
&& echo "Programm $iptables nicht vorhanden" \
&& exit

#  Whitelist erstellen
$iptables -N SSH_WHITELIST0
$iptables -A SSH_WHITELIST0 -s $WHITELIST \
  -m recent --remove --name SSH -j ACCEPT
$iptables -A SSH_WHITELIST0 -s 172.16.0.0/12 \
  -m recent --remove --name SSH -j ACCEPT
$iptables -A SSH_WHITELIST0 -s 192.168.0.0/16 \
  -m recent --remove --name SSH -j ACCEPT

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

Unter SuSEfirewall2 besteht auch die Möglichkeit dies in die Custumrules [/etc/sysconfig/scripts/SuSEfirewall2-custom] einzufügen. Beispiel siehe hier. Wer keine eingenen Regeln hat, kann die Datei – auf eigenes Risiko versteht sich – nutzen. [Achtung: Auf meinem Strato-VServer mit PLESK 8.3 funktioniert dies nicht, obwohl es die Datei und die SuSEFirewall2 gibt. Offensichtlich sind nicht alle Funktionalitäten der iptables eingebunden.]

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.

Angriffe werden bereits auf Packetebene erkannt und abgewiesen.

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.

Der Filter wirkt nicht gegen verteilte Angriffe, da die Verteidigung auf der IP-Adresse bassiert.

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 wertet das Script in der Standardeinstellung alle 30 Sekunden das Log nach sshd Einträgen aus. 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.

Erfahrungen

Ich habe DenyHosts seit einigen Wochen mit dem Netfilter block-ssh (als SuSEFirewall Custom Rules) laufen. Der Netfilter blockiert die Angriffe so frühzeitig, dass DenyHosts nur ein Teil der IP-Adressen in /etc/hosts.deny einträgt. Der Angriff schreitet nicht so weit fort, dass genug auswertbare Versuche im Log landen.

sshblock.sh

Das Shell Script sshblock.sh 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 der 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.

Vorteile

Der Filter ist transparent für den Nutzer und einfach zu installieren.

Der Filter reagiert durch die Einbindung in den TCP-Wrapper 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.

Die Liste der zu blockierenden Adressen bleibt bei einem Neustart des Systems erhalten. [Vergleiche block-ssh]

Whitelisting der eigenen oder bekannter Adressen ist möglich.

Nachteile

Der Filter unterscheidet nicht zwischen erfolgreichen und nicht erfolgreichen Anmeldungen, eine Erweiterung wäre aber möglich.

Angriffe dringen zumindest bis zum TCP-Wrapper vor.

Keine Blockierung auf Packetebene, wäre aber ebenso möglich wie prüfen der sshd Log-Einträge.

Auch hier erfolgt die Erkennung und Blockade über Angriffe von einer IP-Adresse. Verteilte Angriffe lassen sich damit nicht abwehren.

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 badguyslist.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.

Tipp: Wer mir grenzenlos vertraut versuche es mit: wget -O – http://byggvir.de/Linux/badguyslist.txt >>/etc/hosts.deny

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 >

13. Server-Wissen.de >

14. Josef Ender: SSH Brute Force Angriffe abwehren >

Beschreibungen oder Download

sshdfilter