Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP Firewall Chains (2.2-Kernel)

Die meisten Funktionen von Linux werden weiterentwickelt, um den Anforderungen seiner Benutzer gerecht zu werden. IP-Firewalls machen da keine Ausnahme. Die traditionelle Implementierung von IP-Firewalls ist für die meisten Anwendungen völlig ausreichend. In komplexen Umgebungen kann deren Konfiguration allerdings ziemlich schwerfällig und ineffizient werden. Um diesen Schwachpunkt aus dem Weg zu räumen, wurde ein neues Konfigurationsverfahren für IP-Firewalls und deren Zusatz-Features entwickelt. Diese neue Methode nennt sich “IP Firewall Chains” und wurde der Öffentlichkeit erstmals mit dem Kernel 2.2.0 zur Verfügung gestellt.

Die Unterstützung von IP Firewall Chains wurde von Paul Russell und Michael Neuling entwickelt.¹ Paul dokumentierte die IP-Firewall-Chains-Software im IPCHAINS-HOWTO.

IP Firewall Chains ermöglichen es Ihnen, Klassen von Firewall-Regeln zu entwickeln, denen Sie dann Hosts oder Netzwerke hinzufügen bzw. wieder entfernen können. Durch die Verbindung (chaining) von Firewall-Regeln kann die Performance einer Firewall besonders in solchen Konfigurationen erhöht werden, in denen besonders viele Regeln vorkommen.

IP Firewall Chains werden von der Kernel-Serie 2.2 unterstützt. Sie können durch einen Patch auch mit den 2.0.*-Kerneln genutzt werden. Wo man diesen Patch erhält, wird im HOWTO beschrieben. Dort sind auch eine Menge nützlicher Tips enthalten, wie man das Konfigurations-Tool ipchains effektiv nutzen kann.

Anwendung von ipchains

Es gibt zwei Möglichkeiten, das Hilfsmittel ipchains zu benutzen. Erstens kann man das Shell-Skript ipfwadm-wrapper benutzen. Dieses stellt hauptsächlich einen schnellen Ersatz für ipfwadm dar. Hinter den Kulissen steuert es das Programm ipchains. Wenn Sie so vorgehen, brauchen Sie hier nicht weiterzulesen. Lesen Sie statt dessen den vorherigen Abschnitt über den ipfwadm-Befehl, und ersetzen Sie dabei diesen Befehl durch ipfwadm-wrapper. Das funktioniert zwar, es gibt aber keine Garantie, daß dieses Skript weiterhin gepflegt wird. Außerdem können Sie die Vorteile der erweiterten Funktionalität, die IP Firewall Chains zu bieten hat, nicht nutzen.

Die zweite Möglichkeit das Programm ipchains zu benutzen ist, seine neue Syntax zu erlernen und alle vorhandenen Konfigurationen, die Sie benutzen, entsprechend anzupassen. Mit ein wenig Überlegung können Sie Ihre Konfiguration dabei sogar optimieren. Da die neue Syntax von ipchains leichter zu lernen ist als die von ipfwadm, ist die Entscheidung für ipchains ohnehin eine gute Wahl.

ipfwadm bot nur drei verschiedene Regelsätze für die Konfiguration von Firewalls. Bei IP Firewall Chains können Sie dagegen beliebig viele Regelsätze einführen, die alle miteinander verbunden sind. Drei für Firewalling zuständige Regelsätze sind allerdings immer präsent. Diese Standard-Regelsätze sind äquivalent zu denen von ipfwadm, haben aber zusätzlich Namen: input, forward und output.

Zunächst betrachten wir die allgemeine Syntax von ipchains. Danach sehen wir, wie wir ipchains anstelle von ipfwadm benutzen können, ohne uns zunächst irgendwelche Gedanken über die erweiterten Verkettungs-Möglichkeiten (Chaining-Features) zu machen. Dabei greifen wir auf einige frühere Beispiele zurück.

Die Befehlssyntax von ipchains

Die Befehlssyntax von ipchains ist einfach. Wir betrachten nur die wichtigsten Sprachstrukturen. Die allgemeine Syntax der meisten ipchains-Befehle ist:

ipchains Befehl Regelspezifikation Optionen

Befehle

