Was ist der sicherste Weg, um Root-Rechte zu erhalten: sudo, su oder login?

Ich möchte das Root-Konto in Sicherheit haben, auch wenn mein nicht privilegierter Benutzer gefährdet ist.

Unter Ubuntu kann sudo standardmäßig nur aus "Sicherheitsgründen" verwendet werden. Ich bin mir jedoch nicht sicher, ob dies sicherer ist, als nur die Anmeldung an einer Konsole im Textmodus zu verwenden. Es gibt zu viele Dinge, die schief gehen können, wenn ein Angreifer als normaler Benutzer Code ausführen kann. Zum Beispiel das Hinzufügen von Aliasen, das Hinzufügen von Inhalten zu meinem PATH, das Einstellen von LD_PRELOAD und X11-Keyloggern, um nur einige zu nennen. Der einzige Vorteil, den ich sehen kann, ist die Zeitüberschreitung, sodass ich nie vergesse, mich abzumelden.

Ich habe die gleichen Zweifel an su, aber es gibt nicht einmal ein Zeitlimit. Einige Operationen (insbesondere die E / A-Umleitung) sind mit su praktischer, was die Sicherheit betrifft, scheint dies jedoch schlechter zu sein.

Die Anmeldung an einer Konsole im Textmodus scheint die sicherste zu sein. Da es von init gestartet wird, wenn ein Angreifer PATH oder LD_PRELOAD kontrollieren kann, ist er bereits root. Die Tastendruckereignisse können von Programmen, die auf X ausgeführt werden, nicht abgefangen werden. Ich weiß nicht, ob Programme, die auf X ausgeführt werden, [Strg] + [Alt] + [F1] abfangen können (und ein Vollbildfenster öffnen, das wie eine Konsole aussieht) oder Es ist sicher wie [Strg] + [Alt] + [Entf] unter Windows. Das einzige Problem, das ich sehe, ist das Fehlen einer Auszeit.

Vermisse ich etwas? Warum haben die Ubuntu-Leute beschlossen, nur sudo zuzulassen? Was kann ich tun, um die Sicherheit einer der Methoden zu verbessern?

Was ist mit SSH? Traditionell kann sich root nicht über SSH anmelden. Mit der obigen Logik wäre dies jedoch nicht die sicherste Vorgehensweise:

• Erlaube root durch SSH
• in den Textmodus wechseln
• Melden Sie sich als root an
• ssh auf die andere Maschine
• als root anmelden?

Bei Sicherheit geht es immer um Kompromisse. Genau wie der sprichwörtliche Server, der sich in einem sicheren, nicht angeschlossenen Bereich am Grund des Ozeans befindet, rootwäre er am sichersten, wenn es überhaupt keine Möglichkeit gäbe, darauf zuzugreifen.

LD_PRELOAD- und PATH-Angriffe, wie Sie sie beschreiben, setzen voraus, dass es einen Angreifer gibt, der bereits Zugriff auf Ihr Konto oder zumindest auf Ihre Punktedateien hat. Sudo schützt sich überhaupt nicht sehr gut davor - wenn sie Ihr Passwort haben, müssen sie es schließlich nicht versuchen, Sie für später auszutricksen ... sie können es sudo jetzt verwenden .

Es ist wichtig zu überlegen, wofür Sudo ursprünglich entwickelt wurde: Übertragung von bestimmten Befehlen (z. B. zum Verwalten von Druckern) an "Subadministratoren" (möglicherweise Studenten in einem Labor), ohne Root vollständig zu verraten. Die Verwendung von sudo für alles ist die häufigste Verwendung, die ich derzeit sehe, aber es ist nicht unbedingt das Problem, das das Programm lösen sollte (daher die lächerlich komplizierte Syntax der Konfigurationsdatei).

Aber sudo-for unbeschränkter root tut ein weiteres Sicherheitsproblem Adresse: Verwaltung von Root - Passwörter. In vielen Organisationen werden diese häufig wie Süßigkeiten herumgereicht, auf Whiteboards geschrieben und für immer unverändert gelassen. Das hinterlässt eine große Sicherheitslücke, da das Widerrufen oder Ändern des Zugriffs zu einer großen Produktionsnummer wird. Sogar das Verfolgen, welche Maschine welches Passwort hat, ist eine Herausforderung - geschweige denn das Verfolgen, wer welches kennt .

Denken Sie daran, dass das meiste "Cyber-Verbrechen" von innen kommt. Bei der beschriebenen Root-Passwort-Situation ist es schwierig, herauszufinden, wer was getan hat - etwas, was Sudo bei der Remote-Protokollierung recht gut erledigt.

