1. Einleitung 1.1 Was ist Netfilter? 1.2 Was stimmte nicht, was wir im 2.0er u. 2.2er Kernel hatten? 1.3 Wer bist Du? 1.4 Wieso stürzt es ab?

Transkript

1 Linux netfilter Hacking HOWTO Rusty Russell, mailing list ins Deutsche übersetzt von Melanie Berg Überarbeitung von Martin Heidenreich v1.0 Thu Mar 29 13:38:03 CST 2005 Dieses Dokument beschreibt die netfilter-architektur für Linux, wie man sie hacken kann und einiger darauf aufbauende größere Systeme, wie Paketfilter, connection tracking und Network Address Translation (NAT). Diese deutsche Übersetzung steht unter den Bedingungen der GNU General Public License ( Inhaltsverzeichnis 1. Einleitung 1.1 Was ist Netfilter? 1.2 Was stimmte nicht, was wir im 2.0er u. 2.2er Kernel hatten? 1.3 Wer bist Du? 1.4 Wieso stürzt es ab? 2. Wo kann ich die neueste Version herbekommen? 3. Netfilter Architektur 3.1 Netfilter Grundlagen 3.2 Paketauswahl: iptables Paketfilter NAT Masquerading, Portforwarding, transparente Proxies 3.3 Connection Tracking 3.4 Sonstige Möglichkeiten 4. Informationen für Programmierer 4.1 ip_tables verstehen ip_tables Datenstruktur ip_tables aus Sicht der Anwender ip_tables verwenden und erforschen 4.2 iptables erweitern Der Kernel Neue Match-Funktionen Neue Targets Neue Tabellen Anwendertools Neue Match-Funktionen Neue Targets `libiptc' verwenden 4.3 NAT verstehen Connection Tracking 4.4 NAT/Connection Tracking erweitern Standard NAT-Targets Neue Protokolle Der Kernel von innen Neue NAT-Targets Protokoll-Hilfen für TCP und UDP 4.5 Netfilter verstehen (lernen) 4.6 Neue Netfilter-Module schreiben Netfilter-Schnittstellen benutzen Eingereihte Pakete behandeln Kommandos vom Anwender empfangen 4.7 Behandlung von Paketen aus Sicht der Anwender

2 5. 2.0er und 2.2er Paketfilter-Module übersetzen 6. Die Testsuite 6.1 Einen Test schreiben 6.2 Variablen und Umgebung 6.3 Nützliche Tools gen_ip rcv_ip gen_err local_ip 6.4 Einige Ratschläge 7. Motivation 8. Danke 1. Einleitung Hi Leute. Dieses Dokument ist eine Reise; manche Teile sind gut besucht, und in anderen Bereichen wirst Du Dich fast alleine fühlen. Der beste Rat, den ich Dir geben kann, ist Dir eine große, heiße Tasse Kaffee oder Schokolade zu besorgen, Dich in einen bequemen Stuhl zu setzen, und den Inhalt in Dich aufzunehmen, bevor Du Dich in die gefährliche 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. Für Informationen über Kernel-Programmierung empfehle ich meine anderen Tutorials. Dieses Dokument enthält Flüche. Das ist ein natürliches Gewürz in meiner Sprache, aber Du kannst die Originalversion dieses HOWTOs in American Broadcast übersetzen, wenn Du den Filter benutzt: sed 's/[^]aeio]ck/reak/' 1.1. Was ist Netfilter? Netfilter ist eine Basis der Paketbehandlung, gehört aber nicht zu dem normalen Berkeley Socket Interface. Es besteht aus vier Teilen. Zuerst definiert jedes Protokoll 'Hooks' (IPv4 definiert 5), welche wohl definierte 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 können Teile des Kernels sich für das Aufpassen auf verschiedene Hooks für jedes Protokoll registrieren. Wenn ein Paket also an Netfilter gereicht wird, wird überprüft, ob irgendjemand für dieses Protokoll oder für diesen Hook registriert ist; Wenn ja, bekommt jeder von ihnen der Reihe nach die Chance, das Paket zu untersuchen (es möglicherweise zu verändern), das Paket zu verwerfen, es durchzulassen oder Netfilter zu beauftragen, das Paket für Userspace einzureihen.

3 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 experimentellen 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''). Zusätzlich zu diesem einfach Rahmenwerk wurden verschiedene Module geschrieben, welche Funktionalitäten ähnlich zu früheren (pre-netfilter) Kernel bieten, im Besonderen ein erweiterbares NAT-System, und ein erweiterbares Paketfilter-System (iptables) Was stimmte nicht, was wir im 2.0er und 2.2er Kernel hatten? 1. Keine ausgebaute Infrastruktur, um Pakete an Userspace weiterzugeben: o Kernelprogrammierung ist schwer o Kernelprogrammierung muss in C/C++ gemacht werden o Dynamische Filter-Policies gehören nicht in den Kernel o 2.2 führte 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 möglich. 2. Transparente Proxies sind eine Qual: o Wir untersuchen jedes Paket, um zu sehen, ob ein Socket an diese Adresse gebunden ist o Root darf an fremde Adressen binden o Lokal-generierte Pakete können nicht redirected werden o REDIRECT behandelt keine UDP-Antworten: Ein UDP-Named-Paket an 1153 weiterleiten funktioniert nicht, weil manche Clients Antworten von anderen Ports als 53 nicht mögen. o REDIRECT koordiniert sich nicht mit der TCP/UDP Portzuordnung: Ein Benutzer kann einen Port durch eine REDIRECT-Regeln shadowen. o Es ist während der 2.1er-Serie mindestens zweimal zusammengebrochen.

4 o Code ist extrem aufdringlich. Denk an die Statistiken von #ifdef CONFIG_IP_TRANSPARENT_PROXY in 2.2.1: es tritt in 11 Dateien insgesamt 34mal auf. Im Vergleich dazu taucht CONFIG_IP_FIREWALL in 5 Dateien nur insgesamt 10mal auf. 3. Es ist nicht mögliche, Paketfilter-Regeln unabhängig von der Adresse der Schnittstelle zu erstellen: o Um lokal generierte oder lokal bestimmte Pakete von durchgehenden Paketen unterscheiden zu können, muss die lokale Adresse der Schnittstelle bekannt sein. o Sogar das reicht bei Redirection oder Masquerading nicht aus. o Die FORWARD-Kette besitzt nur Informationen über die ausgehende Schnittstelle, was bedeutet, dass Du herausfinden musst, woher ein Paket kam, indem Du Dein Wissen über die Netzwerk-Topologie anwendest. 4. Masquerading ist abhängig von Paketfiltern: Interaktionen zwischen Paketfiltern und Masquerading machen eine Firewall komplex: o Beim Eingangsfilter scheinen Antwortpakete für den Rechner selbst bestimmt zu sein o Beim Forward-Filter werden demaskierte Pakete überhaupt nicht gesehen o 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 können) hängen 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 Überfluss von von verschiedenen Techniken geführt: o Masquerading plus Per-Protokoll Module o Schnelles, statisches NAT durch Routing Code (hat keine Per- Protokoll Routinen) o Portforwarding, Redirect, Auto-Forwarding o Das Linux NAT und virtuelle Server Projekte. 8. Inkompatibilität zwischen CONFIG_NET_FASTROUTE und Paketfiltern: o Weitergeleitete Pakete gehen trotzdem durch drei Ketten o Keine Möglichkeit, zu sagen, ob diese Ketten umgangen werden können

5 9. Wegen Routing-Protection (z.b. Verifikation der Quelladresse) keine Möglichkeit, verworfene Pakete zu untersuchen. 10.Keine Möglichkeit, automatisch die Zähler auf Paketfilter-Regeln zu lesen. 11.CONFIG_IP_ALWAYS_DEFRAG ist eine Compilezeit-Option, die das Leben für Distributionen, die einen general-purpose Kernel wollen, schwer macht 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 Wieso stürzt es ab? Woah! Du hättest es letzte Woche sehen sollen! Weil ich kein so guter Programmierer bin, wir alle es uns wünschen würden und ich natürlich aus Zeitmangel nicht alle Szenarien getestet habe, Ausstattung und/oder Inspiration. Ich habe eine Testumgebung und ich will Dich ermutigen, daran teilzunehmen. 2. Wo kann ich die neueste Version herbekommen? Es gibt einen Server auf netfilter.org der die neuesten HOWTOs, Anwenderprogramme und Testseiten enthält.

6 3. Netfilter Architektur Netfilter ist mehr eine Serie von Hooks auf bestimmten Positionen in einem Protokoll-Stack (Zurzeit IPv4, IPv6 und DECnet). Das (idealisierte) IPv4 Reise-Diagramm sieht folgendermaßen 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 überstanden (ich meine, nicht verstümmelt, Checksumme OK, kein promiscuous receive), werden sie an den NF_IP_PRE_ROUTING [1] Hook des Netfilter Rahmenwerks weitergereicht. Als nächstes kommen sie in den Routing-Code, welcher entscheidet, ob das Paket für eine andere Schnittstelle oder für einen lokalen Prozess bestimmt ist. Der Routing-Code kann nicht routebare Pakete verwerfen. Wenn es für 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 durchläuft dann den letzten Netfilter Hook, den NF_IP_POST_ROUTING [4] Hook, bevor es wieder in die Leitung geschickt wird. Für 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: Tatsächlich wird zuerst der Routing-Code aufgerufen (um Angaben über Quelladresse und IP- Optionen zu bestimmen) und wird erneut aufgerufen, wenn das Paket geändert werden sollte Netfilter Grundlagen Jetzt haben wir ein Beispiel von netfilter für IPv4, Du kannst sehen, wann jeder Hook aktiviert wird. Das ist die Essenz von Netfilter.

7 Kernelmodule können 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 Möglichkeit, das Paket zu verändern. Das Modul kann Netfilter sagen, eine von drei Sachen zu tun: 1. NF_ACCEPT: Die Reise wie gewöhnlich fortsetzen. 2. NF_DROP: das Paket verwerfen, die Reise nicht fortsetzen. 3. NF_STOLEN: Ich habe das Paket übernommen, setz die Reise nicht fort. 4. NF_QUEUE: Das Paket einreihen (gewöhnlich für Userspace). 5. NF_REPEAT: Diesen Hook erneut aufrufen. Die anderen Teile von Netfilter (eingereihte Pakete behandeln, coole Kommentare) werden später in der Kernel-Sektion erklärt. Auf diesem Fundament können wir ziemliche komplexe Paketfilter- Manipulationen aufbauen, wie in den nächsten zwei Sektionen gezeigt werden wird Paketauswahl: iptables Ein System zur Paketauswahl mit dem Namen IP-Tables wurde über das Netfilter Rahmenwerk gebaut. Es ist ein direkter Abkömmling von ipchains (welches von ipfwadm abstammt, welches, wenn ich mich richtig erinnere, von BSD's ipfw abstammt), mit Erweiterungen. Kernelmodule können eine neue Tabelle registrieren und von einem Paket verlangen, eine vorgegebene Tabelle zu durchwandern. Diese Methode zur Paketauswahl wird für 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 verändern: sie soll sie nur filtern. Einer der Vorteile von iptables Filtern gegenüber 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 für jedes gegebene Paket einen (und nur einen) möglichen Ort gibt, um es zu filtern. Dies vereinfacht die Dinge ungemein. Außerdem bedeutet der Fakt, dass das Netfilter Rahmenwerk beides, eingehende und ausgehende Schnittstellen für 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 ermöglicht, die alten ipfwadm und ipchains Anwendungstools ohne ein Upgrade weiter zu verwenden.

8 NAT Dies ist das Königreich der NAT-Tabelle, welche mit Paketen von drei Netfilter-Hooks gefüttert wird: für nicht-lokale Pakete sind für Quell- und Zielveränderungen jeweils der NF_IP_PRE_ROUTING und der NF_IP_POST_ROUTING Hook perfekt. Um das Ziel von lokalen Paketen zu verändern, 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 verändert wird) und in Destination NAT (wo das Ziel der ersten Pakets verändert 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 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) Sonstige Möglichkeiten Die neue Flexibilität bietet sowohl die Möglichkeit, wirklich abgefahrene Dinge zu tun, als auch Erweiterungen oder einen kompletten Ersatz zu schreiben, die auch vermischt werden können. 4. Informationen für Programmierer Ich weihe Dich in ein Geheimnis ein: mein Hamster hat alles programmiert. Ich war nur das Medium, wenn Du es so willst das 'Front-End', im großen Plan meines Hamsters. Also mach mich nicht für irgendwelche Bugs verantwortlich. Mach den schlauen mit dem Fell verantwortlich ip_tables verstehen iptables besteht einfach aus einem benannten Array von Regeln im Speicher (daher der Name 'iptables') und Informationen darüber, wo Pakete von jedem Hook die Reise beginnen sollen. Nachdem eine Tabelle registriert wurde, kann ihr Inhalt von Anwenderseite her gelesen oder ersetzt werden, indem getsockopt() und setsockopt() benutzt werden.

9 iptables registriert nicht mit irgendwelchen Netfilter Hooks: es verlässt sich auf andere Module, die das tun und es angemessen mit Paketen füttern sollen ip_tables Datenstruktur Der Bequemlichkeit halber wird dieselbe Datenstruktur verwendet, um eine Regel von Anwenderseite her oder im Kernel selbst zu repräsentieren, obwohl einige Felder nur im Kernel selbst benutzt werden. Jede Regel besteht aus folgenden Teilen: 1. Einem 'struct ip_entry'. 2. Null oder mehr 'struct ipt_entry_match' Strukturen, an jede Platz für Variablen (0 oder mehr Bytes) von Daten angehängt. 3. Einer 'struct ipt_entry_target' Struktur, an jede Platz für Variablen (0 oder mehr Bytes) von Daten angehängt. Die Variablen-Natur der Regeln gibt eine große Flexibilität für Erweiterungen, wie wir sehen werden, besonders, da jeder Treffer oder jedes Ziel eine willkürliche Menge von Daten tragen können. Dies birgt zwar auch ein paar Fallen, aber wie auch immer: Wir müssen aufpassen. Wir tun dies, indem wir uns darüber versichern, dass die 'ipt_entry', die 'ipt_entry_match' und die 'ipt_entry_target' Strukturen eine angenehme Größe haben, und dass alle Daten auf die maximale Auslastung des Rechners aufgerundet werden, indem wir den IPT_ALIGN() Makro verwenden. `struct ipt_entry' hat die folgenden Felder: 1. Einen 'struct ipt_ip' Teil, der die Bestimmungen für den IP-Header enthält, der zutreffen soll. 2. Ein 'nf_cache' Bitfeld, das zeigt, welche Teile des Pakets diese Regel untersucht hat. 3. Ein 'target_offset' Feld, das den Absatz vom Anfang dieser Regel angibt, wo die ipt_entry_target Struktur beginnt. 4. Ein 'next_offset' Feld, das die absolute Größe dieser Regel angibt, einschließlich Treffer und Ziele. 5. Ein 'comefrom' Feld, das vom Kernel benutzt wird, um die Reise des Pakets zurückzuverfolgen. 6. Ein 'struct ipt_counters' Feld, was die Paket- und Bytezaehler für Pakete, die auf diese Regel gepasst haben, enthaelt. ipt_entry_match' und 'struct ipt_entry_target' sind sehr ähnlich darin, dass sie ein Feld für die Gesamtlänge (jeweils 'match_size' und `target_size') enthalten, einen Union, der den Namen des Treffers oder des Ziels (auf Anwenderseite) enthält, und einen Pointer (für den Kernel).

10 Wegen der trickreichen Natur der Datenstruktur einer Regel werden einige Hilfsroutinen angeboten: ipt_get_target() Diese Funktion liefert einen Pointer auf das Target einer Regel. IPT_MATCH_ITERATE() Dieser Makro ruft die gegebene Funktion für jeden Treffer einer Regel auf. Das erste Argument der Funktion ist 'ipt_match_entry' und andere Argumente (wenn es welche gibt) sind die, die im IPT_MATCH_ITERATE() Makro angeboten werden. IPT_ENTRY_ITERATE() Diese Funktion macht einen Pointer zu einem Eintrag, der Gesamtgröße der Tabelle der Einträge und einer Funktion, die aufzurufen ist. Das erste Argument der Funktion ist 'struct ipt_entry', und andere Argumente (wenn es welche gibt) sind die, die im IPT_ENTRY_ITERATE() Makro angeboten werden ip_tables aus Sicht der Anwender Userspace hat vier Operationen: Es kann die aktuelle Tabelle lesen, die Info lesen (Hook-Positionen und Größe der Tabelle), die Tabelle ersetzen (und die alten Zähler nehmen), und neue Zähler einbauen. So kann Userspace eine kleine Operation simulieren: Dies wird von der libiptc Library getan, welche die einfachen "add/delete/replace" semantics für Programme bietet. Da diese Tabellen in den Kernel transferiert werden, stellt sich die Frage der Auslastung der Maschinen, die unterschiedliche Userspaceund Kernel- space Typ-Regeln haben (z.b. Sparc mit 32-Bit Userland). Diese Fälle werden mit dem Überschreiben der Definition von IPT_ALIGN für diese Plattformen in 'libiptc.h' behandelt ip_tables verwenden und erforschen Der Kernel beginnt die Untersuchung an der Stelle, die durch einen bestimmten Hook definiert ist. Diese Regel wird überprüft; wenn das 'struct ipt_ip' Element zutrifft, wird jedes 'struct ip_entry_match' der Reihe nach untersucht (es wird die match-funktion entsprechend dem Treffer aufgerufen). Wenn die match-funktion 0 liefert, endet die Iteration auf dieser Regel. Wenn sie den 'hotdrop' Parameter auf 1 setzt, wird das Paket ebenfalls sofort verworfen werden (Dies wird für einige verdächtige Pakete benutzt, so wie in der TCP-match Funktion). Wenn diese Iteration bis zum Ende durchläuft, werden die Counter erhöht, `struct ipt_entry_target' wird untersucht: Wenn es ein Standardtarget ist, wird das 'verdict' Feld gelesen (negativ bedeutet ein Urteil über das Paket, positiv steht für ein Offset, zu dem man springen kann). Wenn die Antwort positiv ist und das Offset nicht das der nächsten Regel ist, wird die 'back' Variable gesetzt, und der vorige 'back' Wert wird in das 'comefrom' Feld der Regel geschrieben.

11 Für nicht-standard Targets wird die target Funktion aufgerufen: Sie liefert ein Urteil (nicht-standard Ziele können zu nichts springen, das würde den statischen Loop-Detection-Code brechen). Das Urteil kann IPT_CONTINUE sein, um bei der nächsten Regel weiterzumachen iptables erweitern Weil ich so faul bin, ist iptables leicht erweiterbar. Dies ist hauptsächlich der Versuch, die Arbeit auf die anderen zu schieben, worum es bei Open Source eigentlich geht (Bei Freier Software, wie RMS sagen würde, geht es um Freiheit und ich saß bei einem seiner Gespräche dabei, als ich das hier schrieb). iptables erweitern besteht aus zwei Teilen: den Kernel erweitern, indem man ein neues Modul schreibt, und möglicherweise das Anwendungsprogramm iptables erweitern, indem man eine neue Shared Library schreibt Der Kernel Ein Kernelmodul selbst zu schreiben ist ziemlich einfach, wie Du an den Beispielen sehen kannst. Eine Sache, auf die Du achten musst, ist, dass Dein Code integriert werden muss: Es kann ein Paket von Anwenderseite her ankommen, während ein anderes an einem Interrupt eintrifft. Tatsächlich kann es ab bei SMP vorkommen, dass ein Paket an einem Interrupt pro CPU eintrifft. Folgende Funktionen musst Du kennen: init_module() Das ist der Eintrittspunkt des Moduls. Es liefert eine negative Zahl oder 0, wenn Netfilter es erfolgreich registriert. cleanup_module() Das ist der Austrittspunkt des Moduls; es soll die Registration beim Kernel wieder aufheben. ipt_register_match() Dies wird verwendet, um einen neuen, zutreffenden Typ zu registrieren. Du übergibst ihm ein 'struct ip_match', was gewöhnlich als statische Variable deklariert wird (file-scope). ipt_register_target() Dies wird verwendet, um einen neuen Typ zu registrieren. Du übergibst ihm ein 'struct_ip_target', was gewöhnlich als statische Variable deklariert wird (file-scope). ipt_unregister_target() Um die Registration des Ziel aufzuheben. ipt_unregister_match() Um die Registration des Treffers aufzuheben.

12 Eine Warnung zu trickreichen Dingen (wie das Verwenden von Countern) für Deine neuen Treffer oder Ziele. Auf SMP-Maschinen wird die vollständige Tabelle mit Hilfe von memcpy für jede CPU dupliziert: Wenn Du die Information wirklich zentral halten willst, solltest Du Dir die Treffermethode zu 'limit' ansehen Neue Match-Funktionen Neue Match-Funktionen werden gewöhnlich als allein stehende Module geschrieben. Es ist möglich, diese Module der Reihe nach zu erweitern, obwohl es normalerweise nicht nötig ist. Eine Möglichkeit, um den Benutzern zu erlauben, direkt mit Deinem Modul zu sprechen, ist es, die `nf_register_sockopt' Funktion des Netfilter Rahmenwerks zu nutzen. Eine andere Möglichkeit ist es, Symbole für andere Module zu exportieren, damit sie sich registrieren können; auf diese Weise machen es Netfilter und iptables. Das Wesentliche Deiner neuen Match-Funktion ist 'struct ipt_match', was an 'ipt_register_match()' übergeben wird. Diese Struktur hat die folgenden Felder: list Dieses Feld ist auf irgendeinen Blödsinn gesetzt, z.b. '{NULL, NULL}'. name Dieses Feld ist der Name der Match-Funktion, auf die sich der Anwender bezieht. Der Name sollte dem Modul entsprechend gewählt werden (wenn der Name "mac" ist, muss das Modul "ipt_mac.o" heißen), damit es automatisch geladen werden kann. match Diese Feld ist ein Pointer auf eine Match-Funktion, welche aus einem skb, dem Pointer auf ein Eingangs- und ein Ausgangsgerät (eins davon kann NULL sein, das hängt von dem Hook ab), einem Pointer auf die Match-Daten der zutreffenden Regel, der Größe dieser Regel, dem IP-Offset (nicht Null steht für ein non-head Fragment), einem Pointer auf den Protokoll-Header (ich meine nur den IP-Header), der Gesamtlänge der Daten (ich meine die Paketlänge minus der IP-Header Länge) und schließlich einem Pointer auf die 'hotdrop' Variable besteht. Es soll nicht Null liefern, wenn die Regel auf das Paket zutrifft, und kann 'hotdrop' auf 1 setzen, wenn es Null liefert, um anzuzeigen, dass das Paket sofort verworfen werden soll. checkentry Dieses Feld ist ein Pointer auf eine Funktion, die die Bestimmungen für eine Regel untersucht; Wenn es 0 liefert, wird die Regel des Benutzers nicht akzeptiert werden. Zum Beispiel wird der "tcp" Match Typ nur TCP-Pakete akzeptieren, wenn also der 'struct ipt_ip' Teil der Regel nicht spezifiziert, dass das Protokoll TCP sein muss, wird Null geliefert. Das Tablename Argument erlaubt Deinem Match, zu kontrollieren, in welchen Tabellen es eingesetzt werden kann, und `hook_mask' ist eine Bitmaske von Hooks, von denen diese Regel möglicherweise aufgerufen wurde: Wenn Dein Match von einem der Netfilter-Hooks keinen Sinn macht, kannst Du das hier umgehen.

13 destroy Dieses Feld ist ein Pointer auf eine Funktion, die aufgerufen wird, wenn ein Eintrag, der dieses Match verwendet, gelöscht wird. Dies erlaubt Dir auch, Resourcen in checkentry dynamisch zuzuordnen und sie hier wieder aufzuräumen. me Dieses Feld ist auf '& this_module' gesetzt, welches Deinem Modul einen Pointer gibt. Es bewirkt, dass der usage-count steigt und fällt, je nachdem, ob Regeln dieses Typs erstellt oder gelöscht werden. Das bewahrt den Benutzer davon, das Modul zu entfernen (und somit das cleanup_module aufzurufen), wenn sich eine Regel darauf bezieht Neue Targets Neue Targets werden auch gewöhnlich als allein stehende Module geschrieben. Die Diskussionen der oberen Sektion 'Neue Match Funktionen' können hier ähnlich angewandt werden. Das Wesentliche Deines neuen Targets ist 'struct ipt_target', das an `ipt_register_target()' übergeben wird. Diese Struktur hat die folgenden Felder: list Dieses Feld ist auf irgendeinen Blödsinn gesetzt, z.b. '{NULL, NULL}'. name Dieses Feld ist der Name der Ziel-Funktion, auf die sich der Anwender bezieht. Der Name sollte dem Modul entsprechend gewählt werden (wenn der Name "REJECT" ist, muss das Modul "ipt_reject.o" heißen), damit es automatisch geladen werden kann. target Diese Feld ist ein Pointer auf eine Ziel-Funktion, welche aus einem skbuff, dem Pointer auf ein Eingangs- und ein Ausgangsgerät (eins davon kann NULL sein) einem Pointer auf die Ziel-Daten, der Größe der Ziel-Daten, und der Position der Regel in der Tabelle besteht. Die Target-Funktion liefert eine nicht-negative, absolute Position, zu der zu springen ist, oder ein negatives Urteil (was das negierte Urteil minus 1 ist). checkentry Dieses Feld ist ein Pointer auf eine Funktion, die die Bestimmungen für eine Regel überprüft; wenn das 0 liefert, wird die Regel des Benutzers nicht akzeptiert werden.

14 destroy Dieses Feld ist ein Pointer auf eine Funktion, die aufgerufen wird, wenn ein Eintrag, der dieses Match verwendet, gelöscht wird. Dies erlaubt Dir auch, Resourcen in checkentry dynamisch zuzuordnen und sie hier wieder aufzuräumen. me Dieses Feld ist auf '& this_module' gesetzt, welches Deinem Modul einen Pointer gibt. Es bewirkt, dass der usage-count steigt und fällt, je nachdem, ob Regeln dieses Typs erstellt oder gelöscht werden. Das bewahrt den Benutzer davon, das Modul zu entfernen (und somit das cleanup_module aufzurufen), wenn sich eine Regel darauf bezieht Neue Tabellen Wenn Du willst, kannst Du für einen speziellen Zweck eine neue Tabelle erstellen. Um das zu tun, rufst Du 'ipt_register_table()' mit `struct ipt_table' auf, was die folgenden Felder hat: list Dieses Feld ist auf irgendeinen Blödsinn gesetzt, z.b. '{NULL, NULL}'. name Dieses Feld ist der Name der Ziel-Funktion, auf die sich der Anwender bezieht. Der Name sollte dem Modul entsprechend gewählt werden (wenn der Name "nat" ist, muss das Modul "ipt_nat.o" heißen), damit es automatisch geladen werden kann. table Dies ist ein voll ausgenutztes 'stuct ipt_replace', wie es vom Anwender genutzt werden kann, um eine Tabelle zu ersetzen. Der `counters' Pointer sollte auf NULL gesetzt sein. Diese Datenstruktur kann als ' initdata' deklariert werden, damit es nach dem Booten verworfen werden kann. valid_hooks Dies ist eine Bitmaske der IPv4 Netfilter Hooks, mit der Du die Tabellen betreten wirst: Sie wird verwendet, um zu überprüfen, dass diese Eintrittspunkte gültig sind und um die möglichen Hooks für die ipt_match und die ipt_target 'checkentry() Funktionen zu berechnen. lock Dies ist das read-write Lock für die vollständige Tabelle, initialisiere es auf RW_LOCK_UNLOCKED. private Dies wird vom ip_tables Code intern verwendet.

15 Anwendertools Jetzt, wo Du Dein nettes cooles Kernelmodul geschrieben hast, möchtest Du vielleicht seine Optionen von Anwenderseite her kontrollieren. Lieber, als für jede Erweiterung von iptables eine abgespaltene Version zu haben, benutze ich eine Technologie der späten 90er: Furbies. Sorry, ich meine shared Libraries. Gewöhnlich benötigen neue Tabellen keine Erweiterungen von iptables: Der Benutzer verwendet einfach die '-t' Option, um auf eine neue Tabelle zugreifen zu können. Die shared Libraries sollten eine '_init()' Funktion haben, die beim Laden automatisch aufgerufen wird: Das moralische Gegenstück zu der `init_module()' Funktion der Kernelmodule. Dies sollte 'register_match()' oder 'register_target()' aufrufen, abhängig davon, ob Deine shared Library ein neues Match oder ein neues Ziel ist. Du brauchst nur dann eine shared Library, wenn Du einen Teil der Struktur initialisieren oder eine zusätzliche Option bieten willst. Das Ziel `REJECT' zum Beispiel benötigt nichts dergleichen, hat also auch keine shared Library. Es gibt nützliche Funktionen, die in 'iptables.h.' beschrieben werden, besonders: check_inverse() Überprüft, ob eins der Argumente ein '!' ist, und wenn ja, setzt es das 'invert' Flag, wenn das noch nicht geschehen sein sollte. Wenn sie 'true' liefert, solltest Du optind wie im Beispiel erhöhen. string_to_number() Konvertiert einen String zu einer Zahl in der gegebenen Größenordnung. Sie liefert -1, wenn der String ungültig ist oder außerhalb der Größenordnung liegt. exit_error() Diese Funktion sollte aufgerufen werden, wenn ein Fehler gefunden wird. Das erste Argument ist gewöhnlich 'PARAMETER_PROBLEM', was bedeutet, dass der User die Kommandozeile nicht richtig benutzt hat.

16 Neue Match-Funktionen Die _init() Funktion Deiner shared Library übergibt einen Pointer auf ein statisches 'struct iptables_match' an 'register_match()', was die folgenden Felder hat: next Dieser Pointer wird verwendet, um eine verlinkte Liste von Matches zu erstellen (wie sie für die listing-regeln verwendet wird). Am Anfang sollte er auf NULL gesetzt sein. name Der Name der Match-Funktion. Er sollte entsprechend dem Namen der Library gewählt sein (z.b. "tcp" für 'libipt_tcp.so'). version Dies wird gewöhnlich auf den NETFILTER_VERION Makro gesetzt: Es stellt sicher, dass das iptables Binary nicht aus Versehen die falsche Library auswählt. size Die Größe der Match-Daten für dieses Match; damit Du Dir keine Sorgen machen musst, wird sie von IPT_ALIGN() automatisch aufgerundet werden. userspacesize Für einige Matches ändert der Kernel intern einige Felder (z.b. im Fall von 'limit'). Das bedeutet, dass ein einfaches 'memcmp' nicht mehr ausreicht, um zwei Regeln zu vergleichen (benötigt für die delete-matching-rule Funktionalitaet). Wenn dies der Fall ist, platziere all die Felder, die sich nicht ändern, an den Anfang der Struktur, und lege die Größe der sich nicht ändernden Felder hier ab. help Eine Funktion, die die Synopsis der Option ausdruckt. init Dies kann verwendet werden, um etwas mehr Platz (wenn vorhanden) in der ipt_entry_match Stuktur zu schaffen, und um jegliche nfcache Bits zu setzen; Wenn Du etwas untersuchst, das Du nicht ausdrücken kannst, indem Du den Inhalt von '/linux/include/ netfilter_ipv4.h' verwendest, wende im NFC_UNKNOWN Bit einfach OR an. Dies wird vor 'parse()' aufgerufen werden. parse Dies wird aufgerufen, wenn eine nicht erkannte Option auf der Kommandozeile gesehen wird: Es sollte nicht NULL liefern, wenn diese Option tatsächlich für Deine Library bestimmt war. 'invert' liefert `true', wenn bereits ein '!' gesehen wurde. Der 'flags' Pointer ist für die exklusive Verwendung Deiner Match- Library und wird gewöhnlich dazu verwendet, eine Bitmaske von bestimmten Optionen zu speichern. Vergiss nicht, das nfcache Feld auszurichten. Wenn nötig, kannst Du die Größe der 'ipt_entry_match' Struktur erhöhen, indem Du Sie erneut

17 zuordnest, dann musst Du aber auch sicherstellen, dass die Größe durch den IPT_ALIGN Makro gehen muss. final_check Dies wird nach überstandener Kommandozeileneingabe aufgerufen. Ihm werden die für Deine Library reservierten Integer'flags' übergeben. Dies gibt Dir die Gelegenheit, zu überprüfen, ob alle benötigten Optionen angegeben wurden, zum Beispiel 'exit_error()' aufzurufen, wenn dies der Fall sein sollte. print Dies wird von Chain-Listing-Code verwendet, um jegliche zusätzliche Match-Information einer Regel (wenn vorhanden) ausdrucken (zum Standard Output). Das numerische Flag wird gesetzt, wenn der User es mit der '-n' Option angegeben hat. save Dies ist das Gegenteil von parse: Es wird von 'iptables-save' verwendet, um die Optionen, die die bestimmte Regel erstellt haben, zu reproduzieren. extra_opts Dies ist eine NULL-terminierte Liste von Extra-Optionen, die Deine Library anbietet. Dies wird vermischt mit den jetzigen Optionen und so an getopt_long übergeben; Für Details siehe Manpage. Es gibt noch extra Elemente am Ende dieser Struktur, die iptables intern verwendet: Du brauchst sie hier nicht zu setzen Neue Targets Die _init() Funktionen Deiner shared Libraries übergeben 'register_target()' einen Pointer auf ein statisches 'struct iptables_target', welches ähnliche Felder hat wie die iptables_match Strukturen, die oben detailliert beschrieben wurden. Manchmal braucht ein Target keine Library für den Userspace; Eine triviale musst Du sowieso erstellen: Es gab früher zu viele Probleme mit schlecht platzierten Libraries. [1m `libiptc' verwenden[0m libiptc ist die Kontrolle Library für iptables, entworfen, um Regeln im iptables Kernelmodul aufzulisten und zu manipulieren. Während seine jetzige Verwendung sich auf das iptables Tool beschränkt, macht es das Schreiben neuer Tools recht einfach. Um diese Funktionen nutzen zu können, musst Du root sein. Die Kerneltabellen selbst bestehen nur aus ein paar Tabellen mit Regeln und einer Anzahl von Nummern, die die Eintrittspunkte repräsentieren. Die Namen der Ketten ("INPUT") werden als Abstraktion von der Library unterstützt. Benutzerdefinierte Ketten werden benannt, indem ein Fehlerverweis vor dem Beginn der benutzerdefinierten Kette eingefügt wird, der den Kettennamen in

18 einer speziellen Datensektion des Targets enthält (Die Positionen der eingebauten Ketten werden durch die drei Eintrittspunkte der Tabelle definiert). Wenn 'iptc_init()' aufgerufen wird, wird die Tabelle einschließlich der Counter gelesen. Diese Tabelle wird von der `iptc_insert_entry()', `iptc_replace_entry()', `iptc_append_entry()', `iptc_delete_entry()', `iptc_delete_num_entry()', `iptc_flush_entries()', `iptc_zero_entries()', `iptc_create_chain()' `iptc_delete_chain()', und `iptc_set_policy()' Funktion manipuliert. Die Änderungen an der Tabelle werden nicht eher zurück geschrieben, bis die 'iptc_commit()' Funktion aufgerufen wird. Das bedeutet, dass es für zwei Benutzer der Library gleichzeitig möglich ist, auf derselben Kette zu operieren, um jeweils der Schnellere zu sein; Um das zu verhindern, ist Locking nötig, was aber Zurzeit nicht eingesetzt wird. Es gibt kein Wettrennen mit bei Countern, wie auch immer; Counter werden so in den Kernel zurück addiert, dass eine Erhöhung der Zähler zwischen dem Lesen und dem Schreiben der Tabelle immer noch in der neuen Tabelle auftauchen wird. Es gibt verschiedene Hilfsfunktionen: iptc_first_chain() Diese Funktion liefert den Namen der ersten Kette in dieser Tabelle. iptc_next_chain() Diese Funktion liefert den Namen der nächsten Kette in dieser Tabelle: NULL bedeutet, es gibt keine weiteren Ketten. iptc_builtin() Liefert true, wenn der Name der gegebenen Kette der Name einer eingebauten Kette ist. iptc_first_rule() This returns a pointer to the first rule in the given chain name: NULL for an empty chain. iptc_next_rule() Dies liefert einen Pointer auf die erste Regel im Namen der gegebenen Kette: NULL für eine leere Kette. iptc_get_target() Dies gibt das Target der gegebenen Regel. Wenn es kein erweitertes Target ist, wird der Name dieses Targets geliefert. Wenn es ein Sprung auf eine andere Kette ist, wird der Name dieser Kette geliefert. Wenn es ein Urteil (z.b. DROP) ist, wird dieser Name geliefert. Wenn die Regel kein Ziel hat (und eine accountig-style Regel), wird ein leerer String geliefert.

19 Beachte, dass Du diese Funktion verwenden solltest, anstatt den Wert des 'verdict' Felds der ipt_entry Struktur direkt zu benutzen, da sie die oben genannten weiteren Interpretationen des Standard Urteils bietet. iptc_get_policy() Dies liefert die Policy einer eingebauten Kette und füllt das Counter- argument mit den Treff-Statistiken dieser Policy. iptc_strerror() Diese Funktion liefert eine aussagekräftigere Erklärung von gescheitertem Code in der iptc Library. Wenn eine Funktion scheitert, wird es errno setzen: Dieser Wert kann an iptc_strerror() übergeben werden, um eine Fehlermeldung zu erhalten NAT verstehen Willkommen zu Network Address Translation im Kernel. Beachte, dass die angebotene Infrastruktur mehr für Vollständigkeit als für Effizienz entworfen wurde und dass weitere Entwicklungen die Effizins erhöhen können. Im Moment bin ich froh, dass es überhaupt funktioniert. NAT wird aufgeteilt in Connection Tracking (was die Pakete überhaupt nicht verändert) und in den NAT Code selbst. Connection Tracking kann auch als iptables Modul verwendet werden, um subtile Unterscheidungen von Zuständen zu machen, die NAT egal sind Connection Tracking Connection Tracking benutzt als Hooks die von der Priorität höhergestellten NF_IP_LOCAL_OUT und NF_IP_PRE_ROUTING, um Pakete zu sehen, bevor sie das System betreten. Das ncft Feld in skb ist ein Pointer auf einen der infos[] Arrays im Inneren von struct ip_conntrack. So können wir den Zustand von skb durch das Element bestimmen, auf welches dieser Array zeigt: Dieser Pointer erkennt beides, die State Struktur und die Beziehung des skb zu diesem Zustand. Der beste Weg, das 'nfct' Feld zu lesen, ist es, die 'ip_conntrack_get()' Funktion aufzurufen, die NULL liefert, wenn es nicht gesetzt ist, oder den Connection Pointer. Außerdem füllt sie ctinfo, was die Beziehung des Pakets zu der Verbindung beschreibt. Dieser nummerierte Typ hat folgende Werte: IP_CT_ESTABLISHED Das Paket ist Teil einer in Originalrichtung aufgebauten Verbindung. IP_CT_RELATED Das Paket steht in Zusammenhang mit der Verbindung und geht in die Originalrichtung.

20 IP_CT_NEW Das Paket versucht, eine neue Verbindung aufzubauen (offensichtlich geht es in die Originalrichtung). IP_CT_ESTABLISHED + IP_CT_IS_REPLY Das Paket ist Teil einer aufgebauten Verbindung, und zwar in Antwortrichtung. IP_CT_RELATED + IP_CT_IS_REPLY Das Paket steht in Zusammenhang mit der Verbindung und geht in die Antwortrichtung. Ein Antwortpaket kann also als solches identifiziert werden, indem man auf >= IP_CT_IS_REPLY testet NAT/Connection Tracking erweitern Diese Rahmenwerke wurden entworfen, um jegliche Art von Protokollen und verschiedenen Mapping-Arten unterzubringen. Manche dieser Mapping- Arten können sehr spezifisch sein, so wie load-balancing oder failover Mappings. Intern konvertiert Connection Tracking ein Paket zu einem 'Tupel', der den interessanten Teil des Pakets repräsentiert, bevor nach darauf zutreffenden Regeln gesucht wird. Dieser Tupel hat einen manipulierbaren Teil und einen nicht-manipulierbaren Teil; "src" und "dst" genannt, da dies die Ansicht des ersten Pakets in der Source NAT Welt ist (in der Destination NAT Welt würde es ein Antwortpaket sein). Die Tupel aller Pakete in demselben Paket-Stream in dieser Richtung sind gleich. Das Tupel eine TCP-Pakets enthält z.b. den manipulierbaren Teil (Quell- IP und Quellport) und den nicht-manipulierbaren Teil (Ziel-IP und Zielport) Der manipulierbare und der nicht-manipulierbare Teil müssen trotzdem nicht vom selben Typ sein; Das Tupel eines ICMP- Pakets enthält den manipulierbaren Teil (Quell-IP und ICMP-ID) und den nicht-manipulierbaren Teil (Ziel-IP und ICMP Typ und Code). Jedes Tupel hat ein Inverses, nämlich das Tupel des Antwortpakets in dem Stream. Das Inverse eines ICMP Ping-Pakets (icmp id 1234, von an ) ist zum Beispiel ein Ping Antwort Paket (icmp id 1234, von an ). Diese Tupel, die von 'struct ip_conntrack_tuple' repräsentiert werden, werden häufig verwendet. Tatsächlich ist das, zusammen mit dem Hook, an dem das Paket einging (was einen Effekt auf die zu erwartende Art der Manipulation hat) und dem beteiligten Device, die komplette Information über das Paket. Die meisten Tupel sind Teil von 'struct ip_conntrack_tuple_hash', was einen doppelt verlinkten Listeneintrag und einen Pointer auf die Verbindung, zu der das Paket gehört, hinzufügt.