Warum ist die Root-Anmeldung über SSH so schlecht, dass jeder rät, sie zu deaktivieren?

83

Jeder im Internet rät dazu, die Root-Anmeldung über SSH zu deaktivieren, da dies eine schlechte Praxis und eine Sicherheitslücke im System darstellt, aber niemand erklärt, warum dies so ist.

Was ist so gefährlich beim Aktivieren der Root-Anmeldung (insbesondere bei deaktivierter Passwortanmeldung)?

Und was ist der Unterschied zwischen dem X-Symbol-Benutzernamen und dem Y-Symbol-Kennwort oder dem Root-Benutzernamen und dem X + Y-Symbol-Kennwort aus Sicherheitsgründen, wenn die Kennwortauthentifizierung zulässig ist?

ssh security root

— eilen
quelle

2

Einen Root-Benutzer in den meisten Systemen zu haben, ist an sich schon schlecht.

— Suman

1

Root Login via ssh ist notwendig für ehealth-aussie.blogspot.com/2012/01/… . Alles ist ein Kompromiss.

— Emory

2

Ähm ... sollten wir diese Frage in Sicherheit bringen? Da das Thema mehr auf Sicherheit als auf * nix Systeme abzielt.

— Braiam

1

Es gibt einen administrativen Grund für die Deaktivierung von root. Auf kommerziellen Servern möchten Sie den Zugriff immer nach Personen steuern. root ist niemals eine Person. Selbst wenn Sie einigen Benutzern den Root-Zugriff erlauben, sollten Sie sie zwingen, sich über ihren eigenen Benutzer anzumelden, und dann su -oder sudo -iso, dass ihre tatsächliche Anmeldung aufgezeichnet werden kann. Dies vereinfacht die Sperrung des gesamten Zugriffs auf eine Person erheblich, sodass sie selbst dann nichts damit anfangen kann, wenn sie über das Root-Kennwort verfügt.

— Philip Couling

62

Warum root über SSH ist schlecht

Es gibt viele Bots, die versuchen, sich über SSH bei Ihrem Computer anzumelden. Diese Bots funktionieren folgendermaßen.

Sie führen so etwas aus ssh root@$IPund probieren dann Standard-Passwörter wie "root" oder "password123" aus. Sie tun dies so lange sie können, bis sie das richtige Passwort gefunden haben. Auf einem weltweit zugänglichen Server können Sie viele Protokolleinträge in Ihren Protokolldateien sehen. Ich kann bis zu 20 pro Minute oder mehr gehen.

Wenn die Angreifer Glück (oder genügend Zeit) haben und ein Passwort finden, haben sie root-Zugriff und das würde bedeuten, dass Sie in Schwierigkeiten sind.

Wenn Sie jedoch nicht zulassen, dass sich root über SSH anmeldet, muss der Bot zuerst einen Benutzernamen und dann das entsprechende Passwort erraten. Nehmen wir also an, die Liste der plausiblen Passwörter enthält NEinträge und die Liste der plausiblen Benutzer enthält Mgroße Einträge. Der Bot muss eine Reihe von N*MEinträgen testen, daher ist es für den Bot etwas schwieriger als für den Root-Fall, bei dem es sich nur um eine Reihe von Größen handelt N.

Einige Leute werden sagen, dass dies Mkein wirklicher Sicherheitsgewinn ist, und ich stimme zu, dass es sich nur um eine kleine Sicherheitsverbesserung handelt. Aber ich stelle mir das eher als diese kleinen Vorhängeschlösser vor, die an sich nicht sicher sind, aber viele Menschen am einfachen Zugang hindern. Dies gilt natürlich nur, wenn Ihr Computer keine anderen Standardbenutzernamen wie tor oder apache hat.