Ich denke, auf Ihrem Heimsystem geht es eher darum, dass Sie sich nicht zwei Passwörter merken müssen. Es ist wahrscheinlich, dass viele Leute sie einfach auf den gleichen Wert eingestellt haben - oder schlimmer noch, indem sie sie anfangs auf den gleichen Wert eingestellt haben und sie dann nicht mehr synchronisiert wurden, sodass das root-Passwort verrottet.

Kennwörter verwenden überhaupt für SSH ist gefährlich, da Passwort-Sniffing trojaned ssh - Dämonen an ihren Platz in so etwas wie 90% der realen System Kompromisse gesetzt werden ich gesehen habe. Es ist viel besser, SSH-Schlüssel zu verwenden, und dies kann auch ein funktionsfähiges System für den Remotestammzugriff sein.

Das Problem ist jedoch, dass Sie jetzt von der Kennwortverwaltung zur Schlüsselverwaltung übergegangen sind und die SSH-Schlüssel nicht mehr so ​​einfach zu verwalten sind. Es gibt keine Möglichkeit, Kopien einzuschränken, und wenn jemand eine Kopie erstellt, hat er alle Versuche, die Passphrase brachial zu erzwingen. Sie können festlegen, dass Schlüssel auf Wechseldatenträgern gespeichert und nur bei Bedarf bereitgestellt werden müssen. Dies kann jedoch nicht durchgesetzt werden. Jetzt haben Sie die Möglichkeit eingeführt, dass ein Wechseldatenträger verloren geht oder gestohlen wird.

Die höchste Sicherheit wird durch einmalige Schlüssel oder zeit- / zählerbasierte kryptografische Token erreicht. Dies kann in Software erfolgen, aber manipulationssichere Hardware ist noch besser. In der Open Source-Welt gibt es WiKiD , YubiKey oder LinOTP und natürlich auch das proprietäre Schwergewicht RSA SecurID . Wenn Sie in einer mittelgroßen bis großen Organisation oder sogar in einer sicherheitsbewussten kleinen Organisation arbeiten, empfehle ich dringend, einen dieser Ansätze für den administrativen Zugriff in Betracht zu ziehen.

Wahrscheinlich ist es ein Overkill für zu Hause, wo Sie die Verwaltungsprobleme nicht wirklich haben - solange Sie vernünftige Sicherheitspraktiken befolgen.

Dies ist eine sehr komplexe Frage. mattdm hat bereits viele punkte abgedeckt .

Wenn Sie zwischen su und sudo einen einzelnen Benutzer in Betracht ziehen, ist su ein wenig sicherer, da ein Angreifer, der Ihr Kennwort gefunden hat, nicht sofort Root-Berechtigungen erhalten kann. Es ist jedoch nur erforderlich, dass der Angreifer ein lokales Root-Hole findet (relativ selten) oder einen Trojaner installiert und darauf wartet, dass Sie su ausführen.

Sudo hat sogar Vorteile gegenüber einer Konsolenanmeldung, wenn mehrere Benutzer vorhanden sind. Wenn ein System beispielsweise mit fernen manipulationssicheren Protokollen konfiguriert ist, können Sie immer herausfinden, wer sudo zuletzt ausgeführt hat (oder wessen Konto kompromittiert wurde), aber Sie wissen nicht, wer das root-Passwort in der Konsole eingegeben hat.

Ich vermute, dass Ubuntus Entscheidung zum Teil im Interesse der Einfachheit (nur ein Passwort zu merken) und zum Teil im Interesse der Sicherheit und der einfachen Verteilung von Anmeldeinformationen auf gemeinsam genutzten Maschinen (Unternehmen oder Familie) lag.

Linux verfügt nicht über einen sicheren Aufmerksamkeitsschlüssel oder eine andere sichere Benutzeroberfläche für die Authentifizierung. Soweit ich weiß, hat sogar OpenBSD keine. Wenn Sie sich Sorgen um den Root-Zugriff machen, können Sie den Root-Zugriff auf einem laufenden System deaktivieren. Wenn Sie Root sein möchten, müssen Sie an der Bootloader-Eingabeaufforderung etwas eingeben. Dies ist offensichtlich nicht für alle Anwendungsfälle geeignet. (* Die Sicherheitsstufe von BSD funktioniert folgendermaßen: Auf einer hohen Sicherheitsstufe gibt es Dinge, die Sie ohne Neustart nicht tun können, z. B. die Sicherheitsstufe senken oder direkt auf gemountete Raw-Geräte zugreifen.)