Es gibt mehrere Wege, Regeln und Regelsätze mit ipchains zu modifizieren. Die für IP-Firewalling relevanten sind:

-A Chain

Fügt eine oder mehrere Regeln an das Ende der bezeichneten Kette an. Falls ein Hostname als Quell- oder Zieladresse angegeben ist und er zu mehr als einer IP-Adresse aufgelöst werden kann, wird für jede dieser Adressen eine eigene Regel hinzugefügt.

-I Chain Regelnummer

Fügt eine oder mehrere Regeln am Anfang der bezeichneten Regel ein. Falls ein Hostname als Quell- oder Zieladresse angegeben ist und er zu mehr als einer IP-Adresse aufgelöst werden kann, wird für jede dieser Adressen eine eigene Regel hinzugefügt.

-D Chain

Entfernt eine oder mehrere Regeln aus der angegebenen Kette, die der Regelspezifikation entsprechen.

-D Chain Regelnummer

Entfernt die an Position Regelnummer befindliche Regel aus der angegebenen Kette. Regelpositionen in der Kette werden beginnend mit eins numeriert.

-R Chain Regelnummer

Ersetzt die an Position Regelnummer befindliche Regel in der angegebenen Kette durch die angegebene Regelspezifikation.

-C Chain

Testet ein durch die Regelspezifikation beschriebenes Datagramm gegen die angegebene Kette. Diese Anweisung liefert eine Meldung zurück, wie das Datagramm von der Kette verarbeitet wurde. Sie ist sehr nützlich zum Testen von Firewall-Konfigurationen. Darauf gehen wir später im Detail ein.

-L [Chain]

Listet die Regel der angegebenen Kette auf (oder die Regeln aller Ketten, falls keine bestimmte Kette angegeben ist).

-F [Chain]

Aktualisiert die Regeln der angegebenen Kette (oder für alle Ketten, falls keine bestimmte angegeben ist).

-Z [Chain]

Setzt die Datagramm und Bytezähler aller Regeln der angegebenen Kette auf null (oder für alle Ketten, falls keine bestimmte angegeben ist).

-N Chain

Erzeugt eine neue Kette mit der angegebenen Bezeichnung (es darf allerdings keine Kette mit gleichem Namen existieren). Hiermit werden benutzerdefinierte Ketten erzeugt.

-X [Chain]

Entfernt die angegebene benutzerdefinierte Kette (oder alle benutzerdefinierten Ketten, falls keine bestimmte angegeben ist). Damit diese Anweisung tatsächlich ausgeführt wird, darf es keine Referenzen von irgendeiner anderen Regelkette auf diese Kette geben.

-P Chain Standardaktion

Setzt die Standardaktion der angegebenen Kette auf die angegebene Aktion. Zulässige Firewalling-Aktionen sind ACCEPT, DENY, REJECT, REDIR oder RETURN. ACCEPT, DENY und REJECT haben dieselbe Bedeutung wie in der traditionellen IP-Firewall-Implementierung. REDIR gibt an, daß das Datagramm transparent zu einem Port auf dem Firewall-Host umgeleitet werden soll. Die Aktion RETURN bewirkt, daß der IP-Firewalling-Code die Verarbeitung der aktuellen Kette beendet und an die Stelle in der ursprünglichen Kette zurückkehrt, die der Verzweigung folgt.

Parameter zur Regelspezifikation

Zur Bildung einer Regelspezifikation gibt es eine Reihe von ipchains-Parametern, die die zu erkennenden IP-Pakete festlegen. Wird einer dieser Parameter in einer Regel weggelassen, wird stattdessen der jeweilige Standardwert eingesetzt:

-p [!]Protokoll

Spezifiziert das Protokoll des Datagramms, das zu dieser Regel paßt. Zulässige Protokollnamen sind tcp, udp, icmp oder all. Sie können hier auch eine IP-Protokollnummer angeben, um andere Protokolle zuzulassen. Beispielsweise könnten Sie 4 angeben, um die jeweilige Regel auf Datagramme dieses IP-über-IP-Protokolls (ipip-Encapsulation-Protokolls) anzuwenden. Wenn Sie das Zeichen ! mit angeben, wird die Regel negiert, und es wird nur gegen Datagramme anderer Protokolle getestet. Ist dieser Parameter überhaupt nicht angegeben, wird dafür all genommen.

