Linux-Container vs. VMs: Ein Sicherheitsvergleich

Entwickler lieben Container. Sie sind einfach zu bedienen und schnell zu starten. Sie können viele davon auch auf einfacher Hardware ausführen. Der Startaufwand war schon immer ein Fluch der Entwicklung und des Testens, und dieser Aufwand steigt nur mit Microservices-Architekturen. Wenn ein Entwickler ein halbes Dutzend Dienste benötigt, kann er leicht ein oder zwei Tage mit der Einrichtung verschwenden - Hardware konfigurieren, Installationsprogramme ausführen, Inkompatibilitäten bekämpfen.

Bei Containern wird dies auf Minuten oder Sekunden reduziert und kann auf einer Entwicklungsarbeitsstation ausgeführt werden. Die leicht verfügbaren Repositorys nützlicher Container-Images vervielfachen die Entwicklerproduktivität, ähnlich wie Open Source, jedoch ohne die Mühe, einen Build durchzuführen. Betriebsteams haben Container langsamer übernommen. Ein Grund dafür ist, dass viele Anwendungen, die sie unterstützen müssen, noch nicht containerisiert sind. Ein weiterer Grund ist die Zurückhaltung, sich von VMs zu entfernen.

Für Ops war die Umstellung von Bare-Metal auf VMs selbstverständlich. Einzelne VMs sehen aus und können wie einzelne Systeme mit denselben Tools und Prozessen verwaltet werden. Frühe Bedenken hinsichtlich der VM-Sicherheit wurden durch die lange Produktionsgeschichte von VMs in der Mainframe-Welt, durch die Möglichkeit, dieselben Steuerelemente wie für Bare-Metal-Systeme anzuwenden, durch die Unterstützung der Hardwarevirtualisierung und durch die sich entwickelnde Reife der VM-Management-Tools ausgeräumt.

Viele frühe Sicherheitsbedenken waren auf eine Frage zurückzuführen: Waren VMs so sicher wie Bare Metal? Nun werden ähnliche Fragen zu Containern gestellt. Wie sicher sind Container und wie vergleichen sie sich mit VMs? Wenn wir Dienste, die in Containern ausgeführt werden, mit denselben Diensten vergleichen, die als separate Prozesse auf demselben System ausgeführt werden, ist die Containerversion sicherlich sicherer. Die Trennung zwischen Linux-Namespaces und cgroups bietet Barrieren, die zwischen einfachen Prozessen nicht bestehen. Der Vergleich mit VMs ist weniger eindeutig. Schauen wir uns VMs und Container aus Sicherheitsgründen an.

In diesem Artikel werde ich zwei verschiedene Ansätze zum Vergleichen der VM- und Containersicherheit verfolgen. Der erste Ansatz wird struktureller oder theoretischer sein und die jeweiligen Merkmale aus sicherheitstechnischer Sicht betrachten. Dann werde ich eine praktischere Analyse anwenden, indem ich mir anschaue, was bei einem typischen Verstoß passiert und wie sich dies auf Container- und VM-Architekturen auswirken kann.

Strukturansicht

Für den strukturellen Ansatz werde ich die Angriffsfläche beider Systeme vergleichen. Eine Angriffsfläche gibt die Anzahl der Punkte an, an denen ein System angegriffen werden kann. Es ist nicht genau definiert (z. B. als Zahl), aber nützlich für Vergleiche. Für einen Einbrecher hat ein Haus mit 10 Türen eine größere Angriffsfläche als ein Haus mit einer Tür, selbst wenn die Türen identisch sind. Eine Tür könnte unverschlossen bleiben; Ein Schloss ist möglicherweise defekt. Türen an verschiedenen Orten bieten einem Eindringling möglicherweise mehr Privatsphäre und so weiter.

In Computersystemen enthält die Angriffsfläche alles, wo der Angreifer (oder die in seinem Namen handelnde Software) das Zielsystem „berühren“ kann. Netzwerkschnittstellen, Hardwareverbindungen und gemeinsam genutzte Ressourcen sind mögliche Angriffspunkte. Beachten Sie, dass die Angriffsfläche nicht bedeutet, dass eine tatsächliche Sicherheitsanfälligkeit vorliegt. Alle 10 Türen sind möglicherweise absolut sicher. Eine größere Angriffsfläche bedeutet jedoch mehr zu schützende Orte und die größere Wahrscheinlichkeit, dass der Angreifer in mindestens einer eine Schwäche findet.

