Hlavní navigace

Bezpečné IPv6: když dojde keš – obrana

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

V předchozím díle jsme se seznámili se základními principy útoků na cache sousedů (neighbor cache) a s jejími možnými důsledky. V dnešním díle navážeme a pokusíme se společně nalézt způsoby a prostředky, jak se těmto útokům bránit, nebo alespoň minimalizovat jejich případné následky.

Dnešní díl bude bez dalších úvodů navazovat na díl předchozí. Pro seznámení se s problematikou útoků na cache sousedů tedy doporučujeme nejdříve prostudovat předchozí díl. Cest pro eliminaci útoků na cache sousedů existuje několik, přičemž o žádné z nich nemůžeme říct, že řeší problém komplexně a bezezbytku, či alespoň nevyvolává rozporuplné postoje v rámci IPv6 komunity.

Zvětšení délky prefixu

Jedním z prvních řešení může být zvětšení délky prefixu na velikost zaručující, že část prefixu (host ID) bude obsahovat pouze takové množství IPv6 adres, aby je bylo možné uložit do cache sousedů. V praxi to tedy znamená, že namísto standardní délky prefixu (/64) určeného pro koncové sítě, použijeme prefix delší, například 120 bitů. Tímto zůstane 8 bitů pro adresaci 255 koncových zařízení, tj. jsme ve stejném stavu, jako kdybychom použili délku prefixu /24 u IPv4. Tento přístup ovšem naráží na několik problémů. Při návrhu sítě musíme zohledňovat celkový počet zařízení v koncové sítí a ten promítnout do vhodně volených délek prefixů. Co je ovšem mnohem větší problém, je to, že mechanismy bezstavové autokonfigurace, stejně jako celá řada dalších standardů, předpokládají, že délka prefixu pro koncovou síť bude vždy 64 bitů. S jinou délkou prefixu bezstavová autokonfigurace zkrátka nebude fungovat. Na některých systémech může fungovat kombinace DHCPv6 a delšího prefixu, nicméně tento způsob koliduje například s RFC 4291 - IPv6 Addressing Architecture. Řada výrobců zařízení navíc spoléhá na to, že délka prefixu nebude delší než oněch 64 bitů a byť je delší prefix na zařízení možné nakonfigurovat, tak může dojít k neoptimálnímu zpracování provozu (např. v CPU namísto hardware). V neposlední řadě postup v principu nijak neřeší situaci, kdy je cache sousedů zaplněná a nově připojená zařízení nemohou být zařazena do cache sousedů. Celou problematiku fixní délky prefixu pro koncové sítě pak shrnuje nově vydané RFC 7421 - Analysis of the 64-bit Boundary in IPv6 Addressing.

Zvětšení délky prefixu je tedy postup, který může mít význam spíše jako ochrana vlastních zařízení před útoky cílenými na vyčerpání cache sousedů vzdáleným útočníkem. Lze jej tedy s výhodou použít například pro sítě, které propojují směrovače. Touto situací se speciálně zabývá RFC 6164, které pro takováto spojení doporučuje použít prefix s délkou 127 bitů, tedy takový, který umožňuje připojení právě dvou zařízení. Situace je zachycena na následujícím obrázku:

Na rozdíl od situace s prefixem délky 64 bitů, kterou jsme si popisovali v předchozím díle, jsou záškodníkovy pakety zneškodněny hned na prvním směrovači, a to prostřednictvím tzv. blackhole směrovacího záznamu.

Používání prefixů v jiné délce než 64 bitů je jedno z dalších velice kontroverzních témat, rozdělující IPv6 komunitu. Část komunity považuje vyčlenění 64 bitů pro koncové sítě za velké plýtvání a uvítala by volnější pravidla, druhá skupina v tom vidí přebírání negativních vlastností protokolu IPv4 a dodává, že IPv6 adres máme dostatek, tedy si můžeme dovolit takto "plýtvat" a použít všude prefix délky 64 bitů.

Statické záznamy v cache sousedů