Der bessere Grund, Root nicht zuzulassen, ist, dass Root viel mehr Schaden auf dem Computer anrichten kann als ein Standardbenutzer. Wenn sie also durch Pech Ihr Passwort finden, ist das gesamte System verloren, während Sie mit einem Standardbenutzerkonto nur die Dateien dieses Benutzers manipulieren können (was immer noch sehr schlecht ist).

In den Kommentaren wurde erwähnt, dass ein normaler Benutzer das Recht zur Nutzung haben könnte, sudound wenn das Passwort dieses Benutzers erraten würde, wäre das System ebenfalls vollständig verloren.

Zusammenfassend würde ich sagen, dass es egal ist, welches Benutzerpasswort ein Angreifer erhält. Wenn sie ein Passwort erraten, können Sie dem System nicht mehr vertrauen. Ein Angreifer kann die Rechte dieses Benutzers zum Ausführen von Befehlen verwenden sudo. Der Angreifer kann auch eine Schwachstelle in Ihrem System ausnutzen und Root-Rechte erlangen. Wenn ein Angreifer Zugriff auf Ihr System hatte, können Sie ihm nicht mehr vertrauen.

Hierbei ist zu beachten, dass jeder Benutzer in Ihrem System, der sich über SSH anmelden darf, eine zusätzliche Schwachstelle darstellt. Indem Sie root deaktivieren, beseitigen Sie eine offensichtliche Schwäche.

Warum Passwörter über SSH schlecht sind

Der Grund zum Deaktivieren von Passwörtern ist sehr einfach.

Benutzer wählen falsche Passwörter!

Die ganze Idee, Passwörter auszuprobieren, funktioniert nur, wenn die Passwörter erraten werden können. Wenn also ein Benutzer das Passwort "pw123" hat, wird Ihr System unsicher. Ein weiteres Problem bei von Menschen gewählten Passwörtern ist, dass ihre Passwörter niemals wirklich zufällig sind, da dies dann schwer zu merken wäre.

Es ist auch der Fall, dass Benutzer dazu neigen, ihre Passwörter erneut zu verwenden, um sich bei Facebook oder ihren Google Mail-Konten und auf Ihrem Server anzumelden. Wenn ein Hacker das Facebook-Passwort dieses Benutzers erhält, kann er auf Ihren Server gelangen. Der Benutzer könnte es leicht durch Phishing verlieren oder der Facebook-Server könnte gehackt werden.

Wenn Sie sich jedoch mit einem Zertifikat anmelden, wählt der Benutzer sein Kennwort nicht aus. Das Zertifikat basiert auf einer zufälligen Zeichenfolge, die von 1024 Bit bis zu 4096 Bit (~ 128 - 512 Zeichen Kennwort) sehr lang ist. Darüber hinaus dient dieses Zertifikat nur zur Anmeldung bei Ihrem Server und wird nicht mit externen Diensten verwendet.

Links

http://bsdly.blogspot.de/2013/10/the-hail-mary-cloud-and-lessons-learned.html

Dieser Artikel stammt aus den Kommentaren und ich wollte ihm eine etwas wichtigere Position geben, da er sich etwas eingehender mit Botnetzen befasst, die versuchen, sich über SSH anzumelden, wie sie es tun, wie die Protokolldateien aussehen und was kann man tun, um sie zu stoppen. Es wurde von Peter Hansteen geschrieben.

— Raphael Ahrens
quelle

10

Gute Zusammenfassung. Aber auch private ssh-Schlüssel können gestohlen werden.

— Faheem Mitha

16

@Faheem Mitha Ja aber gestohlen ist anders als vermutet, was die Bots tun. Außerdem liegt Ihr privater Schlüssel nur in Ihren Händen (oder auf der Festplatte) und nicht in den Händen von Dritten wie Stack Exchange oder Google.

— Raphael Ahrens

2

+1. Diese Antwort könnte sich eigentlich auf einfach beschränken N*M > N. Da die meisten * nix-Hosts einen rootBenutzer haben, ist die Größe der Testmatrix die Anzahl der zu versuchenden Kennwörter, wenn Sie Root erlauben, sich direkt von einem Remote-Host aus anzumelden. Wenn Sie direkte Root-Anmeldungen nicht zulassen, multiplizieren Sie die Anzahl der möglichen Kombinationen mit der Anzahl der zu testenden Benutzernamen (und es gibt immer noch keine Garantie dafür, dass Sie gültige Benutzernamen testen!).

— ein

3

@ MichaelKjörling Ich möchte hinzufügen, dass es nicht schwierig ist, den Benutzernamen zu bekommen, da der Benutzername normalerweise kein Geheimnis ist und ich wahrscheinlich jemanden bitten könnte, ihn zu bekommen. Aber es hilft gegen Bots und einfaches Ausprobieren.

— Raphael Ahrens

2

@Jeder, wenn der Benutzername X-Symbole und das Passwort Y hat, gibt es # of X length words* # of Y length wordsmögliche Kombinationen zum Ausprobieren. Wenn der Benutzername festgelegt ist (z. B. root), das Passwort jedoch X + Y-Zeichen lang ist, gibt es # of X+Y length wordsmögliche Passwörter. Und # of X+Y length words=# of X length words * # of Y length words

— Skarap

10

Dies könnten einige der Gründe sein, warum die direkte Anmeldung als Root nicht zulässig sein sollte.

Bruteforce-Versuche. Direkte Root-Anmeldung kann bei einem erfolgreichen Bruteforce-Angriff zu mehr Schaden führen.
Eine falsche Konfiguration von "kennwortlosen" SSH-Schlüsseln (menschliches Versagen) kann dazu führen, dass Ihr Computer dem Internet ausgesetzt wird

Dies ist jedoch nur die Spitze des Eisbergs. Sie müssen andere Einschränkungen und Konfigurationen konfigurieren, z.

Ändern Sie den Standardport (22)
Starke Passwörter und Passphrase
Deaktivieren Sie die hostbasierte Authentifizierung
Erstellen Sie eine Liste der zulässigen Benutzer
Konfigurieren Sie das Leerlauf-Timeout
SSHv2-Protokoll erzwingen
Deaktivieren Sie leere Kennwörter
Verwenden Sie fail2ban als Maßnahme gegen Bruteforce
Alles aufzeichnen
Konfigurieren Sie SSH-Schlüssel und vertrauen Sie nur öffentlichen Schlüsseln unter .ssh / authorized_keys

5

"Direkte Root-Anmeldung kann bei einem erfolgreichen Bruteforce-Angriff zu mehr Schaden führen." Nicht wirklich, wenn man es mit einem Standard- sudoSetup vergleicht. Der wahre Killer ist der Multiplikatoreffekt, wenn Sie keinen Benutzernamen haben, auf den Sie sich verlassen können, dass er auf einem bestimmten Host gültig ist.

— ein Lebenslauf vom

@ MichaelKjörling - Ja, sicher, dass durcheinander Sudo so schädlich sein könnte wie PermitRoot;)

Siehe unix.stackexchange.com/a/2944/9454

— Martin Schröder

1

Das Ändern des Ports ist in vielen Szenarien an sich nachteilig. Und es ist auch nichts anderes als Sicherheit durch Dunkelheit.

— 0xC0000022L

+1 für die Erwähnung von fail2ban, da Brute-Force-Angriffe nicht nur für SSH, sondern für alles andere auf dem Computer von Belang sind. Sie müssen keine Root- oder Systemberechtigungen erwerben, um eine Maschine für praktische Zwecke "zu übernehmen" (Zugriff auf private Daten, Verwendung als Dateidump, Verwendung für Phishing usw.).

— Eric Grange

8

