IPv6/Paketfilter/Host

7.2 Host-Paketfilter

Nach der Theorie zu Netfilter werden wir uns nun wieder der Praxis widmen.

Mit dem Kommando ip6tables können wir, wir erinnern uns, die Netfilter-Regeln verändern.

Genau das werden wir jetzt auf lynx ausprobieren.

Wir schreiben uns einen Paketfilter für lynx.
Nicht nur um uns mit den Parametern von ip6tables vertraut zu machen, sondern auch um lynx zu schützen.
Dabei sind im Workshop mehrere Varianten des gleichen Kommandos angegeben, eine Lang- und eine Kurzform.
Es reicht natürlich, nur eine der beiden Varianten einzugeben.
Die Kürzere ist schneller getippt, die Längere hilft gerade Anfängern zu verstehen, welche Bedeutung die Parameter haben.

Der erste Schritt beim Erstellen eines neuen Paketfilters ist das Beseitigen von Altlasten.

Alle Regeln der Netfilter-Chains müssen gelöscht werden, damit sie nicht mit den neuen Regeln in Konflikt treten.
Im Netfilter-Jargon spricht man vom sogenannten flushen der Chains.
Für jede der relevanten Tabellen muss ein eigener Flush durchgeführt werden.

Die Kommandos lauten: ip6tables benutzen Regeln in Netfilter-Chains löschen

root@lynx :~# ip6tables -- flush -- table filter
root@lynx :~# ip6tables -- flush -- table mangle

Alternative Kurzformen

root@lynx :~# ip6tables -F
root@lynx :~# ip6tables -F -t mangle Alle nutzerdefinierten Chains löschen Sowohl in der Lang- als auch in der Kurzform können wir uns die Angabe der Tabelle filter sparen.

Bei fehlender Angabe geht ip6tables immer davon aus, dass wir die Tabelle filter meinen.

Wir haben die Tabellen erfolgreich von allen Regeln befreit. Was jetzt noch fehlt, ist das Löschen von nutzerdefinierten Chains, die vielleicht noch in den Netfilter-Chains der Tabellen eingehängt sind.

Die Kommandos lauten:

root@lynx :~# ip6tables -- delete - chain -- table filter
root@lynx :~# ip6tables -- delete - chain -- table mangle Alternative Kurzformen:
root@lynx :~# ip6tables -X
root@lynx :~# ip6tables -X -t mangle Regeln auflisten Vom Erfolg unserer Löschaktionen können wir uns überzeugen, indem wir ip6tables mit dem Parameter zur Auflistung der Regeln aufrufen.

Es sollten keine Regeln angezeigt werden.
Das Kommando lautet:

root@lynx :~# ip6tables -- list
Chain INPUT ( policy ACCEPT )
target
 prot opt source
Chain FORWARD ( policy ACCEPT )
target
 prot opt source
Chain OUTPUT ( policy ACCEPT )
target
 prot opt source
destination
destination
destination Alternative Kurzform:
root@lynx :~# ip6tables -L

Wir sehen die Chains INPUT, FORWARD und OUTPUT ohne Regeln.

Die Spalten target, prot (Protokoll), opt (Optionen), source und destination sind jeweils leer.

Eine Sache jedoch fällt auf: Die Default Policies sind alle auf das Target ACCEPT eingestellt.

Damit würde der Paketfilter alle Pakete, die nicht von einer Regel betroffen sind, akzeptieren.

Das Verfahren wird auch Blacklisting genannt, da man explizite Regeln für unerwünschte Pakete definieren muss.

Für die Chains INPUT und FORWARD werden wir aber Whitelisting verwenden.
Das heißt, eingehende Pakete müssen von einer unserer Regeln erfasst und für unschädlich befunden werden.

Andernfalls sollen sie verworfen werden.

Die Default Policies der betroffen Chains werden wir jetzt auf das Target DROP einstellen.

Die Kommandos lauten:

root@lynx :~# ip6tables -- policy INPUT DROP
root@lynx :~# ip6tables -- policy FORWARD DROP
Defaultsetzen
Policy Alternative Kurzformen:
root@lynx :~# ip6tables -P INPUT DROP
root@lynx :~# ip6tables -P FORWARD DROP Wir listen die Regeln wieder auf, um uns vom Erfolg der Maßnahme zu überzeugen:
root@lynx :~# ip6tables -- list
Chain INPUT ( policy DROP )
target
 prot opt source
Chain FORWARD ( policy DROP )
target
 prot opt source
destination
destination Wenn man einen Paketfilter, so wie wir, Schritt für Schritt aufbaut, dann möchte man die Regeln nach und nach hinten anfügen.

Bei ip6tables wird dann von append gesprochen.
Eine Regel für ein Paket soll nicht nur das Paket erfassen, sondern auch eine Entscheidung über sein weiteres Schicksal treffen.

Diese Entscheidung wird mit einem Sprung zu einem Target realisiert.

Da wir auf lynx keine Pakete weiterleiten werden, es handelt sich schließlich nicht um einen Router, fügen wir eine Regel hinzufügen, Sprünge definieren

Regeln184 löschen Regeln an die FORWARD-Chain an, die alle Pakete verwirft. Das Verwerfen geschieht durch einen Sprung in das DROPTarget. Das Kommando lautet:

root@lynx :~# ip6tables -- append FORWARD -- jump DROP Alternative Kurzform:
root@lynx :~# ip6tables -A FORWARD -j DROP Ein kurzer Blick auf die FORWARD-Chain zeigt, dass die Regel wie erwartet angefügt wurde:
root@lynx :~# ip6tables -- list FORWARD Chain FORWARD ( policy DROP )
target
 prot opt source
 destination
DROP
 all
 anywhere
 anywhere Übrigens, diese Regel wäre natürlich nicht nötig gewesen, denn die Default Policy der FORWARD-Chain hätte schon für einen Sprung ins DROP-Target gesorgt.

Wir haben diese Regel nur zu Übungszwecken eingefügt.

Belasten wir Netfilter lieber nicht mit unnötigen Regeln, und löschen die eben angefügte Regel aus der FORWARD-Chain wieder.

Das Löschen von Regeln verläuft ähnlich dem hinzufügen.
Die Regel wird mit allen ihren Parametern übergeben, auch mit dem ursprünglichen Sprungparameter.
Entscheidend ist der Aufruf des Parameters delete anstatt append.

Das Kommando lautet:

root@lynx :~# ip6tables -- delete FORWARD -- jump DROP Alternative Kurzform:
root@lynx :~# ip6tables -D FORWARD -j DROP Ein erneuter Blick auf die FORWARD-Chain zeigt, dass die Regel entfernt wurde:

root@lynx :~# ip6tables -- list FORWARD Chain FORWARD ( policy DROP )

target

prot opt source destination Im Moment erlauben wir keine eingehenden Pakete, auch nicht jene vom Loopback Interface.

Ein kleiner Test zeigt diesen offensichtlichen Missstand auf:

Parameter Interface

user@lynx :~ $ ping6 -c 3 ::1
PING ::1 (::1) 56 data bytes
--- ::1 ping statistics -- 3 packets transmitted ,
 received , 1
 % packet loss ,  time 2 8 ms

Datenverkehr auf dem Loopback Interface verlässt den Node per Definition nie.

Es gibt eigentlich keine Gründe, wieso wir ihn verbieten sollten.
Daher erlauben wir alle Pakete, sofern sie über das Loopback-Interface hinein oder hinaus wollen.
Die Parameter unterscheiden sich je nach betroffener Chain, in der INPUT-Chain benutzen wir den Parameter für das Eingangs-Interface, in der OUTPUT-Chain den für das Ausgangs-Interface.
In der FORWARD-Chain könnten wir, wenn wir wollten, sogar beide Parameter gleichzeitig benutzen.

Die Kommandos lauten:

root@lynx :~# ip6tables -- append INPUT --in - interface lo ' -- jump ACCEPT
root@lynx :~# ip6tables -- append OUTPUT --out - interface ' lo -- jump ACCEPT Alternative Kurzformen:
root@lynx :~# ip6tables -A INPUT -i lo -j ACCEPT
root@lynx :~# ip6tables -A OUTPUT -o lo -j ACCEPT Jetzt klappt es auch mit dem Echo Request an die Loopback Address:
user@lynx :~ $ ping6 -c 3 ::1
PING ::1 (::1) 56 data bytes
64 bytes from ::1: icmp_seq =1 ttl =64 time = .123 ms

3 packets transmitted , 3 received , % packet loss , time  2 ms

Nutzerdefinierte Chain erstellen

Wenn man es ganz genau nimmt, war der Eintrag in der OUTPUT-Chain nicht notwendig, denn diese springt per Default Policy in das Target ACCEPT.

