iptables - Die Firewall des

1 von 13 18.05.2006 10:11 iptables - Die Firewall des Kernels 2.4 Inhalt 1. Vorwort 2. ipfwadm, ipchains, iptables - neue Namen, gleiche Funktion? 3. Kurzer Rückblick in die Entwicklung 4. Grundsätzliche Funktionsweise 4.1. In der Netfilter-Architektur gibt es drei Tabellen (tables): 5. Was wird praktisch mit den Tabellen/Ketten (Tables/Chains) gemacht? 6. Datei-Architektur von iptables: 7. Aufruf-Konventionen von iptables (Schnelleinstieg) 7.1. Liste der Kommandos (nur Kurzform) 7.2. Generelle, begleitende Optionen 7.3. Auswahl von Paketen 7.4. Aktionen bei erfolgreicher Maskierung: 7.5. Welche Ziele sind wo erlaubt? 8. Stateless Firewalling - Filterregeln 9. Stateful Firewalling - erweiterte Filterregeln 10. Spezielle Tricks 10.1. Port-Forwarding und Maskierung 10.2. Protokollieren 10.3. Sonstiges 11. Ein Blick unter die Haube 12. Verwendete Quellen 1. Vorwort Dies ist kein Artikel über die prinzipielle Funktion einer Firewall. Hierzu gibt es bereits zahlreiche Werke, die besser sind, als ich sie jemals schreiben könnte, z.b. das von Felix Mack, http://www.pl-berichte.de/work/firewall/index.html. Der hier vorliegende Artikel befaßt sich vielmehr mit den Neuerungen, die die Architektur des Kernel 2.4 mit sich gebracht hat. Außerdem möchte ich versuchen, die zur Verfügung stehenden Parameter möglichst kompakt und verständlich zu vermitteln, sowie diverse Abhängigkeiten und Zusammenhänge darzustellen. 2. ipfwadm, ipchains, iptables - neue Namen, gleiche Funktion? Nein, nicht nur die Namen haben sich in der Kernel-Evolution geändert. Auch die dahinter verborgenen Funktionen sind von Version zu Version stark erweitert worden. Leider sind damit auch jeweils andere Aufrufkonventionen verbunden. Beim ersten Hinsehen glaubt man an eine mutwillige Verwirrungstaktik der Entwickler, denn mal werden Schlüsselworte und Schalter klein, mal werden sie groß geschrieben. Logik dahinter scheint es keine zu geben. Doch! gerade in diesem Punkt ist iptables wesentlich logischer aufgebaut als seine Vorgänger. Unter der Haube, d.h. im Kernel, geht es mit iptables auch wieder wesentlich aufgeräumter zu. An wesentlich weniger Stellen als bisher wird in den Kernel-Code eingegriffen, um die Firewall-Funktionalität unterzubringen, als dies vorher der Fall war. Damit ist der zur Zeit vorliegende Code auch wesentlich besser wartbar als seine Vorgänger. 3. Kurzer Rückblick in die Entwicklung Vor dem Kernel 2.0 gab es bereits zahlreiche "Progrämmchen", die allerdings meist als Patch in den Kernel implantiert werden mußten, um diverse Effekte zu erreichen. Diese Programme waren zwar vom Code her

2 von 13 18.05.2006 10:11 bemerkenswert, doch bei weitem nicht so elegant wie die heute eingesetzte Architektur. Mit dem Kernel 2.0 tauchte "ipfwadm" auf. Es war ein durchaus leistungsfähiges System, doch es gab nur die Möglichkeit, eingehende, geroutete oder ausgehende Pakete zu filtern. Mit dem 2.2er Kernel erblickte "ipchains" die Linux-Welt. Hier gab es bereits mehrere "chains", die aus jeweils einzelnen Regeln bestanden, die der Reihe nach getestet wurden. Die erste erfolgreiche Regel verließ das Regelwerk und bestimmte den Werdegang des gerade getesteten Paketes. Darüber hinaus konnte man in "ipchains" erstmals eigene Ketten definieren, die den Charakter von Unterprogrammen hatten. Der Kernel 2.4 brachte ebenfalls wieder zahlreiche Neuerungen. Die "Netfilter"-Architektur bringt ein neues Tool namens "iptables" mit. Verbesserungen gab es bei: konsistenterer Namensgebung drei Tabellen, die aus mehreren "Chains" bestehen stateful inspection jetzt möglich Port fowarding mit dem selben Tool snat, dnat, masquerading DoS Limiting Ethernet MAC Adress-Filtering variables Logging rejects mit einstellbarem Verhalten bessere Routing-Kontrolle flexiblere Architektur 4. Grundsätzliche Funktionsweise Um die Funktion besser zu verstehen, gilt es, sich zunächst den Weg, den ein Datenpaket durch den Kernel macht, vorzustellen. Gerade hier haben sich die gravierendsten Änderungen zur bisherigen Architektur gezeigt. Die "chains" haben also mit der Lage der Datenpakete bei ihrem Weg durch den Kernel zu tun. Um bestimmte Zwecke zu erreichen, bzw. bestimmte Schutzvorrichtungen aufzubauen, sind entsprechende Regeln in die jeweiligen "chains" einzutragen. INPUT OUTPUT PREROUTING FORWARD Hier landen alle Pakete, die an einen lokalen Prozeß gerichtet sind. Hier laufen alle Pakete durch, die von einem lokalen Prozeß stammen. Unmittelbar, bevor eine Routing-Entscheidung getroffen wird, müssen die Pakete hier durch. für alle zu routenden Pakete

