Netfilter

Netfilter ist ein Softwareprojekt, das unter anderem Paketfilter, Network Address Translation und weitere für Firewalls relevante Werkzeuge für das Betriebssystem Linux bereitstellt.

Weiterhin 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.^[1] 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.

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 den Userspaceprogrammen 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.

• Das iptable_raw-Modul 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.
• Das iptable_mangle-Modul 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.
• Das iptable_nat-Modul 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.
• Das iptable_filter-Modul registriert die filter-Tabelle, die für allgemeine Paketfilterung eingesetzt wird.

Paket-Defragmentation

Siehe auch: IPv4 #Fragmentierung

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

Eines der wichtigen auf Netfilter aufbauenden Funktionen ist Connection Tracking (lit. “Verbindungsverfolgung”, “Verbindungsüberwachung”).^[2] 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 weiteren 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 wird, 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 zu den Helfermodulen für Connection Tracking gibt es NAT-Helfermodule, die neben der Paketinspektion auch noch Manipulation von Originaladressen zu Antwortadressen im Datenstrom umsetzen.

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. ip_tables 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.

IP Set

Das Userspace-Programm IP Set^[3] 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.

Netfilter-Workshops

Das Netfilter-Projekt organisiert jährliche Veranstaltungen für Entwickler, die dazu dienen, über weitere Nachforschungen und Entwicklungen zu beraten und diskutieren. Der letzte Workshop fand in Paris (Frankreich) Ende September 2008 statt.

Weiterführende Links

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-Datei; 655 kB)

Fußnoten

1. ↑ http://lxr.linux.no/linux+*/net/netfilter/core.c#L157
2. ↑ Netfilter's Connection Tracking System, by Pablo Neira Ayuso, June 14 2006: people.netfilter.org (PDF)
3. ↑ IP sets (englisch) – offizielle Projektseite bei netfilter.org; Stand: 30. März 2011