Die Architektur von Iptables und Netfilter

Eine Firewall ist ein Sicherheitsgerät (Hardware/Software), das das Netzwerk schützt, indem es den Datenverkehr filtert und unerwünschten/unbefugten Zugriff auf private Daten blockiert. Eine ordnungsgemäße Firewall ist wichtig, um Ihre Server und Ihre Infrastruktur zu schützen. Sie kann nicht nur unerwünschten Datenverkehr blockieren, sondern auch verhindern, dass Schadsoftware das System infiziert.

Im Linux-Ökosystem ist iptables eine beliebte Firewall, die eine Schnittstelle zum netfilter-Framework im Linux-Kernel bildet. Die meisten modernen Linux-Systeme sind bereits mit diesen Tools ausgestattet. Um das Beste aus diesen Systemen herauszuholen, ist es unerlässlich, ihre Architekturen zu verstehen. Andernfalls kann die Entwicklung zuverlässiger Firewall-Richtlinien entmutigend sein. Dies könnte zur Erstellung komplizierter Syntaxen, miteinander verknüpfter Teile im Framework usw. führen.

Dieser Leitfaden wird tief in die Architektur von iptables eintauchen, um Benutzern zu helfen, die ihre eigenen Firewall-Richtlinien erstellen müssen. Wir werden auch untersuchen, wie iptables mit netfilter interagiert und wie die verschiedenen Komponenten zusammenpassen.

Iptables und Netfilter

Unter Linux ist die iptables-Firewall die am weitesten verbreitete. Sie funktioniert durch die Interaktion mit den Paketfilter-Hooks im Netzwerk-Stack des Linux-Kernels. Es sind diese Kernel-Hooks, die zusammenfassend als das netfilter-Framework bezeichnet werden.

Jedes eingehende/ausgehende Paket im System löst diese Hooks aus, während es den Stack durchläuft. Auf diese Weise können die bei diesen Hooks registrierten Programme an Schlüsselpunkten mit dem Datenverkehr interagieren. Schließlich verbinden sich die Kernel-Module, die mit iptables assoziiert sind, mit diesen Hooks, um die angegebenen Firewall-Regeln durchzusetzen.

Netfilter-Hooks

Damit sich Programme verbinden können, gibt es fünf verschiedene netfilter-Hooks. Während Pakete den Stack durchlaufen, lösen die Hooks die bei ihnen registrierten Kernel-Module aus. Die Auslösebedingung hängt von Bedingungen ab wie:  der Paketrichtung (eingehend/ausgehend), dem Paketziel, ob das Paket an einem früheren Punkt verworfen/abgewiesen wurde usw.

Dies sind die Hooks, die verschiedene wohldefinierte Punkte im Netzwerk-Stack darstellen:

• NF_IP_PRE_ROUTING: Dieser Hook wird durch jeglichen eingehenden Datenverkehr ausgelöst. Die Auslösung erfolgt, bevor eine Routing-Entscheidung bezüglich des Ziels des Pakets getroffen wird.

• NF_IP_LOCAL_IN: Dieser Hook wird nach dem Routing eines eingehenden Pakets ausgelöst. Das Paket muss zudem für das lokale System bestimmt sein.

• NF_IP_FORWARD: Dieser Hook wird ebenfalls nach dem Routing eines eingehenden Pakets ausgelöst. Er wird jedoch ausgelöst, wenn das Paket an einen anderen Host weitergeleitet werden soll.

• NF_IP_LOCAL_OUT: Jeglicher lokale ausgehende Datenverkehr löst diesen Hook aus, sobald er den Netzwerk-Stack erreicht.

• NF_IP_POST_ROUTING: Dieser Hook wird durch jeglichen ausgehenden/weitergeleiteten Datenverkehr ausgelöst, nachdem das Routing stattgefunden hat, bevor das Paket die Leitung erreicht.

Kernel-Module, die sich für diese Hooks registrieren möchten, müssen eine Prioritätsnummer angeben. Dieser Wert hilft dabei, die Reihenfolge zu bestimmen, in der sie aufgerufen werden, sobald der Hook ausgelöst wird. Ein solcher Mechanismus ermöglicht es mehreren Modulen (verschiedenen Modulen oder mehreren Kopien desselben Moduls), sich in einer deterministischen Reihenfolge mit jedem der Hooks zu verbinden. Jedes Modul gibt nach der Verarbeitung der Pakete eine Entscheidung an das netfilter -Framework zurück.

Tabellen und Chains in Iptables

