Adaptive Segmentationmicro-segmentation September 15, 2020

FIREWALLS UND STATEFUL INSPECTION VERSTEHEN

Rupesh Mishra, Former Director, Office of the CTO

RUPESH MISHRA, FORMER DIRECTOR, OFFICE OF THE CTO

Array

 

Firewalls sind seit langer Zeit ein Hauptpfeiler der Cybersecurity-Strategie eines jeden Unternehmens. Wegen der kritischen Rolle, die sie einnehmen, wurden nach und nach mehr Features und Verbesserungen eingeführt. Ich möchte in diesem Post auf ein besonderes Feature eingehen, das bis ins Jahr 1994 zurückgeht und von Check Point Software Technologies erfunden wurde: Stateful Inspection.

Warum sehen wir uns ausgerechnet Stateful Inspection an? Weil es im Markt der Firewalls eine Unmenge verschiedener Varianten gibt, die zwischen Stateless und Stateful Protocol Inspection liegen. Wir werden diese Begriffe gleich erklären, aber zuvor wollen wir unser Augenmerk noch auf eine Reihe von Lösungen lenken, die es mittlerweile am Markt gibt und die die Grenzen zwischen Stateless und Stateful Inspection verschwimmen lassen. Wir müssen diese verschiedenen Lösungen verstehen, um die richtige Firewall für verschiedene Umgebungen selektieren zu können.

In diesem Post werden wir die technischen Grundlagen von Stateful und Stateless Firewalls erklären. Als zweiten Schritt kategorisieren wir aktuelle Firewalls auf Basis dieser Grundlagen.

STATEFUL VS. STATELESS INSPECTION

Was ist Stateful Inspection?

Stateful Inspection, oder auch dynamische Paketfilter, ist die Fähigkeit einer Firewall Pakete auf Basis ihres Status (oder State) und dem Kontext der Netzwerkverbindung filtern zu können. Schauen wir uns genauer an was State und Kontext einer Netzwerkverbindung bedeuten.

STATE

Um State zu veranschaulichen, sprechen wir am besten über TCP-basierte Kommunikation zwischen zwei Endpunkten. In TCP existieren vier Bits (SYN, ACK, RST, FIN) aus neun möglichen Kontrollbits, die den Status der Verbindung kennzeichnen. Weiter unten finden wir eine einfache Erklärung wie Firewalls den Status einer Verbindung verfolgen können. In der Realität kann eine Verbindung zwischen 11 States pendeln, je nachdem, ob man den Client oder den Server der Verbindung ansieht. Firewalls können eine Policy auf diesen Verbindungs-Status anwenden und müssen dabei natürlich übriggebliebene Pakete, Retransmissions oder verzögerte Pakete mit berücksichtigen.

  1. Wenn ein Client eine Verbindung mittels eines 3-Wege Handshakes initiiert, setzt der TCP Stack das SYN Flag um den Start einer Verbindung anzuzeigen. Die Firewall erkennt daran eine neue Verbindung und kennzeichnet diese als NEW.
  2. Der Server antwortet auf diese Anfrage mit einem Paket, das SYN und ACK gesetzt hat, hier hat die Firewall bereits Pakete von beiden Seiten gesehen und erhöht den State der Verbindung von NEW auf ESTABLISHED. Dies passiert, obwohl der Client den Handshake noch nicht mittels eines finalen Pakets mit gesetztem ACK Flag bestätigt hat.
  3. Ähnlich ist es, wenn eine Firewall ein RST Flag oder auch ein FIN + ACK als Flag sieht. Die Verbindung wird als gelöscht markiert und jedes zukünftige Paket zu dieser Verbindung wird verworfen. 

PSEUDO STATE

