Frage Sollten wir den Root-Benutzer deaktivieren?


Sollten wir das root-Passwort entfernen, die Remote-Anmeldung deaktivieren und grundsätzlich von den Administratoren verlangen, sudo für administrative Aktionen zu verwenden?

alt text


20
2018-05-02 01:31


Ursprung




Antworten:


Auf allen meinen Servern ist der root-Account deaktiviert (sp_pwdp einstellen *). Dies ist zu verlangen sudo für alle Root-Zugriffe. [1] Der Zweck ist, dass alle Superuser-Aktivitäten auditiert werden, damit die Leute sehen können, was mit dem System gemacht wurde.

Für eine Hardcore-Option können Sie machen sudo Schreiben in eine Protokolldatei (im Gegensatz zu syslog), und machen Sie die Datei nur anhängen (mit chattr unter Linux oder chflags auf BSD). Auf diese Weise kann niemand das Audit nachträglich bearbeiten.

[1] Ich habe auch eine Richtlinie, keine Root-Shell auszuführen oder Shell-Escapes aus einem Root-Prozess auszuführen. (Es ist in Ordnung zu verwenden sudo sh -c '...' um Pipelines oder Umleitungen zu machen.


15
2018-05-02 01:57



"Kein Rennen mit Muscheln!" Weißt du, wie viele Programme haben einen "Drop to Shell" -Befehl in ihnen? Sogar Vor Sie fangen an, Shell-Job-Kontrolle zu betrachten ... - womble♦
Ich spreche von "No Shell" als Richtlinie, nicht als Sudo-Option. (Sudo hat eine Noexec-Option, aber das ist natürlich nicht wasserdicht, es sei denn, Sie beschränken die spezifischen Programme, die ein Benutzer ausführen kann.) - Chris Jester-Young
Ist es möglich, sudo so zu konfigurieren, dass "sudo -s" nicht verwendet werden kann? Ich habe nur sudoers verwendet, um einzelne Befehle zu konfigurieren.
@ Graham: Du kannst. Wie Sie jedoch aus den obigen Kommentaren sehen können, hört das nichts auf, wenn Ihre Benutzer sonst etwas ausführen können. Die einzige wasserdichte Lösung ist ein Whitelist-Ansatz, bei dem Sie bestimmte Programme auflisten, die Benutzer ausführen können, und sie müssen alle dynamisch verknüpft sein (damit die "noexec" -Option ihre Aufgabe erfüllen kann). - Chris Jester-Young
Als eine Politik, wo du den Admins vertraust, ist das gut. Sie können sehen, welche Befehle Benutzer ausführen, was sehr hilfreich sein kann, wenn Sie herausfinden wollen, was sich geändert hat. - Hamish Downer


ich mit Nachdruck empfehlen, den root-Benutzer nicht zu deaktivieren. Deaktivieren oder beschränken Sie Root-Logins (über securetty und über sshd_config und über PAM und über was hast du) Wenn dein System es erlaubt, limitiere root die Privilegien oder teile die root-Rolle (ähnlich wie) auf RSBAC tut es.) Aber bitte, BitteDeaktivieren Sie das root-Konto nicht, indem Sie das Passwort entfernen. Andernfalls wird es unmöglich, sich über das System beim System anzumelden sulogin. sulogin wird von allen Initskripten verwendet, die ich kenne, wenn schwerwiegende Fehler von fsck gemeldet werden - und das bedeutet, dass Sie aus dem System ausgeschlossen werden, wenn das Root-Dateisystem beschädigt wird.

Zur Klarstellung: Indem ich den root-Account deaktiviere, indem ich das Passwort lösche, meine ich die verschiedenen Mechanismen, die mit einem! oder a * im Passwortfeld von / etc / shadow oder ähnlich. Ich meine nicht, "ändern Sie den Root-Login-Mechanismus, damit Sie nicht nach einem Passwort gefragt werden."


14
2018-05-02 21:32