Die gesamte Angriffsfläche hängt von der Anzahl der verschiedenen Berührungspunkte und deren Komplexität ab. Schauen wir uns ein einfaches Beispiel an. Stellen Sie sich ein altmodisches System vor, das Börsenkurse anbietet. Es hat eine einzige Schnittstelle, eine einfache serielle Leitung. Das Protokoll in dieser Zeile ist ebenfalls einfach: Ein Aktiensymbol mit fester Länge, z. B. fünf Zeichen, wird an den Server gesendet, der mit einem Preisangebot mit fester Länge antwortet, z. B. 10 Zeichen. Es gibt kein Ethernet, TCP / IP, HTTP usw. (Ich habe vor langer Zeit in einer weit entfernten Galaxie an solchen Systemen gearbeitet.)

Die Angriffsfläche dieses Systems ist sehr klein. Der Angreifer kann die elektrischen Eigenschaften der seriellen Leitung manipulieren, falsche Symbole senden, zu viele Daten senden oder das Protokoll auf andere Weise variieren. Zum Schutz des Systems müssten geeignete Kontrollen gegen diese Angriffe durchgeführt werden.

Stellen Sie sich jetzt den gleichen Service vor, aber in einer modernen Architektur. Der Dienst ist im Internet verfügbar und stellt eine RESTful-API bereit. Die elektrische Seite des Angriffs ist verschwunden - alles, was Sie tun müssen, ist, den eigenen Router oder Switch des Angreifers zu braten. Das Protokoll ist jedoch enorm komplexer. Es verfügt über Schichten für IP, TCP, möglicherweise TLS und HTTP, die jeweils die Möglichkeit einer ausnutzbaren Sicherheitsanfälligkeit bieten. Das moderne System hat eine viel größere Angriffsfläche, obwohl es für den Angreifer immer noch wie ein einzelner Schnittstellenpunkt aussieht.

Bare-Metal-Angriffsfläche

Für einen Angreifer, der nicht physisch im Rechenzentrum vorhanden ist, ist die anfängliche Angriffsfläche das Netzwerk im Server. Dies führte zur „Perimeteransicht“ der Sicherheit: Schützen Sie die Einstiegspunkte in das Rechenzentrum und nichts dringt ein. Wenn der Angreifer nicht eindringen kann, spielt es keine Rolle, was zwischen den Systemen im Inneren passiert. Es funktionierte gut, wenn die Perimeter-Schnittstellen einfach waren (denken Sie an DFÜ), aber Schwachstellen bei internen Schnittstellen hervorriefen. Angreifer, die ein Loch im Umkreis gefunden hatten, stellten häufig fest, dass die interne Angriffsfläche der Serverfarm viel größer als die externe war und sie im Inneren erheblichen Schaden anrichten konnten.

Diese interne Angriffsfläche umfasste Netzwerkverbindungen zwischen Servern, aber auch Interaktionen von Prozess zu Prozess innerhalb eines einzelnen Servers. Schlimmer noch, da viele Dienste mit erhöhten Berechtigungen ausgeführt werden ("Root" -Benutzer), würde ein erfolgreicher Einbruch in einen effektiv uneingeschränkten Zugriff auf alles andere auf diesem System bedeuten, ohne nach zusätzlichen Schwachstellen suchen zu müssen. Eine ganze Branche ist mit dem Schutz von Servern aufgewachsen - Firewalls, Antimalware, Intrusion Detection usw. - mit weniger als perfekten Ergebnissen.

Es gibt auch interessante "Seitenkanal" -Angriffe gegen Server. Forscher haben Beispiele für die Verwendung von Stromverbrauch, Rauschen oder elektromagnetischer Strahlung von Computern gezeigt, um Informationen zu extrahieren, manchmal sehr sensible Daten wie kryptografische Schlüssel. Andere Angriffe haben exponierte Schnittstellen wie drahtlose Tastaturprotokolle genutzt. Im Allgemeinen sind diese Angriffe jedoch schwieriger - sie erfordern möglicherweise beispielsweise die Nähe zum Server -, sodass der Hauptweg, „den Draht runter“ zu kommen, häufiger vorkommt.

VM-Angriffsfläche

