it-swarm.com.de

Welches 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 können Sie Sudo standardmäßig nur aus "Sicherheitsgründen" verwenden. Ich bin mir jedoch nicht sicher, ob es sicherer ist, als sich nur auf einer Konsole im Textmodus anzumelden. Es gibt zu viele Dinge, die schief gehen können, wenn ein Angreifer Code als mein normaler Benutzer ausführen kann. Zum Beispiel Aliase hinzufügen, Dinge zu meinem PATH hinzufügen, LD_PRELOAD- und X11-Keylogger setzen, um nur einige zu nennen. Der einzige Vorteil, den ich sehen kann, ist das Timeout, sodass ich nie vergesse, mich abzumelden.

Ich habe die gleichen Zweifel an su, aber es gibt nicht einmal ein Zeitlimit. Einige Operationen (insbesondere IO Redirection)) sind mit su praktischer, aber aus Sicherheitsgründen scheint dies schlimmer zu sein.

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

Vermisse ich also 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. Aber mit der obigen Logik wäre dies nicht das Sicherste:

  • erlaube root durch SSH
  • wechseln Sie in den Textmodus
  • melden Sie sich als root an
  • ssh zur anderen Maschine
  • als root anmelden?
124
stribika

Bei Sicherheit geht es immer darum, Kompromisse einzugehen. Genau wie der sprichwörtliche Server, der sich an einem sicheren, nicht angeschlossenen Server am Meeresboden befindet, wäre root am sichersten , wenn er vorhanden wäre waren überhaupt keine Möglichkeit, darauf zuzugreifen.

LD_PRELOAD- und PATH-Angriffe wie die von Ihnen beschriebenen 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 sie schließlich nicht für später austricksen ... sie können einfach Sudo verwenden ) jetzt .

Es ist wichtig zu überlegen, wofür Sudo ursprünglich entwickelt wurde: Delegation von spezifischen Befehlen (wie zum Verwalten von Druckern) an "Subadministratoren" (möglicherweise Studenten) in einem Labor), ohne die Wurzel vollständig zu verschenken. 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 Konfiguration) Dateisyntax).

Sudo-for-unrestricted-root behebt ein weiteres Sicherheitsproblem: die Verwaltbarkeit von Root-Passwörtern. In vielen Organisationen werden diese häufig wie Süßigkeiten herumgereicht, auf Whiteboards geschrieben und für immer gleich gelassen. Dies hinterlässt eine große Sicherheitslücke, da das Widerrufen oder Ändern des Zugriffs zu einer großen Produktionsnummer wird. Selbst zu verfolgen, welche Maschine welches Passwort hat, ist eine Herausforderung - geschweige denn zu verfolgen, wer weiß welches.

Denken Sie daran, dass die meisten "Cyber-Verbrechen" von innen kommen. Mit der beschriebenen Root-Passwort-Situation ist es schwierig herauszufinden, wer was getan hat - etwas, mit dem Sudo mit Remote-Protokollierung ziemlich gut zurechtkommt.

Auf Ihrem Heimsystem ist es meiner Meinung nach eher eine Frage der Bequemlichkeit, sich nicht zwei Passwörter merken zu müssen. Es ist wahrscheinlich, dass viele Leute sie einfach gleich eingestellt haben - oder schlimmer noch, sie anfangs gleich eingestellt haben und sie dann nicht mehr synchronisiert haben, sodass das Root-Passwort verrottet ist.

Die Verwendung von Passwörtern für SSH ist gefährlich, da in etwa 90% der realen Systemkompromisse Trojaner-SSH-Daemons mit Passwort-Sniffing eingesetzt werden Ich habe gesehen. Es ist viel besser, SSH-Schlüssel zu verwenden, und dies kann auch ein funktionsfähiges System für den Remote-Root-Zugriff sein.