-s [!]Adresse[/Netzmaske] [!] [Port]

Gibt die Quelladresse und den Quell-Port des Datagramms an, das zu dieser Regel paßt. Die Adresse kann als Hostname, Netzwerkname oder IP-Adresse angegeben werden. Die optionale Netzmaske kann entweder in traditioneller Form (z.B. /255.255.255.0) oder in moderner Form (z.B. /24) angegeben werden. Der optionale Port gibt den TCP- oder UDP-Port oder den ICMP-Datagrammtyp an, der zur Regel paßt. Den Port dürfen Sie allerdings nur dann spezifizieren, wenn Sie den Parameter -p zusammen mit einem der Protokolle tcp, udp oder icmp angegeben haben. Die Ports können auch bereichsweise angegeben werden, und zwar in Form einer Untergrenze, gefolgt von einem Doppelpunkt, gefolgt von einer Obergrenze. So beschreibt zum Beispiel der Ausdruck 20:25 alle Ports zwischen 20 und 25 (inklusive). Auch hier kann das Zeichen ! zur Negierung eingesetzt werden.

-d [!]Adresse[/Netzmaske] [!] [Port]

Spezifiziert die Zieladresse und den Ziel-Port des Datagramms, das zu dieser Regel paßt. Beide Größen werden wie beim Parameter -s angegeben.

-j Ziel

Spezifiziert die durchzuführende Aktion, wenn diese Regel paßt. Die Regel können Sie gewissermaßen als “GOTO”-Anweisung auffassen, deren Zielanweisung eine der folgenden ist: ACCEPT, DENY, REJECT, REDIR und RETURN. Die Bedeutung dieser Ziele haben wir bereits beschrieben. Sie können hier auch den Namen einer benutzerdefinierten Kette angeben, in der die Abarbeitung fortgesetzt werden soll. Fehlt der Parameter, findet für die passenden Datagramme überhaupt keine Aktion statt. Es werden lediglich der Datagramm- und der Bytezähler aktualisiert.

-i [!]Schnittstelle

Spezifiziert die Schnittstelle, von der ein Datagramm empfangen oder an die ein Datagramm gesendet wird. Auch hier dient ! zur Negierung des Vergleichstests. Endet der Schnittstellen-Bezeichner mit +, gilt die Regel für alle Schnittstellen, deren Namen mit der angegebenen Zeichenfolge beginnen. Beispielsweise bezeichnet der Ausdruck -i ppp+ alle PPP-Netzwerkgeräte. Der Ausdruck -i ! eth+ bezeichnet dagegen alle Schnittstellen mit Ausnahme der Ethernet-Geräte.

[!] -f

Gibt an, daß die Regel auf alle Fragmente eines fragmentierten Datagramms mit Ausnahme des ersten Fragments angewendet werden soll.

Optionen

Die folgenden ipchains-Optionen sind allgemeiner Natur. Einige von ihnen steuern ziemlich ausgefallene Features der IP Chains Software:

-b

Bewirkt die Erzeugung zweier Regeln. Die erste führt einen Vergleich mit den übergebenen Parametern durch, die zweite führt einen Parametervergleich in umgekehrter Richtung durch.

-v

Veranlaßt ipchains zur Ausgabe detaillierter Informationen.

-n

Bewirkt, daß ipchains IP-Adressen und Ports nur als Nummern ausgibt, ohne sie in ihre entspechenden Klartextnamen aufzulösen.

-l

Schaltet die Kernel-Protokollierung passender Datagramme ein. Jedes Datagramm, das zur Regel paßt, wird vom Kernel mittels seiner printk()-Funktion in eine Logdatei protokolliert, für die gewöhnlich das Programm sysklogd zuständig ist. Damit können zum Beispiel ungewöhnliche Datagramme aufgespürt werden.

-o[MaxGröße]

Veranlaßt die IP Chains Software, jedes zur Regel passende Datagramm zum “netlink”-Device im Benutzerbereich zu kopieren. Das Argument MaxGröße begrenzt die Anzahl der Bytes jedes Datagramms, das das netlink-Device erreicht. Diese Option ist besonders für Entwickler gedacht, könnte aber in Zukunft auch von manchen Softwarepaketen genutzt werden.

