Iptables
aus Wikipedia, der freien Enzyklopädie
| iptables | |
|---|---|
| Entwickler: | Netfilter-Projekt-Team |
| Aktuelle Version: | 1.4.4 (16. Juni 2009) |
| Betriebssystem: | Linux |
| Kategorie: | Firewall |
| Lizenz: | GPL (Freie Software) |
| Deutschsprachig: | nein |
| netfilter.org | |
iptables ist ein Userspace-Programm zur Konfiguration der Tabellen (tables), die durch die Firewall im Linux-Kernel (bestehend aus einer Reihe von Netfilter-Modulen) bereitgestellt wird, sowie deren Ketten (chains) und Regeln (rules) die in diesen Tabellen enthalten sind. Verschiedene Programme werden gegenwärtig für unterschiedliche Protokolle verwendet; iptables beschränkt sich auf IPv4, für IPv6 gibt es ip6tables, für ARP ist es arptables, und mit ebtables gibt es eine Sonderkomponente für Ethernetpakete.
Da iptables erweiterte Systemprivilegien benötigt, muss es als root ausgeführt werden. Auf den meisten Linux-Systemen ist iptables als /usr/sbin/iptables installiert. Dokumentation ist in der Manpage[1][2] mittels "man iptables" einsehbar, sofern installiert.
Der Begriff iptables wird auch oft verwendet, um ausschließlich die Kernel-Komponenten zu beschreiben. x_tables ist der Name des Kernelmoduls, der den geteilten Code aller vier Module trägt, und der sonst noch das API für iptables-Erweiterungen bereitstellt. Folglich wird Xtables mehr oder minder dazu verwendet, um die gesamte Firewall-Infrastruktur zu benennen.
Inhaltsverzeichnis |
[Bearbeiten] Geschichte
→ Siehe auch: Netfilter#Geschichte
Netfilter und iptables wurden ursprünglich zusammen entwickelt, sodass es Überschneidungen in der früheren Entwicklung gab. Siehe dazu den Netfilter-Artikel.
Linux besitzt seit Version 1.0 einen Paketfilter. Dieser stammte zunächst von BSD ab und wurde in der Linux-Version 2.0 unter dem Namen ipfwadm erweitert. Rusty Russell überarbeitete den Paketfilter nochmals und stellte ihn als ipchains zur Verfügung. Er wurde in Linux 2.2 integriert. Gegen 1999 wurde der Kernel und damit auch ipchains komplett überarbeitet. Aus ipchains ging iptables hervor, das seit Kernel 2.4 zum “Lieferumfang” gehört.
iptables behält die ursprüngliche Grundidee von ipfwadm: Listen von Regeln, wovon jede angibt, was in einem Paket überprüft werden, und was dann mit diesem Paket geschehen soll. ipchains brachte das Konzept von Ketten (chains) ein, und iptables erweiterte dies hin zu Tabellen (tables). Eine Tabelle ist für NAT zuständig, eine weiter zur Filterung. Zusätzlich wurden die drei Punkte wo Pakete auf ihrer “Reise” gefiltert werden so geändert, dass jedes Paket nur durch einen Filterpunkt gelangt.
Diese Aufteilung ermöglichte iptables wiederum Informationen zu verwenden, die das Connection-Tracking-Subsystem erarbeitet hatte — diese Info war zuvor an NAT gebunden. Somit ist iptables besser als ipchains da es die Möglichkeit besitzt, den Zustand einer Verbindung zu überwachen, diese umzuleiten, oder Datenpakete basierend auf dem Zustand zu stoppen oder zu manipulieren, statt dies nur mittels Quell- oder Zieladresse zu tun. Eine Firewall wie iptables die diese Voraussetzungen erfüllt wird als “stateful” bezeichnet, während ipchains außer in sehr begrenzten Ausnahmefällen doch nur “stateless” war.
[Bearbeiten] Zusammenfassung der Funktion
Xtables ermöglicht es dem Systemadministrator Tabellen zu laden, die Ketten von Regeln für die Behandlung von Paketen enthalten. Jede Tabelle dient einen eigenem Zweck. Pakete werden durch sequenzielles Abarbeiten von Regeln innerhalb einer Kette. Eine Regel kann einen Sprung (goto) oder einen Aufruf (jump) in eine andere Kette erwirken, und dies kann mehrfach verschachtelt werden. (Bei einem Aufruf wird der Ursprung des Sprungs für eine spätere Rückkehr vermerkt.) Jedes Netzwerkpaket das den Computer erreicht oder diesen verlässt, durchläuft mindestens eine Kette.
Der Ursprung des Pakets bestimmt, in welcher Kette die Abarbeitung beginnt. Es gibt fünf vordefinierte Ketten (die den fünf Netfilter-Hooks entsprechen), auch wenn eine Tabelle nicht unbedingt alle Ketten haben muss. Vordefinierte Ketten haben eine Policy, z.B. DROP, die greift, wenn ein Paket das Ende der Kette erreicht hat (also ohne auf eine Regel gepasst zu haben). Es können weitere, benutzerdefinierte Ketten angelegt werden, jedoch haben diese keine Policy; trifft ein Paket auf deren Ende, geht die Abarbeitung in der Kette weiter, die ursprünglich den Sprung ausgelöst hat. Leere Ketten sind zulässig.
- “PREROUTING”: Pakete landen in dieser Kette bevor eine Routing-Entscheidung getroffen wird.
- “INPUT”: Paket wird lokal zugestellt. (N.B.: Dies hat wenig mit Prozessen zu tun. Lokale Zustellung wird durch die “local”-Routingtabelle kontrolliert: `
ip route show table local`.) - “FORWARD”: Alle Pakete die geroutet und nicht lokal zugestellt wurden, passieren durch diese Kette.
- “OUTPUT”: Pakete, die vom eigenen Computer erzeugt wurden, tauchen hier auf.
- “POSTROUTING”: Routing-Entscheidung wurde getroffen. Pakete laufen hier nochmals durch kurz bevor sie an die Hardware abgegeben werden.
Jede Regel in einer Kette enthält Spezifikationen (matches), auf welche Pakete sie zutrifft. Regeln können außerdem ein Ziel (target, für Erweiterungen) bzw. Urteil (verdict) enthalten. Mit dem Durchlaufen eines Paketes durch eine Kette werden Regeln nacheinander geprüft. Falls eine Regel auf das Paket nicht zutrifft, wird zur nächsten Regel übergegangen. Trifft sie hingegen zu, wird die mit Ziel/Urteil gelistet Aktion durchgeführt, welche darin resultieren kann, dass das Paket weiter durch die Kette läuft oder nicht. Spezifikationen stellen den größten Teil von Regelwerken dar, da sie die Bedingungen enthalten, auf die ein Paket getestet wird. Diese Tests können für jeden Layer im OSI-Model durchgeführt werden, zu nennen sind bspw. die --mac-source und -p tcp --dport Parameter. Jedoch gibt es auch protokollunabhängige Optionen, z.B. -m time.
Ein Paket avanciert in einer Kette bis entweder (1) eine Regel auf das Paket zutrifft und ein endgültiges Urteil für das Paket gefällt wird (z.B. mittels ACCEPT oder DROP); oder (2) eine Regel beinhaltet als Urteil RETURN, wodurch es in der übergeordneten Kette wieder weitergeht; oder (3) das Ende der Kette wird erreicht.
[Bearbeiten] Frontends
Es gibt haufenweise Drittanbieter-Software zu iptables, die das Aufsetzen von Regeln erleichtern zu suchen. Frontends in textbasierter oder grafischer Manier erlauben es Benutzern, einfache Regelwerke “mittels Klick” zu generieren; Skripte sind oftmals Shell-Skripte (aber auch andere Sprachen sind möglich), die iptables oder (das schnellere) iptables-restore mit einer Reihe von vordefinierten Regeln aufrufen. Dabei können ggf. auch Vorlagen zum Einsatz kommen die mittels Konfigurationsdateien gesteuert wird. Linux-Distributionen setzen oftmals die Variante mit Vorlagen, also mit der Möglichkeit, dass der Benutzer irgendwo seine eigenen Regeln noch definieren kann, um.
Solche Frontends, Generatoren und Skripte sind oft durch ihre Vorlagen und Bauweise beschränkt. Hinzu kommt, dass die so generierten Regelwerke generell nicht für den jeweiligen Einsatz der Firewall optimiert sind, da dies leicht den Arbeitsaufwand für Entwickler des Frontends steigern kann. Benutzer, die ein gutes Verständnis von iptables haben und ein optimiertes Regelwerk wünschen, wird daher angeraten, die Regeln selber zu konstruieren.
[Bearbeiten] Siehe auch
[Bearbeiten] Literatur
- Gregor N. Purdy: Linux iptables - kurz & gut. O'Reilly, Dezember 2004, ISBN 3897215063
- Gregor N. Purdy: Linux iptables Pocket Reference. O'Reilly Media, August 2004, englisch, ISBN 0596005695
- Ralf Spenneberg: Linux-Firewalls mit iptables & Co., m. CD-ROM. Addison-Wesley, München, Februar 2006, ISBN 3827321360 (Hier kapitelweise als PDF verfügbar [3])
[Bearbeiten] Weblinks
- Diagramm Abarbeitungsreihenfolge
- Homepage des Netfilter-Teams (englisch)
- Anleitung für iptables (englisch)
- Umfangreicher deutschsprachiger Workshop

