[fli4l] IPv6 Firewalling

[Christoph Schulz]

Hallo!

Matthias Taube schrieb:

> Hi,
> vielen Dank für die bisherige Hilfe. Im Zuge des Testens der neuen Fli
> Version möchte ich natürlich durch die nun erfolgende Nutzung von IPv6
> keine Lücken in meinem Netz öffnen und habe zwei Fragen zur Sicheren
> Konfiguration des Routers.
> 
> 1. Es wird empfohlen RH0-Headers zu filtern, und zwar vor allen anderen
> Regeln (Zitat: RH Type 0 : the bullet in the foot [1]):
> [...]

Das ist gestern im FFL-506-Zweig im Rahmen von FFL-1065 in r34548 [1] 
erledigt worden.

In trunk/testing rühre ich IPv6 nicht mehr an, das gehört zu den 
Paketen/Funktionalitäten, die ich nur im FFL-506-Zweig weiterentwickele. Das 
RH0-Risiko ist relativ begrenzt. In [2] steht:

"RH0 processing is disabled per default since Linux 2.6.20.9."

Somit ist der fli4l für eine "Traffic Amplification"-Attacke nicht direkt 
nutzbar. Dafür müsste dann ein anderer Rechner herhalten, der über den fli4l 
erreichbar wäre, was eher unwahrscheinlich ist.

> 2. Stoppen von nicht routbaren Traffic
> Weiterhin wird empfohlen, die folgenden Prefixe mit ICMP destination
> network unreachable zu beantworten, falls diese das eigene Netz Richtung
> Internet verlassen wollen:
>> Sending packets to those destinations would only cause them to be
>> returned by a core router.
>> Prefix 	Description
>> 2001:db8::/32 	IPv6 Documentation Prefix (RFC3849)
>> 2001:10::/28 	ORCHID (RFC4843)
>> fc00::/7 	Unique Local Addresses (RFC4193)
>> fe80::/10 	Link Local Unicast (RFC4291)
> 
> Wäre dies auch als Regel auf dem Fli zu empfehlen?

Sagen wir's mal so: Es wäre seitens des fli4l "nett", den Nexthop-Router mit 
solchen Paketen nicht zu "belasten" ;-) Eine (Sicherheits- oder irgend 
anders geartete) Lücke sehe ich darin nicht.

Ich sehe nur potentiellen Handlungsbedarf bei den letzten beiden Einträgen. 
Das Präfix für ORCHID (v1) wurde an die IANA im März 2014 zurückgegeben, 
siehe RFC 7343 zu ORCHID v2 [3]. Somit könnten Hosts im Internet in diesem 
Adressbereich durchaus auftauchen. Das ständige Verfolgen von solchen 
experimentellen Protokollen und temporär vergebenen Präfixen sehe ich nicht 
unbedingt als erstrebenswert an, vor allem, weil man ja nichts kaputt macht, 
wenn man es doch routet.

Das IPv6-Documentation-Präfix soll "per Konvention" nicht gebraucht werden, 
es kann aber keiner einen hindern, es doch zu tun, z.B. für rein private 
Netzwerke. Deshalb würde ich dies auch eher lieber nicht tun. Das RFC 
forumliert das auch Ganze vorsichtig und nicht normativ:

"This assignment implies that IPv6 network operators should add this
 address prefix to the list of non-routeable IPv6 address space [...]"

Da steht kein MUST, nicht einmal SHOULD (sondern nur "should").

Link-Local- und Unique-Local-Adressen sollten hingegen tatsächlich nie 
geroutet werden, obwohl ich unter [4] da einen etwas kryptischen Hinweis 
über das Weiterleiten von LL-Paketen gelesen habe. Vermutlich ist da aber 
heute nichts dran, da es höchst unsinnig wäre, wenn Layer-2-Funktionalität 
(Bridging) von Layer-3-Funktionalität (FORWARDing) abhängig ist. Schließlich 
hat der fli4l noch keine ULA-Unterstützung, die wird aber kommen (in FFL-506 
/ 4.0), dann werde ich auch entsprechende Firewall-Regeln ergänzen.

[1] https://ssl.nettworks.org/repo/changelog/fli4l?cs=34548
[2] https://www.sixxs.net/faq/connectivity/?faq=filters
[3] http://tools.ietf.org/html/rfc7343
[4] http://danielpocock.com/firewalling-ipv6


Danke und Gruß,
-- 
Christoph Schulz
[fli4l-Team]