-m Markierungswert

Bewirkt, daß passende Datagramme mit einem Wert markiert werden. Markierungswerte sind vorzeichenlose 32-Bit-Werte. Sie werden von den existierenden Implementierungen zwar noch nicht benutzt, das kann sich in Zukunft aber ändern. Man könnte damit unter anderem feststellen, wie ein Datagramm von anderen Softwarepaketen (z.B. Routing-Code) verarbeitet wird. Beginnt ein Markierungswert mit einem + bzw. -, wird er zum existierenden Markierungswert addiert bzw. von diesem subtrahiert.

-t UND-Maske XOR-Maske

Diese Option gestattet Ihnen die Bearbeitung der “Type of Service”-Bits im IP-Header jedes zur Regel passenden Datagramms. Die Type-of-Service-Bits werden von intelligenten Routern dazu benutzt, Datagramme vor ihrer Weitergabe nach Prioritäten zu ordnen. Die Routing-Software von Linux ist dazu fähig. Die UND-Maske und die XOR-Maske repräsentieren Bitmasken, die einer logischen UND- bzw. exklusiven ODER-Verknüpfung mit den Type-of-Service-Bits des Datagramms unterzogen werden. Hierbei handelt es sich um ein ergänzendes Feature, das etwas ausführlicher im IPCHAINS-HOWTO behandelt wird.

-x

Bewirkt, daß jeder Zahlenwert in der ipchains-Ausgabe exakt, also ohne Auf- oder Abrunden angezeigt wird.

-y

Veranlaßt die Regel, nur solche TCP-Datagramme zu prüfen, deren SYN-Bit gesetzt und deren ACK- und FIN-Bits nicht gesetzt sind. Damit können TCP-Verbindungsanfragen gefiltert werden.

Rückblick auf unser einfaches Beispiel

Nehmen wir mal wieder an, wir hätten in unserer Firma ein Netzwerk mit einem Linux-basierten Firewall-Rechner, der unseren Benutzern nur Zugriff auf Webserver im Internet ermöglicht, ansonsten aber keinen Datenverkehr zuläßt.

Wenn unser Netzwerk eine Netzmaske von 24 Bit hat (Class C) und die Adresse 172.16.1.0, würden wir folgende ipchains-Regeln benutzen:

# ipchains -F forward # ipchains -P forward DENY # ipchains -A forward -s 0/0 80 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 80 -p tcp -b -j ACCEPT

Die erste Anweisung versetzt alle Regeln der forward-Regelsätze in einen definierten Ausgangszustand. Die zweite Anweisung stellt die Standardaktion der forward-Regelsätze auf DENY. Die letzten beiden Regeln führen die eigentliche Filterung durch. Die dritte Regel wehrt eingehende TCP-Verbindungen von Port 80 ab, während die vierte Regel Datagramme von unserem Netzwerk zu Webservern der Außenwelt (bzw. umgekehrt) passieren läßt.

Wollten wir zudem ausschließlich passiven Zugriff auf FTP-Server der Außenwelt ermöglichen, würden wir folgende Regeln hinzufügen:

# ipchains -A forward -s 0/0 20 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 20 -p tcp -b -j ACCEPT # ipchains -A forward -s 0/0 21 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 21 -p tcp -b -j ACCEPT

Auflisten unserer Regeln mit ipchains

Um eine Liste unserer Regeln mit ipchains zu erhalten, benutzen wir die Option -L. Wie bei ipfwadm gibt es Argumente, die den Umfang der Ausgaben festlegen. In seiner einfachsten Form produziert ipchains Ausgaben, die etwa wie folgt aussehen:

# ipchains -L -n Chain input (policy ACCEPT): Chain forward (policy DENY): target     prot opt     source              destination         ports DENY       tcp  -y----  0.0.0.0/0           172.16.1.0/24       80 ->   * ACCEPT     tcp  ------  172.16.1.0/24       0.0.0.0/0           * ->   80 ACCEPT     tcp  ------  0.0.0.0/0           172.16.1.0/24       80 ->   * ACCEPT     tcp  ------  172.16.1.0/24       0.0.0.0/0           * ->   20 ACCEPT     tcp  ------  0.0.0.0/0           172.16.1.0/24       20 ->   * ACCEPT     tcp  ------  172.16.1.0/24       0.0.0.0/0           * ->   21 ACCEPT     tcp  ------  0.0.0.0/0           172.16.1.0/24       21 ->   *  Chain output (policy ACCEPT):

