Hlavní navigace

Bezpečné IPv6 : směrovač se hlásí

 Autor: ipv6_logo, podle licence: CC BY-SA 3.0
Tomáš Podermański 5. 2. 2015

O IPv6 již bylo napsáno mnoho a dnes představuje prakticky jediné koncepční řešení pro budování Internetu nové generace. Protokol IPv6 se však v mnoha věcech od aktuálně používaného protokolu IPv4 odlišuje. Změny v architektuře protokolu přinášejí inovace, nicméně mohou také ovlivňovat jeho bezpečnostní aspekty.

Seriál jsme rozdělili na několik dílů, ve kterých bychom Vás chtěli seznámit s několika typy útoků, které jsou u protokolu IPv6 víceméně novinkou. Není naším záměrem dávat do rukou útočníků jednoduché návody na provádění útoků, ale poukázat na to, že řada útoků je skutečně velmi snadno proveditelná a jejich důsledky mohou být poměrně fatální. V seriálu se zejména soustředíme na principy útoků, popíšeme, jak je realizovat, a následně se společně pokusíme najít možné způsoby, jak uvedené útoky eliminovat. V dnešní době to ale v mnoha případech nebudou úkoly zcela jednoduché, což je dáno několika faktory:


  • IPv6 protokol je nekompatibilní s protokolem IPv4. V praxi to tedy znamená, že pokud je nějaké zabezpečení v síti již realizováno pro protokol IPv4 (například firewall), nic to neříká o bezpečnostních pravidlech aplikovaných na IPv6. Toto platí samozřejmě i obráceně.
  • Byť jsou první specifikace protokolu IPv6 téměř dvacet let staré, je protokol v porovnání s nasazením IPv4 značně nezralým sourozencem a přirozený provozní tlak na řešení některých typů problémů je tedy zatím velice malý.
  • Třetím významným faktorem je to, že řada výrobců zatím IPv6 nebere zcela vážně. Dnes je naprosto typické, že nový výrobek je uveden na trh nejdříve s podporou IPv4 a podpora IPv6 se přidává až v následných opravách. V takových případech je opět celkem logické, že přednost má základní funkčnost (aby to nějak fungovalo) a bezpečnostní prvky (aby to bylo bezpečné) se objevují až v dalších verzích firmware.

Všechny tyto aspekty dohromady nám pak poměrně znepříjemňují situaci, pokud chceme udržet alespoň stejnou míru zabezpečení jak pro IPv4, tak pro IPv6. V praxi to znamená, že se mnohdy musíme uchylovat k různým trikům a chybějící prvky v zabezpečení IPv6 řešit alternativními způsoby. Někdy ale ani tak neřešíme chybějící implementaci bezpečnostních mechanismů, jako spíše obcházíme architekturu IPv6, abychom eliminovali nově vzniklé problémy.

Při sestavování jednotlivých dílů seriálu jsme vycházeli z naších praktických zkušenosti při implementaci protokolu IPv6 v rámci počítačové sítě Vysokého učení technického v Brně, která se dle statistik sledovaných společnosti Akamai nebo statistik vedených Geoffem Hustonem celosvětově pohybuje na čelních příčkách v míře penetrace IPv6 na koncových zařízeních. Velký dík patří rovněž i kolegům z ostatních univerzit, kteří se v rámci pracovních skupin organizovaných sdružením CESNET, neváhají podělit o vlastní zkušenosti spojené s implementací protokolu IPv6 v jejich sítích.

Oznámení směrovače

Mezi snad nejznámější typ útoku v sítích IPv6 patří zneužití zpráv Oznámení směrovače (Router Advertisement, RA). Oznámení směrovače je integrální součást autokonfigurace koncových zařízení specifikované jako součást mechanismu objevování sousedů Neighbor Discovery for IP version 6 - RFC 4861). Každé zařízení připojené do IPv6 sítě si prostřednictvím zprávy Výzva směrovači (Router Solicitation, RS) může požádat okolní směrovače o předání potřebných údajů pro komunikaci v síti (například adresa směrovače, prefix sítě atd.). Tyto informace se předávají prostřednictvím zprávy Oznámení směrovače, která je zasílaná všem zařízením v příslušné podsíti.

