Nicht, dass es eine sehr gute Idee wäre, es zu ändern, aber zum Spaß. Nach diesem Beitrag gibt es noch einige Probleme auch nach Einträgen im Wechsel /etc/passwd
, /etc/shadow
und /etc/sudoers
. Irgendwelche Vorschläge?
Nicht, dass es eine sehr gute Idee wäre, es zu ändern, aber zum Spaß. Nach diesem Beitrag gibt es noch einige Probleme auch nach Einträgen im Wechsel /etc/passwd
, /etc/shadow
und /etc/sudoers
. Irgendwelche Vorschläge?
Antworten:
Theoretisch reicht es aus, es zu ändern /etc/passwd
und /etc/shadow
root umzubenennen. Das Problem tritt auf, weil so gut wie jede existierende Unix-Software davon ausgeht, dass der Benutzername 'root' existiert und es sich um den Superuser handelt - Mail-Aliase, verschiedene Daemons, Cron ...
Wenn Sie es find /etc -type f -exec grep -l root {} +
unbedingt ausprobieren möchten, sollten Sie zunächst eine Liste aller Konfigurationsdateien finden, die Sie wahrscheinlich ändern müssen - aber wie Sie bereits sagten, ist dies in fast jeder denkbaren Situation eine wirklich schlechte Idee.
BEARBEITEN Noch ein Gedanke - wenn Sie es noch nicht getan haben (was Sie sollten ), stellen Sie sicher, dass es /etc/aliases
einen Eintrag für root
und einen vorhandenen Benutzernamen oder eine E-Mail-Adresse enthält, die korrekt ausgewertet wird. Viele automatisierte systemweite Aufgaben ( cron
z. B.) senden ihre Ausgabe per E-Mail an root
, die normalerweise an die Systemadministratoren gerichtet ist, die für den Betrieb des Systems verantwortlich sind.
chown root …
oder ähnlich in einem Shell-Skript geschrieben haben.
All diese Angstmache, die sagt: "Tu es nicht!" ist lächerlich. Zu einer Zeit, ja, hat es wahrscheinlich viele schlecht geschriebene Skripte gebrochen, aber ich vermute, dass diese nicht mehr so häufig sind; Zumindest nicht in den Standarddistributionen.
Wir wurden angewiesen, das Root-Konto auf einer Untergruppe von Linux-Servern umzubenennen. Nachdem ich versucht hatte herauszufinden, wie man das richtig macht, fand ich stattdessen viele, viele Posts mit der Aufschrift "Tu es nicht!" mit vielen furchtbaren Warnungen vor "schlechten Dingen", wenn Sie sich dazu entschließen. Aber ich habe noch keine konkreten Beispiele für die "schlechten Sachen" gefunden, die passieren könnten.
Lassen Sie mich zurücktreten und erklären, wo ich bin und wie wir hierher gekommen sind. Wir bauen eine PCI-kompatible Umgebung auf, und eines der Tools, mit denen wir diese "Anforderungen" erfüllen können, besagt, dass wir die Konten root, administrator und guest in etwas anderes umbenennen müssen. Für diejenigen, die sich nicht mit PCI auskennen, haben Sie die Möglichkeit, entweder die Richtlinien zu befolgen oder zu dokumentieren, warum Sie diese Richtlinien entweder nicht befolgen können oder nicht, und welche Abhilfemaßnahmen Sie ergreifen müssen, um die Sicherheit der Systeme zu gewährleisten. Daher stelle ich mir vor, dass die meisten Orte dokumentieren, warum sie ihre Stammkonten nicht umbenennen werden. Unsere Gruppe hat jedoch entschieden, dass wir, wenn wir die Windows-Administratorkonten problemlos umbenennen können, auch die Linux-Stammkonten umbenennen werden.
Ich bin mit den Argumenten "Sicherheit durch Dunkelheit" bestens vertraut. Ich weiß, dass das Ändern des Root-Kontonamens die Sicherheit nicht wesentlich verbessert. Root sollte bei SSH deaktiviert sein usw. Ich weiß, das ist nicht der Punkt, ich bin nicht daran interessiert, mehr zu hören. Ich habe auch kein Interesse mehr an Warnungen "der Himmel wird fallen". Ich suche nach Aussagen wie diesen: "> Diese schlechte Sache <wird mit> diesem Standardpaket <passieren (es sei denn, Sie> tun dies <)".
Bisher habe ich 3 CentOS (RHEL) -Systeme, die anscheinend keine Probleme beim Umbenennen des Root-Kontos haben. Folgendes habe ich getan: Ich habe den Kontonamen in / etc / passwd, / etc / shadow, / etc / group und / etc / gshadow geändert. Dann wurde in / etc / nach dem Namen root gesucht und die Postfix-Aliase-Datei so geändert, dass root ein Alias für unseren neuen Kontonamen war. Nennen Sie ihn rojotoro. (Ähnliches sollte für andere E-Mail-Systeme geschehen). Ich stellte auch fest, dass ich einige Konfigurationen für logrotate ändern musste, wenn ich beschrieb, wem die Dateien gehören sollten, die es automatisch erstellen würde. Und das war alles, was ich bisher geändert habe.
Ich habe mir viele init.d-Skripte angesehen, aber nichts geändert, und beim Booten scheint alles in Ordnung zu sein. Ich muss das neue Konto angeben, wenn ich sudo verwende: "sudo -u rojotoro vim / etc / passwd" als Beispiel, aber ich musste eigentlich nichts in der sudoers-Datei ändern. Ich habe vielleicht ein paar Probleme mit Selinux erwartet, die wir haben und die wir erzwingen, aber bisher musste ich dieses System nicht berühren.
Ich kann auch feststellen, dass mkdev- oder mkfs-Skripte möglicherweise angepasst werden müssen, aber ich habe nicht vor, diese zu verwenden, daher habe ich sie nicht mit der gebührenden Sorgfalt betrachtet.
Wenn es wirklich so einfach ist, ohne nachteilige Auswirkungen auf ein selinux-fähiges System zu wechseln, warum dann die Fortsetzung all der Angstmacherei?
rpm -Va
auf Systemen, auf denen das Root-Konto umbenannt wurde, angezeigt wird? Laut dem Maximum RPM-Leitfaden "Die Benutzer- und Gruppen-IDs müssen nicht numerisch sein" kann dies bei der Installation nicht bei jedem RPM erfolgen, der angibt, dass sich Dateien im Besitz von root befinden müssen. Ich frage mich nur, wie Ihre Systeme damit umgehen würden.
vorschlag: mach das nicht.
Einige Tools versuchen über uid mit root zu kommunizieren, da sollte es keine Probleme geben. Einige Tools setzen voraus, dass Ihr Root-Konto als root bezeichnet wird und nicht mehr funktioniert. Versuchen Sie es einfach nicht, es sei denn, Sie sind bereit, die Hälfte Ihres Systems "zum Spaß" neu zu kompilieren.
Meiner Meinung nach ist es am einfachsten, einen neuen Benutzer (Alias) mit der UID 0 und /root
als Startseite zu erstellen .
Warum wechseln Sie nicht die Standard-Shell Ihres Roots auf /bin/false
oder /sbin/nologin
(damit sich niemand anmelden kann, aber das System sie weiterhin verwendet) und melden sich bei dem neu erstellten Alias an?
razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root
Wenn Sie die root-Shell in nologin ändern, werden sudo, mail oder ftw nicht beschädigt.
/bin/false
oder /sbin/nologin
keine Dienste starten kann. Also müssten alle neu konfiguriert werden. Außerdem sollte die Sicherheit verbessert werden, da das Hinzufügen eines zweiten Kontos mit "Root" -Berechtigungen die Sicherheit kaum verbessert.
Linux ist nicht Windows und root kann derzeit nicht einfach umbenannt werden, ohne dass in Zukunft unbekannte Probleme auftreten.
Das Deaktivieren der Remoteanmeldung und sogar der lokalen Anmeldung als Root ist sicherer, da dadurch der Account-Root aktiv deaktiviert wird! UBUNTU tut dies im Wesentlichen und erzwingt sudo statt root-Zugriff.
Grundsätzlich kann niemand das Root-Konto verwenden, um Ihr System anzugreifen, da es nicht mehr zum Anmelden am System verwendet werden kann!
Es wäre schön, wenn eine Standardmethode erstellt würde, mit der sowohl der Name des Root-Kontos als auch dessen UID bei der Installation nach dem Zufallsprinzip geändert werden können, und wenn dies bei jedem Kaltstart möglich ist, um ein UID-Targeting zu verhindern, das derzeit jedoch nicht vorhanden ist.
Anpassen von / etc / passwd Ändern Sie root: x: 0: 0: root: / root: / bin / nologin
Erstellen Sie ein einziges Fallback-Administratorkonto, das NUR IM NOTFALL verwendet werden kann! fallbackadmin: x: 0: 0: root: / root: / bin / bash
Implementieren Sie sudo für alle Administratoren, damit die Änderungsprotokollprüfung implementiert werden kann, um genau zu verfolgen, wer Änderungen für die Verantwortlichkeit vornimmt!
Dies implementiert die PCI US Gov-Anforderungen zum Deaktivieren der Standardadministrator- / Gastkonten und zum Erstellen eines einzelnen Notfalladministratorkontos.
Eine Möglichkeit, Protokolle für die Überwachung zu archivieren, besteht darin, den Terminalverlauf aller Benutzer mit sudo-Kontozugriff zu erfassen, wenn keine zentrale AAA implementiert ist.
Eine Lösung zum Implementieren von Nur-Administrator-Konten besteht darin, ein Nur-Benutzer-Konto und ein sudo-fähiges Konto zu erstellen und den Benutzer dann zu zwingen, für den Administratorzugriff auf sein sudo-fähiges Konto zu su zu wechseln.
Sie können auch die Smartcard-Authentifizierung implementieren, wenn Sie eine höhere Sicherheit wünschen. Für GNU / Linux stehen Lösungen zur Verfügung, die im Vergleich zu CAC-Lösungen für Common Access Cards in den USA für die Zwei-Faktor-Authentifizierung stehen.