Pro kritické aplikace běžící například na serverech v datových centrech, může být jistým řešením zavedení statických záznamů do cache sousedů. Tím je zaručeno, že v případě, kdy útočník zajistí vyčerpání cache sousedů, budou v ní stále obsaženy námi zařazené statické záznamy. Toto řešení je ovšem vykoupeno neskutečnou pracností v podobě vytváření a udržování statických záznamů a v praxi tedy použitelné pouze ve velmi specifických prostředích. Je také nutné, aby koncové zařízení využívalo striktně statickou konfiguraci IPv6 adres na svých rozhraních. Vytvoření statického záznamu u platformy HP používající firmware Comware může vypadat například takto:

[SW]ipv6 neighbor 2001:67C:1220::10 0050-5694-b2e0 interface 
Vlan-interface 1

[SW]display ipv6 neighbors 2001:67C:1220::10 verbose
                 Type: S-Static    D-Dynamic

IPv6 Address     : 2001:67C:1220::10
Link-layer       : 0050-5694-b2e0      VID : N/A    Interface   : N/A
State            : INCMP               Type: S      Age         : -
Vpn-instance     : [No Vrf]

U zařízení Cisco lze stejného efektu dosáhnout zadáním následujících příkazů.

Switch(config)#ipv6 neighbor 2001:67C:1220::10 vlan 1 0050.5694.b2e0

Switch#sh ipv6 neighbors
IPv6 Address                    Age Link-layer Addr State Interface
2001:67C:1220::10                 - 0050.5694.b2e0  REACH Vl1

Vytváření takových statických záznamů není nezbytně nutné pro všechna zařízení v příslušné síti. Záznamy můžeme vytvořit pouze pro kritická zařízení a ostatní ponechat v režimu automatického učení prostřednictvím Neighbor Discovery.

Filtrace podle adresy

Další možností, jak se bránit vzdálené formě útoku, je filtrace adres. Logicky se nabízí filtrace podle zdrojové adresy útočníka v době útoku. Zde lze nicméně předpokládat, že útočník bude jednak vést útok z více míst, a také, že zdrojová adresa v paketech bude nejspíše podvržená. Nabízí se tedy přístup přesně obrácený - propouštět provoz pouze pro cílové adresy, o kterých víme, že na nich jsou skutečně umístěná zařízení s IPv6 adresou.

Připomeňme si, že podstatou útoku je zasílání paketů do cílové sítě na náhodně generováné IPv6 adresy. Princip obrany je pak velice jednoduchý - pakety, u kterých víme, že směřují na neexistující IPv6 adresy, zahodíme hned na vstupu. Nevznikne tak důvod provádět operaci objevování sousedů a tedy nedojde k zaplnění tabulky sousedů ani k případnému přetížení CPU směrovače.

Pro realizaci obrany tohoto typu je možné využití paketových filtrů (ACL), které má většina zařízení implementována přímo v hardware. V základní podobě si tedy můžeme vystačit například s takovýmto jednoduchým filtrem, který bude aplikován na vstupu vnějšího rozhraní směrovače:

acl ipv6 number 3000 name nd-filter
 rule 0 permit ipv6 destination 2001:DB8::A/128
 rule 10 deny ipv6

V praxi si však s tímto jednoduchým filtrem nevystačíme, protože v koncové sítí bude zřejmě více aktivních IPv6 adres. Tím se může údržba takového filtru stát poměrně složitou záležitostí. Jistého zjednodušení lze dosáhnout například tím, že vstupní filtr je definován tak, aby propouštěl pakety s cílovou adresou patřící do společně popsatelného prefixu například délky 120 bitů. Tímto se vyhneme zařazování záznamu do ACL s každým nově připojeným zařízením. Stejně jako v předchozím případě platí, že metoda je aplikovatelná pouze na staticky přidělené adresy a tedy použitelná maximálně pro ochranu sítí, ve kterých jsou připojené servery.