Um uns die Möglichkeit offen zu halten, die Default Policy der OUTPUT-Chain noch zu ändern, tragen wir diese Regel dennoch ein.
Die Regeln sind so allgemein gehalten, dass sie Netfilter nicht wahrnehmbar belasten.

Ein sehr mächtiges Werkzeug von Netfilter sind die nutzerdefinierten Chains.

Zu Übungszwecken werden wir gleich zwei von ihnen erstellen.

Die Kommandos lauten:

root@lynx :~# ip6tables --new - chain allwatchedover
root@lynx :~# ip6tables --new - chain lovinggrace Nutzerdefinierte Chain löschen Nutzerdefinierte Chain umbenennen Alternative Kurzformen:
root@lynx :~# ip6tables -N allwatchedover
root@lynx :~# ip6tables -N lovinggrace Für liebevolle Gunst ist in der objektiven Welt eines Paketfilters kein Platz, die Chain lovinggrace soll daher wieder gelöscht werden.

Das Kommando lautet:

root@lynx :~# ip6tables -- delete - chain lovinggrace Alternative Kurzform:
root@lynx :~# ip6tables -X lovinggrace Auch der Name der Chain allwatchedover ist nicht perfekt.

Denn sie soll später dazu dienen, Pakete die in Ungnade gefallen sind, vor dem Verwerfen noch im Systemlog zu notieren. Passender wäre wohl ein Name wie trashlog, daher benennen wir die Chain um. Das Kommando lautet:

root@lynx :~# ip6tables -- rename - chain allwatchedover trashlog

Alternative Kurzform:

root@lynx :~# ip6tables -E allwatchedover trashlog Die trashlog-Chain wird allerlei unerwünschten Paketen als Target dienen.

Ihre wichtigste Aufgabe ist daher das Verwerfen der Pakete.
Mit einer Default Policy lässt sich diese Aufgabe nicht erledigen, da nutzerdefinierte Chains keine Default Policies besitzen dürfen.
Es bleibt also nur der Sprung zum DROP-Target aus der Chain selbst heraus.
Gerade wenn ein Paketfilter noch nicht ausgereift ist, kann es sehr hilfreich sein, mitzuschreiben welche Pakete als unerwünscht erkannt wurden.
Häufig übersieht man eine Kleinigkeit und verwirft fälschlicherweise legitime Pakete.
Vor dem endgültigen Verwerfen werden wir die Pakete daher, versehen mit einem Hinweis auf die trashlog-Chain, in das Systemlog schreiben lassen.
Weil Netfilter Meldungen im Systemlog standardmäßig mit dem Loglevel warning versieht, müssen wir auch hier eine Anpassung vornehmen.
Warnungen sind für wichtigere Dinge reserviert, es reicht wenn wir von unerwünschten Paketen Notiz nehmen.

Nutzerdefinierte Chain füllen Die Kommandos lauten:

root@lynx :~# ip6tables -- append trashlog -- jump LOG --log - level notice --log - prefix " TRASHLOG : "
root@lynx :~# ip6tables -- append trashlog -- jump DROP Alternative Kurzformen:
root@lynx :~# ip6tables -A trashlog -j LOG --log - level notice --log - prefix " TRASHLOG : "
root@lynx :~# ip6tables -A trashlog -j DROP Übrigens, mit log-level und log-prefix sind uns soeben die ersten Parameter begegnet, von denen es keine Kurzform gibt.

Unsere nutzerdefinierte Chain lassen wir uns wieder von ip6tables anzeigen:

root@lynx :~# ip6tables -- list trashlog
Chain trashlog ( references )
target
 prot opt source
 destination
LOG
 all
 anywhere
 anywhere  LOG level notice prefix ’ TRASHLOG : ’
DROP
 all
 anywhere
 anywhere
Connection
Tracking Der Auflistung können wir gleich mehrere Informationen entnehmen.

Zum einen sehen wir, das die Chain noch nicht von einer Regel als Target genutzt wird (0 references).
Zum anderen sehen wir hier auch, mit welchem Loglevel die Meldungen in das Systemlog geschrieben werden, nämlich notice.
Dem aufmerksamen Betrachter wird auch nicht entgangen sein, dass für diese Chain keine Default Policy angezeigt wird.
Denn nutzerdefinierte Chains dürfen bekanntlich keine Default Policy besitzen.

Das Connection Tracking wird als Erweiterung, als sogenannte Match Extension, nachgeladen.