Es ist nicht immer ein Gewinn für die Sicherheit, die Art und Weise einzuschränken, in der man Root werden kann. Denken Sie an das dritte Mitglied der Sicherheitstriade : Vertraulichkeit , Integrität , Verfügbarkeit . Wenn Sie sich aus Ihrem System ausschließen, können Sie möglicherweise nicht auf einen Vorfall reagieren.

Die Entwickler der gesicherten OpenWall GNU / * / Linux-Distribution haben auch kritische Meinungen zu su(für die Wurzelbildung) und geäußert sudo. Vielleicht möchten Sie diesen Thread lesen:

... leider sind sowohl su als auch sudo subtil, aber grundlegend fehlerhaft.

Neben der Erörterung von Fehlern suund anderen Aspekten hat Solar Designer auch einen bestimmten Verwendungszweck su:

Ja, es war früher die gängige Weisheit der Systemadministratoren, sich als "su root" anzumelden, anstatt sich als root anzumelden. Die wenigen, die auf Nachfrage tatsächlich einen triftigen Grund für diese Präferenz finden könnten, würden auf die bessere Rechenschaftspflicht verweisen, die mit diesem Ansatz erreicht wird. Ja, das ist wirklich ein guter Grund für diesen Ansatz. Aber es ist auch der einzige. ...(Weiterlesen)

In ihrer Distribution haben sie "SUID-Root-Programme in der Standardinstallation vollständig entfernt" (dh einschließlich su; und sie verwenden hierfür keine Funktionen):

Für Server denke ich, dass die Benutzer den Aufruf von su und sudo überdenken und in den meisten Fällen nicht zulassen müssen. Es gibt keine zusätzliche Sicherheit von der alten "Anmeldung als nicht root, dann su oder sudo zu root" sysadmin "Weisheit", verglichen mit der Anmeldung als nicht root und direkt als root (zwei getrennte Sitzungen). Im Gegenteil, der letztere Ansatz ist sicherheitstechnisch der einzig richtige:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Für die Rechenschaftspflicht mehrerer Sysadmins muss das System mehrere root-privilegierte Konten unterstützen, wie es Owl tut.)

(Bei Desktops mit X wird dies schwieriger.)

Man muss sich auch unbedingt damit auseinandersetzen ...

BTW, waren sie ersetzen suloginmit msulogindem Setup mit mehreren Root - Konten zu ermöglichen: msuloginerlaubt es , den Benutzernamen auch eingeben , wenn sie in den Single - User - Modus (und die Erhaltung der „Verantwortlichkeit“) gehen (diese Info kommt diese Diskussion in Russisch ) .

Sie gehen anscheinend davon aus, dass sudoUmgebungsvariablen immer beibehalten werden, dies ist jedoch nicht immer der Fall. Hier ist ein Auszug aus der sudo-Manpage:

Es gibt zwei Möglichkeiten, mit Umgebungsvariablen umzugehen. Standardmäßig ist die Option env_reset sudoers aktiviert. Dadurch werden Befehle mit einer minimalen Umgebung ausgeführt, die TERM, PATH, HOME, SHELL, LOGNAME, USER und USERNAME sowie Variablen aus dem aufrufenden Prozess enthält, die durch die Optionen env_check und env_keep sudoers zulässig sind. Es gibt effektiv eine Whitelist für Umgebungsvariablen.

Wenn jedoch die Option env_reset in sudoers deaktiviert ist, werden alle Variablen, die von den Optionen env_check und env_delete nicht explizit abgelehnt werden, vom aufrufenden Prozess übernommen. In diesem Fall verhalten sich env_check und env_delete wie eine schwarze Liste. Da es nicht möglich ist, alle potenziell gefährlichen Umgebungsvariablen auf die schwarze Liste zu setzen, wird die Verwendung des Standardverhaltens env_reset empfohlen.

In allen Fällen werden Umgebungsvariablen mit einem Wert, der mit () beginnt, entfernt, da sie als Bash-Funktionen interpretiert werden könnten. Die Liste der Umgebungsvariablen, die sudo zulässt oder ablehnt, ist in der Ausgabe von sudo -V enthalten, wenn es als root ausgeführt wird.

Wenn env_resetalso aktiviert ist (Standardeinstellung), kann ein Angreifer Ihre PATHoder andere Umgebungsvariablen nicht außer Kraft setzen (es sei denn, Sie fügen sie einer Whitelist mit Variablen hinzu, die beibehalten werden sollen).

Der sicherste Ansatz ist die SSH-Anmeldung mit (mindestens) 2048 langen Schlüsseln (bei deaktivierter Kennwortanmeldung) unter Verwendung eines physischen Geräts zum Speichern des Schlüssels.