Ist das ein Problem in Systemen wie Ubuntu, die niemals ein root-Passwort setzen? Ich scheine "sudo sulogin" ausführen zu können, aber vielleicht verstehe ich keinen kritischen Aspekt. - jldugger
Leider bin ich nicht mit der Art vertraut, wie Ubuntu root behandelt. Aber wenn Sie in der Lage sind, "sudo sulogin" auszuführen und eine root-Shell zu erhalten, ohne dass Sie nach einem root-Passwort gefragt werden, dann ist das kein Problem, da möglicherweise derselbe Mechanismus beim Booten angewendet wird. Sie könnten versuchen, grepping für sulogin durch die Initskripte zu suchen, um zu überprüfen, wann und wie es aufgerufen wird. - Mihai Limbăşan
Ubuntu verwendet kein Sulogin. Wenn Sie in den Einzelbenutzermodus wechseln, erhalten Sie sofort eine Root-Shell. Lesen Sie jedoch meinen Kommentar (in meinem Post), um zu sehen, warum dies in den meisten Fällen kein Problem ist. - Chris Jester-Young
@ Chris: Danke, antwortete dort. - Mihai Limbăşan
Außerdem gibt es Ansprüche, die haben su oder sudo In Ihrem System für Benutzer verfügbar bedeutet mehr Sicherheitsrisiken, die Sie vermeiden können, wenn Sie nur dedizierte Root-Benutzer haben. Das ist eine Position, die von den Autoren der Eulen-sicheren Distribution (und Solar-Designer unter ihnen) befürwortet wird - unix.stackexchange.com/questions/8581/... versucht ihre Position mit Referenzen zu präsentieren. - imz -- Ivan Zakharyaschev


Ich habe das root-Konto auf allen meinen Servern aktiviert. Alle Administratoren haben ihren eigenen Benutzer und müssen sich damit einloggen. Von dort wechseln sie zur Wurzel. (root ssh ist deaktiviert)

Halten Sie die Anzahl der Administratoren niedrig. Nur die Personen, die wirklich Root-Zugriff auf diesem Server benötigen, haben das Passwort.

Ich bin kein Fan von Sudo. Es ist viel zu einfach, 'sudo bash' für eine root-Shell zu verwenden. Ich bin mir bewusst, dass dies deaktiviert sein kann, aber warum? Beschränken Sie einfach die Benutzer, die Administratoraufgaben ausführen und miteinander sprechen können. Wir haben eine Richtlinie, Root-Terminals nicht unbeaufsichtigt zu lassen. Also log dich ein, su, mach die Arbeit, log dich aus.

Hinweis: Ich arbeite in einem relativ kleinen Unternehmen (50 Mitarbeiter) und wir kommen mit nur 2 Teilzeit-Admins (1 Windows / 1 Linux) zurecht. Diese Vorgehensweise ist möglicherweise nicht die beste, wenn Sie um Größenordnungen mehr Benutzer haben. Ich würde immer noch nicht Sudo verwenden. Es gibt andere Möglichkeiten, Root-Aktivitäten zu protokollieren.


2
2018-05-02 05:55



Wenn Sie root shell von einer Konsole wollen, können Sie einfach 'sudo -i' ausführen, anstatt es von sudo bash zu öffnen. Persönlich mag ich die Idee, sich als root-Benutzer direkt anzumelden, nicht wirklich, da es für böswilliges Goaten zu riskant ist (d. H. Versehentlich den Computer bei geöffneter root-Shell unlocked lassen). - Spoike
Sie verlieren jedoch die Protokollierung / Auditing damit. Stellen Sie sicher, dass alle Benutzer sudo verwenden und verhindern Sie, dass Benutzer sudo bash oder sudo -i oder sudo -s mit der Unternehmensrichtlinie ausführen. Das gibt Ihnen einen Audit-Trail, und wenn Sie alle Ihre Logs an einen zentralen Loghost übertragen, können Sie leicht überprüfen, ob die Benutzer die Richtlinien befolgen. - Christopher Cashell
Das ist der Ansatz, der von den Autoren der Owl secure distribuion (und dem Solar Designer unter ihnen) vertreten und befürwortet wird - unix.stackexchange.com/questions/8581/... versucht ihre Position mit Referenzen zu präsentieren. - imz -- Ivan Zakharyaschev


Das root-Passwort zu deaktivieren ist imho eine falsche "gute Idee". Der Tag, an dem du es brauchen wirst, wirst du Ja wirklich brauchen. (Abhängig von Ihrer Konfiguration benötigen Sie möglicherweise den Einzelbenutzermodus für Beispiel)

Die Deaktivierung der Root-Remote-Anmeldung ist möglicherweise relevant, jedoch nur, wenn Sie sich lokal anmelden können.

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


