|
|
| Zeile 16: |
Zeile 16: |
|
| |
|
| === 7.3 Router-Paketfilter === | | === 7.3 Router-Paketfilter === |
| Das Filtern von Paketen auf einem Router stellt eine besondere Herausforderung dar.
| | [[IPv6/Paketfilter/Router]] |
| * 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.
| |