IPv6/Paketfilter/Netfilter

7.1 Einführung in Netfilter

Als Paketfilter werden wir das Netfilter -Framework des Linux Kernels verwenden.

Technisch gesehen befindet sich der Paketfilter damit im sogenannten Kernelspace, was erhebliche Geschwindigkeitsvorteile mit sich bringt.
Gesteuert wird Netfilter von Kommandos aus dem Userspace, zum Beispiel aus einem Terminal heraus.1 Im Kernelspace, also dort wo die Pakete über Interfaces das System betreten, befinden sich auch

1

Als Kernelspace wird der Teil des Betriebssystems bezeichnet, in dem der Kernel, und damit auch die Treiber, laufen.

Er ist aus dem Userspace, wo die Programme der Nutzer laufen, nicht ohne Umwege erreichbar.

Architektur

Abbildung 7.1 Netfilter im Kernelspace, ip6tables im Userspace $ip6tables Userspace NetfilterRegeln sixxs eth1 Kernelspace IPv6

Internet internal die Regeln des Paketfilters.

Sie können deshalb direkt angewendet werden.

ip6tables Eines der Kommandos zum Verwalten und Anzeigen der Netfilter-Regeln ist ip6tables.

Es lädt die Netfilter-Regeln aus dem Kernel herunter, modifiziert sie entsprechend den mitgegebenen Parametern, und lädt sie dann wieder in den Kernel hinein.

Der Ablauf ist in Abbildung 7.1 dargestellt. Regeln Wenn man Pakete filtert, möchte man bestimmte Gruppen von Paketen erkennen, um ihnen eine definierte Behandlung zukommen zu lassen.

Und sei es nur, um sie wegen ihrer Gefährlichkeit oder Unerwünschtheit zu verwerfen.
Derartige Pakete erkennt Netfilter anhand von Regeln.
In einer Regeln sind die Kriterien festgelegt, denen ein Paket genügen muss, um von der Regel erfasst zu werden.

Chains Gruppen von Regeln organisiert Netfilter in Regelketten, den sogenannten Chains.

Dabei gibt es eingebaute Chains, beispielsweise INPUT, FORWARD und OUTPUT, aber auch nutzerdefinierte Chains.

Tabellen Die Chains wiederum werden in Tabellen zusammengefasst, daher auch der Name ip6tables des entsprechenden Werkzeugs.

Sofern nicht anders angegeben, nutzen wir die Tabelle filter.
Bei der Nutzung von ip6tables wird diese Tabelle automatisch gewählt, darum verzichten wir bei der Definition von Regeln oft auf die explizite Angabe des Tabellennamens.

Chains der filter-Tabelle Pakete die durch die filter-Tabelle laufen, passieren eine der bereits vordefinierten Chains.

Das betrifft sowohl Pakete für die das System nur ein Zwischenstopp ist, als auch Pakete

INPUT FORWARD Lokaler Prozess OUTPUT Netfilter

Abbildung 7.2 Die NetfilterChains der Tabelle filter die an das System selbst gerichtet sind oder von dort stammen.

Pakete für das System landen dann üblicherweise in einem lokalen Prozess oder einem Socket.
Darunter können wir uns einen Dienst vorstellen, zum Beispiel einen DNSoder Webserver.
Die eingebauten Chains der filter-Tabelle sind:

INPUT Pakete die für einen lokalen Prozess oder Socket bestimmt sind, gehen durch diese Chain. OUTPUT Pakete die von einem lokalen Prozess oder Socket kommen, werden durch diese Chain geschickt. FORWARD Pakete die auf einem Interface eintreffen, und das System sogleich wieder verlassen, passieren diese Chain. Das trifft auch auf Pakete zu, die das System auf dem gleichen Interface verlassen, auf dem sie gekommen sind. Die Chains der filter-Tabelle sind in auch Abbildung 7.2 dargestellt. Die filter-Tabelle wird nur dazu genutzt, Pakete zu erkennen und über ihr Schicksal zu entscheiden.

In der filter-Tabelle können Pakete nicht verändert werden.

Deshalb sei hier auch die Tabelle mangle erwähnt.

Sie erlaubt nämlich die Modifikation von Paketen.
Damit stellt sie ein sehr mächtiges Werkzeug im Netfilter-Framework dar.
Unter IPv4

nutzt man die mangle-Tabelle zur Implementierung von SNAT und PAT. Chains der mangle-Tabelle

Abbildung 7.3 Nutzerdefinierte Chain innerhalb einer Netfilter-Chain Netfilter-Chain Nutzerdefinierte Chain RegelRegel1 2 Regel A Regel B Regel C Regel 3 Zusätzlich zur INPUT-, OUTPUT- und FORWARD-Chain enthält die mangle-Tabelle auch folgende Chains: PREROUTING Hier gehen alle Pakete durch, die über ein Interface eingetroffen sind.

Diese können in der Chain verändert werden, noch bevor die Routingentscheidung getroffen wurde.

POSTROUTING Kurz bevor Pakete das System verlassen, werden sie durch diese Chain geschickt.