1
2018-05-29 17:34



Was ist, wenn das Booten in den Einzelbenutzermodus eine Grub-Option ist? - jldugger
Was ist das Ziel der Deaktivierung des Root-Accounts? Was werden Sie tun, wenn Sie Ihre sudo-Binärdatei oder Konfiguration (oder welches Werkzeug Sie verwenden) bremsen? - Benoit
Disabling root remote login might be relevant but only if you are able to log on locally. Das ist schlicht eklatant. Sie können sich remote mit anmelden irgendein Konto; Die Deaktivierung der Root-Remote-Anmeldung beschränkt Sie nicht auf den lokalen Zugriff. - Dan


Ich deaktiviere nur den SSH-Zugriff für root und fordere Benutzer (oft nur Entwickler) 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 jemand ein gutes Passwort schreibt. Sobald drinnen sind, haben nur die Admins die Berechtigungen für sudo.


1
2018-05-29 18:07



Das Ändern des SSH-Ports ist sowieso sinnlos. Ein einfacher Portscan gibt es einfach weg. Wenn ich auf Port 22 auf meinem Computer telnet, bekomme ich SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2 - Matt Simmons
@MattSimmons Ja, aber die meisten Wörterbuchangriffe sind automatisiert und sehr elementar. Sie kümmern sich nicht um Port-Scans; Sie versuchen, sich mit zufälligen IP-Adressen an Port 22 zu verbinden, und wenn sie Timeouts haben, gehen sie zur nächsten IP in ihrer Liste über. Es ist keine Sicherheitsmaßnahme, es hilft nur, die automatisierten Port 22-Attacken loszuwerden. Offensichtlich ist ein gezielter Angriff ein ganz anderes Ballspiel. - Dan


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

Szenario 1 Ein Administrator führt versehentlich einen Rogue-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 Logins (z. B. su / sudo) würde der Administrator aufgefordert, sich zu authentifizieren, wenn der Rogue-Code versucht, erhöhte Rechte zu verwenden ... Wenn er nicht erhöht wird, beschränkt er sich auf die Benutzerrechte, was zu minimalem Schaden führen sollte.

Szenario 2 Ein Schurkenverwalter möchte Informationen erhalten / Änderungen vornehmen. Sie verbinden sich mit der Konsole (physischer Konsolenzugriff, HP iLo / ähnlich oder vGuest Konsolenzugriff), melden sich als root an und tun, was sie wollen. Wenn es keine benannte Konto- / Zugriffskarte gibt, die für den Zugriff auf die Konsole verwendet wird, gibt es wahrscheinlich nicht viel von einem Audit-Trail.

  1. Stellen Sie sicher, dass sie wirklich sind, von denen sie sagen, dass sie sind. Identitätsdiebstahl ist nicht das Problem, Identitätsprüfung ist.
  2. Überprüfen Sie ihre Autorisierung, geben Sie ihnen nur, was sie zu diesem Zeitpunkt brauchen. Die abgestufte Autorisierung ermöglicht es ihnen, zu erhöhen, wenn sie es brauchen.
  3. Überprüfe alles, habe einen Rekord, damit du weißt, wer, was wann und wo gemacht hat. Vorzugsweise auch deshalb

1
2017-10-10 05:10





Sie sollten festlegen, dass jeder sudo für jeden root-Befehl als Richtlinie verwendet. Es gibt niemals einen Grund, "sudo bash" oder ähnliches zu spielen, es ist nur der Bequemlichkeit wegen, wegen der Ignoranz, oder um seine Spuren zu verwischen.

Wenn Sie die Anmeldung beim root-Konto direkt deaktivieren, lähmen Sie Ihre Fähigkeit, das System bei schwerwiegenden Problemen zu reparieren.

Wenn Sie Ihre Administratoren nicht davon überzeugen können, sich als selbst einzuloggen 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.


0
2018-05-23 23:53





Die Autoren von Owl Secure Distribution (und Solar Designer) haben eine entgegengesetzte sorgfältig begründete Sichtweise; siehe z.B. die Antwort https://unix.stackexchange.com/questions/8581/which-is-the-sast-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 gemacht) wird ebenfalls aus ihrer Sicht betrachtet (im Grunde besteht die Lösung darin, mehrere Root-Benutzer mit unterschiedlichen Namen zu haben).


0
2018-05-21 05:03