© Pakpoom Makpan/Shutterstock.com
Ist Docker womöglich ein Sicherheitsrisiko?

Wie sicher ist Docker?


Eine Webanwendung in einen Docker-Container zu verpacken, hat viele Vorteile. Aber ist das auch sicher? Vielleicht sogar sicherer als bei einer Ausführung direkt auf dem Server? Oder nicht vielleicht doch gefährlicher? Immerhin ist da ja mit Docker eine zusätzliche Komponente im Spiel, mit eigenen Schwachstellen und möglichen Problemen.

Gab es nicht bereits Berichte über mit Schadsoftware infizierte Container? Und Vorträge zu Docker auf den Sicherheitskonferenzen? Beides gab es, und diese Berichte und Vorträge sind auch der Grund für diesen Artikel. Aber bevor ich dazu komme, möchte ich erst eine grundlegende Frage klären: Wie sieht es eigentlich mit der Sicherheit von Docker-Containern im Vergleich zu Sandboxes, virtuellen Maschinen und direkt auf dem Server ausgeführten Programmen aus? Das lässt sich nur beantworten, wenn man zugleich die Ziele der möglichen Angreifer betrachtet. Hier beschränkt auf Webanwendungen, um das Ganze nicht unnötig zu verkomplizieren. Fangen wir mit der Sicherheit von Docker im Vergleich zu anderen Technologien an.

Am sichersten, aber nicht perfekt: die Sandbox

Am sichersten ist die Ausführung möglicherweise bösartigen Codes in einer besonders abgeschotteten Sandbox. Zwei gute Beispiele dafür sind Edge bzw. sein Vorgänger IE und der Adobe Reader, die beide die Folgen eines möglichen Angriffs reduzieren, indem sie die gefährdeten Prozesse in eine Sandbox sperren. Trotzdem gibt es immer wieder Schadsoftware, die, ausgehend von einer Schwachstelle im Browser oder Adobe Reader, das gesamte System kompromittiert.

Die Sandbox erhöht lediglich den Aufwand für den Angreifer. Ohne Sandbox benötigt er zwei Schwachstellen: eine in Browser oder Adobe Reader, um überhaupt Code einzuschleusen, und eine zweite, über die der eingeschleuste Code dann aus der Sandbox ausbricht und sich Systemrechte verschafft. Mit etwas Glück ist das aber so aufwendig, dass der Angreifer aufgibt und sich ein anderes Ziel sucht. Allerdings ist den Cyberkriminellen der Ausbruch aus der Sandbox in der Vergangenheit des Öfteren gelungen. Ironischerweise zum Teil über Schwachstellen, die direkt den Ausbruch aus der Sandbox erlaubten, ohne dass zuvor der Browser oder Reader kompromittiert werden musste. Es ist auch möglich, ganze Programme oder sogar das Betriebssystem in einer Sandbox auszuführen, wobei es sich dabei im Fall von Betriebssystemen schon um speziell gehärtete virtuelle Maschinen handelt.

Keine Schutzmaßnahme im eigentlichen Sinn: virtuelle Maschinen

Virtuelle Maschinen trennen zwar das darin ausgeführte System vom Hostsystem, im Allgemeinen aber nicht, um die Sicherheit zu erhöhen, sondern um mehrere Systeme parallel und unabhängig voneinander auf der gleichen Hardware ausführen zu können. Dass die virtuelle Maschine den Angreifer an der Ausweitung seiner Rechte hindert, ist nur ein angenehmer Nebeneffekt.

Virtuelle Maschinen basieren auf dem Hypervisor-Prinzip. Der Hypervisor ist die abstrahierende Schicht zwischen der Hardware und der virtuellen Maschine (Typ-1-Hypervisor) oder dem Betriebssystem (Host) und der virtuellen Maschine (Typ-2-Hypervisor).

Ein Typ-2-Hypervisor sitzt direkt auf dem vorhandenen Betriebssystem und benutzt dessen Treiber für den Zugriff auf die Hardware. Die Performance und Sicherheit sind dabei etwas geringer als bei einem Type-1-Hypervisor, der direkt auf die Hardware zugreift. Auch der Ausbruch aus virtuellen Maschinen ist möglich und sogar leichter als der aus der gehärteten Sandbox. Entsprechende Schwachstellen werden immer wieder gefunden und behoben. Je nachdem, was der Angreifer erreichen möchte, kann er nach dem Ausbruch entweder das Hostsystem kompromittieren oder auf andere, parallel laufende virtuelle Maschinen zugreifen.

Docker: noch weniger Abschottung als in virtuellen Maschinen

Womit wir zu Docker kommen. Docker-Container sitzen direkt auf dem Betriebssystem des Hosts, ohne einen Hypervisor, der zwischen Betriebssystem und Container liegt. Im Gegensatz zu Prozessen auf virtuellen Maschinen, die nur mit dem Kernel der virtuellen Maschine kommunizieren können, greifen Prozesse in Containern teilweise direkt auf den Hostkernel zu. Und sind damit nur einen Schritt von der Kontrolle über den Host entfernt, während sie bei einem Ausbruch aus einer virtuellen Maschine erst noch deren Kernel überwinden müssen.

Trotzdem ist der Container sicherer als direkt auf der Hardware laufende Software, denn eine gewisse Trennung gibt es ja. Außerdem enthalten die Docker-Container im Allgemeinen nur die wirklich benötigten Komponenten, während reguläre Systeme viele für den jeweiligen Zweck unnötige Programme enthalten. Das reduziert die Angriffsfläche, und das ist immer gut!

Docker war aber auch nie dafür vorgesehen, um darin nicht vertrauenswürdigen Code auszuführen, und das womöglich auch noch mit Root-Rechten. Man könnte Docker zum Beispiel durch SELinux oder AppArmor absichern. Aber auch abgesichert ist ein Container einfach nicht so stark vom Host getrennt wie eine echte virtuelle Maschine. Und selbst die sollte man nicht verwenden, um schädlichen Code auszuführen.

Docker-Container sind keine Sicherheitscontainer!

Docker wurde entwickelt, um Anwendungen in der gleichen Umgebung zu entwickeln, zu testen und auszurollen. Und Ihrem eigenen Code werden Sie ja wohl vertrauen, oder? Wenn nicht, sollten Sie ihn keinesfalls veröffentlichen. Weder als Container noch in einer virtuellen Maschine oder direkt auf der Hardware. Und was die Idee betrifft, verschiedene Anwendungen in verschiedenen Containern parallel zu betreiben, so ist die gar nicht mal so schlecht; zumindest, wenn man es macht, um jeder eine eigene Umgebung bereitzustellen, in der sie ungestört von anderen Anwendungen ist.

Wenn man das aber macht, um Anwendungen aus verschiedenen Vertrauenssphären, zum Beispiel von verschiedenen Kunden, auf einem Server zu betreiben, hat man ein Problem, sobald eine dieser Anwendungen bösartig ist oder kompromittiert wird; jedenfalls dann, wenn der Angreifer auf die Daten anderer Vertrauenssphären zugreifen will, aber dazu komme ich gleich noch. Das gleiche Problem hätte man aber auch, wenn die Anwendungen direkt auf der Hardware laufen würden oder in einer virtuellen Maschine. Im ersten Fall wäre es etwas größer, da der Zugriff sofort möglich ist, im zweiten etwas kleiner, da der Ausbruch aus der virtuellen Maschine schwieriger als der Ausbruch aus einem Container ist.

Wird die Webanwendung direkt auf dem ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang