Sollten wir den Root-Benutzer deaktivieren?

Sollten wir das root-Passwort entfernen, die Remote-Anmeldung deaktivieren und Administratoren grundsätzlich auffordern, sudo zu verwenden, um administrative Aktionen auszuführen?

Bei allen meinen Servern ist das Root-Konto deaktiviert ( sp_pwdpauf *). Dies ist sudofür jeden Root-Zugriff erforderlich . [1] Ziel ist es, dass alle Superuser-Aktivitäten überprüft werden, damit die Benutzer sehen können, was mit dem System geschehen ist.

Für eine härtere Option können Sie sudoin eine Protokolldatei schreiben (im Gegensatz zu syslog) und die Datei nur anhängen (unter chattrLinux oder chflagsBSD). Auf diese Weise kann niemand das Audit nachträglich bearbeiten.

[1] Ich habe auch die Richtlinie, keine Root-Shell auszuführen oder Shell-Fluchten aus einem Root-Prozess auszuführen. (Es ist jedoch in Ordnung, sudo sh -c '...'Pipelines oder Umleitungen auszuführen.)

Ich empfehle nachdrücklich , den Root-Benutzer nicht zu deaktivieren. Deaktivieren oder beschränken Sie Root-Anmeldungen (über securetty und über sshd_config sowie über PAM und über what have you). Wenn Ihr System dies zulässt, begrenzen Sie die Root-Berechtigungen oder teilen Sie die Root-Rolle auf (ähnlich wie bei RSBAC ). Aber bitte, bitte , tun Sie es Deaktivieren Sie das Root-Konto nicht, indem Sie das Kennwort entfernen. Andernfalls ist es nicht möglich, sich über im System anzumelden sulogin. suloginwird von allen mir bekannten Initskripten verwendet, wenn von fsck schwerwiegende Fehler gemeldet werden - und das bedeutet, dass Sie vom System ausgeschlossen werden, wenn das Root-Dateisystem beschädigt wird.

Zur Verdeutlichung: Mit "Deaktivieren des Root-Kontos durch Entfernen des Passworts" meine ich die verschiedenen Mechanismen, die mit einem! oder ein * im Passwortfeld von / etc / shadow oder ähnlichem. Ich meine nicht "Ändern Sie den Root-Anmeldemechanismus, damit Sie nicht zur Eingabe eines Kennworts aufgefordert werden."

Ich habe das Root-Konto auf allen meinen Servern aktiviert. Alle Administratoren haben einen eigenen Benutzer und müssen sich über diesen anmelden. Von dort wechseln sie zu root. (root ssh ist deaktiviert)

Halten Sie die Administratoranzahl niedrig. Nur die Personen, die auf diesem Server wirklich root-Zugriff benötigen, haben das Passwort.

Ich bin kein Fan von Sudo. Es ist viel zu einfach, einfach 'sudo bash' für eine Root-Shell zu machen. Mir ist bewusst, dass dies deaktiviert werden kann, aber warum sollte ich mich darum kümmern? Begrenzen Sie einfach die Benutzer, die Administratoraufgaben ausführen und miteinander sprechen können. Wir haben die Richtlinie, Root-Terminals nicht unbeaufsichtigt zu öffnen. Es geht also darum, sich einzuloggen, die Arbeit zu erledigen und sich abzumelden.

Hinweis: Ich arbeite in einer relativ kleinen Firma (50 Angestellte) und wir kommen mit nur 2 Teilzeitadministratoren (1 Windows / 1 Linux) zurecht. Diese Vorgehensweise ist möglicherweise nicht die beste, wenn Sie mehrere Benutzer haben. Ich persönlich würde sudo immer noch nicht verwenden. Es gibt andere Möglichkeiten, die Root-Aktivität zu protokollieren.

Das Deaktivieren des root-Passworts ist imho eine falsche "gute Idee". An dem Tag, an dem du es brauchst, wirst du es wirklich brauchen. (Abhängig von Ihrer Konfiguration benötigen Sie diese möglicherweise, um sich beispielsweise im Einzelbenutzermodus anzumelden.)