Auch hier ist wieder eine Veränderung möglich.
Möchte man SNAT nutzen, wäre dies der richtige Ort um die Quelladresse zu manipulieren.

Beispiel Abbildung 7.3 zeigt die Regeln 1 bis 3 einer Netfilter-Chain und die Regeln A bis C einer nutzerdefinierten Chain. Die Position jeder einzelnen Regel oder Chain ist entscheidend für die Leistungsfähigkeit und die Sicherheit des Paketfilters. Regeln werden stets in der Reihenfolge ihres Auftretens in einer Tabelle abgearbeitet.

Die nutzerdefinierte Chain aus der Abbildung 7.3 ist zwischen den Regeln 2 und 3 der NetfilterChain positioniert, somit lautet die endgültige Reihenfolge der Regeln:

• Regel 1 • Regel 2 • Regel A • Regel B • Regel C • Regel 3

Zu filternde Pakete werden gegen die Regeln geprüft, bis eine der Regeln zutrifft.

Hat eine Regel dem Paket ein abschließendes Schicksal bescheinigt, werden die folgenden Regeln nicht mehr durchlaufen.
Das Verfahren wird auch First Match genannt.
Durch die geschickte Positionierung der Regeln lässt sich ein effizienter Paketfilter erstellen.

Nachdem ein Paket eine Chain der filter-Tabelle durchlaufen hat, sollte sein weiteres Schicksal feststehen.

Nun kann es vorkommen, dass keine der Regeln in der Chain auf das Paket angewendet werden konnte.
Auch besteht nicht die Verpflichtung, überhaupt Regeln in eine Chain einzupflegen.
Und so tritt gelegentlich der Fall ein, dass die sogenannte Default Policy der Chain greifen muss.
Die Default Policy einer Chain legt fest, wie mit Paketen zu verfahren ist, die am Ende der Chain angekommen sind.

Die typischen Default Policies sind: ACCEPT Das Paket wird zugelassen. DROP Das Paket wird verworfen. Neben den Kriterien, nach denen ein Paket erkannt wird, definieren die Regeln auch, was bei einem Treffer passieren soll. Im Netfilter-Jargon spricht man von einem Target, und meint damit das weitere Schicksal des betroffenen Paketes.

Zwei der eingebauten Targets, und zwar ACCEPT und DROP, haben wir bei den Default Policies schon kennengelernt.
Es existieren noch weitere Targets:

First Match Default Policies Targets RETURN Die aktuelle Chain wird verlassen.

Von einer nutzerdefinierte Chain springt man hiermit zurück in die Netfilter-Chain.
Befindet sich die Regel, welche dieses Target nutzt, bereits in einer Netfilter-Chain, dann wird die Default Policy angewendet.

REJECT Das Paket wird verworfen, die Quelle erhält eine Fehlermeldung.

Die Fehlermeldung wird als ICMPv6-Nachricht

Nutzerdefinierte Chains als Targets Connection Tracking LOG TOS QUEUE,formuliert.

Eine Ausnahme kann bei TCP-Paketen konfiguriert werden, dort ist auch ein Verbindungsabbruch mit TCP-Reset einstellbar.

Der Kernel schreibt eine Zeile, mit den wichtigsten Header-Informationen des Paketes, in das Systemlog.

Dies ist ein besonderes Target, denn es beendet das Filtern nicht.
Der Filter fährt bei der nächsten Regel fort.

Das Feld Traffic Class im IPv6-Header wird mit einem zu definierenden Wert überschrieben.

Da hier eine Veränderung des Paketes stattfindet, ist dieses Target nur in der mangle-Tabelle erlaubt.

NFQUEUE Das Paket wird in den Userspace befördert, wo es von einem Prozess verarbeitet werden kann.

Das Target wird genutzt um aufwändige Analysen durchzuführen, die im Kernelspace wegen ihrer Komplexität nicht gut aufgehoben wären.

Alternativ kann als Target auch eine nutzerdefinierte Chain angegeben werden.

Die dadurch gewonnene Flexibilität ist enorm.
So kann man verdächtige Pakete durch eine Chain mit besonders strengen Regeln schicken, oder vertraute Adressbereiche an langsamen Chains vorbeischleusen.
Wir werden diese Funktion später nutzen, um potentiell gefährliche Protokolle in speziellen Chains zu entschärfen.

Das Netfilter-Framework unterstützt Connection Tracking, ein Feature mit dem sich Stateful Packet Inspection (SPI) realisieren lässt.

Das heißt, wir können unterschiedliche Regeln auf Pakete anwenden, abhängig davon, ob sie eine neue oder eine bestehende Verbindung repräsentieren.
Damit wird ein Kompromiss möglich, der es erlaubt neue Verbindungen mit aufwändigen Regeln zu bearbeiten.
Trotzdem werden bestehende Verbindungen nicht negativ beeinflusst, da wir die entsprechenden Pakete zügig passieren lassen können. Über jede Verbindung wird vom Connection Tracking anhand eines Datensatzes Buch geführt.
Dieser besteht aus dem Netzwerkprotokoll (IPv6), der Quell- und Zieladresse, dem Upper

