Bezpečné IPv6: když dojde keš

Dříve než si popíšeme vlastní útoky a pokusíme se najít způsoby jejich eliminace se podíváme, co je to cache sousedů (Neighbor Cache) a jak v ní záznamy vůbec vznikají. Cache sousedů je datová struktura, kterou si udržuje každý IPv6 uzel. Obsahuje, mimo jiné, dvě klíčové položky, a to IPv6 adresu a jí odpovídající linkovou (MAC) adresu. Pro zjištění tohoto mapování mezi IPv6 a MAC adresami se používá dvojice zpráv Výzva sousedovi (Neighbor Solicitation) a Ohlášení souseda (Neighbor Advertisement), které jsou součástí protokolu NDP, se kterým jsme se už potkali v předchozích dílech seriálu. V naprosté většině případů vznikají záznamy v cache sousedů automaticky a z pohledu komunikující aplikace zcela transparentně.

Připomeňme si, k čemu toto mapování vůbec potřebujeme. Pokud chce IPv4 nebo IPv6 uzel komunikovat s jiným uzlem, musí si v první řadě zodpovědět na následující otázky.

1. Můžu druhý uzel kontaktovat přímo? Nachází se ve stejné L2 síti jako já?
2. Pokud ne, znám směrovač, přes který mu můžu data poslat?

Ve světě IPv4 se zařízení všechny potřebné informace dozvědělo statickou konfigurací, nebo protokolem DHCPv4. Zejména pak IPv4 adresu, prefix sítě a výchozí bránu. Zjištění, jestli se adresa dalšího zařízení nachází ve stejné síti, se pak určí vcelku jednoduše tak, že se použije binární operace AND a musí platit, že zdrojová-IP AND prefix sítě == cílová-IP AND prefix sítě. Pokud rovnice platí, lze zařízení kontaktovat přímo a pro zjištění jeho linkové adresy se použije protokol ARP. Pokud rovnice neplatí, zařízení, které chceme kontaktovat, se nachází v jiné síti. Pakety se tedy pošlou na adresu výchozí brány, jejíž linkovou adresu zjistí zařízení také pomocí ARP.

Protokol IPv6 na to jde nicméně trochu jinak. Rozděluje zařízení na ta, která se nachází na stejné lince (on-link) a ostatní (off-link). Pod pojmem linka si zde můžete představit jakékoliv médium, přes které se dá komunikovat na linkové úrovni - například Ethernet nebo PPP.

Jak se určí, že jsou zařízení připojená na stejné lince? Tuto informaci zařízením sdělí směrovač ve své zprávě Ohlášení směrovače. Jak jsme si popsali v prvním díle seriálu, v této zprávě se zasílá informace o IPv6 prefixu, který se v síti používá, a ze kterého si zařízení mají vygenerovat IPv6 adresu. Pokud je pro daný IPv6 prefix nastaven příznak on-link, zařízení připojená do dané sítě (s daným prefixem) spolu mohou komunikovat přímo. Tedy pomocí zpráv Výzva sousedovi a Ohlášení souseda zjistit mapování mezi svými IPv6 a linkovými adresami. Pokud u prefixu příznak nastaven není, předpokládá se, že zařízení je off-link. Provoz pak musí zařízení zaslat na výchozí bránu.

Pokud byste dumali nad tím, kdy má smysl do sítě šířit IPv6 prefix a zakázat komunikaci zařízení mezi sebou, tak to dává smysl třeba v NBMA (Non-broadcast multiple-access) sítích, kde komunikace probíhá vždy přes centrální směrovač. Tento koncept lze také teoreticky použít pro separaci klientů v lokální síti - provoz musí totiž jít vždy přes směrovač. Zde je nicméně problém v implementacích, kdy ne všechny na tento příznak reagují správně. Zájemce o podrobnější informace lze odkázat na RFC 5942 a RFC 4943.

