IPv6/Paketfilter/Router

7.3 Router-Paketfilter

Das Filtern von Paketen auf einem Router stellt eine besondere Herausforderung dar.

Auf der einen Seite sollen sich Router, die zwischen zwei kommunizierenden Hosts sitzen, nicht unnötig in die Kommunikation einmischen oder diese gar beeinträchtigen.
Auf der anderen Seite möchte man als Betreiber eines Routers nach Möglichkeit keine unerwünschten oder schädlichen Pakete verarbeiten.
Darüber hinaus kann ein Router oft nur Vermutungen darüber anstellen, ob ein Paket erwünscht, unerwünscht oder gar schädlich ist.
Manchmal lässt Anforderungen

Zonen Zonen und Interfaces sich nicht einmal feststellen, ob ein Paket in einem gewissen Kontext überhaupt Sinn ergibt.

Nicht zuletzt deshalb ist es auch umstritten, ob auf einem Router überhaupt Pakete gefiltert werden sollten.
Da fuzzball bei uns nicht nur für das reine Routing zuständig ist, sondern auch einen Resolving DNS Server bereitstellt und als NAT64-Gateway fungiert, gibt es guten Grund, einen Paketfilter zu installieren.
Der Router ist nämlich zentrale Austauschpunkt für Daten unseres Lern- und Bastelnetzwerkes mit dem IPv6-Internet.
Wir werden als schädlich erkannte Pakete grundsätzlich verwerfen und alle anderen überwiegend auf Plausibilität prüfen.
Glücklicherweise nimmt uns das Connection Tracking den Großteil der Plausibilitätsprüfungen ab.

Beim Schreiben komplexer Paketfilter verliert man leicht den Überblick.

Eine Möglichkeit, dem Vorzubeugen, ist das Arbeiten mit Zonen.
Eine Zone ist dann ein Bereich eines Netzwerkes, für den einheitliche Regeln gelten.
Auch wir werden mit Zonen arbeiten, um eine einfache Abstraktion vom Konkreten zu erreichen.
Dazu definieren wir eine Zone Untrusted, in der sich alle Systeme befinden, die nicht unter unserer Kontrolle stehen.
Unter anderem der Teil des IPv6Internets, der sich nicht in unserem Lern- und Bastelnetzwerk abspielt.
Alles was am Link internal geschieht, halten wir für vertrauenswürdig, diese Zone trägt daher den Namen Trusted.

Zonengrenzen befinden sich immer an Interfaces, und niemals inmitten eines Links.

Zwei oder mehr Zonen können sich daher auch nur innerhalb eines Nodes treffen.
In Abbildung

7.6 sind die Zonen zu sehen, in denen sich fuzzball befindet. Der Weg ins IPv6-Internet führt über das Interface sixxs, es zeigt in die Zone Untrusted.

Daher sind Pakete die über sixxs ins System gelangen besonders streng zu filtern.
Ebenfalls der Zone Untrusted wird das Interface nat64 zugeordnet.
Pakete die über dieses Interface in das System gelangen, stammen aus dem IPv4-Internet, welches ebenfalls nicht unter unserer Kontrolle steht.
Pakete die über eth1 empfangen werden, kom

Untrusted
IPv6
Internet
IPv4
Internet
sixxs
nat64
eth1
 fuzzball
internal
Trusted

Abbildung 7.6 Zonen von fuzzball

men aus der Zone Trusted, denn sie stammen von Systemen die wir unter Kontrolle haben. Die Zonen lassen sich nicht ohne weiteres auf die eingebauten Chains übertragen.

So laufen alle eingehenden Pakete durch die Chain INPUT, unabhängig davon ob sie aus einer Trusted- oder Untrusted-Zone stammen.
In den Regeln muss daher das betroffene Interface berücksichtigt werden.
Darum ist es manchmal sinnvoll, nutzerdefinierte Chains für eine Zone zu erstellen, und diese abhängig vom Interface einzuhängen.

An anderen Stellen wiederum ist es praktischer, für bestimmte Protokolle nutzerdefinierte Chains anzulegen.