Sie haben Recht, dass der Root-Benutzername und das X + Y-Symbolkennwort kryptografisch mindestens so sicher sind wie ein X-Symbol-Benutzername + Y-Symbolkennwort. Tatsächlich ist es sogar noch sicherer, da die Namen der Leute leicht zu erraten sind (Bots versuchen vielleicht nur John, Mike, Bill, etc ... und btw: das ist, was viele von ihnen tun, anstatt root zu versuchen). Und wenn es sich um einen gezielten Angriff handelt, hat man besonders Pech, denn wenn jemand den Server eines Unternehmens beschädigen möchte, ist es kein Problem, den Namen (Spitznamen) des Systemadministrators herauszufinden.

Und sobald der Angreifer Zugriff auf das Konto hat, das der Sysadmin für SSH-Anmeldungen verwendet (und dann verwendet suoder sudoum seine Aufgaben auszuführen), kann er die Sitzung dieses Benutzers mit einem Programm infizieren, das dem Angreifer das root-Kennwort sendet, wenn der Sysadmin das nächste eingibt Zeit.

Es sind alle Arten von Root-Anmeldungen, die unter Sicherheitsgesichtspunkten als schlechte Praktiken gelten (oder gelten sollten). Die "normale" Benutzeranmeldung -> su / sudo-Kette fügt einen Audit-Trail hinzu. Im Klartext: Man kann herausfinden, wer was getan hat.

Ein Sonderfall kann der Fall sein, bei dem nur eine Person Root-Zugriff hat. In diesem Fall wird durch die Verwendung des zusätzlichen "normalen" Benutzers nicht viel Wert hinzugefügt (zumindest konnte ich diesen Wert nie sehen). Aber trotzdem - Sie sollten sowieso einen einfachen Benutzer im System haben (für nicht administrative Aufgaben, Ausführen von wget usw. ;-)).

— Skarap
quelle

4

Was ist so gefährlich beim Aktivieren der Root-Anmeldung (insbesondere bei deaktivierter Passwortanmeldung)?

Der Angreifer (Bot / Botnet / Hacker) muss nur das Passwort erraten und hat die vollständige Kontrolle über Ihr System, wenn Sie für das Internet geöffnet sind. Aus den gleichen Gründen sollte auch keines der Systemkonten (WWW-Daten, Proxy usw.) in der Lage sein, sich über SSH anzumelden.

Wenn Sie die Kennwortanmeldung deaktiviert haben (z. B. mit dem öffentlichen Schlüssel), müssen Sie berücksichtigen, dass jeder, der den privaten Schlüssel erhält, die vollständige Kontrolle über Ihr System hat. Lesen Sie weiter unten, warum die Verwendung eines öffentlichen Schlüssels für einen Benutzer besser ist.

Und was ist der Unterschied zwischen dem X-Symbol-Benutzernamen und dem Y-Symbol-Kennwort oder dem Root-Benutzernamen und dem X + Y-Symbol-Kennwort aus Sicherheitsgründen, wenn die Kennwortauthentifizierung zulässig ist?

Der zusätzliche Benutzername kann eine Sicherheitsebene hinzufügen, da: a) der Angreifer sowohl das Paar als auch den Benutzernamen und das Passwort kennen sollte; b) Wenn ein Angreifer in Ihr System eindringt, hat er keinen sofortigen Zugriff auf ein privilegiertes Konto, was dem Angreifer ein wenig Nuance verleiht.

In diesem Fall ist der öffentliche Schlüssel auch ein Plus, da:

Der Angreifer benötigt Ihren öffentlichen Schlüssel
Der Angreifer benötigt das Kennwort (oder die Authentifizierungsmethode), um erhöhte Berechtigungen zu erhalten

— Braiam
quelle

1

