IPTables, nftables, ipchains, firewalld

IPTables und IPChains sind klassische Firewall-Tools auf Kernel-Ebene für Linux. IPChains ist älter und wurde größtenteils von IPTables abgelöst. Firewalld ist ein Daemon und Frontend, der IPTables- oder nftables-Regeln automatisch verwaltet und eine einfachere Konfiguration ermöglichen soll.

IPChains war das Nachfolgetool von IPFWADM in älteren Linux-Kerneln (2.2er-Reihe). Es wurde hauptsächlich genutzt, um Netzwerkpakete zu filtern, weiterzuleiten und NAT einzurichten. Heute ist es veraltet und sollte kaum noch eingesetzt werden.

IPTables führte erweiterte Funktionen wie State Tracking (Connection Tracking) und modular aufgebaute Extensions ein. Das machte es deutlich leistungsfähiger und flexibler als IPChains.

Firewalld abstrahiert die reine IPTables-Regelverwaltung in „Zonen“ und Dienste. Es läuft als Dienst im Hintergrund und ermöglicht dynamische Regeländerungen, ohne dass man jede einzelne IPTables-Regel manuell schreiben muss.

Meistens nicht. IPChains ist so gut wie überall durch IPTables ersetzt worden. In älteren Systemen kann es noch vorhanden sein, aber für moderne Distributionen spielt es faktisch keine Rolle mehr.

IPTables arbeitet mit Tabellen und Chains (INPUT, FORWARD, OUTPUT etc.), in denen Du Filter- und NAT-Regeln verwaltest. Es nutzt das Netfilter-Framework im Linux-Kernel, um Netzwerkpakete zu inspizieren und zu filtern.

INPUT regelt eingehende Pakete, OUTPUT regelt ausgehende Pakete, FORWARD bezieht sich auf Pakete, die das System lediglich weiterleitet (z. B. als Router oder Bridge).

Die Installation variiert je nach Distribution. Unter Debian/Ubuntu zum Beispiel: sudo apt-get install firewalld. Unter Fedora und CentOS ist Firewalld oft bereits vorinstalliert.

Ja, allerdings kann es zu Konflikten kommen, wenn Du manuell IPTables-Regeln setzt und Firewalld parallel Regeln generiert. Normalerweise ist es besser, sich für eine Variante zu entscheiden.

Du kannst zum Beispiel sudo firewall-cmd --permanent --add-port=80/tcp nutzen und dann sudo firewall-cmd --reload. Damit öffnest Du den TCP-Port 80.

Weil sie direkt auf Kernel-Ebene arbeiten und Dir vollständige Kontrolle geben. Du musst jedoch jeden Befehl selber definieren. Firewalld ist dagegen ein „High-Level Tool“, das viel automatisiert.

Mit NAT („Network Address Translation“) kannst Du lokale IP-Adressen übersetzen, um Internetzugang zu ermöglichen (Masquerading) oder eingehende Verbindungen auf andere interne Hosts weiterzuleiten (Port Forwarding).

So gut wie nichts mehr – IPChains ist historisch. Du solltest es höchstens noch in sehr alten Systemen antreffen. Für moderne Anwendungsszenarien ist IPChains kein Thema mehr.

Ja, das ist eine der Kernfunktionen. Du kannst Netzwerkschnittstellen verschiedenen Zonen zuweisen (z. B. public, home, dmz). Die Zone bestimmt dann die Standard-Regeln für diesen Bereich.

Du kannst alle Regeln flushen: sudo iptables -F. Oder Du beendest den Dienst, z. B. sudo systemctl stop iptables, sofern Deine Distribution den Dienst so verwaltet.

Ja, inzwischen nutzen viele Distributionen unter der Haube nftables und Firewalld kann darauf zugreifen. Firewalld selbst abstrahiert, sodass Du weniger von der konkreten Backend-Implementation mitbekommst.

Beispiel: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT erlaubt eingehende TCP-Pakete auf Port 22 (SSH), falls keine restriktiveren Regeln dem im Weg stehen.

Neben IPTables-Regeln musst Du in /etc/sysctl.conf oder temporär via sysctl -w net.ipv4.ip_forward=1 das IP-Forwarding aktivieren. Dann kannst Du IPTables-Regeln im FORWARD-Chain definieren.

Ja, meist greifen sie sofort, außer Du nutzt den Parameter --permanent. Dann musst Du im Anschluss noch ein firewall-cmd --reload ausführen.

Du kannst mit firewall-cmd --permanent --delete-service=<service> oder --delete-port=<port> Regeln entfernen. Alternativ kannst Du die Default-Konfiguration wiederherstellen, indem Du die Config-Dateien löschst und Firewalld neu installierst.

Du kannst alle Regeln mit sudo iptables-save > /etc/iptables.rules speichern und beim Systemstart mit sudo iptables-restore < /etc/iptables.rules laden. Viele Distributionen haben dafür eigene Skripte oder Services.

Wenn Du eine Schnittstelle in eine andere Zone verschiebst, erbt diese Schnittstelle sofort deren Firewall-Regeln. Achte darauf, dass Du Dich nicht versehentlich aussperrst (z. B. bei SSH-Verbindungen).

Technisch funktioniert IPChains in alten Systemen immer noch, aber es wird nicht mehr weiterentwickelt oder gewartet. Du solltest es nicht mehr nutzen, da moderne Tools sicherer und flexibler sind.

Theoretisch ja, aber es führt oft zu Durcheinander, weil Firewalld seine eigenen Regeln schreibt. Besser ist, Du bleibst bei einer Methode, damit Du stets den Überblick behältst.

