Bevor wir uns im nächsten Beitrag mit der Installation, sicheren Konfiguration und Härtung eines Nginx-Servers befassen, möchte ich im Folgenden noch etwas Grundlagenarbeit erörtern: Die Funktionsweise der Trusted Path Execution unter Linux.
Die Trusted Path Execution sind als Teil des Grsecurity Patches während der Konfiguration optional aktivierbar.
Die Ausführung von schädlichem Code auf einem Linux System, entweder durch einen externen Angreifer oder (un)gewollt durch einen lokalen Nutzer, ist eine der größten IT-Sicherheitsbedrohungen der heutigen Tage. Um diese Gefahr zu vermindern, ist Trusted Path Execution (TPE) ein weiterer Sicherheits-Layer, der die Ausführbarkeit von Dateien unter bestimmten Umständen einschränkt.
Die Nutzung von TPE erschwert beispielsweise den Versuch einer Privilege Escalation deutlich - wenn der Account mithilfe von TPE geschützt wird, ist es einem Angreifer nicht möglich, benutzerdefinierte Dateien auszuführen, die nicht in einem vertrauenswürdigem Pfad liegen. Im Rahmen vieler Angriffe versuchen Angreifer oftmals, nach dem Einbruch in das System Code nachzuladen und auszuführen, beispielsweise um eine lokale Sicherheitslücke auszunutzen.
Einen eigenen, sicheren Linux Kernel mit PaX und Grsecurity zu kompilieren hat eine Menge Vorteile, insbesondere bei öffentlich erreichbaren Servern. Ich kann jedem nur empfehlen, seinen Computer mit diesen beiden Kernel-Patchsammlungen zu härten.
In der IT-Sicherheit gibt es das Prinzip, optimiert-minimalistisch vorzugehen. Minimalistisch bedeutet, dass die Anzahl der Services, Anwendungen und Dateien auf einem Server und auf dem Netzwerkpfad auf dem Weg dorthin quantitativ möglichst gering gehalten werden sollte. Jedes Netzwerkgerät, jede Firewall, jeder Virenscanner und jedes Intrusion Detection System das sich in einem Netzwerk oder auf einem Computer befindet, kann prinzipiell Schwachstellen enthalten und angreifbar sein.
Optimiert vorzugehen bedeutet, das die notwendigen Tools hochsicher konfiguriert worden, in einer sicheren Umgebung kontrolliert laufen und, wenn möglich, gehärtet worden sind.
Zusammenfassung: Viele Tools zur Absicherung sind oftmals unsicherer als wenige, hoch optimierte und gehärtete Komponenten!
Auf jedem Linux Server ist ein Linux-Kernel vorhanden, es handelt sich daher um eine notwendige Komponente, die es im Folgenden zu härten gilt.
Was ist ein Kernel?
Der Kernel ist der "essentielle Kern" eines jeden Betriebssystems. Es ist der "unterste Teil" des Betriebssystems, der jedoch mit den höchsten Rechten läuft. Sollte dieses Grundwissen über den Kernel nicht vorhanden sein, empfehle ich jedem, sich vor einer Härtung mit PaX & Co. ein grundlegendes Wissen zu der Thematik anzueignen. Ein falsch konfigurierter, selbst kompilierter, gehärteter Kernel kann anfälliger sein, als der Kernel der Distribution!
Was ist PaX?
PaX beinhaltet eine Reihe von Patches, die für den Linux Kernel entwickelt worden sind. Die Patches bieten eine Reihe Vorteile, neue Funktionalitäten und einige Verbesserung vorhandener Kernel-Features. Als Schutz vor Exploits bietet PaX beispielsweise eine verbesserte ASLR (Address Space Layout Randomization).
Was ist Grsecurity?
Grsecurity sind weitere Patches für den Linux Kernel. PaX und Grsecurity wurden für eine Zusammenarbeit entwickelt und bedingen einander. Die Hauptfeatures von Grsecurity sind:
Ein RBAC-System (eine Rollenbasierte Zugriffskontrolle)
Memory Execution Prevention (NX-Bit), Memory Randomization (ASLR) und eine Verhinderung des Ausnutzens von Buffer-Overflows (über die PaX Patches)
Trusted Path Execution.
Zusätzliche chroot (Change Root) Härtung
Randomisierungen (TCP/IP Stack und Prozess-IDs)
Eingeschränkte Sichtbarkeit von Prozessen (z.B. den Kernel Threads)
Die Funktionalitäten lassen sich über Sysctl konfigurieren.
Dieser Beitrag wurde am 14.Dezember 2014 auf die Linux-Kernel-Version 3.14.26 aktualisiert.
Einen eigenen Linux Kernel aus den Quellen zu kompilieren, ist Thema dieses IT Security Blog Beitrags. In einigen Tagen (Update: Beitrag erschienen) werde ich einen weiteren Beitrag veröffentlichen, bei denen ich Möglichkeiten nennen werde, einen "gehärteten" bzw. "gepatchten" Linux Kernel zu kompilieren. Bevor wir uns jedoch mit Themen wie PAX, grSecurtity & Co. auseinander setzen, müssen einige Grundlagen vorhanden sein. Die Quellcodebeispiele werde ich auf Basis eines Debian GNU/Linux Systems (Ubuntu 14.04 LTS) demonstrieren.
Vor- und Nachteile eines eigenen Kernels
Um es vorwegzunehmen - notwendig ist ein eigener Kernel in den meisten Fällen nicht. Mit Hilfe eines eigenen Kernels ist es beispielsweise möglich, diesen exakt an das System anzupassen, daher nur die Module bzw. Treiber zu kompilieren, die auch wirklich für das System benötigt werden. Ein Debian Paket des aktuellen Kernels lässt sich somit auf eine Größe von etwa 6-7 MB reduzieren. Notwendig ist ein selbst kompilierter Kernel beispielsweise auch dann, wenn dieser für mehr Sicherheit, zur Systemhärtung, gepatcht und angepasst werden soll.
Die Konfiguration erfordert etwas Erfahrung, der größte "Nachteil" ist die etwas schwerere Wartbarkeit. Ein Update des selbst kompilierten Kernels aus den Paketquellen der Distribution ist dann nicht mehr ohne weiteres möglich.
Eine Wiederherstellung bzw. Rückkehr zum originalen Kernel der Distribution ist zu jedem Zeitpunkt ohne Probleme möglich.