Um ihre Regeln zu organisieren, verwendet die iptables-Firewall Tabellen. Die Tabellen kategorisieren die Regeln basierend auf der Art der Entscheidungen, die sie treffen. Wenn sich eine Regel beispielsweise mit NAT (Network Address Translation) befasst, wird die Regel unter der nat-Tabelle abgelegt. Ebenso wird eine Regel, die darüber entscheidet, ob ein Paket an sein Ziel zugelassen oder abgewiesen werden soll, der filter -Tabelle hinzugefügt.

Innerhalb jeder Tabelle von iptables, sind die Regeln weiter in separaten “Chains” organisiert. Während die Tabelle die Art der Regeln darstellt, die sie enthält, beschreiben die Chains die netfilter -Hooks, die die Regeln auslösen. Kurz gesagt bestimmen Chains, wann die Regel ausgewertet wird.

Hier sind die integrierten Chains von iptables. Interessanterweise spiegeln die Chain-Namen auch den Namen des zugehörigen netfilter Hooks wider:

Mithilfe der Chains können Administratoren bestimmen, in welcher Phase der Paketzustellung die Regel ausgewertet wird. Da jede Tabelle mehrere Chains enthält, kann sie ihren Einfluss auch auf mehrere Punkte in der Verarbeitung ausdehnen. Bestimmte Entscheidungen sind nur an bestimmten Punkten des Netzwerk-Stacks sinnvoll. Daher hat nicht jede Tabelle eine Chain, die bei jedem Kernel-Hook registriert ist.

Das netfilter-Framework bietet nur 5 Kernel-Hooks. Daher sind an jedem Punkt der Hooks Chains aus mehreren Tabellen registriert. Wenn beispielsweise drei Chains die PREROUTING-Chains haben, dann sind sie beim NF_IP_PRE_ROUTING-Hook registriert. Jede von ihnen muss eine Priorität angeben, die entscheidet, in welcher Reihenfolge die PREROUTING-Chain jeder Tabelle aufgerufen wird. Die PREROUTING-Chain mit der höchsten Priorität wird zuerst ausgewertet, die mit der nächsthöheren Priorität als zweite und so weiter.

Die iptables-Tabellen

Gehen wir einen Schritt zurück und werfen einen Blick auf die Tabellen, die iptables bietet. Wie bereits erwähnt, repräsentiert jede Tabelle verschiedene Regelsätze, die nach Aufgabenbereich organisiert sind, für die Paketauswertung.

• filter-Tabelle

In iptables ist die filter-Tabelle eine der bekanntesten. Sie wird verwendet, um zu bestimmen, ob ein Paket sein Ziel weiter ansteuern darf oder nicht. In der Firewall-Terminologie wird dieser Prozess als “Filtern” von Paketen bezeichnet.

Es sind die Funktionen der filter Tabelle, auf die sich die meisten Menschen beziehen, wenn sie über Firewalls sprechen.

• nat-Tabelle

Diese Tabelle implementiert Regeln zur Regulierung von NAT. Wenn Pakete in den Netzwerk-Stack gelangen, entscheiden die in dieser Tabelle beschriebenen Regeln, wie die Quell-/Zieladresse des Pakets geändert wird, was sich auf das Routing des Pakets und jeglichen Antwortverkehr auswirkt.

Oft wird die nat-Tabelle verwendet, um Pakete in Netzwerke zu leiten, zu denen kein direkter Zugriff besteht.

• mangle-Tabelle

Diese Tabelle enthält die Regeln, die die IP-Header der Pakete auf verschiedene Weise ändern. Beispielsweise kann sie den TTL-Wert (Time to Live) eines Pakets ändern, indem sie die Anzahl der gültigen Netzwerk-Hops, die das Paket überstehen kann, verlängert oder verkürzt. Darüber hinaus kann die mangle-Tabelle andere IP-Header auf ähnliche Weise ändern.

Diese Tabelle darf auch eine interne Kernel-“Markierung” auf dem Paket hinterlassen, die andere Tabellen und Netzwerk-Tools zur weiteren Verarbeitung aufgreifen können. Diese Markierung berührt nicht das eigentliche Paket, sondern fügt die Markierung der Kernel-Repräsentation des Pakets hinzu.

• raw-Tabelle