Ich möchte nur etwas hinzufügen, das nicht zum Thema gehört. (für das Thema "/ bin / su" hier nachher ankreuzen)

Ich denke, dass die oben genannte "Sicherheit" auch mit den tatsächlichen Daten verknüpft sein sollte, die wir sichern möchten.

Es wird und sollte anders sein, wenn wir Folgendes sichern möchten: my_data, my_company_data, my_company_network.

Wenn ich über Sicherheit spreche, spreche ich normalerweise auch über "Datensicherheit" und Sicherung. Wir können auch fehlertolerante Systeme und dergleichen hinzufügen.

Angesichts dessen denke ich, dass die Sicherheit insgesamt ein Gleichgewicht zwischen der Benutzerfreundlichkeit, der "Datensicherheit" und dem erforderlichen Aufwand für die Implementierung eines sicheren Systems darstellt.

Ubuntus Ziel war und ist immer noch der Endbenutzer: Sudo ist die Standardeinstellung.

Fedora ist die kostenlose Version von RedHat, die wiederum stärker auf Server ausgerichtet ist: Sudo war früher deaktiviert.

Für die anderen Distributionen liegen mir keine direkten Informationen vor.

Ich benutze gerade hauptsächlich Fedora. Und als Benutzer im alten Stil habe ich nie "su" eingegeben. Aber ich kann in sehr kurzer Zeit "/ bin / su -" eingeben, auch wenn ich nicht gerade ein Typist bin. Die PATH-Variable .. sollte kein Problem sein (ich gebe den Pfad ein). Auch das "-" (Minus) sollte grundsätzlich meine Benutzerumgebungsvariablen entfernen und nur die Root-Variablen laden. dh einige zusätzliche mögliche Probleme vermeiden. Wahrscheinlich auch das LS_PRELOAD.

Für den Rest denke ich, dass @mattdm ziemlich genau war.

Aber lassen Sie es uns in das richtige Feld setzen. Angenommen, ein Scripting Smart Kit erhält Zugriff auf meine Daten. Was zur Hölle wird er wohl damit anfangen? - Veröffentlichen Sie meine Bilder? meine? - Versuchen Sie, den Namen meiner Freundin herauszufinden und ihr zu sagen, dass ich Pornoseiten besuche?

Auf dem Einzelbenutzerbild sind die beiden schlimmsten Situationen: - Das Kind löscht alle meine Daten: zum Spaß oder aus Versehen - Das Kind verwendet meine Maschine, um einen weiteren Angriff auf eine andere Entität zu erstellen. Oder ähnliche Ziele.

Im ersten Fall, den ich oben erwähnt habe, sollten Sie sich mehr um ein Backup als um die Netzwerksicherheit bemühen. Ja, du bist gerettet. Ich meine, ein Hardware-Absturz ist nicht anders.

Der zweite Fall ist subtiler. Es gibt jedoch Signale für diese Aktivitäten. In jedem Fall können Sie das Mögliche tun, aber ich würde meinen Heim-PC nicht so konfigurieren, dass er vor Terroranschlägen geschützt ist!

Ich werde die anderen Szenarien überspringen.

Prost F

Wenn Sie befürchten, dass ein manipuliertes Benutzerkonto zum Ermitteln des für sudooder verwendeten Kennworts verwendet werden kann, verwenden Sie sueinen einmaligen Passcode für sudound su.

Sie können die Verwendung von Schlüsseln für Remotebenutzer erzwingen, dies kann jedoch zu Compliance-Zwecken nicht erfolgreich sein. Es ist möglicherweise effektiver, eine SSH-Gateway-Box einzurichten, die eine Zwei-Faktor-Authentifizierung erfordert, und von dort aus die Schlüsselverwendung zuzulassen. Hier ist ein Dokument zu einem solchen Setup: Sichern Sie Ihre SSH-Bereitstellung mit der WiKID-Zwei-Faktor-Authentifizierung .

Sie können auch einen Blick auf privacyIDEA werfen , das Ihnen nicht nur die Möglichkeit bietet, OTP zum Anmelden auf dem Computer (oder zum Ausführen von su / sudo) zu verwenden, sondern es kann auch OTP offline ausführen.

Darüber hinaus ist es in der Lage, Ihre SSH-Schlüssel zu verwalten. Dh wenn Sie viele Computer und mehrere Root-Benutzer haben, werden alle SSH-Schlüssel zentral gespeichert. Somit ist es einfach, einen SSH-Schlüssel zu "widerrufen" / zu löschen, wenn dem Schlüssel nicht mehr vertraut werden kann.

Natürlich gibt es organisatorische Aufgaben und Abläufe, um das System abzusichern.