SSH absichern – BASICS – „root“ Benutzer nicht einloggen lassen

Die zweite Maßnahme schlägt in eine ähnliche Kerbe wie die erste. Wir ändern eine Konstante („root“) in eine Variable („neuer Nutzer“) und erschweren es den Crackern und ihren Scripts damit noch weiter, über SSH in unseren Server einzubrechen.

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

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

Wenn nur ein Benutzer auf dem Server konfiguriert ist, dürfte das „root“ sein. Eine Loginmöglichkeit für den „root“ Benutzer ist aber generell eine schlechte Idee. Schlecht, weil der Benutzername bekannt ist und jeder Bot den als ersten ausprobiert. Schlecht, weil „root“ alle Macht auf dem Server hat und beliebig Befehle absetzen kann. Wird „root“ gekapert, sind wir erst mal erledigt…

Sogar Microsoft hat verstanden, dass man die Benutzer nicht als „Administrator“ arbeiten lassen soll, da dieser privilegierte Benutzer in der Windows-Welt das Angriffsziel Nummer Eins war. Auf vielen LAN-Parties in der Windows 2000 Ära war der „Administrator“ ohne Passwort gang und gäbe. Damit wurde über das Netz unglaublich viel Schindluder getrieben…

Aber zurück zu unserem Server: Um dem Problem entgegenzuwirken, legen wir uns einen zweiten Benutzer an und statten diesen mit „sudo“-Rechten aus. Das bedeutet, dass sich unser neuer Benutzer durch den „sudo“-Befehl gefolgt von einer Passworteingabe „root“-Rechte aneignen kann. Ist das geschehen, müssen wir verhindern, dass unser Server zukünftig per SSH den User „root“ einloggen lässt. Ab dann melden wir uns ausschließlich mit dem neuen Benutzer an.

Legen wir also einen neuen Benutzer an. Unter Debian hilft uns dabei das Dienstprogramm adduser.
Ich nenne meinen Benutzer in dieser Anleitung „bla“. Bitte wähle einen besseren Namen für Deinen Benutzer :)

adduser bla
Wir müssen nun zwei Mal das selbe Passwort für den neuen User eingeben. Das können wir uns über pwgen erzeugen. Es sollte mindestens 64 Zeichen lang sein!
Dann folgen einige Abfragen für weitere Details zum Benutzer. Diese können wir aber alle mit „Enter“ überspringen. Als letztes werden wir gefragt, ob die Einstellungen passen und der Benutzer angelegt werden soll. Wir quittieren das mit „Y“ und „Enter“.

Wunderbar, der neue Benutzer „bla“ wurde damit auf dem Server erstellt.

Nun statten wir ihn mit mehr Rechten aus. Dazu bearbeiten wir mit folgendem Befehl eine Konfigurationsdatei:
visudo -f /etc/sudoers.d/server

In dieser Datei fügen wir eine Zeile für unseren Benutzer hinzu (in Deinem Fall bitte „bla“ durch Deinen Benutzernamen ersetzen):
bla ALL=(ALL:ALL) ALL

Das wären dann die maximalen Rechte für „bla“:

  • ALL= | Darf auf jedem Host Befehle ausführen.
  • (ALL:ALL) | Darf als jeder Benutzer und jede Gruppe Befehle ausführen.
  • ALL | Darf jeden beliebigen Befehl ausführen.

Nachdem der neue Benutzer angelegt und mit zusätzlichen Rechten ausgestattet worden ist, ändern wir eine Zeile in der der Konfigurationsdatei sshd_config:

nano /etc/ssh/sshd_config

Wir suchen die Rubrik # Authentication:
Dort interessiert uns die Option
PermitRootLogin yes

Diese Zeile ändern wir auf
PermitRootLogin no
und speichern die Datei. Damit verbieten wir das Einloggen des Benutzers „root“ über SSH.

Nun ist es wieder enorm wichtig, wie bei der Änderung der Port-Nummer vorzugehen und nach dem Neustart des SSH-Daemons unbedingt mit einer zweiten Verbindung zu testen, ob wir uns als der neue Benutzer wirklich an unserem Server anmelden können und wir über den sudo -i Befehl Root-Rechte bekommen.

Funktioniert alles wie geplant, schließen wir die alte SSH-Verbindung.
Ab diesem Zeitpunkt sollten wir uns nicht mehr als „root“ am Server anmelden können…

Ansonsten heißt es Fehlersuche. Finden wir den Fehler nicht, kopieren wir die Konfigurationsdatei zurück und starten SSH neu.

Geht der Login, ist das Ziel der Übung erreicht :)
Nun muss der Cracker erst unseren Benutzernamen erraten, bevor er versuchen kann, unser Passwort zu brechen!

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.