Vlastní zpráva Oznámení směrovače má relativně jednoduchý formát a v podstatě pouze ostatním uživatelům v síti říká: “Já jsem směrovač a můžeš mě použít jako cestu do Internetu (default gateway).” Tato samotná informace nám však často nestačí, a proto se k této zprávě přidávají další konfigurační údaje vhodné pro koncové zařízení - zejména prefix sítě. Tyto konfigurační údaje jsou pak zaslány jako ICMPv6 zpráva všem zařízením v síti. Na rozdíl od automatické konfigurace řešené prostřednictvím DHCP (jak v4, tak v6) se mohou koncová zařízení dozvědět prakticky okamžitě, že mají začít používat jiný síťový prefix (v případě přečíslování), anebo jiný směrovač (například při výpadku některého z nich).

Legitimní zpráva RA může vypadat přibližně následovně:
Ohlášení směrovače - obrázky k článku

Vidíme, že směrovač posílá ze své link-local adresy (fe80::204:96ff:fe1d:4e30) oznámení směrovače všem uzlům v lokální síti (multicast adresa All nodes address ff02::1). V Oznámení směrovače šíří směrovač informaci o používaném prefixu IPv6 - 2001:67c:1220:80c::/64 a své adrese MAC. Link-local adresu směrovače (fe80::204:96ff:fe1d:4e30) si koncová zařízení uloží do své směrovací tabulky, jako výchozí bránu a informace o prefixu použijí pro vytvoření unikátní adresy.

Jak jistě tušíte, tento mechanismus přímo svádí k některým typům útoků. Za směrovač se může prohlásit jakékoliv zařízení a prostřednictvím falešného Oznámení směrovače “podstrčit” všem zařízením v síti nové konfigurační údaje. Ukažme si na příkladu, jak může věc fungovat v praxi. Pro náš případ využijeme nástroje THC-IPV6, který obsahuje hned několik užitečných nástrojů, které budeme používat i v některých dalších scénářích. Jedním z nástrojů je utilita fake_router6, která z libovolného PC s Linuxem vytvoří falešný směrovač IPv6, a to prostým spuštěním příkazu:

# ./fake_router6 -X eth0 2a03:2880:2110:df07::/64
Starting to advertise router 2a03:2880:2110:df07:: (Press Control-C to end) ...

Pokud se po spuštění příkazu podíváme do konfigurace některého z počítačů připojeného ve stejné podsíti, tak uvidíme v konfiguraci adres přibližně toto:

Vypis adres - obrázky k článku

Kromě adresy přidělené regulérním směrovačem v síti (2001:67c:1220:*, zeleně vyznačené), Link-local adres (fe80:*) jsou taky na rozhraní nakonfigurovány námi “podstrčené” adresy (2a03:2880:2110:df07:*, červeně vyznačené).

Jestli někomu ony podvržené adresy přijdou povědomé, tak to není náhoda. Pokud se podíváte do databáze whois tak zjistíte, že tyto adresy jsou přiděleny společnosti Facebook. Skrývá se v tom další záměr. Představme si situaci, kdy útočník na svém PC spustí následující posloupnost příkazů:

# host facebook.com 
facebook.com has address 173.252.110.27
facebook.com has IPv6 address 2a03:2880:2110:df07:face:b00c:0:1
facebook.com mail is handled by 10 msgin.t.facebook.com.
# ip address add 2a03:2880:2110:df07:face:b00c:0:1/64 dev eth0

Tedy nejprve si zjistí, pod jakou IPv6 adresou se skrývá doména facebook.com a tu stejnou adresu nakonfiguruje na svém rozhraní. Pro uživatele v příslušné podsíti je výsledek poměrně přímočarý. Při pokusu o přístup na Facebook se mu může zobrazit něco podobného:

Nový Facebook - obrázky k článku