Die können dann in allen betroffenen Zonen verwendet werden.
Der Paketfilter von fuzzball wird von beiden Techniken Gebrauch machen.

Zonen und Chains Oft müssen Pakete ihre Zone verlassen um ein Ziel in einer anderen Zone zu erreichen.

Solche Pakete, die von einer Zone in eine andere befördert werden wollen, sollen ebenfalls vom Paketfilter geprüft werden.
Sie passieren die Chain FORWARD.
In dieser Chain treffen mehrere Zonen aufeinander.

Um herauszufinden, von welcher Zone in welche andere Zone ein Paket befördert werden möchte, müssen wir auf die betroffenen Interfaces schauen.

Ein- und ausgehendes Interface sind in den Regeln der FORWARD-Chain wichtige Parameter.

Zonenübertritte Wir beginnen nun mit dem Aufbau des Paketfilters für fuzzball. Der erste Schritt ist das Entfernen aller möglicherweise bestehenden Regeln: Vorhandene Regeln entfernen

root@fuzzball :~#
ip6tables
-- flush
root@fuzzball :~#
ip6tables
-- flush -- table mangle
root@fuzzball :~#
ip6tables
-- delete - chain
root@fuzzball :~#
ip6tables
-- delete - chain -- table mangle Vom Erfolg der Maßnahme werden wir uns überzeugen:
root@fuzzball :~# 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
Default Policies Wir sehen, dass in den Chains INPUT, FORWARD und OUTPUT keine Regeln existieren.

Wir können also nun dem Aufbau des Paketfilters beginnen.

Zuerst legen wir die Default Policies der Chains INPUT und FORWARD fest.
Grundsätzlich sollen Pakete verworfen werden.
Wir betreiben in diesen Chains also Whitelisting:

root@fuzzball :~# ip6tables -- policy INPUT DROP
root@fuzzball :~# ip6tables -- policy FORWARD DROP Auch hier lassen wir uns das Ergebnis der letzten Kommandos anzeigen:
root@fuzzball :~# ip6tables -- list
Chain INPUT ( policy DROP )
target
 prot opt source
Chain FORWARD ( policy DROP )
target
 prot opt source
destination
destination
Loopback
Interface Die Default Policies verweisen jetzt auf das Target DROP für ein kommentarloses Verwerfen von Paketen.

Das wohl einzige Interface auf fuzzball, welches uneingeschränktes Vertrauen genießt, ist das Loopback Interface.

Pakete von und zum Loopback Interface dürfen den Paketfilter ungehindert passieren:

root@fuzzball :~# ip6tables -- append INPUT --in - interface lo -- jump ACCEPT
root@fuzzball :~# ip6tables -- append OUTPUT --out - interface lo -- jump ACCEPT Für Pakete die verworfen werden sollen, aber dennoch von Interesse sein könnten, erstellen wir eine nutzerdefinierte Chain.

Sie dient anderen Regeln als Target.

Die Chain schreibt Pakete mit dem Level Notice ins Systemlog, anschließend verwirft sie die Pakete:

Chain für verworfene Pakete

root@fuzzball :~# ip6tables -- new - chain trashlog
root@fuzzball :~# ip6tables -- append trashlog -- jump LOG --log - level notice --log - prefix " TRASHLOG : "
root@fuzzball :~# ip6tables -- append trashlog -- jump DROP Ein kurzer Blick auf die Chain zeigt, ob sie wie gewünscht angelegt wurde:
root@fuzzball :~# ip6tables -- list trashlog
Chain trashlog ( references )
target
 prot opt source
 destination
LOG
 all
 anywhere
 anywhere LOG level notice prefix ’ TRASHLOG : ’
DROP
 all
 anywhere
 anywhere Pakete bestehender Verbindungen und ihre verwandten Pakete sollen den Paketfilter ungehindert passieren.

Die Plausibilitätsprüfung für diese Pakete hat das Connection Tracking bereits erledigt.
Wir fügen die entsprechende Regel der INPUTChain hinzu:

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

Connection Tracking

nutzen Eingehende ungültige Pakete, egal aus welcher Zone sie stammen, werden wir verwerfen.