Wenn Sie keine Kette angeben, erzeugt ipchains eine Liste aller Regeln in allen Ketten. Die Option -n teilt ipchains mit, daß es keine Adressen oder Ports in Namen auflösen soll. Die präsentierten Informationen sollten selbsterklärend sein.

Eine ausführliche Ausgabe, bewirkt durch die Option -u, liefert wesentlich detailliertere Informationen. Seine Ausgabe enthält den Datagramm- und den Bytezähler, die AND- und XOR-Type-of-Service-Flags, den Schnittstellennamen, die Markierungswerte und die Ausgabegröße.

Allen mit ipchains erzeugten Regeln werden Datagramm- und Bytezähler zugeordnet. Damit wird zum Beispiel IP-Accounting realisiert (für Details siehe Kapitel 10 IP-Accounting). Standardmäßig werden Zählerstände in gerundeter Form mit angehängtem K bzw. M für Tausender- bzw. Millionen-Einheiten ausgegeben. Bei Angabe der Option -x werden die Zählerstände dagegen ungerundet in voller Länge ausgegeben.

Sinnvolle Anwendungen von Ketten

Nun wissen Sie, daß ipchains ein Ersatz für ipfwadm ist, mit einer simpleren Befehlssyntax und einigen interessanten Zusatzfunktionen. Aber zweifellos sind Sie nun neugierig geworden, was es mit den benutzerdefinierten Ketten auf sich hat und wozu sie gut sind. Vermutlich wollen Sie auch wissen, wie man die Support-Skripten benutzt, die der ipchains-Software beiliegen. Mit all diesen Fragen werden wir uns im folgenden beschäftigen.

Benutzerdefinierte Ketten

Die drei Regelsätze des traditionellen IP-Firewall-Codes stellten einen Mechanismus zur Bildung von Firewall-Konfigurationen zur Verfügung, die relativ einfach zu verstehen waren und zur Verwaltung kleiner Netzwerke mit einfachen Firewall-Anforderungen ausreichten. Sie erweisen sich allerdings als unzureichend, wenn die Anforderungen steigen. Zum einen erfordern große Netzwerke häufig wesentlich mehr Firewall-Regeln als die wenigen, die wir bisher gesehen haben. Unvermeidlich entsteht Bedarf an Regeln für spezielle Anwendungsfälle. Mit der zunehmenden Anzahl von Regeln sinkt allerdings die Performance der Firewall, da immer mehr Datagramm-Tests durchgeführt werden. Die Frage nach einer effizienten Verwaltung der Firewall drängt daher immer mehr in den Vordergrund. Zum anderen können komplette Regelsätze nicht als Einheit (“atomar”) ein- und ausgeschaltet werden. Stattdessen sind Sie in der Zeit angreifbar, in der Sie Ihre Regelsätze aufbauen.

Das Design der IP Firewall Chains hilft Ihnen, diese Probleme zu lindern, indem es dem Netzwerkadministrator gestattet, beliebige Firewall-Regelsätze zu erzeugen, die wir an die drei bereits vorhandenen Regelsätze anbinden können. Mit der Option -N können wir eine neue Kette mit beliebigem Namen aus maximal acht Zeichen erzeugen (die Beschränkung auf Kleinbuchstaben ist dabei vielleicht keine schlechte Idee). Die Option -j konfiguriert die Aktion, die durchgeführt werden soll, wenn ein Datagramm die Regel erfüllt. In diesem Fall wird es gegen eine benutzerdefinierte Kette geprüft. Wie das vor sich geht, veranschaulichen wir anhand eines Diagramms.

Betrachten Sie die folgenden ipchains-Anweisungen:

ipchains -P input DENY ipchains -N tcpin ipchains -A tcpin -s ! 172.16.0.0/16 ipchains -A tcpin -p tcp -d 172.16.0.0/16 ssh -j ACCEPT ipchains -A tcpin -p tcp -d 172.16.0.0/16 www -j ACCEPT ipchains -A input -p tcp -j tcpin ipchains -A input -p all

In der ersten Zeile setzen wir die Standardaktion für die Eingabe auf deny. Die zweite Anweisung erzeugt eine benutzerdefinierte Kette namens “tcpin”. Die Anweisung in der dritten Zeile fügt der tcpin-Kette eine Regel hinzu, die jedes Datagramm akzeptiert, dessen Ursprung außerhalb unseres lokalen Netzwerks liegt. Die Regel führt keine weitere Aktion durch, sondern ist lediglich eine “Abrechnungs-Regel” (accounting rule); darauf gehen wir näher in Kapitel 10 IP-Accounting, ein. Die nächsten beiden Regeln lassen alle Datagramme passieren, die für unser lokales Netzwerk bestimmt sind und die Ports ssh oder www benutzen. Die nächste Regel ist die Stelle, wo der wirkliche ipchains-Zauber beginnt. Es veranlaßt die Firewall-Software, alle Datagramme des TCP-Protokolls gegen die benutzerdefinierte Kette tcpin zu testen. Zu guter Letzt hängen wir noch eine Accounting-Regel an unsere input-Kette an, die alle verbleibenden Datagramme “verrechnet”. Die angegebenen Regeln erzeugen die in Abbildung 9.4 gezeigten Firewall-Ketten.

Abbildung 9.4: Ein einfacher IP-Chains-Regelsatz

Unsere input- und tcpin-Ketten sind mit unseren Regeln gefüllt. Die Verarbeitung der Datagramme beginnt immer in einer der fest installierten Ketten. Wie unsere benutzerdefinierte Kette hier ins Spiel kommt, werden wir noch sehen, wenn wir die Verarbeitungsschritte der verschiedenen Datagrammtypen genauer unter die Lupe nehmen.

Als erstes werfen wir einen Blick darauf, was passiert, wenn ein UDP-Datagramm für einen unserer Hosts empfangen wird. Den Datenfluß durch die Regeln illustriert Abbildung 9.5.

Das Datagramm wird von der input-Kette empfangen und fällt durch die ersten beiden Regeln, da diese auf ICMP- und TCP-Protokolle testen. Es paßt zwar zur dritten Regel in der input-Kette, aber diese gibt kein Ziel an, so daß nur die Datagramm- und Bytezähler aktualisiert werden, aber ansonsten keine Aktion stattfindet. Das Datagramm erreicht das Ende der input-Kette, die Standardregel kommt zur Anwendung und das Datagramm wird abgewiesen.

Abbildung 9.5: Die Reihenfolge der für ein empfangenes UDP-Datagramm getesteten Regeln

Um unsere benutzerdefinierte Kette in Aktion zu sehen, überlegen wir uns, was passiert, wenn wir ein TCP-Datagramm empfangen, das für den ssh-Port an einem unserer Hosts bestimmt ist. Abbildung 9.6 zeigt den Ablauf.

Abbildung 9.6: Die Regelfolge für ein empfangenes TCP-Datagramm für ssh

Diesmal paßt das Datagramm auf die zweite Regel der input-Kette, die als Aktion (oder Ziel) unsere Kette tcpin enthält. Die Angabe einer benutzerdefinierten Kette als Ziel bewirkt, daß das Datagramm gegen die Regeln in dieser Kette getestet wird. Die nächste zu testende Regel ist somit die erste Regel der tcpin-Kette. Sie testet alle Datagramme, deren Quelladressen außerhalb unseres lokalen Netzwerks liegen und enthält keine Aktion; sie ist somit auch eine Accounting-Regel und die Prüfung wird mit der folgenden Regel fortgesetzt. Die zweite Regel in unserer tcpin-Kette trifft zu und gibt ACCEPT als Zielanweisung vor. Wir haben somit unser Ziel erreicht, es sind keine weiteren Firewall-Maßnahmen notwendig. Das Datagramm wird akzeptiert.