Nicht alle Netzwerk-Protokolle haben einen State wie z.B. TCP. Ein gutes Beispiel hierfür ist natürlich UDP, ein häufig genutztes Protokoll, dass per Definition stateless ist. Applikationen, die UDP nutzen halten den Status in der Applikations-Logik oder kommen sogar ganz ohne Status aus. Ein paar bekannte Beispiele sind zum Beispiel DNS, TFTP, SNMP, RIP, DHCP, etc. Moderne Firewalls führen hier einen “Pseudo State” für diese Protokolle. Als Beispiel wird für eine ausgehende DNS Anfrage ein Eintrag mit IP, Port und Source-Adresse und Destination-Adresse angelegt. Ein Antwortpaket (DNS Antwort) wird dann erlaubt, wenn es den Parametern entspricht und innerhalb eines definierten Zeitfensters liegt.

KONTEXT

Der Kontext einer Verbindung beinhaltet mit den Paketen assoziierte Metadaten wie zum Beispiel:

  • IP und Port von Quelle und Ziel
  • Zeitstempel des letzten empfangenen Pakets
  • Paket-Größe
  • Sequenznummern und Flags der Layer 4 Verbindung
  • Layer 3 Daten über Fragmentierung und Reassemblierung, um Sessions zu identifizieren bei denen Pakete erwartet werden

Einordnung von Firewalls anhand Stateful vs. stateless Inspection

Da wir jetzt wissen, welche Daten eine Firewall mit Verbindungen speichert, lohnt es sich die verschiedenen Arten von Firewalls am Markt anzusehen.

Stateless Firewalls – Wie Sie Funktionieren, wo man sie nutzt und gängige Probleme

Beziehen wir uns auf Abbildung 1 um die Mechanismen in einer stateless Firewall zu verstehen. Eine stateless Firewall sieht ein- und ausgehenden Traffic (1 in Abb. 1) indem sie sich die Protokoll-Header der Pakete auf der OSI Schicht 2-4 ansieht und mit der Policy vergleicht (2). Die Policy-Action (4a und 4b) wie ALLOW, DENY oder RESET bestimmt dabei, ob das Paket durchgelassen oder gefiltert wird (2).

stateless_firewall_policy_decisions

Abbildung 1: Flussdiagramm für die Policy-Entscheidung einer Stateless Firewall

Vor- und Nachteile von Stateless Firewalls

Zuerst sprechen wir über die Vorteile:

  • Der Abgleich des Pakets mit der Policy basiert auf statischen Daten, deswegen kann diese Operation schnell und mit wenig CPU und Speicherbedarf ausgeführt werden. Deswegen wird diese Technik vorwiegend für ACLs (Access Control Lists) in Layer 2 Geräten wie Switchen oder auch Layer 3 Geräten wie Routern eingesetzt, um einen hohen Durchsatz zu gewähren.
  • Das Ergebnis ist, dass Stateless Paketfilterung weniger Ressourcen-intensiv und in Hardware verwendet wird. Die Verarbeitung der Pakete braucht kaum Zeit und erzeugt so keine Latenz beim Weiterleiten der Pakete.

Jetzt die Nachteile:

  • Eine Stateless Firewall entscheidet aufgrund statischer Daten und hat deswegen nur limitierte Filtermöglichkeiten
  • Die Konfiguration und das Management der ACLs auf diesen Geräten ist bereits in kleinen Umgebungen fehleranfällig, und unmöglich in großen Umgebungen.

So erklären sich die Probleme im Management der ACLs in kleinen und großen Umgebungen, sehen wir uns zuerst eine kleine Umgebung an.

  • Stateless Firewalls sind per Definition unidirektional, weil sie Policy Entscheidungen nur aufgrund eines Pakets und dessen Header treffen, ohne den Flow der Pakete zu kennen. Um eine akkurate Policy zu schreiben, muss man stets beide Seiten der Verbindung bei einer bidirektionalen Verbindung wie im Falle von TCP berücksichtigen und zulassen. Zwei Rules pro Verbindung zu schreiben wird sehr schnell zu einem Problem.
  • Denken wir jetzt an ein Protokoll wie FTP, bei dem stets zwei Verbindungen für jede Transaktion genutzt werden und die Datenverbindung dabei einen zufällig ausgehandelten Port benutzt. Dies kann von einer Stateless Firewall nicht verarbeitet werden. Um das zu erreichen muss man weite Port-Ranges öffnen und schafft somit ein großes Sicherheitsproblem.
  • Ein weiteres Beispiel könnte ein interner Host sein, der eine Verbindung zum Internet aufbaut. Aber wie erlaubt man mit Hilfe einer ACL den zurückkommenden Traffic? Stateless Firewalls wurden nicht für diese Anwendung gebaut und ergeben keinen Sinn, wenn es um Mikro-Segmentierung geht, bei der die Policy sehr feingranular und richtungsgebunden sein muss.