Díky tomu, že koncová zařízeni v příslušné síti mají nakonfigurovanou stejnou adresu podsítě, v jaké je Facebook, pakety k Facebook serveru nejsou odeslány na adresu směrovače, ale provoz je navázán s podvrženou adresou na útočníkově PC (server útočníka se tváří, že je ve stejné síti jako uživatel). Sofistikovanější verzi tohoto útoku pak může být vytvoření MitM (Man in the Middle) proxy, která přesměrovává provoz na regulérní server. Útočník pak může zasáhnout do probíhající komunikace podle svých potřeb. Zprovoznění takovéto proxy se zabývá například článek Ondřeje Caletky.

Předchozí příklad měl pouze demonstrovat, jak je s využitím IPv6 poměrně snadné (spuštěním dvou příkazů) upravit konfiguraci jedné podsítě tak, aby bylo možné podvrhnout komunikaci. Celkem oprávněně lze namítnout, že tento typ útoku lze eliminovat zabezpečeným kanálem prostřednictvím SSL/TLS. To ovšem platí pouze za podmínky, že uživatelé jsou náležitě obezřetní a automaticky do svého prohlížeče neimportují jakýkoliv certifikát (tedy i útočníkův). Poněkud nepříjemné je, že v tomto případě není možné útok eliminovat ani s využitím DNSSEC, protože z pohledu překladu doménového jména je výsledná IPv6 adresa stále stejná.

Když je oznámení směrovačů o něco více

Podvrhávání komunikace není jediná záškodnická činnost, kterou lze s využitím zpráv Oznámení směrovače realizovat. Jak jsme si ukázali v předchozím případě, jedno IPv6 rozhraní může mít nakonfigurováno hned několik síťových prefixů a adres. To lze využít k dalšímu zajímavému útoku, který je znám pod názvem RA Flood. Podstatou tohoto útoku je periodické generování paketů Oznámení směrovače s novými, náhodnými prefixy. Operační systém pak musí každý takový paket zpracovat následujícím způsobem:

  • Nakonfigurovat další IPv6 adresu na rozhraní, které paket přijalo.
  • Link-local adresu směrovače (také náhodně generovanou) vložit do směrovací tabulky jako výchozí bránu.

Pokud pakety s Oznámením směrovače dokážeme generovat dostatečně rychle, způsobíme tím většině operačních systému docela velké potíže. K simulaci útoku lze opět použít utilitu z balíku THC-IPV6:

# ./flood_advertise6 -X eth0
Starting to flood network with neighbor advertisements on eth0 
(Press Control-C to end, a dot is printed for every 100 packet):
....

Jak velké to jsou potíže si můžete prohlédnou na následujícím videu. Již několik vteřin po spuštění příkazu je CPU PC vytíženo na 100%. V dalším sledu je PC prakticky neovladatelné až do té míry, že přestane reagovat na uživatelské vstupy. Pokud byste podléhali přesvědčení, že je to pouze záležitost produktů z dílny firmy Microsoft tak vás můžeme uklidnit, že ne. Útokem byly (jsou) zranitelné takřka všechny platformy téměř bez výjimky.

Uvedený typ útoku je znám už od roku 2010 a oficiálně byl poprvé publikován 15. dubna 2011 prostřednictvím CVE-2010 autorem námi používaného THC-IPV6 toolkitu Marcem Heusem. I přes zjevný problém někteří výrobci, jako například Juniper, věc uzavřeli s tím, že se jedná o záležitost stran specifikace IPv6 a je nutno věc nejdříve vyřešit na půdě IETF, jak detailněji rozebírá článek (Microsoft, Juniper urged to patch dangerous IPv6 DoS hole). V mezičase ostatní výrobci implementovali alespoň nějaké formy ochrany tak, aby útok nevedl k plnému vytížení CPU. V produktech Microsoft se alespoň základní ochrana objevila až začátkem roku 2013. Nicméně i přes omezení množství zpracovávaných zpráv (rate limiting) Oznámení směrovače zůstává stále RA Flood závažným problémem. Mezi nahodile zahozenými zprávami může být oznámení skutečného směrovače, čímž koncové zařízení přijde o korektní IPv6 konektivitu.