My se nyní podíváme na ty nejklasičtější varianty komunikace, které můžeme v IPv6 síti dnes nalézt. Když spolu chtějí komunikovat dvě zařízení na stejné lince, nebo chcete-li, ve stejné síti, a když zařízení posílá data do Internetu.

Při komunikaci v rámci stejné linky odesílající uzel zašle do sítě zprávu Výzva sousedovi. Pokud vše funguje jak má, cílový uzel zprávu zpracuje a tázajícímu uzlu odpoví prostřednictvím zprávy Ohlášení souseda. Kromě dotazované IPv6 adresy do odpovědi přibalí ještě svou adresu linkové vrstvy (MAC adresu). Na základě této zprávy si tázající uzel zařadí příslušnou IPv6 adresu a jí odpovídající MAC adresu do cache sousedů, kde si je ponechá po určitý čas.

V případě, že chce uzel zaslat data mimo svou síť, vyhledá si podle směrovací tabulky IPv6 adresu odpovídajícího směrovače nebo výchozí brány a dále postupuje stejným způsobem jak v předchozím případě. Výsledkem je, že se v cache sousedů objeví IPv6 a MAC adresa směrovače. Na následujícím obrázku je zachycen právě takový průběh komunikace koncového zařízení v případě, že cache sousedů je na samotném zařízení i na připojujícím směrovači prázdná. Na koncovém zařízení je spuštěn příkaz ping6 www.cesnet.cz. Před vlastním vysláním ICMPv6 paketu Echo Request musí ale ještě proběhnout převod doménového jména na IPv6 adresu (pakety č. 3 a 4). Tomu však předchází zjišťování linkové adresy směrovače (pakety 1 a 2). Pro pakety s odpovědí již směrovač nemusí zjišťovat linkovou adresu cílového uzlu, protože všechny informace, které potřebuje, již získal z předchozí komunikace. Pro jistotu však po několika vteřinách provede ověření, zda je příslušná IPv6 adresa skutečně dostupná (pakety 7 a 8).

V případě, že zjišťování linkové adresy sousedního uzlu nebo směrovače neproběhne úspěšně do určitého času, je do tabulky sousedů uložen záznam s příznakem, že uvedený cílový uzel nebo směrovač je nedostupný.

Pokud bychom hledali obdobný mechanismus v IPv4 tak odpovídajícím ekvivalentem cache sousedů je ARP tabulka a zprávy Neighbor Solicitation a Neighbor Advertisement odpovídají zprávám ARP Request a ARP Reply protokolu ARP. Je zde však několik odlišností. První jsme již zmínili - rozdělení na on-link, off-link. Mezi další odlišnosti patří, že zprávy výzva sousedovi nejsou posílány na broadcast, ale zasílány do multicast skupiny a že samotný protokol NDP je součásti ICMPv6 a nikoliv samostatným protokolem nad linkovou vrstvou, jak tomu bylo v případě protokolu ARP. Pro názornost zachycují následující obrázky obsah části tabulky ARP a cache sousedů na tomtéž zařízení.

U ARP tabulky vidíme mapování mezi IPv4 adresou a MAC adresou, na jakém rozhraní, případně v jaké VLAN je daná IP naučena a jak dlouho již v tabulce je. Cache sousedů u protokolu IPv6 vypadá o trochu jinak.

Vidíme, že většina informací zůstala zachována. Přibylo ale další políčko, které popisuje stav dané adresy. Z výpisu vidíme, že se adresy v cache mohou nacházet v několika stavech - dosažitelná (Reachable), prošlá (Stale), odložená (Delay) a testovaná (Probe).

Pokud daná adresa odeslala v poslední době nějaká data, je brána jako dosažitelná. Pokud vyprší doba, po kterou lze adresu považovat za dosažitelnou, adresa přejde do stavu prošlá, nicméně v cache sousedů stále zůstává. Pokud je adresa ve stavu prošlá a je třeba ji odeslat nějaká data, data se odešlou, adresa přejde do stavu odložená a čeká se, zda dosažitelnost nepotvrdí vyšší vrstva. Pokud ne, adresa přejde do stavu testovaná a směrovač se aktivně snaží dosažitelnost ověřit.