Sehen wir uns das Problem jetzt in großen Umgebungen an:

  • Wir stellen uns vor, wir haben einen Zauberstab, mit dem wir die o.a. genannten Probleme eliminieren können. Selbst in diesem Fall werden wir Probleme mit Ressourcen haben, wie zum Beispiel dem TCAM (Ternary content-addressable memory) auf dem Switch oder Router haben, weil dieser so teuer und eng bemessen ist, dass man niemals für all die Applikationen im Rechenzentrum Policy auf Ihnen schreiben kann.
  • Selbst bei Implementierung in Software bedeutet die Menge der benötigten ACLs ein Problem. Als ich für einen anderen Hersteller gearbeitet habe, hat alleine das Parsen und Einlesen der Policy Tabelle auf einem System mit sehr vielen ACLs über 30 Minuten gedauert (Policy Tabelle in Abb. 1). Dieser Prozess muss jedes Mal neu ausgeführt werden, wenn Regeln hinzukommen oder gelöscht werden. Die Verfügbarkeit leidet und hat Einfluss auf die Geschäftsprozesse und das bei Alltagsaufgaben wie einer Regel.


REFLEXIVE FIREWALLS AKA REFLEXIVE ACLS

Eine reflexive ACL, auch IP-Session-Filter ACL genannt, ist eine Methode, um automatisch den zurückkommenden Traffic dynamisch in eine Allow-Liste zu bewegen. Die meisten Schritte bei dieser Art der Filterung sind ähnlich wie bei Stateless Firewalls, bis auf den Mechanismus einen neuen Flow zu identifizieren und automatisch eine dynamische, stateless ACL dafür anzulegen. Sehen wir uns den Fluss eines Paketes genauer an.

reflexive_acl_policy_decisions

Abb 2: Flussdiagramm einer Policy-Entscheidung bei reflexiven ACLs

Wenn eine reflexive ACL eine neue, ausgehende IP Verbindung sieht (6 in Abb. 2), dann wird ein dynamischer ACL Eintrag hinzugefügt, der die Gegenrichtung der Verbindung kennzeichnet und die Parameter von Source und Destination umdreht. Diese neue dynamische ACL erlaubt automatisch den Netzwerkverkehr, der zurückkommt. Gleichermaßen wird diese reflexive ACL gelöscht, wenn ein FIN, ein RST Flag für beide Seiten dieser Verbindung gesehen wird oder ein Timeout eintritt.

Was sind die Vorteile reflexiver Firewalls?

Der einzige Vorteil einer reflexiven Firewall über einer Stateless Firewall ist die Fähigkeit automatisch den Verkehr zurück zu erlauben. Damit entfallen manuell erstellte Regeln für diese Richtung der Kommunikation.

Nachteile einer reflexiven Firewall?

Reflexive ACLs berufen sich, wie auch bei Stateless Firewalls auf die statischen Infos im Paket. Und obwohl sie einen Vorsprung beim Management gegenüber normalen ACLs haben, ist es einfach die reflexiven ACLs zu umgehen. Reflexive Firewalls haben die gleichen Probleme wie Stateless Firewalls. Man kann zum Beispiel ein Paket so fragmentieren, dass die Information, die die reflexive ACL braucht, um zu funktionieren, über verschiedene Pakete verteilt. So kann die reflexive ACL nicht entscheiden, ob der Traffic erlaubt oder geblockt werden soll. Eine Stateful Firewall auf der anderen Seite, kann ganze TCP Streams reassemblieren und trifft dann eine Entscheidung aufgrund des Status und des Kontexts für den gesamten Stream.

