1. Einleitung

Hi Leute.

Dieses Dokument ist eine Reise; manche Teile sind gut besucht, und in anderen Bereichen wirst Du Dich fast alleine fuehlen. Der beste Rat, den ich Dir geben kann, ist Dir eine grosse, heisse Tasse Kaffee oder Schokolade zu besorgen, Dich in einen bequemen Stuhl zu setzen, und den Inhalt in Dich aufzunehmen, bevor Du Dich in die gefaehrliche Welt des Netzwerk-Hackens begibst.

Um die Verwendung der Infrastruktur auf dem Netfilter-Rahmenwerk besser zu verstehen, empfehle ich, das Paketfiltering-HOWTO und das NAT-HOWTO zu lesen. Fuer Informationen ueber Kernel-Programmierung empfehle ich Rusty's Unreliable Guide to Kernle Hacking und Rusty's Unreliable Guide to Kernel Locking.

Dieses Dokument enthaelt Flueche. Das ist ein natuerliches Gewuerz in meiner Sprache, aber Du kannst die Originalversion dieses HOWTOs in American Broadcast uebersetzen, wenn Du den Filter benutzt:

sed 's/[^]aeio]ck/reak/'

1.1 Was ist Netfilter?

Netfilter ist eine Basis der Paketbehandlung, gehoert aber nicht zu dem normalen Berkeley Socket Interface. Es besteht aus vier Teilen. Zuerst definiert jedes Protokoll 'Hooks' (IPv4 definiert 5), welche wohldefinierte Punkte auf der Reise eines Pakets durch den Protokoll-Stack sind. An jedem dieser Punkte wird das Protokoll Netfilter mit dem Paket und der Hook-Nummer aufrufen.

Zweitens koennen Teile des Kernels sich fuer das Aufpassen auf verschiedene Hooks fuer jedes Protokoll registrieren. Wenn ein Paket also an Netfilter gereicht wird, wird ueberprueft, ob irgendjemand fuer dieses Protokoll oder fuer diesen Hook registriert ist; Wenn ja, bekommt jeder von ihnen der Reihe nach die Chance, das Paket zu untersuchen (es moeglicherweise zu veraendern), das Paket zu verwerfen, es durchzulassen oder Netfilter zu beauftragen, das Paket fuer Userspace einzureihen.

Der dritte Teil besteht darin, dass eingereihte Pakete gesammelt werden (von ip_queue-Treiber), um an den Userspace geschickt zu werden; diese Pakete werden asynchron behandelt.

Der letzte Teil besteht aus coolen Kommentaren im Code und Dokumentation. Das ist Bestandteil eines jeden experimentiellen Projekts. Das Netfilter- Motto ist (schamlos von Cort Dougan gestohlen):

         '' Also... wo ist das hier besser als KDE? ''

(Dieses Motto hat sich ein wenig ausgeweitet: ''Peitsch mich aus, schlag mich, lass mich ipchains benutzen'').

Zusaetzlich zu diesem einfach Rahmenwerk wurden verschiedene Module geschrieben, welche Funktionalitaeten aehnlich zu frueheren (pre- netfilter) Kernel bieten, im Besonderen ein erweiterbares NAT-System, und ein erweiterbares Paketfilter-System (iptables).

1.2 Was stimmte nicht mit dem, was wir im 2.0er und 2.2er Kernel hatten?

1. Keine ausgebaute Infrastruktur, um Pakete an Userspace weiterzugeben:
   • Kernelprogrammierung ist schwer
   • Kernelprogrammierung muss in C/C++ gemacht werden
   • Dynamische Filter-Policies gehoeren nicht in den Kernel
   • 2.2 fuehrte ein, Pakete via netlink zum Userspace zu kopieren, aber das ist langsam, und 'sanity checks' (wenn ein Paket z.B. nur behauptet, von einer existierenden Schnittstelle zu kommen) sind nicht moeglich.