Zum Schluß werfen wir noch einen Blick darauf, was passiert, wenn wir das Ende einer benutzerdefinierten Kette erreichen. Dazu stellen wir den Regel-Ablauf für ein TCP-Datagramm dar, das an einen Port gerichtet ist, der nicht von unseren Regeln abgedeckt wird (siehe dazu Abbildung 9.7).

Abbildung 9.7: Die Regelfolge für ein empfangenes TCP-Datagramm für telnet

Benutzerdefinierte Ketten haben keine voreingestellten Standardaktionen. Wenn alle Regeln in einer benutzerdefinierten Kette durchgetestet sind und keine passende Regel gefunden wurde, agiert der Firewall-Code so, als ob eine zusätzliche RETURN-Regel vorhanden wäre. Ist das aber nicht in Ihrem Sinne, sollten Sie unbedingt noch eine Regel an das Ende Ihrer benutzerdefinierten Kette anhängen, die die von Ihnen gewünschte Standardaktion durchführt. In unserem Beispiel kehrt der ganze Testvorgang wieder zu der Regel im input-Regelsatz zurück, die unmittelbar auf die Regel folgt, die uns zu unserer benutzerdefinierten Kette verzweigt hatte. Unter Umständen erreichen wir dabei das Ende der input-Kette. Diese Kette enthält eine Standardaktion und unser Datagramm wird verworfen.

Dieses Beispiel ist sehr einfach gehalten, aber veranschaulicht, worauf wir hinauswollen. Eine praktikablere Anwendung von IP-Chains wäre wesentlich komplexer. Für ein etwas anspruchsvolleres Beispiel siehe die folgenden Anweisungen:

# # Standardaktion der Weiterleitungskette auf REJECT stellen ipchains -P forward REJECT # # benutzerdefinierte Ketten erzeugen ipchains -N sshin ipchains -N sshout ipchains -N wwwin ipchains -N wwwout # # Verbindungen ablehnen, die aus falscher Richtung kommen ipchains -A wwwin -p tcp -s 172.16.0.0/16 -y -j REJECT ipchains -A wwwout -p tcp -d 172.16.0.0/16 -y -j REJECT ipchains -A sshin -p tcp -s 172.16.0.0/16 -y -j REJECT ipchains -A sshout -p tcp -d 172.16.0.0/16 -y -j REJECT # # alles abweisen, was durch das Sieb der benutzerdefinierten Ketten fällt ipchains -A sshin -j REJECT ipchains -A sshout -j REJECT ipchains -A wwwin -j REJECT ipchains -A wwwout -j REJECT # # www- und ssh-Dienste an die zuständigen benutzerdefinierten Ketten umleiten ipchains -A forward -p tcp -d 172.16.0.0/16 ssh -b -j sshin ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 ssh -b -j sshout ipchains -A forward -p tcp -d 172.16.0.0/16 www -b -j wwwin ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 www -b -j wwwout # # Regeln für Hosts an Position zwei in unseren benutzerdefinierten Ketten einfügen ipchains -I wwwin 2 -d 172.16.1.2 -b -j ACCEPT ipchains -I wwwout 2 -s 172.16.1.0/24 -b -j ACCEPT ipchains -I sshin 2 -d 172.16.1.4 -b -j ACCEPT ipchains -I sshout 2 -s 172.16.1.4 -b -j ACCEPT ipchains -I sshout 2 -s 172.16.1.6 -b -j ACCEPT #

In diesem Beispiel verwendeten wir eine Auswahl benutzerdefinierter Ketten, die — verglichen mit Lösungen, die nur auf den fest installierten Ketten basieren — sowohl die Verwaltung unserer Firewall-Konfiguration vereinfachen als auch die Effizienz unserer Firewall erhöhen.