Die iptables-Firewall ist Stateful (zustandsorientiert), was bedeutet, dass die Pakete im Kontext ihrer Beziehung zu vorherigen Paketen ausgewertet werden. Die Verbindungsverfolgungsfunktion (Connection Tracking), die auf dem netfilter-Framework aufbaut, ermöglicht es iptables Pakete als Teil einer laufenden Verbindung oder Sitzung zu betrachten und nicht als einen Strom einzelner, nicht zusammenhängender Pakete. Im Allgemeinen wird die Verbindungsverfolgungslogik sehr bald nach dem Eintreffen des Pakets an der Netzwerkschnittstelle angewendet.

Die raw-Tabelle hat eine sehr eng definierte Funktion. Der einzige Zweck dieser Tabelle besteht darin, einen Mechanismus zur Markierung von Paketen bereitzustellen, um sie von der Verbindungsverfolgung auszuschließen.

• security-Tabelle

Die security Tabelle versieht Pakete mit internen SELinux-Sicherheitskontext-Markierungen. Dies wiederum beeinflusst, wie SELinux (oder jede andere Anwendung, die SELinux-Sicherheitskontexte interpretiert) die Pakete behandelt.

Die SELinux-Markierungen können pro Paket oder pro Verbindung angewendet werden.

In jeder Tabelle implementierte Chains

Bisher haben wir über Tabellen und Chains separat gesprochen. Es ist an der Zeit zu klären, welche Chains in welcher Tabelle verfügbar sind. Dieses Thema erweitert die Diskussion über die Reihenfolge der Auswertung von Chains, die für denselben Hook registriert sind. Was passiert beispielsweise, wenn drei Tabellen über PREROUTING-Chains verfügen? Wie ist ihre Reihenfolge bei der Auswertung?

Werfen Sie als Nächstes einen Blick auf die folgende Tabelle. Sie zeigt die Chains, die verfügbar sind in jeder iptables-Tabelle.

Von links nach rechts gelesen beschreibt sie, welche Tabellen welche Chains enthalten. Zum Beispiel hat die raw-Tabelle sowohl PREROUTING- als auch OUTPUT-Chains. Von oben nach unten gelesen beschreibt sie, in welcher Reihenfolge jede Chain aufgerufen wird, wenn ihr zugehöriger netfilter Hook ausgelesen wird.

Beachten Sie, dass die nat-Tabelle aufgeteilt wurde zwischen DNAT-Operationen (Ändern des Ziels eines Pakets) und SNAT-Operationen (Ändern der Quelle eines Pakets), um deren Reihenfolge klarer festzulegen. Die Tabelle enthält auch Darstellungspunkte, an denen Routing-Entscheidungen getroffen werden und an denen die Verbindungsverfolgung aktiviert ist.

Die Hooks (Spalten), die ein Paket auslöst, basieren auf der Natur des Pakets (eingehend/ausgehend), den getroffenen Routing-Entscheidungen und der Frage, ob ein Paket die Filterkriterien erfüllt.

Bestimmte Ereignisse können eine Chain einer Tabelle während der Verarbeitung überspringen. Beispielsweise wird nur das erste Paket einer Verbindung anhand der NAT-Regeln bewertet, wie sie in der nat-Tabelle beschrieben sind. Für jedes nachfolgende Paket in derselben Verbindung werden dieselben nat-Entscheidungen ohne zusätzliche Bewertung angewendet. Auf Antworten auf die NAT-Verbindungen werden automatisch die umgekehrten NAT-Regeln für ein ordnungsgemäßes Routing angewendet.

Reihenfolge des Chain-Durchlaufs

Unter der Annahme, dass der Server die Paket-Routing-Regeln kennt und die Firewall-Regeln die Übertragung zulassen, stellen die folgenden Abläufe dar, wie die verschiedenen Pfade durchlaufen werden:

• Eingehende Pakete, die für das lokale System bestimmt sind: PREROUTING >> INPUT

• Eingehende Pakete, die für einen anderen Host bestimmt sind: PREROUTING >> FORWARD >> POSTROUTING

• Lokal generierte Pakete: OUTPUT >> POSTROUTING

Zusammenfassend lässt sich unter Berücksichtigung aller bisher besprochenen Informationen feststellen, dass jedes eingehende Paket, das für das lokale System bestimmt ist, anhand der PREROUTING-Chains der Tabellen raw, , mangle, und nat-Tabellen bewertet wird. Anschließend durchläuft es die INPUT-Chains der Tabellen mangle, , filter, , security, und nat-Tabellen, bevor es schließlich den lokalen Socket erreicht.

Iptables-Regeln

Die iptables -Firewall-Regeln befinden sich in einer bestimmten Chain einer bestimmten Tabelle. Wenn eine Chain aufgerufen wird, wird das betreffende Paket anhand jeder Regel in der Chain bewertet. Jede Regel besteht aus zwei Komponenten: einer Matching-Komponente und einer Aktionskomponente.

