Zum größten Teil wird durch das Deaktivieren von Remote-Root-Anmeldungen nur wenig erreicht. Es hilft nur geringfügig dabei, eine Richtlinie durchzusetzen, bei der sich Administratoren über ihre eigenen Konten anmelden und subei Bedarf rooten (oder sudomöglicherweise mit sudosh... verwenden, abhängig von Ihren Richtlinien).
Das Erstellen extrem langer und umständlicher Root-Passwörter (effektiv, solange Sie noch nicht das alte DES + 12-Bit-Salt-Hashing für Ihre Passwörter verwenden) ist bei der Durchsetzung einer solchen Richtlinie ungefähr genauso effektiv.
Eine mir vertraute Site hatte ein System, bei dem die eindeutigen Kennwörter für jeden Host zufällig generiert, in einer Datenbank gespeichert und an die Systeme weitergegeben wurden. Administratoren mussten sshmit ihren normalen Konten und sudofür die meisten Operationen arbeiten. Das Root-Passwort war ihnen jedoch über einen SSL-basierten internen Webdienst zugänglich (für den außerdem das RSA SecurID-Token und die PIN erforderlich waren). Das Abrufen eines Root-Passworts umfasste die Eingabe einer Begründung (normalerweise ein Link zu einer Remedy (TM) -Ticketnummer) und Zugriffen, die regelmäßig überprüft wurden. Einer der wenigen akzeptablen Gründe für die direkte Verwendung des Root-Passworts waren Fälle, in denen ein System fsckwährend des Startvorgangs gestoppt wurde ... undsuloginbenötigte ein echtes Root-Passwort, um die Überprüfungs- und Reparaturprozesse des Dateisystems manuell auszuführen. (Es gab einige Diskussionen über alternative Methoden dafür - die für Linux relativ einfach sind, aber weitaus schwieriger werden, wenn Sie versuchen, Ihre Verfahren zu erweitern, um die vielen älteren HP-UX-, AIX- und älteren SunOS- und Solaris-Systeme zu berücksichtigen, die dies tun waren in dieser Umgebung noch in Produktion).
Es gibt Eckfälle, in denen ein Root-Passwort erforderlich ist - oder zumindest die beste verfügbare Alternative ist. Es ist im Allgemeinen Ihre beste Strategie, es verfügbar zu halten und gleichzeitig ausreichend robust gegen die Art von Bedrohungen zu machen, die Sie erwarten können.
Eine andere Site, die ich kenne, hat einen ziemlich eleganten Ansatz für die dezentrale Kontoverwaltung. Sie verfügen über Benutzer- * und Sudo- * Pakete (Think RPMs), die unter Verwendung der normalen Paketverwaltungsverfahren und der Automatisierungsinfrastruktur in die Systeme installiert werden. In ihrem Fall ist das sudo- * Paket vom entsprechenden user- * Paket abhängig. Dies ist hilfreich, da Sie damit Cluster von Computern mit lokalisierten Konten haben können (alle Konten sind Administratoren, Entwickler, Supportmitarbeiter oder "kopflose" Konten) und die Abhängigkeit von LDAP / NIS oder anderen vernetzten Identitäts- und Authentifizierungsdiensten beseitigt wird. (Dies reduziert die Kopplung zwischen Systemen und macht sie wesentlich robuster).
Ein Gedanke, den ich an diesem Ansatz mag, ist, dass er Flexibilität bietet. Jeder mit sudoZugriff kann einen Befehl zum Hinzufügen eines normalen Benutzers oder eines anderen sudoBenutzerkontos ausgeben . Wenn ich also an einem Ticket arbeite, kann mir jeder, der bereits Zugriff auf ein System hat, problemlos Zugriff gewähren. Es gibt keine Verzögerungen, während ein Ticket, mit dem ich zu einer Zugriffssteuerungsliste in einer zentralen Datenbank hinzugefügt werden kann, einen zentralisierten Genehmigungsprozess durchläuft und schließlich eine Änderung an das betreffende System zurückgibt. Jeder der autorisierten sudoBenutzer im System kann mir Zugriff gewähren und mich später entfernen. (Ja, wenn ich böse wäre und sie mich spielensudoIch könnte böswillig Dinge ändern, um den Zugriff beizubehalten ... in der Tat gibt es einige Dinge, die ich als normaler Benutzer tun könnte, um den Zugriff nach einer solchen Entfernung beizubehalten. Dies ist jedoch nicht die Bedrohung, über die sie sich Sorgen machen. Mein Zugriff ist immer noch auf eine relativ kleine Anzahl von Systemen insgesamt beschränkt. Daher sind die Auswirkungen eines kompromittierten Kontos immer noch geringer als bei den meisten ähnlichen Programmen, die ich gesehen habe.