Detailně je celý proces objevování sousedů popsán v knize Pavla Satrapy.

Seznámili jsme se s cache sousedů - k čemu je a jak se plní. Nyní se podíváme, jak může být zneužitá k záškodnické činnosti.

Lokální útok

První varianta útoku předpokládá, že je útočník ve stejné podsíti jako oběť. Útočník má v tomto případě mnohem snažší přístup k signalizačním protokolům - zejména k mechanismu objevování sousedů. Princip útoku lze jednoduše popsat takto: Postupným generováním dotazů a podvržených odpovědi vytvoříme některému z okolních uzlů (zpravidla připojujícímu směrovači) iluzi, že v síti je připojeno velké množství koncových zařízení. To způsobí, že uzel vyčerpá veškeré zdroje určené pro cache sousedů (bude ji mít zaplněnou) a to v konečném důsledku způsobí, že do této tabulky nebude možné zařazovat adresy nově připojených zařízení. V úplně základní podobě si vystačíme s velice jednoduchou variantou útoku, která využívá prostého generování zpráv Výzva sousedovi. V případě, že zařízení obdrží zprávu Výzva sousedovi, zařadí si příslušnou adresu do tabulky sousedů ve stavu DELAY (odložená) a počká, zda vyšší vrstva provede skutečné ověření dosažitelnosti příslušné adresy.

Pro simulaci útoku lze použít nástroj flood_solicitate6 z balíku THC-IPV6, který zajistí generování zpráv Výzva sousedovi.

[root@test8 thc-ipv6-2.5]# ./flood_solicitate6 -X eth1
FE80::D27E:28FF:FE75:B3B4
Starting to flood network with neighbor solicitations on eth1 (Press
Control-C to end, a dot is printed for every 1000 packets):
.....................................................................
.....................................................................
..

Jak probíhá vlastní výměna paketů je zachyceno na následujícím obrázku:

Všechy zprávy jsou zasílány na cílovou adresu ff02::1, tedy “broadcast” (nebo chcete-li multicastová skupina, kterou musejí přijímat všechny IPv6 uzly). Každý paket obsahuje nahodile vygenerovanou zdrojovou IPv6 a MAC adresu, čímž je zajištěno, že s každým paketem teoreticky vznikne nový záznam v cache sousedů. Znalci IPv6 mohou namítnout, že zpráva Výzva sousedovi se má správně zasílat na multicastovou adresu uzlu vytvořenou speciálně pro tento účel, jak jsme si popisovali v předchozím díle. Většina implementací IPv6 však neprovádí žádnou následnou kontrolu a takovou zprávu normálně zpracují. Tímto útokem lze tedy zasáhnout všechna zařízení v lokální síti.

Tímto útokem na většině zařízení ovšem nedojde k zaplnění cache sousedů. Je to způsobeno tím, že záznamy zůstanou ve stavu DELAY (odložená) případně PROBE (testovaná). U záznamů v tomto stavu operační systém po určitém čase, zpravidla po několika desítkách vteřin, provede prověření dostupnosti sousedů zasláním výzvy. Vzhledem k tomu, že na takovou výzvu nedorazí odpověď, příslušný záznam je vyřazen. Vlastní útok se tedy neprojeví v samotném znepřístupnění služeb po protokolu IPv6, ale pouze zvýšenou zátěží všech zařízení připojených v příslušném síťovém segmentu. Následující obrázek zachycuje histogram se zátěží L3 přepínače, který je právě pod výše popsaným útokem. Po spuštění útoku cca v desáté minutě se zvýší zátěž CPU z klidových 5 % cca na 35-40 %.

Lokální útok v rafinovanější podobě

