In unserem Administrationsteam hat jeder Root-Passwörter für alle Client-Server. Aber was sollen wir tun, wenn eines der Teammitglieder nicht mehr mit uns arbeitet? Er hat immer noch unsere Passwörter und wir müssen sie alle ändern, jedes Mal wenn uns jemand verlässt.Wie verwalten Sie die Root-Passwörter der Server?
Jetzt verwenden wir SSH-Schlüssel anstelle von Passwörtern, aber das ist nicht hilfreich, wenn wir etwas anderes als SSH verwenden müssen.
Die von mir ausgeführten Systeme haben eine sudo-only-Richtlinie. Das root-Passwort lautet * (deaktiviert), und die Benutzer müssen sudo verwenden, um Root-Zugriff zu erhalten. Sie können dann Ihre sudoers Datei bearbeiten, um Personen den Zugriff zu gewähren/zu entziehen. Es ist sehr granular und hat viele Konfigurationsmöglichkeiten --- hat aber vernünftige Standardwerte, so dass es nicht lange dauern wird, bis Sie es einrichten.
Obwohl es eine gute Idee ist, eine sudo only-Richtlinie zu verwenden, wie Chris vorgeschlagen hat, ist abhängig von der Größe Ihres Systems ein ldap-Ansatz hilfreich. Wir ergänzen das um eine Datei, die alle Root-Passwörter enthält, aber die Root-Passwörter sind wirklich lang und nicht zu merken. Obwohl dies als Sicherheitslücke angesehen werden kann, können wir uns trotzdem anmelden, wenn der LDAP-Server nicht aktiv ist.
Zitieren Sie mich nicht, aber ich erinnere mich, dass sudoers auch in LDAP gespeichert werden können, was super-cool ist, wenn Sie Tonnen von Servern haben, die zentral verwaltet werden sollen. :-) +1 –
Wenn Sie den SSH-Zugriff über Ihre Zertifikate haben, können Sie nicht über ssh anmelden und ändern Sie die root Passwort per passwd oder sudo passwd, wenn Sie etwas anderes, das das Passwort erfordert tun müssen?
Wenn Sie Root-Zugang haben, können Sie Root-Passwort ändern, aber Benutzer, die root-Zugriff über Zertifikate haben sollen das Root-Passwort nicht ändern, aus vielen Gründen – bmwael
Letztes Mal versuchte ich es, passwd root aufgefordert für die altes root-Passwort auch wenn es bereits als root läuft, aber wiederum kein Schutz als root kann/etc/shadow direkt bearbeiten. – Joshua
Wir verwenden die sudo only-Richtlinie, in der ich arbeite, aber Root-Passwörter bleiben erhalten. Die Root-Passwörter stehen nur ausgewählten Mitarbeitern zur Verfügung. Wir haben ein Programm namens Password Manager Pro, das alle unsere Passwörter speichert und auch Passwort-Audits ermöglicht. Dadurch können wir zurückgehen und sehen, welche Kennwörter von welchen Benutzern aufgerufen wurden. Daher können wir nur die Passwörter ändern, die tatsächlich geändert werden müssen.
Abgesehen von der sudo-Richtlinie, die wahrscheinlich besser ist, gibt es keinen Grund, warum jeder Administrator kein eigenes Konto mit UID 0, aber anders benannt, mit einem anderen Passwort und sogar anderen Home-Verzeichnis haben könnte. Entfernen Sie einfach ihren Account, wenn sie weg sind.
Wir haben es so einfach gemacht, die Root-Passwörter auf jeder Maschine, die wir verwalten, zu ändern, also haben wir einfach das Skript ausgeführt, als die Leute gegangen sind. Ich weiß nicht sehr klug, aber es hat funktioniert. Vor meiner Zeit hatte jeder in der Firma Zugriff auf root auf allen Servern. Zum Glück haben wir uns davon entfernt.
Im Allgemeinen, wenn jemand unser Team verlässt, kümmern wir uns nicht um Root-Passwörter zu ändern. Entweder haben sie die Firma verlassen (und haben keine Möglichkeit mehr, auf die Maschinen zuzugreifen, da ihr VPN gesperrt wurde, ebenso wie ihr Ausweiszugang zum Gebäude und ihr drahtloser Zugang zum Netzwerk), oder sie sind in einer anderen Abteilung innerhalb des Unternehmens und haben die Professionalität, um nicht mit unserer Umgebung zu verschrauben.
Ist es ein Sicherheitsloch? Könnte sein. Aber wirklich, wenn sie sich mit unserer Umwelt anlegen wollten, hätten sie das vor dem Weitermachen getan.
Bisher hat jeder, der das Team verlässt, der wieder Zugang zu unseren Maschinen haben möchte, immer um Erlaubnis gebeten, obwohl sie ohne die Erlaubnis weiterkommen könnten. Ich sehe keinen Grund, unsere Fähigkeit, Arbeit zu erledigen, zu behindern, d. H. Keinen Grund zu glauben, dass jemand anderes, der sich weiter und weiter bewegt, anders handeln würde.
Angemessen starkes Root-Passwort. Anders auf jeder Box. Keine Remote-Root-Logins und keine Passwörter für Logins, nur Schlüssel.
würde ich normalerweise folgendes vorschlagen:
Nun, mit dieser Einstellung alle Benutzer sudo für remote admin verwenden müssen, aber wenn das System ernsthaft vermasselt ist, gibt es keine Suche nach das Root-Passwort zum Entsperren der Konsole.
EDIT: andere Systemverwaltungstools, die ihre eigenen Logins bereitstellen, müssen ebenfalls angepasst werden.
Das ist ein wirklich schönes Setup. Ich mag die Idee von pw-less Login an der physischen Konsole. Sie müssen jedoch sicherstellen, dass jede Software, die Systemkonten zur Authentifizierung verwendet (WebMin usw.), ebenfalls angepasst wird. – sleske
Vielen Dank und danke, dass Sie darauf hingewiesen haben, dass andere Software manchmal die Anmeldung über unerwartete Pfade ermöglicht. – Joshua
SSH-Schlüssel haben keine echte Alternative.
Für die Verwaltung vieler authorized_keys Dateien auf vielen Servern müssen Sie Ihre eigene Lösung implementieren, wenn Sie nicht die gleiche Datei auf jedem Server haben wollen. Entweder über ein eigenes Tool oder mit einer Konfigurationsverwaltungslösung wie Puppet, Ansible oder ähnlichem.
Sonst eine for-Schleife in bash oder einige clush Aktion wird ausreichen.
Alles außer SSH-Logins:
Für Dienstleistungen, die Sie ausführen, die Login-basiert, mit einem zentralen Backend eine Art Authentifizierung verwenden. Denken Sie daran, dass niemand arbeiten wird, wenn dieses Backend nicht verfügbar ist!
Führen Sie den Dienst gruppiert aus. Machen Sie keine Hacks mit einem Super-Duper-Service Backdoor-Account, um immer Zugriff zu haben, falls etwas kaputt geht (wie der Admin-Zugang aufgrund einer Fehlkonfiguration). Unabhängig davon, wie sehr Sie die Zugriffs- oder Konfigurationsänderungen überwachen, die sich auf dieses Konto auswirken, ist dies "nur schlecht" (TM).
Anstatt diese Hintertür richtig zu machen, können Sie auch einfach die Anwendung clustern oder zumindest ein Ersatzsystem haben, das regelmäßig die vorhandene Konfiguration widerspiegelt, wenn die Hauptbox stirbt, die dann leicht durch Routingänderungen aktiviert werden kann im Netzwerk. Wenn das zu kompliziert klingt, ist Ihr Geschäft entweder zu klein und Sie können mit einem halben bis zu zwei Tagen Ausfallzeit leben. Oder Sie hassen Cluster wegen fehlendem Wissen und sparen nur an den falschen Dingen.
Im Allgemeinen: Wenn Sie Software verwenden, die mit irgendeiner Art von Active Directory oder LDAP-Integration unbrauchbar ist, müssen Sie den Hai springen und Passwörter für diese manuell ändern.
Auch eine dedizierte Passwort-Management-Datenbank, die nur von sehr wenigen direkt zugegriffen werden kann, und nur für alle anderen schreibgeschützt ist, ist sehr nett. Ärgere dich nicht mit Excel-Dateien, da diese nicht über die richtige Rechteverwaltung verfügen. Die Arbeit mit der Versionskontrolle für .csv-Dateien schneidet nach einem bestimmten Schwellenwert nicht wirklich ab.
Wie oft suchen Sie nach anderen Benutzern von uid/gid 0 und nach dem Deaktivieren des root-Passworts? –
Auf guten Betriebssystemen (z. B. OpenBSD) gibt es eine tägliche E-Mail, die Sie darüber informiert, welche Änderungen an verschiedenen wichtigen Dateien vorgenommen wurden, z. B. der Kennwortdatenbank (sowie dem Überwachungsskript selbst). :-) –
Dieses Auditing-Skript warnt Sie übrigens auch vor neuen setuid-Programmen. –