Da ungültige Pakete manchmal auf Fehlkonfigurationen hinweisen, lassen wir sie zur Zwecken der Fehlerbehebung ins Systemlog schreiben:

Ungültige Pakete verwerfen

root@fuzzball :~# ip6tables -- append INPUT -- match conntrack -- ctstate INVALID -- jump trashlog Ohne Angabe eines Interfaces, trifft diese Regel auf alle eingehenden Pakete, und damit auch auf alle Zonen, zu.

Extension Header Der Routing Header Typ 0 wurde als gefährlich eingestuft und gilt als veraltet.

Auch andere Extension Header könnten, abhängig von der Reihenfolge ihres Auftretens und ihrer Parameter, in Zukunft unerwünscht sein.
Um den Überblick nicht zu verlieren, erstellen wir eine nutzerdefinierte Chain namens bad-eh, in der alle unerwünschten Extension Header benannt werden.
Der Routing Header Typ 0 wird mit einer passenden Regel verworfen:

root@fuzzball :~# ip6tables -- new - chain bad - eh
root@fuzzball :~# ip6tables -- append bad - eh -- match rt --rt - type -- jump DROP Andere Regeln können bei Bedarf später hinzugefügt werden.

Damit die Regel wirksam wird, hängen wir die eben erstellte Chain in die INPUT-Chain ein:

root@fuzzball :~# ip6tables -- append INPUT -- jump bad - eh

Neighbor Discovery

Sowohl auf den Links der Trusted-Zone, als auch auf den Links der Untrusted-Zone, benötigen wir das Neighbor Discovery Protocol für die Selbstorganisation des Links.

Dazu schreiben wir uns eine nutzerdefinierte Chain ndp-minimal mit den nötigen Regeln für NDP:

root@fuzzball :~# ip6tables -- new - chain ndp - minimal
root@fuzzball :~# ip6tables -- append ndp - minimal -- protocol icmpv6 -- icmpv6 - type neighbor - solicitation -- match hl --hl - eq 255 -- jump ACCEPT
root@fuzzball :~# ip6tables -- append ndp - minimal -- protocol icmpv6 -- icmpv6 - type neighbor - advertisement -- match hl --hl - eq 255 -- jump ACCEPT Auch auf das Umleitungen von Pakete lassen wir uns ein:
root@fuzzball :~# ip6tables -- append ndp - minimal -- protocol icmpv6 -- icmpv6 - type redirect -- match hl --hl - eq 255 -- jump ACCEPT MLDv1 und MLDv2 sind vorgeschrieben und notwendig, darum erlauben wir die beiden Protokolle ebenfalls:

Typ 13 : Multicast Listener Query ( MLDv1 , MLDv2 )

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

Typ 131: Multicast Listener Report ( MLDv1 )

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

Typ 132: Multicast Listener Done ( MLDv1 )

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

Typ 143: Multicast Listener Report ( MLDv2 )

root@fuzzball :~# ip6tables -- append ndp - minimal -- protocol icmpv6 -- icmpv6 - type 143 -- match hl --hl - eq 1 -- jump ACCEPT Danach hängen wir die Chain ndp-minimal in die INPUT-Chain ein, jedoch nur für eintreffende ICMPv6-Pakete:
root@fuzzball :~# ip6tables -- append INPUT -- protocol icmpv6 -- jump ndp - minimal Auch von dieser Regel sind wieder alle Zonen betroffen.

Als nächstes werden wir eingehende Router Solicitations von der Trusted-Zone erlauben, denn für diese ist fuzzball der zuständige Router:

Router Solicitations

root@fuzzball :~# ip6tables -- append INPUT --in - interface eth1 -- protocol icmpv6 -- icmpv6 - type router - solicitation -- match hl --hl - eq 255 -- jump ACCEPT In den Router Advertisements verteilen wir die Adresse des Resolving DNS Servers.

Dessen Dienste sollten wir für die Trusted-Zone ebenfalls freigeben:

ResolvingServer DNS

