Linux Server absichern: SSH

Den SSH Zugang abzusichern ist eine der ersten Maßnahmen, um einen sicheren Serverbetrieb zu gewährleisten.

Dieser Befehl
cat /var/log/auth.log | grep -i "fail" | wc -l
zeigt die Anzahl der Angriffsversuche, den Server via SSH brute-force des Passworts, zu übernehmen, an.

Als ich mir hier den VPS, auf dem dckg.net läuft, gemietet habe, das Ding demnach ganz neu und nirgendwo irgendwie bekannt war, kamen die Angriffe schon im 5 Minuten Takt.
Meistens sind es chinesische und russische IP Adressen, vereinzelt auch USA und Afrika, die versuchen, einzubrechen. Manchmal kommt auch gleich ein ganzes /24 Subnet. Loadbalancing, wie bei Google. 😁
Da es öffentliche IP-Datenbanken gibt, in denen viele Details wie z.B. Land, Hoster, etc. aufgeschlüsselt sind, ist es für die Angreifer ein leichtes, potenziell ungesicherte Server ausfindig zu machen.
Stoppt man die Angreifer nicht frühzeitig durch geeignete Software oder Firewallregeln und verwendet darüber hinaus noch ein schwaches SSH-Passwort, dann kann man sich fast schon sicher sein, dass der Server bald übernommen wird.
Spätestens ab diesem Zeitpunkt hat man ein Problem, wer nämlich Server betreibt haftet auch für die entstanden Schäden, die durch mangelnde Absicherung entstehen.

Eine schnelle Lösung: fail2ban
apt-get update && apt-get install fail2ban
Und den SSH Port auf einen anderen Port legen, in der /etc/ssh/sshd_config


Eine sichere Lösung: iptables & Schlüsseldateien
Iptables ist eine Firewall.

Dort stehen verschiedene Methoden zur Minimierung der Angriffsfläche zur Verfügung:

Limit der neuen Verbindungen pro IP pro Zeit:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --name SSH --update --seconds 600 --hitcount 3 -j DROP

Dokumentation

Limit der parallelen Verbidnungen pro IP-(Range)
iptables -A INPUT -p tcp --syn --dport 22 -m connlimit --connlimit-above 2 --connlimit-mask 32 -j DROP
Dokumentation

Für IPv4 reicht die erste Regel. Unglücklicherweise gelten die iptables-Regeln nur für IPv4. IPv6 Regeln werden mit ip6tables gesetzt.
IPv6 macht die erste Regel auch gleich wirkungslos, zumal man als Privatkunde üblicherweise einen /48-IPv6 Block gratis dazu bekommt.
Das sind
1,208,925,819,614,629,174,706,176
IP-Adressen. Angesichts dieser Quantität ergibt es natürlich keinen Sinn mehr, nur neue Verbindungen pro Zeit pro IP zu begrenzen.
Das Connlimit-Modul in Verbindung mit der Subnetzmaske schafft hier Abhilfe, so können die gleichzeitigen Verbindungen pro Subnet begrenzt werden, demzufolge lässt sich auch die erste Regel wieder einsetzen.

Authentifiziert man sich gegenüber dem Server ausschließlich mit einem privat/öffentlichen Schlüsselpaar, kann das erraten der SSH-Zugangsdaten annähernd ausgeschlossen werden.
Dazu in der /etc/ssh/sshd_config nachfolgendes anpassen:
PasswordAuthentication no


Was ist überhaupt ein Schlüsselpaar? Ein Schlüsselpaar besteht aus öffentlichem und privatem Schlüssel, vergleichbar mit einem Schloss (öffentlicher Key), sowie einem Schlüssel (privater Key). Überall wo man den öffentlichen Schlüssel (Schloss) installiert, hat man mit dem privaten Schlüssel (Schlüssel) Zugriff. Es gilt daher, den privaten Schlüssel geheim zu halten.

Ein Schlüsselpaar erstellt man unter Windows mit der puttygen.exe, welche standardmäßig bei PuTTY dabei ist.
Den fertigen Key dann zur
mkdir ~/.ssh
echo hier_öffentlichen_key_einfügen >> ~/.ssh/authorized_keys

authorized_keys Datei hinzufügen.

service ssh restart
Das Fenster des SSH-Clients noch nicht schließen, sondern in einer neuen SSH-Session den Login mit Keyfile versuchen.

Fahrlässigerweise könnte man jetzt annehmen, dass es schon ausreicht, Passwort-basierten Login zu deaktivieren, dementsprechend nur Schlüsseldateien zu nutzen.
In dieser Hinsicht ist der SSH-Zugang zwar gegen fremde Logins durch brute-force geschützt, was von der Komplexität der Keyfiles herrührt (>1024bits). Nichtsdestoweniger bleibt man anfällig für DoS Angriffe, da jeder Loginversuch mittels Schlüsselpaar vom Server Rechenaufwand erfordert.
Eine Firewall ist letztendlich unverzichtbar.