Netfilter

Netfilter
Basisdaten
Hauptentwickler	Netfilter-Projekt
Betriebssystem	Linux
Programmiersprache	C
Kategorie	Linux-Kernel-Modul: Paketfilter NAT Firewall
Lizenz	GNU General Public License
http://www.netfilter.org/

Netfilter ist ein Softwareprojekt, das unter anderem Paketfilter, Network Address Translation und weitere für Firewalls relevante Werkzeuge für den Linux-Kernel bereitstellt. Außerdem bezeichnet Netfilter die Softwareschicht innerhalb des Linux-Kernels, die beim Empfang und Senden von Netzwerkpaketen aufgerufen wird. Diese leitet lediglich die Ausführung von weiteren Modulen wie eben Paketfilter ein. Diese Module können dann Pakete abfangen und manipulieren.

Beziehung einiger Netfilter-Komponenten zueinander

Geschichte

Das Netfilter/iptables-Projekt wurde 1998 von Rusty Russell ins Leben gerufen, der außerdem der Autor des Vorgängers ipchains war. Mit Wachstum des Projektes gründete er 1999 das Netfilter-Coreteam (oder einfach Coreteam; Hauptentwicklerteam). Die dort produzierte Software – von hier an Netfilter genannt – ist unter der GNU General Public License (GPL) lizenziert und wurde im März 2000 in den Linux-Kernel, Version 2.3, integriert. Im August 2003 wurde Harald Welte Vorsitzender des Kernteams. Im April 2004 – nach intensiver Suche seitens des Netfilter-Projekts in kommerziellen Produkten, die die Software vertrieben, ohne sich an die Lizenzbedingungen zu halten – erreichte Welte in Deutschland eine historische gerichtliche Verfügung gegen Sitecom Deutschland. Im September 2007 wurde Patrick McHardy, der die Entwicklung bereits in den vergangenen Jahren leitete, neuer Vorsitzender des Kernteams. Seit 2013 ist Pablo Neira Ayuso der Vorsitzende des Kernteams. Im Juni 2016 wurde Patrick McHardy wegen umstrittener Klagen gegen Verletzungen der GPL aus dem Kernteam ausgeschlossen.

iptables vorausgehend waren die damals prädominanten Firewallpakete ipchains in Linux 2.2 und ipfwadm in Linux 2.0, welches Ähnlichkeiten zu BSDs ipfw besaß. Sowohl ipchains als auch ipfwadm griffen direkt in den Netzwerk-Code ein, um Pakete zu manipulieren, da es bis dato noch keine generische Schnittstelle wie Netfilter gab.

Während ipchains und ipfwadm Paketfilterung und NAT kombinierten (insbesondere drei gewisse Sorten von NAT, Masqueradieren, Portweiterleitung und Umleitung), sind Paketoperationen in Netfilter in kleinere Module aufgeteilt – siehe mehr dazu unten. Jede Operation hängt sich bei Netfilter an unterschiedlichen Position ein, um Pakete zu bearbeiten. Die Connection-Tracking- und NAT-Subsysteme sind bei Netfilter genereller gehalten und mächtiger als die abgestumpften Versionen bei ipchains und ipfwadm.

iptables

→ Hauptartikel: iptables

Die Kernelmodule ip_tables, ip6_tables, arp_tables (Unterstriche gehören zum Namen) und ebtables stellen eine Hauptkomponente, und somit “Nutzer” des Netfilter-Hooksystems dar. Sie stellen ein tabellen-basiertes System zur Definition von Firewallregeln auf, die die Filterung oder Manipulation ermöglichen. Die Tabellen können mittels der Userspaceprogramme iptables, ip6tables, arptables bzw. ebtables administriert werden.

Jede Tabelle ist genaugenommen ein eigener Hook, und natürlich wurde jede auch für einen gewissen Zweck eingeführt. Netfilter betrifft dies insofern, als Tabellen in einer gewissen Reihenfolge abgearbeitet werden. Ansonsten werden alle Tabellen an die gleiche Unterfunktion weitergegeben, die dann über jede Regel läuft und diese ausführt.