Tímto však útočníkovy možnosti nejsou vyčerpány. Značně zákeřnější formou útoku je varianta, kdy se útočník pokusí přesvědčit zařízení, že vygenerovaná adresa je opravdu dostupná, tedy, že záznam je ve stavu REACHABLE (dosažitelná) nebo STALE (prošlá). Tento stav indikuje, že dostupnost příslušné adresy v cache sousedů byla již ověřená. Tímto je zaručeno, že záznam zůstane v tabulce po hodně dlouhou dobu, v praxi zpravidla řádově hodiny. Průběh vlastního útoku je zachycen na následujícím obrázku:

Útočník zašle směrovači (2001:db8::a) zprávu, například ICMPv6 ECHO Request, kde na pozici zdrojové adresy vloží například adresu 2001:db8::b. Není nezbytně nutné, aby útočník komunikoval přímo se směrovačem, na který hodlá útok vést. Obecně postačí jakékoliv zařízení za směrovačem, které dokáže vygenerovat paket s odpovědí. V našem případě se ovšem přímo směrovač bude pokoušet odpovědět zprávou ICMPv6 ECHO Reply. Dříve než bude schopen odeslat paket s odpovědí, musí zjistit linkovou (MAC) adresu souseda a tu si zařadit do cache sousedů. Vytvoří si tedy dočasný záznam pro adresu 2001:db8::b, kde ještě nemá vyplněnou MAC adresu a odešle Výzvu sousedovi. Útočník na tuto zprávu odpoví Ohlášením souseda. Na základě této výměny zpráv si směrovač vloží do cache sousedů informaci, že k IPv6 adrese 2001:db8::b přísluší linková adresa aa:bb:cc:dd:ee:ff a poznačí si, že tato adresa je dosažitelná (REACH). Tímto je zajištěno, že záznam bude u většiny zařízení ponechán v cache sousedů po výrazně delší dobu. V dalším kroku útočník celou operaci opakuje pro adresu 2001:db8::c, 2001:db8::d, atd.

Pro realizaci takového útoku není potřeba žádných složitých prostředků a lze jej prakticky realizovat na každém linuxovém systému s využitím základních příkazů, tj. ip (ifconfig) a ping6 například takovýmto způsobem:

# ip address add 2001:db8::b/64 dev eth1
# ping6  -I 2001:db8::b -c 1 2001:db8::a
# ip address add 2001:db8::c/64 dev eth1
# ping6  -I 2001:db8::c -c 1 2001:db8::a
# ip address add 2001:db8::d/64 dev eth1
# ping6  -I 2001:db8::d -c 1 2001:db8::a

Na směrovači pak vzniknou následující záznamy:

[SW]display ipv6 neighbors vlan 777
           Type: S-Static   D-Dynamic
IPv6 Address                    Link-layer      VID   Interface      State  T  Age
FE80::250:56FF:FE94:B2E0        0050-5694-b2e0  777   GE1/0/2        DELAY  D  129
2001:DB8::D                     0050-5694-b2e0  777   GE1/0/2        REACH  D  9
2001:DB8::C                     0050-5694-b2e0  777   GE1/0/2        REACH  D  9
2001:DB8::B                     0050-5694-b2e0  777   GE1/0/2        REACH  D  9

Praktické důsledky útoku

Jaké může mít takový útok praktické důsledky? Vlivem ponechání příslušného záznamu v tabulce se cache sousedů postupně zaplní až do té míry, kdy do ní není možné přidávat další záznamy. Pokud je tento stav vyvolán na připojujícím směrovači, tak v příslušném síťovém segmentu již nebude možné zařadit do cache sousedů záznam pro toto zařízení a tímto se stane IPv6 konektivita pro příslušné zařízení nedostupná. Pokud je navíc na příslušném směrovači, nebo alespoň slotu směrovače, paměť pro cache sousedů sdílená mezi všemi rozhraními (což ve většině případů je), tak jsou současně stejným způsobem postiženy i segmenty připojené na rozhraní sdílející tuto paměť. Pokud by se někdo domníval, že dostatečná velikost cache sousedů, která by byla schopná pojmout všechny možné záznamy, je pouhou implementační drobností, tak jenom připomínáme, že paměť pro cache by musela pojmout více než 2⁶⁴ záznamů, což i v minimalistické podobě mnohonásobně přesahuje řády PB. Je tedy zřejmé, že každé zařízení musí mít nějaký konečný limit počtu záznamů v cache sousedů a musí implementovat odpovídající strategii, jak se zachovat v případě, že je tento počet záznamů překročen.