Wenn eine Erweiterung geladen wird, sind zusätzliche Parameter nutzbar, die von der Erweiterung eingebracht werden.
Wir werden die Erweiterung Connection Tracking häufig benutzen.
Zunächst sollen alle eingehenden Pakete, die vom Connection Tracking als ungültig erkannt wurden, in die nutzerdefinierte Chain trashlog springen.

Dort werden sie im Systemlog vermerkt und dann verworfen. Das Kommando lautet:

root@lynx :~# ip6tables -- append INPUT -- match conntrack -- ctstate INVALID -- jump trashlog Alternative Kurzform:
root@lynx :~# ip6tables -A INPUT -m conntrack -- ctstate INVALID -j trashlog Bestehende Verbindungen und ihre verwandten Pakete sollen den Paketfilter ungehindert passieren können.

Daher erlauben wir alle eingehenden Pakete die das Connection Tracking einer bestehenden Verbindung zuordnen konnte.

Das Kommando lautet:

root@lynx :~# ip6tables -- append INPUT -- match conntrack -- ctstate ESTABLISHED , RELATED -- jump ACCEPT

Alternative Kurzform:

root@lynx :~# ip6tables -A INPUT -m conntrack -- ctstate ' ESTABLISHED , RELATED -j ACCEPT Mit dem Parameter protocol, in der Kurzform schlicht p, lässt sich das Protokoll definieren, auf das eine Regel zutreffen muss.

Das Protokoll kann als Protokollnummer, so wie sie im IPv6-Header auftaucht, angegeben werden.
Alternativ kann auch die ausgeschriebene Variante genutzt werden.
Die gängigsten Protokolle im Überblick:

tcp
Transmission Control Protocol
udp
User Datagram Protocol
ipv6
IPv6-in-IPv6
icmpv6
Internet Control Message Protocol v6

Wenn in einer Regel das Protokoll spezifiziert wird, dann werden weitere Parameter nutzbar.

Bei ICMPv6 wird unter anderem der Parameter icmpv6-type nutzbar.
Ihm kann die Typnummer einer ICMPv6 Message als Zahl oder ausgeschriebene Variante übergeben werden.
Die ausgeschriebenen Typen, manche von ihnen sogar mit alternativer Schreibweise, sind:

• destination-unreachable • no-route • communication-prohibited • address-unreachable • port-unreachable • packet-too-big • time-exceeded, ttl-exceeded • ttl-zero-during-transit • ttl-zero-during-reassembly • parameter-problem • bad-header • unknown-header-type Parameter Protokoll • unknown-option • echo-request, ping • echo-reply, pong • router-solicitation • router-advertisement • neighbour-solicitation, neighbor-solicitation • neighbour-advertisement, neighbor-advertisement • redirect NDP und SLAAC erlauben

Wie Sie sicher schon bemerkt haben, hat der NetworkManager auf lynx inzwischen seine Konnektivität verloren.

Das liegt unter anderem daran, dass ICMPv6 Messages vom Paketfilter noch nicht akzeptiert werden.
Wie wir wissen, organisiert sich der Link aber ausschließlich über ICMPv6 Messages.

Wir sollten diese also zügig wieder zulassen, um die Konnektivität zurückzugewinnen.

Eine Einschränkung werden wir dennoch vornehmen, wir erlauben nur ICMPv6 Messages, die sowohl vom Hop Limit als auch vom Typ her in die typische Kommunikation des Neighbor Discovery Protocols hineinpassen.

Dazu erstellen wir uns eine nutzerdefinierte Chain namens ndp-slaac, füllen diese mit Regeln, und hängen sie abschließend für alle ICMPv6-Pakete in die INPUT-Chain ein:

root@lynx :~# ip6tables --new - chain ndp - slaac

Eine zusätzliche Erweiterung, sie heißt hl, ist für die Analyse des Hop Limits zuständig.

Wir laden sie wie gewohnt mit match nach.

In den ersten Regeln der Chain ndp-slaac erlauben wir NDP:

root@lynx :~# ip6tables -- append ndp - slaac -- protocol  icmpv6 -- icmpv6 - type router - solicitation -- match hl --hl - eq 255 -- jump ACCEPT
root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type router - advertisement -- match hl --hl - eq 255 -- jump ACCEPT
root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type neighbor - solicitation -- match hl --hl - eq 255 -- jump ACCEPT
root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type neighbor - advertisement -- match hl --hl - eq 255 -- jump ACCEPT Auch Umleitungen werden wir akzeptieren:
root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type redirect -- match hl --hl - eq 255 -- jump ACCEPT Und natürlich MLDv1 und MLDv2, um die Selbstorganisation des Links nicht zu gefährden:

