Einen ganzen Linux-Server der Quellcodeverwaltung unterstellen (git)

Ich denke darüber nach, meinen gesamten Linux-Server mit git unter Versionskontrolle zu stellen. Der Grund dafür ist, dass dies möglicherweise der einfachste Weg ist, böswillige Änderungen / Rootkits zu erkennen. Alles, was ich naiv für notwendig halte, um die Integrität des Systems zu überprüfen: Mounten Sie die Linux-Partition jede Woche oder so mit einem Rettungssystem, überprüfen Sie, ob das Git-Repository noch nicht gealtert ist, und geben Sie dann einen Git-Status aus, um Änderungen am System zu erkennen .

Gibt es außer der offensichtlichen Verschwendung von Speicherplatz noch andere negative Nebenwirkungen?

Ist es eine total verrückte Idee?

Ist es überhaupt eine sichere Möglichkeit, nach Rootkits zu suchen, da ich / dev und / proc höchstwahrscheinlich zumindest ausschließen müsste?

Das ist eine "schlechte Idee". Abgesehen von allem anderen wird Ihr Repository so langsam wie möglich und schlimmer, wenn jede Revision beibehalten wird.

Versuchen Sie es mit einer zentralen Verwaltung, wie Marionette / Cfengine / Koch. So bleiben die Dinge wie erwartet und unerwartete Änderungen werden rückgängig gemacht.

Kombinieren Sie dies mit etwas wie iwatch, um E-Mails mit nicht autorisierten Dateiänderungen zu erhalten.

Kombinieren Sie dies weiter mit rpm / deb-Dateien, wenn Sie benutzerdefinierte Anwendungen einführen möchten.

Werfen Sie ab und zu so etwas wie Rkhunter oder Chkrootkit für Kicks ein und Sie sollten bereit sein zu gehen.

Job erledigt.

Eine weitere Alternative ist die Einrichtung von tripwire , einer GPL-Software, die alle wichtigen Dateien auf Ihrem System durchsucht und feststellt, welche Änderungen Sie als inakzeptabel definiert haben. Änderungen können so einfach wie mtime über die Inode-Nummer bis hin zu kryptografisch starken Prüfsummen definiert werden.

Es erfordert einige Einstellungen und Anpassungen, wenn Sie nicht jede Nacht eine ganze Reihe von Berichten über geänderte Dateien in /var/run, Änderungen an DHCP-Client-Dateien in /etcund dergleichen erhalten möchten sehr hilfreich.

Die Datenbank der Dateieigenschaften wird mit einem Schlüssel signiert nicht an die Maschine bekannt, die Sie das Vertrauen hilft haben , dass kein Werkzeug in böswilliger Absicht , die Datenbank oder die Stolper Binärdateien verändert hat. Um die vollständige Sicherheit zu gewährleisten, können Sie eine Kopie der tripwire-Tools und -Datenbanken auf ein schreibgeschütztes Medium brennen, das auf dem Server bereitgestellt und zum Überprüfen aller Änderungen seit dem Brennen der Disc verwendet werden kann, wenn eine vollständige forensische Analyse erforderlich ist.

Wenn Sie dies tun, ist es sehr wichtig, dass Tripwire eingerichtet und in Betrieb genommen wird, bevor die Maschine in Betrieb genommen wird. Andernfalls können Sie nicht sicher sein, dass ein böswilliger Benutzer zuvor keine Chance hatte, die Maschine zu infizieren wurde tripwired.

Ich denke nicht, dass dies wahrscheinlich funktioniert, aber als Experiment würde ich gerne sehen, was passiert, wenn Sie dies nur mit dem Ordner / etc tun. Dort werden die meisten Konfigurationsinformationen gespeichert.

@Sirex hat bereits eine sehr gute Antwort geliefert. Wenn Sie jedoch mit Sicherheit noch einen Schritt weiter gehen möchten, ist die beste Möglichkeit, damit umzugehen, die Vorbeugung und dann die Erkennung.

Versuchen Sie, ein System mit / filesystem einzurichten, das schreibgeschützt ist. Mache / tmp zu einem separaten RAM mit der Option noexec, nodev. Damit das System funktioniert, muss / var wirklich nur mit Lese- und Schreibzugriff bereitgestellt werden. Also mounten Sie unter / var eine fs mit rw, noexec, nodev und entfernen Sie die Schreibrechte für / var / tmp (afaik, wird von Daemons selten benötigt und sollte konfigurierbar sein). Verwenden Sie auch einen Sicherheitspatch für Ihren Kernel, um den Zugriff von Benutzern auf Ressourcen weiter einzuschränken, z. B. grsec. Verwenden Sie eine Firewall mit möglichst restriktiven Regeln.

Einige Distributionen bieten eine umfassende Dokumentation zur Systemhärtung. Beispielsweise:

• Debian-Handbuch sichern
• Debian-Wiki härten

Ich halte es für eine gute Idee, die Änderungen zu analysieren, die ein Tool in Ihrem System vornimmt:

1. Installieren Sie ein nacktes Linux in einer VM
2. Initialisiere den Root Git
3. Installieren Sie das zu analysierende Tool
4. Alle in Ihrem System vorgenommenen Änderungen werden angezeigt

... Löschen Sie die VM

Sie müssten jedoch .gitignore wie proc usw. eine Menge Ordner zur Datei hinzufügen .

In Situationen, in denen Sie nur bestimmte Ordner im gesamten Dateisystem unter Versionskontrolle halten möchten, kann der folgende Ansatz funktionieren:

Erstellen Sie zunächst ein Git-Repository auf folgender /Ebene:

$ cd /
# git init

Erstellen Sie dann eine /.gitignoreWhitelist, die nur bestimmte Ordner auflistet, beispielsweise nur die Whitelist /path/to/versioned/config/folder/(basierend auf /programming//a/11018557/320594 ):

/*
!/path/
/path/*
!/path/to/
/path/to/*
!/path/to/versioned/
/path/to/versioned/*
!/path/to/versioned/config/
/path/to/versioned/config/*
!/path/to/versioned/config/folder/
!/.gitignore

Dann erstelle ein erstes Commit:

# git add -A
# git commit -m "Initial commit"

Fügen Sie dann bei Bedarf die zusätzlichen Ordner hinzu, die der Versionskontrolle unterliegen sollen.

PS:

Zusätzlich zu der vorherigen Methode können Sie etckeeper( https://etckeeper.branchable.com/ ) für die Versionierung dieses bestimmten Ordners verwenden, wenn Sie / etc / unter Versionskontrolle behalten müssen, da dieser für diesen Zweck spezialisierter ist ( Es wird zB nach der Installation von Paketen automatisch festgeschrieben.