Wann ist eine Applikation nicht Firewall-tauglich?

So ist es auch im Netz. Wir begnügen uns nicht mit Perimeter-Sicherheit am Übergang zum Internet. Wir denken auch an eine Situation, in der ein Angreifer die Internet-Firewall überwunden hat. Ziel ist das Erschweren der sogenannten lateralen Bewegung des Eindringlings. Dies erfolgt standardmäßig durch Segmentierung des internen Netzes. Die effektivste Segmentierung ist gemäß dem Ansatz Zero Trust die Mikrosegmentierung. Sie besteht darin, dass sämtliche Netzkommunikation jeder wertvollen Ressource auf das erforderliche Minimum beschränkt wird.

Das folgende Szenario verdeutlicht den Ansatz:

• Ein berechtigtes Endgerät mit einer bestimmten IP-Adresse greift über ein bestimmtes Protokoll (TCP oder UDP) und von einer bestimmten Portnummer aus auf eine Applikation zu.
• Der Zugriff erfolgt über eine Firewall mit einer Verbindungstabelle (Connection Table), manchmal auch Sitzungstabelle genannt (Session Table).
• Der Server als Hüter der Werte (Daten, Ressourcen) hat eine bestimmte IP-Adresse und stellt für berechtigte Endgeräte den Zugriff über ein bestimmtes Protokoll auf eine bestimmte Portnummer bereit.

Somit kommen wir zu einem 5-Tupel (stilistisch sauberer, aber hier ungebräuchlich: Quintupel). Fünf Angaben kennzeichnen einen Datenstrom eindeutig: Sender-IP-Adresse, Ziel-IP-Adresse, Protokoll, Sender-Port, Ziel-Port. Mittels dieser Angaben kann über jeden Datenstrom in der Verbindungstabelle der Firewall Buch geführt werden. Passt ein Datenpaket zum Schema eines erlaubten Datenstroms, wird es durchgelassen, ansonsten nicht.

Die ersten Firewalls, die wenige Jahre nach meinem Berufseinstieg auf Unix-Basis entstanden, waren bereits in der Lage, die Pakete anhand des 5-Tupels nach Übereinstimmung mit erlaubten Schemata zu filtern, daher die Bezeichnung Paketfilter. Die einfachen Paketfilter waren wie das Internet Protocol (IP) statuslos (stateless). Das bedeutet: Jedes IP-Paket wird einzeln betrachtet, geprüft und als legitim oder illegitim eingestuft.

Die meisten Applikationen nutzen das Transmission Control Protocol (TCP), das im Gegensatz zu IP statusbehaftet (stateful) funktioniert. In der Telekommunikation wurde bereits vor der Erfindung des Internets von verbindungslosen und verbindungsorientierten Diensten gesprochen. IP gilt als verbindungslos, TCP als verbindungsorientiert. Jede TCP-Verbindung beginnt mit einem expliziten Verbindungsaufbau in drei Schritten, welche die sogenannten Sequenznummern auf Client und Server synchronisieren. Der Client startet mit einem SYN-Paket, das er an den Server richtet (SYN = synchronize sequence numbers). Der Server antwortet im zweiten Schritt mit der Angabe der eigenen Sequenznummer (SYN) und der Bestätigung des Empfangs des ersten Client-Pakets (Acknowledgement, ACK). Im dritten Schritt bestätigt der Client den Empfang des ersten Pakets des Servers (= zweites Paket im Vorgang). Der sogenannte Three-Way-Handshake ist somit komplett. Die TCP-Verbindung ist aufgebaut.

Der TCP-Verbindungsaufbau kann von der zwischen Client und Server vermittelnden Firewall erkannt werden. Die Firewall kann erstens dafür sorgen, dass Verbindungen nur in einer Richtung aufgebaut werden können. Zweitens kann die Firewall bei jedem Paket prüfen, ob es zu einer bereits legitim aufgebauten TCP-Verbindung passt, d.h. zu einem Eintrag in der Verbindungstabelle der Firewall. Diese Prüfung geht über die ursprüngliche IP-Paketfilterung hinaus und stellt jedes Paket in den Kontext einer Verbindung. Der Status der Verbindung wird dabei berücksichtigt. Die Firewall arbeitet statusorientiert (stateful), daher die Bezeichnung „stateful inspection“. Beginnend ungefähr Mitte der 1990er Jahre wurden statuslose Paketfilter zunehmend durch statusbewusste Firewalls ersetzt.

Damit kann ein Protokoll, das von Hause aus verbindungslos ist, nicht als Firewall-tauglich bezeichnet werden. Das verbindungslose User Datagram Protocol (UDP) wird beispielsweise für Audio und Video (AV) in Echtzeit verwendet, weil TCP immer die korrekte Paketfolge herstellt, bevor es die Pakete an die Applikation übergibt. Bei Echtzeit-AV kommt es jedoch weniger auf die reihenfolgengetreue Übermittlung ALLER Pakete als auf die Maximierung der Anzahl der übermittelten Pakete binnen möglichst kurzer Zeit an. Denn erstens können Paketverluste bei der Dekodierung des Paketstroms durch einige Tricks kompensiert werden (auf diese Tricks kommt es hier nicht an), und zweitens nehmen Menschen bei der audiovisuellen Kommunikation Informationsverluste bis zu einem bestimmten Grad nicht wahr oder stören sich nicht daran.

Während TCP grundsätzlich anders als UDP Firewall-tauglich ist, gibt es TCP-Anwendungen, die nicht Firewall-tauglich sind, nämlich Applikationen, die eine TCP-Verbindung aufbauen, diese aber nur sporadisch nutzen. Firewalls wenden in der Regel Housekeeping an, d.h. sie räumen in ihrer Verbindungstabelle auf. Wird eine Verbindung längere Zeit nicht genutzt, löscht die Firewall den entsprechenden Eintrag in der eigenen Verbindungstabelle. Die Folge ist, dass die Firewall fortan Pakete im Rahmen der aus Sicht von Client und Server noch bestehenden Verbindung blockiert. Die Anwendung kann schlau oder weniger schlau reagieren; sie kann selbsttätig die Verbindung neu aufbauen, oder ratlos bleiben und eine Fehlermeldung generieren.

Gibt es Abhilfen bei Applikationen, die nicht oder weniger Firewall-tauglich sind? In der Regel kann diese Frage bejaht werden:

• Echtzeit-AV-Übertragung ist meistens mit einer sogenannten Signalisierung verbunden, d.h. einem Protokoll, das den Aufbau einer Sitzung (Session) steuert. Ein Beispiel ist das Session Initiation Protocol (SIP). Ein Session Border Controller (SBC) kann den Aufbau einer SIP-basierenden Kommunikation zwischen verschiedenen Netzsegmenten vermitteln. Der SBC nimmt selbst an der SIP-Signalisierung teil und öffnet die UDP-Ports, die für die Kommunikation benötigt werden. Genauso schließt er auch die UDP-Ports, wenn sie nicht mehr benötigt werden.
• Firewalls sollten auch mit weniger schlau programmierten TCP-Anwendungen umgehen können. So kann die Firewall erstens im eigenen Log protokollieren, warum genau ein Paket verworfen wurde. Wenn der Log-Eintrag besagt, dass zu einem Paket nicht die passende Verbindung gefunden wurde, kann der Administrator reagieren und zum Beispiel in der eine Applikation unterstützenden Firewall-Regel bestimmen, dass der Eintrag in der Verbindungstabelle der Firewall länger ungelöscht bleibt oder sogar nie gelöscht wird.