• Matching

Der Matching-Teil einer Regel gibt die Bedingungen an, die ein Paket erfüllen muss, bevor die angegebene Aktion (oder das “Target”) ausgeführt wird.

Das Matching-System bietet eine unglaubliche Flexibilität. Seine Funktionalität kann auch mithilfe von iptables-Erweiterungen erweitert werden. Regeln können so definiert werden, dass sie Pakete nach Protokolltyp, Quell-/Zieladresse, Quell-/Zielport, Quell-/Zielnetzwerk, Eingangs-/Ausgangsschnittstelle, Headern, Verbindungsstatus und anderen Kriterien filtern. Eine Regel kann auch eine Kombination dieser Bedingungen enthalten, was zu komplexen Regelsätzen führt, um zwischen verschiedenen Verkehrsarten zu unterscheiden.

• Targets

Ein Target ist die Aktion, die ausgeführt wird, wenn ein Paket die Matching-Kriterien einer Regel erfüllt. Im Allgemeinen werden Targets in zwei Gruppen unterteilt:

• • Terminierende Targets: Sie beenden den Bewertungsprozess innerhalb der Chain und geben die Kontrolle an den netfilter-Hook zurück. Basierend auf dem Rückgabewert lässt der Hook das Paket entweder weiterreisen oder verwirft es.

  • Nicht-terminierende Targets: Das Target führt eine Aktion aus und die Bewertung in der Chain wird fortgesetzt. Obwohl jede Chain eine endgültige terminierende Entscheidung durchlaufen muss, kann zuvor eine beliebige Anzahl nicht-terminierender Targets stattfinden.

Die Verfügbarkeit jedes Targets innerhalb von Regeln ist vom Kontext abhängig. Beispielsweise können der Chain- und Tabellentyp die Verfügbarkeit von Targets beeinflussen. Weitere mögliche Faktoren sind aktivierte Erweiterungen in der Regel und die übereinstimmenden Klauseln.

Benutzerdefinierte Chains

Es gibt auch eine spezielle Klasse von nicht-terminierenden Targets: das Jump-Target. Jump-Targets sind Aktionen, die ausgeführt werden, wenn die Auswertung von einer Chain zu einer anderen für eine zusätzliche Verarbeitung wechselt. Bisher haben wir über integrierte Chains gesprochen, die eng mit den netfilter-Hooks verbunden sind, die sie aufrufen. Allerdings ermöglicht iptables es Admins auch, ihre eigenen benutzerdefinierten Chains zu erstellen.

Regeln in benutzerdefinierten Chains ähneln ebenfalls denen in integrierten Chains. Der Hauptunterschied besteht darin, dass benutzerdefinierte Chains nur erreichbar sind, indem man von einer Regel aus zu ihnen “springt”. Das liegt daran, dass benutzerdefinierte Chains nicht mit irgendwelchen netfilter-Hooks verknüpft sind.

Sie können sich benutzerdefinierte Chains als Erweiterungen der Chain vorstellen, die sie ursprünglich aufgerufen hat. Beispielsweise wird in einer benutzerdefinierten Chain die Auswertung an die aufrufende Chain zurückgegeben, wenn sie das Ende der Regelliste erreicht oder eine übereinstimmende Regel ein RETURN-Target ausführt. Interessanterweise kann eine benutzerdefinierte Chain die Auswertung auch zu einer anderen benutzerdefinierten Chain “springen” lassen.

Diese Funktion legt den Grundstein für eine bessere Organisation und den notwendigen Rahmen für eine robuste Verzweigung.

Verbindungsverfolgung

Bei der Erörterung der raw-Tabelle und der Kriterien für die Übereinstimmung des Verbindungsstatus haben wir das Verbindungsverfolgungssystem besprochen, das auf dem netfilter-Framework implementiert ist. Diese Funktion ermöglicht es iptables , Pakete im Kontext einer laufenden Verbindung zu betrachten. Das Verbindungsverfolgungssystem stellt iptables außerdem die erforderliche Funktionalität zur Durchführung von “stateful” (zustandsgesteuerten) Operationen zur Verfügung.

Direkt nach dem Eintritt eines Pakets in den Netzwerk-Stack wird die Verbindungsverfolgung angewendet. Die Chains der raw-Tabelle und einige grundlegende Plausibilitätsprüfungen sind die gesamte Logik, die für die Zuordnung von Paketen zu einer Verbindung erforderlich ist.

