Next Previous Contents

3. Netfilter Architektur

Netfilter ist mehr eine Serie von Hooks auf bestimmten Positionen in einem Protokoll-Stack (zur Zeit IPv4, IPv6 und DECnet). Das (idealisierte) IPv4 Reise-Diagramm sieht folgendermassen aus:

Ein Paket, das das Netfilter System durchreist:

   --->[1]--->[ROUTE]--->[3]--->[4]--->
                 |            ^
                 |            |
                 |         [ROUTE]
                 v            |
                [2]          [5]
                 |            ^
                 |            |
                 v            |

Links geht das Paket ein: Den einfachen sanity-check ueberstanden (ich meine, nicht verstuemmelt, Checksumme OK, kein promiscuous receive), werden sie an den NF_IP_PRE_ROUTING [1] Hook des Netfilter Rahmenwerks weitergereicht.

Als naechstes kommen sie in den Routing-Code, welcher entscheidet, ob das Paket fuer eine andere Schnittstelle oder fuer einen lokalen Prozess bestimmt ist. Der Routing-Code kann unroutebare Pakete verwerfen.

Wenn es fuer den Rechner selbst bestimmt ist, wird der NF_IP_LOCAL_IN [2] Hook des Netfilter Rahmenwerks wieder aufgerufen, bevor das Paket an den Prozess (wenn es einen gibt) geschickt wird.

Wenn der Zielort stattdessen eine andere Schnittstelle ist, wird der NF_IP_FORWARD [3] Hook des Netfilter Rahmenwerks stattdessen aufgerufen.

Das Paket durchlaeuft dann den letzten Netfilter Hook, den NF_IP_POST_ROUTING [4] Hook, bevor es wieder in die Leitung geschickt wird.

Fuer Pakete, die lokal generiert wurden, wird der NF_IP_LOCAL_OUT [5] Hook aufgerufen. Hier kannst Du sehen, dass Routing erst dann einsetzt, wenn dieser Hook aufgerufen wurde: Tatsaechlich wird zuerst der Routing-Code aufgerufen (um Angaben ueber Quelladresse und IP-Optionen zu bestimmen) und wird erneut aufgerufen, wenn das Paket geaendert werden sollte.

3.1 Netfilter Grundlagen

Jetzt haben wir ein Beispiel von netfilter fuer IPv4, Du kannst sehen, wann jeder Hook aktiviert wird. Das ist die Essenz von Netfilter.

Kernelmodule koennen sich registrieren, um an irgendeinem dieser Hooks lauschen. Wenn dieser Netfilter Hook dann vom Networking-Code aufgerufen wird, hat an diesem Punkt jedes registrierte Modul die Moeglichkeit, das Paket zu veraendern. Das Modul kann Netfilter sagen, eine von drei Sachen zu tun:

  1. NF_ACCEPT: Die Reise wie gewoehnlich fortsetzen.
  2. NF_DROP: das Paket verwerfen, die Reise nicht fortsetzen.
  3. NF_STOLEN: Ich habe das Paket uebernommen, setz die Reise nicht fort.
  4. NF_QUEUE: Das Paket einreihen (gewoehnlich fuer Userspace).
  5. NF_REPEAT: Diesen Hook erneut aufrufen.

Die anderen Teile von Netfilter (eingereihte Pakete behandeln, coole Kommentare) werden spaeter in der Kernel-Sektion erklaert.

Auf diesem Fundament koennen wir ziemliche komplexe Paketfilter- Manipulationen aufbauen, wie in den naechsten zwei Sektionen gezeigt werden wird.

3.2 Paketauswahl: iptables

Ein System zur Paketauswahl mit dem Namen IP-Tables wurde ueber das Netfilter Rahmenwerk gebaut. Es ist ein direkter Abkoemmling von ipchains (welches von ipfwadm abstammt, welches, wenn ich mich richtig erinnere, von BSD's ipfw abstammt), mit Erweiterungen. Kernelmodule koennen eine neue Tabelle registrieren und von einem Paket verlangen, eine vorgegebene Tabelle zu durchwandern. Diese Methode zur Paketauswahl wird fuer Paketfilter (die 'Filter'-Tabelle), Network Address Translation (die 'NAT'-Tabelle) und allgemeine Behandlung von pre-routing Paketen (die 'mangle'-Tabelle) verwendet.

Paketfiltern

Diese Tabelle, 'filter', sollte die Pakete niemals veraendern: sie soll sie nur filtern.

Einer der Vorteile von iptables Filtern gegenueber ipchains ist, dass es klein und schnell ist, und es die Netfilter-Hooks NF_IP_LOCAL_IN, NF_IP_FORWARD und NF_IP_LOCAL_OUT verwendet. Das bedeutet, dass es fuer jedes gegebene Paket einen (und nur einen) moeglichen Ort gibt, um es zu filtern. Dies vereinfacht die Dinge ungemein. Ausserdem bedeutet der Fakt, dass das Netfilter Rahmenwerk beides, eingehende und ausgehende Schnittstellen fuer den NF_IP_FORWARD Hook bietet, dass viele Arten des Filterns weitaus einfacher werden.

Beachte: Ich habe die Kernelteile sowohl von ipchains als auch von ipfwadm zu Modulen auf Netfilter portiert, was es ermoeglicht, die alten ipfwadm und ipchains Anwendungstools ohne ein Upgrade weiterzuverwenden.

NAT

Dies ist das Koenigreich der NAT-Tabelle, welche mit Paketen von drei Netfilter-Hooks gefuettert wird: fuer nicht-lokale Pakete sind fuer Quell- und Zielveraenderungen jeweils der NF_IP_PRE_ROUTING und der NF_IP_POST_ROUTING Hook perfekt. Um das Ziel von lokalen Paketen zu veraendern, wird der NF_IP_LOCAL_OUT Hook verwendet.

Diese Tabelle unterscheidet sich insoweit leicht von der 'Filter'-Tabelle, als dass nur das erste Paket einer neuen Verbindung die Tabelle durchwandern wird: Das Resultat dieser Untersuchung wird dann auf alle weiteren Pakete derselben Verbindung angewandt.

Masquerading, Portforwarding, transparente Proxies

Ich unterteile NAT in Source NAT (wo die Quelle des ersten Pakets veraendert wird) und in Destination NAT (wo das Ziel der ersten Pakets veraendert wird).

Masquerading ist eine spezielle Form von Source NAT: Port-Forwarding und transparente Proxies sind eine spezielle Form von Destination NAT. Dies wird nun alles mit dem NAT-Rahmenwerk erledigt, anstatt unabhaengige Einheiten zu sein.

3.3 Connection Tracking

Connection Tracking ist ein Fundament von NAT, wurde aber als separates Modul implementiert; dies erlaubt es, durch eine Erweiterung der Paketfilter einfach und sauber Connection Tracking zu verwenden (das 'state' Modul).

3.4 Sonstige Moeglichkeiten

Die neue Flexibilitaet bietet sowohl die Moeglichkeit, wirklich abgefahrene Dinge zu tun, als auch Erweiterungen oder einen kompletten Ersatz zu schreiben, die auch vermischt werden koennen.


Next Previous Contents