Tímto však zábava s tímto druhem útoku zdaleka nekončí. Omezení (rate limiting) zpráv Oznámení směrovače pomohlo vůči základnímu útoku RA Flood, který pouze náhodně generuje prefixy a link-local adresy směrovačů. Zprávu Oznámení směrovače lze nicméně rozšířit o další volby. Jednou z těchto voleb je Route Information Option která nese podrobnější informace o směrování. Klient, který přijme zprávu Ohlášení směrovače s touto volbou, si informaci vloží do směrovací tabulky. Tak lze pouze jedním paketem Ohlášení směrovače docílit vložení několika desítek (potenciálně stovek) cest do směrovací tabulky. Některé platformy, jako např. MAC OS nebo Microsoft Server 2012, skončí po zaslání těchto paketů restartem. Pro zájemce lze doporučit stránku Sama Bowneho, kde jsou uvedeny návody a demonstrace pro různé platformy.

Selektivní útoky

Ačkoliv Oznámení směrovače jsou primárně určena všem zařízením připojeným v příslušné podsíti, paket s Oznámením směrovače je možné selektivně zaslat na libovolnou unicast adresu. Tímto můžeme předat “zajímavé” autokonfigurační údaje pouze těm zařízením, u kterých k tomu máme důvod. Z hlediska provozu sítě se tato možnost používá ve specifických případech, kterým se budeme věnovat v jednom z dalších dílů seriálu. Útočníkovi se nicméně tato vlastnost velice hodí, protože problém jednotlivce nebude jistě budit tak velkou pozornost jako to, že se všem začaly podivně chovat stránky například Google.com. 

Pro vytvoření takového paketu již útočníkovi nebudou stačit nástroje z THC-IPv6, ale bude se muset uchýlit k něčemu trošku sofistikovanějšímu. Jednak může zprovoznit vlastní instanci démona radvd, kterou nastaví tak, aby určitým klientům předávala požadované parametry. Může také použít nástroj Dana Lüdtkeho ratools, který umožňuje vytvořit zprávu Ohlášení směrovače zcela podle útočníkových potřeb. V neposlední řadě lze také použít některý generátor paketů. Výborně se pro tento účel hodí knihovna Scapy napsaná pro jazyk Python, která prostřednictvím předdefinovaných tříd umožňuje sestavení vlastního paketu a následné odeslání do sítě. Balíčky jsou k dispozici pro většinu distribucí.

Následující kód nám vytvoří paket, který zvolenému zařízení podvrhne adresy serverů Google:

$ python
>>> from scapy.all import *
>>> b = ICMPv6ND_RA(chlim=64,routerlifetime=1800)
>>> c = ICMPv6NDOptPrefixInfo(prefix='2a00:2450:4014:80b::',prefixlen=64)
>>> a = IPv6(dst='fe80::6ab5:99ff:feea:d48a')/b/c
>>> send(a)

Oproti nástroji fake_router6 však podvržený prefix patřící Google není zaslán všem zařízením v sítí, ale pouze zařízením s adresou fe80::6ab5:99ff:feea:d48a.

Pachatel 6to4

Útoky vedené prostřednictvím falešných zpráv Oznámení směrovače nemusí nutně znamenat cílenou záškodnickou činnost. V síti celkem často můžeme narazit na zařízení, která běžný uživatel připojí do sítě a ta se začnou chovat jako IPv6 směrovač. Běžně se tak chovají některé MS Windows s nakonfigurovanou službou “Sdílení Internetu”. Tato služba funguje pro IPv4 provoz jako NAT. Pokud zařízení nemá nativní IPv6 konektivitu, tak si, pokud může, nastaví tunelování IPv6 skrz IPv4 pomocí přechodového mechanismu 6to4, který mu IPv6 konektivitu umožní. Vytvořený prefix 6to4 je následně oznamován do sítě a ostatní zařízení se jej bez problému naučí. Důsledkem je, že takto nakonfigurované PC na sebe “stáhne” veškerý provoz IPv6 a prostřednictvím 6to4 se snaží pakety doručit na nejbližší 6to4 relay. Výsledkem tedy je, ze vaše data určená například na server ve vedlejší místnosti oběhnou půl světa.

