Detekce výskytu duplicitních IPv6 adres je jednou z dalších novinek protokolu IPv6. Uvedený mechanismus jsme už kdysi popisovali v jiném seriálu, takže si nyní provedeme jen velmi krátkou rekapitulaci. V rámci přidělování IPv6 adresy koncovému zařízení se od začátku předpokládalo, že adresa zařízení nebude přidělená externí autoritou, jakou je například DHCP server, ale že se na tvorbě IPv6 adresy bude podílet samo koncové zařízení. Z tohoto důvodu byla celá IPv6 adresa o celkové délce 128 bitů rozdělená na dvě stejně velké části - adresu sítě a identifikátor síťového rozhraní zařízení v dané síti. Síťová část adresy (horních 64 bitů) je společná pro všechny uzly na stejném síťovém segmentu a identifikátor síťového rozhraní (spodních 64 bitů) je unikátní pro každé síťové rozhraní IPv6 uzlu. Zatímco síťová část adresy je předem dána konfigurací sítě, předpokládá se, že identifikátor rozhraní si uzel nějakým vhodným algoritmem vytvoří sám.
Úplně první návrhy protokolu IPv6 počítaly s tím, že identifikátor síťového rozhraní hostitele bude odvozen od linkové adresy síťové karty (MAC adresy). Tento přístup však začal narážet na problémy stran ochrany soukromí - jakékoliv IPv6 zařízení by bylo sledovatelné napříč Internetem, ať už se vyskytne v jakékoliv síti. Z toho důvodu se v roce 2011 objevilo RFC 3041, později nahrazené RFC 4941, zavádějící mechanismus, kterému se zkráceně říká Privacy Extensions. Ten ve zjednodušené podobě funguje tak, že identifikátor síťového rozhraní hostitele je generován zcela nahodile a v pravidelných časových intervalech se musí měnit. V konečném důsledku je tedy výsledná IPv6 adresa koncového uzlu náhodně vytvořená a předem nepredikovatelná.
Skutečnost, že IPv6 adresy nejsou přidělovány centrální autoritou, která má přehled, komu jakou adresu přidělila, vede k tomu, že v přidělování adres mohou teoreticky vzniknout kolize. I když je pravděpodobnost vzniku takové kolize velmi malá, nelze ji se 100% jistotou vyloučit. Aby byly ošetřeny jednak tyto krajní případy a také situace, kdy jsou v rámci jedné sítě nedopatřením manuálně nakonfigurovány totožné IPv6 adresy, disponuje protokol IPv6 detekcí duplicitních adres (DAD - Duplicate Address Detection).
Celá detekce duplicitních adres funguje následovně. Představme si situaci, že váš laptop je nově připojen do sítě. Na základě Výzvy směrovači (Router Solicitation) obdrží Oznámení směrovače (Router Advertisement), kde se dozví, že má pro síťovou část adresy použít například prefix 2001:67c:1220:f777::/64. Pokud má aktivovanou podporu Privacy Extensions, vygeneruje si náhodně 64 bitovou posloupnost pro identifikátor síťového rozhraní, kterou připojí za přidělený síťový prefix a tím získá výslednou IPv6 adresu. Dříve než však tuto adresu nakonfiguruje na svém rozhraní, vyšle do sítě zprávu Výzva sousedovi (Neigbor Solicitation), kde jako adresu vyzývaného souseda použije právě vytvořenou IPv6 adresu. Vtip je v tom, že pokud by na síti již uzel s uvedenou adresou existoval, tak odpoví prostřednictvím zprávy Ohlášení souseda (Neigbor Advertisement). V naprosté většině případů však odpověď nedorazí a uzel tak ví, že může takto zvolenou adresu použít. Mechanismus si můžeme přirovnat k situaci, kdy vstoupíte do místnosti, kde je umístěno 1,8 * 1019 (264) židlí a vy víte, že místnost nemá žádný zasedací pořádek. Náhodně si tedy zvolíte židli, ale před usednutím se ještě zdvořile zeptáte, zda židle, na kterou se hodláte usadit, je volná. Pokud se do určité doby nikdo neozve, tak se prostě posadíte.
V reálné sítí pak může celý proces vypadat tak, jak je zachyceno na následujícím obrázku:
Nejdříve koncový uzel vyšle do sítě požadavek na ověření dostupnosti souseda s adresou fe80::c844:ce09:2179:f914. Jedná se o jeho link-local adresu, kterou by chtěl nadále používat (paket č. 1). Pokud usoudí, že vytvořená link-local adresa s nikým nekoliduje, využije ji k zaslání následné zprávy Výzva směrovači (paket č. 2). Po obdržení zprávy Oznámení směrovače (paket č. 3) zařízení ví, jaký IPv6 prefix se v síti používá. Z daného prefixu si zařízení vytvoří dvojici IPv6 adres - globální a dočasnou a celý proces pro tyto adresy zopakuje (pakety č. 4 a 5). Vzhledem k tomu, že nedorazila reakce od žádného okolního uzlu, systém si obě globální IPv6 adresy nakonfiguruje na svém rozhraní a začne je používat.
Jak už asi tušíte, zde jsou přímo ideální podmínky pro to, aby do procesu mohl velmi jednoduchým způsobem vstoupit útočník. Ten pak na každý dotaz, zda v síti již existuje příslušná adresa, jednoduše odpoví, že existuje. V praxi pak průběh útoku vypadá tak, jak je zachyceno na následujícím obrázku:
Stejně jako v předchozím případě uzel vyšle do sítě Výzvu sousedovi. Útočník ale pohotově zareaguje zprávou Ohlášení souseda. Uzel se tedy začne domnívat, že příslušná IPv6 adresa se už používá. V případě, že má uzel aktivovanou podporu pro Privacy Extensions, vznikne na straně uzlu domněnka, že náhodou došlo k vygenerování stejného identifikátoru síťového rozhraní. Vygeneruje si tedy nový identifikátor - tedy i novou IPv6 adresu, doufaje, že tentokrát již kolize nenastane. Opět zkontroluje, zda v síti taková adresa existuje a opět od útočníka obdrží odpověď, že ano. Takto se děj opakuje, dokud koncový uzel nevyhodnotí situaci tak, že jakékoliv další pokusy jsou zbytečné. Pokud bychom se vrátili do našeho přirovnání k místnosti s židlemi, situace je obdobná, jako kdyby se po každém vašem dotazu, zda je příslušná židle volná, odněkud ozval hlas “tato židle je obsazená”.
Duplicitní adresy a standardy
Dříve než si řekneme, jaké je v těchto situacích chování jednotlivých implementací, podívejme se co o detekci duplicitních adres hovoří standardy. Specifikace bezstavové autokonfigurace (RFC 4862) jasně říká, že v případě detekování duplicitní IPv6 adresy se má příslušné IPv6 rozhraní deaktivovat a podat o tom systému zprávu (například do logu). V té době specifikace předpokládala, že identifikátor síťového rozhraní dané IPv6 adresy bude vždy odvozený od adresy linkové vrstvy (MAC adresy). Výskyt duplicitní IPv6 adresy by tedy indikoval duplicitní MAC adresu v síti. S příchodem Privacy Extensions tj. RFC 3041 a RFC 4941, bylo toto chování upraveno. Pakliže je IPv6 adresa vytvořena s využitím Privacy Extensions a je detekována jako duplicitní, systém musí vytvořit novou IPv6 adresu a proces detekce duplicitní adresy opakovat. Počet opakování by pak měl být záležitostí nastavení operačního systému.
V roce 2006 doznal mechanismus detekce duplicitních adres dalšího vylepšení v podobě RFC 4429 - Optimistic Duplicate Address Detection (DAD) for IPv6. Původní návrhy totiž předpokládaly, že adresa, pro kterou probíhá detekce duplicity, se nesmí používat pro komunikaci. Použít ji lze až poté, co je potvrzená její unikátnost (resp. je nepotvrzena její duplicita). To ovšem může trvat v některých případech až 2 vteřiny. Výskyt kolize při použití 64 bitových identifikátorů je však velice vzácný jev, a tak RFC 4429 upravuje chování tak, že adresu je možné používat ihned a případná kolize se řeší až v následujícím kroku. Další změny v mechanismu detekce duplicitních adres přináší draft Enhanced Duplicate Address Detection, který řeší některé speciální situace, kdy koncový uzel současně přijímá data, a tedy sám sebe detekuje jako duplicitní uzel.
DAD a MS systémy
Jaké jsou praktické důsledky útoku? Zde opět bude zejména záležet na tvůrci implementace kódu detekce duplicitních adres v příslušném operačním systému. Systémy z dílny Microsoft mají ve výchozím stavu aktivovanou podporu Privacy Extensions a Optimistic DAD. Vygenerují si tedy link-local adresu a ihned ji použijí k odeslání zprávy Výzva směrovači. Pokud by došlo k detekci duplicitní IPv6 adresy - ať už náhodou nebo díky útočníkovi, systém se pokusí ještě o dalších 9 pokusů. Pokud jsou všechny vyhodnoceny jako duplicitní, tak v generování dalších adres se už nepokračuje. Dobrou zprávou nicméně je, že pokud systém nemá nakonfigurovanou IPv6 adresu, tak se v cca 3 minutových intervalech pokouší znova otestovat duplicitu posledně zvolené IPv6 adresy.
Pokud je IPv6 adresa na rozhraní nakonfigurována staticky, je sice provedeno ověření duplicitní adresy, ale adresa zůstane na rozhraní nakonfigurována bez ohledu na výsledek tohoto testu. Adresu je tedy možno využívat ke komunikaci.
DAD v Linuxu
V případě Linuxu se chování trochu odlišuje. Link-local adresa zůstane nakonfigurována na rozhraní bez ohledu na výsledek testu duplicity. V případě globální adresy odvozené od MAC adresy (EUI64) k nakonfigurování takové adresy nedojde. Systém pak s minutovou periodou provádí další testování duplicity této IPv6 adresy. V okamžiku, kdy už není duplicita detekována, systém IPv6 adresu na rozhraní nakonfiguruje. V případě, že je v linuxovém jádře aktivována podpora pro Privacy Extensions, systém provede 5 pokusů s náhodně vytvořenými IPv6 adresami. Pokud všechny testy duplicity dopadnou negativně, linuxové jádro vzdá generování dalších IPv6 adres až do restartu síťového rozhraní. V případě, že je IPv6 adresa konfigurována manuálně, nastaví se na rozhraní vždy, bez ohledu na výsledek testu duplicity.
Poznámka: Záleží na distribuci jestli náhodně generované adresy má ve výchozím stavu zapnuté nebo ne. Enterprise distribuce (např. RedHat, CentOS) používají většinou adresy odvozené od MAC adresy. Uživatelské distribuce pak zase většinou mají Privacy Extensions aktivované. Pokud byste chtěli nastavení na svém systému zkontrolovat, případně upravit, můžete chování systému ovlivnit prostřednictvím volby net.ipv6.conf.ethX.use_tempaddr. Volba use_tempaddr pak může nabývat několika voleb:
- 0: Privacy Extensions jsou vypnuté
- 1: Privacy Extensions jsou zapnuté, ale pro komunikaci nejsou preferované
- 2: Privacy Extensions jsou zapnuté a preferované pro komunikaci
V některých případech se může stát (např. při manuální konfiguraci), že test duplicity dopadne negativně a IPv6 adresa přesto bude nakonfigurovaná na příslušném rozhraní. Adresy totiž zůstanou ve stavu “tentative dadfailed” a operační systém tyto adresy nebude používat. V tomto případě je nutné nepoužívat příkaz ifconfig (který je stejně označen za zastaralý), protože se žádným způsobem nedozvíte, že adresa je v tomto stavu - jinými slovy ve výpisu příkazu ifconfig vypadá vše normálně. Prozradí vám to ale příkaz ip:
[root@test9 ~]# ip -6 addr show eth1
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:67c:1220:f777::2/64 scope global tentative dadfailed
valid_lft forever preferred_lft forever
inet6 fe80::250:56ff:fe94:8a43/64 scope link tentative dadfailed
valid_lft forever preferred_lft forever
Poznamenejme jen, že v tomto “mrtvém” stavu už adresy zůstanou až do restartu síťového rozhraní nebo odkonfigurování a zpětném nakonfigurování IPv6 adres.
DAD a FreeBSD
Chování detekce duplicitních adres v systémech FreeBSD zřejmě nejvíce odpovídá tomu co požadují RFC. V případě, že je na rozhraní detekována duplicitní adresa je příslušné IPv6 rozhraní trvale deaktivováno. Zatím se nám však nepodařilo najít nějaký elegantní způsob, jak tento stav změnit, kromě restartu celého systému:
test-freebsd: # ifconfig em1
em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:50:56:b5:e4:3f
inet6 fe80::250:56ff:feb5:e43f%em1 prefixlen 64 duplicated scopeid 0x2
inet6 2001:67c:1220:f777::12 prefixlen 64 tentative
nd6 options=2b<PERFORMNUD,ACCEPT_RTADV,IFDISABLED,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
Útočník na sítí - IPv6 se nekoná
Výskyt útočníka zneužívající mechanismu detekce duplicitních adres má tedy v síti poměrně nepříjemné důsledky. Takřka pro všechny systémy to znamená, že nezískají IPv6 konektivitu. Jak jsme si ukázali, některé systémy, jako například Linux nebo Windows implementují jisté opravné procedury, které umožní zpětné získaní IPv6 konektivity alespoň po odeznění útoku. Je zde opět vidět, že tvůrci operačních systémů upřednostňují větší robustnost před striktním dodržováním standardů. V praxi je pak chování každé implementace trošku jiné a zpravidla ne zcela dokonale zdokumentované. Pokud chceme znát přesně chování mechanismu detekce duplicitních adres příslušného systému, nezbývá nám zpravidla jiná možnost než analýza chování v testovacím prostředí.
K otestování je možné opět využít nástroj z balíku thc, který vytvoří z libovolného PC útočníka. Použití je opět velice jednoduché:
# ./dos-new-ip6 -X eth1
Started ICMP6 DAD Denial-of-Service (Press Control-C to end) ...
Jak je to v IPv4
Pokud se podíváme do světa IPv4 tak i tam je k dispozici podobný mechanismus pro detekci duplicitních adres. Pro podobné účely se používá mechanismus nazvaný “Gratuitous ARP”. Nevyžádané (Gratuitous) ARP pakety v tomto případě značí ARP pakety, které pro normálním fungování protokolu ARP nejsou třeba. Princip mechanismu pro detekce duplicit je pak velice podobný jako u IPv6. Uzel vyšle do sítě zprávu Gratuitous ARP Request, kde jak cílovou, tak zdrojovou IP uvede svou vlastní. Pokud do určitého času nedorazí odpověď v podobě zprávy ARP Reply, adresa je považována za nekonfliktní. Uvedený mechanismus je dnes implementován ve všech běžně používaných operačních systémech. Má ovšem několik úskalí. Tento mechanismus totiž zasílá pouze jeden dotaz, když si zařízení konfiguruje adresu a už neprovádí žádné další detekce v průběhu. Pokud se tedy vyskytnou v síti dva počítače se stejnou adresou, později připojený počítač zahlásí chybu. První zařízení si problému často ale ani nevšimne. Zařízení pak zkouší adresu použít tak jak tak, což vede k problémům s konektivitou, jelikož si navzájem stále resetují TCP spojení. Proto bylo vydáno RFC 5227, které doplňuje detekci duplicitní adresy i pro IPv4. Způsob chování je pak stejný jako u protokolu IPv6.
Detekce duplicitních adres v IPv4 je však stále pouhou volitelnou nástavbou mající za úkol snadněji odhalit chyby v konfiguraci sítě. Nejsou zde tak striktní pravidla pro akci, kterou je nutné vykonat v případě detekce konfliktní adresy. V případě, že se do sítě připojují uživatelé, IPv4 adresy jsou typicky pod jednotnou autoritou v podobě DHCPv4 serveru, kde server eliminuje případné přiřazení konfliktní adresy. Na druhou stranu, DHCPv4 server nedokáže vyřešit situaci, kdy konfliktní adresa je nakonfigurována například staticky.
Je třeba mít také na paměti, že detekce duplicitních adres byla u protokolu IPv6 také původně zamýšlená jako pomocník pro snadnější odhalení chyb v síti. Vše se ale radikálně změnilo s příchodem Privacy Extensions, kde je mechanismus detekce duplicitních adres součásti běžného procesu volby adresy pro rozhraní. Pravidla jsou tu však vcelku striktní. Dle specifikací musí být příslušné IPv6 rozhraní trvale deaktivováno (tj. do restartu systému nebo rekonfigurace). Jak jsme si ukázali, tak operační systémy (Windows, Linux) po nějakém čase provádějí opětovné ověření adresy. Pokud se časem tato implementace dostane i na další zařízení tak se nejspíše vyhnete hypotetickému katastrofickému scénáři, kdy po DAD útoku budete muset oběhnout všechna PC, tiskárny, čtečky a kamery a provést jejich reboot.
Smysluplnost detekce duplicitních adres
Pomineme-li původní záměr detekce duplicitních adres, tj. eliminace konfiguračních chyb, tak vás jistě napadne, zda má vůbec smysl testovat náhodně generované adresy podle Privacy Extensions. Adresní prostor o velikosti 264 je dostatečně velký, aby pravděpodobnost výskytu kolizí byla naprosto minimální. Touto otázkou se zabývá již dříve zmíněné RFC 4429, které uvádí, že v sítí s pěti tisíci uzly je pravděpodobnost výskytu kolize 5.4e-12. Otázkou tedy zůstává, zda při takto nízké pravděpodobnosti má vůbec smysl nějakou detekci duplicitních adres provádět. Ve prospěch kritiků hovoří i další argument, že mechanismus detekce duplicitních adres vyžaduje, aby všechna zařízení připojená v síti byla schopna na případnou výzvu reagovat. To je ovšem velký problém pro mobilní zařízení, která ve snaze šetřit baterie nemají trvalé zprovozněné síťové rozhraní. Zařízení připojené například k WiFi síti “uspí” IP stack, aby šetřilo baterii. Jak jsme si ukázali v jednom z předchozích článků zabývajícím se multicastem, některé zařízení konfiguraci IPv6 adresy řeší tak, že s každým probuzením se znovu provádí celý proces tvorby a ověření adresy. To ovšem s sebou nese další problémy v podobě vytváření nových záznamů v cache sousedů a v konečném důsledku zvýšenému multicast provozu na síti.
Obrana
V současné době nám není známo, že by existoval nějaký obranný prostředek proti tomuto typu útoku na straně síťové infrastruktury. Princip, který se používá pro zamezení obdobnému útoku v IPv4, tj. ARP inspection, o kterém jsme hovořili v druhém díle, není možné v tomto případě využít. Je to opět dáno tím, že IPv6 adresy jsou tvořeny nepredikovatelně na straně klienta. Ke zmírnění dopadu útoku je možné použít některé techniky First-Hop-Security (například větší segmentace sítě), které jsme popisovali již dříve.
Účinnou formu obrany proti tomuto útoku můžeme použít na straně samotného zařízení. Princip obrany je velmi jednoduchý - výsledek detekce duplicitních adres se zkrátka ignoruje a příslušná adresa je nakonfigurována vždy. Postup je sice v rozporu se standardy, ale v praxi by neměl narážet na problémy. V unixových systémech je možné chování zpravidla nastavit parametrem sysctl.
Linux:
# sysctl -w net.ipv6.conf.eth1.accept_dad=0
net.ipv6.conf.eth1.accept_dad = 0V případě FreeBSD pak:
# sysctl -w net.inet6.ip6.dad_count=0
net.inet6.ip6.dad_count: 1 -> 0
U systémů Windows lze podobně celý mechanismus deaktivovat pomocí příkazu.
C:\Windows\system32>netsh interface ipv6 set privacy maxdadattempts=0
Zajímavé může být nastavení této vlastnosti i na směrovači připojující celou síť. U platformy Cisco nastavením dané volby na rozhraní:
SW-Cisco(config-if)# ipv6 nd dad attempts 0Podobně tak u HP Comware
[SW-Comware-Vlan-interface220]ipv6 nd dad attempts 0Případně u platformy HP ProCurve
SW-Procurve(config)# ipv6 nd dad attempts 0Závěr
V dnešním díle jsme si ukázali nepříjemnosti, které nám může způsobit útočník zneužitím mechanismu detekce duplicitních adres. Původní záměr o vytvoření mechanismu, který by měl pomáhat eliminovat zejména konfigurační chyby, se díky použití Privacy Extensions začal postupně používat k trochu jinému účelu. Dnes mechanismus detekce duplicitních adres představuje pro útočníka prostředek, jak efektivně deaktivovat IPv6 stack při startu nebo rekonfiguraci koncového systému. Stejně jako v předchozích případech, v dnešní době nemusí být důsledky útoku nijak fatální, protože řada aplikací, zejména prohlížečů, je schopná přepnutí na protokol IPv4. Ve snaze vytvořit robustnější implementaci protokolu IPv6, pak operačních systémy, například Linux nebo Windows, implementují alespoň základní ochrané prostředky, které umožní získat zpět IPv6 konektivitu po odeznění útoku. Dochází tak nicméně k velkým odlišnostem daného mechanismu v reálných implemetacích a k rozporu se specifikacemi.
Obranné prostředky proti tomuto typu útoku jsou na straně síťové infrastruktury zatím spíše omezené. Částečně mohou pomoci některé techniky First-Hop-Security. Na straně koncových systémů je možné zpravidla konfiguračně deaktivovat celý mechanismus detekce duplicitních adres a tím udělat systém proti tomuto útoku imunní. Na druhou stranu ale pak může nastat problém při (byť velmi nepravděpodobném) opravdovém výskytu duplicitní adresy.
Tímto dílem jsme současně uzavřeli náš exkurs do bezpečnostních novinek protokolu IPv6. Jak jste si mohli všimnout, přestože protokol IPv6 je tu s námi již takřka 20 let, stále ještě zbývá mnoho problému k dořešení - od standardizace přes implementace v zařízeních až po konfigurační zvyklosti (Best Practices). Doufáme, že seriál přispěl k detailnějšímu porozumění některých vlastností protokolu IPv6 a doufáme, že vás neodradil od dalšího seznamování se s tímto protokolem. Jak jsme si popsali, řada útoků je velice dobře realizovatelná bez ohledu na to, zda je protokol v síti implementován či nikoliv. Dobré porozumění protokolu je tedy dnes nutností, bez které se kvalifikovaný správce neobejde.