Wenn VMs wie Bare Metal verwendet werden, ohne dass sich die Architektur der Anwendung unterscheidet (wie dies häufig der Fall ist), teilen sie sich die meisten der gleichen Angriffspunkte. Eine zusätzliche Angriffsfläche ist ein möglicher Fehler im Hypervisor, Betriebssystem oder der Hardware, Ressourcen zwischen VMs ordnungsgemäß zu isolieren, sodass eine VM den Speicher einer anderen VM irgendwie lesen kann. Die Schnittstelle zwischen der VM und dem Hypervisor stellt auch einen Angriffspunkt dar. Wenn eine VM durchbrechen und beliebigen Code im Hypervisor ausführen kann, kann sie auf andere VMs auf demselben System zugreifen. Der Hypervisor selbst stellt einen Angriffspunkt dar, da er Verwaltungsschnittstellen verfügbar macht.

Je nach Art des VM-Systems gibt es zusätzliche Angriffspunkte. VM-Systeme vom Typ 2 verwenden einen Hypervisor, der als Prozess auf einem zugrunde liegenden Host-Betriebssystem ausgeführt wird. Diese Systeme können angegriffen werden, indem das Host-Betriebssystem angegriffen wird. Wenn der Angreifer Code auf dem Hostsystem ausführen kann, kann er möglicherweise Auswirkungen auf den Hypervisor und die VMs haben, insbesondere wenn er als privilegierter Benutzer Zugriff erhalten kann. Das Vorhandensein eines gesamten Betriebssystems, einschließlich Dienstprogrammen, Verwaltungstools und möglicherweise anderer Dienste und Einstiegspunkte (wie SSH), bietet eine Reihe möglicher Angriffspunkte. VM-Systeme vom Typ 1, bei denen der Hypervisor direkt auf der zugrunde liegenden Hardware ausgeführt wird, eliminieren diese Einstiegspunkte und haben daher eine kleinere Angriffsfläche.

Container-Angriffsfläche

Wie bei VMs teilen sich Container die grundlegenden Angriffspunkte für Netzwerkeintritte von Bare-Metal-Systemen. Darüber hinaus sind Containersysteme, die ein vollständig geladenes Host-Betriebssystem verwenden, wie virtuelle Maschinen vom Typ 2 denselben Angriffen ausgesetzt, die gegen die Dienstprogramme und Dienste dieses Host-Betriebssystems verfügbar sind. Wenn der Angreifer Zugriff auf diesen Host erhalten kann, kann er versuchen, auf die laufenden Container zuzugreifen oder diese auf andere Weise zu beeinflussen. Wenn er privilegierten Zugriff ("Root") erhält, kann der Angreifer auf jeden Container zugreifen oder diesen steuern. Ein „minimalistisches“ Betriebssystem (wie Apceras KurmaOS) kann dazu beitragen, diese Angriffsfläche zu reduzieren, kann sie jedoch nicht vollständig beseitigen, da für die Containerverwaltung ein gewisser Zugriff auf das Host-Betriebssystem erforderlich ist.

Die grundlegenden Containertrennungsmechanismen (Namespaces) bieten auch potenzielle Angriffspunkte. Darüber hinaus sind nicht alle Aspekte von Prozessen auf Linux-Systemen mit einem Namespace versehen, sodass einige Elemente von mehreren Containern gemeinsam genutzt werden. Dies sind natürliche Bereiche, die Angreifer untersuchen können. Schließlich ist der Prozess zur Kernel-Schnittstelle (für Systemaufrufe) groß und in jedem Container verfügbar, im Gegensatz zu der viel kleineren Schnittstelle zwischen einer VM und dem Hypervisor. Sicherheitslücken in Systemaufrufen können potenziellen Zugriff auf den Kernel bieten. Ein Beispiel hierfür ist die kürzlich gemeldete Sicherheitsanfälligkeit im Linux-Schlüsselring.

Architektonische Überlegungen

Sowohl für VMs als auch für Container kann die Größe der Angriffsfläche von der Anwendungsarchitektur und der Verwendung der Technologie beeinflusst werden.