Problém nechtěných a nevědomě (díky službě “sdílení Internetu”) vznikajících směrovačů IPv6 je znám už řadu let. Na některých verzích Windows se tento problém pokouší řešit IPv6 readiness update, který implicitně sdílení vypíná. I přes tuto aktualizaci se s falešnými směrovači lze stále v síti setkat, jak je možné vidět v následujícím grafu, který zachycuje výskyt falešných směrovačů v kolejní síti Vysokého učení technického v Brně, připojující řádově 6 tisíc uživatelů.

Falešné směrovače - obrázky k článku

Graf je vytvořen za poslední dva roky a lze vidět, že počet falešných směrovačů klesá, jak jsou postupně instalovány systémové aktualizace. I přesto se s danými zařízeními můžeme v síti stále běžně potkat. Detailněji se problémem rovněž zabývála prezentace “Falešné směrovače v sítích IPv6” na IPv6 semináři organizovaným sdružením CESNET.

Zamezení konektivity

Další možností útoků je pomocí zprávy Ohlášení směrovače odepřít všem, nebo pouze vybraným uživatelům, konektivitu do IPv6 světa. Na začátku dnešního článku jsme napsali, že pokud zařízení přijme zprávu Ohlášení směrovače, link-local adresu směrovače, který ji zaslal, si vloží do své směrovací tabulky jako adresu výchozí brány. Přesněji řečeno, RFC 4861 definuje datovou strukturu Default Router List, do které si zařízení zařazuje seznam směrovačů, kterým může zaslat data. Tato struktura může být implementovaná přímo jako směrovací tabulka daného zařízení nebo jako samostatná datová struktura, která je se směrovací tabulkou pouze propojena. U každé adresy směrovače v Default Router List si zařízení poznamená, po jakou dobu je směrovač dostupný. Tuto informaci šíří samy směrovače v políčku Router Lifetime ve zprávě Ohlášení směrovače. Útočník pak může zaslat podvržené Ohlášení směrovače, kde nastaví dostupnost směrovače na 0. Po přijetí takovéto zprávy jsou zařízení povinny vymazat daný směrovač ze svého seznamu a de facto tak přijdou o svou adresu výchozí brány. Celý útok pak může vypadat následovně:

$ python
>>> from scapy.all import *
>>> raddr = x
>>> a=IPv6(src=raddr, dst='ff02::1')/ICMPv6ND_RA(routerlifetime=0)
>>> send(a)

Útočník si nejprve zjistí adresu směrovače, který posílá legitimní Ohlášení směrovače. Poznamená si jeho link-local IPv6 adresu do proměnné raddr a vytvoří si vlastní zprávu Ohlášení směrovače. Daný ICMPv6 paket pak zašle všem zařízením v dané síti, která si po přijetí této zprávy adresu legitimního směrovače odstraní ze svého seznamu směrovačů a tedy i ze své směrovací tabulky. Jako cílovou adresu lze uvést pouze konkrétní adresu zařízení a provést tak selektivní útok.

Dalším způsobem, jak uživatelům odepřít IPv6 konektivitu, je zneužití zpráv Ohlášení souseda (Neighbor Advertisement) a Výzva sousedovi (Neighbor Solicitation). Tyto zprávy se používají pro zjištění mapování mezi IPv6 adresou a linkovou (MAC) adresou. Jedná se tedy o obdobu zpráv protokolu ARP - ARP Request a ARP Reply, jak jej známe ze světa IPv4. Podrobněji se celému mechanismu zjištění mapování mezi IPv6 a MAC adresou budeme věnovat v dalších dílech seriálu. Pro nynější útok nám bude stačit informace, že pokud směrovač odpovídá zprávou Ohlášení souseda, jaká MAC adresa odpovídá jeho IPv6 adrese, měl by do zprávy uvést, že je směrovač - nastavit příznak Router flag.

Pokud útočník Ohlášení souseda podvrhne a příznak vynuluje, zařízení si musí danou adresu směrovače opět smazat ze svého seznamu směrovačů (Default Router List). Přijde tedy opět o svou výchozí bránu. Princip útoku lze pak demonstrovat následujícím jednoduchým kódem.

$ python
>>> from scapy.all import *
>>> raddr = x
>>> b = ICMPv6ND_NA(R=0,tgt=raddr)
>>> a=IPv6(src=raddr, dst=’fe80::6ab5:99ff:feea:d48a’)/b
>>> send(a)