Das System prüft jedes Paket gegen eine Reihe bestehender Verbindungen. Bei Bedarf aktualisiert das System den Status der bestehenden Verbindungen oder erstellt neue. Pakete, die in einer der Chains der raw-Tabelle mit dem NOTRACK-Target markiert wurden, umgehen weitere Verbindungsverfolgungsroutinen.

• Verfügbare Zustände

Verbindungen, die vom Verbindungsverfolgungssystem verfolgt werden, wird einer der folgenden Zustände zugewiesen:

• • NEW : Nach dem Eintreffen eines Pakets, das keiner bestehenden Verbindung zugeordnet ist, aber als erstes Paket nicht ungültig ist, wird dem System eine neue Verbindung mit diesem Label hinzugefügt. Dies geschieht sowohl bei verbindungsorientierten Protokollen (z. B. TCP) als auch bei verbindungslosen Protokollen (z. B. UDP).

  • ESTABLISHED: Der Status einer Verbindung wird von NEW  auf ESTABLISHED aktualisiert, wenn eine gültige Antwort aus der Gegenrichtung empfangen wird. Für TCP-Verbindungen bedeutet dies ein SYN/ACK. Für UDP- und ICMP-Verkehr bedeutet dies eine Antwort, bei der Quelle und Ziel des ursprünglichen Pakets vertauscht sind.

  • RELATED: Pakete, die nicht Teil einer Verbindung sind, aber mit einer bestehenden Verbindung in Beziehung stehen, werden als RELATED  gekennzeichnet. Dies kann eine Hilfsverbindung bedeuten (z. B. bei einer FTP-Datenübertragungsverbindung) oder ICMP-Antworten auf Verbindungsversuche anderer Protokolle.

  • INVALID: Pakete, die nicht Teil einer bestehenden Verbindung sind, als ungeeignet für den Aufbau einer neuen Verbindung erachtet werden, nicht identifiziert werden können, nicht routingfähig sind usw., werden als INVALID.

  • UNTRACKED: Ein Paket kann als UNTRACKED gekennzeichnet werden, wenn es in einer Chain der raw-Tabelle als Ziel ausgewählt wurde, um die Verfolgung zu umgehen.

  • SNAT: Es kennzeichnet einen virtuellen Zustand, der gesetzt wird, wenn die Quelladresse durch eine NAT-Operation geändert wird. Dies wird vom Verbindungsverfolgungssystem so gehandhabt, dass die Quelladressen in Antwortpaketen übersetzt werden.

  • DNAT: Ähnlich wie SNAT, bedeutet dies einen virtuellen Zustand, wenn die Zieladresse durch eine NAT-Operation geändert wird. Das Verbindungsverfolgungssystem verarbeitet dies so, dass es weiß, dass es die Zieladresse beim Routen von Antwortpaketen wieder zurückübersetzen muss.

Diese vom Verbindungsverfolgungssystem verfolgten Zustände ermöglichen es Administratoren, spezifische Regeln zu erstellen, die auf bestimmte Punkte im Lebenszyklus einer Verbindung abzielen. Dies bietet die notwendige Funktionalität für gründlichere und sicherere Regeln.

Schlussgedanken

Unter Linux bilden das netfilter-Framework und die iptables-Firewall die Basis für die meisten Firewalls. Die Netfilter-Hooks sind nah genug am Netzwerk-Stack, um eine leistungsstarke Kontrolle über die vom System verarbeiteten Pakete zu ermöglichen. Durch die Nutzung dieser Funktionen bietet die iptables-Firewall eine flexible Möglichkeit, Richtlinienanforderungen an den Kernel zu übermitteln.

Diese Anleitung befasst sich eingehend mit der inneren Struktur des netfilter-Frameworks und der iptables-Firewall. Darüber hinaus wird das Verbindungsverfolgungssystem behandelt. Wenn Sie verstehen, wie diese Teile zusammenpassen, können Sie sie besser nutzen, um robustere und sicherere Serverumgebungen zu erstellen.

Obwohl sich diese Anleitung mit den internen Abläufen befasst, sollten Sie sich abschließend diese Anleitung zur Konfiguration von iptables ansehen, um sie in der Praxis anzuwenden. Darüber hinaus können Sie sehen, wie die UFW-Firewall further simplifies iptables weiter vereinfacht. Darüber hinaus ist es nützlich zu erfahren, wie Sie iptables-Firewall-Regeln auflisten und löschen.

Fröhliches Schaffen!