Best Practices zum Härten von Sudo?

Question

In jeder von mir gelesenen Anleitung zum Härten wird empfohlen, sich nicht beim Root-Konto anzumelden und stattdessen Sudo zu verwenden. Ich kann das verstehen, wenn Sie eine strikte sudoers -Datei festlegen, die nur die erforderlichen Befehle für jede Gruppe und jeden Benutzer aktiviert. Aber auf jedem Server, auf den ich getreten bin, habe ich nur eine nicht einschränkende Sudo Konfiguration gesehen. Ich würde gerne verstehen, ob es sich um eine gute Praxis handelt oder nicht und warum (trotzdem verstehe ich den Grund für die Rückverfolgbarkeit).

Also hier sind meine Fragen:

Reicht es aus, su zu verbieten und Sudo zuzulassen, um die Rückverfolgbarkeit der Administratoraktionen zu gewährleisten? (Ich kann mir ein Szenario vorstellen, in dem ein Benutzer viele Sudo-Aktionen ausführt, bevor er seine bash_history löscht.)
Gibt es neben .bash_history eine andere Quelle, die nützlich ist, um die Rückverfolgbarkeit zu gewährleisten? Kann eine solche Datei von einem Administrator (mit Sudo) aktualisiert werden?
Ist es möglich, Sudo -i und Sudo -s in der Konfiguration?
Kann Sudo command Dienstprogramm ohne starke sudoers Konfiguration haben? Wenn ja, welche?

Darüber hinaus sehe ich für einen einzelnen Benutzer nur Vorteile darin, Sudo zu verbieten und su zu aktivieren. In der Tat scheint es eine schlechte Praxis zu sein, sich mit root und normalem Benutzer anzumelden, die dasselbe Passwort verwenden.

Bryan Field · Accepted Answer

Ihre Frage ist ziemlich weit gefasst und berührt verschiedene Themen. Es ist möglicherweise besser, einige Details in eine separate Frage zu stellen.

Reicht es aus, su zu verbieten und Sudo zuzulassen, um die Rückverfolgbarkeit der Administratoraktionen zu gewährleisten?

... kann der Sudo-Befehl ein Dienstprogramm ohne eine starke Sudoer-Konfiguration haben? welche ?

Uneingeschränkt Sudo hat einige Vorteile gegenüber su.

Jeder sudoer kann sein persönliches Passwort verwenden. Auf diese Weise müssen Sie das Root-Passwort nicht erneut verteilen, wenn es geändert wird.
Sudo kann so konfiguriert werden, dass Aktivitäten protokolliert werden. Wenn Ihre syslog -Konfiguration an einen Remotestandort schreibt, wird es für jemanden schwierig, ihre Spuren zu verwischen.

Der uneingeschränkte root Zugriff ist jedoch weiterhin "uneingeschränkt".

Wenn Sie keinen Remote-Server syslog verwenden, können Tracks problemlos abgedeckt werden.
Der Einfachheit halber verwenden die Leute häufig Sudo -s, Um eine interaktive Shell zu erhalten. Auf diese Weise können Sie die automatische Vervollständigung von bash für eingeschränkte Verzeichnisse erhalten. Leider sind die Vorteile von syslog ungültig, wenn eine Person Sudo -s Ausführen darf. Es gibt auch viele Alternativen zu Sudo -s, Mit denen Befehle ohne spezifische Protokollierung ausgeführt werden können.

(Ich kann mir ein Szenario vorstellen, in dem ein Benutzer viele Sudo-Aktionen ausführt, bevor er seine bash_history löscht.)

bash_history Darf nicht als Verlaufsverfolgungstool verwendet werden. Dies dient nur der Benutzerfreundlichkeit.

Gibt es neben .bash_history eine andere Quelle, die nützlich ist, um die Rückverfolgbarkeit zu gewährleisten? Kann eine solche Datei von einem Administrator (mit Sudo) aktualisiert werden?

