SSH absichern – BASICS – SSH Port ändern

Die erste Maßnahme ist die einfachste, aber zugleich wirkungsvollste: Ein Cracker kann nur das cracken, was er findet. Geht sein Script an uns vorüber, sucht es sich andere, einfachere Ziele, die leichter verwundbar sind.

Aktuell: Ja
System: Linux / Unix generic. Hier vorgestellt auf Debian 7 „Wheezy“

Security through Obscurity!
Ist das Schlagwort für diese Maßnahme.

Bitte sei Dir dessen bewusst: Wenn wir den Port von SSH umziehen, machen wir den Server damit nicht „sicherer“. Wir verzögern nur das Unvermeidliche – dass der Port irgendwann gefunden wird. Diese Maßnahme schützt nur vor Script-Kiddies, welche ausschließlich Port 22 abfragen und unseren Server in Frieden lassen, wenn sie auf „22“ keine Antwort bekommen. Ein Port-Scanner findet unseren umgezogenen SSH-Port. Nur machen sich die meisten Bots halt (zum Glück!) nicht die Mühe…

Stelle es Dir so vor, wie einen Nebelwerfer auf dem Schlachtfeld: Die Schützengräben sind alle in weißen Waber gehüllt. Niemand sieht etwas. Ein Scharfschütze gibt an der Stelle auf. Aber was, wenn der Feind ein Maschinengewehr hat und volle Kanone in den Nebel ballert? Der Nebel spendet keinerlei Schutz vor einem direkten Treffer. Und irgendwann fangen wir uns die Kugel ein. Vielleicht später, vielleicht nicht so oft. Aber „Security through Obscurity“ ist eben kein echter „Schutz“, sondern nur eine „Verschleierung“.

Was wiederum nicht heißen soll, dass die Maßnahme schlecht ist und gar nichts bringt. Gerade die ganzen China- und Osteuropa-Bots lassen unseren Server nach dem Verlegen des Ports in Ruhe… Es soll nur nicht das Gefühl von falscher Sicherheit aufkommen! Die Haustür einzumauern und nur noch durch die Hintertüre zu gehen, wird einen Einbrecher nicht wirklich abhalten, in unser Haus einzubrechen – wenn er es nur fest genug will.

Achtung!
Bitte vor dem Editieren der Konfigurationsdatei eine Sicherheitskopie davon erstellen! In der Einleitung wird beschrieben, wie wir das erledigen…

Botnetze versuchen einen Angriff eigentlich immer über Port „22“, da dieser der Standard-Port für SSH ist. Die erste Maßnahme besteht folgerichtig darin, auf einen anderen Port zu wechseln und die Scripts dadurch ins Leere laufen zu lassen…

Wir editieren dazu die Datei /etc/ssh/sshd_config:
sudo nano /etc/ssh/sshd_config

Die Option, die uns hier interessiert, ist die Port Variable. Statt der „22“ ändern wir die Nummer auf eine andere.

Aber Achtung! Portnummern gehen zwar von 1 bis 65535. Es gibt aber eine Menge von Standard-Ports für alle möglichen Anwendungen. Diese sollten wir natürlich nicht verwenden, um Probleme mit diesen Diensten zu vermeiden…
Hier ist eine Liste auf Wikipedia, „wer“ „wer“ ist:
https://de.wikipedia.org/wiki/Liste_der_standardisierten_Ports

Als Faustregel kann man sagen, dass zwischen 50000 und 65000 eigentlich ein gutes Plätzchen für unseren neuen SSH-Port zu finden sein sollte ;)

Stellen wir ihn testweise mal auf 55444. Dann speichern wir die Datei.

Eine solche Änderung wird erst nach einem Neustart des betreffenden Dienstprogramms wirksam. Bei SSH gibt es dazu eine kleine, aber feine Besonderheit:

Der Daemon hält die bestehenden Verbindungen auch nach einem Neustart offen! Das ist sehr praktisch, denn nach dem Restart des Dienstes sollte es uns die Verbindung kappen. Hätten wir jetzt einen Fehler in der Konfiguration und der Daemon startet nicht mehr – oder startet mit falschen Parametern – dann könnten wir uns nicht mehr an unserem Server anmelden.

Darum ist es von größter Wichtigkeit, direkt und sofort nach dem Neustart von SSH mit einer zweiten, neuen Verbindung zu testen, ob die Einstellungen auch funktionieren und wir uns damit anmelden können!

Also, veranlassen wir einen Neustart von SSH:
sudo service ssh restart

Wir behalten unsere Verbindung und bauen eine neue mit Port 55444 auf.

Erst, wenn die neue Verbindung mit dem neuen Port funktioniert und wir uns anmelden können, dürfen wir die alte Verbindung kappen! GAR KEINES FALLS VORHER !!!

Sollte etwas NICHT funktionieren und wir uns mit der neuen Verbindung NICHT einloggen können, müssen wir den Fehler über die alte Verbindung suchen, beheben und SSH neu starten. Danach probieren wir wieder mit einer neuen Verbindung, ob der Login klappt.

Geht es bis hier hin immer noch nicht, sollten wir das Backup der Konfigurationsdatei wiederherstellen:
sudo cp /etc/ssh/sshd_config_original /etc/ssh/sshd_config

Und dann SSH neu starten. Jetzt sind wir ‚zurück auf Anfang‘ und können analysieren, was schief gelaufen ist. Allerdings sollte das beim Ändern der Port-Nummer noch nicht passieren ;)

Hat es geklappt?
Wunderbar! Damit läuft zukünftig der Angriff der Bots ins Leere und sie prallen bildlich gesprochen an eine Wand, wo früher die „Tür“ von SSH war…

Navigation

< Vorheriger Artikel | Nächster Artikel >

Haftungsausschluss!

Bitte lies Dir den Disclaimer durch, bevor Du eine Anleitung umsetzt...

Anzeige *

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.