Útočník vytvoří falešné Ohlášení souseda, ve které vynuluje příznak definující, že zprávu zaslal směrovač. Zařízení s adresou fe80::6ab5:99ff:feea:d48a si po přijmutí této zprávy směrovač ze svého seznamu směrovačů odebere. Prakticky tak přijde o výchozí bránu a tedy i o IPv6 konektivitu do světa.

V čem je to jiné oproti IPv4

Čtenáře jistě napadne, že obdobné problémy musí zákonitě existovat i v protokolu IPv4. I zde jsme zvyklí, že zařízení připojíme do sítě a ono si “samo” zjistí všechny potřebné konfigurační údaje. V čem je tedy situace jiná?

Ve světě IPv4 se dnes jako prostředek autokonfigurace využívá v sítích Ethernet takřka bezvýhradně protokol DHCP (RFC 2131). Zařízení po připojení do sítě prostřednictvím požadavku na všesměrovou adresu (broadcast) vyzve server DHCP o přidělení konfiguračních údajů. Server DHCP odpoví a klient  si na základě jeho odpovědi nastaví IP adresu na rozhraní, případně další údaje, například adresy rekurzivních jmenných serverů. Konfigurační údaje se vždy přidělují na předem stanovený čas, který se může pohybovat od několika sekund až po několik dnů. V okamžiku, kdy klientovi končí platnost přidělených údajů, znovu požádá o jejich prodloužení, ale tentokrát již nikoliv prostřednictvím dotazu na všesměrovou adresu, ale dotazem přímo na server DHCP, který konfigurační údaje poskytl. Klient si tedy musí sám aktivně vyslat žádost o přidělení, případně o prodloužení platnosti konfiguračních údajů. Protokol tedy funguje na principu dotaz - odpověď - potvrzení.

Pokud by útočník chce podvrhnout konfigurační údaje, musí nějakým způsobem zasáhnout do komunikace v okamžiku vyslání prvního požadavku klienta. Pokud útočník má štěstí a dokáže odpověď vytvořit rychleji než servery DHCP instalované správcem sítě, je klient prakticky plně pod útočníkovou kontrolou. Této zranitelnosti například zneužívají Trojan.Flush.M a Trojan:W32/DNSChanger.

V případě autokonfigurace IPv6 je logika věci obrácená. Klient neustále poslouchá na síťovém rozhraní a v okamžiku, kdy dorazí paket obsahující Oznámení směrovače, si ihned nakonfiguruje příslušné parametry. Změnu konfiguračních údajů lze tedy na rozdíl od IPv4 provést kdykoliv, jediným paketem a prakticky s okamžitou reakcí.

Znalci IPv6 jistě namítnou, že i v rámci protokolu IPv6 je možné použít přidělování konfiguračních údajů prostřednictvím DHCPv6. To je bezesporu pravda. Protokol DHCPv6 je nicméně řešen pouze jako rozšiřující nástavba nad bezstavovou autokonfigurací a pro své správné fungování potřebuje Oznámení směrovače. Zařízení připojené do sítě musí nejdříve z Oznámení směrovače zjistit, že má pro konfiguraci adresy použít protokol DHCPv6. Až následně je provedena procedura, kterou známe: dotaz - odpověď, případně potvrzení (podle typu použitého DHCPv6). Bez Oznámení směrovače nelze DHCPv6 použít, protože neexistuje způsob, jak klientovi sdělit výchozí bránu do Internetu. DHCPv6 tuto informaci sdělit neumí. Bez Oznámení směrovače také nelze předat informaci o tom, v jaké je zařízení podsíti - DHCPv6 přiděluje pouze adresu, ne síťovou masku (délku prefixu). Zařízení ve stejné síti tedy nemohou komunikovat mezi sebou, protože neví o tom, že ve stejné síti jsou. V praxi se navíc rozchází jednotlivé implementace operačních systémů, kde některé berou informaci z Ohlášení směrovače jako autoritativní a některé pouze jako tip, jak by se v síti měly chovat. Určité platformy navíc protokol DHCPv6 nepodporují (např. Android). Tady se ale není čemu divit, jelikož dle RFC 6434 je koncové zařízení povinné implementovat pouze bezstavovou konfiguraci. Podpora protokolu DHCPv6 je pouze doporučována, nicméně  není striktně vyžadována. Zkrátka a jednoduše - v IPv6 to bez bezstavové autokonfigurace a Oznámení směrovačů prostě nejde (pomineme-li statickou konfiguraci).

