IPv6 ICMP echo requests auf dem WAN

[tiermutter]

Moin,

IPv6 ist ja sehr auf ICMP angewiesen, auch bei IPv6-test.com wird ja ausgewiesen ob echo requests funktionieren oder nicht.
Meine sense hat per default einige pass Regeln für IPv6 ICMP drin (IPv6 RFC4890 requirements), aber halt keine echo requests.
Wie wichtig ist es eigentlich ICMP echo requests auf dem WAN (oder wo sonst noch?) freizugeben und wozu?

 

[blurrrr]

Von was sprichst Du jetzt? ICMP Typ 8? Das ist die Anfrage eines Echos (Typ 0 wäre die Antwort). Wenn Du z.B. einen Ping zur Firewall schickst (Echo Request), ist eben die Frage, ob die Firewall darauf antworten soll (Typ 0), oder nicht. "Wichtig" liegt im Auge des Betrachters...:

- "Wichtig" kann schon sein, da ansonsten z.B. der Portscan fehl schlägt, weil man keine Ausnahme definiert hat.
- "Wichtig" kann auch sein, weil man ggf. prüfen will, ob das System nur halb abgeranzt ist, aber ggf. der Ping noch durch geht. Ein Beispiel wäre da: Dein VPN geht nicht (von ausserhalb nach Hause). Erste Maßnahme: Ping-Check. Steht der Ping, steht der Anschluss erstmal grundsätzlich (ggf. ist der VPN-Dienst einfach nur gestorben). Kriegst Du gar keine Rückmeldung, weisst Du auch nicht, ob nicht ggf. grade Deine Hardware in Rauch aufgeht.
- "Wichtig" wäre auch, wenn ein Monitoring diesen Anschluss überwacht.
- "Wichtig" wäre ggf. auch, Latenzen messen zu können.

Im Zuge von IPv6 muss ich allerdings auch sagen, dass es garnicht "so" wichtig ist, wichtiger wäre die Durchreichung der Anforderungen an die dahinterliegenden Geräte. Wenn etwas hinter der Firewall auf einen Ping reagiert, stellt sich die Frage garnicht, ob der Anschluss noch da ist

Also ich würde es zulassen, allein schon aus "praktischen" Gründen. Wenn irgendwer das Internet nach X scannt, wird er nicht so dämlich sein und vorher noch einen Ping-Check laufen lassen, das kostet zum einen mehr Zeit und zum anderen fallen ja alle raus, die nicht auf die Anforderungen antworten.

Generell ist es aber nicht "wichtig" und wenn es Dir ein besseres Gefühl gibt, lass es einfach aus und jut is...

 

[tiermutter]

Von was sprichst Du jetzt? ICMP Typ 8? Das ist die Anfrage eines Echos

Jo, von der Anfrage (RFC4890 spricht von Typ 128)...

Klar dass ich das Gerät oder ggf. dahinterliegende Geräte nicht anpingen kann, solange das geblockt wird, auch der Nutzen für mich ist klar.
Ich dachte dass es ggf. noch einen weiteren wichtigen Nutzen für die Funktion von IPv6 hat, so klingt es jedenfalls immer.
So wie es scheint spielt es aber nur bei Teredo eine weitere wichtige Rolle für den Verbindungsaufbau (hätte ja sein können dass es für manche Provider ebenfalls eine wichtige Rolle spielt).

 

[Barungar]

Ich sehe es wie blurrrr. Mach das ICMPv6 auf. Bei mir ist es seit Jahren offen und ich lebe noch.

Nein, ganz im Ernst. Erstens sehe ich bei IPv6 ein geringeres Risiko als bei IPv4 und zweitens wird das ICMPv6 auch anders genutzt als ICMPv4.
IPv6 ermittelt mit ICMPv6 die Path-MTU bei TCPv6-Verbindungen. IPv6 erlaubt im Gegensatz zu IPv4 keine Paketfragmentierung!
Heißt, wenn per ICMPv6 keine verlässliche Path-MTU ermittelt werden kann, hat das negative Auswirkungen auf Dein TCPv6.