Sehr wenige der von mir verwendeten Passwörter bestehen aus weniger als 20 zufälligen alphanumerischen Zeichen (setzen Sie [A-Za-z0-9] plus einige Sonderzeichen). 20 solcher Zeichen (also 20 von 40 Zeichen) ergeben eine Reihenfolge von 10 ^ 32 Kombinationen. 128 Entropiebits liegen in der Größenordnung von 10 ^ 38. Alles in allem ist das kein großer Unterschied, und der SSH-Server kann jede Art von Ratenbeschränkung implementieren, sodass es in diesem Fall nicht so ist, als würden Sie einen Offline-Brute-Force-Angriff durchführen. An Passwörtern ist nichts auszusetzen, wenn Sie damit leben können, dass sie so schwer zu merken sind wie ein 128-Bit-Schlüssel.

— einen Lebenslauf vom

@michael shh ... gib keine Reichweite an, jetzt wissen Hacker, dass sie Regenbogentabellen in der Größenordnung von 20 Zeichen Länge verwenden sollten ...?

— Braiam

6

@Braiam Rainbow-Tabellen sind nur nützlich, wenn der Angreifer Zugriff auf die Hashes hat, um eine Offlinesuche durchzuführen. In diesem Fall hat der Angreifer nur die Serverantwort, anhand derer er sich verifizieren kann. Dies ist wahrscheinlich auf so viele Versuche beschränkt - und viel langsamer.

— Peter

@Peter ups, ich habe sowohl das Wörterbuch als auch die Hashes durcheinander gebracht, aber auf jeden Fall hat der OP gefragt, warum er keine schwachen oder leeren Passwörter verwenden soll, was lächerlich ist, deshalb kam ich mit lächerlichen Situationen, warum er nicht sollte. Tut mir leid, dass ich nicht so interpretiert wurde und als FUD angenommen wurde.

— Braiam

2

Wenn Sie 1,8 * 10 ^ 35 Passwörter ausprobieren möchten (und das ist nur für den Bereich von 18-22 zufälligen Zeichen aus einem Satz von 40, und Sie wissen nicht, welche Zeichen außerhalb des Satzes [A-Za-z0- 9] Ich benutze), sagte ich fast viel Spaß. Das sind ungefähr 117,1 Bit Entropieäquivalent (2 ^ 117,1 ~ 1,78 * 10 ^ 35), und wie @Peter hervorhob, müssten Sie höchstwahrscheinlich einen Online- Angriff ausführen . Das Speichern all dieser Passwörter (ohne auf Komprimierung zurückzugreifen) erfordert ungefähr 3,6 * 10 ^ 36 Bytes oder 3 * 10 ^ 24 TiB (und wenn diese Zahl um ein paar Größenordnungen falsch ist, wen interessiert das? ). Keyword zufällig .

— einen Lebenslauf vom

1

Es ist nicht gerade schlecht, solange Sie Sicherheitsvorkehrungen treffen. Als Beispiel könnten Sie CSF (Configure Server Firewall) installieren und die Anzahl der zulässigen Fehlversuche festlegen. Wenn also jemand es versucht, sagen wir mal über 5 Fehlversuche, dann werden diese automatisch blockiert. Der gesamte erste Teil des besten Antwortenden ist also überhaupt kein Problem. Das ist mir oft passiert und zum Glück waren alle Einführer dauerhaft gesperrt. Ich denke für einen Server ist es kein großes Problem, wenn Sie die einzige Person sind, die den Server verwaltet, aber natürlich, wenn es viele Systemadministratoren gibt oder wenn Sie in einer Organisation arbeiten, dann verwenden Sie diese offensichtlich nicht Wurzel. Ich denke, auch für einen Desktop-PC ist die Verwendung eines anderen Kontos besser, da ein Sicherheitsrisiko besteht, da Sie viel Software verwenden, auf einem Server jedoch nicht. Wenn Sie keine zufällige Software verwenden, der Sie nicht vertrauen, achten Sie darauf, diese so gering wie möglich zu halten. Die Schlussfolgerung lautet also: Nein, es ist nicht wirklich schädlich, wenn Sie wissen, wie ein Server richtig verwaltet wird.

— Don Dilanga
quelle