root@fuzzball :~# ip6tables -- append INPUT --in - interface eth1 -- protocol udp -- destination - port 53 -- match conntrack -- ctstate NEW -- jump ACCEPT
root@fuzzball :~# ip6tables -- append INPUT --in - interface eth1 -- protocol tcp -- destination - port 53 -- match conntrack -- ctstate NEW -- jump ACCEPT Widmen wir uns nun der Chain FORWARD.

Durch sie laufen alle Pakete hindurch, die von einem Interface zu einem anderen müssen.
In unserem Fall bedeutet das auch immer einen Forwarding filtern

Connection Tracking

Zonenwechsel von Trusted zu Untrusted oder umgekehrt.

Wäre fuzzball in weiteren Zonen vertreten, dann würde durch diese Chain auch der Verkehr zwischen den anderen Zonen laufen.

Auch für weitergeleitete Pakete kann Netfilter ein Connection Tracking durchführen.

Das nimmt uns eine Menge Arbeit beim definieren von Regeln ab.
Gleichzeitig erhöht ein frühzeitiges Durchlassen von unschädlichen Paketen die Effizienz der Regelabarbeitung.
Bestehende Verbindungen und allen damit verwandten Paketen erlauben wir deshalb auch in der FORWARD-Chain das Passieren:

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

Extension Header Nutzerdefinierte Chain für ICMPv6

Gefährliche Extension Header werden wir auch beim Forwarding nicht akzeptieren.

Darum hängen wir die nutzerdefinierte Chain bad-eh auch in der FORWARD-Chain ein:

root@fuzzball :~# ip6tables -- append FORWARD -- jump bad - eh Bei den Upper Layer Protocols hat sich im Bereich Forwarding nichts Wesentliches im Vergleich zu IPv4 geändert.

Den Schwerpunkt des Filterns legen wir deshalb auf ICMPv6 fest.

Wir starten mit einer neuen nutzerdefinierten Chain namens icmpv6-filter :

root@fuzzball :~# ip6tables -- new - chain icmpv6 - filter

Link-local Addresses

Link-local Addresses besitzen bekanntlich nur auf ihrem eigenen Link Gültigkeit.

Deshalb dürfen sie niemals weitergeleitet werden.
Pakete die als Quell- oder Zieladresse eine Link-local Addresses enthalten, werden daher verworfen:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source fe8 ::/1 -- jump DROP
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- destination fe8 ::/1 -- jump DROP

Echo Requests sind ein nützliches Werkzeug bei der Fehlersuche, darum werden wir sie nicht grundsätzlich verbieten.

Einige Einschränkungen werden wir aber machen.
Nodes aus der Trusted-Zone sollen Echo Request an jeden versenden dürfen:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type echo - request -- match conntrack -- ctstate NEW -- jump ACCEPT

Echo Requests

Aber nur bestimmte Nodes aus der Trusted-Zone dürfen vom Rest der Welt mit Echo Requests angesprochen werden. Die Liste können Sie beliebig erweitern.

Im Workshop geben wir lynx frei, felis bleibt für Echo Requests unerreichbar.

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- destination 2 a 1 :198:2 :8 a23 :2 : ff : fe6 : d1e -- protocol icmpv6 -- icmpv6 - type echo - request -- match conntrack -- ctstate NEW -- jump ACCEPT Das Präfix und die Adresse in den Parametern von ip6tables müssen Sie natürlich an Ihre eigenen Gegebenheiten anpassen.

Die Antwortpakete (Echo Replies) für die eben erstellten Regeln werden dank Connection Tracking frühzeitig erlaubt.

Andere Echo Replies sind davon allerdings nicht betroffen.
Zum Beispiel Echo Replies die an eine Multicast Address verschickt werden.
So ein Verhalten ist schädlich und kann von Betroffenen sogar als Angriff aufgefasst werden.
Echo Replies auf Multicast Addresses werden wir daher grundsätzlich verwerfen:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- destination ff ::/8 -- protocol icmpv6 -- icmpv6 - type echo - reply -- jump DROP Echo Replies ICMPv6 Error Messages für bestehende Verbindungen werden vom Connection Tracking erkannt und wurden von uns bereits erlaubt.