Chování jednotlivých systémů a zařízení se pochopitelně liší výrobce od výrobce. Na několika příkladech si ukážeme, jak diametrálně se mohou jednotlivé implementace lišit. Například L3 přepínač HP řady 5800 při počtu záznamů 8192 oznámí, případně zašle SNMP trap, že cache sousedů je plná a tímto je pro něj věc vyřízená. Všechna nově připojená IPv6 zařízení mají prostě smůlu:

<SW>display ipv6 neighbors all count
#May 7 14:30:19:562 2000 SW TPMB/4/ND TABLE FULL:
1.3.6.1.4.1.25506.2.38.1.5.4.1: Neighbor table is full and number
of items is 8192.

Total entry(ies):  8192

U L3 přepínače Cisco 3560 je průběh trochu jiný. Při počtu 2000 záznamů L3 přepínač poinformuje o tom, že další záznamy se nevejdou do TCAM a že pakety mohou být zpracovány v software.

Switch#
*Mar 1 00:24:13.393: %PLATFORM_IPv6_UCAST-6-PREFIX:  One or more, more specific
prefixes could not be programmed into TCAM and are being covered by a less
specific prefix, and the packets may be software forwarded

Celkem logicky se začne postupně zvyšovat vytížení CPU a při cca 20 000 záznamech začne docházet k chybám v alokacích, dojde k deaktivaci CEF (Cisco Express Forwarding) a L3 přepínač je výkonostně v koncích.

Switch#
*Mar 1 00:27:57.209: %SYS-2-MALLOCFAIL: Memory allocation of 65536 bytes failed from
0x2D84A28, alignment 85 Pool: Processor  Free: 111680  Cause: Memory
fragmentation6 Alternate Pool: None  Free: 0  Cause: No Alternate pool
7 -Process= "IPv6 Input", ipl= 0, pid= 3328 -Traceback= 2025520z
2D6A00Cz 2D70BCCz 2D84A2Cz 330B7D8z 330B93Cz 26E8EF0z 26B610Cz 26705C8z
2670768z 273FFA0z 275F0ACz 23C1870z 23C1E50z 23C2258z 23C416Cz9
*Mar 1 00:27:57.209: %COMMON_FIB-3-NOMEM: Memory allocation failure for fib entry
insertion in IPv6 CEF [0x0265A098] (fatal) (0 subsequent failures).10
*Mar 1 00:27:57.209: %COMMON_FIB-4-DISABLING: IPv6 CEF is being disabled due to a
fatal error.

Switch#sh processes cpu history

100 **********************************************************
90  **********************************************************
80  **********************************************************
70  **********************************************************
60  **********************************************************
50  **********************************************************
40  **********************************************************
30  **********************************************************
20  **********************************************************
10  **********************************************************
 0....5....1....1....2....2....3....3....4....4....5....5....6
           0    5    0    5    0    5    0    5    0    5    0
               CPU% per second (last 60 seconds)

Pokud se podívame na situaci u operačních systémů, tak situace je o něco lepší. Je to celkém logické. Operační systém má zpravidla k dispozici výkonnější procesor a není omezen specializovaným hardware jako u směrovačů a přepínačů. Není tedy problém, aby cache sousedů v takovém případě obsahovala například stovky tisíc záznamů. Implementace se ale liší systém od systému. Zatímco FreeBSD žádný limit pro počet záznamů nemá, jiné operační systémy (Windows, Linux, MAC OS X) mají typicky nastavený maximální počet záznamů, který je možné do cache sousedů uložit. Například Linux má ve výchozím stavu nastaven limit na hodnotu 1024 a je ovlivnitelný parametrem sysctl:

net.ipv6.neigh.default.gc_thresh3

Pokud by se vám 1024 záznamů jevilo jako poměrně malé číslo i pro běžný provoz, tak v praxi zřejmě nebude představovat problém. Je to dáno tím, že Linuxové systémy, stejně jako Windows, uplatňují upravenou strategii uvolňování záznamů v tabulce sousedů. Podroběji se této strategii budeme věnovat v příštím díle.

Asi není překvapením, že každá platforma reaguje trošku jinak a chování se mezi jednotlivými výrobci, operačními systémy či dokonce verzemi firmware liší. Poněkud nepříjemné je, že odhalení přesného chování a nalezení limitů u jednotlivých zařízení je zpravidla věcí čistě experimentální. Podle našich zkušeností, často jedinou cestou, jak se k objektivní informaci o počtu záznamů v cache sousedů dostat, je podrobit zařízení testům v laboratoři.

Poznámka: Ačkoliv se v článcích snažíme vždy v maximálně otevřené podobě demonstrovat realizace útoků, tak v tomto případě jsme se rozhodli udělat výjimku. Na jednu stranu by postup pro zaplnění cache sousedů byl jistě užitečný pro ty, kteří si případně chtějí v testovacím prostředí oveřit limity svých zařízení. Zkušenosti nám však ukázaly, že pro řadu zařízení jsou důsledky zaplnění cache sousedů poměrně fatální a to s přesahem na chod IPv4 infrastruktury. Z toho důvodu jsme se v tomto případě rozhodli přesný postup zcela záměrně nezveřejňovat.

Vzdálený útok

Trochu jinou variantou útoku na vyčerpání cache sousedů je jeho vzdálená varianta. V tomto případě se útočník může vyskytovat kdekoliv na Internetu. Princip útoku se dá zjednodušeně popsat takto: Postupným zasíláním paketů do cílové sítě na různé cílové adresy donutíme hraniční směrovač příslušné sítě vygenerovat zprávu Výzva sousedovi a zařadit si do cache sousedů záznam o nedostupnosti cílové adresy. Tím může dojít k její vyčerpání, ke zvýšení zátěže směrovače a nárustu objemu komunikace signalizačních protokolů a multicast provozu v koncové síti.

V praxi však tento útok zpravidla vede ke stejným výsledkům, jako první forma dříve popisovaného lokálního útoku. Nedojde tedy k faktickému zaplnění celé cache sousedů, ale ke značně zvýšené zátěži procesoru. Na útoku jsou ovšem nepříjemné dvě věci. Jednak může být proveden z jakéhokoliv místa na Internetu a navíc, cílem útoku nemusí být nutně pouze koncová síť připojující servery nebo uživatele. Obětí může být například kterákoliv propojovací síť spojující jeden nebo více směrovačů. Tímto se útok řadí do pozice, kdy jej lze zneužít nejen pro útočení na koncové systémy, ale i na samotnou infrastrukturu Internetu, tj. například na spojovací sítě mezi směrovači, nebo peerovací sítě v propojovacích uzlech (IXP). Na následujícím obrázku vidíme, jak může taková situace vypadat.

Dva směrovače jsou propojené sítí s prefixem 2001:db8::/64. Pokud útočník zašle libovolný paket na nějakou cílovou adresu z této sítě, musí směrovač vyvolat proces vyhledání souseda. K operaci využije své CPU a vyšle do sítě zprávu Výzva sousedovi. Druhý směrovač musí tuto zprávu nějak zpracovat, protože jen tak zjistí, že se jej netýká. K tomu opět využije CPU, takže útočník může každým paketem “obtěžovat” hned dva či více směrovačů najednou.