Ketten in dieser Hinsicht entsprechen von wo aus der Netfilter-Stapel aufgerufen wurde, also z. B. Paketempfang (PREROUTING), lokal zugestellt (INPUT), weitergeleitet (FORWARD), lokal ausgegeben (OUTPUT), und Paketversand (POSTROUTING). Netfilter-Module, die keine Tabellen bereitstellen (s. u.) inspizieren ggf. den Ursprung, um somit zu entscheiden, welche Operationen durchgeführt werden sollen.

Module:

iptable_raw

registriert, wenn es geladen wird, einen Hook, der vor jedem anderen Netfilter-Hook aufgerufen wird. Es macht darüber hinaus eine Tabelle namens raw verfügbar, in der Pakete gefiltert werden können, bevor sie speicherintensivere Operationen wie Connection Tracking erreichen.

iptable_mangle

registriert einen Hook und eine Tabelle namens mangle, die nach Connection Tracking (aber noch vor weiteren Tabellen) durchlaufen wird, sodass Manipulationen an Paketen durchgeführt werden können, die spätere Entscheidungen wie NAT oder den Paketfilter beeinflussen könnten.

iptable_nat

registriert zwei Hooks: DNAT-basierte Transformationen werden vor dem Filter-Hook abgearbeitet, SNAT-basierte Transformationen danach. Die nat-Tabelle die im Zuge dessen verfügbar wird, ist lediglich eine “Konfigurationsdatenbank”, die nur für NAT-Abbildungen gedacht ist, nicht für Paketfilterung.

iptable_filter

registriert die filter-Tabelle, die für allgemeine Paketfilterung eingesetzt wird.

Paket-Defragmentation

Siehe auch: „Datagrammfragmentierung“ im Artikel IPv4

Das nf_defrag_ipv4-Modul wird zur Defragmentierung von IPv4-Paketen eingesetzt, bevor Connection Tracking (im nf_conntrack_ipv4-Modul) diese erhält. Dieser Schritt ist notwendig für die Connection-Tracking- und NAT-“Helfer”-Module (sozusagen “mini-ALGs”) innerhalb des Kernels, die den Datenstrom nicht fragmentübergreifend inspizieren und daher eher mit fragmentfreien Paketen arbeiten.

Die Defragmentierung von IPv6-Paketen ist kein Extramodul, sondern ist in nf_conntrack_ipv6 integriert.

Connection Tracking

Siehe auch: Stateful Packet Inspection

Eine der wichtigen auf Netfilter aufbauenden Funktionen ist Connection Tracking (lit. “Verbindungsverfolgung”, “Verbindungsüberwachung”). Connection Tracking ermöglicht es dem Kernel, die Übersicht über alle logischen Netzwerkverbindungen oder Sitzungen zu behalten, und somit alle Pakete, die eine Verbindung ausmachen, miteinander in Bezug zu stellen. NAT ist auf diese Information angewiesen um alle verwandten Pakete in gleicher Weise zu transformieren. Auch iptables kann diese Information nutzen, um Stateful Packet Inspection (SPI) bereitzustellen.

Der Zustand einer “(Netfilter-)Verbindung” ist jedoch unabhängig von jeglichen Zuständen eines potentiellen Transportprotokolls wie TCP oder SCTP. Ein Grund dafür ist, dass beim bloßen Weiterleiten von Paketen, also keiner lokalen Zustellung, der eigentliche TCP-Abarbeitungsprozess gar nicht zum Zuge kommen muss. Selbst verbindungslose Protokolle wie UDP, IPsec (AH/ESP), GRE und andere Tunnelprotokolle haben einen, wenn auch “pseudo”-, Verbindungszustand. Als Heuristik für solche Protokolle kommt meist ein zeitbasierter Inaktivitäts-Timeout zum Zuge, nach dessen Ablauf eine Netfilter-Verbindung gelöscht, und somit “vergessen” wird.

Jede Netfilter-Verbindung wird eindeutig durch ein (Layer-3-Protokoll, Quelladresse, Zieladresse, Layer-4-Protokoll, Layer-4-Schlüssel) Tupel identifiziert. Der Layer-4-Schlüssel hängt vom verwendeten Transportprotokoll ab; für TCP/UDP sind es die Portnummern, für Tunnel kann es deren Tunnel-ID sein, ist aber sonst einfach nur null, als ob es nicht Teil des Tupels wäre. Um den TCP-Port in jedem Fall auslesen zu können, werden Pakete zwangsläufig defragmentiert.