Pokud se  podíváme na útok zneužívající zprávy Výzva sousedovi a Ohlášení souseda můžeme považovat za úplnou novinku u protokolu IPv6. U IPv4 jsme sice měli možnost provést útoky na protokol ARP, nicméně ani pomocí protokolu ARP nejsme schopni smazat adresu směrovače ze směrovací tabulky.

Historie se opakuje

Pokud se podíváme do minulosti, tak zjistíme, že velice podobný mechanismus bezstavové konfigurace výchozí brány, byl rovněž k dispozici v protokolu IPv4 pod názvem ICMP Router Discovery a specifikován v RFC 1256. I přestože jeho podpora byla implementována takřka ve všech operačních systémech včetně systémů Windows 95, patrně jste o něj v dnešní praxi nikde nezavadili. V roce 1999 bylo publikováno bezpečnostní oznámení na prakticky stejné typy problémů, které dnes známe z autokonfigurace IPv6. V té době byl uvedený problém považován za relativně závažnou hrozbu. Lze říci, že takřka všechny systémy od té doby ve výchozím stavu zprávy ICMP Router Advertisment podle RFC 1256 ignorují a konfigurační údaje se přebírají pouze z DHCP.

Pokud by někdo očekával, že se situace může opakovat i v případě IPv6, bude zklamán. Jak jsme zmínili dříve, bezstavová konfigurace a Oznámení směrovače jsou integrální součásti protokolu IPv6 bez kterých automatická konfigurace v IPv6 zkrátka nefunguje. Záležitost kolem bezstavové konfigurace je navíc kontroverzním tématem rozdělujícím IPv6 komunitu na dva nesmiřitelné tábory. První z nich preferuje, aby bylo možné IPv6 adresy přidělovat pouze přes DHCPv6, ideálně s využitím linkové adresy (MAC) a přiřazením výchozí brány pomocí DHCPv6. Tímto by mohla být bezstavová konfigurace pomocí Ohlášení směrovače zcela eliminována a vše by mohlo probíhat přesně tak jak známe z IPv4. Druhá skupina se ovšem domnívá, že to je nekoncepční přebírání vlastností z IPv4 porušující navíc nezávislost vrstev u TCP/IP. Pokud je totiž výchozí brána přidělována pomocí DHCP, tak aplikační protokol (DHCP) přiděluje informaci určenou pro směrování. Tuto informaci by ale měly sdělovat pouze zařízení pracující na síťové vrstvě (směrovače), které díky směrovacím protokolům jako jediné ví, jaký je reálný stav sítě. Bezstavová konfigurace pomocí Ohlášení směrovače s případnou kombinací DHCPv6 tak podle druhé skupiny poskytuje větší flexibilitu a zachovává vrstvovou nezávislost.

Tento ideologický rozpor se vleče již několik let a četné diskuse objevující se přibližně s měsíční periodou nejenom v rámci IETF vedou k patovému výsledku. Konsensus klíčových lidí, tvořící jádro pracovních skupin IPv6 (6man, v6ops), je jasný - žádná výchozí brána v DHCPv6, dokud nebude zdokumentována situace, která je současnými prostředky IPv6 nerealizovatelná.

Poněkud rozpačitým výsledkem celého sporu je pak současné řešení, kde musíme provozovat a vhodným způsobem zabezpečit dva protokoly pro dosažení podobné míry ochrany jako u IPv4 s DHCPv4. Vrstvová závislost je navíc stejně porušená, protože informace o rekurzivních jmenných serverech je možné vložit do Ohlášení směrovače.

Mě se ale IPv6 netýká