Darüber hinaus sollen die Nodes in der Trusted-Zone die Möglichkeit erhalten, auch ungefragt Fehlermeldungen zu verschicken.

Error Messages

Wir beginnen mit der wichtigsten Fehlermeldung wenn es um Path MTU Discovery geht, nämlich der Packet Too Big Error Message:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type packet - too - big -- jump ACCEPT Auch das Überschreiten der Zeitgrenze für den Zusammenbau von Fragmenten dürfen Nodes aus der Trusted-Zone anzeigen:
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type ttl - zero - during - reassembly -- jump ACCEPT Probleme beim Auswerten von Headern oder Parametern sollen ebenso den Paketfilter passieren dürfen:
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type bad - header -- jump ACCEPT
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type unknown - header - type -- jump ACCEPT
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type unknown - option -- jump ACCEPT In der Trusted-Zone befinden sich nicht nur Hosts, sondern auch fuzzball als Router ist mit einem Interface in der Zone vertreten.

Daher erlauben wir auch die Fehlermeldungen, die für Router typisch sind, nämlich Destination Unreachable und Hop Limit Exceeded:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type destination - unreachable -- jump ACCEPT
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- source 2 a 1 :198:2 :8 a23 ::/64 -- protocol icmpv6 -- icmpv6 - type ttl - zero - during - transit -- jump ACCEPT

Neighbor Discovery Protocol

Auf keinen Fall dürfen ICMPv6-Nachrichten den Router passieren, die außerhalb des lokalen Links nichts zu suchen haben. Als erstes verwerfen wir NDP:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type neighbor - solicitation -- jump DROP
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type neighbor - advertisement -- jump DROP
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type router - solicitation -- jump DROP
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type router - advertisement -- jump DROP

Auch Umleitungen haben beim Forwarding nichts verloren:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type redirect -- jump DROP

Die Protokolle MLDv1 und MLDv2 sind zwischen den Zonen ebenfalls unerwünscht.

Typ 13 : Multicast Listener Query ( MLDv1 , MLDv2 )

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 13 -- jump DROP

Typ 131: Multicast Listener Report ( MLDv1 )

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 131 -- jump DROP

Typ 132: Multicast Listener Done ( MLDv1 )

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 132 -- jump DROP

Typ 143: Multicast Listener Report ( MLDv2 )

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 143 -- jump DROP

ICMPv6-Nachrichten zur Neunummerierung von Netzwerken sollen auch nicht weitergeleitet werden

Router
Renumbering

Typ 138:

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 147 -- jump DROP Mit den ICMPv6-Nachrichten Node Information Query kann man von einem Node Informationen einholen, zum Beispiel seinen Hostnamen.

Der Node antwortet dann mit einem Node Information Reply, der die gewünschten Informationen enthält.

Das Verfahren ist in RFC 4620 [CH06] spezifiziert und gilt als experimentell.

Solange wir dafür keine Verwendung haben, verwerfen wir die zugehörigen Pakete deshalb:

Node-Informationen

Typ 139: Node Information Query

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 139 -- jump DROP

Typ 14 : Node Information Reply

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 14 -- jump DROP Mobile IPv6

Da wir kein Mobile IPv6 einsetzen, werden wir auch alle entsprechenden IPCMv6-Nachrichten verwerfen:

Typ 144: Home Agent Address Discovery Request

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 144 -- jump DROP

Typ 145: Home Agent Address Discovery Reply

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 145 -- jump DROP

Typ 146 Mobile Prefix Solicitation

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 146 -- jump DROP

Typ 147: Mobile Prefix Advertisement

root@fuzzball :~# ip6tables -- append icmpv6 - filter -- protocol icmpv6 -- icmpv6 - type 147 -- jump DROP Alle weiteren ICMPv6-Pakete verwerfen wir:
root@fuzzball :~# ip6tables -- append icmpv6 - filter -- jumpDROP

Sollte es Probleme beim Forwarding geben, und der Verdacht fällt auf verworfene ICMPv6-Pakete, dann ersetzen wir das Target der zuletzt eingefügten Regeln durch trashlog. Dann werden die Pakete weiterhin verworfen, aber wir können den Vorgang im Systemlog beobachten.