Netfilter-Verbindungen können mit dem Userspace-Programm conntrack manipuliert werden.

Mittels Connection Tracking kann iptables Einsicht auf Verbindungsparameter wie Zustände (states), Status (statuses) etc. Paketfilterregeln stärker und einfacher handhabbar machen. Die wichtigsten Zustände sind:

NEW

mit dem Paket beginnt eine neue Verbindung

ESTABLISHED

das Paket gehört zu einer bereits bestehenden Verbindung

RELATED

dieser Zustand wird einem Paket zugeordnet, das eine neue Verbindung beginnen würde, wobei die Verbindung aber bereits “erwartet” wurde. Die zuvor genannten mini-ALGs setzen diese Erwartungen auf, z. B. wenn das nf_conntrack_ftp-Modul den “PASV”-Befehl in einer FTP-Verbindung findet.

INVALID

Das Paket wurde als ungültig eingestuft, z. B. wenn es nicht dem TCP-Zustands-Transitionsgraphen folgt.

UNTRACKED

ist ein besonderer Zustand der vom Administrator zugewiesen werden kann, um Connection Tracking für ein gewisses Paket zu umgehen (s. o.: raw-Tabelle)

Ein Beispiel wäre, dass das erste Paket vom Connection Tracking als “new” eingestuft wird. Ein darauffolgendes Antwortpaket wäre dann “established” und ein ICMP-Fehlerpaket wäre “related”. Ließ sich ein ICMP-Fehlerpaket jedoch keiner Verbindung zuordnen, so wäre es als “invalid” klassifiziert.

“Helfer”-Module

Mittels weiterer Plugins lässt sich Connection Tracking soweit erweitern, dass es Kenntnis von Protokollen der Anwendungsschicht erhält und somit versteht, dass zwei oder mehrere Verbindungen “verwandt” (related) sind. Nehme man bspw. das FTP, das zunächst eine Kontrollverbindung öffnet, für jeden Datentransfer jedoch eine weitere separate. Ist das nf_conntrack_ftp-Modul geladen, so wird das erste Paket einer FTP-Datenverbindung als “related” statt “new” eingestuft, da es logischer Teil einer bereits bestehenden Verbindung ist.

Die Helfermodule inspizieren nur jeweils ein Paket auf einmal. Sollten also wichtige Informationen, die für Connection Tracking relevant sind, auf mehrere Pakete, entweder durch IP-Fragmentierung oder TCP-Segmentierung aufgeteilt sein, so können die Module ihrer Aufgabe nicht nachkommen. IP-Fragmentierung wird erzwungene Defragmentierung entgegengesetzt, jedoch wird TCP-Segmentierung bisher nicht behandelt. Im Falle von FTP wurde angenommen, dass eine Segmentation “nahe” Befehlen wie PASV mit üblichen Segmentgrößen normal nicht auftreten würde, und somit wird Segmentierung in Netfilter auch nicht weiter beachtet.

Network Address Translation

Jede Verbindung besitzt “Original-Adressen” (Quelle, Ziel) sowie “Antwort-Adressen”, welche zu Beginn gleich sind. NAT innerhalb Netfilters wird dadurch realisiert, dass die Antwort-Adresse, und wo gewollt, -Ports, entsprechend umgeschrieben werden. Werden Pakete empfangen, so wird deren Tupel auch gegen Antwort-Adressen (und -Ports) abgeglichen. NAT erwartet, dass Pakete fragmentfrei vorliegen. (Falls nötig und möglich werden IPv4-Pakete bei der Ausgabe vom (nicht-Netfilter) IPv4-Stack refragmentiert.)

NAT-Helfermodule

Ähnlich den Helfermodulen für Connection Tracking gibt es NAT-Helfermodule, die neben der Paketinspektion auch noch Manipulation von Originaladressen zu Antwortadressen im Datenstrom umsetzen.

nftables

