Ich möchte das Root-Konto sicher haben, selbst wenn mein nicht privilegierter Benutzer kompromittiert wird.
Unter Ubuntu können Sie sudo standardmäßig nur aus „Sicherheitsgründen“ verwenden. Ich bin mir jedoch nicht sicher, ob es sicherer ist, als nur die Anmeldung auf einer Textmodus-Konsole zu verwenden. Es gibt zu viele Dinge, die schief gehen können, wenn ein Angreifer Code als mein normaler Benutzer ausführen kann. Zum Beispiel das Hinzufügen von Aliasen, das Hinzufügen von Sachen zu meinem PATH, das Setzen von LD_PRELOAD und X11-Keyloggern, um nur einige zu nennen. Der einzige Vorteil, den ich sehe, ist die Zeitüberschreitung, sodass ich nie vergesse, mich abzumelden.
Ich habe die gleichen Zweifel an su, aber es gibt nicht einmal eine zeitliche Begrenzung. Einige Operationen (insbesondere IO-Umleitung) sind mit su bequemer, aber sicherheitstechnisch scheint dies schlechter zu sein.
Die Anmeldung auf einer Textmodus-Konsole scheint am sichersten 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 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. Abgesehen davon sehe ich als einziges Problem das fehlende Timeout.
Also übersehe 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. Aber die Verwendung der obigen Logik wäre nicht die sicherste Vorgehensweise:
- Root über SSH zulassen
- in den Textmodus wechseln
- melden Sie sich als root an
- SSH zum anderen Rechner
- als root anmelden?
Akzeptierte Antwort:
Bei Sicherheit geht es immer darum, Kompromisse einzugehen. Genau wie der sprichwörtliche Server, der sich in einem sicheren, unplugged, am Grund des Ozeans befindet, root wäre die meisten sicher, wenn es überhaupt keine Möglichkeit gäbe, darauf zuzugreifen.
LD_PRELOAD- und PATH-Angriffe wie die von Ihnen beschriebenen gehen davon aus, dass ein Angreifer bereits Zugriff auf Ihr Konto oder zumindest auf Ihre Dotfiles hat. Dagegen schützt Sudo überhaupt nicht gut – wenn sie Ihr Passwort haben, brauchen sie Sie später nicht auszutricksen … sie können einfach sudo verwenden jetzt .
Es ist wichtig zu bedenken, wofür Sudo ursprünglich entwickelt wurde:Delegierung von spezifischen Befehle (wie die zum Verwalten von Druckern) an „Sub-Administratoren“ (vielleicht Doktoranden in einem Labor) weitergeben, ohne root vollständig preiszugeben. Mit sudo alles erledigen ist die häufigste Verwendung, die ich jetzt 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-unrestricted-root macht es adressieren Sie ein weiteres Sicherheitsproblem:die Verwaltbarkeit von Root-Passwörtern. In vielen Organisationen werden diese wie Bonbons herumgereicht, auf Whiteboards geschrieben und für immer so gelassen. Das hinterlässt eine große Schwachstelle, da das Widerrufen oder Ändern des Zugriffs zu einer großen Produktionsnummer wird. Selbst den Überblick darüber zu behalten, welcher Computer welches Passwort hat, ist eine Herausforderung – ganz zu schweigen davon, wer es weiß welche.
Verwandte:Was würde ich bekommen, wenn sudo ein Kernel-zerstörendes Programm ist?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 fertig wird.
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 gesetzt haben – oder schlimmer noch, sie anfangs gleich gesetzt haben und sie dann nicht mehr synchronisiert haben, wodurch das Root-Passwort verrottet ist.
Passwörter überhaupt verwenden für SSH ist gefährlich, da trojanische SSH-Daemons zum Ausspionieren von Passwörtern in ungefähr 90 % der realen Systemkompromittierungen eingesetzt werden, die ich gesehen habe. Es ist viel besser, SSH-Schlüssel zu verwenden, und dies kann auch ein funktionierendes System für den Remote-Root-Zugriff sein.
Aber das Problem besteht darin, dass Sie jetzt von der Passwortverwaltung zur Schlüsselverwaltung gewechselt sind und SSH-Schlüssel nicht wirklich sehr überschaubar sind. Es gibt keine Möglichkeit, Kopien einzuschränken, und wenn jemand eine Kopie erstellt, hat er alle Versuche, die er will, um die Passphrase brutal zu erzwingen. Sie können Richtlinien aufstellen, die besagen, dass Schlüssel auf Wechseldatenträgern gespeichert und nur bei Bedarf installiert werden müssen, aber es gibt keine Möglichkeit, dies durchzusetzen – und jetzt haben Sie die Möglichkeit eingeführt, dass ein Wechseldatenträger verloren geht oder gestohlen wird.
Die höchste Sicherheit wird durch Einmalschlü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 gibt es auch das proprietäre Schwergewicht RSA SecurID. Wenn Sie in einer mittelgroßen bis großen Organisation oder sogar in einer sicherheitsbewussten kleinen Organisation tätig sind, empfehle ich dringend, einen dieser Ansätze für den Administratorzugriff zu prüfen.
Es ist jedoch wahrscheinlich zu viel für zu Hause, wo Sie nicht wirklich die Verwaltungsprobleme haben – solange Sie vernünftige Sicherheitspraktiken befolgen.