Praktické problémy s IPv6, část třetí

Od napsání předchozích epizod se na poli českého IPv6 udála zásadní událost. Servery společnosti Internet Info, včetně tohoto blogu, jsou přístupné přes IPv6. Že jste si ani nevšimli? Tak to má být. Zřejmě to s těmi problémy kolem IPv6 není tak žhavé… I přesto si dovolím dokončit několik kapitol o problémech s tímto protokolem.

Nechtěné Man-in-the-Middle útoky

Útok typu M-i-t-M je asi to nejzákeřnější, co může útočník na síti dělat. Je to také často jediná použitelná cesta, jak odposlouchat šifrované spojení, pokud uživatelé nejsou důslední v ověřování autenticity protistrany.  Klíčovou podmínkou pro provedení takového útoku je přesměrování veškeré komunikace tak, aby procházela počítačem útočníka. Na IPv6 je takové přesměrování běžným jevem. Stačí k němu počítač s MS Windows ve verzi Vista nebo vyšší a z nějakého důvodu zapnutá služba sdílení připojení k Internetu (ICS). Tato služba totiž kromě NATu, pokud nadetekuje veřejnou externí adresu, aktivuje také 6to4 směrovač, který do sítě nabízí 6to4 IPv6 adresy formou bezestavové konfigurace. Za to patří Microsoftu pochvala, jak jsem uvedl v prvním díle, pokud by se tak chovala většina NATů, měli bychom přechod na IPv6 dávno za sebou. Bohužel, celé to evidentně není tak doladěné, jak by být mělo − běžně se stává, že počítač posílá ohlášení směrovače i zpátky externím rozhraním (!). Vzhledem k povaze automatické konfigurace IPv6 dojde vpodstatě okamžitě k přesměrování IPv6 provozu přes stanici „útočníka“. Situaci naznačuje následující obrázek.

Faktický důsledek této situace není ani tak bezpečnostní, jako spíš výkonnostní. Klientské stanice s MS Windows obvykle nejsou dimenzovány na směrování síťového provozu, navíc je může uživatel kdykoli vypnout a tím všechna spojení přerušit.

Třídy adres a provisioning nastavení

Už v předchozím díle jsem nakousl, že bezestavová automatická konfigurace mimo jiné neumí sdělit klientovi, že v dané síti fungují pouze určité IP adresy. Takže pokud takové omezení v síti platí, je nutné každou stanici ručně zkonfigurovat.

Další velice zajímavé volby skrývá tabulka priorit adres, v Linuxu uložená v souboru /etc/gai.conf. Zatímco v IPv4 světě se tak nějak počítalo, že jedno síťové rozhraní má jen jednu IP adresu, koncept IPv6 počítá s tím, že jedno rozhraní má adres několik. Stejně tak se počítá s tím, že odpověď na DNS dotaz obsahuje více adres. Jsou definována přesná poměrně sofistikovaná pravidla, jakou adresu vybrat jak na straně zdroje, tak i na straně cíle.

Výchozí nastavení například předepisuje, že pokud je dostupné spojení po IPv4 i IPv6, dá se přednost IPv6. Navíc jsou rozsahy IP adres tříděny do skupin a upřednostňují se spojení v rámci jedné skupiny. Tím se má v maximální možné míře eliminovat používání prostředníků – Teredo adresa si k sobě vybere jen Teredo adresu, 6to4 jen 6to4 adresu a nativní IPv6 adresa jen nativní adresu. Systém nám trochu drhne v tom, že žádný producent obsahu nepublikuje 6to4 adresu v DNS, a také v tom, že velká část „nativních“ IPv6 adres je ve skutečnosti tunelovaných.

Chceme-li zavést IPv6 do prostředí s již zavedeným IPv4 protokolem, mohli bychom předejít některým problémům upravením tabulky priorit tak, aby  spojení po IPv4 protokolu dostalo maximální prioritu, a spojení přes IPv6 se používalo pouze v případě, že není zbytí.  Takové nastavení je velmi rozumné – zaručuje totiž, že co fungovalo doteď, to bude fungovat nadále bez problému a případné problémy nastanou jen s obsahem, který by bez IPv6 vůbec dostupný nebyl.

I v tomto případě ale nezbývá, než všechny stanice obejít a ručně konfiguraci změnit. Nicméně osobně nemám dojem, že by to bylo zcela špatně. Rozhodnutí o preferování určitých adres by dle mého názoru mělo být v kompetenci správce počítače, nikoli správce sítě.

Blýská se na lepší časy?

S IPv6 to není tak špatné, ale neznamená to, že by nemohlo být lépe. Zkusím v několika bodech shrnout, jak si představuji budoucnost:

• Tunelování, ať už nativní, nebo 6to4 se stane minulostí. Pokud dojde k rozšíření IPv6-only obsahu, je možné, že se začne více používat Teredo, jednoduše proto, že nepotřebuje žádnou podporu ze strany síťové infrastruktury, a zároveň je předinstalováno takřka v každých MS Windows.
• Správci menších sítí se postupně smíří s tím, že na IPv6 není možné získat úplnou kontrolu nad přidělováním IPv6 adres a pro jednoduchost budou používat bezestavovou konfiguraci, případně doplněnou o bezestavové DHCP. Větší sítě budou každého uživatele připojovat do samostatné VLANy a/nebo použijí DHCPv6.
• Problém rušivých RA dostane řešení, např. v podobě rozšíření „RA-guard“ v síťových přepínačích, které zabrání klientským stanicím vůbec do sítě odesílat ohlášení směrovače. V menších sítích, jejíchž aktivní prvky takové možnosti nenabízí, lze k podobnému účelu použít démon Ramond, který rušivým RA nezabrání, ale hbitě odčiní jejich efekt zasláním „mazacích RA“. Další možnosti shrnuje dokument „Rogue RA Problem statement“.
• Naučit se budou muset také poskytovatelé obsahu. Zatímco dnes k odstřihnutí zlobivého uživatele obvykle stačí zablokovat jeho IP adresu, bude u IPv6 nezbytné blokovat přinejmenším celou podsíť /64, pokud se realizuje vize, že každý zákazník včetně domácích dostane rozsah /48, bude jej zřejmě nutné zablokovat celý. Problém vidím v tom, že stejně dlouhý prefix dostane jak jedna domácí přípojka (efektivně jeden uživatel), tak například celé ČVUT (~ 10000 uživatelů). Nikde není ani dáno, že všechny podsítě používají délku prefixu /64. Viděl bych to tak, že časem vznikne databáze IP adres a k nim relevantních délek prefixu. Nejde ale jen o odstřihování uživatelů. Stejný problém bude nutné vyřešit v nejrůznějších webových anketách, pro ztížení možnosti manipulace výsledků.

Končí prozatím poslední díl miniseriálu. Jak už jsem zmínil v úvodu, v moři zvaném IPv6 se hnuly ledy. Zpřístupnění webů Internet Infa považuji za velký krok pro české IPv6. Ukazuje se, že ani komerční poskytovatelé obsahu nemusí mít strach, že by vystavením AAAA záznamů pro své domény přišly o zákazníky. Kdo bude následovat? Seznam, Idnes, nebo snad TN.cz? Nechme se překvapit.