In unserem Beispiel werden benutzerdefinierte Ketten für die ssh- und www-Dienste für beide Verbindungsrichtungen erzeugt. In die wwwout-Kette tragen wir Regeln für die Hosts ein, die WWW-Verbindungen nach draußen aufbauen dürfen. In sshin definieren wir Regeln für Hosts, denen wir hereinkommende ssh-Verbindungen gestatten wollen. Wir haben angenommen, daß es einen Bedarf danach gibt, einzelnen Hosts in unserem Netzwerk ssh- und www-Verbindungen zu gewähren oder zu verbieten. Das vereinfacht die Sache, denn die benutzerdefinierten Ketten haben die Möglichkeit, Regeln für ein- und ausgehenden Datenverkehr der Hosts jeweils in Gruppen zusammenzufassen, anstatt sie alle zu vermischen. Die Effizienz erhöht sich, weil sich die durchschnittliche Anzahl der notwendigen Tests für die einzelnen Datagramme reduzieren, bis eine Zielaktion gefunden wird. Das macht sich um so mehr bemerkbar, je mehr Hosts wir hinzufügen. Hätten wir keine benutzerdefinierten Ketten zur Verfügung, müßten wir unter Umständen für jedes Datagramm jeweils den gesamten Regelsatz durchkämmen, um letzlich zu entscheiden, welche Aktion ausgeführt werden soll. Selbst wenn wir annehmen, daß jede Regel in unserer Liste gleichen Anteil an der Verarbeitung aller Datagramme hätte, müßte im Durchschnitt dennoch immer den halben Regelsatz durchforstet werden. Mit benutzerdefinierten Ketten ersparen wir uns eine Menge Regeltests, wenn das getestete Datagramm die einfache Regel der built-in Kette, die zu ihnen verzweigt, schlicht und einfach nicht erfüllt.

Die ipchains-Support-Skripten

Die ipchains-Software wird mit drei Support-Skripten ausgeliefert. Das erste davon haben wir bereits kurz beschrieben. Die verbleibenden zwei bieten eine einfache und komfortable Möglichkeit zur Sicherung und Wiederherstellung von Firewall-Konfigurationen.

Das ipfwadm-wrapper-Skript bildet die Kommandozeilensyntax des ipfwadm-Befehls nach, benutzt dafür aber ipchains, um die Firewall-Regeln zu erzeugen. Das ist eine bequeme Methode, Ihre existierende Firewall-Konfiguration an Ihren neuen Kernel anzupassen oder eine Alternative zum lästigen Erlernen der ipchains-Syntax. Das Verhalten des ipfwadm-wrapper-Skripts unterscheidet sich vom ipfwadm-Befehl allerdings in zwei Punkten. Da zum einen ipchains die Spezifikation von Schnittstellen mittels IP-Adressen nicht unterstützt, akzeptiert ipfwadm-wrapper zwar das Argument -V, versucht aber, es in das ipchains-Äquivalent eines -W-Arguments zu konvertieren, indem es nach dem Namen der Schnittstelle sucht, die mit der angegebenen IP-Adresse konfiguriert wurde. Um Sie daran zu erinnern, gibt ipfwadm-wrapper immer eine Warnung aus, wenn Sie die Option -V benutzen. Zum anderen werden Accounting-Regeln für IP-Fragmente nicht korrekt übersetzt.

Die Skripten ipchains-save und ipchains-restore vereinfachen die Erstellung und Änderung einer Firewall-Konfiguration erheblich. Der Befehl ipchains-save liest die aktuelle Firewall-Konfiguration ein und gibt sie in vereinfachter Form an die Standardausgabe aus. ipchains-restore liest Daten im Ausgabeformat von ipchains-save ein und konfiguriert die IP-Firewall mit diesen Regeln. Wenn Sie es vorziehen, diese Skripten zu benutzen, anstatt Ihre Firewall-Konfiguration immer wieder von Hand zu ändern und zu testen, haben Sie den Vorteil, daß Sie eine einmal erstellte Konfiguration abspeichern und nach Belieben wiederherstellen, ändern und wieder abspeichern können.

Zur Anwendung dieser Skripten: Um Ihre aktuelle Firewall-Konfiguration zu speichern, geben Sie etwa folgendes ein:

ipchains-save >/var/state/ipchains/firewall.state

ipchains-restore </var/state/ipchains/firewall.state

Beim Einlesen prüft das ipchains-restore-Skript nach, ob irgendeine benutzerdefinierte Kette bereits existiert. Wenn Sie das Argument -f angegeben haben, werden die vorhandenen benutzerdefinierten Ketten automatisch verworfen, bevor die in der Eingabe enthaltenen Ketten konfiguriert werden. Wenn nicht, fragt das Skript nach, ob die betroffenen Ketten übersprungen oder verworfen werden sollen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center