Layer Protocol und zusätzlichen Daten des Upper Layer Protocol. Die zusätzlichen Daten des Upper Layer Protocols sind bei TCP die Portnummern von Quelle und Ziel.

Gleichzeitig bietet die TCP-Statemachine Netfilter weitere Anhaltspunkte für das Connection Tracking.2 Bei UDP stehen nur die Portnummern zur Verfügung, da es sich um ein verbindungsloses Protokoll handelt.

Wenn eine Verbindung keine zusätzlichen Daten bereitstellt, wird eine Pseudo-Verbindung angenommen.

Sie basiert auf den wenigen vorhandenen Daten des Datensatzes der Verbindung.
Dann arbeitet die Plausibilitätsprüfung für solche Verbindungen mit vordefinierten Ablaufzeiten für Pakete.
Bleiben passende Pakete während eines gewissen Zeitraums aus, gilt die Verbindung als beendet.

Das Connection Tracking des Netfilter-Frameworks unterscheidet zwischen zugehörigen und verwandten Paketen.

Pakete die einer Verbindung zugehörig sind, dienen dem Austausch von Daten in der Verbindung.
Es handelt sich um jene Pakete, die zwischen den beteiligten Nodes hin und her wandern.

Verwandte Pakete hingegen sind jene Pakete, die zwar einer Verbindung zugeordnet werden können, dieser aber nicht direkt angehören.

Damit sind hauptsächlich ICMPv6-Fehlermeldungen gemeint, ohne die eine Verbindung häufig nicht zustande kommen kann.
Verwandte Pakete sind daher ebenso wichtig für eine Verbindung wie die zugehörigen Pakete.

Die verschiedenen Zustände einer Verbindung lassen sich bequem in den Netfilter-Regeln abfragen.

Ein Paket kann also nicht nur nach seiner Herkunft, seinen Eigenschaften und seinen Header-Feldern bewertet werden, sondern auch danach, in welchem Zusammenhang es zu bereits behandelten Paketen steht.
Die wichtigsten Zustände lauten:

2

Die TCP-Statemachine liefert detaillierte Informationen über den aktuellen Zustand einer TCP-Verbindung.

Gerade bei Verbindungen, welche noch nicht vollständig ausgehandelt sind, erleichtern diese Informationen die Bewertung der Plausibilität eintreffender Pakete.

Connection Tracking mit TCP und UDP Connection Tracking mit anderen Protokollen Verwandte Pakete Zustände im Connection Tracking

Abbildung 7.4 Beispiel für die Zustände des Connection Trackings Host A Router 1 3 NEW UDP-Datagramm ESTABLISHED UDP-Datagramm RELATED ICMPv6 Parameter Problem Host2 B Beispiel Connection Tracking NEW Mit diesem Paket würde eine neue Verbindung im Connection Tracking geführt werden.

Es repräsentiert die erste Kontaktaufnahme durch, oder mit, einem anderen Node.

ESTABLISHED Das Paket gehört zu einer bestehenden Verbindung. RELATED Das Paket ist mit einer bestehenden Verbindung verwandt und für das Funktionieren dieser wahrscheinlich wichtig.

Das Auftreten des Paketes wurde vom Connection Tracking bereits erwartet.

INVALID Das Paket ist ungültig.

Es wurde entweder nicht erwartet, oder es passt nicht zu der Verbindung, in der es auftrat.
Falsch gesetzte Flags in TCP-Segmenten führen ebenfalls zu diesem Zustand.

UNTRACKED Das Paket wird vom Connection Tracking ignoriert.

Diesen Zustand muss der Administrator des Paketfilters manuell vergeben, es findet nur in Sonderfällen oder bei der Fehlersuche Anwendung.

Das Beispiel aus Abbildung 7.4 verdeutlicht die Zustände des Connection Trackings.

Host A und Host B kommunizieren über den gemeinsamen Router.
Auf dem Router läuft ein Linux-Kernel mit Netfilter.
Das erste Paket, das der Router sieht, ist ein UDP-Datagramm von Host A an Host B.
Da das Connection Tracking auf dem Router dieses Paket keiner bestehenden

Verbindung zuordnen kann, erstellt er eine neue Pseudo-Verbindung.

Das Paket hat den Zustand NEW.
Kurz darauf trifft ein Antwortpaket von Host B ein.
Das Connection Tracking kann das Paket der eben erstellten Verbindung zuordnen und versieht das Paket daher mit dem Zustand ESTABLISHED.

Leider konnte der Host A das Paket nicht verarbeiten, der Grund könnte zum Beispiel ein unbekannter Parameter in einem Extension Header gewesen sein.

Der Host A antwortet mit der ICMPv6-Fehlermeldung Parameter Problem.
Auf dem Router erkennt das Connection Tracking, dass es sich hierbei um ein verwandtes Paket handelt und ordnet es der bestehenden Verbindung zu.
Es erhält den Zustand RELATED.