Netfilter

Netfilterist einSoftwareprojekt,das unter anderemPaketfilter,Network Address Translationund weitere fürFirewallsrelevante Werkzeuge für denLinux-Kernelbereitstellt. 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.

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

Beziehung einiger Netfilter-Komponenten zueinander

Geschichte

DasNetfilter/iptables-Projektwurde 1998 vonRusty Russellins Leben gerufen, der außerdem der Autor des Vorgängersipchainswar. Mit Wachstum des Projektes gründete er 1999 dasNetfilter-Coreteam(oder einfachCoreteam;Hauptentwicklerteam). Die dort produzierte Software – von hier anNetfiltergenannt – ist unter derGNU General Public License(GPL) lizenziert und wurde im März 2000 in den Linux-Kernel, Version 2.3, integriert. Im August 2003 wurdeHarald WelteVorsitzender 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 gerichtlicheVerfügunggegen 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 Firewallpaketeipchainsin Linux 2.2 undipfwadmin Linux 2.0, welches Ähnlichkeiten zuBSDsipfwbesaß. 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,PortweiterleitungundUmleitung), 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 Kernelmoduleip_tables,ip6_tables,arp_tables(Unterstriche gehören zum Namen) undebtablesstellen 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 Userspaceprogrammeiptables,ip6tables,arptablesbzw.ebtablesadministriert 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 entsprechenvon wo ausder 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 namensrawverfügbar, in der Pakete gefiltert werden können, bevor sie speicherintensivere Operationen wie Connection Tracking erreichen.

iptable_mangle

registriert einen Hook und eine Tabelle namensmangle,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. Dienat-Tabelle die im Zuge dessen verfügbar wird, ist lediglich eine “Konfigurationsdatenbank”, die nur fürNAT-Abbildungen gedacht ist, nicht für Paketfilterung.

iptable_filter

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

Paket-Defragmentation

Siehe auch:„Datagrammfragmentierung “im Artikel IPv4

Dasnf_defrag_ipv4-Modul wird zur Defragmentierung von IPv4-Paketen eingesetzt, bevor Connection Tracking (imnf_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 innf_conntrack_ipv6integriert.

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 oderSitzungenzu 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 wieTCPoderSCTP.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 wieUDP,IPsec(AH/ESP),GREund andereTunnelprotokollehaben 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-Programmconntrackmanipuliert 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 dasnf_conntrack_ftp-Modul den “PASV” -Befehl in einerFTP-Verbindung findet.

INVALID

Das Paket wurde als ungültig eingestuft, z. B. wenn es nicht demTCP-Zustands-Transitionsgraphenfolgt.

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 einICMP-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 vonProtokollen der Anwendungsschichterhä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 dasnf_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ürConnection Trackinggibt 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 wurdeNFTablesgenannt, das Kommandozeilenwerkzeug dafürnft.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 Linux7 – 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-Programmipsetwird verwendet, um sogenannte „IP sets “innerhalb desLinux-Kernelseinzurichten, anzusehen und sonstig zu verwalten. Ein IP-Set ist üblicherweise eineMengeanIP-Adressen,kann aber auch Mengen von Netzwerknummern oderPortsenthalten, 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 inIP Setverfügbar, sodass der Benutzer eine für sich optimale Lösung auswählen kann.

Anders als die meisten Netfilter-Erweiterungen wieConnection Tracking,istIP Seteher 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)