Warum kann der Root-Benutzer die Protokolle löschen?

Weil Sie den Server verwalten müssen müssen.

Was hindert einen Hacker mit Root-Zugriff daran, die Protokolle zu löschen, um ihre Spuren zu verwischen?

In Bezug auf die lokale Protokollierung nur seine eigene Dummheit. In Bezug auf die externe Protokollierung, ihre und Ihre Fähigkeiten.

Es gibt viele, viele verschiedene Möglichkeiten zum "Protokollieren". Tatsächlich könnte das verwurzelte Computerprotokoll auf einem separaten, versteckten Gerät gespeichert werden, das nicht einfach überschrieben werden kann, z. B. einem Himbeer-Pi / Arduino-Logger, von dem ich einige habe.

Unter Linux root soll so ziemlich alles können. In Windows gilt das gleiche Konzept. Wenn Sie Root-Zugriff auf einen Computer haben, können Sie fast alles tun, was Sie möchten, einschließlich des Löschens von Protokollen.

Sie können auch alle Verbindungen zu einem bestimmten Computer protokollieren, insbesondere wenn dies nicht der Fall ist Es soll überhaupt nicht "zugegriffen" werden.

Wie würden Sie herausfinden, was los ist, und wie würden Sie es umgehen?

So finden Sie alle Änderungen in den letzten 120 Minuten:

  find / -mmin -120 -printf '% p \ t% a \ n'  

Schön, oder? Gotcha, Hacker! Mwahahaha ... aber Sie können diese Attribute ändern, wenn Sie wissen, was Sie tun, wie folgt:

  touch -d "vor 24 Stunden" <file>  

Schlimmer noch, automatisieren Sie es:

  find / -print | beim Lesen der Datei; Berühren Sie -d "$ (Datum -r" $ Datei ") - 24 Stunden" "$ Datei" erledigt  

Aber warten Sie, Mark Hulkalo! Wenn alle Dateien vor 24 Stunden zuletzt bearbeitet wurden, zeigt dies deutlich, dass wir einen Haxor haben! Richtig, aber Sie können auch $ RANDOM anwenden, wenn 24 vorhanden ist. Hier ist ein Beispiel für eine Zahl von 1-24: $ ((RANDOM% 10) + 1) . Jetzt sieht es nicht so einfach aus, es zu entdecken, oder?

Aber was ist, wenn alle Dateien so aussehen, insbesondere Dateien, die nicht geändert werden sollen? Beschränken Sie den Bereich auf ein bestimmtes Verzeichnis, z. B. / root . Es gibt viele Möglichkeiten, Ihre Anwesenheit lokal zu maskieren.

Wenn der Angreifer nicht vergessen hat, ~ / .bash_history zu bereinigen, fliegen Sie blind. Wirklich, wenn die einzige "Protokollierung", die Sie haben, ~ / .bash_history ist, dann sind Sie in Schwierigkeiten, wenn Ihr Angreifer zumindest mäßig intelligent ist. Dies kann auf jedem Benutzerkonto mit erstaunlicher Leichtigkeit gelöscht werden, solange Sie über die entsprechenden Berechtigungen verfügen.

Es ist viel einfacher, Einträge an einem Ort zu protokollieren, an dem sie nicht leicht erkannt oder geändert werden können, z. B. an einem externen Gerät. Während es möglich ist, mithilfe der Forensik die Fußabdrücke Ihres Angreifers wiederherzustellen, ist es sehr, sehr einfach zu umgehen, wenn Sie wissen, was Sie tun. Aus diesem Grund ist die externe Protokollierung eine viel bessere Lösung.

Und das ist die Geschichte, warum die externe Protokollierung im Allgemeinen die Antwort ist. Beachten Sie, dass es auch Möglichkeiten gibt, die externe Protokollierung zu umgehen. Nichts ist jemals 100% sicher; Sie können es Ihrem Angreifer nur schwerer machen, nicht unmöglich.

Warum kann der Root-Benutzer die Protokolle löschen?

Da jemand in der Lage sein muss, Änderungen am System vorzunehmen, dh Protokolldateien zu drehen, Protokolldateien zu entfernen usw. In UNIX root ist traditionell dieser voll privilegierte Benutzer. Tatsächlich gibt es keinen großen Unterschied zwischen dem Ändern eines Protokolls und dem Ersetzen einer Binärdatei, um die Protokollierung zu unterlassen - und root kann standardmäßig beides.

Was verhindert, dass ein Hacker mit Root-Zugriff die Anmeldungen löscht?

Die Standardkonfiguration stoppt den Angreifer normalerweise überhaupt nicht. Eine naheliegende Möglichkeit, dies zu verbessern, besteht darin, sich bei einem Remote-Protokollserver anzumelden, der so geschützt ist, dass der Angreifer ihn hat Kein Zugriff (im einfachsten Fall: keine Remote-Anmeldung möglich).