nftables ist eine von den Netfilter-Entwicklern 2009 gestartete Weiter- bzw. Neuentwicklung der Filtermöglichkeiten im Linux-Kernel. nftables basiert wie iptables, ip6tables, arptables und ebtables auf der Netfilter-Softwareschicht im Kernel. Hauptgrund für den Start des Projektes war und ist es, mehrfachen Code, der durch die getrennten Tools für IPv4-, IPv6-, arp-Protokolle und Bridge-Filterung zu vereinheitlichen. Das neue Filterwerkzeug wurde NFTables genannt, das Kommandozeilenwerkzeug dafür nft. Um diese Ziele zu erreichen, wurde nftables von vornherein als Ablösung von iptables konzipiert. Bedingt durch den Erfolg von iptables und den zahllosen Tools und Firewalls, die darauf basieren, fand das Projekt lange Zeit nicht die Nutzung, die gewünscht war. Deshalb entschlossen sich die Entwickler eine Kompatibilitätsschicht zu iptables einzuführen. Die Filter-Engine wurde als eine Art „virtuelle Maschine“ ausgeführt, die die Filterregeln in einem Bytecode verarbeiten kann. Netfilter lässt prinzipiell mehr Verarbeitungsmöglichkeiten zu als die alten Projekte, hatte aber bis 2016 noch nicht den vollständigen Funktionsumfang für die Ablösung der Altprojekte erreicht, so dass beide Projekte derzeit im Kernel koexistieren. NFtables wurde mit Version 3.13 in den Standard-Linux-Kernel aufgenommen und teilweise auch für Linux-Distributionen in ältere Kernels rückportiert (Red Hat Enterprise Linux 7 – Kernel 3.10).

Für den Anwender hat nftables den Vorteil einer vereinheitlichten Syntax für IP-, arp- und eb-Regeln sowie der Tatsache, dass Regeln für IPv4 und IPv6 oft vereinheitlicht werden können.

Weitere Netfilter-Projekte

Obwohl es sich bei folgenden nicht um Kernelmodule handelt, die direkt auf die Netfilter-Code-Infrastruktur aufbauen, werden einige weitere Softwarepakete vom Netfilter-Projekt unterstützt.

ulogd

ulogd ist ein Userspace-Programm, das zum Empfang und zur Archivierung von Paketen (oder deren Eigenschaften) und Eventbenachrichtigungen des Netfilter-Subsystems dient. iptables kann Pakete mittels des “userspace queueing”-Mechanismus an den Userspace weiterleiten und Connection Tracking kann mit ulogd interagieren um weitere Informationen (z. B. Verbindungszustand) über Pakete oder Events (z. B. Verbindung geschlossen, Verbindung wurde ge-NAT-ed) auszutauschen.

ipset

Das Userspace-Programm ipset wird verwendet, um sogenannte „IP sets“ innerhalb des Linux-Kernels einzurichten, anzusehen und sonstig zu verwalten. Ein IP-Set ist üblicherweise eine Menge an IP-Adressen, kann aber auch Mengen von Netzwerknummern oder Ports enthalten, je nachdem, welchen Typ ein Set hat.

Solche Sets sind viel effizienter zu durchsuchen als wenn reguläre iptables-Regeln Stück für Stück geprüft und abgearbeitet würden, aber einhergehend mit Sets ist natürlich ein gegebenenfalls höherer Speicherbedarf. Verschiedene Speichermodelle sind in IP Set verfügbar, sodass der Benutzer eine für sich optimale Lösung auswählen kann.

Anders als die meisten Netfilter-Erweiterungen wie Connection Tracking, ist IP Set eher mit iptables in Verbindung zu bringen. Es bedient sich keiner Netfilter-Hooks, stellt aber ein iptables-Modul zum Zugehörigkeitstest und minimalen Änderungen (Setzen/Löschen) von IP-Set-Inhalten.

Weblinks

Homepages:

• Netfilter/iptables Projekt-Homepage (englisch)
• conntrack-tools Homepage (englisch)
• ipset homepage (englisch)
• ulogd homepage (englisch)

Der Workshop:

• Home of the Netfilter Workshop websites (englisch/französisch)
• Workshop résumé/blog (englisch/französisch)

Technische Dokumentation:

• “Writing Netfilter Modules” E-Book (2009; PDF; 655 kB)