Mit sudo iptables -L -n -v bekommst Du eine Übersicht Deiner Chains, Ports, Protokolle und Counters. Das -n verhindert eine Namensauflösung und beschleunigt die Ausgabe.

Mit sudo firewall-cmd --state prüfst Du, ob Firewalld läuft. Zudem kannst Du mit firewall-cmd --list-all die aktive Zone und deren Regeln anzeigen lassen.

Über die PREROUTING-Chain in der nat-Tabelle, etwa so:
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.0.10:80
Vergiss nicht, IP-Forwarding zu aktivieren.

Weil Du Regeln on-the-fly ändern kannst, ohne komplette IPTables-Neuladevorgänge. So kannst Du Ports öffnen oder schließen, ohne bestehende Verbindungen zu kappen.

Es fehlt das State Tracking, es gibt weniger (oder gar keine) aktuelle Extensions, und die Konfigurationsmöglichkeiten sind deutlich eingeschränkter. In Sachen Sicherheit ist das ein erheblicher Nachteil.

Beispiel: sudo iptables -P INPUT DROP. Damit setzt Du die Standard-Policy für die INPUT-Chain auf DROP. Vergiss nicht, erwünschten Traffic explizit zu erlauben.

Nein, Du kannst Firewalld komplett über die CLI (firewall-cmd) konfigurieren. Es gibt aber GUIs wie firewall-config für Anwender, die lieber klicken.

Jede Zone hat bestimmte vordefinierte Regeln, die den Traffic mehr oder weniger restriktiv behandeln. Beispielsweise ist „public“ relativ offen, während „drop“ alles verwirft, außer das Nötigste.

IPChains kam mit dem Linux-Kernel 2.2 heraus. Das wurde 1999 veröffentlicht. Du siehst also, es ist ziemlich angestaubt und lange nicht mehr aktuell.

Frag den Status ab: systemctl status firewalld oder sudo firewall-cmd --state. Für IPTables: sudo iptables -L. Manche Distributionen haben eine Standard-Einstellung, aber beide Tools könnten vorhanden sein.

Es gibt kein offizielles automatisches Conversion-Tool. Du könntest Deine IPTables-Regeln manuell in Firewalld-Zonen übersetzen oder Firewalld nur als Frontend fürs IPTables-Backend laufen lassen. Komplett bequem ist das aber nicht.

Fedora, CentOS und RHEL nutzen Firewalld standardmäßig. Debian und Ubuntu setzen oft noch auf ufw oder gar keine voreingestellte Firewall, lassen sich aber problemlos mit Firewalld bestücken.

Eine Stateful Firewall erkennt zusammenhängende Verbindungen und kann darauf reagieren, ob ein Paket Teil einer bereits bestehenden Verbindung ist. IPTables (mit ip_conntrack) und Firewalld (über nftables/iptables) unterstützen das.

Ja, über sudo systemctl stop firewalld && sudo systemctl disable firewalld. Dann bist Du allerdings ungeschützt, es sei denn, Du setzt aktiv IPTables-Regeln oder hast eine andere Firewall.

IPTables ist durchaus noch gebräuchlich, allerdings nimmt nftables in modernen Systemen zunehmend dessen Stelle ein. Firewalld kann wiederum beides (iptables oder nftables) ansteuern. IPTables selbst ist aber immer noch funktional und verbreitet.

In der Regel werden IPTables-Regeln angewendet, sobald Du sie setzt. Es kann aber passieren, dass Du Dich aussperrst. Deswegen solltest Du Dich schrittweise vorarbeiten und Deine SSH-Session offen halten oder testweise Regeln per Script hinzufügen.

Ja, Firewalld unterstützt IPv4, IPv6, Bridges, VLANs und mehr. Deine Konfiguration kannst Du anpassen, indem Du die passende Zone und Dienste definierst.

Nur, wenn Du ein extrem altes System administrierst, das IPTables gar nicht kennt. In modernen Setups hast Du keinerlei Vorteil durch IPChains.

Du kannst LOG als Target verwenden, z. B. sudo iptables -A INPUT -p tcp --dport 22 -j LOG --log-prefix "SSH-ATTEMPT: ". So bekommst Du Einträge in Deinem Syslog.

Ja, Du kannst über firewall-cmd --permanent --direct auch direkt IPTables-Regeln hinzufügen, wenn Dir die Zonen-Logik nicht ausreicht.

Beispiel Debian/Ubuntu: sudo apt-get remove firewalld. Achte darauf, danach eventuell IPTables oder eine andere Lösung zu aktivieren, damit Du nicht ungeschützt bist.

Genau wie in IPTables gab es in IPChains vordefinierte Chains, um eingehenden, ausgehenden oder weitergeleiteten Traffic zu bearbeiten. Das Konzept ist bei IPTables erweitert worden.

Du kannst es umgehen, indem Du direkt IPTables- oder nftables-Regeln setzt, oder eine andere Firewall-Lösung wie ufw (Uncomplicated Firewall) nutzen. Firewalld ist nur eine von mehreren Möglichkeiten.

Ja, das Tool firewall-config bietet eine simple GUI. Unter GNOME findest Du es teilweise schon vorinstalliert. Sonst installierst Du es meist über dasselbe Paket wie Firewalld.

Standardmäßig loggt Firewalld nicht jeden Paket-Drop. Wenn Du das willst, musst Du Logging-Regeln aktivieren oder die „LogDenied“-Option setzen, z. B. in /etc/firewalld/firewalld.conf oder per firewall-cmd.

Nimm Firewalld (mit nftables-Unterbau) oder direkt nftables. IPTables ist noch in Ordnung, aber auf dem Weg in den Legacy-Status. IPChains ist historisch und definitiv nicht mehr empfehlenswert.