Untersuchung der Verwendung der NGFW-Funktionalität in einer Mikrosegmentierungsumgebung

Seit fast zwei Jahrzehnten sind Next-Generation-Firewalls (NGFWs) ein unverzichtbares Sicherheitsinstrument. Da die heutigen Netzwerke jedoch immer komplexer werden, löst der von NGFWs angebotene Perimeterschutz ein Problem, das immer weniger relevant wird.

Illumio erforscht die Möglichkeiten, NGFW-Funktionen in einer Mikrosegmentierungsumgebung zu implementieren und die beiden Technologien zu kombinieren, um die Art von Sicherheit zu bieten, die für komplexe Netzwerke erforderlich ist.

Im ersten Teil habe ich einen Überblick über die Geschichte, den Wert und die Herausforderungen von Next-Generation-Firewalls (NGFWs) gegeben.

In diesem zweiten Artikel werde ich über das "Was wäre, wenn?"-Szenario sprechen, bei dem eine Teilmenge der NGFW-Funktionalität in eine Mikrosegmentierungslösung eingebettet wird. Ich werde über verschiedene Anwendungsfälle sprechen und darüber, welche NGFW-Funktionen für jeden geeignet sein könnten.

NGFWs arbeiten für den Nord-Süd-Verkehr – tun sich aber schwer mit Ost-West-Verkehr

Die NGFW wurde um die Idee herum entwickelt, den Perimeter eines Netzwerks zu schützen, und zwar hauptsächlich um den Schutz vor Bedrohungen im eingehenden Datenverkehr. In der Netzwerkwelt wird diese Art von Datenverkehr oft als "Nord-Süd" bezeichnet. Diese Terminologie stammt aus der weit verbreiteten Praxis, ein Netzwerk mit der Internet-"Blase" an der Spitze zu zeichnen, wobei der Datenverkehr in das Rechenzentrum von oben nach unten oder von Norden nach Süden fließt. Der Datenverkehr innerhalb des Rechenzentrums wird in der Regel als seitlich, von links nach rechts oder von rechts nach links bewegt dargestellt und daher oft als "Ost-West" bezeichnet.

Mit dieser Terminologie kann man sagen, dass es einen mächtigen Anwendungsfall für NGFWs gibt, die in einer Nord-Süd-Rolle verwendet werden, wie ich im ersten Teil erwähnt habe. Der Anwendungsfall für Ost-West ist jedoch etwas weniger sicher. Diese zweite Aussage hat Ihnen wahrscheinlich einige Nackenhaare aufgezogen, also lassen Sie mich etwas genauer auf diese Aussage eingehen.

Firewalls kosten drei Arten von Geld: Hardware, Wartung/Support und Konfiguration/Überwachung. Trotz der hohen Kosten in allen drei Kategorien ist der ROI für NGFWs für den Nord-Süd-Anwendungsfall ziemlich eindeutig. Wenn es um Ost-West geht, stellt sich heraus, dass nur eine Teilmenge der vollständigen NGFW-Funktionen relevant ist, aber die Anbieter geben Ihnen keinen Rabatt, wenn Sie nicht den vollen Funktionsumfang nutzen. Es ist oft schwierig, den Kauf einer vollständigen NGFW-Appliance zu rechtfertigen und nur die Hälfte der Funktionalität zu nutzen, umso mehr in den Fällen, in denen der NGFW-Funktionsumfang nicht gesetzlich oder behördlich vorgeschrieben ist.

NGFWs für den Süd-Nord-Verkehr

Das sind zwei der guten Anwendungsfälle für eine NGFW, aber es gibt tatsächlich einen dritten, den die Leute selten in Betracht ziehen, außer am Rande: der Süd-Nord-Anwendungsfall oder auf Englisch, die Steuerung des ausgehenden Datenverkehrs aus dem Netzwerk. Die NGFW-Anbieter reden darüber, aber nur ein bisschen. Und die meisten Unternehmen sind sich zwar der Bedrohung durch uneingeschränkte ausgehende Verbindungen bewusst, tun aber bemerkenswert wenig, um dem Problem tatsächlich zu begegnen. In der jahrelangen Zusammenarbeit mit vielen Kunden habe ich festgestellt, dass die meisten Unternehmen nicht einmal über einen Prozess verfügen, mit dem ihre internen Anwendungsbesitzer ausgehende Kontrollen an der Netzwerkgrenze anfordern können.

