SSH absichern, Server schonen, ruhiger schlafen

Furchtbar diese Script Kiddies. Schau ich mir mit

cat /var/log/messages | grep sshd | wc -l

an, was der SSH deamon heute so getrieben hat, bekomme ich 8327 heraus. Das sind ganz grob 8320 Versuche in meinen Server einzusteigen seit 1:30 (logrotate) bis jetzt, 23:56Uhr. Alle 10 Sekunden ein Angriff. Das nervt. Und es ist nur Statistik, denn in der Regel kommen die Anfragen in Zyklen geballt auf einmal. Nicht nur, dass immer mal die Chance besteht Erfolg oder Pech zu haben (je nach Seite), es strapaziert auch unnötig die Ressourcen des Servers. Was tun?Absichern! Mit failtoban hantiere ich schon eine ganze Weile, aber es geht auch einfacher. Der SSH Dienst lässt sich auf vielfältigste Weise relativ schnell so absichern, dass man ein wenig ruhiger schlafen kann und ein paar Leute weniger hört, die draußen vor dem Tor die Füße gegen die Zarge knallen. Die Änderungen sind in der SSH Konfigurationsdatei vorzunehmen, vorzugsweise liegt diese unter

/etc/ssh/sshd_config

1. Port 4711
   SSH wartet per Definition auf Port 22 auf Anfragen. Das macht die Sache für Angreifer einfach und ist Grund genug, den Port zu ändern. Vielleicht irgendwas nettes im Vierstelligen?
2. ListenAddress 123.123.123.123
   Unter Umständen laufen auf der Maschine mehrere Interfaces. Und je mehr IP Adressen es werden umso mehr Angriffe über SSH darf man erdulden. Also ist es Zeit hier genau eine IP Adresse einzutragen.
3. AllowUsers eyjafjallajökull
   Wer muss sich überhaupt auf der Kiste einloggen? Standard LAMP Systeme benötigen nicht viele Nutzer, häufig nur genau einen. Und genau der wird hier konfiguriert. Aber wen? root? Nein, denn
4. PermitRootLogin no
   Root sperren wir aus. Ebenso wie der Port ist root als Benutername schon eine ziemlich einfach zu erratende Variable. Mit sudo erledigen wir dann die wirklich wichtigen Dinge, der login läuft dann über den User eyjafjallajökull oder jeden anderen denkbaren (und eingerichteten!) Account.
5. MaxStartups 3
   Wenn man erst kein Glück hat, und dann auch noch Pech dazu kommt, toben sich auch noch mehrere Zeitvertreiber gleichzeitig am Tor aus. Also beschränken wir die von ssh maximal offenen Loginversuche einfach.
6. MaxAuthTries 3
   Wer dreimal falsch lag kann nach Hause gehen. Es liegt in der Natur der Sache, dass nicht direkt der erste Brute-Force Erfolg hat, also versucht man es weiter. Aber nach 3 mal Karussell mag SSH dann nicht mehr.

   Wenn das auch alles noch nicht geholfen hat hilft nur die Besinnung auf alte Werte: Rauf auf die Brüstung mit den Pechkesseln! Der Vollständigkeit halber:

7. Protocol 2
   Das ist auf halbwegs modernen Kisten sowieso der Fall.

Für die Paranoiker, Passwortvergesser und Zwei-Finger-Suchsystem-Tipper gibt es dann noch die Authentifizierung mittel RSA Key, da gehe ich vielleicht später mal noch drauf ein, so paranoid bin ich noch nicht. Nein, eigentlich liegt das nicht am Bedürfnis der Absicherung, sondern am Handling. Ein (anstädniges) Passwort im Kopf scheint mir sicherer als eine Datei auf der Workstation und ist darüber hinaus universeller.
Als letztes: SSH neu starten!

/etc/init.d/sshd restart

Wer über SSH selbst den Dienst konfiguriert hat, was bei Webservern der Fall sein wird, sollte in einem zweiten Terminal dann schauen, ob man sich erfolgreich einloggen kann, bevor man das eigentliche Terminal schließt. Sonst läuft man bei Fehlkonfiguration Gefahr sich selbst auszusperren. Lästige Kiste.

Mit failtoban oder DenyHosts kann man dann auch noch die messages und Konsorten auswerten und die entsprechenden Angreifer über iptables blocken (lassen). Das ist gerade deshalb nett, weil sie damit noch weit früher und Einfallstor übergreifend zum Teufel geschickt werden können. Was vergessen? Nächstes mal gibts auch wieder ein Bildchen, aber ich muss mir so viel aus dem Berufsleben anderer Leute anhören…

Nachtrag: Wie ich gerade gesehen habe, hat Thomas Falkner in seinem Blog vor bereits 3,5 Jahren einen ziemlich sinngleichen Artikel geschrieben. Ist auch schön, und ausführlicher in Bezug auf PubkeyAuthentication.