Moin
a) Ein key-based-login ist nicht sichererer als ein gut gesicherter Login mit einem komplexen und sicheren Passwort. Die Umstellung auf den key-based Login ist also per se kein Grund den root-login auf einmal zu erlauben zu erlauben.
b) root ist ein bekannter Angriffsvektor. Deshalb verwendet man einen anderen User, dessen User-ID nicht offensichtlich (leicht zu erraten) ist.
Du könntest auch root umbenennen. Damit schaffst Du aber andere Probleme.
c) Wenn ein Angreifer erst mal einen shell-Zugang auf deinem System hat, kann er sich auch zugriff auf den root-Account verschaffen. Du solltest daher alle Maßnahmen ergreifen, damit ein Angreifer keinen Shell-Zugang bekommt.
Meine Empfehlung. Bleib bei key-Login und non-root-User
Mordor
Mordor, ich kann dir nicht folgen. Kannst du mir bitte für a) und c) ein Beispiel geben?
Ich glaube er meint bei c), dass man also nicht-root eben erstmal keine root-Rechte hat und noch einen zusätzlichen Schutz überwinden muss.
Moin
Kannst du mir bitte für a) und c) ein Beispiel geben?
zu a) Ein Key ist im Prinzip nur ein langes und sicheres Passwort. Du bekommst also keine höhere Sicherheit, nur weil Du eine Key-basierte Anmeldung verwendest.
Das Verfahren ist in der Praxis nur deshalb sicherer, weil die meisten Menschen eben keine sicheren Passwörter verwenden können/wollen und man beim Key-Verfahren wahrscheinlich (!) keine schlechten Keys erstellen kann. Ein schlecht gesicherter Key (ohne gutes Passwort) auf dem Client, kann die Sicherheit aber leicht aushebeln und dann ist das Key-basierte Verfahren insgesamt auf einmal unsicherer, als ein Login mit
einem guten Passwort.
Oder kurz:
Die Argumentation "Ich verwende jetzt Keys zur Anmeldung und deshalb darf sich root direkt anmelden ohne die Sciherheit zu verringern" ist so falsch.
zu c) Wenn ich einen Shell-Zugang auf einem System habe, finde ich auch eine Möglichkeit um mir irgendwie Root-Rechte zu verschaffen. Dazu muss ich das Passwort für den root-Zugang nicht rausfinden. Wichtig ist daher, das Du den Login-Account genauso gut absicherst, als wäre es der root-Account. Sonst bringt Dir der User-Account keine zusätzliche Sicherheit.
Mordor
zu a) Ein Key ist im Prinzip nur ein langes und sicheres Passwort. Du bekommst also keine höhere Sicherheit, nur weil Du eine Key-basierte Anmeldung verwendest.
Moment, der Key wird hier aber nicht als Passwort verwendet. Der Key wird für ein Challenge-Response Verfahren verwendet, über welches der Benutzer dann authentifiziert wird (Server schickt Client eine Challenge, welche vom Client beantwortet (=verschlüsselt mit Key) wird). Im Prinzip bekommt man hier dann doch eine höhere Sicherheit, weil man einen Key nicht so leicht angreifen kann wie ein Passwort (Brute-Force).
Danke johnassel 
a) Schlüssel werden auch nicht so oft benutzt wie Passwörter, d.h. es werden primär Passwörter angegriffen.
b) Da stimme ich dir zu, Mordor. root sollte keinen direkten, externen Zugang haben. Irgendeinen Benutzer anlegen reicht aus und mit diesem dann einloggen. Aber im Hinterkopf mit d).
c) Wenn ich einen Shell-Zugang habe, dann bin ich nicht automatisch root. Dafür muss ich ja noch weitere Dienste angreifen. Ausserdem ist sudo ist ja nicht für z.B. den Webserver möglich. Was aber effektiv egal ist, denn auch als Webserver kann ich z.B. Spam verschicken oder weitere Software runterladen und ausführen (z.B. IRC-Proxy, ftp-Server installieren, etc). Mehr Sicherheit bekommst du mit z.B. selinux. Ich halte das für einen (simplen) (v)Server übertrieben. Hier geht es nicht um kritische Daten.
d) IP-Bereich für den SSH begrenzen. Klingt simpel, wird aber gerne übersehen. Wieso sollte man aus z.B. China einen SSH-Zugriff auf den Server erlauben? Und wer ist so dumm und greift Server im eigenen Land bzw. noch beim eigenen Provider an? Daher macht es Sinn den Bereich auf seinen eigenen DSL-Provider, Schule/Uni/Arbeitgeber sowie eventuell Freunde zu begrenzen.
Hier im Forum wird dagegen immer wieder vorgeschlagen, SSH, etc global zu erlauben und dann potentielle Angreifer über fehlgeschlagene Logins per fail2ban zu sperren. Leider wird hierbei übersehen, dass dieses nicht gegen eine Sicherheitslücke im SSH-Server hilft, denn dieser wird dennoch die ersten 2, 3 Logins annehmen. Genau solche Sicherheitslücken gab es in der Vergangenheit Konsequenzen des OpenSSL-Debakels | heise Security und wird es auch immer wieder geben.