Das Deaktivieren der Remote-Anmeldung als Root ist möglicherweise relevant, aber nur, wenn Sie sich lokal anmelden können.

Und ja, sudo sollte auf jedem Ihrer Server installiert sein. Es ist nützlich und einfach zu konfigurieren. Warum möchten Sie es nicht benutzen?

Ich deaktiviere nur den SSH-Zugriff für root und fordere Benutzer (oft nur Entwickler) auf, SSH-Schlüssel zu verwenden. Es gibt einfach zu viele Wörterbuchangriffe und das Ändern des SSH-Ports ist für uns keine Option.

Auf diese Weise müssen Sie nicht darauf vertrauen, dass irgendjemand ein gutes Passwort schreiben kann. Einmal drinnen haben nur die Admins Berechtigungen für sudo.

Ich weiß, dass dieser Thread wirklich alt ist, aber es gibt einige Hauptmängel in der Logik der verknüpften Artikel und ich fühle mich "rant'ie" - sudo erlaubt sowohl Whitelisting als auch Blacklisting. Nicht nur schwarz, wie im verlinkten Artikel angegeben - Dies überspringt die Idee von AAA (Authentication, Authorization & Auditing) - su & sudo ermöglicht sowohl abgestufte Authentifizierung als auch Verantwortlichkeit.

Szenario 1 Ein Administrator führt versehentlich einen betrügerischen Code in ein System ein, der als root angemeldet ist. Der Code hat vollständigen Zugriff und der Administrator weiß möglicherweise nie, was passiert ist. Zumindest bei abgestuften Anmeldungen (z. B. su / sudo) wird der Administrator aufgefordert, sich zu authentifizieren, wenn der betrügerische Code versucht, erhöhte Rechte zu verwenden.

Szenario 2 Ein betrügerischer Administrator möchte Informationen erhalten oder Änderungen vornehmen. Sie stellen eine Verbindung zur Konsole her (physischer Konsolenzugriff, HP iLo / similar- oder vGuest-Konsolenzugriff), melden sich als Root an und führen die gewünschten Aktionen aus. Sofern nicht ein benannter Account / eine benannte Zugangskarte für den Konsolenzugriff verwendet wird, gibt es wahrscheinlich nicht viele Prüfpfade.

1. Stellen Sie sicher, dass sie wirklich so sind, wie sie sagen. Identitätsdiebstahl ist nicht das Problem, Identitätsüberprüfung ist.
2. Prüfen Sie ihre Berechtigung, geben Sie ihnen nur das, was sie zu diesem Zeitpunkt benötigen. Durch die gestufte Berechtigung können sie die Berechtigung erhöhen, wenn sie sie benötigen.
3. Prüfen Sie alles, führen Sie Aufzeichnungen, damit Sie wissen, wer was wann wo getan hat. Am liebsten auch warum

Sie sollten von jedem Benutzer verlangen, dass er sudo für jeden Root-Befehl als Richtlinie verwendet. Es gibt keinen Grund, "sudo bash" oder ähnliches auszuführen, es dient nur der Bequemlichkeit, der Unwissenheit oder der Verdeckung der eigenen Spuren.

Wenn Sie Anmeldungen für das Root-Konto direkt deaktivieren, können Sie das System nur schwer reparieren, wenn schwerwiegende Probleme auftreten.

Wenn Sie Ihre Administratoren nicht davon überzeugen können, sich als sie selbst anzumelden und sudo für jeden als root ausgeführten Befehl auszuführen und nicht in eine Shell auszubrechen, haben Sie schwerwiegende Probleme, für die es keine technische Lösung gibt.

Die Autoren von Owl Secure Distribuion (und Solar Designer) vertreten einen genau entgegengesetzten Standpunkt. siehe zB die Antwort /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 für eine Darstellung ihrer Ansprüche. Das Problem der Überwachung der Superuser-Aktionen (welche Person hat was getan) wird auch aus ihrer Sicht angesprochen (im Grunde besteht die Lösung darin, mehrere Root-Benutzer mit unterschiedlichen Namen zu haben).