POSTROUTING Alle Pakete, die geroutet werden, laufen nach dem Routing hier durch. 4.1. In der Netfilter-Architektur gibt es drei Tabellen (tables): An dieser Stelle mag die Frage aufkommen: "Haben wir was vergessen?" Nein, haben wir nicht. Die "tables" haben den Zweck, die verschiedenen Arten der Paketbehandlung auf Module verteilen zu können und nur die Module zu laden (und damit auch nur die "tables" mitzuführen), die im Augenblick bzw. für die gestellte Anforderung benötigt werden. Deswegen tauchen die "tables" auch im obigen Diagramm nicht auf, da sie nur gruppierenden Charakter haben. filter Die Standard-Tabelle, die immer dann verwendet wird, wenn keine Tabelle explizit angegeben wird. Diese Tabelle besteht aus den chains INPUT, FORWARD und OUTPUT. Eventuell lassen sich in dieser Tabelle weitere benutzerdefinierte Chains unterbringen. nat Diese Tabelle ist für alle Arten von Adress-Umsetzungen oder Port-Forwarding verantwortlich und besteht aus den Chains PREROUTING, OUTPUT und POSTROUTING. Die in dieser Tabelle befindlichen Chains werden für jedes erste Paket einer neuen Verbindung aufgerufen und führen entsprechende Änderungen an den Port- oder IP-Nummern der Pakete durch. mangle In dieser Tabelle existieren die Chains PREROUTING und OUTPUT und hier werden spezielle Änderungen an Paketen vorgenommen. Die einzelnen Tabellen existieren nur, wenn Regeln in diesen Tabellen angelegt worden sind. Entsprechend hoch ist die Effizienz eines Paketfilters, wenn z.b. nur einfache Filterfunktionen benutzt werden, da die nicht vorhandenen Tabellen gar nicht erst durchlaufen werden müssen. Vorsicht ist jedoch beim Anlegen von Regeln geboten, da hier peinlichst auf den Zusammenhang zwischen den "tables" und den "chains" geachtet werden muß. 5. Was wird praktisch mit den Tabellen/Ketten (Tables/Chains) gemacht? filter/input hier landen alle Pakete, die an einen lokalen Prozeß gerichtet sind. Damit lassen sich Zugriffe auf lokale Prozesse hier perfekt regulieren, z.b.: Zugriff auf einen lokal laufenden Server nur aus bestimmten Netzen Nur Pakete durchlassen, die zu einer bestehenden Verbindung gehören filter/output hier gehen alle Pakete durch, die von einem lokalen Prozeß erzeugt wurden. Damit lassen sich lokale Prozesse nach außen schützen, z.b.: keine ausgehenden "verdächtigen" Verbindungen am Server (Schutz eines Servers vor Daten-Klau) keine "losen" Pakete nach draußen -- nur gültige Verbindungen filter/routing durch diese Chain gehen alle Pakete durch, die durch diese Maschine geroutet werden. Hiermit lassen sich also alle Rechner in jeweils dem Zielnetz des Routing schützen, z.b.: kein UDP nach außen, außer DNS keine öffnenden Verbindungen nach innen Pakete, die zu keiner Verbindung gehören, werden gefiltert 3 von 13 18.05.2006 10:11