Viele ältere VM-Anwendungen behandeln VMs wie Bare Metal. Mit anderen Worten, sie haben ihre Architekturen nicht speziell für VMs oder Sicherheitsmodelle angepasst, die nicht auf Perimetersicherheit basieren. Sie installieren möglicherweise viele Dienste auf derselben VM, führen die Dienste mit Root-Rechten aus und haben nur wenige oder keine Sicherheitskontrollen zwischen den Diensten. Bei der Neuarchitektur dieser Anwendungen (oder beim Ersetzen durch neuere Anwendungen) werden möglicherweise VMs verwendet, um eine Sicherheitstrennung zwischen Funktionseinheiten zu gewährleisten, und nicht nur, um eine größere Anzahl von Maschinen zu verwalten.

Container eignen sich gut für Microservices-Architekturen, bei denen eine große Anzahl (normalerweise) kleiner Services mithilfe standardisierter APIs „aneinandergereiht“ werden. Solche Dienste haben oft eine sehr kurze Lebensdauer, wenn ein containerisierter Dienst bei Bedarf gestartet wird, auf eine Anforderung reagiert und zerstört wird oder wenn Dienste je nach Bedarf schnell hoch- und heruntergefahren werden. Dieses Verwendungsmuster hängt von der schnellen Instanziierung ab, die Container unterstützen. Aus Sicherheitsgründen hat es sowohl Vor- als auch Nachteile.

Die größere Anzahl von Diensten bedeutet eine größere Anzahl von Netzwerkschnittstellen und damit eine größere Angriffsfläche. Es ermöglicht jedoch auch mehr Steuerelemente auf Netzwerkebene. In der Apcera-Plattform muss beispielsweise der gesamte Container-zu-Container-Verkehr explizit zugelassen werden. Ein Rogue-Container kann keinen Netzwerkendpunkt willkürlich erreichen.

Kurze Containerlebensdauer bedeutet, dass die Zeit, die ein Angreifer benötigt, um etwas zu tun, begrenzt ist, im Gegensatz zu dem Zeitfenster, das ein langjähriger Dienst bietet. Der Nachteil ist, dass die Forensik schwieriger ist. Sobald der Container verschwunden ist, kann er nicht mehr auf Malware untersucht werden. Diese Architekturen erschweren es einem Angreifer auch, Malware zu installieren, die nach der Zerstörung des Containers überlebt, wie dies bei Bare-Metal-Anwendungen der Fall sein kann, indem ein Treiber installiert wird, der beim Booten geladen wird. Container werden normalerweise aus einem vertrauenswürdigen, schreibgeschützten Repository geladen und können durch kryptografische Überprüfungen weiter gesichert werden.

Betrachten wir nun, was während eines Verstoßes passiert.

Schutz vor Verstößen

Angreifer haben normalerweise ein oder zwei Ziele beim Eindringen in ein Serversystem. Sie wollen Daten bekommen oder Schaden anrichten.

Wenn sie nach Daten suchen, möchten sie so viele Systeme wie möglich mit den höchstmöglichen Berechtigungen infiltrieren und diesen Zugriff so lange wie möglich aufrechterhalten. Wenn sie dies erreichen, haben sie Zeit, die Daten zu finden, die möglicherweise bereits vorhanden sind - beispielsweise eine schlecht gesicherte Datenbank - oder die im Laufe der Zeit eine langsame Erfassung erfordern, z. B. das Sammeln von Transaktionen, wenn sie von Benutzern eingehen. Um den Zugang für eine lange Zeit aufrechtzuerhalten, ist Stealth erforderlich. Der Angriff erfordert auch eine Möglichkeit, die Daten herauszuholen.

Wenn der Angreifer einfach versucht, Schaden zu verursachen, besteht das Ziel erneut darin, auf so viele Systeme und Berechtigungen wie möglich zuzugreifen. Aber es gibt einen Balanceakt: Sobald der Schaden beginnt, wird er vermutlich bemerkt, aber je länger der Angreifer auf den Start wartet (während die Malware von System zu System filtert), desto größer ist die Wahrscheinlichkeit, entdeckt zu werden. Das Abrufen von Daten ist weniger wichtig als die koordinierte Kontrolle der Malware. Die Idee ist, so viele Systeme wie möglich zu infizieren und sie dann an einem synchronisierten Punkt zu beschädigen, entweder vorab oder auf Befehl.

Verstöße umfassen eine Reihe von Elementen. Schauen wir uns die einzelnen an und sehen wir, ob VMs und containerisierte Architekturen die Angriffsfläche für jede beeinflussen können.