\documentclass[a4paper,german]{article} \usepackage{linuxdoc-sgml} \usepackage{qwertz} \usepackage{url} \usepackage[latin1]{inputenc} \usepackage{babel} \usepackage{epsfig} \usepackage{null} \def\addbibtoc{ \addcontentsline{toc}{section}{\numberline{\mbox{}}\relax\bibname} }%end-preamble \setcounter{page}{1} \title{Linux netfilter Hacking HOWTO} \author{Rusty Russell, mailing list {\ttfamily netfilter@lists.samba.org}} \date{v1.0 Tue May 2 14:07:03 CST 2000} \begin{document} \maketitle Ins Deutsche übersetzt von Melanie Berg (mel@sekurity.de) \abstract{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 (http://www.gnu.org/copyleft/gpl.html).} \tableofcontents :%sno/ `/ `/gI \section{Einleitung\label{intro}} 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 Rusty's Unreliable Guide to Kernle Hacking und Rusty's Unreliable Guide to Kernel Locking. 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: \begin{tscreen} \begin{verbatim} sed `s/[^]aeio]ck/reak/' \end{verbatim} \end{tscreen} \subsection{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 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 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. 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): \begin{tscreen} \begin{verbatim} `` Also... wo ist das hier besser als KDE? `` \end{verbatim} \end{tscreen} (Dieses Motto hat sich ein wenig ausgeweitet: ``Peitsch mich aus, schlag mich, laß 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). \subsection{Was stimmte nicht mit dem, was wir im 2.0er und 2.2er Kernel hatten?} \begin{enumerate} \item Keine ausgebaute Infrastruktur, um Pakete an Userspace weiterzugeben: \begin{itemize} \item Kernelprogrammierung ist schwer \item Kernelprogrammierung muß in C/C++ gemacht werden \item Dynamische Filter-Policies gehören nicht in den Kernel \item 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. \end{itemize} \item Transparente Proxies sind eine Qual: \begin{itemize} \item Wir untersuchen {\bfseries jedes} Paket, um zu sehen, ob ein Socket an diese Adresse gebunden ist \item Root darf an fremde Adressen binden \item Lokal-generierte Pakete können nicht redirected werden \item 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. \item REDIRECT koordiniert sich nicht mit der TCP/UDP Portzuordnung: Ein Benutzer kann einen Port durch eine REDIRECT-Regeln shadowen. \item Es ist während der 2.1er-Serie mindestens zweimal zusammengebrochen. \item 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. \end{itemize} \item Es ist nicht mögliche, Paketfilter-Regeln unabhängig von der Adresse der Schnittstelle zu erstellen: \begin{itemize} \item Um lokal-generierte oder lokal-bestimmte Pakete von durchgehenden Paketen unterscheiden zu können, muß die lokale Adresse der Schnittstelle bekannt sein. \item Sogar das reicht bei Redirection oder Masquerading nicht aus. \item Die FORWARD-Kette besitzt nur Informationen über die ausgehende Schnittstelle, was bedeutet, dass Du herausfinden mußt, woher ein Paket kam, indem Du Dein Wissen über die Netzwerk-Topologie anwendest. \end{itemize} \item Masquerading ist abhängig von Paketfiltern:Interaktionen zwischen Paketfiltern und Masquerading machen eine Firewall komplex: \begin{itemize} \item Beim Eingangsfilter scheinen Antwortpakete für den Rechner selbst bestimmt zu sein \item Beim Forward-Filter werden demaskierte Pakete überhaupt nicht gesehen \item Beim Ausgangsfilter scheinen Pakete vom lokalen Rechner zu kommen \end{itemize} \item TOS-Manipulation, Redirect, ICMP unreachable und mark (welche Effekte auf Portforwarding, Routing und QoS haben können) hängen ebenfalls vom Paketfilter-Code ab. \item ipchains-Code ist weder modular noch erweiterbar (zum Beispiel MAC-Adressen Filter, Filtern nach Optionen, etc). \item Mangel an ausreichender Infrastruktur hat zu einem Überfluß von von verschiedenen Techniken geführt: \begin{itemize} \item Masquerading plus Per-Protokoll Module \item Schnelles, statisches NAT durch Routing Code (hat keine Per-Protokoll Routinen) \item Portforwarding, Redirect, Auto-Forwarding \item Das Linux NAT und virtuelle Server Projekte. \end{itemize} \item Inkompatibilität zwischen CONFIG\_NET\_FASTROUTE und Paketfiltern: \begin{itemize} \item Weitergeleitete Pakete gehen trotzdem durch drei Ketten \item Keine Möglichkeit, zu sagen, ob diese Ketten umgangen werden können \end{itemize} \item Wegen Routing-Protection (z.B. Verifikation der Quelladresse) keine Möglichkeit, verworfene Pakete zu untersuchen. \item Keine Möglichkeit, automatisch die Zähler auf Paketfilter-Regeln zu lesen. \item CONFIG\_IP\_ALWAYS\_DEFRAG ist eine Compilezeit-Option, die das Leben für Distributionen, die einen general-purpose Kernel wollen, schwer macht. \end{enumerate} \subsection{Wer bist Du?} Ich bin der einzige, der dumm genug ist, das zu tun. Als ipchains Co-Autor und jetziger Linux Kernel IP Firewall Maintainer sehe ich viele der Probleme, die die Leute mit dem jetzigen System haben, da ich erkenne, was sie alles machen wollen. \subsection{Wieso stürzt es ab?} Woah! Du hättest es {\bfseries letzte} Woche sehen sollen! Weil ich kein so guter Programmierer bin, wir wir alle es uns wünschen würden, und ich natürlich nicht alle Szenarien getestet habe, wegen Mangel an Zeit, Ausstattung und/oder Inspiration. Ich habe eine Testumgebung, und ich will Dich ermutigen, daran teilzunehmen. \section{Wo kann ich die neueste Version herbekommen?} Es gibt einen CVS Server auf samba.org, der die neuesten HOWTOs, Anwendertools und Testseiten enthält. Wenn Du browsen möchtest, kannst Du das Webinterface benutzen: \nameurl{http://www.samba.org/cgi-bin/cvsweb/netfilter/}{Web Interface}. Um die neuesten Quellcodes zu bekommen, kannst Du folgendes tun: \begin{enumerate} \item Log Dich anonym auf dem SAMBA CVS Server ein: \begin{tscreen} \begin{verbatim} cvs -d :pserver:cvs@cvs.samba.org:/cvsroot login \end{verbatim} \end{tscreen} \item Wenn Du nach einem Paßwort gefragt wirst, tippe `cvs'. \item Überprüfe den verwendeten Code: \begin{tscreen} \begin{verbatim} cvs -d :pserver:cvs@cvs.samba.org:/cvsroot co netfilter \end{verbatim} \end{tscreen} \item Um ein Update auf die neueste Version zu bekommen, verwende \begin{tscreen} \begin{verbatim} cvs update -d -P \end{verbatim} \end{tscreen} \end{enumerate} \section{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 folgendermaßen aus: %\begin{tscreen} %\begin{verbatim} %Ein Paket, das das Netfilter System durchreist: % % --->[1]--->[ROUTE]--->[3]--->[4]---> % | ^ % | | % | [ROUTE] % v | % [2] [5] % | ^ % | | % v | %\end{verbatim} %\end{tscreen} \begin{center} {% Picture saved by xtexcad 2.4 \unitlength=1.000000pt \begin{picture}(280.00,120.00)(0.00,0.00) \put(110.00,20.00){\vector(0,-1){20.00}} \put(110.00,100.00){\vector(0,-1){60.00}} \put(220.00,0.00){\vector(0,1){20.00}} \put(220.00,80.00){\vector(0,1){30.00}} \put(220.00,40.00){\vector(0,1){20.00}} \put(260.00,110.00){\vector(1,0){20.00}} \put(200.00,110.00){\vector(1,0){40.00}} \put(140.00,110.00){\vector(1,0){40.00}} \put(40.00,110.00){\vector(1,0){40.00}} \put(0.00,110.00){\vector(1,0){20.00}} \put(110.00,30.00){\makebox(0.00,0.00){2}} \put(220.00,30.00){\makebox(0.00,0.00){5}} \put(250.00,110.00){\makebox(0.00,0.00){4}} \put(190.00,110.00){\makebox(0.00,0.00){3}} \put(30.00,110.00){\makebox(0.00,0.00){1}} \put(190.00,60.00){\framebox(60.00,20.00){Route}} \put(110.00,30.00){\circle{20.00}} \put(30.00,110.00){\circle{20.00}} \put(220.00,30.00){\circle{20.00}} \put(250.00,110.00){\circle{20.00}} \put(190.00,110.00){\circle{20.00}} \put(80.00,100.00){\framebox(60.00,20.00){Route}} \end{picture}} \end{center} \label{netfilter-traversal} 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 Prozeß bestimmt ist. Der Routing-Code kann unroutebare 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 Prozeß (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. \subsection{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. 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: \begin{enumerate} \item NF\_ACCEPT: Die Reise wie gewöhnlich fortsetzen. \item NF\_DROP: das Paket verwerfen, die Reise nicht fortsetzen. \item NF\_STOLEN: Ich habe das Paket übernommen, setz die Reise nicht fort. \item NF\_QUEUE: Das Paket einreihen (gewöhnlich für Userspace). \item NF\_REPEAT: Diesen Hook erneut aufrufen. \end{enumerate} 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. \subsection{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. \subsubsection{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 weiterzuverwenden. \subsubsection{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. \paragraph{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 unabhängige Einheiten zu sein. \subsection{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). \subsection{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. \section{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. \subsection{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. 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. \subsubsection{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: \begin{enumerate} \item Einem `struct ip\_entry'. \item Null oder mehr `struct ipt\_entry\_match' Strukturen, an jede Platz für Variablen (0 oder mehr Bytes) von Daten angehängt. \item Einer `struct ipt\_entry\_target' Struktur, an jede Platz für Variablen (0 oder mehr Bytes) von Daten angehängt. \end{enumerate} 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: \begin{enumerate} \item Einen `struct ipt\_ip' Teil, der die Bestimmungen für den IP-Header enthält, der zutreffen soll. \item Ein `nf\_cache' Bitfeld, das zeigt, welche Teile des Pakets diese Regel untersucht hat. \item Ein `target\_offset' Feld, das den Absatz vom Anfang dieser Regel angibt, wo die ipt\_entry\_target Struktur beginnt. \item Ein `next\_offset' Feld, das die absolute Größe dieser Regel angibt, einschließlich Treffer und Ziele. \item Ein `comefrom' Feld, das vom Kernel benutzt wird, um die Reise des Pakets zurückzuverfolgen. \item Ein `struct ipt\_counters' Feld, was die Paket- und Bytezähler für Pakete, die auf diese Regel gepaßt haben, enthält. \end{enumerate} 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). Wegen der trickreichen Natur der Datenstruktur einer Regel werden einige Hilfsroutinen angeboten: \begin{description} \item[ipt\_get\_target()] \mbox{} Diese Funktion liefert einen Pointer auf das Target einer Regel. \item[IPT\_MATCH\_ITERATE()] \mbox{} 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. \item[IPT\_ENTRY\_ITERATE()] \mbox{} 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. \end{description} \subsubsection{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 Userspace- und Kernelspace 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 Platformen in `libiptc.h' behandelt. \subsubsection{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. 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. \subsection{iptables erweitern} Weil ich so faul bin, ist {\ttfamily 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). {\ttfamily iptables} erweitern besteht aus zwei Teilen: den Kernel erweitern, indem man ein neues Modul schreibt, und möglicherweise das Anwendungsprogramm {\ttfamily iptables} erweitern, indem man eine neue Shared Library schreibt. \subsubsection{Der Kernel} Ein Kernelmodul selbst zu schreiben ist ziemlich einfach, wie Du an den Beispielen sehen kannst. Eine Sache, auf die Du achten mußt, ist, dass Dein Code integriert werden muß: Es kann ein Paket von Anwenderseite her ankommen, während ein anderes an einem Interrupt eintrifft. Tatsächlich kann es ab 2.3.4 bei SMP vorkommen, dass ein Paket an einem Interrupt pro CPU eintrifft. Folgende Funktionen mußt Du kennen: \begin{description} \item[init\_module()] \mbox{} Das ist der Eintrittspunkt des Moduls. Es liefert eine negative Zahl oder 0, wenn Netfilter es erfolgreich registriert. \item[cleanup\_module()] \mbox{} Das ist der Austrittspunkt des Moduls; es soll die Registration beim Kernel wieder aufheben. \item[ipt\_register\_match()] \mbox{} 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). \item[ipt\_register\_target()] \mbox{} 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). \item[ipt\_unregister\_target()] \mbox{} Um die Registration des Ziel aufzuheben. \item[ipt\_unregister\_match()] \mbox{} Um die Registration des Treffers aufzuheben. \end{description} 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. \paragraph{Neue Match-Funktionen} Neue match-Funktionen werden gewöhnlich als alleinstehende 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: \begin{description} \item[list] \mbox{} Dieses Feld ist auf irgendeinen Blödsinn gesetzt, z.B. `$\{$NULL, NULL$\}$'. \item[name] \mbox{} 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, muß das Modul ``ipt\_mac.o'' heißen), damit es automatisch geladen werden kann. \item[match] \mbox{} 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. \item[checkentry] \mbox{} 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 muß, 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. \item[destroy] \mbox{} 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. \item[me] \mbox{} 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. \end{description} \paragraph{Neue Targets} Neue Targets werden auch gewöhnlich als alleinstehende 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: \begin{description} \item[list] \mbox{} Dieses Feld ist auf irgendeinen Blödsinn gesetzt, z.B. `$\{$NULL, NULL$\}$'. \item[name] \mbox{} 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, muß das Modul ``ipt\_REJECT.o'' heißen), damit es automatisch geladen werden kann. \item[target] \mbox{} 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). \item[checkentry] \mbox{} 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. \item[destroy] \mbox{} 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. \item[me] \mbox{} 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. \end{description} \paragraph{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: \begin{description} \item[list] \mbox{} Dieses Feld ist auf irgendeinen Blödsinn gesetzt, z.B. `$\{$NULL, NULL$\}$'. \item[name] \mbox{} 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, muß das Modul ``ipt\_nat.o'' heißen), damit es automatisch geladen werden kann. \item[table] \mbox{} Dies ist ein voll ausgenutztes `struct 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. \item[valid\_hooks] \mbox{} 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. \item[lock] \mbox{} Dies ist das read-write Lock für die vollständige Tabelle, initialisiere es auf RW\_LOCK\_UNLOCKED. \item[private] \mbox{} Dies wird vom ip\_tables Code intern verwendet. \end{description} \subsubsection{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 {\ttfamily 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 {\ttfamily 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: \begin{description} \item[check\_inverse()] \mbox{} Ü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. \item[string\_to\_number()] \mbox{} 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. \item[exit\_error()] \mbox{} 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. \end{description} \paragraph{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: \begin{description} \item[next] \mbox{} 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. \item[name] \mbox{} Der Name der Match-Funktion. Er sollte entsprechend dem Namen der Library gewählt sein (z.B. ``tcp'' für `libipt\_tcp.so'). \item[version] \mbox{} Dies wird gewöhnlich auf den NETFILTER\_VERION Makro gesetzt: Es stellt sicher, dass das {\ttfamily iptables} Binary nicht aus Versehen die falsche Library auswählt. \item[size] \mbox{} Die Größe der Match-Daten für dieses Match; damit Du Dir keine Sorgen machen mußt, wird sie von IPT\_ALIGN() automatisch aufgerundet werden. \item[userspacesize] \mbox{} 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 Funktionalität). Wenn dies der Fall ist, plaziere all die Felder, die sich nicht ändern, an den Anfang der Struktur, und lege die Größe der sich nicht ändernden Felder hier ab. \item[help] \mbox{} Eine Funktion, die die Synopsis der Option ausdruckt. \item[init] \mbox{} 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. \item[parse] \mbox{} 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. Vergiß nicht, das nfcache Feld auszurichten. Wenn nötig, kannst Du die Größe der `ipt\_entry\_match' Struktur erhöhen, indem Du Sie erneut zuordnest, dann mußt Du aber auch sicherstellen, dass die Größe durch den IPT\_ALIGN Makro gehen muß. \item[final\_check] \mbox{} 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. \item[print] \mbox{} 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. \item[save] \mbox{} Dies ist das Gegenteil von parse: Es wird von `iptables-save' verwendet, um die Optionen, die die bestimmte Regel erstellt haben, zu reproduzieren. \item[extra\_opts] \mbox{} 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. \end{description} Es gibt noch extra Elemente am Ende dieser Struktur, die {\ttfamily iptables} intern verwendet: Du brauchst sie hier nicht zu setzen. \paragraph{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 mußt Du sowieso erstellen: Es gab früher zu viele Probleme mit schlecht plazierten Libraries. \subsubsection{`libiptc' verwenden} {\ttfamily libiptc} ist die Kontroll 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, mußt 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 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ückgeschrieben, 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 zur Zeit nicht eingesetzt wird. Es gibt kein Wettrennen mit bei Countern, wie auch immer; Counter werden so in den Kernel zurückaddiert, dass eine Erhöhung der Zähler zwischen dem Lesen und dem Schreiben der Tabelle immernoch in der neuen Tabelle auftauchen wird. Es gibt verschiedene Hilfsfunktionen: \begin{description} \item[iptc\_first\_chain()] \mbox{} Diese Funktion liefert den Namen der ersten Kette in dieser Tabelle. \item[iptc\_next\_chain()] \mbox{} Diese Funktion liefert den Namen der nächsten Kette in dieser Tabelle: NULL bedeutet, es gibt keine weiteren Ketten. \item[iptc\_builtin()] \mbox{} Liefert true, wenn der Name der gegebenen Kette der Name einer eingebauten Kette ist. \item[iptc\_first\_rule()] \mbox{} This returns a pointer to the first rule in the given chain name: NULL for an empty chain. \item[iptc\_next\_rule()] \mbox{} Dies liefert einen Pointer auf die erste Regel im Namen der gegebenen Kette: NULL für eine leere Kette. \item[iptc\_get\_target()] \mbox{} 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. 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. \item[iptc\_get\_policy()] \mbox{} Dies liefert die Policy einer eingebauten Kette und füllt das Counterargument mit den Treff-Statistiken dieser Policy. \item[iptc\_strerror()] \mbox{} 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. \end{description} \subsection{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 Effizienz 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. \subsubsection{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 Paket zu der Verbindung beschreibt. Dieser numerierte Typ hat folgende Werte: \begin{description} \item[IP\_CT\_ESTABLISHED] \mbox{} Das Paket ist Teil einer in Originalrichtung aufgebauten Verbindung. \item[IP\_CT\_RELATED] \mbox{} Das Paket steht in Zusammenhang mit der Verbindung und geht in die Originalrichtung. \item[IP\_CT\_NEW] \mbox{} Das Paket versucht, eine neue Verbindung aufzubauen (offensichtlich geht es in die Originalrichtung). \item[IP\_CT\_ESTABLISHED + IP\_CT\_IS\_REPLY] \mbox{} Das Paket ist Teil einer aufgebauten Verbindung, und zwar in Antwortrichtung. \item[IP\_CT\_RELATED + IP\_CT\_IS\_REPLY] \mbox{} Das Paket steht in Zusammenhang mit der Verbindung und geht in die Antwortrichtung. \end{description} Ein Antwortpaket kann also als solches indentifiziert werden, indem man auf {$>$}= IP\_CT\_IS\_REPLY testet. \subsection{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 fail-over Mappings. Intern konvertiert Connection Tracking ein Paket zu einem `Tupel', der den interessanten Teil des Pakets repreasentiert, 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 192.168.1.1 an 1.2.3.4) ist zum Beispiel ein Ping Antwort Paket (icmp id 1234, von 1.2.3.4 an 192.168.1.1). 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. Eine Verbindung wird von `struct ip\_conntrack' repräsentiert: Es hat zwei `struct ip\_conntrack\_tuple\_hash' Felder: Eins, was sich auf die Richtung des Originalpakets bezieht (tuplehash{[}IP\_CT\_DIR\_ORIGINAL]), und eins, was sich auf die Antwortrichtung des Pakets bezieht (tuplehash{[}IP\_CT\_DIR\_REPLY]). Wie auch immer, das erste, was der NAT Code tut, ist nachzusehen, ob der Connection Tracking Code es geschafft hat, ein Tupel zu extrahieren und ein bestehende Verbindung zu finden, indem er in das nfct Feld von skbuff sieht; Das sagt uns, ob es ein Versuch ist, eine neue Verbindung aufzubauen, oder, wenn nicht, in welche Richtung das ganze geht; im letzteren Fall werden die Manipulationen ausgeführt, die vorher für diese Verbindung bestimmt wurden. Wenn es der Anfang einer neuen Verbindung war, suchen wir nach einer Regel für dieses Tupel, indem wir den Standard-Mechanismus von iptables verwenden. Trifft eine Regel zu, wird sie verwendet, um Manipulationen sowohl für die Original-, als auch für die Antwortrichtung auszuführen; dem Connection Tracking Code wird mitgeteilt, dass die zu erwartenden Antwort sich geändert hat. Dann wird das Paket wie oben beschrieben verändert. Wenn es keine Regel gibt, wird eine `Null' Bindung erstellt: Das mappt das Paket gewöhnlich nicht, stellt aber sicher, dass wir keinen anderen Stream über den existierenden mappen. Manchmal kann die Null-Bindung nicht erstellt werden, weil wir bereits einen existierenden Stream darübergemappt haben. In diesem Fall könnte die Pre-Protocol Manipulation versuchen, ihn zu remappen, obwohl es vom Namen her keine Null-Bindung ist. \subsubsection{Standard NAT-Targets} NAT Targets sind wie alle anderen iptables Target-Erweiterungen, außer, dass sie darauf bestehen, nur in der `nat' Tabelle verwendet zu werden. Sowohl SNAT als auch DNAT Targets verwenden `struct ip\_nat\_multi\_range' als Extradaten; dies wird benutzt, um einen Bereich von Adressen zu bestimmen, auf denen ein Mapping gültig ist. Ein Element dieses Bereichs, `struct ip\_nat\_range', besteht aus einer inklusiven minimalen und maximalen IP-Adresse und aus einem inklusiven minimalen und maximalen Wert zur Protokollbestimmung (zum Beispiel TCP Ports). Es gibt auch Platz für Flags, die uns sagen, ob die IP-Adresse gemappt werden kann (manchmal wollen wir nur den protokoll-spezifischen Teil eines Tupels mappen, nicht die IP), oder ein anderes, das uns sagt, dass der protokoll-spezifische Teil des Bereichs `valid' ist. Ein Multi-Range ist ein Array aus diesen `struct ip\_nat\_range' Elementen; das bedeutet, dass ein Bereich ``1.1.1.1-1.1.1.2 Ports 50-55 AND 1.1.1.3 Port 80'' sein kann. Jedes Element wird zu dem Bereich dazuaddiert (Union, für die, die diese Theorie mögen). \subsubsection{Neue Protokolle} \paragraph{Der Kernel von innen} Ein neues Protokoll zu implementieren bedeutet zuerst, zu entscheiden, was der manipulierbare und was der nicht-manipulierbare Teil des Tupels sein sollen. Jedes Teil des Tupels hat die Eigenschaft, dass es den Stream eindeutig identifiziert. Der manipulierbare Teil des Tupel ist der Teil, mit dem Du NAT machen kannst: Für TCP ist das der Quellport, für ICMP ist das die ICMP id; etwas, das das ``Stream Identifier'' benutzt werden kann. Der nicht-manipulierbare Teil ist der Rest des Pakets, der den Stream zwar auch eindeutig identifiziert, mit dem wir aber nicht spielen können (z.B. TCP Zielport, ICMP Typ). Sobald Du Dich dazu entschieden hast, kannst Du eine Erweiterung für den Connection Tracking Code schreiben und die `ip\_conntrack\_protocol' Struktur, die Du an `ip\_conntrack\_register\_protocol()' übergeben mußt, ausbauen. Die Felder von `struct ip\_conntrack\_protocol' sind: \begin{description} \item[list] \mbox{} Setz es auf `$\{$NULL, NULL$\}$'; verwendet, um sich der Liste zu nähern. \item[proto] \mbox{} Die Nummer Deines Protokolls, siehe `/etc/protocols'. \item[name] \mbox{} Der Name Deines Protokolls. Das ist der Name, den der Anwender sehen wird; meistens ist es das beste, den entsprechenden Namen aus `/etc/protocols' zu verwenden. \item[pkt\_to\_tuple] \mbox{} Die Funktion, die die protokollspezifischen Teile des Tupels ausfüllt, sobald ihr das Paket übergeben wird. Der `datah' Pointer zeigt auf den Anfang des Headers (direkt hinter der IP-Adresse), und datalen ist die Länge des Pakets. Es liefert NULL, wenn das Paket nicht lang genug ist, um Header-Informationen zu enthalten; datalen wird (gezwungenermaßen) immer mindestens 8 Byte lang sein. \item[invert\_tuple] \mbox{} Diese Funktion wird einfach dazu verwendet, den protokollspezifischen Teil des Tupels so zu ändern, wie eine Antwort auf dieses Paket aussehen würde. \item[print\_tuple] \mbox{} Diese Funktion wird verwendet, um den protokollspezifischen Teil eines Tupels auszudrucken; gewöhnlich wird es mit sprintf() in den mitgegebenen Buffer geschrieben. Geliefert wird die Anzahl von verwendeten Buffer-Zeichen. Dies wird verwendet, um den Status des /proc Eintrags zu drucken. \item[print\_conntrack] \mbox{} Diese Funktion wird benutzt, um den privaten Teil der Conntrack Struktur (wenn vorhanden) zu drucken. Sie wird auch verwendet, um den Status unter /proc zu drucken. \item[packet] \mbox{} Diese Funktion wird aufgerufen, wenn ein Paket erkannt wird, das Teil einer aufgebauten Verbindung ist. Du bekommst einen Pointer auf die Conntrack Struktur, den IP-Header, die Länge und ctinfo. Du gibt ein Urteil über das Paket zurück (gewöhnlich NF\_ACCEPT), oder -1 wenn das Paket kein gültiger Teil der Verbindung ist. Innerhalb dieser Funktion kannst Du, wenn Du willst, diese Verbindung löschen, Du solltest aber folgendes Idiom verwenden, um races zu vermeiden: \begin{tscreen} \begin{verbatim} if (del_timer(&ct->timeout)) ct->timeout.function((unsigned long)ct); \end{verbatim} \end{tscreen} \item[new] \mbox{} Diese Funktion wird aufgerufen, wenn ein Paket zum ersten Mal eine Verbindung aufbaut; es gibt kein ctinfo arg, da das erste Paket der Definition nach ctinfo IP\_CT\_NEW ist. Wenn es beim Verbindungsaufbau scheitert, liefert die Funktion 0, oder im selben Moment ein Connection Timeout. \end{description} Sobald Dein fertig bist und getestet hast, dass Du Dein neues Protokoll einsetzen kannst, ist es an der Zeit, NAT beizubringen, wie es zu übersetzen ist. Dies bedeutet, ein neues Modul zu schreiben; eine Erweiterung zum NAT-Code und die `ip\_conntrack\_protocol' Struktur, die Du an `ip\_conntrack\_register\_protocol()' übergeben mußt. \begin{description} \item[list] \mbox{} Setz es auf `$\{$NULL, NULL$\}$'; verwendet, um sich der Liste zu nähern. \item[name] \mbox{} Der Name Deines Protokolls. Das ist der Name, den der Anwender sehen wird; meistens ist es das beste, den entsprechenden Namen aus `/etc/protocols' zu verwenden, um auto-loading zu ermöglichen, wie wir später noch sehen werden. \item[protonum] \mbox{} Die Nummer Deines Protokolls, siehe `/etc/protocols'. \item[manip\_pkt] \mbox{} Das ist die andere Hälfte der von Conntection Tracking benutzten `ptk\_to\_tuple' Funktion: Stell sie Dir als ``tuple\_to\_ptk'' vor. Trotzdem gibt es ein paar Unterschiede: Du bekommst einen Pointer auf den Anfang des IP-Headers, und die Gesamtlänge des Pakets. Das liegt daran, dass manche Protokolle (UDP, TCP) den IP-Header kennen müssen. Dir wird das `ip\_nat\_tuple\_manip' Feld des Tupels gegeben (ich meine das ``src'' Feld) statt des ganzen Tupels und der Art der Manipulation, die auszuführen ist. \item[in\_range] \mbox{} Diese Funktion wird verwendet, um zu sagen, ob manipulierbarer Teil des gegebenen Tupels im gegebenen Bereich liegt. Diese Funktion ist ein bißchen trickreich: Wir erhalten die Art der Manipulation, die auf das Tupel angewandt wurde, die uns sagt, wie wir den Bereich interpretieren können (ist es ein Quell- oder ein Zielbereich, auf den wir abzielen?). Diese Funktion wird benutzt, um zu überprüfen, ob ein existierendes Mapping uns in den richtigen Bereich bringt, außerdem noch, um zu überprüfen, ob vielleicht überhaupt keine Manipulation nötig ist. \item[unique\_tuple] \mbox{} Diese Funktion ist das Herzstück von NAT: Wir erhalten ein Tupel und einen Bereich und sollen den Per-Protocol Teil des Tupels verändern, um es im Bereich zu plazieren und somit einzigartig zu machen. Wenn wir kein unbenutztes Tupel in diesem Bereich finden, wird 0 geliefert. Außerdem bekommen wir einen Pointer auf die Conntrack Struktur, welcher für ip\_nat\_user\_tuple() benötigt wird. Gewöhnlich wird einfach der Per-Protocol Teil des Tupels durch den Bereich iteriert, und `ip\_nat\_user\_tupel()' wird solange überprüft, bis es einmal false liefert. Beachte, dass der Null-Mapping Fall bereits überprüft wurde: Entweder liegt er außerhalb des gegebeben Bereichs, oder er ist schon besetzt. Wenn IP\_NAT\_RANGE\_PROTO\_SPECIFIED gesetzt ist, bedeutet dies, dass der Anwender NAT, und nicht NAPT macht: Etwas Vernünftiges mit dem Bereich tun. Wenn kein Mapping erwünscht ist (In TCP zum Beispiel sollte kein Ziel-Mapping den TCP-Port ändern, wenn es nicht ausdrücklich verlangt wird), wird 0 geliefert. \item[print] \mbox{} Given a character buffer, a match tuple and a mask, write out the per-protocol parts and return the length of the buffer used. \item[print\_range] \mbox{} Mit einem gegebenen Charakter-Buffer, einem Match-Tupel und einer Maske wird dies den Per-Protocol Teil ausdrucken und die Länge des Buffers liefern. \end{description} \subsubsection{Neue NAT-Targets} Das ist der wirklich interessante Teil. Du kannst neue NAT-Targets schreiben, die einen neuen Mapping-Typ bieten: Zwei Extra-Targets werden im Standard Package geliefert: MASQUERADE und REDIRECT. Diese illustrieren recht einfach das Potential und die Macht des Schreibens neuer NAT-Targets. Sie werden genauso wie alle anderen iptables Targets geschrieben, nur intern werden sie `ip\_nat\_setup\_info()' aufrufen und die Verbindung extrahieren. \subsubsection{Protokoll-Hilfen für TCP und UDP} Dieser Teil befindet sich noch in der Entwicklung. \subsection{Understanding Netfilter} Netfilter ist ziemlich simpel und wurde in den vorangegangenen Sektionen recht ausführlich beschrieben. Wie auch immer, manchmal ist es notwendig, weiter zu gehen als die NAT oder die ip\_tables Infrastruktur bietet, oder vielleicht möchtest Du sie auch vollständig ersetzen. Ein wichtiger Punkt bei Netfilter (Naja, in der Zukunft) ist Caching. Jedes skb hat ein `nfcache' Feld: Eine Bitmaske, die sagt, welche Felder im Header untersucht wurden und ob das Paket verändert wurde oder nicht. Die Idee ist, dass auf jeden Netfilter Hook in den dazu relevanten Bits eine OR-Verknüpfung angewandt werden kann, so dass wir später ein Cache-System schreiben können, das clever genug sein wird, um zu erkennen, wann Pakete nicht an Netfilter gereicht werden müssen. Die wichtigsten Bits sind NFC\_ALTERED, was bedeutet, dass das Paket verändert wurde (Dies wird für den NF\_IP\_LOCAL\_OUT Hook von IPv4 bereits verwendet, um geänderte Pakete erneut zu routen), und NFC\_UNKNOWN, was aussagt, dass Caching nicht angewandt werden sollte, da einige Eigenschafte untersucht wurden, die nicht ausgedrückt werden konnten. Im Zweifelsfall solltest Du das NFC\_UNKNOWN Flag in das nfcache Feld von skb in Deinem Hook setzen. \subsection{Neue Netfilter-Module schreiben} \subsubsection{Netfilter-Schnittstellen benutzen} Um Pakete im Kernel zu empfangen/behandeln, kannst Du einfach ein Modul schreiben, welches beim ``Netfilter Hook'' registriert. Im Grunde ist das ein Ausdruck von Interesse an einem gegebenen Punkt; der genaue Punkt ist protokollspezifisch und wird in protokollspezifischen Netfilter-Headern, wie ``netfilter\_ipv4.h'', definiert. Um Netfilter Hooks zu registrieren (und das wieder aufzuheben), benutzt Du die `nf\_register\_hook' und die `nf\_unregister\_hook' Funktionen. Beide benötigen einen Pointer auf `struct nc\_hook\_ops', welchen Du wie folgt benutzt: \begin{description} \item[list] \mbox{} Setz es auf `$\{$NULL, NULL$\}$'; verwendet, um sich der Liste zu nähern. \item[hook] \mbox{} Die Funktion, die aufgerufen wird, wenn ein Paket auf diesen Hook-Punkt trifft. Deine Funktion muß NC\_ACCEPT, NC\_DROP oder NC\_QUEUE liefern. Wenn NC\_ACCEPT geliefert wird, wird der nächste an diesen Punkt angehängte Hook aufgerufen werden. Wenn NC\_DROP geliefert wird, wird das Paket verworfen werden. Wenn NC\_QUEUE geliefert wird, wird das Paket gequeued werden. Wenn Du einen Pointer auf einen skb Pointer erhälst, kannst Du skb, wenn Du willst, vollständig ersetzen. \item[flush] \mbox{} Zur Zeit unbenutzt: Es wurde entworfen, um Paket-Treffer weiterzureichen, wenn der Cache gelöscht wird. Vielleicht wird es niemals implementiert werden: Setz es auf NULL. \item[pf] \mbox{} Die Protokollfamilie, zum Beispiel `PF\_INET' für IPv4. \item[hooknum] \mbox{} Die Nummer des Hooks, für den Du Dich interessierst, z.B. `NC\_IP\_LOCAL\_OUT'. \end{description} \subsubsection{Eingereihte Pakete behandeln} Dies ist die zur Zeit von `ip\_queue' verwendete Schnittstelle; Du kannst hier registrieren, um Pakete für ein gegebenes Protokoll zu behandeln. Hier herrscht eine ähnliche Semantik wie bei der Registrierung für einen Hook, außer, dass Du eine Behandlung des Pakets blockieren kannst. Außerdem siehst Du nur Pakete, für die ein Hook mit `NC\_QUEUE' geantwortet hat. Die zwei Funktionen, die verwendet werden, um Interesse an gequeueten Paketen zu registrieren, heißen `nc\_register\_queue\_handler()' und `nf\_unregister\_queue\_handler()'. Die Funktion, die Du registrieren wirst, wird mit dem `void *' Pointer aufgerufen werden, mit dem Du sie an `nf\_register\_queue\_handler()' übergeben hast. Wenn niemand registriert ist, ein Paket zu behandeln, ist das Liefern von NF\_QUEUE äquivalent zum Liefern von NF\_DROP. Die Pakete werden eingereiht werden, sobald Du Dich dafür registriert hast. Du kannst mit ihnen tun, wasimmer Du willst, wenn Du aber fertig bist mit ihnen, mußt Du `nf\_reinject()' aufrufen (benutz nicht einfach nur `kfree\_skb()'). Wenn Du ein skb reinjizierst, übergibst Du ihm das skb, das dem Queue-Handler gegebene `struct nf\_info' und ein Urteil: NF\_DROP verwirft es, NF\_ACCEPT läßt es weiter durch die Hooks iterieren, NF\_QUEUE reiht sie erneut ein und NF\_REPEAT bewirkt, dass der Hook, der das Paket eingereiht hat, erneut konsultiert wird (Paß auf unendliche Loops auf!). Du kannst in `struct nf\_info' sehen, um hilfreiche Informationen über das Paket zu bekommen, z.B. über die Schnittstelle oder den betreffenden Hook. \subsubsection{Kommandos vom Anwender empfangen} Netfilter Komponenten wollen mit dem Anwender interagieren. Die Methode hierfür ist die Verwendung des setsockopt Mechanismus. Beachte, dass jedes Protokoll modifiziert werden muß, um nf\_setsockopt() für nicht verstandene setsockopt Nummern (und nf\_getsockopt() für getsockopt Nummern) aufrufen zu können, und das bis jetzt nur IPv4, IPv6 und DECnet modifiziert wurden. Wir verwenden eine mittlerweile bekannte Technik: Wir registrieren ein `struct nf\_sockopt\_ops', indem wir nf\_register\_sockopt() aufrufen. Die Felder dieser Struktur sind wie folgt: \begin{description} \item[list] \mbox{} Setz es auf `$\{$NULL, NULL$\}$'; verwendet, um sich der Liste zu nähern. \item[pf] \mbox{} Die Protokollfamilie, die Du behandelst, zum Beispiel PF\_INET. \item[set\_optmin] \mbox{} und \item[set\_optmax] \mbox{} Diese bestimmen den (exklusiven) Bereich der verwendeten setsockopt Nummern. 0 und 0 bedeutet also, dass Du keine setsockopt Nummern benutzt. \item[set] \mbox{} This is the function called when the user calls one of your setsockopts. You should check that they have NET\_ADMIN capability within this function. \item[get\_optmin] \mbox{} and \item[get\_optmax] \mbox{} These specify the (exclusive) range of getsockopt numbers handled. Hence using 0 and 0 means you have no getsockopt numbers. \item[get] \mbox{} Das ist die Funktion, die aufgerufen wird, wenn der User eine Deiner getsockopts aufruft. Du solltest überprüfen, ob es eine NET\_ADMIN Capability in dieser Funktion gibt. \end{description} Die zwei letzten Felder werden intern verwendet. \subsection{Behandlung von Paketen aus Sicht der Anwender} Durch das Verwenden der libipq Library und des `ip\_queue' Moduls kann nun fast alles, was im Kernel getan werden kann, auch von Anwenderseite her geschehen. Das bedeutet, dass Du, mit etwas Geschwindigkeitsverlust, Deinen Code ausschließlich im Userspace entwickeln kannst. Wenn Du keine große Bandbreite filtern mußt, wirst Du das angenehmer finden, als die Pakete im Kernel zu behandeln. In den frühen Tagen von Netfilter habe ich das bewiesen, indem ich eine Embryo-Version von iptables zum Userspace portierte. Netfilter öffnet den Leute die Tür, um ihre eigenen recht effizienten Module zu schreiben, und das in welcher Sprache sie wollen. \section{2.0er und 2.2er Paketfilter-Module übersetzen} Sieh Dir die ip\_fw\_compat.o Datei an; diese sollte eine Portierung recht einfach machen. \section{Die Testsuite} Auf dem CVS Server gibt es eine Test-Suite: Je größer der Bereich ist, den diese Testsuite abdeckt, desto größer wird Deine Zufriedenheit sein, zu sehen, dass Änderungen am Code nichts komplett zerbrochen haben. Triviale Tests sind mindestens so wichtig, wie trickreiche Tests: Es sind die trivialen Tests, die die komplexen vereinfachen (da Du weißt, dass die Grundlagen gut funktionieren, bevor die trickreichen Tests ausgeführt werden). Die Tests sind einfach: Sie sind nur Shell-Scripte im /testsuite Verzeichnis, die erfolgreich sein sollen. Die Scripte werden in alphabetischer Reihenfolge ausgeführt, `01test' kommt also vor `02test'. Zur Zeit gibt es fünf Testverzeichnisse: \begin{description} \item[00netfilter/] \mbox{} Generelle Tests zum Netfilter-Rahmenwerk. \item[01iptables/] \mbox{} Tests zu iptables. \item[02conntrack/] \mbox{} Tests zu Connection Tracking. \item[03NAT/] \mbox{} Tests zu NAT. \item[04ipchains-compat/] \mbox{} Tests zur Kompatibilität von ipchains/ipfwadm. \end{description} Im testsuite/ Verzeichnis gibt es ein Script mit dem Namen `test.sh'. Es konfiguriert zwei Dummy-Schnittstellen (tap0 und tap1), aktiviert Forwarding und beseitigt alle Netfilter-Module. Dann geht es durch die oberen Verzeichnisse und führt dort alle test.sh Scripte aus, bis eins davon nicht funktioniert. Dieses Script hat zwei optionale Argumente: `-v' druckt jeden gerade ausgeführten Test aus. Außerdem kann ein optionaler Testname angegeben werden: Ist dieser gegeben, werden alle anderen Tests ausgelassen, bis dieser eine gefunden wird. \subsection{Einen Test schreiben} Erstelle in dem betreffenden Verzeichnis eine neue Datei: Versuche, Deinen Test so zu numerieren, dass er zur richtigen Zeit ausgeführt wird. Um zum Beispiel ICMP Reply Tracking zu testen (02conntrack/02reply.sh), müssen wir zuerst sicher sein, dass ausgehende ICMP Pakete sauber getrackt werden (02conntrack/01simple.sh). Gewöhnlich ist es besser, mehrere kleine Dateien zu erstellen, von denen jede einen Bereich abdeckt, da das hilft, Probleme für die Leute, die auf der Testsuite arbeiten, sofort zu isolieren. Wenn etwas in dem Test schief läuft, gib ein `exit 1', das verursacht einen Fehler; wenn dies etwas ist, das Du schon erwartet hast, solltest Du eine eindeutige Meldung hinterlassen. Dein Test sollte mit `exit 0' enden, wenn alles gut läuft. Du solltest den Erfolg eines {\bfseries jeden} einzelnen Befehls überprüfen, indem an den Anfang des Scripts die Option `set -e' setzt oder indem Du ein `$|$$|$ exit 1' an jeden Befehl anhängst. Die Hilfsfunktionen `load\_module' und `remove\_module' können verwendet werden, um Module zu laden: Du solltest Dich nicht auf das automatische Laden von Modulen in der Testsuite verlassen, es sei denn, das ist es spezifisch, was Du testen willst. \subsection{Variablen und Umgebung} Du hast zwei Schnittstellen zum Spielen: tap0 und tap1. Ihre Schnittstellenadressen stehen jeweils in {\ttfamily \$TAP0} und {\ttfamily \$TAP1}. Beide haben die Netzmaske 255.255.255.0; ihre Netzwerke stehen jeweils in \$TAP0NET und \$TAP1NET. Es gibt eine leere Temporary Datei in \$TMPFILE. Sie wird am Ende Deines Tests gelöscht. Dein Script wird aus dem /testsuite Verzeichnis heraus gestartet werden, woimmer das auch sein mag. Also solltest Du Tools (wie iptables) mit Pfadnamen wie `../userspace' verwenden. Dein Script kann mehr Informationen ausdrucken, wenn \$VERBOSE gesetzt ist (was bedeutet, dass der User ein `-v' auf der Kommandozeile angegeben hat. \subsection{Nützliche Tools} Es gibt verschiedene nützliche Testsuite-Tools im Unterverzeichnis `Tools': Jedes davon endet mit einem Nicht-Null Exit Status, wenn es ein Problem gibt. \subsubsection{gen\_ip} Du kannst IP-Pakete mit `gen\_ip' generieren, was IP-Pakete an Standard-% Input liefert. Du kannst IP-Pakete an tap0 und tap1 liefern, indem Du Standard-Output an /dev/tap0 oder /dev/tap1 sendest (Falls diese nicht existieren sollten, werden sie beim ersten Verwenden der Testsuite erstellt). gen\_ip ist ein einfaches Programm, das zur Zeit sehr penibel mit der Reihenfolge seiner Argumente ist. Zuerst gibt es die allgemeinen optionalen Argumente: \begin{description} \item[FRAG=offset,length] \mbox{} Erstelle ein Paket, zerlege es dann in Fragmente von folgendem Offset und folgender Länge. \item[MF] \mbox{} Setz das `More Fragments' Bit in dem Paket. \item[MAC=xx:xx:xx:xx:xx:xx] \mbox{} Setz die Quell-MAC-Adresse des Pakets. \item[TOS=tos] \mbox{} Setz das TOS-Feld im Paket (0 - 255). \end{description} Als nächstes kommen die erforderlichen Argumente: \begin{description} \item[source ip] \mbox{} Quell-IP-Adresse des Pakets. \item[dest ip] \mbox{} Ziel-IP-Adresse des Pakets. \item[length] \mbox{} Gesamtlänge des Pakets, einschließlich Header. \item[protocol] \mbox{} Protokollnummer des Pakets, 17 ist zum Beispiel UDP. \end{description} Die Argumente hängen dann vom Protokoll ab: für UDP (17) gibt es Quell- und Ziel-Portnummer. Für ICMP (1) gibt es Typ und Code der ICMP Meldung: ist der Typ 0 oder 8 (ping-Antwort oder ping), werden zwei zusätzliche Argumente (das ID und das Sequenzfeld) benötigt. Für TCP werden Quell- und Zielport, sowie Flags (``SYN'', ``SYN/ACK'', ``ACK'', ``RST'' or ``FIN'') benötigt. Hier gibt es drei optionale Argumente: ``OPT='', gefolgt von einer durch Kommata getrennten Liste von Optionen, ``SYN='' gefolgt von einer Sequenznummer, und ``ACK='' gefolgt von einer Sequenznummer. Schließlich sagt das optionale Argument ``DATA'', dass der Payload des TCP-Pakets mit den Inhalt von Standard-Input gefüllt werden soll. \subsubsection{rcv\_ip} Du kannst Dir IP-Pakete mit rcv\_ip ansehen, was eine Kommandozeile ausgibt, die so nah wie möglich an die Originalwerte herankommt, die an gen\_ip übergeben wurden (mit Ausnahme von Fragmenten). Das ist extrem nützlich für das Analysieren von Paketen. Es erfordert zwei Argumente: \begin{description} \item[wait time] \mbox{} Die maximale Zeit in Sekunden, um auf ein Paket von Standard Input zu warten. \item[iterations] \mbox{} Die Anzahl der zu empfangenden Pakete. \end{description} Es gibt ein optionales Argument ``DATA'', was den Payload des Pakets nach dem Paketheader auf Standard-Output ausdruckt. Der Standardweg, rcv\_ip in einem Shellscript zu verwenden, ist wie folgt: \begin{verbatim} # Jobkontrolle aufsetzen, damit mir $ in Shellscripten verwenden können. set -m # Zwei Sekunden auf ein Paket von tap0 warten. ../tools/rcv_ip 2 1 < /dev/tap0 > $TMPFILE & # Sichergehen, dass rvp_ip läuft. sleep 1 # Ein ping-Paket senden ../tools/gen_ip $TAP1NET.2 $TAP0NET.2 100 1 8 0 55 57 > /dev/tap1 || exit 1 # Auf rvp_ip warten if wait %../tools/rcv_ip; then : else echo rcv_ip failed: cat $TMPFILE exit 1 fi \end{verbatim} \subsubsection{gen\_err} Dieses Programm nimmt ein Paket (wie zum Beispiel von ip\_gen generiert) und wandelt es in einen ICMP Fehler um. Es hat drei Argumente: Die Quell-IP-Adresse, einen Typ und einen Code. Die Ziel-IP-Adresse wird auf die Quell-IP-Adresse des von Standard-Input übergebenen Pakets gesetzt. \subsubsection{local\_ip} Dies nimmt ein Paket von Standard-Input und injiziert es von einem einfachen Socket ins System. Dies gibt ihm den Anschein eines lokal-generierten Pakets (anders, als ein Paket an eines der Ethertap Devices zu übergeben, was wie ein Paket aussehen würde, das woanders generiert wurde). \subsection{Einige Ratschläge} All diese Tools nehmen an, dass sie alles mit einem Lesen und Schreiben tun können: Dies ist wahr für die Ethertap Devices, könnte aber nicht wahr sein, wenn Du etwas Trickreiches mit Pipes machst. dd can verwendet werden, um Pakete auszuschneiden: dd hat eine obs (output block size) Option, die verwendet werden kann, um Pakete mit einem einzigen Schreiben auszugeben. Teste zuerst auf Erfolg: z.B. ein Test darauf, ob Pakete erfolgreich geblockt werden. Teste zuerst, ob Pakete normal durchgehen, teste {\bfseries anschließend}, ob Pakete geblockt werden. Andernfalls könnte ein Fehler, der nichts damit zu tun hat, die Pakete aufhalten... Versuche, exakte Tests zu schreiben, keine `Schreib zufälliges Zeug und warte ab, was passiert' Tests. Wenn ein exakter Tests nicht funktioniert, ist es sehr nützlich, das zu wissen. Wenn ein zufälliger Test nicht funktioniert, hilft das nicht viel. Wenn ein Tests ohne ein Meldung nicht gelingt, kannst Du ein `-x' (ich meine `\#! /bin/sh -x') in die erste Zeile des Scripts setzen, um zu sehen, welches Kommando gerade ausgeführt wird. Wenn ein Test mal gelingt, mal nicht, überprüfe zufälligen Netzwerkverkehr, der dazwischenkommen könnte (versuche, alle externen Schnittstellen zu deaktivieren). Da ich an das gleiche Netzwerk wie Andrew Trigell angeschlossen bin, werde ich zum Beispiel ständig von Windows Broadcasts geplagt. \section{Motivation} Als ich ipchains entwickelte, merkte ich (in einem dieser Flash-Momente-während-man-auf-Einlaß-wartet in einem chinesischen Restaurant), dass Paketfiltern an der falschen Stelle ansetzte. Ich kann es jetzt nicht mehr finden, aber ich erinnere mich daran, dass ich eine Mail an Alan Cox schrieb, der mir antwortete `Warum beendest Du nicht erst das, was Du im Moment tust, obwohl Du wahrscheinlich recht hast'. Um es kurz zu sagen, sollte Pragmatismus über die Richtige Sache siegen. Als ich ipchains, was ursprüngliche eine kleine Modifikation des Kernelteils von ipfwadm war, und dann doch eine größere Neu-Überarbeitung wurde, beendete und das HOWTO schrieb, bemerkte ich die Verwirrung, die in der großen Linux-Community über Dinge wie Paketfiltern, Masquerading, Portforwarding und ähnliches herrscht. Das ist das Gute daran, wenn Du Dein eigener Support bist: Du bekommst ein besseres Gefühl dafür, was die User versuchen zu tun, und womit sie noch straucheln. Es ist die größte Auszeichnung für Freie Software, wenn sie von vielen Usern eingesetzt wird (darum geht es, richtig?), und das bedeutet, dass man es leicht machen muss. Die Architektur, und nicht die Dokumenation, ist der Schlüssel hierzu. Ich hatte also die Erfahrung, sowohl mit dem ipchains-Code, als auch mit einer guten Vorstellung davon, was die Leute dort draußen taten. Es gab nur zwei Probleme: Zuerst wollte ich nicht in den Security-Bereich zurückgehen. Ein Security-Consultant zu sein ist ein konstantes moralischen Tauziehen zwischen Deinem Gewissen und Deinem Konto. Auf einem fundamentalen Level verkaufst Du das Gefühl von Sicherheit, was alles andere ist als wirkliche Sicherheit. Vielleicht wäre es anders, in einer Militäreinrichtung zu arbeiten, wo man Sicherheit versteht. Das zweite Problem ist, dass es nicht nur um Newbies geht; eine wachsende Anzahl von großen Unternehmen und ISPs benutzen dieses Zeug. Ich brauchte zuverlässige Informationen von dieser Klasse von Benutzern, wenn es sich auf die Home-User von Morgen ausbreiten sollte. Diese Probleme wurden gelöst, als ich auf der Usenix 1998 auf David Bonn von Watchguard traf. Sie suchten einen Linux-Kernel Programmierer; Im Ende einigten wir uns darauf, dass ich für einen Monat zu ihrer Niederlassung in Seattle kommen würde, wo wir sehen würde, ob wir eine Vereinbarung rausschlagen könnten, in der sie meinen neuen Code und meine jetzige Support-Arbeit sponsorn würden. Das Gehalt, das sie mir anboten, war mehr als das, nachdem ich gefragt hatte, ich hatte also keine Einnahmeverluste. Das bedeutet, dass ich mir für eine Weile keine Sorgen um Geld zu machen brauche. Die Nähe zu Watchguard gab mir die Nähe zu den großen Clients, die ich brauchte, und dass ich unabhänging von ihnen war, erlaubte mir, alle User (z.b. Watchguard Competitors) gleich zu supporten. Ich hätte also einfach Netfilter schreiben und ipchains portieren können und wäre fertig damit gewesen. Leider hätte das den ganzen Masquerading-% Code im Kernel gelassen: Die Unabhängigkeit zwischen Paketfiltern und Masquerading ist ein wichtiger Punkt beim Paketfiltern, aber Masquerading muß auch auf das Netfilter-Rahmenwerk übertragen werden. Meine Erfahrung mit dem ipfwadm `Schnittstellen-Adressierungs' Feature hat mich auch gelehrt, dass es keine Hoffnung dafür gab, den Masquera% ding Code einfach auszulassen und zu erwarten, dass ihn jemand brauchte und somit selbst die Arbeit einer Portierung zu Netfilter übernehmen würde. Ich brauchte also mindestens soviele Features wie im damaligen Code; vorzugsweise ein paar mehr, um mutige und kreative User zu ermutigen, es mir nachzumachen. Dies bedeutete, transparente Proxies (zum Glück!), Masquerading und Port-Forwarding zu ersetzen. Mit anderen Worten, ein komplettes NAT-Layer. Sogar, wenn ich mich dazu entschieden hätte, das existierenden Masquerading Layer zu Portieren, anstatt ein generisches NAT-System zu schreiben, zeigte der Masquerading Code doch sein Alter und den Mangel an Wartung. Es gab keinen Masquerading Maintainer, und das zeigte sich jetzt. Es scheint, dass ernsthafte User Masquerading generell nicht verwenden und dass es nicht viele Home-User gibt, die die Arbeit der Wartung übernehmen würden. Tapfere Leute wie Juan Ciarlante schrieben Fixes, aber der Punkt (der immer weiter nach hinten verschoben wurde) war erreicht, an dem eine komplette Überarbeitung nötig war. Beachte bitte, das nicht ich die Person war, die NAT überarbeitet hat: Ich verwendete Masquerading nicht mehr und hatte den existierenden Code zu der Zeit nicht studiert. Das ist wahrscheinlich der Grund, warum es länger dauerte, als es dauern sollte. Aber das Resultat ist ziemlich gut, meiner Meinung nach, und ich habe sicher verdammt viel gelernt. Ohne Zweifel wird die zweite Version noch besser werden, wenn wir sehen, wie die Leute es einsetzen. \section{Danke} Danke denen, die geholfen haben. \end{document}