Aufgaben eines Paketfilters

Ich mache mir zunächst die Aufgaben eines Paketfilters klar, um dann seine Bestandteile unter diesen Aspekten - den Aufgaben - zu betrachten und so besser zu verstehen.

Die Hauptaufgabe eines Paketfilters ist das Filtern des Datenverkehrs an Hand von vorgegebenen Regeln für die im Netz vorkommenden Protokolle. Dabei trifft der Paketfilter seine Entscheidungen normalerweise basierend auf den Kopfdaten der Datagramme und nicht ihrem Inhalt. Eine Ausnahme bilden einige Connection-Tracking-Module, wie zum Beispiel für FTP, die aus dem Datenstrom der Verbindung zu Port 21 die Ports der zugehörigen Datenverbindungen ermitteln.

An den Grenzen von Netzwerken kommt oft zusätzlich noch die Adressübersetzung, das heißt das Ändern von Quell- und / oder Zieladresse sowie der Ports bei TCP und UDP als Aufgabe dazu. Diese Umsetzung findet sich vorwiegend bei IPv4-Netzen, weil bei diesen die Anzahl der frei verfügbaren global eindeutigen Adressen seit langem nicht mehr den Bedarf decken kann und daher Adressen mehrfach verwendet werden.

Die Adressübersetzung dient zwei Zielen: das eine ist das Verbergen ganzer Netze hinter einzelnen Adressen (Masquerading), das andere das Ermöglichen der Kommunikation von Rechnern in verschiedenen Netzen, die den gleichen Präfix verwenden.

Masquerading finde ich häufig bei SOHO-Umgebungen, die von ISP eine IP-Adresse bekommen haben und hinter dieser verschiedene Endgeräte verbergen, die alle eine Verbindung in das Internet benötigen. Da mehrere interne Adressen auf eine externe Adresse gebündelt werden, geht es nicht ohne Änderung der TCP- und UDP-Ports ab. Von der externen Seite sind die internen Rechner nicht direkt adressierbar, da von außen nur eine IP-Adresse sichtbar ist.

Ein Beispiel für die Adressübersetzung ganzer Netzwerk-Präfixe ist ein Zusammenschluß zweier Netze, die bisher die gleichen privaten Netzwerkadressen verwendet haben. Da ich hier für die Umsetzung mit gleich großen Netzwerk-Präfixen arbeiten kann, müssen die Ports nicht zwingend geändert werden und außerdem sind alle internen Rechner von extern - über die umgesetzte Adresse - direkt adressierbar.

Kommen wir zurück auf das Filtern des Datenverkehrs, das dem Schutz vor Angreifern dient. Ich kann einzelnen Geräten eingeschränkten Zugang zu anderen Netzen gewähren oder Port-Scans verhindern, mit Port-Knocking auch für verfügbare Dienste. Unter bestimmten Voraussetzungen kann ich mit Rate-Limiting DoS-Angriffe entschärfen und gefährliche Datenpakete blockieren.

Formal dient die Filterung des Datenverkehrs der Durchsetzung einer Policy, welche den erlaubten und den verbotenen Datenverkehr in einem Netzwerk definiert.

Natürlich beschreibt eine Policy nicht direkt, welcher Datenverkehr erlaubt oder verboten ist. Dann müsste sie bei jeder Änderung im Netzwerk angepasst werden. Stattdessen drückt die Policy abstrakt die Ziele aus, von denen ausgehend ich, mit Kenntnis der im Netz eingesetzten Adressen und Protokolle, Regeln für den Paketfilter ableiten muss.

Eine weitere Aufgabe eines Paketfilters ist der Schutz vor unerwünschtem Datenabfluss. Natürlich kann ein Paketfilter nicht davor schützen, dass Daten durch Ausnutzen der erlaubten Verbindungen das Netz verlassen. Er kann jedoch den Datenverkehr in Bahnen lenken, auf denen ich mit anderen Mitteln dem Abfluss von Daten entgegenwirken kann.

Der Paketfilter hat dabei lediglich unterstützende Funktion, indem er den Datenverkehr umleitet zu einem Proxy, welcher den Datenverkehr bewertet und geeignete Entscheidungen trifft.