2. Transparente Proxies sind eine Qual:
   • Wir untersuchen jedes Paket, um zu sehen, ob ein Socket an diese Adresse gebunden ist
   • Root darf an fremde Adressen binden
   • Lokal-generierte Pakete koennen nicht redirected werden
   • REDIRECT behandelt keine UDP-Antworten: Ein UDP-Named-Paket an 1153 weiterleiten funktioniert nicht, weil manche Clients Antworten von anderen Ports als 53 nicht moegen.
   • REDIRECT koordiniert sich nicht mit der TCP/UDP Portzuordnung: Ein Benutzer kann einen Port durch eine REDIRECT-Regeln shadowen.
   • Es ist waehrend der 2.1er-Serie mindestens zweimal zusammengebrochen.
   • Code ist extrem aufdringlich. Denk an die Statistiken von #ifdef CONFIG_IP_TRANSPARENT_PROXY in 2.2.1: es tritt in 11 Dateien insgesamt 34 mal auf. Im Vergleich dazu taucht CONFIG_IP_FIREWALL in 5 Dateien nur insgesamt 10 mal auf.
3. Es ist nicht moegliche, Paketfilter-Regeln unabhaengig von der Adresse der Schnittstelle zu erstellen:
   • Um lokal-generierte oder lokal-bestimmte Pakete von durchgehenden Paketen unterscheiden zu koennen, muss die lokale Adresse der Schnittstelle bekannt sein.
   • Sogar das reicht bei Redirection oder Masquerading nicht aus.
   • Die FORWARD-Kette besitzt nur Informationen ueber die ausgehende Schnittstelle, was bedeutet, dass Du herausfinden musst, woher ein Paket kam, indem Du Dein Wissen ueber die Netzwerk-Topologie anwendest.
4. Masquerading ist abhaengig von Paketfiltern:

   Interaktionen zwischen Paketfiltern und Masquerading machen eine Firewall komplex:

   • Beim Eingangsfilter scheinen Antwortpakete fuer den Rechner selbst bestimmt zu sein
   • Beim Forward-Filter werden demaskierte Pakete ueberhaupt nicht gesehen
   • Beim Ausgangsfilter scheinen Pakete vom lokalen Rechner zu kommen

5. TOS-Manipulation, Redirect, ICMP unreachable und mark (welche Effekte auf Portforwarding, Routing und QoS haben koennen) haengen ebenfalls vom Paketfilter-Code ab.
6. ipchains-Code ist weder modular noch erweiterbar (zum Beispiel MAC- Adressen Filter, Filtern nach Optionen, etc).
7. Mangel an ausreichender Infrastruktur hat zu einem Ueberfluss von von verschiedenen Techniken gefuehrt:
   • Masquerading plus Per-Protokoll Module
   • Schnelles, statisches NAT durch Routing Code (hat keine Per- Protokoll Routinen)
   • Portforwarding, Redirect, Auto-Forwarding
   • Das Linux NAT und virtuelle Server Projekte.
8. Inkompatibilitaet zwischen CONFIG_NET_FASTROUTE und Paketfiltern:
   • Weitergeleitete Pakete gehen trotzdem durch drei Ketten
   • Keine Moeglichkeit, zu sagen, ob diese Ketten umgangen werden koennen
9. Wegen Routing-Protection (z.B. Verifikation der Quelladresse) keine Moeglichkeit, verworfene Pakete zu untersuchen.
10. Keine Moeglichkeit, automatisch die Zaehler auf Paketfilter-Regeln zu lesen.
11. CONFIG_IP_ALWAYS_DEFRAG ist eine Compilezeit-Option, die das Leben fuer Distributionen, die einen general-purpose Kernel wollen, schwer macht.

1.3 Wer bist Du?

Ich bin der einzige, der dumm genug ist, das zu tun. Als ipchains Co-Autor und jetziger Linux Kernel IP Firwall Maintainer sehe ich viele der Probleme, die die Leute mit dem jetzigen System haben, da ich erkenne, was sie alles machen wollen.

1.4 Wieso stuerzt es ab?

Woah! Du haettest es letzte Woche sehen sollen!

Weil ich kein so guter Programmierer bin, wir wir alle es uns wuenschen wuerden, und ich natuerlich nicht alle Szenarien getestet habe, wegen Mangel an Zeit, Ausstattung und/oder Inspiration. Ich habe eine Testumgebung, und ich will Dich ermutigen, daran teilzunehmen.