Reales SELinux-Sicherheitsbeispiel?

11

Kann jemand ein Beispiel aus dem wirklichen Leben geben, wo SELinux seinen Sicherheitsspeck aufbewahrt hat? (oder AppArmour, wenn Sie möchten). Wenn nicht Ihre eigene, ein Hinweis auf jemanden mit einer glaubwürdigen Erfahrung?

Kein Labortest, kein Whitepaper, keine Best Practice, kein CERT-Hinweis, sondern ein echtes Beispiel, so etwas wie audit2warum zeigt sich ein echter Hacking-Versuch, der in seinen Spuren gestoppt wurde?

(Wenn Sie kein Beispiel haben, behalten Sie bitte Kommentare in Kommentaren anstelle von Antworten bei.)

Vielen Dank!

linux security selinux

— kmarsh
quelle

Diese Frage enthält eine Bedingung, die schwer zu beantworten ist. Das Problem ist, dass Systeme, die nicht kompromittiert werden, keine Nachrichten machen. Sie machen die Nachrichten nur, wenn sie kompromittiert werden. Daher gibt es Neuigkeiten über viele kompromittierte CentOS-Systeme, die genau deshalb kompromittiert wurden, weil ihre Administratoren SELinux deaktiviert haben, weil sie nicht lernen möchten, wie man es konfiguriert und wartet. Wenn sie SELinux nicht deaktiviert hätten, wären sie nicht kompromittiert worden.

— Juliano

Danke, aber ich habe nicht nach Neuigkeiten gesucht, sondern nach tatsächlichen persönlichen Erfahrungen.

— kmarsh

5

Wie wäre es damit von Russell Coker ? Es ist ein Beispiel aus dem wirklichen Leben, da er jeden als Root auf seine Maschine eingeladen hat. Auf den ersten Blick dachte ich, das wäre verrückt, aber dann erkennt man die Kraft von SELinux, die Wurzel etwas nutzlos zu machen.

Hier sind einige Beispiele aus seiner Praxis.

— Keithosu
quelle

1

Interessant. Im ersten Link gibt er Root-Zugriff weg, aber (ich denke) sperrt mit SELinux fast alles, was Root normalerweise tun kann. Während dies ein echter Computer ist, qualifiziert er sich nur so für das wirkliche Leben wie eine Reality-TV-Show. Wie viele SysAdmins würden auf diese Weise eine Maschine einrichten? Der zweite Link ist mehr, wonach ich suche. Ich werde sie mir ansehen. Vielen Dank!

— kmarsh

4

Bei SELinux geht es nicht unbedingt um den Schutz vor Hackern. Es geht darum, Richtlinien für das Verhalten eines Systems zu dokumentieren und durchzusetzen. Es ist ein Werkzeug in der Toolbox, das wertvoll ist, aber Fähigkeiten erfordert, um es gut zu nutzen.

Ein Beispiel aus dem wirklichen Leben, wie es Sie rettet, ist ungefähr so:

Eine Sicherheitsanfälligkeit in einem FTP-Daemon ermöglicht es einem anonymen Benutzer, Root-Rechte zu erlangen. Ein Angreifer nutzt diese Sicherheitsanfälligkeit, um auf Benutzerverzeichnisse zuzugreifen und private SSH-Schlüssel zu stehlen, von denen einige keine Passphrase haben.

Wenn SELinux so konfiguriert ist, dass die Richtlinie "FTP-Dienste dürfen Dateien in Benutzerverzeichnissen lesen und schreiben" nicht zulässig ist, ist der Exploit nicht erfolgreich und der Richtlinienverstoß wird protokolliert.

— duffbeer703
quelle

2

Das ist kein Beispiel aus dem wirklichen Leben, es ist ein Beispiel dafür, wie ein Beispiel aus dem wirklichen Leben aussehen könnte. Es ist ein hypothetisches Beispiel aus dem wirklichen Leben. Was das OP nicht verlangt hat.

— Jürgen A. Erhard

3

Hier finden Sie eine detaillierte Beschreibung eines Angriffs, den SELinux gestoppt hat, mit Protokolldetails und einer Erläuterung der verwendeten forensischen Techniken. Ich habe diesen Artikel im Linux Journal veröffentlicht:

http://www.linuxjournal.com/article/9176

Hier ist ein Auszug von Anfang an:

Wenn Sie mit dem Internet verbundene Server betreiben, müssen Sie möglicherweise irgendwann mit einem erfolgreichen Angriff fertig werden. Letztes Jahr stellte ich fest, dass es einem Angreifer trotz der auf einem Testwebserver (Targetbox) vorhandenen mehrschichtigen Verteidigung gelungen war, einen Exploit bei einem teilweise erfolgreichen Versuch zu verwenden, Zugriff zu erhalten. Auf diesem Server wurden Red Hat Enterprise Linux 4 (RHEL 4) und das Mambo-Content-Management-System ausgeführt. Es gab mehrere Schutzmechanismen, einschließlich Security-Enhanced Linux (SELinux). SELinux verhinderte, dass der Angreifer die zweite Stufe des Angriffs ausführte, und verhinderte möglicherweise einen Root-Kompromiss.

In diesem Artikel wird eine Fallstudie zur Reaktion auf das Eindringen vorgestellt, in der erläutert wird, wie ich das Eindringen entdeckt habe, welche Schritte ich unternommen habe, um den Exploit zu identifizieren, wie ich mich von dem Angriff erholt habe und welche Lehren ich aus der Systemsicherheit gezogen habe. Ich habe Computernamen und IP-Adressen aus Datenschutzgründen geändert.

— obscurerichard
quelle