V tomto díle jsme si ukázali, jak nám autokonfigurace, která je integrální a nedílnou součásti protokolu IPv6, může způsobit značné nesnáze. Pokud někdo až do této chvíle žil v přesvedčení, že se ho uvedené problémy netýkají, protože IPv6 ho zatím vůbec nezajímá, tak je na velkém omylu. Dnes mají všechny hlavní operační systémy podporu IPv6 ve výchozím stavu aktivovanou a je tedy na nich možné realizovat téměř všechny útoky využívající protokol IPv6 bez ohledu na to, zda je protokol v síti implementován správcem či nikoliv. Prostá ignorace IPv6 tedy zřejmě není nejlepším způsobem. Stojí tedy za zvážení, zda není lepší v síti raději implementovat IPv6 a mít nad věci alespoň rámcovou kontrolu, než věcem nechat zcela volný průběh. Implementace by však měla odpovídat bezpečnostní politice, která je nastavená pro IPv4. V opačném případě hrozí, že bezpečnostní opatření pro IPv4 jsou takřka bezpředmětná, pakliže je lze snadno obejít s využitím IPv6. V příštím díle si ukážeme, jak je možné se proti uvedeným útokům bránit nebo alespoň minimalizovat případné škody v případě, kdy pro plnou obranu nemáme vhodné technické prostředky.

Poznámka: Uvedené příklady, nástroje nebo ukázky zdrojových kódů jsou upraveny, aby je nebylo možné použít pouhým zkopírováním do konzole a spuštěním. Slouží pouze jako prostředek k hlubšímu pochopení diskutované tématiky. Upozorňujeme, že jejich zneužití může být v rozporu přinejmenším s dobrým vychováním.

Našli jste v článku chybu?

5. 2. 2015 13:18

Honza (neregistrovaný)

Děkuji autorovi.
Bezvadně vysvětlené a pochopitelné. Jsem překvapen jak jednuduché je napadnout síť IPv6. Také bych očekával lepší zabezpečení popřípadě více práce pro případného útočníka.

Oceňuji takové sdílení informací a rád bych loboval za udržení kvality a detailech při vysvětlování jak útok provést.
Pokud budu vědět jak to funguje mohu se pokusit zabránit takovým útokům dostupnými prostředky.

Ještě jednou díky a skvělá práce.

Honza



5. 2. 2015 22:25

Nová verze je nasazená, kotvy z titulky fungují a stejně tak i navigace po nových názorech pomocí kláves P a N.

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: „Připluly“ z Německa a možná obsahují jed

„Připluly“ z Německa a možná obsahují jed

Podnikatel.cz: Vládu obejde, kvůli EET rovnou do sněmovny

Vládu obejde, kvůli EET rovnou do sněmovny

Lupa.cz: Slevové šílenství je tu. Kde nakoupit na Black Friday?

Slevové šílenství je tu. Kde nakoupit na Black Friday?

DigiZone.cz: Česká televize mění schéma ČT :D

Česká televize mění schéma ČT :D

Podnikatel.cz: K EET. Štamgast už peníze na stole nenechá

K EET. Štamgast už peníze na stole nenechá

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

Vitalia.cz: Baletky propagují zdravotní superpostel

Baletky propagují zdravotní superpostel

DigiZone.cz: NG natáčí v Praze seriál o Einsteinovi

NG natáčí v Praze seriál o Einsteinovi

Vitalia.cz: Paštiky plné masa ho zatím neuživí

Paštiky plné masa ho zatím neuživí

Podnikatel.cz: Na poslední chvíli šokuje vyjímkami v EET

Na poslední chvíli šokuje vyjímkami v EET

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Podnikatel.cz: EET zvládneme, budou horší zákony

EET zvládneme, budou horší zákony

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Měšec.cz: Kdy vám stát dá na stěhování 50 000 Kč?

Kdy vám stát dá na stěhování 50 000 Kč?

Lupa.cz: Proč firmy málo chrání data? Chovají se logicky

Proč firmy málo chrání data? Chovají se logicky

Vitalia.cz: Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Láska na vozíku: Přitažliví jsme pro tzv. pečovatelky

Měšec.cz: Finančním poradcům hrozí vracení provizí

Finančním poradcům hrozí vracení provizí

Podnikatel.cz: Prodává přes internet. Kdy platí zdravotko?

Prodává přes internet. Kdy platí zdravotko?

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu