Benennen Sie / etc / passwd und / etc / shadow aus Sicherheitsgründen um [geschlossen]


8

Ich habe einen Server. Mein Server ist sicher, aber stellen wir uns einen guten Hacker vor, der hereinkommt. Er kann jetzt nach /etc/passwdund schauen /etc/shadow. Ich möchte diese Dateien /etc/passwdin etwas umbenennen /etc/xxanoda.

Ich dachte, ich kann einen Link erstellen, aber für einen Hacker ist das einfach ls -l.

Es ist möglich, diese Dateien umzubenennen und trotzdem ein Betriebssystem ohne Kompatibilitätsprobleme zu haben, oder ist es völlig nutzlos? Nur für die Suche nach Wissen.


1
Ich denke, es ist möglich, einen separaten Authentifizierungsserver zu verwenden, um alle Benutzerkennwörter zu speichern. Der Hauptserver kontaktiert den Authentifizierungsserver, wenn ein Benutzer versucht, sich anzumelden. Der Authentifizierungsserver wird von Benutzern ferngehalten (kein direkter Internetzugang).
Strg-Alt-Delor

9
Sicherheit durch Dunkelheit ist überhaupt keine Sicherheit.
Türknauf

Dies ist eine schreckliche, schreckliche, schreckliche Idee.
Shadur

Antworten:


29

Der Dateisystem-Hierarchiestandard für Unix-ähnliche Systeme enthält /etc/passwdeinen festen Speicherort, und die Tools sind daher normalerweise fest codiert, um dort danach zu suchen. Während Sie theoretisch alle relevanten Dienstprogramme neu kompilieren können, um an einem neuen Speicherort zu suchen, kann jeder Angreifer immer nur nach Zeichenfolgen in diesen Binärdateien suchen, um die neue Datei zu finden, oder reguläre Ausdrücke verwenden, um Dateien mit passwdähnlichen Inhalten zu finden .

Die shadowDatei sollte nur für root(und möglicherweise für eine aufgerufene Gruppe shadow) lesbar sein . Wenn es einem Angreifer gelungen ist, Root-Zugriff auf Ihr System zu erhalten, hat er die vollständige Kontrolle und es ist zu diesem Zeitpunkt ziemlich irrelevant, ob er Ihre passwd / shadow-Dateien lesen kann oder nicht.

Es ist denkbar, dass einige Situationen hilfreich sind, wenn sich Dateien nicht an den erwarteten Stellen befinden, z. B. wenn Sie einen schlecht konfigurierten Webserver haben, auf dem jemand Anfragen stellen http://myserver/../../etc/passwdkann. Im Allgemeinen erfordert diese Art der Indirektion jedoch viel Arbeit für einen minimalen Sicherheitsvorteil.


8
Im letzten Fall ist es besser, stattdessen den Webserver zu reparieren ...
Braiam

Aber das ist in Ordnung, da alle Benutzer mit Konten auf dem Server selbst keine Kennwörter haben, nur SSH-Schlüssel und Kennwortinformationen /etc/passwdsowieso nicht gespeichert sind , oder?
Blacklight Shining

12

Das Beste, was wäre, ist "völlig nutzlos", wie Sie es ausdrücken. (Es bietet keine zusätzliche Hürde für einen Eindringling)

/etc/passwd enthält Kontonamen, aber jeder, der Shell-Zugriff auf das System hat, kann sie finden.

/etc/shadowenthält vertrauliche Informationen (die Kennwort-Hashes), ist jedoch nur für root lesbar. Wenn es einem Eindringling gelungen ist, Root-Rechte zu erhalten - wie buchstabieren Sie eine Katastrophe ?


1
Sie sollten auch davon ausgehen, dass ein Angreifer vollen Zugriff auf jede Datei auf Ihrem System hat (und möglicherweise eine eigene Kopie heruntergeladen hat), bis Sie etwas anderes wissen.
Bert

4
"Wie buchstabiert man eine Katastrophe?" funktioniert wahrscheinlich besser in einem Kontext, in dem Sie keine Katastrophe buchstabieren müssen, um danach zu fragen: D

9

In modernen Unices (und Unix-Likes, einschließlich Ubuntu) /etc/passwdenthält es keine Geheimnisse. Das Umbenennen wäre schwieriger, als es sich lohnt, da viele Dienstprogramme neu erstellt werden müssten, um an seinem neuen Standort danach zu suchen.

/etc/shadowist eine andere Sache, da diese Datei Geheimnisse enthält, aber das Umbenennen hilft nicht weiter. Es ist nur für root lesbar. Selbst wenn ein Hacker als ein anderer Benutzer in das System eindringt, reicht dies nicht aus, um an die Datei zu gelangen. Aus diesem Grund wurden Passwörter /etc/passwdan erster Stelle entfernt: Jeder muss lesen können /etc/passwd, aber nur root muss in der Lage sein, die tatsächlichen Passwörter zu finden, sodass die Passwörter in eine Datei verschoben wurden, die nur root lesen konnte.