Neben dem absichtlichen Datenabfluss kann mich ein Paketfilter auch vor unbeabsichtigter, versehentlicher Preisgabe von sensiblen Informationen schützen. Dazu muss ich die Schwächen der in meinem Netz verwendeten Protokolle kennen und in manchen Fällen die Reichweite dieser Protokolle einschränken. So sendet beispielsweise MS Windows unter Umständen den NTLM-Hash des angemeldeten Nutzers an beliebige SMB-Server. Diese Information genügt, um sich in Windows-Netzen auszuweisen und Dienste zu nutzen. Um mich vor der versehentlichen Preisgabe dieser Information zu schützen, muss ich die Ports 139 und 445 für UDP und TCP abgehend sperren, auch wenn ich auf Grund einer permissiven Policy abgehenden Datenverkehr eigentlich erlauben würde.

Schließlich kann der Paketfilter noch die Authentisierung und Authorisierung von Netzwerk-Geräten unterstützen, indem er HTTP-Anfragen zunächst zu einem Captive Portal umleitet und den Datenverkehr erst nach Anmeldung am Portal freigibt.

Chance - Risiko - Policy - Firewall - Paketfilter

Bevor ich mich weiter in Details verliere, will ich kurz auf ein paar Begriffe und Zusammenhänge eingehen.

Vom wirtschaftlichen Standpunkt ausgehend, wäge ich die Chancen eines Systems (den Gewinn, den ich damit erziele) ab gegen die Risiken (die Verluste, die ich damit erleide). Ist das betrachtete System die IT-Infrastruktur einer Firma, wende ich mich wegen dieser Zahlen an die Geschäftsführung. Ist es mein persönliches Netz zu Hause, muss ich die Zahlen selbst bestimmen. Konkret geht es um den Nutzen oder Gewinn, den ich mit Hilfe des betrachteten Systems erreiche und die Verluste, die bei der Benutzung des Systems entstehen. Das Ermitteln dieser Zahlen benötigt betriebswirtschaftliche Kenntnisse.

Mit einer Security Policy (Sicherheitsrichtlinie) kann ich nur Verluste reduzieren. Die ermittelten finanziellen Werte geben den finanziellen Rahmen vor, innerhalb dessen sich meine Security Policy und die von ihr abgeleiteten Maßnahmen bewegen müssen, damit ich mich nicht langfristig zugrunde richte. So kann ich den Aufwand schätzen, den ich sinnvollerweise betreibe, um das System zu schützen.

Als nächstes ermittle ich die Schwachstellen des Systems und wie diese ausgenutzt werden können. Davon ausgehend lege ich Richtlinien - eine Policy - fest, die das Ausnutzen dieser Schwachstellen im besten Fall verhindert, zumindest aber erschwert. Das heißt, die Policy legt dem Gesamtsystem Beschränkungen auf, die einerseits die Ausnutzung von vorhandenen Schwachstellen verhindern, andererseits aber immer noch die Nutzung des Systems für seinen eigentlichen Zweck zulassen sollen. Hier muss ich eine Balance finden, wobei mir der oben erwähnte finanzielle Rahmen hilft.

Um die Policy durchzusetzen, kann ich - neben anderen Maßnahmen - für Rechnernetze eine Firewall verwenden. Diese besteht aus verschiedenen Komponenten: Paketfiltern, die den Datenverkehr auf den unteren Ebenen des OSI-Modells regulieren, Application Gateways, die sich um die oberen Ebenen des OSI-Modells kümmern und Intrusion Detection Systeme, die überwachen, ob die Policy eingehalten wird. Intrusion Prevention Systeme schließlich können bei einer erkannten Verletzung der Policy weitere Maßnahmen einleiten. In diesem Buch geht es vor allem um Paketfilter.

Die Policy sollte als erstes festlegen, ob ich grundsätzlich alles erlaube und nur bestimmten Datenverkehr verbiete - ein permissiver Ansatz - oder ob ich nur bestimmten Datenverkehr erlaube und alles andere verbiete - ein prohibitiver Ansatz. Die Antwort darauf kann in verschiedenen Bereichen eines Netzwerks unterschiedlich ausfallen. Anschließend sollte die Policy den erlaubten und / oder den verbotenen Datenverkehr beschreiben.

