Autor: Sebastian van de Meer (Seite 34 von 49)

Nur damit ich es bei der nächsten Anfrage zu diesem Thema schön verlinken kann, denn es scheint ein Standardproblem zu sein….

Wenn jemandem also auffällt dass in seinem Kernel oder Syslog Meldungen aufschlagen wie:

Oct 24 16:34:12 hostname kernel: [786717.368688] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:35:30 hostname kernel: [786795.230542] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:11 hostname kernel: [786836.309684] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:45 hostname kernel: [786870.407123] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:36:45 hostname kernel: [786870.628257] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:39:09 hostname kernel: [787014.210067] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:40:15 hostname kernel: [787080.322571] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:41:41 hostname kernel: [787166.667404] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:30 hostname kernel: [787275.473179] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.498606] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.498613] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:32 hostname kernel: [787277.584353] rt6_redirect: source isn't a valid nexthop for redirect target
Oct 24 16:43:39 hostname kernel: [787284.396245] rt6_redirect: source isn't a valid nexthop for redirect target

Dann hast du das RFC nicht gelesen! Für das normale Next Hop Routing ist bei IPv6 IMMER die link-local Adresse des Routers zu benutzen und NICHT die Global Unicast IP.

Kontrolle Kontrolle….. Ganz einfach wenn euch folgender Befehl etwas anderes als die fe80 Adresse eures lokalen Router auswirft, dann ist es in 99% der Fällt falsch:

$ ip -6 route show default
default via fe80::20c:42ff:fe72:2ba6 dev eth0 proto static metric 1

Kennt man die Adresse des Routers nicht, hat man die Möglichkeit sie recht einfach zu erfragen, denn Router antworten auf einen ping einer bestimmten Adresse. Möchte ich als wissen, welcher Router hinter meinem eth0 steht:

$ ping6 -c 5 ff02::2%eth0
PING ff02::2%eth0(ff02::2) 56 data bytes
64 bytes from fe80::1: icmp_seq=1 ttl=64 time=40.8 ms
64 bytes from fe80::1: icmp_seq=2 ttl=64 time=24.1 ms
64 bytes from fe80::1: icmp_seq=3 ttl=64 time=0.602 ms
64 bytes from fe80::1: icmp_seq=4 ttl=64 time=0.542 ms
64 bytes from fe80::1: icmp_seq=5 ttl=64 time=0.578 ms

--- ff02::2%eth0 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 0.542/13.344/40.848/16.508 ms

Um das eigentliche Problem besser zu verstehen hilft es den Redirect Punkt besser zu verstehen. Zuerst ICMP Redirect gab es auch bereits bei IPv4… Es ist nichts weiter als eine GAAANZZ alte Version eines Routing „Protokolls“. Über diesen Weg teilt einem der Router eine „bessere“ Route zu einem Ziel mit. Bei einem Router ist es verständlicherweise witzlos bei mehreren „kann“ es helfen. Ich denke aber sauber konfiguriert wäre besser. Wie kommt es nun zu diesem Logeintrag? Ganz einfach…. Ist die IPv6 default Route zum Next Hop nicht, wie vorgeschrieben, die fe80 Adresse des Routers (bei nicht Next Hop Routing natürlich nicht) erreicht der Client den Router und somit die gerouteten Netze (Internet)… Vorausgesetzt der Client hat bereits eine Adresse, welche es ihm ermöglicht den Router überhaupt zu erreichen. Eine fest eingestellt öffentliche IPv6 Adresse zum Beispiel (wenn man hier weiter denkt wird einem schnell klar, dass es schon falsch sein muss nicht die fe80 zu nehmen). ABER wenn der Client nun so seinen Weg über den Router nimmt und dieser dann versucht einem eine „bessere“ Router per ICMP Redirect zu übermitteln, wird der Router hier nicht die fe80 eintragen, sondern die Angesprochene öffentliche. Dieses ist falsch, wird vom Client erkannt und ins Logfile geschrieben!

Nun lassen sich diese Logmeldungen natürlich abschalten, wenn man seinem Client mitteilt, dass er bitte alle ICMPv6 Redirect Messages ignorieren soll, korrekt konfiguriert ist das eigenen Next Hop Routing damit leider noch immer nicht 😀 OK ok… Angreifen könnten natürlich versuchen die ICMP Redirect Messages zu nutzen um einen Angriff zu fahren, denn jeder kann diese Meldungen senden. Damit dieser greift müsste dieser Angreifer im gleichen fe80 (denn nur diese würden vom Client ja genutzt) sitzen. Was bedeutet „am gleichen“ Switch. Ist der Angreifer dort hat er noch 10000 andere Möglichkeiten, gegen welche man sich absichern sollte. Dieses zur Vollständigkeit, da es gerade im speziellen um die Logmeldung geht, gibt es dazu ein anders mal genaueres 😀

Mehr zum Abschalten bis dahin hier:

http://askubuntu.com/questions/118273/what-are-icmp-redirects-and-should-they-be-blocked

So long….