Mein Job ist im Grunde genommen Forschung und Entwicklung, mit einem starken Fokus auf den "R"-Teil. Lassen Sie uns in diesem Sinne ein Gedankenexperiment durchführen. Betrachten wir für einen Moment das Nord-Süd-Problem als gelöst. Es ist nicht in dem Sinne gelöst, dass es keine 100% fehlerfreie Lösung gibt, aber es ist in dem Sinne, dass die meisten Unternehmen diesen Weg nicht mehr als den primären Angriffsweg in ihre Netzwerke betrachten. Lassen Sie uns stattdessen darüber nachdenken, wie Netzwerke sicherer gemacht werden könnten, wenn Sie ausgewählte NGFW-Funktionen in Ihre Mikrosegmentierungslösung implementieren und sowohl Ihre Ost-West- als auch Ihre Süd-Nord-NGFW-Kontrollen verbessern könnten, ohne weitere Geräte kaufen zu müssen oder Ihre eigenen internen organisatorischen Prozesse bekämpfen zu müssen, die Sie daran hindern, ausgehende NGFW-Funktionen zu nutzen.

Die Süd-Nord- und Ost-West-Anwendungsfälle sind unterschiedlich, aber es gibt erhebliche Überschneidungen. Darüber hinaus sind viele Nord-Süd-Features für keines dieser Features relevant. Beginnen wir mit dem Ost-West-Anwendungsfall.

Wie ich bereits sagte, gibt es sicherlich einen Anwendungsfall für eine begrenzte Teilmenge von Ost-West-NGFW-Steuerelementen. Der ROI für eine vollwertige Appliance (oder virtuelle Appliance) mag angesichts der Kosten fragwürdig sein, aber der Bedarf ist dennoch real. Wenn Ihr Netzwerk PII-, HIPPA- oder PCI-Daten enthält, unterliegen Sie mit ziemlicher Sicherheit den Gesetzen und Vorschriften zum Schutz dieser Daten. In vielen Fällen beinhaltet dies die explizite Anforderung, traditionelle NGFW-Dienste wie DLP (Data Loss Prevention) und IDS/IPS (Intrusion Detection/Prevention Service) zu implementieren. Auch wenn es kein Mandat gibt, bleibt es eine Best Practice. Mit anderen Worten, die Anwendungs-ID, die Möglichkeit, Datenverkehr basierend auf der tatsächlichen Art des Datenverkehrs zu blockieren oder zuzulassen, im Gegensatz zu Port und Protokoll, ist ebenfalls ein leistungsstarkes und wünschenswertes Werkzeug, um Angriffe und Datenexfiltration zu verhindern.

Für den Süd-Nord-Anwendungsfall können einige zusätzliche Funktionen hilfreich sein. DLP wird wahrscheinlich immer noch benötigt, und die Anwendungs-ID ist für diesen Anwendungsfall ebenso nützlich, aber dazu würde ich eine URL-Filterung und die Möglichkeit hinzufügen, den Datenverkehr basierend auf der Ziel-IP-Reputation und der Geografie zu steuern. Sicher, Ihre Grenz-NGFW kann dies bereits tun, aber wie ich bereits erwähnt habe, gibt es für einen Anwendungsbesitzer oft keine Möglichkeit, diese Funktionen zu nutzen, wenn die Grenzgeräte nicht unter seiner Kontrolle stehen. Und das sind sie selten in einer großen Rechenzentrumsumgebung.

Die meisten anderen NGFW-Dienste haben einen begrenzten Wert für Ost-West oder Süd-Nord. DDoS und QoS machen innerhalb eines Netzwerks wenig Sinn. Ebenso ist moderne AV-Software, die innerhalb des Betriebssystems ausgeführt wird, wahrscheinlich effizienter als eine netzwerkbasierte Lösung, sodass netzwerkbasierter Virenschutz wahrscheinlich nicht auf der Tagesordnung steht.

Die Leistung von NGFW-Funktionen auf Endgeräten

Es ist an der Zeit, über die Auswirkungen von NGFW-Funktionen auf die Leistung zu sprechen, die auf Endpunkten ausgeführt werden. Wenn Sie sich erinnern, erwähnte Teil eins, dass NGFW-Geräte fast Supercomputer-Systeme mit viel spezialisierter Hardware sind, um eine respektable Leistung zu erzielen. Daraus folgt natürlich, dass einzelnen Servern bei der Implementierung derselben Funktionalität eine erhebliche Leistungseinbuße auferlegt würde. Glücklicherweise scheint dies eine dieser Zeiten zu sein, in denen die Intuition aus dem Fenster geworfen wird. Lassen Sie uns darüber sprechen, warum.