Mit den Erkenntnissen lassen sich dann gegebenenfalls neue Regeln formulieren.

Zum Abschluss hängen wir die nutzerdefinierte Chain icmpv6filter noch in die FORWARD-Chain ein:

root@fuzzball :~# ip6tables -- append FORWARD -- protocol icmpv6 -- jump icmpv6 - filter

Upper Layer Protocols

Das Filtern von Upper Layer Protocols ist ein Thema, welches weder zum Titel des Workshops passt, noch in dessen Rahmen ausreichend behandelt werden könnte.

Die folgenden Regeln erlauben einfach jede neue Verbindung aus der TrustedZone in die Untrusted-Zone:

Datei: /etc/rc.local

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

root@fuzzball :~# ip6tables -- append FORWARD --in - interface eth1 --out - interface sixxs -- match conntrack -- ctstate NEW -- jump ACCEPT
root@fuzzball :~# ip6tables -- append FORWARD --in - interface eth1 --out - interface nat64 -- match conntrack -- ctstate NEW -- jump ACCEPT Betrachten Sie diese beiden Regeln bitte als Notbehelf im Rahmen des Workshops, und nicht als Ersatz für einen durchdachten Paketfilter.

Dort wo dieses Kapitel endet, fängt das klassische Paketfiltern der höheren Protokolle an.

Wie schon bei lynx durchgeführt, werden wir auch für fuzzball die Regeln sichern.

Nicht nur des effizienteren Formates wegen, sondern auch um alle erstellten Regeln im Überblick zu behalten.
Wir leiten die Ausgabe von ip6tables-save wieder in eine Datei um:

Regeln sichern

root@fuzzball :~# ip6tables - save > / etc / packetfilter Die Datei /etc/packetfilter von fuzzball ist in Anhang D Paketfilter von fuzzball zu sehen.

Bei jedem Systemstart werden wir den Paketfilter in den Kernel laden, damit fuzzball sofort und sicher seine Arbeit aufnehmen kann.

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

Viele der vorgestellten Regeln verwerfen ungewollte Pakete kommentarlos.

Im produktiven Betrieb ist es häufig notwendig, einen Kompromiss zwischen dem Mitschreiben von Paketen und der Geschwindigkeit des Paketfilters zu finden.
In unserem Lern- und Bastelnetzwerk sind wir diesen Zwängen nicht ausgesetzt, und könnten theoretisch jedes verworfene

Regeln wiederherstellen Verworfene Pakete mitschreiben

Systemlog auswerten

Paket dokumentieren.

Dazu müssen nur die Targets der entsprechenden Regeln auf die nutzerdefinierte Chain trashlog zeigen.
Im Folgenden Beispiel wurde die Regel für eingehende Echo Requests auf trashlog umgeleitet.
Ein Echo Request von außerhalb wurde daraufhin verworfen, aber vorher im Systemlog hinterlegt.
Einen Blick auf das Systemlog erhalten wir mit dem Kommando dmesg, welches hier ausgeführt wurde:

root@fuzzball :~# dmesg
TRASHLOG : IN = sixxs OUT = eth1 MAC = SRC =2 1: 7 f8 : 33:
:
: a1 5 :7821:
1 DST =2 a 1 : 198: 2 :8 a23 :
:
: bad : affe LEN =1 4 TC = HOPLIMIT =59 FLOWLBL = PROTO = ICMPv6 TYPE =128 CODE = ID =76 9 SEQ =1

Erfahrungen sammeln

Die gezeigte Zeile wurde vom verworfenen Paket erzeugt.

Alle wichtigen Informationen sind enthalten, so dass Vorfälle nachvollzogen werden können.
In diesem Fall wurde ein Echo Request mit dem Identifier 7609 und der Sequenznummer 1 verworfen.

Beschäftigen Sie sich ruhig noch eine Weile mit dem Paketfilter von fuzzball.

Schreiben Sie Pakete mit, und versuchen Sie anhand des Systemlogs nachzuvollziehen, was passiert ist.