Ich habe auch mal gerade einen Test da gemacht, bei mir kam auf Anhieb das raus.

 

[tiermutter]

Heißt, wenn per ICMPv6 keine verlässliche Path-MTU ermittelt werden kann, hat das negative Auswirkungen auf Dein TCPv6.

Genau um sowas ging es mir, Sorgen habe ich auch keine das offen zu haben.

Ich habe auch mal gerade einen Test da gemacht, bei mir kam auf Anhieb das raus.

Ich bin nun bei 19/20... die Sache mit dem Hostname haben wir ja schon diskutiert, der Punkt fehlt mir

 

[the other]

Moinsen,
hier:
https://www.rfc-editor.org/rfc/rfc4890sind dazu auch nochmal einige differenziertere Angaben enthalten...

Ich bin per Smartphone auch bei 19/20...der ICMP6 klappt da nicht. Im anderen VLAN (lustigerweise gleiche Firewall Regeln, sollte also egal sein) hab ich mit dem PC 20/20. Da scheinen also vielleicht die Androids von Hause aus was zu blocken...? Wäre jetzt jedenfalls meine Interpreatation (da auf beiden Interfaces die ICMPv6 erlaubt sind...)

Dem link sind bzgl. der ICMPv6 Protokolle noch einige "Feinheiten" zu entnehmen (was soll unbedingt erlaubt werden, was eher nicht, was gar nicht)...falls du da noch feinjustieren willst.

 

[blurrrr]

Jo, von der Anfrage (RFC4890 spricht von Typ 128)...

Ja, v6 = Typ 128, sorry, bin noch immer schwer v4 gepolt

 

[the other]

Moinsen,
öffnet ihr denn ICMPv6 komplett oder mit ausgewählten Protokollen?
Hab heute zum Versuchen mal nur die als notwendig erachteten geöffnet (also echo reply, echo request, parameter problem /header, time exceed, packet too big, destination unreachable).
Oder ist das tendenziell eh wumpe?

 

[Barungar]

Ich lasse ICMPv6 komplett durch.

 

[the other]

Moinsen,
ich habe mich gestern nochmal dem Thema angenommen (ICMPv6 und Firewallregeln).
Nach etwas Suchen habe ich dann einige nette Hinweise für die pfsense gefunden. Ob dies auch für zB opensense gilt und wie weit auch andere Hersteller das so umsetzen, kann ich allerdings nicht sagen.
Gilt also afaik erst einmal nur für die pfsense (hier die ce in Gebrauch):
für das Funktionieren von IPv6 ist hier nix mehr einzustellen!
Also keine extra Regeln nötig!
Hintergrund: die pfsense legt bei der Installation bereits einige versteckte Regeln an, welche dafür sorgen, dass IPv6 zB out-of-the.box funktionieren (eben ohne extra manuell angelegt Regeln).
Die versteckten und alle anderen Regeln finden sich unter (console):
pfctl -s rules

Habe also hier alle extra Regeln zu ICMPv6 entfernt...die Testseiten für IPv6 zeigen danach das selbe (positive) Ergebnis an.

 

[tiermutter]

Jo, ich habe auch einige Default Rules drin, aber eben keine davon erlaubt echo requests, die musste ich manuell erlauben.

 

[the other]

Moinsen,
ja EchoRequ wird geblockt im default, weil eben nicht zwingend notwendig für IPv6 Funktionalität.
Daher habe ich auf die Interfaces im LAN ICMPv6 komplett erlauben gesetzt. Für WAN dagegen habe ich gar keine Regel drin dazu.

 

[Barungar]

Echo Request ist aber auch nicht schädlich. Das war es weder bei IPv4 noch bei IPv6. Ja, es erlaubt grundsätzlich auszupionieren welche Ports eines Systems offen sind. Aber das ist auch eher Schlangenöl, das zu unterbinden. Hinzu kommt, das Port-Scans bei IPv4 wahrscheinlicher sind als bei IPv6... bei einem /64-Subnetz wäre der Portscan-Aufwand höher als für das ganze IPv4-Internet...