Der andere Nachteil reflexiver ACLs ist die Fähigkeit mit bestimmten Applikationen zusammen zu funktionieren. Ein Beispiel: eine verbreitete Applikation wie FTP, die man benutzt, um Dateien übers Netzwerk zu kopieren, funktioniert indem sie dynamisch einen Port für eine Datenverbindung aushandelt, die parallel zur Kontrollverbindung läuft. Weil reflexive ACLs statisch sind können sie nur bidirektional Traffic zwischen Hosts erlauben, die das gleiche Tupel aus Source, Source-Port, Destination, Destination-Port und Protokoll haben. Applikationen wie FTP können hiermit nicht bedient werden.

STATEFUL FIREWALLS – Wie sie arbeiten, wo man sie benutzt und ihre Schwächen

Eine Stateful Firewall beachtet STATE sowie KONTEXT einer Verbindung um die Policy anzuwenden. Um die Arbeitsweise zu verstehen sehen wir uns das untenstehende Diagramm an.

stateful_firewall_policy_decisions

Abb. 3: Flussdiagramm Policy-Entscheidung einer Stateful Firewall

 

  1. Wenn ein Paket an der Firewall ankommt (1 in Abb. 3) wird versucht den korrespondierenden vorhandenen Flow in einer Tabelle mit allen existierenden Verbindungen (Flow-Table, Connection Table oder auch State Table genannt) zu finden (Source-IP, Source-Port, Destination-IP, Destination-Port, Protokoll). Aufmerksame Leser werden hier bereits den Unterschied zu Stateless Firewalls merken, wo in der Policy nach diesem 5er-Tupel gesucht wird und nicht in der Flow Table. Die Flow Table und zugehörige Tabellen beinhalten den STATE und KONTEXT aller vorher gesehenen Flows.
  2. Wird ein Eintrag gefunden, wird das Paket beschleunigt über die Data Plane verarbeitet (Fast Path). Einfache Verfahren hierfür checken Häufigkeiten und Paketraten, validieren Layer 3 Flags und Header um Fragmentierungs- und Reassemblierungs-Attacken zu verhindern, prüfen ebenfalls Layer 4 Flags und Header, um Attacken wie DOS und Spoofing zu verhindern. Wenn die Firewall auch Layer 7 testen kann, so werden zusätzliche Filter durchlaufen, sog. Application Layer Gateways (ALGs). Wenn alle Checks erfolgreich sind, wird das Paket an den nächsten Hop weitergeleitet (3b).
  3. Wenn der Flow Lookup (3a) kein Ergebnis liefert, dann wird angenommen, dass das Paket für eine neue Verbindung ist und muss durch zusätzliche Prüfungen laufen. Dieser Pfad wird auch als „Slow Path“ bezeichnet, weil dazu eine Menge Logik in der Control Plane durchlaufen werden muss. Dort werden neben den Checks aus dem Fast Path auch die Prüfungen ausgeführt, die entscheiden, ob das Paket durch die Policy erlaubt ist oder nicht.
  4. Die Firewall sieht sich also STATE und KONTEXT an (5).
  5. Trifft eine Policy Regel zu und eine Aktion ist für diese Policy angegeben (ALLOW, DENY, RESET), wird die Aktion ausgeführt (8a oder 8b). Außerdem erlauben moderne Stateful Firewalls anzugeben, welche weiteren Inhaltsprüfungen durchgeführt werden sollen. Diese Prüfungen werden in die Entscheidung einbezogen und ein Eintrag in die Flow Table (9) vorgenommen, so dass nachfolgende Pakete für diese Verbindung sehr viel schneller verarbeitet werden können (Fast Path) und kein Eingreifen der Control Plane mehr benötigen. 