Das Problem besteht nun darin, dass Sie von der Kennwortverwaltung zur Schlüsselverwaltung übergegangen sind und SSH-Schlüssel nicht wirklich überschaubar sind. Es gibt keine Möglichkeit, Kopien einzuschränken, und wenn jemand eine Kopie erstellt, hat er alle Versuche, die Passphrase brutal 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 erzwungen 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. Diese können in Software durchgeführt werden, manipulationssichere Hardware ist jedoch noch besser. In der Open Source-Welt gibt es WiKiD , YubiKey oder LinOTP , und natürlich gibt es auch das proprietäre Schwergewicht RSA SecurID . Wenn Sie sich in einer mittelgroßen bis großen Organisation oder sogar in einer sicherheitsbewussten kleinen Organisation befinden, empfehle ich dringend, einen dieser Ansätze für den Administratorzugriff zu prüfen.

Es ist jedoch wahrscheinlich ein Overkill für zu Hause, wo Sie nicht wirklich Probleme mit der Verwaltung haben - solange Sie vernünftige Sicherheitspraktiken befolgen.

105
mattdm

Dies ist eine sehr komplexe Frage. mattdmhat bereits viele Punkte abgedeckt .

Wenn Sie zwischen su und Sudo einen einzelnen Benutzer betrachten, ist su etwas sicherer, da ein Angreifer, der Ihr Kennwort gefunden hat, nicht sofort Root-Rechte erhalten kann. Der Angreifer muss jedoch nur ein lokales Wurzelloch finden (relativ selten) oder einen Trojaner installieren und darauf warten, dass Sie su ausführen.

Sudo bietet sogar gegenüber einer Konsolenanmeldung Vorteile, wenn mehrere Benutzer vorhanden sind. Wenn ein System beispielsweise mit manipulationssicheren Remote-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 auf der Konsole eingegeben hat.

Ich vermute, Ubuntus Entscheidung war teilweise im Interesse der Einfachheit (nur ein Passwort zu merken) und teilweise im Interesse der Sicherheit und der einfachen Verteilung von Anmeldeinformationen auf gemeinsam genutzten Computern (Unternehmen oder Familie).

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 über den Root-Zugriff Sorgen machen, können Sie den Root-Zugriff von einem laufenden System aus ganz 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. (* BSDs Sicherheitsstufe funktioniert folgendermaßen: Bei einer hohen Sicherheitsstufe gibt es Dinge, die Sie ohne einen Neustart nicht tun können, z. B. das Verringern der Sicherheitsstufe oder den direkten Zugriff auf gemountete Rohgeräte.)

Die Einschränkung der Art und Weise, wie man Wurzel werden kann, ist nicht immer ein Sicherheitsgewinn. 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 Designer der gesicherten OpenWall GNU/*/Linux-Distribution haben auch kritische Meinungen zu su (um root zu werden) und Sudo geäußert. Vielleicht möchten Sie diesen Thread lesen:

... leider sind sowohl su als auch Sudo subtil aber grundlegend fehlerhaft.

Neben der Erörterung der Fehler von su und anderer Dinge zielt Solar Designer auch auf einen bestimmten Grund für die Verwendung von su ab:

Ja, es war früher übliche Sysadmin-Weisheit, "su root" zu verwenden, anstatt sich als root anzumelden. Die wenigen, die auf Nachfrage tatsächlich einen gültigen 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" (d. H. Einschließlich su; und sie verwenden hierfür keine Funktionen):

Ich denke, bei Servern müssen die Benutzer den Aufruf von su und Sudo durch die Benutzer überdenken und in den meisten Fällen nicht zulassen. Es gibt keine zusätzliche Sicherheit von der alten "Anmeldung als Nicht-Root, dann su oder Sudo zu Root" sysadmin "Weisheit" im Vergleich zur Anmeldung als Nicht-Root und als Root direkt (zwei separate Sitzungen). Im Gegenteil, der letztere Ansatz ist unter Sicherheitsgesichtspunkten der einzig richtige:

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

(Für die Verantwortlichkeit mehrerer Systemadministratoren muss das System die Verwendung mehrerer Root-Konten unterstützen, wie dies bei Owl der Fall ist.)

(Bei Desktops mit X wird dies schwieriger.)

Sie müssen sich auch unbedingt mit ...

Übrigens sollten sie sulogin durch msulogin ersetzen, um das Setup mit mehreren Root-Konten zu ermöglichen: msulogin ermöglicht es einem, auch den Benutzernamen einzugeben Wenn Sie in den Einzelbenutzermodus wechseln (und die "Verantwortlichkeit" bewahren) (diese Informationen stammen von diese Diskussion auf Russisch ).

Sie scheinen davon auszugehen, dass bei Verwendung von Sudo immer Umgebungsvariablen erhalten bleiben, dies ist jedoch nicht immer der Fall. Hier ist ein Auszug aus der Sudo-Manpage:

Es gibt zwei verschiedene Möglichkeiten, mit Umgebungsvariablen umzugehen. Standardmäßig ist die Option env_reset sudoers aktiviert. Dies führt dazu, dass Befehle in einer minimalen Umgebung ausgeführt werden, die TERM, PATH, HOME, Shell, LOGNAME, USER und USERNAME enthält, zusätzlich zu Variablen aus dem Aufrufprozess, die durch die Sudoers-Optionen env_check und env_keep 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 verweigert werden, vom aufrufenden Prozess geerbt. In diesem Fall verhalten sich env_check und env_delete wie eine schwarze Liste. Da nicht alle potenziell gefährlichen Umgebungsvariablen auf die schwarze Liste gesetzt werden können, 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önnen. 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.

Also wenn env_reset ist aktiviert (Standardeinstellung), ein Angreifer kann Ihre PATH oder andere Umgebungsvariablen nicht überschreiben (es sei denn, Sie fügen sie speziell einer Whitelist von Variablen hinzu, die beibehalten werden sollen).

4
Cedric

Der sicherste Ansatz ist die SSH-Anmeldung mit einem (mindestens) 2048 langen Schlüssel (bei deaktivierter Kennwortanmeldung) mit einem physischen Gerät zum Speichern des Schlüssels.

4
Šimon Tóth

Ich möchte nur etwas hinzufügen, das etwas vom Thema abweicht. (für das Thema einchecken '/ bin/su -' hier nach)

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

Es wird und sollte anders sein, wenn wir sichern wollen: 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 Sicherheit als Ganzes ein Gleichgewicht zwischen der Benutzerfreundlichkeit, der "Datensicherheit" und dem erforderlichen Aufwand zur Implementierung eines sicheren Systems darstellt.

Ubuntus Ziel war und ist 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 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 eine Schreibkraft bin. Die PATH-Variable .. sollte kein Problem sein (ich gebe den Pfad ein). Auch das "-" (Minus) sollte im Prinzip meine Benutzerumgebungsvariablen entfernen und nur die Root-Variablen laden. Vermeiden einiger zusätzlicher möglicher Probleme. Wahrscheinlich auch der LS_PRELOAD.

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

Aber lassen Sie es uns in die richtige Box legen. Angenommen, ein Scripting-Smart-Kit erhält Zugriff auf meine Daten. Was zum Teufel glaubst du, wird er damit machen? - Meine Bilder veröffentlichen? meine? - Versuchen Sie, den Namen meiner Freundin herauszufinden und ihr zu sagen, dass ich Pornoseiten besuche?

Im 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.

Für den ersten Fall, den ich oben erwähnt habe, sollten Sie sich besser um ein Backup als um die Netzwerksicherheit bemühen. Ja, du bist gerettet. Ich meine, ein Hardware-Absturz ist nicht so 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.

3
user5520

Wenn die Sorge besteht, dass ein kompromittiertes Benutzerkonto verwendet werden kann, um das für Sudo oder su verwendete Kennwort zu ermitteln, verwenden Sie einen einmaligen Passcode für Sudo und su.

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

2
nowen

Sie können auch einen Blick auf privacyIDEA werfen, der Ihnen nicht nur die Möglichkeit bietet, OTP für die Anmeldung am Computer (oder für su/Sudo) zu verwenden, sondern auch OTP offline.

Darüber hinaus kann es Ihre SSH-Schlüssel verwalten. Das heißt, 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 Workflows, um das System zu sichern.

0
cornelinux