Alle Dateien auf dem Server können von einer Person mit uneingeschränktem root Zugriff aktualisiert werden. (ob über Sudo oder su)

Das Verfolgen der Aktivität eines root - Benutzers kann Gegenstand einer anderen Frage sein. Ich glaube, dass erweiterte Konfigurationen von SELinux dies können, aber es ist wahrscheinlich nicht praktisch. Ich kenne keine andere Möglichkeit, die Aktivität eines root - Benutzers zu verfolgen.

Wie gesagt, wenn Sie eine Protokollierung haben, die auf einen Remote-Protokollserver geschrieben werden muss, um zu verhindern, dass diese vom Angreifer gelöscht werden.

ist es möglich, Sudo -i und Sudo -s in der Konfiguration einzuschränken?

Um Ihnen wörtlich zu antworten, ist dies möglicherweise möglich, geht jedoch über den Rahmen dieses Beitrags hinaus. Erwägen Sie, eine neue Frage zu erstellen.

Dies wird Ihr Problem jedoch nicht lösen. Zum Beispiel könnte man Sudo su Anstelle von Sudo -s Verwenden. Man könnte Sudo sudoers Verwenden oder die crontab usw. aktualisieren.

Die einzige Möglichkeit, dies zu lösen, besteht darin, die Fähigkeiten von Sudo mithilfe einer Whitelist einzuschränken. Wie Sie sagten, ist dies bei weitem nicht so häufig, aber sicherlich der einzige Weg, um das Ziel einer zuverlässigen Rückverfolgbarkeit mit jedem Detaillierungsgrad zu erreichen.

Hoffe das hilft. Fühlen Sie sich frei, meine Antwort zu klären oder eine spezifischere Frage zu stellen, wenn Sie neue Fragen haben, die auf dem basieren, was Sie bisher gelernt haben.

Dmitry Grigoryev · Answer

Wenn ich Ihren letzten Satz anspreche, mache ich tatsächlich etwas in diesem Sinne auf meinem SSH-Server. Ich habe dort zwei Benutzer: ssh_user Und Sudo_user. Nur ssh_user Darf sich anmelden, aber er ist kein Sudoer und muss einen su Sudo_user - Befehl ausgeben, um die Dinge zu erledigen. Dies bietet eine zusätzliche Verteidigungslinie: Selbst wenn der Angreifer Anmeldeinformationen von ssh_user Erhält (z. B. durch Diebstahl meiner PuTTY-Konfigurationsdateien), erhält er nicht sofort Zugriff auf Sudo oder /etc/shadow auf dem Server und muss das Passwort von Sudo_user brutal erzwingen oder einen Exploit auf dem System ausführen, um Root-Zugriff zu erhalten.

Sobald der Angreifer Zugriff auf das Konto ssh_user Hat, ist der Server natürlich gefährdet, aber ich erwarte, dass dieser Trick mir etwas mehr Zeit gibt, um zu reagieren, bevor der eigentliche Schaden angerichtet wird.

ilkkachu · Answer

Was das betrifft:

Die Anmeldung mit root und normalem Benutzer mit demselben Kennwort scheint eine schlechte Praxis zu sein.

Sudo kann so konfiguriert werden, dass anstelle des Kennworts des laufenden Benutzers nach dem Kennwort des "Zielbenutzers" oder nach einem Root-Kennwort gefragt wird. Für einen einzelnen Benutzer können Sie also unterschiedliche nichtprivilegierte und Administratorkennwörter haben. Für mehrere Administratoren, die alle unterschiedliche Kennwörter für den unprivilegierten Zugriff und den Administratorzugriff haben sollten, ist dies schwieriger und wahrscheinlich am einfachsten, wenn zusätzliche Benutzer mit der UID 0 erstellt werden.

Von sudoers (5) :

[Sudo] überprüft die Anmeldeinformationen des aufrufenden Benutzers, nicht die Anmeldeinformationen des Zielbenutzers (oder des Stamms). Dies kann über die später beschriebenen Flags rootpw, targetpw und runaspw geändert werden.