Upozornění: Možná vás napadlo, že by se problém dal pojmout komplexněji. Proč rovnou nezařadit do filtru i cílové porty příslušné služby, když už jednou provádíme filtraci na cílovou adresu? Pokud například víme, že na příslušné adrese běží pouze web server na portu 80, tak není žádný důvod, proč by měly být dostupné další porty. Zde si však dovolíme opět upozornit na problém filtrace paketů s rozšířenými hlavičkami. Pokud zařadíme filtraci pro příslušný TCP/UDP port, donutíme zařízení provádět inspekci obsahu i na vyšších protokolových vrstvách, čímž potenciálnímu útočníkovi umožníme provést útok, ať už s využitím zřetězení rozšířených hlaviček nebo hlavičky fragmentace, jak jsme popisovali v díle Trable s hlavičkami.

IPv6 destination guard

Jakousi automatizovanou podobu předchozího způsobu představuje technika jménem Destination guard. Princip je velice jednoduchý. Pakliže na směrovač dorazí paket s cílovou adresou, kterou cache sousedů neobsahuje, je takový paket ihned zahozen. Technika má jedno úskalí a tím je počáteční naplnění cache sousedů. K tomuto se právě využívá vazební tabulky (neighbor binding database), kterou jsme popisovali v druhém díle Zkrocení zlých směrovačů. Je tedy součástí technik, které se souhrně nazývají First-Hop-Security a bez aplikace těchto technik, a tedy i omezení z nich vyplývajících, nebude fungovat. Praktickou demonstraci ukazující použití této techniky je možné shlédnout na krátkém videu.

Omezení počtu IPv6 adres v cache sousedů na rozhraní

Doposud jsme si popisovali možné způsoby ochrany, které jsou použitelné pro sítě, ve kterých jsou umístěné servery. Taková koncová síť je z podstaty věci mnohem více chráněná proti lokálním útokům a tedy má smysl věnovat pozornost spíše obraně proti vzdálenému vyčerpání cache sousedů. Odlišná situace ovšem nastává v sítí, kde jsou umístěná koncová zařízení běžných uživatelů. Zde je koncová síť přístupná prakticky každému, kdo se do ni připojí a útočník má mnohem lepší podmínky pro vedení lokálního útoku na cache sousedů.

Některé platformy umožňují nastavit omezení počtu záznamů v cache sousedů příslušející jednomu rozhraní. Tato volba nám zaručí, že útočník v jedné síti nevyčerpá na směrovači veškerou kapacitu cache sousedů. Vlastní síťový segment je útokem sice postižen, ale nejsou ohroženy ostatní sítě na stejném směrovači.

Na platformě Cisco lze k tomu použít následující příkaz, který omezí počet záznamů na každém logickém rozhraní na 1000.:

Switch(config)# ipv6 nd cache interface-limit 1000

U platformy HP lze podobný limit nastavit na jednotlivých rozhraních následovně.

[SW]interface vlan 210
[SW-Vlan-interface210] ipv6 neighbors max-learning-num 1000

Omezení doby záznamu v cache sousedů

Poměrně důležitým krokem, ke kterému budete muset v některých případech sáhnout, je zkrácení doby, po kterou je záznam v cache sousedů držen. Jak jsme si řekli v předchozím díle, mnohá zařízení se na WiFi sítí chovají tak, že si s každou reautentizací vygenerují novou IPv6 adresu. Tímto může dojít poměrně k rychlému zaplnění tabulky sousedů. Záznamy, které se takto vygenerovaly, se vztahují k adresám, které se ale reálně již nepoužívají a tedy pouze zabírají místo. Účinným řešením tohoto problému je právě snížení doby, po kterou je záznam v cache sousedů uchován.

