Frage:
Warum ist das Deaktivieren von root aus Sicherheitsgründen erforderlich?
Randomblue
2016-02-16 03:04:36 UTC
view on stackexchange narkive permalink

Diese Seite zum Server-Hardening behauptet:

Das Deaktivieren des Root-Kontos ist aus Sicherheitsgründen erforderlich.

Warum ist Deaktivieren des aus Sicherheitsgründen erforderlichen Root-Kontos?

Ich glaube, Ihre Antwort befindet sich im Abschnitt direkt über Ihrem Zitat "Erstellen Sie" Schattenbenutzer "mit Sudo-Kräften".
Der Link weist nur darauf hin, dass Sie das Kennwort für das Root-Konto mit [passwd -l] (http://man7.org/linux/man-pages/man1/passwd.1.html) deaktivieren und nicht das Root-Konto deaktivieren Konto auf eine größere Art und Weise. Du könntest immer noch "su" machen.
Übrigens kann ich nicht sagen, dass ich das für einen großartigen Artikel halte.
Wenn Sie einen Ubuntu-Server ausführen, versuchen Sie "tail -f / var / log / auth.log" und sehen Sie, wie viele Angreifer versuchen, sich als root anzumelden.
Ein nicht deaktiviertes Root-Konto ist nur durch seine Kennwortstärke geschützt. Wenn dieses Kennwort gefährdet ist, ist Ihr System gefährdet.
Und all dies spiegelt im Wesentlichen wider, dass das ursprüngliche Sicherheitsmodell in Unix, dass root allmächtig ist, in der Welt des Internets nicht gut funktioniert. Eine feinere Granularität ist erforderlich.
Eine Seite über Server-Hardening, die ausführlich beschreibt, wie wichtig es ist, / tmp zu sichern, aber dennoch / tmp und / var / tmp verwechselt ([sie sind nicht gleich!] (Http: //www.pathname). com / fhs / pub / fhs-2.3.html # VARTMPTEMPORARYFILESPRESERVEDBETWEE)) und irgendwie * nicht * [libpam-tmpdir] erwähnen (https://launchpad.net/ubuntu/trusty/+package/libpam-tmpdir)? Obwohl es definitiv einige gute Vorschläge gibt, sollte diese Seite * eindeutig * nicht als Evangelium verstanden werden.
Verwandte Themen von Unix Stack Exchange: [Was ist der sicherste Weg, um Root-Rechte zu erhalten: sudo, su oder login?] (Http://unix.stackexchange.com/questions/8581/which-is-the-safest-way- to-get-root-privileges-sudo-su-or-login /)
@ThorbjørnRavnAndersen: "Ein nicht deaktiviertes Root-Konto ist nur durch seine Passwortstärke geschützt": Wenn man also die Passwort-Anmeldung für root deaktiviert und stattdessen ein SSH-Schlüsselpaar verwendet, ist das Problem gelöst! Oder ist es?
@SteveJessop ist ein Schritt in die richtige Richtung. Vielleicht möchten Sie sehen, was Apple in OS X mit "rootless" gemacht hat. Http://apple.stackexchange.com/questions/193368/what-is-the-rootless-feature-in-el-capitan-really
Sechs antworten:
Ohnana
2016-02-16 03:12:38 UTC
view on stackexchange narkive permalink

Wenn Sie Root nicht verwenden, verwenden Sie sudo! Sudo ist eine großartige Möglichkeit, nur dann Root zu werden, wenn Sie dies benötigen.

  1. Root ist ein riesiges Ziel. Wie lautet der Benutzername von root? Wurzel! Ich bin so schlau :)
  2. Protokollierung. Sudo verfügt über ein besseres Kommando für die Überwachungsprotokollierung zentraler Protokollierungsserver). Dies ist in einigen Fällen hilfreich für die forensische Analyse.
  3. Granulare Berechtigungen. Root ist ein Big Flippin 'Hammer. Geben Sie Ihren Benutzern keine BFHs. Mit Sudo können Sie festlegen, dass ein Benutzer Aktualisierungsbefehle wie aptitude ohne Kennwort ausführen kann, aber alles ist verboten! Sie können das nicht mit dem BFH machen, das root ist. Die IT bietet Ihnen die Flexibilität, bestimmte Befehle für Benutzer zu genehmigen, andere jedoch nicht zuzulassen. Auf diese Weise können Sie eine Sicherheitsrichtlinie erstellen, bei der sich ein Administrator nicht jedes Mal physisch bei einem Computer anmelden muss, wenn ein Computer aktualisiert werden muss (oder eine andere geringfügige Aufgabe).
  4. Idiotensicherheit. Warum geben Sie Benutzern kein BFH? Weil sie dumm sind. Warum verwende ich sudo anstelle von root? Ich bin dumm. Dumm bedeutet Fehler, und Fehler bedeuten Sicherheitslücken und Systemadministrationsprobleme.
    5. ol>
Dann gibt der Benutzer Folgendes ein: "sudo bash"
Wenn Sie über eine ordnungsgemäße Überwachungsrichtlinie verfügen, wird dem Benutzer Folgendes angezeigt: `Berechtigung verweigert. Dieser Vorfall wird gemeldet. "
Dann gibt der Benutzer "SHELL = / my / program apt-get install " ein und erhält eine Shell, weil ein Paket "$ SHELL" mit "sh" verwechselt hat.
Oder der Benutzer erstellt ein Paket mit einer Setuid-Shell und installiert es dann. Oder installieren Sie eine alte Version eines Root-Daemons mit bekannten Sicherheitslücken.
Obwohl Sie ein gutes Argument für die Verwendung von "sudo" über das Root-Konto vorbringen, bin ich mir nicht sicher, ob Sie tatsächlich ein Argument für die Deaktivierung des Root-Passworts vorbringen.
@Gilles Es sei denn, Sie erlauben nur Updates oder haben eine Whitelist von Paketen.
@Ohnana können Sie all das tun, während ein Root-Konto aktiviert ist. Sie müssen es nur deaktivieren, wenn Benutzer Ihres Systems gezwungen werden müssen, die Regeln zu befolgen (d. H. Sie sind entweder dumm oder können nicht vollständig vertrauenswürdig sein).
@TomLeek `sudo su` scheint besser zu funktionieren, da es die Umgebung korrekt einrichtet, eine Login-Shell ausführt usw.
@PyRulez Nur Updates zuzulassen, würde nicht helfen. Die Standard-Sudo-Konfiguration in vielen Distributionen, in denen die meisten Umgebungsvariablen einschließlich "SHELL" gesäubert werden, löst jedoch * diesen * besonderen Eskalationsweg. Es gibt wahrscheinlich andere, die Pakete mit interaktiver Konfiguration beinhalten, obwohl das Zulassen nur von Upgrades das Risiko dort erheblich verringert.
@immibis Das Ausführen von "sudo su" anstelle von "sudo bash" ist sowohl irrelevant (Toms Punkt ist, dass der Benutzer eine Shell ausführt, nach der er alles tun kann, was er will) als auch sinnlos ("sudo su" richtet die Umgebung nicht richtig ein "Nicht mehr als" sudo bash "und keine Anmeldeshell ausführt - es wird die Anmeldeshell des Benutzers (Feld" pw_shell "der Benutzerdatenbank) ausgeführt, jedoch nicht als Anmeldeshell (" -bash "oder ähnliches) Führen Sie `.profile`)) aus.
Mein einziger Streitpunkt dabei ist die Verwendung des Begriffs "idiotensicher". Man kann ein System narrensicher machen, aber nur idiotensicher. Echte Idiotensicherung ist unmöglich, weil das Universum immer bessere Idioten herstellt.
Es könnte argumentiert werden, dass die Verwendung eines dedizierten Root-Kontos und das Starten einer Root-Shell sicherer ist als "sudo", da "sudo" entweder Anmeldeinformationen zwischenspeichert (sodass sich ein Schadprogramm im Hintergrund verstecken und auf die Coattails eines Legitimen zugreifen kann Anfrage), oder Sie müssen Ihr Passwort so oft eingeben, dass es zur Gewohnheit wird.
@Gilles @immibis Die Implikation ist, dass der Benutzer böswillig sein könnte. In diesem Fall ist die Verwendung von "sudo" keine Option
@immibis, `sudo su` tut nichts, was` sudo -i` nicht tut, außer unnötig unnötige ausführbare Dateien aufzurufen.
Warum benennst du root nicht um?
@Joshua, das ist eine unglaublich schwierige Sache und wird Sie höchstwahrscheinlich für den Rest des Systemlebens verfolgen. Jeder ist auf root angewiesen! Am besten deaktivieren Sie die Anmeldung und arbeiten von dort aus.
@Ohnana: vim / etc / password ist einfach. Dateien gehören der ID und nicht dem Namen.
@Joshua / etc / shadow, / etc / groups auch. Außerdem gibt `find / etc -type f -exec grep -l root {} +` an, wie viele Konfigurationsdateien nach root als root und nicht nach UID 0 suchen. Dabei werden nicht alle Tools gezählt, die Sie möglicherweise für das neue System neu kompilieren müssen Konfiguration ... In einer perfekten Welt würde jeder UID 0 anstelle von root sagen, aber diese verdammten Fleischsäcke machen immer wieder alles kaputt.
Sie vernachlässigen die Tatsache, dass ich es mit Erfolg versucht habe.
Der größte Grund für sudo over root login für mich: Wenn Sie mehreren Personen Root-Zugriff gewähren müssen, möchten Sie ihn für eine Person widerrufen (z. B. wenn sie das Unternehmen verlässt). Mit sudo einfach. Wenn Sie diesen Personen das Root-Passwort übergeben haben, müssen Sie es ändern und alle anderen müssen sich das neue Passwort merken.
@Ohnana [Dieser Vorfall wird gemeldet] (https://xkcd.com/838/) in der Tat.
schroeder
2016-02-16 03:11:58 UTC
view on stackexchange narkive permalink

Die Site, auf die Sie verlinken, kann nur sehr schlecht erklären, wozu Sie aufgefordert werden. Das Root-Konto ist nicht deaktiviert, sondern das Kennwort für root ist deaktiviert. Das macht passwd -l .

Mit diesen Anweisungen soll sichergestellt werden, dass sich Benutzer nicht als Root-Benutzer anmelden können, da das Root-Konto leicht zu erraten ist. Ich bin mir nicht sicher, ob ihr Ansatz, einen Pseudo-Benutzer mit einem "schwer zu erratenden Namen" zu erstellen, so viel sicherer sein wird ...

root ist in der Tat das Hauptziel von ssh-Bots. Sollten Sie vergessen, es in `sshd_config` zu deaktivieren, würde das Betriebssystem Sie sichern.
Tom Leek
2016-02-16 03:12:25 UTC
view on stackexchange narkive permalink

Es ist eine alte Tradition aus den Tagen des Mainframes. Die Idee ist, dass root mit der Maschine tun kann, was er will, einschließlich des Austauschs des Kernels oder der Zerstörung der UEFI-Variablen, die die Maschine blockieren können. Während ein Nicht- root -Konto dies nicht kann - es sei denn, diesem Konto werden über sudo Administratorrechte erteilt, was Sie mit Ubuntu haben werden, und es zerstört die oben genannten Gründe vollständig.

Das Deaktivieren des root -Kontos wird jetzt ausschließlich dazu verwendet, ältere Götter zu beschwichtigen, die:

  1. mürrisch sind;
  2. sind veraltet;
  3. sind seit Jahrzehnten tot, werden aber immer noch von einer mächtigen Kaste von Hohepriestern verehrt, die zusammen als "Konformitätsprüfer" bekannt sind.
    4. ol>

    In der Praxis Ihr digitales Leben ist von Ihrem normalen Benutzerkonto aus vollständig zugänglich. Daher ist es wenig sinnvoll, einen Schutz in Bezug auf den Benutzer root vorzunehmen. Das Mucking mit der Unterscheidung root / non- root gehört der Vergangenheit an, als Maschinen große Server waren, die von Hunderten von Benutzern gemeinsam genutzt wurden, die möglicherweise einander feindlich gesinnt waren.

"Ihr digitales Leben ist von Ihrem normalen Benutzerkonto aus vollständig zugänglich" - OP fragt im Zusammenhang mit der * Server * -Härtung. Dies setzt ein Desktop-System voraus.
Ich glaube auch, dass "sudo" Sachen protokolliert.
Bei Computern mit mehreren Benutzern gibt es einen Aspekt der Rechenschaftspflicht. Root ist ein generisches Konto, daher kann alles, was von root ausgeführt wird, nicht an einen Benutzer gebunden werden (es sei denn, die Anmeldung wurde von einem bestimmten Benutzerkonto erhöht).
Ist diese Antwort ein Augenzwinkern? Oder verwenden Sie auch weiterhin die Kennwortauthentifizierung anstelle von Schlüsselpaaren?
Mike McManus
2016-02-17 04:51:41 UTC
view on stackexchange narkive permalink

Bitte beachten Sie, dass (zumindest bei Ubuntu und seinen Derivaten) ein Kompromiss mit dem Deaktivieren des Root-Passworts verbunden ist.

Sollte es auf Ihrem System zu einer Katastrophe kommen, sollten Sie das System über die Konsole im Wiederherstellungsmodus (oder Einzelbenutzermodus) starten. Wenn das Root-Passwort deaktiviert ist (wie es standardmäßig der Fall ist), kann beim Booten im Einzelbenutzermodus überhaupt keine Authentifizierung erforderlich sein , da das Root-Konto keine Anmeldeinformationen für diesen Zweck hat. Unter diesen Umständen kann nicht garantiert werden, dass ein anderes Konto funktioniert. Dies wird durch Sonderfallcode im Sulogin-Programm erledigt.

Alles in allem ist dies jedoch ein einfacher Handel: Sie verhindern eine ganze Klasse von Remote-Angriffen, während Sie das System für nicht authentifizierte Root öffnen Melden Sie sich über die physische Konsole an. Denken Sie daran, dass Sie ein System ohnehin niemals vor einem Angreifer mit physischem Zugriff schützen können. Aus diesem Grund gibt es sichere Rechenzentren mit elektronischer Zugangskontrolle.

Alexander C. Solon
2016-02-16 11:46:49 UTC
view on stackexchange narkive permalink

Root ist im Allgemeinen deaktiviert, um eine zusätzliche Sicherheitsebene im gesamten Linux-Betriebssystem bereitzustellen. Der Root-Benutzer hat die Möglichkeit, buchstäblich alles zu ändern, unabhängig von der Wichtigkeit. Dies macht es zu einem häufigen Ziel von Hackern, Viren usw. Durch Deaktivieren (oder vielmehr Deaktivieren des Kennworts) wird sichergestellt, dass das Konto nicht angemeldet werden kann, wenn das Kennwort abgerufen wird (was eigentlich nicht so schwierig ist).

Tatsächlich kann es auf modernen Linux-Systemen trotz grundlegender Benutzerfehler ziemlich schwierig sein, ein komplexes Root-Passwort "abzurufen".
Es gibt immer die Brute-Force-Methoden, oder wenn sie ein Passwort mit einem beliebigen Wort verwenden, kann eine Regenbogentabelle verwendet werden. In beiden Fällen ist dies möglich. Wenn Sie einen Server betreiben, der ein beliebtes Ziel sein könnte (z. B. ein Server für Google, Facebook oder ähnliches), sollten Sie sicherstellen, dass dies sowieso nicht geschieht
Es hängt von der Konfiguration ab, aber viel Glück beim brutalen Erzwingen eines komplexen Root-Passworts, das mit bcrypt gespeichert wurde. Und da Passwörter gesalzen sind (in so ziemlich allen möglichen Konfigurationen, einschließlich der meisten Standardkonfigurationen), sind Regenbogentabellen nutzlos.
GAD3R
2016-02-16 17:21:36 UTC
view on stackexchange narkive permalink

Standardmäßig ist das Kennwort des Root-Kontos in Ubuntu gesperrt.

Wenn das Konto dieses Benutzers von einem Angreifer kompromittiert wird, kann der Angreifer beim nächsten Mal auch Root-Berechtigungen erhalten. Das Benutzerkonto ist das schwache Glied in dieser Kette und muss daher mit der gleichen Sorgfalt wie root geschützt werden.

Das Passwort des Root-Kontos muss nicht für alle freigegeben werden, die irgendeine Art von Verwaltung durchführen müssen Aufgaben auf dem System.

Um Ihr Root-Konto zu deaktivieren, verwenden Sie den folgenden Befehl: 

  sudo passwd -dl root


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...