Seit vielen Jahren habe ich schon diverse Server am laufen, viele davon sind direkt aus dem Internet erreichbar. Wer direkt aus dem Internet erreichbar ist, kann auch direkt über das Internet angegriffen werden. Ein gängiges und beliebtes Ziel für Angriffe ist der SSH Dienst, die Gründe dafür dürften zum einen dessen Verbreitung (jeder Linux Server hat diesen) und dessen Möglichkeiten (Shellzugang) sein.

In der Praxis gibt es viele Rechner im Internet welche automatisch nach verwundbaren SSH Versionen oder ungeschützten Zugängen (kein oder ein schlechtes Passwort) suchen. Das Problem mit den ungeschützten Zugängen löst man heute in der Regel mittels Public-Key-Authentifizierung, und die Sache mit den verwundbaren SSH Versionen lösen wir mit Updates. Als Administrator wissen wir das SSH sofort nach einem verfügbaren Update auch aktualisiert (und neu gestartet) werden muss.

In der Regel haben wir also mit SSH sehr wenig Probleme, das einzige was noch bleibt sind die vielen Meldungen welche uns die Angreifer im Logfile hinterlässt:

Mar 19 08:03:39 host.stefan-betz.net sshd[2967]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:43 host.stefan-betz.net sshd[2981]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:43 host.stefan-betz.net sshd[2981]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:46 host.stefan-betz.net sshd[2999]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:46 host.stefan-betz.net sshd[2999]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:49 host.stefan-betz.net sshd[3025]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:51 host.stefan-betz.net sshd[3025]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:56 host.stefan-betz.net sshd[3057]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:56 host.stefan-betz.net sshd[3057]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:04:00 host.stefan-betz.net sshd[3087]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!

Ein wirksamer Schutz dies zu verhindern ist es die maximale Anzahl von Verbindungen auf einen bestimmten Dienst innerhalb einer bestimmten Zeit zu verhindern. Eine andere, von mir jedoch nicht benutzte Maßnahme, sind Dienste welche in den Logfiles schauen was passiert und dann diese IP Adressen sperren. Ich selbst bevorzuge immer Lösungen welche ohne zusätzliche Software auskommen, mit dem Hintergrund das jede Software die zusätzlich installiert wird auch zusätzliche Angriffsfläche zu Verfügung stellt.

Das filtern von IP Paketen ist unter Linux die Aufgabe von iptables, und daher nutze ich dies auch zur Absicherung meiner SSH Zugänge. Konkret werden folgende Regeln benötigt:

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --set --name SSH --rsource
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --update --seconds 60 --hitcount 4 --name SSH --rsource -j REJECT \
  --reject-with icmp-port-unreachable
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --set --name SSH --rsource
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --update --seconds 60 --hitcount 4 --name SSH --rsource -j REJECT
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT

Wenn diese Befehle ausgeführt werden hat man 3 zusätzliche Regeln in seinem Paketfilter vom System installiert. Die erste Regel sorgt dafür das alle Pakete welche den SSH Dienst erreichen möchten, und den Status NEW haben erfasst und dem recent Modul bekannt gemacht werden. Das recent Modul führt eine Liste von Adressen und Ports und kann auf diese verschiedene Aktionen anwendern, z.B. prüfen wann zuletzt ein Paket von dieser Adresse kam.

Genau das machen wir uns bei der zweiten Regel zu nutze, jedes Paket muss auch durch diese Regel (die erste hat keine Aktion ausgeführt). Hier passiert aber was, und zwar wird bei jedem Paket (gleicher Status) ein Zähler aktualisiert auf den aktuellen Wert, gleichzeitig wird geprüft ob es das 4. Paket innerhalb von 60 Sekunden ist. Ist dies der Fall wird der Verbindungsaufbau abgelehnt, und unser Angreifer wird sich relativ schnell ein anderes Ziel suchen.

Die letzte Regel ist Optional wenn man keine weiteren Regeln hat, sie sorgt lediglich dafür das eingehende SSH Anfragen erlaubt werden. Da Regeln der Reihe nach abgearbeitet werden ist dies sehr sinnvoll, um sich nicht versehentlich von seinem System auszusperren. Einen kompletten Paketfilter werde ich an dieser stelle nicht Beschreiben.

Die Maßnahme hat genauso wie alle anderen Systeme die auf das sperren einer IP Adresse aufbauen natürlich auch einen Nachteil: Sitzt man zusammen mit dem Angreifer hinter einem NAT kommt man auch selbst nicht mehr auf den Server, die "angreifende" IP ist nämlich immer die gleiche. Hat man sich selbst ausgesperrt kann man einfach eine Minute warten, dann sind neue Verbindungen zum SSH Dienst wieder möglich, mal davon ausgehend das der böse Angreifer nicht immer noch im eigenen Netz sitzt und die Nachteile von NAT ausnutzt.