Snížení doby platnosti záznamu může posloužit rovněž jako obrana proti cílenému útoku. Víceméně pak s útočníkem hrajeme hru na přetahovanou, jejíž cílem je uvolňovat podvržené záznamy rychleji, než útočník stíhá vytvářet nové. Tuto strategii používá například Linuxové jádro nebo novější verze systému Windows, kde ve výchozí konfiguraci je záznam v cache sousedu udržován pouhých 70 sekund, bez ohledu na to, zda je příslušná adresa stále na sítí dostupná či nikoliv. Jak to funguje v praxi. Za normálních okolností, resp. dle RFC 4861 by operační systém měl před vyřazením adresy nejdříve provést ověření její dostupnosti (Neighbor Unreachability Detection - NUD). Teprve až na základě výsledku tohoto testu provést případné vyřazení adresy z cache sousedů. Oba zmíněné operační systémy věc řeší jednoduše. Ověření dostupnosti (NUD) zkrátka neprovádějí a příslušný záznam rovnou vyřadí. V minulém díle jsme zmínili, že linuxové systémy mají ve výchozím stavu cache sousedů omezenou na 1024 záznamů. Díky rychlému uvolňování záznamů nejsou v cache sousedů adresy všech zařízení v podsítích, ale pouze těch, které s uzlem komunikovaly během posledních 70 vteřin. V praxi tedy limit v podobě 1024 záznamů není tak omezující.

Přístup rychlého uvolňování není ovšem zcela bezproblémový. Jeho důsledkem je nutnost mnohem častěji provádět zjištění mapování mezi IPv6 a linkovými adresami. To v některých případech může vést na pomalejší odezvu v případě navazování nových spojení a zejména pak zvýšený provoz na úrovni signalizačních protokolů - tedy zejména multicast provozu, který je značně problematický zejména ve WiFi sítích, jak jsme si ostatně popisovali v díle Trable s multicastem. Přístup tedy představuje jakési vyhánění čerta ďáblem, který je rovněž v rozporu s původním záměrem, jak jej definuje RFC 4861 a tedy i kontroverzní z pohledu skalních zastánců bezpodmínečného dodržování RFC. I přes tyto vady na kráse se výrobci operačních systému přiklánějí spíše k variantě rychlejšího uvolňování záznamů než k implementaci celého algoritmu NUD.

U aktivních prvků je ovšem situace jiná. Zde spíše převládá strategie pozvolnějšího uvolňování záznamů. Na většině zařízení se jedná o konfigurovatelný parametr, který je možné za běhu modifikovat. Zde opět platí, že každý výrobce k problému přistupuje trošku jinak. Na zařízeních Cisco je možné nastavit dobu expirace záznamu v sekundách příkazem:

SW-Cisco(config)# ipv6 nd cache expire <čas v sekundách>

Na zařízeních HP používající firmware Comware lze použit příkaz:

[SW-Comware]ipv6 neighbor stale-aging <čas v hodinách>

Zde je trochu omezení v tom, že se čas nastavuje v hodinách a minimální doba expirace je 1 hodina. Úplně jinak je to na zařízeních stejného výrobce u řady Procurve, kde se čas nastavuje společně s dobou expirace záznamu v tabulce ARP. Tentokrát se čas nastavuje v minutách.

SW-Procurve(config)# ip arp-age <čas v minutách>

Stejně jako způsoby konfigurace se také liší i použité výchozí hodnoty - od několika desítek minut až po dny. Parametry konkrétního zařízení je tedy třeba vždy konzultovat s dokumentací nebo ověřit experimentálně.

Tímto jsme vyčerpali základní výčet obranných prostředků proti útokům vedeným na vyčerpání cache sousedů. Vzhledem k tomu, že se jedná o celkem složitou oblast, nabízíme pro přehlednost tabulku se souhrnem jednotlivých obranných technik a vhodnosti jejich použití:

Technika Eliminace lokálního útoku Eliminace vzdáleného útoku Nevýhoda
Zvětšení délky prefixu NE ANO Nelze použít s autokonfigurací
Statické záznamy v cache sousedů ANO ANO Náročný management
Filtrace podle adresy NE ANO Vyžaduje vytváření ACL. Vhodné pouze pro servery.
Omezení počtu IPv6 adres na rozhraní částečně NE Pouze minimalizuje dosah útoku
Omezení doby záznamu v cache sousedů částečně částečně Zmírňovací technika, může vést na vyšší zátěž CPU