Útok bez útočníka

Pokud směrovač ve vaší síti zahlásí informaci o vyčerpané cache sousedů, či se začne chovat neobvykle, nemusí to nutně znamenat, že se ve vaší síti nachází záškodník. Tento jev může nastat i za normálních okolností a napomáhá tomu několik nových vlastnosti protokolu IPv6:

• Každé IPv6 zařízení má nakonfigurovánou kromě globální IPv6 adresy ještě dalších několik adres jako například link-local nebo unique-local. Minimálně je třeba počítat alespoň se dvěma IPv6 adresami na každé zařízení.
• V případě, že zařízení využívá Privacy Extensions dle RFC 4941 nebo RFC 3041, je nutno počítat s tím, že zařízení si bude průběžně generovat na rozhraní nové IPv6 adresy, přičemž dříve používané adresy si ponechá po nějakou dobu stále ještě dostupné. Skutečnou lahůdku pak představují některé operační systémy, které si novou IPv6 adresu vytvoří s každou reasociací k WiFi síti.

Pokud přihlédneme k oběma skutečnostem, můžeme bez problémů narazit na zařízení, které má na IPv6 rozhraní nakonfigurováno například 10 nebo více IPv6 adres, jak jsme si ostatně ukázali v předchozím díle. A zde pak už začíná být poměrně těsno. Pokud uvážíme, že v síti máme připojených k jednomu směrovači například 800 takových zařízení, velice snadno se můžeme přiblížit k limitu celkového počtu záznamů v tabulce sousedů. Jak to vypadá v praxi, si můžeme ukázat na následujícím grafu, který zachycuje počet unikátních MAC, IPv4 a IPv6 adres během jednoho týdne, tak, jak je monitorujeme v rámci vybraných sítí počítačové sítě VUT v Brně.

Z grafu můžeme vidět, že zelený a červený průběh, které představují počet unikátních IPv4 a MAC adres v ARP tabulce, se prakticky kryjí. Na každou MAC adresu tedy připadá jedna IPv4 adresa. Počet záznamů v ARP tabulce tudíž odpovídá počtu zařízení připojených v sítí. V případě IPv6 je situace trošku jiná. Černý průběh zachycuje počet unikátních MAC adres, modrý průběh počet unikátních IPv6 adres v cache sousedů. Zde vidíme, že počet záznamů v sítích, které podporují IPv6 protokol, je více než dvoj až trojnásobný oproti počtu zařízení.

Závěr

Z vlastní zkušenosti doporučujeme na problém dostatečné velikosti cache sousedů myslet, zejména při návrhu větších sítí. V provozním prostředí je pak také vhodné průběžně monitorovat míru jejího zaplnění. Není asi třeba zdůrazňovat, že v případě zaplnění cache sousedů je diagnostika takového stavu značně problematická. Část uživatelů totiž začne hlásit, že se jim občas špatně načítá Google a při řešení takového problému vás zpravidla nenapadne, že problém může být způsoben tím, že je zaplněná cache sousedů - ať už vlivem velkého počtu řádných záznamů anebo v důsledku cíleně vedeného útoku.

Zatímco prostor pro ARP záznamy je na většině zařízeních v řádech desítek tisíc a jedná se zpravidla o velice dobře zdokumentovanou informaci, v případě IPv6 je prostor pro cache sousedů často výrazně menší a výrobci zařízení raději tento údaj v dokumentaci nezmiňují či všemožně zatemňují. Údaj o velikosti cache sousedů je přitom poměrně stěžejní zejména proto, že na mnohých platformách je velikost vázána na hardwarové prostředky, které má zařízení k dispozici. Je tedy možné, že změna limitu nebude řešitelná jinak než výměnou hardware. V příštím díle se podíváme na možné principy obrany proti cíleným útokům na cache sousedů a na konkrétní způsoby, které lze k obraně použít.