Abgesehen von FreeBSD haben OpenBSD und wahrscheinlich auch andere die Idee, unveränderliche oder nur anhängbare Dateien zu erstellen. Mit chflags können Sie Protokolldateien auf diese Weise markieren. Dann sind nur Anhänge möglich und die Datei kann nicht gelöscht werden. Wenn Sie diese Funktion mit Sicherheitsstufe kombinieren, können Sie Protokolldateien erstellen, die nur im Einzelbenutzermodus geändert (entfernt, gedreht) werden können.

Sie können auch alternative oder erweiterte Sicherheitsmechanismen wie SELinux verwenden, um sicherzustellen, dass die "normaler" Root-Benutzer kann Dateien nicht ändern.

Wenn auf dem Server der Root-Benutzer kompromittiert wurde, kann dieser Benutzer auf jeden Fall alle Dateien (einschließlich Protokolle) auf den Systemen löschen. In den meisten Unternehmen werden Protokolle jedoch nicht lokal gespeichert.

Wenn Protokolle lokal gespeichert und gelöscht werden, kann zur Ermittlung des Ausmaßes des Verstoßes eine forensische Analyse durchgeführt werden, um die Dateien wiederherzustellen.

Die meisten Unternehmenswebserver und Unternehmensumgebungen verwenden jedoch eine Art Protokollverwaltung. Dies kann von Standardtools wie Syslog und SNMP bis hin zu proprietärer Protokollverwaltungssoftware wie Splunk reichen.

Wann Wenn diese Systeme verwendet werden, müsste der Angreifer das Protokollverwaltungssystem und alle Sicherungen davon gefährden, um die Protokolle zu löschen und ihre Spuren zu verwischen.

So sicher, man kann als Root Dateien löschen; Dies ist jedoch keine bestimmte Art, die eigenen Spuren zu verwischen.

Da WORM-Geräte (einmal schreiben, viele lesen) immer noch selten sind. In Systemen, in denen Sicherheit und Forensik sehr wichtig sind, werden diese Geräte zum Aufzeichnen von Protokollen in Echtzeit verwendet, jedoch nicht gelöscht, auch von root. Um dies sicher implementieren zu können, muss es sich um eine Hardwarebeschränkung handeln. Weniger sicher könnte es sein, dass eine API einem Softwaredienst ausgesetzt wird, der nur Operationen zum Schreiben neuer und Lesen alter Dateien ausführt. Wenn der Server auch über ein Hardwaregerät oder einen Hypervisor verfügt, der grundsätzlich jede Änderung am System protokolliert, ist es sehr schwierig, Ihre Spuren zu verbergen.

Für die wirklich Paranoiden etwas in der Art von:

  tail -f /var/log/auth.log > / dev / lp0  

... würde wahrscheinlich alle außer denen aufhalten, die sich zur Brandstiftung beugen würden.

Peitsche die Oki-Bänder aus!

Weil JEMAND in der Lage sein muss, Protokolldateien zu verwalten, und wenn nicht root, wer dann? Möchten Sie wirklich ein System, bei dem eine Protokolldatei, die beispielsweise 90% Ihres Speicherplatzes einnimmt, absolut nicht gelöscht werden kann?

Sicher, dies ist eine Sicherheitslücke. In dem gleichen Sinne, dass ein System, mit dem jeder Benutzer etwas tun kann, eine Sicherheitslücke schafft. Die meisten Türschlösser sind so konzipiert, dass das Schloss nur von jemandem entfernt werden kann, der sich im Haus befindet. Dies bedeutet jedoch, dass jeder, der in Ihr Haus gelangen kann, z. B. ein Gast oder ein Klempner, Ihr Türschloss durch ein Schloss ersetzen kann, für das nur er den Schlüssel hat. Ist das eine Sicherheitslücke? Sicher. Aber was ist die Alternative? Machen Sie es so, dass niemand das Schloss ersetzen kann? Was ist, wenn die Sperre aufbricht?

Im wirklichen Leben ist es kein einfaches Entweder / Oder: "Unsichere Systeme", in die jeder einsteigen und etwas tun kann, im Gegensatz zu "sicheren Systemen", bei denen wir uns zu 100% sicher sind Nur autorisierte Benutzer können autorisierte Dinge tun. Es gibt eine Reihe von "Sicherheit". Je sicherer Sie ein System erstellen, desto unpraktischer wird es für autorisierte Benutzer häufig, ihre Arbeit zu erledigen. Irgendwann ist die Sicherheit so hoch, dass das System praktisch unbrauchbar wird.

Ich habe dies in Kommentaren gesagt, aber es scheint, dass es eine vollständige Antwort verdient.

Wenn Sie SELinux verwenden, können Sie es so konfigurieren, dass root keine Protokolldateien löschen kann. SELinux verwendet die obligatorische Zugriffssteuerung (Steuerung basierend auf Rollen), um zu bestimmen, welche Rollen jede Datei lesen / schreiben / ausführen können, zusätzlich zur diskretionären Zugriffssteuerung von Linux, die angibt, was Jeder Benutzer / jede Gruppe / jeder kann eine Datei bearbeiten - die typischen rwxrwxrwx-Berechtigungen.