Typ 13 : Multicast Listener Query ( MLDv1 , MLDv2 )

root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type 13 -- match hl --hl - eq 1 -- jump ACCEPT

Typ 131: Multicast Listener Report ( MLDv1 )

root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type 131 -- match hl --hl - eq 1 -- jump ACCEPT

Typ 132: Multicast Listener Done ( MLDv1 )

root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type 132 -- match hl --hl - eq 1 -- jump ACCEPT

Typ 143: Multicast Listener Report ( MLDv2 )

root@lynx :~# ip6tables -- append ndp - slaac -- protocol icmpv6 -- icmpv6 - type 143 -- match hl --hl - eq 1 -- jump ACCEPT Zuletzt wird die nutzerdefinierte Chain noch in die INPUTChain eingehängt:
root@lynx :~# ip6tables -- append INPUT -- protocol icmpv6 -- jump ndp - slaac Nun sollte der NetworkManager wieder in der Lage sein, Konnektivität herzustellen.

Aus Platzgründen wird hier auf eine Angabe der alternativen Kurzform verzichtet.

Parameter Quelle und Ziel Die wohl wichtigsten Parameter eines jeden Paketfilters sind Quell- und Zieladressen von Paketen.

Dabei ist die Angabe von einzelnen Adressen, von Listen (mit Kommata getrennte Adressen) oder Präfixen möglich.
Die Leistungsfähigkeit des Paketfilters hängt stark davon ab, wie gut die Adressen aggregiert sind.
Das heißt, immer wenn es möglich ist, mehrere Adressen als Präfix auszudrücken, sollte dies geschehen.

Um die Fehlersuche am internen Link zu erleichtern, erlauben wir Echo Request aus dem Präfix für Link-local Addresses. Das Kommando lautet:

root@lynx :~# ip6tables -- append INPUT -- source fe8 ::/1 -- destination fe8 ::/1 -- protocol icmpv6 -- icmpv6 - type echo - request -- match conntrack -- ctstate NEW -- jump ACCEPT Alternative Kurzform:
root@lynx :~# ip6tables -A INPUT -s fe8 ::/1 -d fe8 ::/1 -p icmpv6 -- icmpv6 - type echo - request -m conntrack -- ctstate NEW -j ACCEPT

Parameter Port

Wenn wir die Regeln auf ein Upper Layer Protocol anwenden, können wir auch auf die diversen Parameter des jeweiligen Protokolls zugreifen.

Beispielhaft sei hier der Parameter zum Filtern von Portnummern erwähnt.
Auch hier sind wieder mehrere Angaben möglich.
Neben alleinstehenden Portnummern sind auch durch Kommata getrennte Listen, aber auch ganze Portbereiche gültige Werte.
Portbereiche werden in der Form Erster-Port:Letzter-Port angegeben.
Ausgeschriebene Varianten existieren ebenfalls, die komplette Liste befindet sich in der Datei /etc/services und wird hier aus Platzgründen ausgespart.
Wir nutzen den Parameter Port, um auf lynx den Fernwartungsdienst Secure Shell (SSH) für den internen Link freizugeben.

Das Kommando lautet:

root@lynx :~# ip6tables -- append INPUT -- source fe8 ::/1 -- protocol tcp -- destination - port 22 -- match conntrack -- ctstate NEW -- jump ACCEPT

Alternative Kurzform:

root@lynx :~# ip6tables -A INPUT -s fe8 ::/1 -p tcp -- dport 22 -m conntrack -- ctstate NEW -j ACCEPT Die ausgehenden Verbindungen von lynx werden vom Connection Tracking erfasst.

Alle eingehenden Pakete, die zu diesen Verbindungen gehören, werden über die Zustände ESTABLISHED und RELATED ins System hineingelassen.
Deshalb sind, sofern man bei dieser großzügigen Konfiguration für ausgehende Verbindungen bleiben möchte, keine weiteren Regeln für die OUTPUT-Chain nötig.

Wir haben jetzt einen funktionierenden Paketfilter auf lynx, der leider nicht von Dauer ist.

Denn die Netfilter-Regeln überleben einen Neustart nicht.
Das Kommando ip6tables-save kann uns aber weiterhelfen.
Es liest alle Regeln aus und gibt sie in einem Format wieder, das für ip6tables lesbar ist:

root@lynx :~# ip6tables - save Q -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack -- ctstate INVALID -j trashlog -A INPUT -m conntrack -- ctstate RELATED , ESTABLISHED -j ACCEPT -A INPUT -p ipv6 - icmp -j ndp - slaac Q
COMMIT Wir leiten die Ausgabe von ip6tables-save in eine Datei um:
root@lynx :~# ip6tables - save > / etc / packetfilter Ausgehende Verbindungen Regeln sichern So stehen uns die Regeln auch nach einem Neustart noch zur Verfügung, wir müssen sie dann nur noch in den Kernel laden.

Die Datei /etc/packetfilter von lynx ist in Anhang C Paketfilter von lynx zu sehen.

Regeln richtig

Es gibt zwei Möglichkeiten, Netfilter nach dem Systemstart laden
wieder mit den vorher definierten Regeln zu versorgen.

Die beliebteste scheint zu sein, die mit ip6tables beginnenden Kommandos in ein Shell-Skript zu schreiben, und dieses auszuführen.
Davon soll an dieser Stelle dringend abgeraten werden! Uns ist aus dem Abschnitt 7.1 Einführung in Netfilter bekannt, dass bei jedem Aufruf von ip6tables der gesamte Regelsatz aus dem Kernel heruntergeladen wird.
Dann wird der Regelsatz modifiziert, zum Beispiel durch anfügen einer Regel.
Der geänderte Regelsatz wird dann wieder in den Kernel geladen.
Auch wenn der Vorgang blitzartig vonstatten zu gehen scheint, so stellt er doch eine unnötige Belastung für das System dar.
Ein weiterer, viel wichtigerer, Grund gegen das eben beschriebene Vorgehen ist im Herzen des Betriebssystems zu finden: Dem Scheduler.
Der Scheduler legt fest, wann ein Prozess Rechenzeit bekommt, und wann ihm zugunsten eines anderen Prozesses Rechenzeit entzogen wird.

Jeder Aufruf von ip6tables ist ein eigener Prozess.

Das bedeutet, dass es vorkommen kann, dass der Scheduler einem der vielen ip6tables-Prozesse zu irgendeinem Zeitpunkt Rechenzeit entzieht.
Andere Prozesse belegen dann den Prozessor bis ip6tables diesen dann wieder in Beschlag nehmen darf.
Während ip6tables pausiert, haben wir einen unfertigen Paketfilter im Kernel, denn es stehen unter Umständen noch Regeln zum Laden aus.
Dass ein halbfertiger Paketfilter, auch wenn er nur wenige Millisekunden existiert, keine gute Idee ist, leuchtet ein.

Regeln wiederherstellen Das Kommando ip6tables-restore bietet für das Problem eine Lösung an.

Es lädt den gesamten Regelsatz auf einmal in den Kernel, und lässt sich dabei auch nicht unterbrechen.

Wir laden unseren Packetfilter testweise erneut in den Kernel:

root@lynx :~# ip6tables - restore < / etc / packetfilter

Beachten Sie bitte die Richtung in welche die spitze Klammer zeigt.

Eine falsch gesetze Klammer wird zu Datenverlust in der Datei /etc/packetfilter führen.

Datei: /etc/rc.local

#!/ bin / sh -e
#
# By default this script does nothing .
ip6tables - restore < / etc / packetfilter
exit

Abbildung 7.5 Skript rc.local

Auf lynx machen wir es uns einfach, indem wir die Wiederherstellung nach dem Systemstart automatisch ausführen.

Dazu verändern wir die Datei /etc/rc.local wie in Abbildung 7.5

gezeigt. Als Faustregel gilt: Den Paketfilter mit ip6tables erstellen und modifizieren, anschließend mit ip6tables-save abspeichern. Den Paketfilter im produktiven Betrieb immer mit ip6tablesrestore in den Kernel laden. Wir haben soeben ip6tables im Schnellverfahren kennengelernt.

Die vorgestellten Parameter sind nur ein kleiner Teil des riesigen Funktionsumfangs von ip6tables und dem NetfilterFramework.
Bitte nehmen Sie sich etwas Zeit, um im Umgang mit den vorgestellten Werkzeugen Handlungssicherheit zu erlangen.
Spätestens wenn wir den komplexeren Paketfilter für fuzzball schreiben, wird dies hilfreich sein.
Wie so oft hilft ein Studium der Hilfeseiten, abrufbar mit man ip6tables, weiter.

Wiederherstellung nach Systemstart Faustregel Weiterführendes Studium