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/shadowund /etc/sudoers. Irgendwelche Vorschläge?
der kontoname "root"? das oberste Verzeichnis "/"?
Akira
4
der Benutzername root
yxkb
1
dann klären Sie bitte Ihre Frage ...
Akira
7 Jahre später frage ich mich, ob Sie damit angefangen haben und welche Art von BadStuff daraufhin passiert ist ... ^ _ ^
Mioriin
Antworten:
29
Theoretisch reicht es aus, es zu ändern /etc/passwdund /etc/shadowroot 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/aliaseseinen Eintrag für rootund einen vorhandenen Benutzernamen oder eine E-Mail-Adresse enthält, die korrekt ausgewertet wird. Viele automatisierte systemweite Aufgaben ( cronz. 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.
Nur von Benutzernamen, wenn die betreffende Gruppe nicht ihre Standardgruppe ist, aber ein guter Punkt.
Shadur
3
ist es? Ich dachte, die meisten Apps gehen für UID und nicht den Namen. Ich denke, idealerweise sollte keine Anwendung annehmen, "root = UID 0"
yxkb
2
@yxkb: Du hast recht, keine Anwendung sollte das annehmen. Aber ich würde wirklich gerne 1 $ für jede Anwendung oder jedes Skript erhalten, das dies tut! :)
Bram
1
Tatsächlich. Denken wir an alle Zeiten, die wir alle persönlich chown root …oder ähnlich in einem Shell-Skript geschrieben haben.
Derobert
24
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?
Dies wäre eine bessere Antwort, wenn Sie die einzelnen Absätze herausschneiden, in denen Unwissende angesprochen werden sollen. Es ist nicht wirklich notwendig
Michael Mrozek
3
Du hast recht, aber es hat eine Weile gedauert, bis ich es eingestanden habe. Es war beabsichtigt, sicherzustellen, dass andere tatsächlich Erfahrung mit dem Ändern des Root-Benutzernamens hatten, bevor sie die Idee verprügelten, aber es war wirklich nicht nötig.
5mi11er
3
Da Sie unter CentOS arbeiten: Können Sie überprüfen, was rpm -Vaauf 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.
Bram
1
Wo in PCI heißt es, dass Sie ROOT umbenennen müssen?
Kidburla
@MichaelMrozek, Normalerweise würde ich einer Antwort zustimmen, die keine solche Hintergrundgeschichte haben sollte. Eine Internetsuche zu diesem Thema ist jedoch mit so vielen Warnungen behaftet, dass in drei Abschnitten über OP gesprochen wird. Ich denke, es ist in diesem Fall angebracht. Es half, seinen "How To" -Absatz zu formulieren, und erleichterte es mir, den Kontext seiner Lösung zu kennen, der meinem ähnlich ist.
user1717828
7
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.
Ich glaube nicht, dass jemand bestreitet, dass das Umbenennen von root bestenfalls eine schrecklich schlechte Idee ist.
Shadur
Kuhkatz, es ist nur eine Vorsichtsmaßnahme. Wenn jemand das tut, kann es hilfreich sein, es zurückzusetzen, wenn Sie wissen, was passiert, wenn jemand root wechselt
yxkb
In dem Artikel, in dem Sie die Idee hatten, dass dies die Anmeldung als root unterbricht, als würde man sudo verwenden. Daher ist eine Neuinstallation nur dann möglich, wenn Sie sie wiederherstellen. Deshalb müssen Sie es nicht versuchen, es ist offensichtlich, wie man es wiederherstellt. Halten Sie außerdem ein LART bereit, falls ein Benutzer es dennoch versucht.
Kuhkatz
Wegen Neukompilierung ... gogo gentoo? Ein Patch in jedem Ebuild, um alle zu regieren?
Bananguin
4
Meiner Meinung nach ist es am einfachsten, einen neuen Benutzer (Alias) mit der UID 0 und /rootals Startseite zu erstellen .
Warum wechseln Sie nicht die Standard-Shell Ihres Roots auf /bin/falseoder /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.
Zugegeben, wie @ 5mi11er anmerkte, habe ich das nicht ausprobiert, aber wenn root's shell auf gesetzt ist /bin/falseoder /sbin/nologinkeine 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.
Bram
Ich denke, diese Lösung ist die beste, die es bisher ermöglicht, den Namen für root zu suchen und die Anmeldung für root zu deaktivieren. Sie können die Reihenfolge der Zeilen vertauschen, sodass root2 vor root erscheint. Whoami meldet root2, d. H. uid to name lookup stoppt, wenn der erste uid-eintrag übereinstimmt. Ich bin nicht einverstanden, dass Dienste nicht gestartet werden können, da der Kernel einen Prozess startet und ihm die UID 0 gibt, um das System einzurichten (init, upstart, ...)
X Tian
2
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.
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ürroot
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 anroot
, die normalerweise an die Systemadministratoren gerichtet ist, die für den Betrieb des Systems verantwortlich sind.quelle
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?
quelle
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.
quelle
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?Wenn Sie die root-Shell in nologin ändern, werden sudo, mail oder ftw nicht beschädigt.
quelle
/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.
quelle