4 von 13 18.05.2006 10:11 nat/prerouting Wenn Adress-Übersetzungen durchgeführt werden, müssen alle Pakete vor dem Routing hier durch. Hier lassen sich für zu routende Pakete verändern: die Ziel-IP-Adresse der Ziel-Port nat/output vom lokalen Rechner stammende Pakete gehen hier durch; Änderungen wie nat/prerouting. nat/postrouting Hier gehen nochmals alle Pakete, die geroutet worden sind, durch (auch lokal erzeugte Pakete). Hier werden Angaben über die Herkunft eines Paketes verändert, wie: Quell-IP-Adresse Masquerading (Sonderform von Quell-IP-Änderung) mangle/prerouting mangle/output ähnlich den "nat" chains, nur mit dem Unterschied, daß hier spezielle Paket-Parameter geändert werden können, wie: die TTL (Time to live) 6. Datei-Architektur von iptables: Obwohl "iptables" scheinbar nur aus einer ausführbaren Datei besteht, sind dennoch zahlreiche kleine "Helferlein" in Form von Kernel-Modulen an seiner Arbeit beteiligt. Die Verzeichnisse /lib/modules/2.4.?/kernel/net/ipv4/netfilter und /lib/modules/2.4.?/kernel/net/ipv6/netfilter/ geben einen kleinen Eindruck von den beteiligten Kernel-Modulen. Die Module "ipchains" und "ipfwadm" sind Kompatibilitäts-Module, die gestatten, daß trotz Kernel 2.4 immer noch mit "ipchains" oder "ipfwadm" gearbeitet werden kann. Sollte "iptables" nicht funktionieren, wie z.b. bei SuSE 7.2, so liegt das meist daran, daß in einem Initialisierungs-Skript das Kernel-Modul "ipchains" geladen wurde. root@kruemel:~ > iptables -L /lib/modules/2.4.4-4gb/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters /lib/modules/2.4.4-4gb/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables.o failed /lib/modules/2.4.4-4gb/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed iptables v1.2.1a: can't initialize iptables table `filter': iptables who? (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. root@kruemel:~ > lsmod... einige Zeilen verschluckt pcmcia_core 43936 0 [ds i82365] ipchains 33408 0 (unused) usbcore 47120 1 [hid usb-ohci] root@kruemel:~ > rmmod ipchains root@kruemel:~ > iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination

5 von 13 18.05.2006 10:11 Chain OUTPUT (policy ACCEPT) target prot opt source destination root@kruemel:~ > warum nicht gleich so? bash: warum: command not found root@kruemel:~ > 7. Aufruf-Konventionen von iptables (Schnelleinstieg) Grundsätzlich gilt: Kommandos bestehen aus einem GROSS-Buchstaben, z.b. -L oder einer Lang-Form z.b. --list Targets (d.h. Ziele oder Aktionen) bestehen aus einem Wort in GROSS, z.b. DROP Chains bestehen aus einem Wort in GROSS, z.b. PREROUTING Tabellen sind Worte in Kleinbuchstaben, z.b. filter Optionen bestehen aus Kleinbuchstaben, z.b. -t oder --source-port 7.1. Liste der Kommandos (nur Kurzform)! Ein vorangestelltes "!" bedeutet Negation, d.h. der nachfolgende Parameter darf nicht mit den Daten eines Paketes übereinstimmen. Ohne "!" wird stets auf Übereinstimmung getestet. [...] Alle in eckigen Klammern stehenden Werte sind optional <...> Das in spitzen Klammern stehende Wort steht stellvertretend für den stattdessen einzusetzenden Inhalt -A <chain> <regel> Anfügen einer neuen Regel am Ende einer Chain/Tabelle -D <chain> <regel> Löschen einer Regel aus einer Chain/Tabelle -C <chain> <regel> Testen eines Paketes mit bestimmten Bedingungen auf eine Chain/Tabelle -R <chain> <nr> <regel> Ersetzen einer Regel durch eine neue -I <chain> <nr> <regel> Einfügen einer Regel in eine Tabelle/Chain -L [<chain>] Auflisten aller Regeln einer Tabelle/Chain evtl. mit -Z -F [<chain>] Alle Regeln einer Chain löschen -Z [<chain>] Löschen der Zähler einer Chain -N <chain> Neue benutzerdefinierte Chain anlegen -X <chain> Benutzerdefinierte Chain löschen -P <chain> <ziel> Standardverhalten einer Chain festlegen -E <chain> <chain-neu> Umbenennen einer Chain 7.2. Generelle, begleitende Optionen -t <tabelle> Auswahl einer Tabelle (filter, nat, mangle); "filter" ist die Standard-Tabelle, falls diese Option nicht gewählt wurde. Hierbei wird das diese Tabelle "managende" Modul [iptable_<tabelle>] geladen, sofern der Kernel mit automatischem Modul-Loading konfiguriert ist. -v Mehr ausgeben... -n Numerische Ausgaben bei Auflistungen -x Exakte Zahlenangeben anstelle von Kilo, Mega, Giga... -h Hilfe-Meldungen und Optionen ausgeben (in Verbindung mit -m oder -j werden die mit dem jeweiligen Modul zur Verfügung stehenden zusätzlichen Optionen angezeigt).

6 von 13 18.05.2006 10:11 -m <modul> Zusätzliche Optionen bereitstellen, die im angegebenen Modul verankert sind. Hierbei wird der Modulname ohne vorangestelltes "ipt_" und ohne Erweiterung angegeben (z.b. "mac" zum Laden des Moduls "ipt_mac.o"). Besonders hilfreich ist in diesem Zusammenhang die Hilfe-Funktion (-h), die in Verbindung mit einem Modul dessen Parameter und Optionen auflistet. 7.3. Auswahl von Paketen -p [!] <protokoll> Spezifiziert ein zu testendes Protokoll (tcp, udp, icmp) bzw. einen numerischen Wert gemäß /etc/protocols. -s [!] <adresse>[/<maske>] -d [!] <adresse>[/<maske] Angabe einer Quell-IP Adresse wahlweise mit Maske. Die Maske kann als Anzahl der gültigen Bits (0-32) oder als Subnetzmaske der Form 255.255.255.0 o.ä. angegeben werden. Angabe der Ziel-IP Adresse. Syntax genau wie bei -s -i [!] <interface> Spezifiziert die Schnittstelle, durch die das Paket gekommen ist. Endet der Name mit einem "+", so werden alle Schnittstellen, die mit dem vorangehenden Namen beginnen, getestet. -o [!] <interface> Spezifiziert die Schnittstelle, durch die das Paket gehen wird. Endet der Name mit einem "+", so werden alle Schnittstellen, die mit dem vorangehenden Namen beginnen, getestet. [!] -f Fragmente von IP-Paketen treffen. Da es sich um Fragmente von IP-Paketen handelt, gibt es keine Möglichkeit, deren Quell- oder Ziel-IP oder -Port zu bestimmen. Deswegen greifen andere Bedingungen nicht. 7.4. Aktionen bei erfolgreicher Maskierung: -j <ziel> Bestimmt, was nach Erfüllung der vorher spezifizierten Regel passieren soll. Fehlt dieser Parameter, hat die zugrunde liegende Regel keine Auswirkung. ACCEPT Paket annehmen. DROP Paket vernichten, keine Benachrichtigung des Absenders. QUEUE Einreihen des Pakets in eine Warteschlange für einen Benutzerprozeß. RETURN diese Chain verlassen und beim Aufrufer fortsetzen bzw. die Policy der Chain ausführen. zusätzlich als Module realisiert (extra Hilfe mit -h): LOG Paketdaten in das System-Log eintragen, Regeln in dieser Chain normal fortsetzen. MARK Das Paket mit einer optional anzugebenden Zahl markieren. Dies kann in nachfolgenden Regeln getestet werden. MASQUERADE Dieses geroutete Paket bekommt als Absende-Adresse die IP-Nummer und einen beliebigen Port des ausgehenden Interfaces. Damit lassen sich bei Wählverbindungen mit nur einer IP-Adresse mehrere Rechner über einen Router an nur eine Wählverbindung koppeln. Beim Löschen des Interfaces mit der "Leih-IP Nummer" werden alle gemerkten Daten vergessen. REJECT Ähnlich DROP wird das Paket abgewiesen, jedoch erhält der Absender eine Antwort auf das Paket. TCPMSS Bietet spezielle Optionen, die Datenmenge je Paket zu beschränken. Leider fand ich keine vernünftige Doku dazu. TOS Mit diesem Ziel läßt sich das 8-bit breite Type of Service Feld des IP-Headers setzen. MIRROR Experimentelles Ziel, das Quelle und Ziel vertauscht. Damit scannt ein "Bösewicht" sich selbst.

7 von 13 18.05.2006 10:11 REDIRECT SNAT DNAT Dieses Ziel sorgt dafür, daß das Paket an den lokale Rechner zugestellt wird. Hiermit lassen sich Pakete an "Phantasie-Ziele" abfangen und lokal behandeln. Dieses Ziel ändert die Quell-IP Adresse (und evtl. den Port) eines Paketes. Alle nachfolgenden Pakete dieser Verbindung werden genauso geändert. Dieses Ziel erfüllt fast die gleiche Aufgabe wie MASQUERADE, doch sollte SNAT bei festen IP-Nummern verwendet werden. Mit diesem Ziel wird die Ziel-IP Adresse eines Paketes und allen nachfolgenden Paketen dieser Verbindung geändert. 7.5. Welche Ziele sind wo erlaubt? Das wohl Verwirrendste an iptables ist, sich aus jeder Menge Fließtext zusammenzureimen, welche "table" aus welchen "chains" besteht und welche "targets" nun gerade in welcher Kombination aus "table" und "chain" erlaubt bzw. möglich sind. Ich habe versucht, alle Kombinationen zu finden, die sinnvoll sind, bzw. im Fließtext der man-pages herauszulesen waren. Sollte diese Tabelle nicht ganz korrekt sein, bin ich dankbar für eine kurze Nachricht. Die mit (*) gekennzeichneten "targets" sind jeweils die default-option. INPUT ACCEPT (*) DROP QUEUE RETURN LOG REJECT MIRROR filter nat mangle - - PREROUTING - ACCEPT (*) MIRROR DNAT REDIRECT ACCEPT (*) MARK TOS FORWARD ACCEPT (*) DROP QUEUE RETURN LOG REJECT MIRROR - - POSTROUTING - ACCEPT (*) SNAT MASQUERADE - OUTPUT ACCEPT (*) DROP QUEUE RETURN LOG REJECT ACCEPT (*) DNAT REDIRECT ACCEPT (*) MARK TOS 8. Stateless Firewalling - Filterregeln Diese Funktionen stellen das Grundgerüst eines Paketfilters dar. Fast alle Funktionen dieser Art gab es bei den Vorgängern bereits. Nur eben die Syntax ist ein bißchen anders als gewohnt. Alle Stateless-Funktionen werden in der filter-tabelle in den Chains INPUT, OUTPUT und FORWARD vorgenommen.

8 von 13 18.05.2006 10:11 INPUT Hier stehen Regeln zum Schutz des lokalen Rechners OUTPUT evtl. fehlkonfigurierte Programme "taub" machen FORWARD zum Schutz von Rechnern, zu denen geroutet werden muß Aufrufkonventionen: [!] -s <adresse> [/<maske>] [!] -d <adresse> [/<maske>] Prüfen des Paketes auf seine Quell-Adresse bzw. den Adress-Bereich. Die Maske kann als Zahl 0..32 (=Anzahl der zu testenden Bits) oder als Subnetzmaske, z.b. 255.255.255.248 angegeben werden. Prüfen des Paketes auf seine Ziel-Adresse bzw. den Adress-Bereich. Die Maske kann als Zahl 0..32 (=Anzahl der zu testenden Bits) oder als Subnetzmaske, z.b. 255.255.255.248 angegeben werden. [!] -i <interface> [+] Prüfung auf das Interface, auf dem das Paket ankam. Diese Bedingung ist nur sinnvoll bei den Chains INPUT, FORWARD oder PREROUTING. Ein "+" am Ende des Namens trifft alle Interfaces mit dem vorangehenden Wort am Anfang, z.b. "ippp+" für "ippp0, ippp1,..." [!] -o <interface> [+] Prüfung auf das Interface, auf dem das Paket den Rechner verlassen wird.. Diese Bedingung ist nur sinnvoll bei den Chains OUTPUT, FORWARD oder POSTROUTING. Ein "+" am Ende des Namens trifft alle Interfaces mit dem vorangehenden Wort am Anfang, z.b. "eth+" für "eth0, eth1,..." [!] -f Testen auf Fragmente oder unfragmentierte Pakete ("!" vorangestellt.) [!] -p tcp Testen, ob das Paket TCP-Protokoll überträgt, bzw. nur Laden der -m tcp Erweiterung "tcp" (-m). Nachfolgende Optionen sind nur in einem der beiden Fälle möglich: --source-port [!] --sport [!] --destination-port [!] --dport [!] --tcp-flags [!] <maske> <komponente> Prüfen des Quell-Ports des Paketes oder eines Port-Bereiches. Prüfen des Ziel-Ports des Paketes oder eines Port-Bereiches. Maskiert die angegebenen TCP-Flags und prüft, ob die angegebenen Komponenten gesetzt sind. Masken und Komponenten können die Flags "SYN", "ACK", "FIN", "RST", "URG", "PSH" oder "ALL" und "NONE" sein. z.b. --tcp-flags SYN,ACK,FIN SYN läßt nur die Pakete durch, bei denen SYN gesetzt, ACK und FIN ungesetzt sind. [!] --syn läßt nur die Pakete durch, bei denen SYN gesetzt, ACK und FIN ungesetzt sind. [!] -p udp -m udp --source-port [!] --sport [!] --destination-port [!] --dport [!] [!] -p icmp -m icmp Testen, ob das Paket UDP-Protokoll überträgt, bzw. nur Laden der Erweiterung "udp" (-m). Nachfolgende Optionen sind nur in einem der beiden Fälle möglich: Prüfen des Quell-Ports des Paketes oder eines Port-Bereiches. Prüfen des Ziel-Ports des Paketes oder eines Port-Bereiches. Testen, ob das Paket ICMP-Protokoll überträgt, bzw. nur Laden der Erweiterung "icmp" (-m). Nachfolgende Option ist nur in einem der beiden Fälle möglich: --icmp-type [!] <name> Prüfen der ICMP-Nachricht. Eine Liste der Nachrichten kann mit "iptables -p icmp -h" erhalten werden.

9 von 13 18.05.2006 10:11 -m mac Einbinden des Moduls zur MAC-Adressen-Überprüfung (=Ethernet Interface Adresse). Nachfolgende Option ist nur bei geladenem "mac" Modul möglich: --mac-source [!] <xx:xx:xx:xx:xx:xx> Prüfen der Ethernet-Quell-Adresse. Ist nur sinnvoll in den Chains PREROUTING, FORWARD oder INPUT. -m multiport Dieses Modul erlaubt das Testen mehrerer einzelner Ports. Es lassen sich in den nachfolgenden Optionen bis zu 15 Ports angeben. --source-port [<port[,<port>]>] --destination-port [<port[,<port>]>] --port [<port[,<port>]>] Prüfen des Quell-Ports des Paketes. Prüfen des Ziel-Ports des Paketes. Prüfen des Quell- oder Ziel-Ports des Paketes. Beispiele: Alle Regeln aller Chains in der "filter" Tabelle löschen iptables -F Pakete an lokale Prozesse ------------------------- Policy (Standardverhalten am Regelende): Paket verwerfen iptables -P INPUT DROP TCP-Pakete aus dem lokalen Netz durchlassen iptables -A INPUT -p tcp -s 192.168.1.0/24 -j ACCEPT TCP-Pakete ohne SYN-Flag wegwerfen (an dieser Stelle Unsinn!) (Info: SYN-Flag ist nur beim Ersten Paket einer TCP-Verbindung gesetzt) iptables -A INPUT -p tcp! --syn -j DROP TCP-Pakete an Ziel-Port 113 (auth) erlauben iptables -A INPUT -p tcp --dport 113 -j ACCEPT UDP-Pakete aus lokalem Netz passieren lassen iptables -A INPUT -p udp -s 192.168.1.0/24 -j ACCEPT UDP-Pakete von Name-Servern durchlassen iptables -A INPUT -p udp --sport 53 -j ACCEPT ICMP-Pakete (z.b. Ping) aus lokalem Netz erlauben iptables -A INPUT -p icmp -s 192.168.1.0 -j ACCEPT ICMP-Pakete (z.b. Ping) generell verbieten iptables -A INPUT -p icmp -j DROP Pakete, die geroutet werden --------------------------- Policy (Standardverhalten am Regelende): Paket verwerfen iptables -P FORWARD DROP Pakete aus lokalem Netz erlauben und routen iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT Pakete von lokalen Prozessen ---------------------------- Policy (Standardverhalten am Regelende): Paket durchlassen iptables -P OUTPUT ACCEPT sonst keine Einschränkungen -- wir stellen nichts an :-) Wie man sich leicht überlegen kann, lassen sich mit diesen Regeln bereits einfache Schutzmechanismen aufbauen - allerdings nur wirklich einfache Mechanismen. Denn eine Prüfung kann nur für jedes Paket