IDS/IPS ist ein guter Ausgangspunkt. Von allen NGFW-Diensten gilt IDS/IPS als einer der "schwersten", was bedeutet, dass es eine unverhältnismäßig große Anzahl von Ressourcen verbraucht und einer der Gründe für die große Menge an kundenspezifischem Silizium in einer NGFW-Appliance ist. Wenn ich ein mittelgroßes Rechenzentrum mit 1.000 Workloads mit einer IDS/IPS-Lösung schütze, muss ich wahrscheinlich IDS/IPS-Signaturen für mindestens ein Dutzend verschiedener Betriebssysteme unterstützen (Windows 2008, 2012, 2016, 2019, mindestens ein halbes Dutzend Variationen und Versionen von CentOS, RedHat und Ubuntu (plus möglicherweise Solaris oder AIX, wenn ich im Gesundheitswesen oder im Bankwesen tätig bin). Auf jedem dieser 1.000 Server läuft mindestens ein Dienst, auf den ich achten möchte, möglicherweise bis zu drei oder vier verschiedene Dienste, die alle potenzielle Schwachstellen aufweisen. Und mit einem Dutzend Betriebssystemen führe ich möglicherweise ein Dutzend verschiedene Versionen jedes dieser drei oder vier Dienste aus, von denen jeder unterschiedliche Schwachstellen aufweist.

Kurz gesagt, ich halte Ausschau nach irgendwo zwischen 10.000 und 100.000 Schwachstellensignaturen für diese tausend Computer. Und ich suche nach Anzeichen dafür in jedem einzelnen Paket, das durch mein NGFW-Netzwerkgerät fließt – auf jedem möglichen Port, an dem sie möglicherweise betrieben werden. Dies ist eindeutig keine Last, die wir jedem Server im Rechenzentrum auferlegen wollen.

In der Praxis müssen wir das auch nicht. Es gibt keinen Grund, auf einem Linux-Host nach Windows-Schwachstellen zu suchen. Es ist nicht erforderlich, auf einem Rechner, auf dem NGINX ausgeführt wird, nach apache2-Schwachstellen zu suchen. Es ist nicht erforderlich, auf einem System, auf dem Application X Version 2.2 ausgeführt wird, nach Schwachstellen in Application X Version 1.0, 1.1, 1.2, 1.3, 2.0 und 2.1 zu suchen.

Anstatt in jedem einzelnen Paket nach 10.000 bis 100.000 Schwachstellen zu suchen, suchen wir nach vielleicht vier. Nicht 4.000. Vier. Und vier ist ein lösbares Problem.

Wie? Denn da wir auf jedem Server einen Agenten haben, haben wir vollen Zugriff, um das Betriebssystem zu verstehen, welche Patches angewendet wurden und welche nicht, welche Software (und welche Versionen dieser Software) installiert sind und ausgeführt werden und vor allem, über welche Ports sie kommunizieren. Wir suchen nach Schwachstellen, die spezifisch für die erkannten Betriebssystem- und Softwareversionen sind, insbesondere an den Ports, an die die relevanten Prozesse gebunden sind. Wir reduzieren den Suchraum um etwa vier Größenordnungen. Und vier Größenordnungen sind in der Informatik eine spektakulär große Zahl. Das ist der Unterschied zwischen schwer und leicht.

Ähnliche Strategien könnten auf Dienste wie DLP und URL-Filterung angewendet werden. Es ist nicht notwendig, jedes Paket auf jedem Server nach eingeschränkten DLP-Inhalten zu filtern oder riesige Datenbanken mit URLs oder IP-Informationen für öffentliche Adressen auf jedem Server zu speichern. Im Fall von DLP suchen Sie nur nach bestimmten Inhalten auf einer ganz bestimmten Gruppe von Servern basierend auf Workload-Bezeichnungen, auf die gleiche Weise, wie die Segmentierungsrichtlinie angewendet wird. Für die URL-Filterung kann die große Datenbank mit IP-Merkmalen im zentralen Richtlinienverwaltungssystem gespeichert, bei Bedarf über eine LAN-Verbindung mit geringer Latenz abgerufen und für nachfolgende Nachschlagevorgänge lokal zwischengespeichert werden. Die meisten Server kommunizieren immer wieder mit der gleichen relativ kleinen Gruppe von Servern.

NGFW-Funktionen für eine Mikrosegmentierungslösung

Wenn Sie NGFW-Funktionen zu einer Mikrosegmentierungslösung hinzufügen, profitieren Sie am meisten davon, dass die NGFW-Funktionen genau wie bei Firewall-Richtlinien chirurgisch und genau dort angewendet werden, wo Sie sie benötigen, und nicht auf ganze VLANs oder Subnetze als Gruppe. Eine bezeichnungsbasierte Richtlinie ermöglicht es dem Anwendungsbesitzer, sehr spezifische Dienste chirurgisch und genau dort anzuwenden, wo sie benötigt werden, anstatt das Rechenzentrum mit einem breiten Pinsel zu malen. Bestimmte NGFW-Funktionen können nur für die notwendigen Server aktiviert werden und nur die erforderliche Inspektion durchführen. Dadurch wird der Overhead auf das absolut Minimum reduziert, das erforderlich ist, um Ihre spezifischen Sicherheitsanforderungen zu erfüllen, und Sie können Sicherheit, Leistung und Kosten in Einklang bringen.

Denken Sie daran, dass das Ziel hier nicht darin besteht, Ihre Border-NGFW-Geräte zu ersetzen. Vielmehr geht es darum, selektiv die Lücken zu füllen, in denen bestehende NGFW-Lösungen architektonisch oder finanziell nicht sinnvoll sind, indem eine leistungsstarke Teilmenge von NGFW-Funktionen auf den Servern selbst ausgeführt wird. Dieser Ansatz ermöglicht es Anwendungsbesitzern, ihre ausgehende Sicherheit dort zu "besitzen", wo dies sonst nicht möglich wäre, und diese Funktionen in Situationen anzubieten, die mit herkömmlichen Lösungen ansonsten unerschwinglich wären.

Blick in die Zukunft

Um dies zu veranschaulichen, lassen Sie uns noch weiter in die Zukunft blicken.

TLS 1.3 wurde 2018 ratifiziert und entwickelt sich langsam zum nächsten Standard für verschlüsseltes Web und andere Dienste. Ihre erste Reaktion darauf könnte sein: "Nicht mein Problem" oder vielleicht "Na und?" Ich würde behaupten, dass es tatsächlich extrem relevant ist. Eine NGFW kann die meisten verfügbaren Dienste ohne Deep Packet Inspection (DPI) nicht bereitstellen. Und damit DPI in irgendeiner Weise aussagekräftig ist, müssen die Daten im Klartext und nicht verschlüsselt vorliegen.

Als NGFWs zum ersten Mal auf den Markt kamen, war nur ein winziger Bruchteil des Webverkehrs verschlüsselt. Im Laufe der Zeit wurde immer mehr Datenverkehr auf HTTPS oder verschlüsselten Datenverkehr umgestellt. Heutzutage ist fast 100 % des gesamten Webverkehrs verschlüsselt und kann daher nicht auf Malware, Viren, Datenexfiltration oder andere NGFW-Server analysiert werden. Die Lösung, die dafür entwickelt wurde, heißt TLS MiTM (Man-in-the-Middle).

Die Einrichtung von TLS MiTM ist etwas mühsam, wenn auch einfach im Konzept. Die Lösung besteht aus einer Reihe von beweglichen Teilen. Zunächst erstellt die Organisation ein internes TLS-Zertifikat. Der öffentliche Schlüssel wird an alle Systeme (Laptops, Desktops, Server usw.) innerhalb der Organisation übertragen, und jedes Betriebssystem ist so konfiguriert, dass es diesem Zertifikat vertraut und es zur Verschlüsselung der gesamten ausgehenden Kommunikation verwendet, unabhängig vom Ziel. Der private Schlüssel wird dann an Ihre NGFW-Umkreisgeräte verteilt, die als transparente Webproxys konfiguriert sind.  

Wenn ein Nutzer (oder Server oder ein anderes Gerät) eine ausgehende Verbindung mit einer externen Website herstellt, z. B. gmail.com in diesem Beispiel, wird der Datenverkehr nicht mit dem Google TLS-Zertifikat verschlüsselt, sondern mit dem internen Zertifikat der Organisation. Wenn die NGFW des Perimeters diesen ausgehenden Datenverkehr erkennt, ist sie in der Lage, ihn zu entschlüsseln und den Inhalt des Datenverkehrs vollständig zu analysieren, da sie über eine Kopie des privaten Schlüssels verfügt. Die NGFW beendet die interne Verbindung und erstellt mithilfe des Google-Zertifikats eine neue TLS-Verbindung zu gmail.com und leitet den Inhalt der beiden Verbindungen weiter (die interne Verbindung von innerhalb der Organisation zur externen Verbindung zu Google Mail) und ist somit in der Lage, den gesamten Datenverkehr anzuzeigen und zu analysieren, auch wenn er verschlüsselt ist.

Diese Methode ist zwar umständlich und CPU-intensiv, funktioniert aber seit etwa einem Jahrzehnt für die meisten Dienste mit SSL, dann TLS 1.0, 1.1 und 1.2 recht gut.

So weit so gut. Aber TLS 1.3 ändert das Spiel. Erstens schreibt TLS 1.3 Perfect Forward Secrecy in Form eines DH-Schlüsselaustauschs pro Verbindung vor. Aus diesem Grund hat ein passives Gerät keine Möglichkeit, die Nutzlast zu entschlüsseln, selbst wenn Zugriff auf den verwendeten privaten Schlüssel vorhanden ist. Mit TLS 1.3 ist es zwingend erforderlich, ein Gerät in den Stream einzufügen und den Datenverkehr als Proxy zu leiten. Zweitens werden durch TLS 1.3 die Verschlüsselungen mit geringerer Sicherheit als veraltet eingestuft, sodass ein Proxy-Gerät eine Proxy-Verbindung auf TLS 1.2 herabstufen kann, was eine gängige Strategie ist, die häufig verwendet wird, um Rechenressourcen in der NGFW zu sparen (da Verschlüsselungen mit niedrigerer Sicherheit in der Regel weniger Berechnungen erfordern).

Wenn uns die Geschichte der Kryptographie etwas gelehrt hat, dann, dass alte, vertrauenswürdige Standards im Laufe der Zeit mit fast 100%iger Sicherheit als anfällig befunden werden. Die derzeitige Praxis, TLS 1.3 auf TLS 1.2 herabzustufen, um eine passive Entschlüsselung und/oder Herabstufung zu ermöglichen, um Ressourcen zu sparen, läuft auf einem Timer und wartet nur darauf, dass TLS 1.2 veraltet ist. Wenn dieser Tag kommt, werden viele passive Inspektionsgeräte zu teuren Briefbeschwerern, während viele Inline-Lösungen schnell überfordert sind, weil sie gezwungen sind, rechenintensivere Kryptographie zu verwenden.

Ein schmutziges kleines Geheimnis der NGFW-Welt ist, dass zumindest zum Zeitpunkt des Schreibens dieses Artikels Ihr WebSocket-Datenverkehr wahrscheinlich nicht auf Bedrohungen jeglicher Art überprüft wird. Warum? Denn eine typische NGFW kann den Datenverkehr nicht in Echtzeit entschlüsseln. Der WebSocket-Datenverkehr muss in Ihrem Browser (mit Entwicklertools) angezeigt oder nachträglich mit etwas wie Wireshark erfasst und entschlüsselt werden (vorausgesetzt, Sie haben die privaten Schlüssel), um die Nutzlast zu überprüfen. WebSockets werden in Webanwendungen immer häufiger eingesetzt, da die Technologie eine großartige Lösung für JavaScript-Anwendungen bietet, um Daten zwischen Ihrem Browser und einem Webserver hin und her zu verschieben. Buchstäblich alles kann über eine WebSocket-Verbindung verschoben werden, und es ist für Ihre NGFW völlig undurchsichtig.

Zu guter Letzt sollten wir andere allgegenwärtige neue Technologien nicht vergessen, wie z. B. die Verwendung von QUIC für den Web-Traffic. QUIC ist zwar ein leistungsstarkes neues Tool, mit dem Sie den Datenverkehr schneller und effizienter an Ihren Browser weiterleiten können, verwendet jedoch keine standardmäßige TLS-Verschlüsselung. Das bedeutet, dass Ihre Inline-NGFW entweder den gesamten QUIC-Datenverkehr blockieren muss (was ein Downgrade auf TLS erzwingt) oder den Datenverkehr ungeprüft passieren lassen muss. Die erste Lösung verringert die Qualität der Benutzererfahrung, und die zweite setzt das Unternehmen Risiken aus. Beides ist nicht ideal.

Die Verarbeitung einiger NGFW-Aufgaben auf Workload-Ebene trägt dazu bei, die Lebensdauer der Investition in vorhandene NGFW-Appliances zu verlängern. Es ermöglicht die Entlastung eines bestimmten Prozentsatzes rechenintensiver Prozesse, indem sie pro Workload verarbeitet werden. Dies ermöglicht es dem Kunden, einen Teil der Inspektionsnutzlast von seinen Netzwerkgeräten zu entlasten, wodurch ein ansonsten notwendiges Firewall-Upgrade verzögert wird und gleichzeitig die Vorteile von Zero Trust in Teilen seines Netzwerks verfügbar gemacht werden, die sonst technisch oder finanziell nicht sinnvoll wären.