Závěr

Dnes jsme si ukázali některé základní techniky, které můžeme použít, ať už pro eliminaci útoků na cache sousedů, nebo alespoň pro zmírnění jejich následků. V současné době, kdy je IPv6 protokol zpravidla implementován v režimu dual-stack, tj. společně s IPv4, nemusí být důsledky útoků na cache sousedů až tak fatální. Řada prohlížečů podporuje automatické přepnutí na protokol IPv4 v případě, že je protokol IPv6 nedostupný. Případné problémy s cache sousedů tedy nemusí být pro uživatele na první pohled viditelné. Automatické přepnutí ovšem funguje většinou pouze pro prohlížeč a už ne například pro emailového klienta, či jiné aplikace využívající IPv6. Výrazně horší situace také nastane v případě, kdy je síť implementována jako IPv6 only, například s využitím DNS64/NAT64, jak před časem popisoval Ondřej Caletka. V takovém případě uživatel pocítí jakýkoliv problém na IPv6 protokolu okamžitě.

Našli jste v článku chybu?

19. 3. 2015 10:41

Vzhledem k tomu, že jsem byl v závěru zmíněn, musím reagovat :)

Podle mého názoru je chování systému na IPv6-only síti mnohem lepší − prostě to nefunguje a je to potřeba opravit. Uživatelé nezahrnují technickou podporu nejasnými stížnostmi jako že „Youtube videa se načítají pomalu“, nebo „Firefox funguje, ale Thunderbird ne“ a technik řešící problém jej velice rychle najde, protože projde jedinou možnou cestu od uživatele.

V dual-stack světě je například i pro zkušeného administrátora velký pr…

23. 3. 2015 13:14

Matěj Grégr (neregistrovaný)

Hezký den,
ano, máte pravdu. Chyby se musí řešit jinými postupy, než principiálně stejné chyby u IPv4. Co se týče chybějícího odkazování na BCP, tak to je to dané tím, že BCP pro IPv6 zatím neexistují. Resp. neexistují oficiální BCP, které by reprezentovaly nějaký konsensus. Tedy není se moc na co odkazovat.

M.


Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

Lupa.cz: Kdo pochopí vtip, může jít do ČT vyvíjet weby

Kdo pochopí vtip, může jít do ČT vyvíjet weby

Podnikatel.cz: E-Ježíšek si i letos zařádí. Nákupy od 2 do 5 tisíc

E-Ježíšek si i letos zařádí. Nákupy od 2 do 5 tisíc

120na80.cz: Pánové, pečujte o svoje přirození a prostatu

Pánové, pečujte o svoje přirození a prostatu

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

Přehledná titulka, průvodci, responzivita

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

Jsou čajové sáčky toxické?

Vitalia.cz: Dáte si jahody s plísní?

Dáte si jahody s plísní?

Měšec.cz: U levneELEKTRO.cz už reklamaci nevyřídíte

U levneELEKTRO.cz už reklamaci nevyřídíte

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání

Měšec.cz: Jak levně odeslat balík přímo z domu?

Jak levně odeslat balík přímo z domu?

Root.cz: Vypadl Google a rozbilo se toho hodně

Vypadl Google a rozbilo se toho hodně

Vitalia.cz: Znáte „černý detox“? Ani to nezkoušejte

Znáte „černý detox“? Ani to nezkoušejte

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla

DigiZone.cz: Sony KD-55XD8005 s Android 6.0

Sony KD-55XD8005 s Android 6.0

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

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

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

Vitalia.cz: Říká amoleta - a myslí palačinka

Říká amoleta - a myslí palačinka

Lupa.cz: Co se dá měřit přes Internet věcí

Co se dá měřit přes Internet věcí

Měšec.cz: Jak vymáhat výživné zadarmo?

Jak vymáhat výživné zadarmo?

DigiZone.cz: Recenze Westworld: zavraždit a...

Recenze Westworld: zavraždit a...