Es scheint Verwirrung darüber zu geben, wie SELinux verwendet werden könnte, um dies zu erreichen, aber es ist ziemlich einfach. Ein möglicher Punkt der Verwirrung ist die Idee eines Linux-Benutzers und einer SELinux-Rolle . Für Linux-Benutzer ändert sich nichts. SELinux fügt nur das hinzu, was Linux bereits hat. Sie würden Ihre Benutzer also wie gewohnt einrichten. root wäre wie immer dasselbe.

Dann müssen Sie SELinux-Rollen einführen. Linux-Benutzern können viele SELinux-Rollen zugewiesen werden, und die Rollen eines Benutzers bestimmen, was er auf dem System tun kann. Jetzt hat die Standard-SELinux-Richtlinie - meiner Meinung nach "gezielt" - einen uneingeschränkten Benutzer, der einem Superuser entspricht. Standardmäßig wird root als unbeschränkt zugewiesen, sodass root alles ohne SELinux ausführen kann. Ich kann mir vorstellen, dass die meisten Leute die Standardrichtlinie oder die Standardrollen in SELinux nicht ändern, sodass der Eindruck entsteht, dass root alles tun kann, was es will.

Dies ist jedoch nicht notwendig . Wenn Sie die SELinux-Rolle von root entfernen, kann sie nichts tun (Sie können sich nicht einmal anmelden). Zuvor möchten Sie jedoch einen Benutzer mit der Rolle der Verwaltung von SELinux einrichten. Sowohl "gezielte" als auch "mls" -Richtlinien sind mit solchen Verwaltungsrollen ausgestattet, aber ich vergesse, wie es genau heißt. Normalerweise geben Sie dies einem Ihrer Systemadministratoren, damit dieser bei Bedarf die SELinux-Richtlinien, -Rollen usw. ändern kann.

Ihre Frage betrifft den gesamten Punkt von SELinux und seinem obligatorischen Zugangssystem. Die Leute erkannten, dass das Erhalten von Wurzeln Hackern viel zu viel gibt. Sie können Ihr SSH, Ihr HTTP und alles andere vermasseln, was sie wollen. Mit SELinux können Sie jedoch den Root-Zugriff einschränken oder entfernen. Selbst wenn sich jemand bei root anmeldet, kann er Ihr System nicht einfach zerstören. Hinweis: Dies gilt nicht nur für Protokolldateien. Dies gilt für alles im System. Das Erhalten von root wird sehr schnell bedeutungslos, wenn Sie SELinux richtig konfigurieren.

Und um klar zu sein, muss ein Benutzer irgendwann in der Lage sein, die Protokolldateien zu löschen. Das Ziel ist nicht, das Löschen von Protokolldateien unmöglich zu machen, sondern es ist für root unmöglich, alle Protokolldateien zu löschen. Wenn jemand / etwas im System eine Protokolldatei erstellen kann, kann er diese Protokolldatei auch löschen , es sei denn, Sie verwenden eine Art einmaligen Schreibspeicher wie andere haben erwähnt.

Dann verschiebt sich die Frage ein wenig: Ein Hacker kompromittiert Ihren Webdienst und kann anschließend die damit verbundenen Protokolle löschen, oder? Und genau darum geht es uns wirklich, denn das ist das Protokoll, das ihre Aktionen verfolgt. Wenn sie das noch ändern können, worum geht es dann bei diesem ganzen Zirkusakt? Nun, die Antwort ist, dass sie möglicherweise in der Lage sind, die Protokolldateien zu löschen / zu ändern, je nachdem, in welchem ​​Kontext sie ausgeführt werden, nachdem sie das System ausgenutzt haben, und ob dieser Kontext die Berechtigung hat, die zu ändern relevante Protokolldateien. Aber das ist ein Kaninchenbau an sich und diese Antwort ist so wie sie ist lang genug. Trotzdem zeichnet SELinux sowieso Systemanrufe auf, und der Hacker, der Ihren Webdienst kompromittiert hat, kann SELinux-Protokolle nicht ändern (es handelt sich um zwei separate Kontexte / Rollen im System), sodass Sie zumindest über diese verfügen.

Standardmäßig hindert nichts einen Angreifer daran, die Protokolle zu löschen, um ihre Spuren zu verwischen. Wenn jedoch ein Angreifer die Protokolle löscht, ist es offensichtlich, dass etwas passiert ist. Aus Sicht eines Angreifers ist es intelligenter, die Protokolle so zu ändern, dass nur seine Spuren gelöscht werden.

Andererseits können Sie einige Maßnahmen zum Schutz der Protokolle implementieren, z. B. sie in Echtzeit senden Zeit zu einem externen Server.