iptables

Netfilter und iptables wurden ursprünglich zusammen entwickelt, sodass es Überschneidungen in der früheren Entwicklung gab. Siehe dazu den Netfilter-Artikel.

Linux besitzt ab 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.

Die aktuelle Version 1.8.5 ist am 3. Juni 2020 veröffentlicht worden.[3]

Der Nachfolger von iptables ist nftables, das seit der Linux-Kernelversion 3.13 verfügbar ist.[4][5][6]

Iptables 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 (jump) oder einen Aufruf (goto) in eine andere Kette erwirken, und dies kann mehrfach verschachtelt werden. (Eine Rückkehr (return) kehrt zur nächsten Regel nach dem Sprung zurück.) 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.

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.

Beispiele:

• Firewall Builder
• ISPConfig
• Plesk
• UFW (Uncomplicated Firewall)
• Webmin

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 selbst zu konstruieren.

• IPFilter
• Paketfilter
• OSI-Modell
• Liste der Portnummern
• Fail2ban

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

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

• Homepage des Netfilter-Teams (englisch)
• frozentux.net (englisch)
• Dokumentation unter Selflinux

1. Phil Sutter: iptables 1.8.10 release. 10. Oktober 2023 (englisch, abgerufen am 10. Oktober 2023).
2. The iptables Open Source Project on Open Hub: Languages Page. In: Open Hub. (abgerufen am 3. September 2018).
3. iptables – iptables tree. Abgerufen am 14. Juni 2020 (englisch).
4. Die Neuerungen von Linux 3.13 – c't Magazin, am 20. Januar 2014
5. Die Neuerungen von Linux 4.10 – c't Magazin, am 17. Januar 2017
6. Linux 3.13: 1.2. nftables, the successor of iptables (englisch) – Linux Kernel Newbies, am 19. Januar 2014