Next Previous Contents

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:
  2. Transparente Proxies sind eine Qual:
  3. Es ist nicht moegliche, Paketfilter-Regeln unabhaengig von der Adresse der Schnittstelle zu erstellen:
  4. Masquerading ist abhaengig von Paketfiltern:

    Interaktionen zwischen Paketfiltern und Masquerading machen eine Firewall komplex:

  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:
  8. Inkompatibilitaet zwischen CONFIG_NET_FASTROUTE und Paketfiltern:
  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.


Next Previous Contents