10 von 13 18.05.2006 10:11 einzeln durchgeführt werden und kennt keine Zustände. So sind z.b. Befehle wie "ping" generell verboten und Ergebnisse von Name-Server-Abfragen generell erlaubt, was Angreifern leicht die Möglichkeit eines Eindringens bieten kann und gleichzeitig starke Einschränkungen darstellt. 9. Stateful Firewalling - erweiterte Filterregeln Wie wir gerade gesehen haben, reicht eine Prüfung auf Paket-Ebene nicht aus, um ausreichenden Schutz zu bieten. Besseren Schutz bietet ein Mechanismus, der den Zustand aller Verbindungen, die durch die Firewall aktiv bestehen, mitverfolgt und dementsprechend reagiert. Diese Funktion führt das Modul "ipt_state" aus, welches mit -m state aktiviert wird und über die Datei /proc/net/ip_conntrack mit der Außenwelt kommuniziert. Ein gelegentlicher Blick in diese Datei verrät einiges über das, was dieses Modul tut... Aufrufkonventionen: -m state Aktivieren des Moduls "ip_state". [!] --state <status> Prüfen, ob Paket in einem gewählten Verbindungszustand ist. mögliche Zustände: INVALID NEW ESTABLISHED RELATED Ungültiger Zustand, dieses Paket eröffnet weder eine neue Verbindung, noch gehört es zu einer bestehenden. Dieses Paket eröffnet eine neue Verbindung. Dieses Paket gehört zu einer bereits bestehenden Verbindung Dieses Paket hat etwas mit einer bestehenden Verbindung zu tun. Beispiel: zu routende Pakete nur durchlassen, wenn von innen oder zu einer bestehenden Verbindung gehörig iptables -A FORWARD -s 192.168.1.0/24 -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT Lokale Prozesse genauso schützen iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Das Faszinierende am Mechanismus des "Connection Tracking" ist, daß selbst eigentlich zustandslose Verbindungen wie UDP oder ICMP mitverfolgt werden können. wolfgang@scarlett:~ > ping 192.168.1.5 PING 192.168.1.5 (192.168.1.5): 56 data bytes --- 192.168.1.5 ping statistics --- 9 packets transmitted, 0 packets received, 100% packet loss wolfgang@scarlett:~ > nslookup asdf ^C wolfgang@scarlett:~ > ssh kruemel... wolfgang@scarlett:~ > cat /proc/net/ip_conntrack icmp 1 7 src=192.168.1.2 dst=192.168.1.5 type=8 code=0 id=65029 [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 type=0 code=0 id=65029 use=1 tcp 6 431996 ESTABLISHED src=192.168.1.2 dst=192.168.1.3 sport=32770 dport=22 src=192.168.1.3 dst=192.168.1.2 sport=22 dport=32770 [ASSURED] use=1 udp 17 16 src=192.168.0.1 dst=62.104.219.88 sport=32771 dport=53 [UNREPLIED] src=62.104.219.88 dst=192.168.0.1 sport=53 dport=32771 use=1 wolfgang@scarlett:~ >

11 von 13 18.05.2006 10:11 10. Spezielle Tricks Eine Firewall nur zum Schutz anderer Systeme heranzuziehen, ist eine Möglichkeit. Doch die Netfilter-Architektur bietet noch einige andere Möglichkeiten: 10.1. Port-Forwarding und Maskierung Hinter diesen Schlagworten verstecken sich eigentlich ganz einfach zu verstehende Mechanismen. Pakete werden so geändert, daß sie an andere Maschinen gerichtet sind (Destination NAT). Hierbei wird einfach nur eine andere Ziel-IP-Nummer in das Paket eingetragen. Dies muß in der PREROUTING Chain der Tabelle "nat" erfolgen. von einer anderen Maschine zu kommen scheinen (Source NAT). Hierbei wird die Quell-IP-Adresse des Paketes ausgetauscht. Dieser Schritt kann nur in der POSTROUTING Chain der "nat" Tabelle durchgeführt werden. an einen anderen Port gerichtet werden. von einem anderen Port zu kommen scheinen. Typische Anwendungen dieser Methoden sind das Verstecken von Rechnern hinter der Firewall, das Verschleiern von IP-Adressen oder das gemeinsame Nutzen einer (z.b. vom Provider) vorgegebenen IP-Adresse durch mehrere Nutzer. Alle nachfolgend aufgelisteten Targets werden nur für das erste Paket einer Verbindung spezifiziert. Alle nachfolgend gesandten/empfangenen Pakete werden automatisch korrekt modifiziert. Aufrufkonventionen: -j SNAT Aktivieren des Source-NAT zum Ändern der Quell-IP-Adresse. --to-source <adresse>[-<adresse>][:<port>-<port>] Dieser Parameter, der angegeben werden muß, legt fest, welches die Quell-IP-Adresse des Pakets ist. Werden mehrere Adressen angegeben, so wird eine dieser Adressen ausgewählt. Sind die zu wählenden Adressen nicht aufeinanderfolgend, kann der Parameter mehrfach angegeben werden. Werden darüberhinaus ein oder mehrere Ports angegeben, so wird ein Port aus diesem Bereich ausgewählt, der für diese Verbindung gewählt wird. Sonst wird versucht, den Port nicht zu ändern. -j DNAT Aktivieren des Destination-NAT zum Ändern der Ziel-IP-Adresse. --to-destination <adresse>[-<adresse>][:<port>-<port>] Mit dieser Option wird die Ziel-Adresse, zu der die Pakete dieser Verbindung gelangen sollen, angegeben. -j MASQUERADE Aktivierung der Maskierung, einer Sonderform des SNAT. Unterschied zum SNAT ist, daß keine Quell-IP-Adresse angegeben werden kann, sondern die IP-Adresse des ausgehenden Interface als neue Quelle eingetragen wird. Mit dem Herunterfahren eines Interface (z.b. Auflegen einer Wählverbindung) werden alle gespeicherten Verbindungs-Informationen gelöscht, was bei SNAT nicht der Fall ist.

12 von 13 18.05.2006 10:11 --to-ports :<port>[-<port>] Hiermit lassen sich ein Port oder ein Bereich von Ports angeben, die beim Maskieren verwendet werden sollen. Ohne diese Angabe werden Ports automatisch gewählt und wenn möglich, nicht verändert. -j REDIRECT Hiermit werden alle Pakete dieser Verbindung an den lokalen Rechner umgeleitet. Damit kann z.b. das zwangsweise Ansprechen eines Name-Servers innerhalb eines Netzes erzwungen werden. --to-ports :<port>[-<port>] Hiermit lassen sich ein Port oder ein Bereich von Ports angeben, die beim Umleiten verwendet werden sollen. Ohne diese Angabe werden Ports automatisch gewählt und wenn möglich, nicht verändert. Beispiele: Name-Server von 192.168.99.99 umbiegen auf echten Server (z.b. 62.104.219.88) iptables -A PREROUTING -t nat -p udp -d 192.168.99.99 --dport 53 \ -j DNAT --to-destination 62.104.219.88 Maskieren bei einer Wählverbindung iptables -A POSTROUTING -t nat -s 192.168.1.0/24 -j MASQUERADE 10.2. Protokollieren Nicht nur zum Test, auch zur Überwachung von "schrägen" Mustern von IP-Paketen ist es sinnvoll, über diverse Dinge Protokoll zu führen. Dies kann mit dem LOG-Target sehr einfach geschehen. Alles Protokollierte wird im Syslog (/var/log/messages) mitgeschrieben. Aufrufkonventionen: -j LOG Falls die vorher spezifizierten Bedingungen zutreffen, wird das Paket geloggt. Im Gegensatz zu anderen Targets wird die Kette nach dieser Regel nicht verlassen, sondern die nächste Regel weiterhin getestet. --log-level <level> Legt den Grad der Meldung fest, die hiermit geloggt wird. Über das eigentliche Verhalten entscheidet die Einstellung des Syslog. --log-prefix <text> Stellt den angegebenen Text vor die eigentlich geloggte Meldung. Damit lassen sich verschiedene Nachrichten schnell unterscheiden. --log-tcp-sequence Mitloggen der TCP Sequence-Nummer. --log-tcp-options Optionen im TCP Header werden mitgeschrieben --log-ip-options Optionen im IP Header werden mitgeschrieben -m limit Dieses Modul ist als Zusatz zum "LOG"-Target gedacht, um die Anzahl der Log-Einträge zu beschränken (bei DoS-Attacken). --limit <rate> / <zeit> --limit-burst <zahl> Gibt die maximal durchschnittlich zu erreichende Rate pro Zeiteinheit an. z.b. 3/second, 5/minute, 3/hour, 100/day. Bei Überschreitung dieser Rate greift diese Regel nicht mehr. Bei Überschreiten dieser Zahl wird das nachfolgende Target nicht mehr getroffen. Diese Option, deren Standardwert auf 5 steht, ist gedacht, um vor allem Log-Einträge nicht zu überfluten.

10.3. Sonstiges Es gibt noch einige Kleinigkeiten, die erwähnenswert sein könnten. In diesem kleinen Workshop möchte ich mich jedoch auf das Erstellen eigener Chains beschränken. Eigene Chains - wozu? Eigene Chains verhalten sich wie "Unterprogramme", so daß öfter benötigte Aktionen (z.b. Loggen und Verwerfen) nur einmalig definiert werden müssen. Beispiele: Alle benutzerdefinierten Chains der Tabelle "filter" Löschen iptables -X Log and drop definieren als benutzerdefinierte Chain iptables -N logdrop iptables -A logdrop -j LOG --log-prefix "IPTABLES packed died: " iptables -A logdrop -j DROP... Alles Unnütze verbieten, bestehende Verbindungen -> OK iptables -A FORWARD -s $mynet -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -j logdrop 11. Ein Blick unter die Haube Einige der bereits im Text genannten Dateien des /proc Dateisystems seien an dieser Stelle nochmals genannt. Sie ermöglichen in beschränktem Umfang, einen Blick in die Arbeitsweise der Netfilter-Architektur zu werfen: /proc/net/ip_conntrack zeigt alle derzeit aktiven Verbindungen (selbst bei verbindungslosen Protokollen wie UDP oder ICMP) an. /proc/net/ip_tables_names Enthält die Liste aller zur Zeit geladenen Tables. /proc/net/ip_queue Wird von den UserSpace-Queue-Routinen zur Kommunikation genutzt. 12. Verwendete Quellen Folgende Quellen aus dem Internet sowie die man-page von iptables halfen mir bei der Zusammenstellung zu diesem Workshop: : http://www.netcologne.de/~meberg/netfilter/ : http://www.gnumonks.org/ftp/pub/doc/conntrack+nat.html : http://www.gnumonks.org/ftp/pub/doc/packet-journey-2.4.html : http://www.boingworld.com/workshops/linux/iptables-tutorial/ : http://www.linuxguruz.org/iptables/ : http://www.yolinux.com/tutorials/linuxtutorialnetworkgateway.html Copyright (C) Wolfgang Kinkeldei Erschienen auf Pro-Linux, letzte Änderung 2001-11-04 13 von 13 18.05.2006 10:11