iptables

iptables
Entwickler	Netfilter-Projekt-Team
Aktuelle Version	1.4.12.1 (1. September 2011)
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 werden. Diese Tabellen enthalten Ketten (chains) und Regeln (rules). 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] 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 gemeinsamen Code aller vier Module trägt, und das API für iptables-Erweiterungen bereitstellt. Folglich ist mit Xtables oft die gesamte Firewall-Infrastruktur gemeint.

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 wird 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 weitere 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 Information war zuvor an NAT gebunden. Somit hat iptables mehr Möglichkeiten als ipchains, da es zusätzlich den Zustand einer Verbindung überwachen, diese umleiten, oder Datenpakete basierend auf dem Zustand stoppen und manipulieren kann, 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.

Zusammenfassung der Funktion

Xtables ermöglicht dem Systemadministrator, Tabellen zu laden, die Ketten von Regeln für die Behandlung von Paketen enthalten. Jede Tabelle dient einem eigenen Zweck. Pakete werden durch sequenzielles Abarbeiten von Regeln innerhalb einer Kette weitergereicht. 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.

Graph zum Paketfluss. Pakete beginnen in einem bestimmten Kasten und werden entsprechend den Umständen (z. B. Routing) einen gewissen Pfad nehmen.

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 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 gelistete 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 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 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 bis eine Regel als Urteil RETURN enthält (wodurch es in der übergeordneten Kette wieder weitergeht) oder bis das Ende der Kette erreicht wird.

Frontends

Zur Erleichterung beim Aufsetzen von Regeln wird Software von vielen Herstellern angeboten. Frontends in textbasierter oder grafischer Manier erlauben es Benutzern, einfache Regelwerke mit wenigen Mausklicks anzulegen; 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 auch Vorlagen zum Einsatz kommen, die mittels Konfigurationsdateien angelegt werden. Linux-Distributionen verwenden oft Vorlagen, bieten dem Anwender aber auch die Möglichkeit, eigene Regeln zu definieren.

Solche Frontends, Generatoren und Skripte sind oft durch ihre Vorlagen und Bauweise beschränkt. Hinzu kommt, dass die so generierten Regelwerke meist nicht für den jeweiligen Einsatz der Firewall optimiert sind, da eine automatische Optimierung im Frontend einen hohen Entwicklungsaufwand darstellen würde. Benutzern, die ein gutes Verständnis von iptables haben und ein optimiertes Regelwerk wünschen, wird daher angeraten, die Regeln selber zu konstruieren.

Siehe auch

• IPFilter
• Paketfilter, Firewall
• Masquerading, OSI-Modell
• Liste der standardisierten Ports
• Fail2ban

Literatur

• Gregor N. Purdy: Linux iptables – kurz & gut. O’Reilly, Dezember 2004, ISBN 3-89721-506-3
• Gregor N. Purdy: Linux iptables Pocket Reference. O’Reilly Media, August 2004, englisch, ISBN 0-596-00569-5
• Ralf Spenneberg: Linux-Firewalls mit iptables & Co., m. CD-ROM. Addison-Wesley, München, Februar 2006, ISBN 3-8273-2136-0. Kapitelweise: opensource-training.de (PDF)

Weblinks

 Wikibooks: Linux-Kompendium: Linux-Firewall mit IP-Tables – Lern- und Lehrmaterialien

• Homepage des Netfilter-Teams (englisch)
• Anleitung für iptables (englisch)
• Dokumentation unter Selflinux (deutsch)

Einzelnachweise

1. ↑ iptables und ip6tables auf dev.medozas.de