Habe ich meine Policy, ermittle ich im nächsten Schritt die Protokolle und Netzwerkadressen, die ich zulassen oder sperren muss und die Art von Application Gateways, die ich einsetzen muss, um die Ziele der Policy zu erreichen.

OSI Modell

Um den Paketfilter und die Application Gateways richtig einzuordnen, greife ich auf das Open Systems Interconnection (OSI) Modell zurück. Dieses Modell dient seit vielen Jahren als Referenzmodell für Netzwerkprotokolle.

Es ist als Schichtenmodell ausgeführt, bei dem jede Schicht genau definierte Aufgaben hat, die Dienste der darunterliegenden nutzt und seine Dienste den darüber liegenden zur Verfügung stellt. Es gibt in diesem Modell die folgenden sieben Schichten:

Reale Protokolle können mehrere Schichten des OSI Modells abbilden, zum Beispiel:

• Ethernet die Schichten 1 und 2
• IP, ICMP, IGMP die Schicht 3
• TCP, UDP die Schicht 4
• HTTP, SMTP die Schichten 5, 6 und 7

Paketfilter arbeiten auf den OSI Schichten 1 bis 4. Habe ich verschlüsselten Datenverkehr, kann der Paketfilter nur bis zur Schicht 3, den IP-Adressen, arbeiten.

Für Protokolle der Ebenen 5 bis 7 muss ich entweder auf Application Gateways setzen und mit Paketfiltern erzwingen, dass diese genutzt werden. Oder ich untersuche den Datenverkehr mittels Deep Packet Inspection (DPI) und steuere mit den gewonnenen Erkenntnissen den Paketfilter und damit den Datenverkehr.

Reaktive Schutzmaßnahmen

Eine Möglichkeit, einen Server mittels Paketfilter zu schützen, besteht darin, die Log-Nachrichten des Servers auszuwerten und unerwünschten Datenverkehr zu unterbinden.

Fail2ban ist eine Software, die so etwas macht: sie wertet die Systemprotokolle aus und sperrt nach einer bestimmten Anzahl von Fehlversuchen die IP-Adresse über den Paketfilter. Damit kann ich Brute-Force-Attacken auf Login-Dienste verlangsamen und so unbrauchbar machen.

Das funktioniert jedoch nur, wenn der fail2ban-Dämon die benötigten Log-Nachrichten erhält und der Datenstrom über diesen Rechner läuft. Für lokale Dienste ist das leicht zu realisieren.

Auf einem separaten Paketfilter benötige ich dafür ein komplexes System, das die Log-Nachrichten zentral auswertet und die Paketfilter steuert.

Port-Knocking und TCP-Stealth

Eine weitere Möglichkeit, bei der ein Paketfilter einen Server schützt, ist Port-Knocking. Bei diesem Verfahren unterbindet der Paketfilter zunächst jeglichen Datenverkehr. Erst wenn die Software auf dem Server, die den Datenverkehr beobachtet, eine bestimmte Signatur in den Datenpaketen erkennt, veranlasst sie den Paketfilter, den Datenverkehr vom Sender der Signatur zuzulassen.

Damit lassen sich Zugänge zu einem System so verbergen, dass ein Angreifer den kompletten Datenverkehr des Systems beobachten und analysieren müsste, um den geschützten Dienst zu finden und die Signatur zu ermitteln. Dieses Verfahren ist sicherer als das nachträgliche Sperren bei Fehlversuchen, aber nur für einen begrenzten Personenkreis geeignet, dem die Signatur bekannt sein und die Software zur ihrer Erzeugung zur Verfügung stehen muss.

TCP-Stealth funktioniert, oberflächlich betrachtet, ähnlich. Es ist aber direkt im TCP-Stack implementiert und arbeitet ohne den Paketfilter. Die Signatur befindet sich hier direkt in den Datagrammen, welche die TCP-Verbindung aufbauen. Damit ist TCP-Stealth noch schwerer zu entdecken, als Port-Knocking, welches für die Signatur zusätzliche Datagramme verwendet, die nichts mit der eigentlichen Verbindungsaufnahme zu tun haben und dadurch einem aufmerksamen Beobachter auffallen können. In [ixGK2014] und [ctKGEAPM2014] finden sich nähere Informationen dazu.