Wir kennen jetzt Stateful Firewalls, lösen sie alle Probleme, die Stateless Firewalls haben?

Als erstes sehen wir dazu die Nachteile einer Stateful Firewall an:

  • Stateful Firewalls führen weitere Checks aus, um mehr Sicherheit zu gewährleisten und brauchen deshalb mehr CPU und Speicher. Architekten und Entwickler dieser Firewalls haben über diese Probleme lange nachgedacht und viele der aktuellen Firewalls haben diesen Nachteil nicht mehr, da sie moderne Algorithmen verwenden, um Data und Control Plane zu trennen – und erreichen so fast die Performance von Stateless Firewalls. Wir lassen die Stateless Firewall hier trotz allem gewinnen.
  • Eine Stateful Firewall kann eine höhere Angriffsfläche haben als eine Stateless Firewall, weil die Menge Code, die dafür benötigt wird und dort läuft, wesentlich größer ist. Eine einfache Google Suche liefert dazu viele Beispiele. Mit der Zeit haben aber viele dieser Stateful Firewalls, speziell die in die Betriebssysteme eingebauten Firewalls unter Linux und Windows so viele Szenarien gesehen und Entwicklungs-Iterationen durchlaufen, dass man sie mittlerweile als Enterprise-grade bezeichnen kann.

Was sind die großen Vorteile von Stateful Firewalls?

  • Eine Stateful Firewall garantiert volle Inspektion von Protokollen und kann STATE und KONTEXT von Flows mit einbeziehen, dadurch fällt Angriffsoberfläche weg. Wir werden diesen Punkt in einem späteren Blog mit betrachten und zeigen was es bedeutet. Stay tuned.
  • Eine Stateful Firewall ist die Basis für fortgeschrittene Application Layer Firewalls
  • Eine Stateful Firewall versteht Flows und kann Datenpakete eines Flows zuordnen. Dadurch ist es einfach Regeln für bidirektionale Verbindungen oder für Pseudo State Netzwerkprotokolle zu schreiben
  • Weil eine Stateful Firewall tiefer in Pakete sehen kann, kann sie komplexe Protokolle verstehen, die zum Beispiel dynamische Ports und Protokolle zur Laufzeit aushandeln und die Policy darauf adaptieren. Man denke zum Beispiel an FTP und P2P Protokolle wie MS Teams oder Skype.
     

Schlusswort

Wir haben damit begonnen das Konzept von STATE zu beleuchten und welche Dinge dazu führen, dass eine Firewall als stateful gilt. Später haben wir uns verschiedene Typen von Firewalls angesehen und verstanden, wie sie Policy-Entscheidungen treffen und welche Auswirkungen auf die Security und Performance das haben kann. Es gibt keine Firewall, die alle Probleme löst und jede dieser Firewalls hat einen Platz in einer Verteidigungsstrategie: eine stateless Firewall kann dort helfen, wo grobgranulare Policy reicht und eine stateful Firewall dort, wo feingranularere und tiefergehende Policy verlangt wird. Natürlich haben wir in diesem Blog die technischen Zusammenhänge etwas vereinfacht, um die grundsätzlichen Design-Prinzipien klarer herauszuarbeiten. In der Wirklichkeit gibt es eine Myriade von verschiedenen Möglichkeiten und Kombinationen diese zu implementieren.

Da wir jetzt das technische Grundwissen für “Statefulness“ besitzen, wird mein nächster Post genauer darauf eingehen warum Stateful Firewalls wichtig für die Security-Segmentierung bzw. Mikro-Segmentierung sind und warum jeder Hersteller dafür Stateful Firewalls verwenden sollte.

Für jegliche Fragen, bitte kontaktieren sie mich. Sehen Sie sich auch Illumio Labs an, wo wir mehr technische Blogs, Demos und Open Source Code veröffentlichen, um Ihre Sicherheit in Rechenzentrum und Cloud zu steigern.

 

Adaptive Segmentationmicro-segmentation
Share this post:

Try Illumio Edge