Wenn der Hacker tut Wurzel bekommen, dann ein Umbenennungs sparen Sie nicht. Eine einfache Rekursion grepkönnte dem Hacker eine Liste von Dateien in einem /etc/shadowähnlichen Format geben, und dann muss der Hacker sie nur durchsehen, um die gewünschten Daten zu finden. Sie haben ihn um höchstens ein paar Stunden und wahrscheinlich auch weniger verzögert: Auch dies ist nicht die Zeit wert, die erforderlich wäre, um alle Dienstprogramme zu ändern und neu zu kompilieren, die vom /etc/shadowStandort abhängen .


Außerdem, wenn er Root-Zugriff hat, braucht / braucht / er nicht das Passwort eines anderen. Er kann einfach suauf ein beliebiges Konto zugreifen oder das Kennwort eines beliebigen Benutzers im System ändern. Und wenn er die Passwörter wirklich haben möchte (nur für den Fall, dass die Benutzer ihre Passwörter an anderer Stelle wiederverwenden), kann er eine modifizierte loginBinärdatei hochladen oder ein pamModul hinzufügen , das Authentifizierungsversuche abfängt und die Kombinationen aus Benutzername und Passwort an ihn weiterleitet.
Shadur

2

Sie können diese Dateien nicht einfach umbenennen. Viele Prozesse und Programme werden nach ihnen suchen, da dies ein Standard in Linux-Systemen ist. Was Sie tun können, ist, Ihren Server auf die richtige Weise zu sichern.


Ich wollte nur mehr Sicherheit hinzufügen, ich habe mehr als eine Website auf meinem Server.
Marco Caggiano

2

Während es wahrscheinlich keinen Sinn macht, die /etc/passwdund /etc/shadow-Dateien umzubenennen , sollten Sie sich, wenn Sie zusätzliche Sicherheit wünschen, PAM (steckbare Authentifizierungsmodule) und NSS (Name Service Switch) ansehen. Wie hier.

Mit PAM können Authentifizierungsmodule hinzugefügt werden, die ihre Authentifizierungsinformationen nicht aus den Standarddateien, sondern aus einer anderen Quelle wie ldap oder einer Datenbank lesen. Die Verwendung würde bedeuten, dass die /etc/shadowDose fast vollständig beseitigt werden kann.

NSS ergänzt PAM, indem ein Teil der Namensauflösung (z. B. zu welchen Gruppen dieser Benutzer gehört) von den Standarddateien ( /etc/passwd, /etc/groups) unabhängig gemacht wird . Die Verwendung würde bedeuten, dass Ihre passwd-Datei möglicherweise nur eine Fallback-Option für root enthält und nicht mehr. Die Verwendung von SSH-Schlüsseln zur Überprüfung der Root-Anmeldung würde auch die Notwendigkeit beseitigen, ein Root-Passwort in der Schattendatei zu haben (obwohl dies möglicherweise erwünscht ist, wenn die SSH-Verbindung unterbrochen wird).

Wenn Sie Ihre Benutzer nicht über eine separate Datenbank oder einen separaten LDAP-Host authentifizieren möchten, können Sie alternativ auch eigene PAM- und NSS-Module erstellen, die ihre Daten aus einer nicht standardmäßigen Datei lesen, obwohl ich diese Option nicht empfehlen würde.

Wenn Sie versuchen möchten, sie zu verwenden, vergessen Sie niemals, eine Art Fallback auf eine bekannte, funktionierende Authentifizierungsschicht beizubehalten, da Sie sich sonst selbst mit root vom System ausschließen können.

Beachten Sie, dass nicht alle Anwendungen PAM unterstützen (viele von ihnen jedoch). NSS kann jedoch verwendet werden, um die Authentifizierung für Apps zu implementieren, die PAM nicht unterstützen, und einige Websites, die ich über NSS gelesen habe, schlagen diesen Ansatz tatsächlich vor. Dies bedeutet jedoch, dass das NSS-Modul jedem, der auf die NSS-Authentifizierungsschicht zugreifen kann, das (möglicherweise) gehashte Kennwort zur Verfügung stellt. Dies ist fast immer etwas, das Sie vermeiden möchten (im Grunde ist es dasselbe, als würden Sie der Shadow-Datei einen Lesezugriff ohne Rootberechtigung gewähren )! Wenn Sie diesen Ansatz wählen, stellen Sie immer sicher, dass NSS nur verwendet wird, um dem Benutzer die Basisdaten (wie den Inhalt von /etc/passwd) bereitzustellen , und PAM als Authentifizierungsschicht verwendet wird.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.