Bezpečné IPv6: vícehlavý útočník

Dnešní díl bude bez dalších úvodů navazovat na díl předchozí. Před čtením tohoto dílu tedy doporučujeme nejdříve prostudovat díl předchozí, ve kterém byla obecná problematika rozšířených hlaviček vysvětlena.

Vkládání hlaviček

Úplně nejzákladnějším způsobem zneužití rozšířených hlaviček je jejich cílené vkládání do těla paketu. Smyslem tohoto útoku je doručit koncovému zařízení data, která by za normálních okolností byla odfiltrována. Jak tento útok může fungovat v praxi si ukážeme na našem oblíbeném mechanismu RA-Guard.

Podstatou útoku je vložení několika rozšířených hlaviček tak, aby filtrační mechanismus přístupového portu přepínače nebyl schopen identifikovat protokol, který je v IPv6 paketu přenášen. Vzhledem k tomu, že paket obsahující více rozšířených hlaviček je z hlediska specifikace protokolu IPv6 naprosto v pořádku, koncové zařízení jej normálně zpracuje. Pokud si tedy vytvoříme specifický ICMPv6 paket Ohlášení směrovače, koncové zařízení bez problémů provede na základě informací v paketu konfiguraci či rekonfiguraci. Podrobně se tímto jednoduchým útokem zabývá RFC 7113. Paket, do kterého jsme si vložili tři Destination Options hlavičky pak může vypadat například následovně.

Tento paket je pak již dostatečně velký, aby obešel filtrační jednotku některých zařízení. Pokud byste chtěli útok otestovat ve vaší síti, můžete použít následující rozšířený kód z prvního dílu, který jsme použili pro generování falešných zpráv Oznámení směrovače.

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

Na třetím řádku přibyl kód, který zajistí vytvoření jedné Hop-by-hop rozšířené hlavičky v celkové délce 8 bajtů. Ta je pak následně vložená mezi základní IPv6 hlavičku a ICMPv6. Tím jsme vložili pouze jednu rozšiřující hlavičku. Větší počet si můžeme naskládat například takto:

h = IPv6ExtHdrHopByHop(len=0)/IPv6ExtHdrHopByHop(len=0)

Přestože je tento útok znám již delší dobu, současná zařízení jsou vůči němu pořád zranitelná. Příkladem může být poslední verze přepínače určeného pro přístupovou vrstvu Cisco Catalyst 2960-S. I s nejnovější verzi IOS, která je dnes dostupná (15.2.2E), je přepínač vůči tomuto útoku zranitelný. Tento přepínač navíc nelze nakonfigurovat tak, aby zahazoval pakety, které nerozpozná (undetermined transport v ACL, jak si popíšeme dále), tedy je vůči tomuto útoku kompletně bezbranný.

Na straně operačních systémů je situace o něco lepší. Obrana je postavená na jednoduchém principu. Pakliže je operačnímu systému doručen paket Oznámení směrovače a současně tento paket obsahuje rozšířené hlavičky, tak je zahozen. Mnohé operační systémy již tuto obranu mají implementovanou. Příkladem mohou být poslední verze Windows. U Linuxu záleží na distribuci - např. Ubuntu se rozšířeným hlavičkám v Ohlášení směrovače brání, CentOS ne. Tato obrana však není definována v žádném RFC, jedná se tedy víceméně o porušení standardu.

Demonstrace útoku prostřednictvím RA-Guard je jednoduchá díky tomu, že se jedná o jednosměrnou komunikaci. Trošku složitější situace nastává v případě, že chceme klasifikační/filtrační jednotku obelstít při použití interaktivní komunikace - například u protokolu TCP. Princip útoku zůstává stále stejný. Mezi základní IPv6 hlavičku a hlavičku protokolu TCP vložíme jednu či několik rozšířených hlaviček a zašleme protistraně. Realizace toho útoku, pokud nechceme ve Scapy programovat celý TCP stack, je ale trochu složitější. Pro případ, že chcete otestovat, jestli firewall na vašem síťovém zařízení je vůči takovému typu útoku odolný, můžete zkusit použít jednoduchý modul pro linuxové jádro, který zajistí, že do každého odeslaného paketu bude vloženo několik rozšířených hlaviček.

Zneužití Fragmentace

Další typ útoků je možné realizovat díky hlavičce fragmentace. Tento útok je v principu hodně podobný útokům zneužívající fragmentaci v IPv4. Princip spočívá v tom, že celý paket je účelově rozdělen do fragmentů. Vzhledem k tomu, že většina jednoduchých paketových filtrů (například těch realizovaných v ASIC čipu) neumí provádět rekonstrukci fragmentů (fragment reassembling), lze tento útok také s úspěchem použít k obcházení filtračních pravidel v síti.

Pro otestování lze použít následující kód:

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

V kódu jsme za IPv6 hlavičku vložili rozšířenou hlavičku fragmentace, zbytek paketu může zůstat tak, jak je. O fragmentaci samotnou se postaráme pozměněním kódu pro odesílání, kde zavoláme funkci fragment6(), která se za nás postará o vlastní fragmentaci. Funkce přijímá dva argumenty - první argument jsou data k odeslání a druhý argument je maximální velikost fragmentu. Tu si zvolíme tak, aby nám vyhovovala a paket se skutečně rozfragmentoval. V praxi pak výsledný paket může vypadat jak na následujícím obrázku.

Pokud by chtěl firewall zpracovat daný paket, nevidí do samotného obsahu - nemůže tedy ihned rozhodnout jestli má paket propustit nebo zahodit. Vidíme však, že firewall dokáže poznat protokol uvnitř paketu. Toto však může útočník obejít tím, že zkombinuje tento typu útoku s předchozím a vytvoří za hlavičkou fragmentace dostatečně dlouhý řetězec dalších rozšířených hlaviček. Hlavička vlastního protokolu se tak nedostane do prvního fragmentu. Je to tedy další cesta, jak můžeme v praxi vcelku jednoduše obejít paketový filtr.

Filtrování hlaviček a vzdálený DoS s využitím fragmentace

V předchozím díle jsme si řekli, že zpracování rozšířených hlaviček v hardware je relativně komplikovaná záležitost. Z toho důvodu mnohá zařízení často IPv6 paket i s pouhou jednou rozšířenou hlavičkou přeposílají do CPU. Tím dramaticky degradují výkonnost a propustnost celého zařízení zpracovávající takový provoz. Díky těmto problémům mnozí ISP raději pakety s rozšířenými hlavičkami rovnou zahazují, než aby riskovali případné ohrožení stability infrastruktury. Touto problematiku se podrobněji zaobírá pracovní skupina IETF v6ops, která dochází k zajímavým zjištěním. Například pro jednoduchou hlavičku Hop-by-Hop je šance na zahození kolem 40 %. V dnešní době, kdy se v praxi intenzivně řeší ztrátovost paketů větší jak několik málo procent, je tato ztrátovost extrémní a posouvá to rozšířené hlavičky téměř do pozice nefunkční technologie. Problémem také je, že filtrování provozu obsahující rozšířené hlavičky se často neděje až v koncové síti, ale někde po cestě. To znamená, že zahazování není součástí nastavené bezpečnostní politiky koncového autonomního systému, ale pakety zahazuje často některý z tranzitních operátorů. To je podstatně složitější problém k vyřešení, protože díky dynamičnosti směrování vlastně dopředu nevíme, kudy nám provoz do cílové destinace poteče a koho případně kontaktovat. Pokud by potenciálně někdo chtěl využít koncept rozšířených hlaviček pro nějakou novou aplikaci, tak nemůže, jelikož nedokáže ani zajistit, že daný paket vůbec dojde Internetem na koncové zařízení. Tohoto stavu může navíc využít útočník pro vcelku zajímavý, i když poněkud kuriózní, typ DoS útoku.

Jelikož se útok opírá ještě o některé další vlastnosti protokolu IPv6, o kterých jsme se zatím v článcích nezmiňovali, nejprve si krátce je vysvětlíme.

IPv6 protokol vyžaduje, aby minimální délka paketu, kterou koncové uzly musí umět zpracovat, byla 1280 bajtů. Tím se posouvá hranice velikosti v bajtech, od které pakety mohou být fragmentovány nad tuto hodnotu. IPv6 také kompletně mění způsob fragmentace - již se neděje po cestě, jak tomu bylo zvykem u IPv4, ale fragmentují pouze koncová zařízení. Aby koncové zařízení mohlo zjistit, že paket, který odeslalo, je pro nějaký směrovač po cestě příliš velký, využívá se protokolu ICMPv6 a jeho zprávy Packet Too Big. Pokud tedy velký paket dorazí po cestě k cíli na úzké hrdlo, směrovač ho zahodí a pošle zpět koncovému zařízení zprávu Packet Too Big. Poslední informaci, kterou budeme pro správné pochopení útoku potřebovat, jsou tzv. Atomické fragmenty (Atomic Fragments). Jedná se o běžné, nefragmentované pakety, které však v sobě nesou fragmentační hlavičku. Byly definovány již v původní specifikaci IPv6 a podrobně se jimi zabývá RFC 6946. Pokud se zamýšlíte nad tím, k čemu je vůbec dobrá fragmentační hlavička v nefragmentovaném paketu, tak jí využívají některé přechodové mechanismy v okamžiku, kdy je třeba doručovat IPv6 pakety do IPv4 sítě.

Jak potom probíhá vlastní útok? Útočník, který chce narušit komunikaci mezi klientem a serverem, zašle serveru zprávu Packet Too Big ve které server informuje, že cesta ke klientovi má MTU menší jak 1280. Server si tuto informaci poznamená, a pokud pak klient server kontaktuje, začne mu server v souladu se specifikací zasílat odpovědi s vloženou hlavičkou Fragmentace. Pokud jsou pakety s rozšířenými hlavičkami zahazovány po cestě, a v předchozí části jsme si ukázali, že tomu tak je v nemalém množství případů, útočníkovi se podaří znemožnit IPv6 komunikaci mezi klientem a serverem. Pokud data s rozšířenou hlavičkou zahazována nejsou, stále je tu problém. Prohlížeče často odpověď obsahující hlavičku Fragmentace neinterpretují jako odpověď na svůj pokus o navázání spojení, a pokud prohlížeč nepoužívá nějakou variantu Happy Eyeballs, spojení trvá nemalou dobu, než se přepne zpět na IPv4.

Pro jednoduchou realizaci útoku si můžeme ICMPv6 paket poskládat sami pomocí Scapy, nebo lze využít další z penetračních nástrojů ipv6toolkit. Realizaci pak provedeme spuštěním příkazu:

icmp6 --icmp6-packet-too-big -d IPv6:adresa:serveru --peer-addr 
IPv6:adresa:klienta --mtu 1000 -o 80 -v

Na adresu serveru se zašle zpráva ICMPv6 Packet Too Big tvářící se tak, že klient, specifikovaný parametrem peer-addr, má problém s přijetím dat od serveru, protože používá MTU pouze 1000 bajtů. Server pak začne vkládat do odpovědi klientovi hlavičku Fragmentace a útok je úspěšný. Na následujícím obrázku lze vidět, jak reálný útok vypadá, mezi naším zařízením a serverem root.cz.

Útok začíná zasláním zprávy Packet too Big danému serveru. Touto zprávou se snažíme server přesvědčit, aby klientovi, který je specifikován v těle této zprávy, začal posílat data s hlavičkou Fragmentace. Když se pak klient pokouší navázat TCP spojení (2. paket), server mu dle specifikace odpovídá s hlavičkou fragmentace (3. paket). Vidíme však, že klient tuto zprávu neinterpretuje jako odpověď na svůj pokus o navázání spojení a zkouší ho navázat znovu (4. paket). Toto se opakuje, dokud to klienta nepřestane bavit nebo nezasáhnou Happy Eyeballs. Tento příklad je také demonstrován na síti, kde nedojde k zahození paketů s rozšířenými hlavičkami. Pokud by ale odpověď od serveru putovala skrz tranzitního operátora, který takové pakety zahazuje, došlo by k efektivnímu útoku DoS. Odpovědi od serveru by totiž ke klientovi vůbec nedorazily.

Pokud si to celé shrneme, tak pro úspěšnou realizaci útoku musí být splněno několik předpokladů.

1. Útočník potřebuje znát IPv6 adresu klienta a serveru. To nicméně není až tak problém a RFC 5157 popisuje několik způsobů, jak dané adresy získat.
2. IPv6 pakety s atomickými fragmenty jsou po cestě filtrovány. Pokud se pakety nefiltrují, stále je zde možnost útoku, protože odpověď obsahující hlavičku Fragmentace často není interpretována jako odpověď na zaslaný paket.
3. Server musí při přijetí zprávy ICMPv6 Packet Too Big začít generovat atomické fragmenty (vložit do odpovědi hlavičku Fragmentace).
4. Server musí akceptovat podvrženou zprávu ICMPv6 Packet Too Big
5. ISP útočníka musí akceptovat paket, ve kterém je podvržená adresa.

Zdálo by se, že podmínek pro to, aby útok byl úspěšný, je hodně, nicméně většina z nich je vcelku bez problémů splnitelná. Pro zastánce přístupu: “Problém je vyřešen, když existuje RFC nebo BCP ( Best Current Practice), které mu zamezuje” mohou být lehce kontroverzní body 4. a 5. Pro bod 4. existuje RFC 5927, které podobné útoky popisuje a navrhuje určité validace zpráv. Pokud by servery používaly tato doporučení, byl by takový útok daleko obtížnější. U bodu 5. existuje dokument BCP 38, který doporučuje operátorům provádět validaci a filtraci prefixů, aby se zamezilo odeslání paketů s podvrženou zdrojovou IP adresou. Jednoduše řečeno, operátor by měl předávat pouze pakety, kde zdrojová adresa spadá pod prefix, který je danému operátorovi přidělen. Pokud by všichni operátoři BCP 38 zavedli, útočník by pak nemohl podvrhnout svou adresu a byl by lépe dohledatelný. Zdálo by se, že tedy řešení problému dávno existuje, nicméně realita je však taková, že se tyto kontroly moc neprovádí. Proč tomu tak je, by vydalo na samostatný seriál. Spokojíme se zatím s tím, že útočníkovi v dnešním Internetu vcelku nic moc nebrání zasílat pakety s podvrženou IP adresou a podvrženými údaji v ICMP paketu.

Přetížení CPU síťových prvků

Je třeba si dát také pozor na vytížení procesoru na síťových zařízeních. Přepínače se většinou snaží zpracovávat pakety pomocí hardware, nicméně ne vždy je to možné. Příkladem paketu, který vždy zpracovává procesor je IPv6 paket obsahující rozšířenou hlavičku Hop-by-Hop. Ostatní rozšířené hlavičky se zařízení většinou snaží přeposlat pomocí hardware, jelikož se jimi moc zabývat nemusí. Problém nicméně je, když od zařízení požadujeme právě kontroly a validace těchto paketů. Potom se může stát, že paket již v hardware zpracovat nelze a musí se předat CPU. Tématu vytížení procesoru při aktivních mechanismech First Hop Security se věnuje například práce „The impact of using SAVI on processing resources“. V následujícím grafech Ovidiu Strugaru například ukazuje, o kolik se zatíží CPU, pokud ověřování pro IPv6 zapneme.

Autoři práce postupně zvedali počet paketů za vteřinu, které musel přepínač validovat. Pro 80% zatížení procesoru stačilo pouze 150 paketů za vteřinu. Dané vytížení bylo dáno pouze při podvržení zdrojové IPv6 adresy a MAC adresy. Vůbec tedy není zohledněno další vytížení při vložení rozšířených hlaviček, kde se dá předpokládat, že bude vyšší.

Ideální přepínač by měl omezovat počet paketů, které jsou zasílány z hardware do CPU (rate-limiting). Cisco povětšinou ve svých materiálech uvádí, že ho má implementovaný, nicméně typicky pouze pro platformy 6500 a 7200, tedy ne pro zařízení určené pro přístupovou vrstvu. U ostatních zařízení je rate-limiting většinou implementován pouze pro jednotlivé protokoly (např. limit na broadcast pakety u ARP aj.), nicméně chybí nějaká lepší podpora pro IPv6. Ostatně to lze vidět i v dané ukázce, kde byli schopni vcelku výkonný přepínač 3750 hodně zatížit.

Částečná obrana

Pro obranu proti výše zmíněným útokům využijeme zpravidla nějakou formu filtrace paketů s rozšířenými hlavičkami. Lze vytvořit např. následující ACL, které bude zahazovat hlavičky Destination Options a Hop-by-Hop.

Router(config)# ipv6 access-list DENY-EXTHEADERS
Router(config-ipv6-acl)# deny 60 any any
Router(config-ipv6-acl)# deny 0 any any
Router(config-ipv6-acl)# permit ipv6 any any

Takováto filtrace je ale poměrně drastické opatření, které může poškodit i legitimní provoz. Není také vždy pravidlem, že zařízení podporuje danou filtraci. Například u L2/L3 přepínačů 2960s nebo 3750x tyto ACL podporovány nejsou. Přepínač vám je sice dovolí nakonfigurovat, nicméně provozní pakety s rozšířenými hlavičkami bez problémů přepošle dále.

Abychom zbytečně nezahazovali legitimní provoz, lze použít méně striktní variantu. Filtry nastavíme tak, aby zahazovaly pouze provoz, u kterého zařízení nedokáže rozpoznat transportní protokol - tedy když zařízení není schopné paket zpracovat natolik, aby našlo, kde transportní protokol vůbec začíná. Tyto pakety mají navíc do legitimního provozu většinou dost daleko, tedy jejich zakázáním se toho tolik nestane. Zneužití fragmentace nebo řetězce hlaviček, který je příliš dlouhý, že ho zařízení není schopno zpracovat, jsme demonstrovali na útoku, pomocí kterého je možné obejít ACL přepínače. Ve spolupráci se společností HP se nakonec podařilo najít a odladit řešení, které tento typ útoku eliminuje. Výsledkem je nově přidaná funkcionalita, kterou můžete na nejnovějším firmware Comware aktivovat pomocí jednoduchého příkazu:

[HP-Comware] ipv6 option drop enable

Cisco na některých svých zařízeních podporuje ACL, kterým lze dosáhnout podobného efektu. Můžeme tak rozšířit ACL, které jsme si ukázali v předchozím díle následovně:

Switch(config)# ipv6 access-list DENY-RA
Switch(config-ipv6-acl)# deny icmp any any router-advertisement
Switch(config-ipv6-acl)# deny ipv6 any any undetermined-transport
Switch(config-ipv6-acl)# permit ipv6 any any

Klíčový je zde třetí řádek, kdy pomocí klíčového slova undetermined-transport přikážeme zařízení, aby nerozpoznaný provoz zahodil. ACL tedy zahodí všechny IPv6 pakety Oznámení směrovače a pakety, které není schopno zpracovat natolik, aby rozpoznalo, co je v nich vlastně přenášeno. Je třeba ale poznamenat, že podpora tohoto příkazu zcela závisí na tom, jestli je podporován v hardware daného přepínače. U přepínačů určených pro přístupovou vrstvu (např. řada 2900) tomu tak většinou není.

Pokud zařízení nepodporuje undetermined-transport u ACL, lze ještě využít přístup negace. Místo toho, abychom zakázali to, co přepínač nerozpozná, tak povolíme pouze to, co rozpozná. Konfigurace bude sice o dost složitější, ale pro některé platformy je to jediná možnost jak těmto útokům zabránit. Příkladem by pak mohlo být následující ACL.

Switch(config)# ipv6 access-list DENY-UNDETERMINED-TRANSPORT
Switch(config-ipv6-acl)# permit 0 any any
Switch(config-ipv6-acl)# permit 1 any any
Switch(config-ipv6-acl)# permit 3 any any
...
...
Switch(config-ipv6-acl)# permit 254 any any
Switch(config-ipv6-acl)# permit 255 any any

Nenechte se zmást faktem, že v daném ACL vlastně nic nezakazujeme a vše naopak povolujeme. Toto ACL totiž využíváme pouze proto, abychom povolili provoz, který zařízení je schopno rozpoznat. Jelikož se přepínač snaží zpracovat paket až na transportní protokol, pokud transportní protokol nerozpozná, tak ho nemůže propustit, protože ACL povoluje jenom pro něj známé protokoly.

Pokud se u síťových zařízení nemůžeme spoléhat na filtraci nebo mechanismy First Hop Security, zbývá nám pouze nějak zabezpečit koncové operační systémy. Existují dvě RFC, které se danou problematikou zabývají. RFC 7112 doporučuje, aby při použití fragmentace, byly všechny rozšířené hlavičky v prvním fragmentu. Zařízení pak je schopno rozpoznat, jaký protokol se ve fragmentovaném paketu nachází a zařídit se podle toho. RFC 6980 pak zakazuje použití hlavičky fragmentace u zpráv Ohlášení směrovače, Ohlášení souseda atd. a některé koncové systémy ho již implementovaly. Některé operační systémy zašly ještě dále a filtrují všechny zprávy protokolu NDP, které obsahují nějakou rozšířenou hlavičku. Jedná se sice o porušení standardu, nicméně zas tak to nevadí. U protokolu NDP zatím neexistuje jediný důvod, proč by nějaké rozšířené hlavičky měl obsahovat, tedy když se zahodí, nic se nestane. Ideální je tedy udržovat koncové systémy aktualizované, což asi nemusíme příliš připomínat.

Neradostné vyhlídky rozšířených hlaviček

V současné době neexistuje jednoznačná cesta k řešení problému rozšířených hlaviček. Z pohledu IETF je celkem pochopitelná snaha zachovat možnosti rozšířených hlaviček pokud možno v co nejvíce flexibilní podobě. Proti tomu ovšem stojí implementační možnosti současných technologií a požadavky operátorů. Realitu pak vystihuje glosa Randyho Bushe z posledního meetingu RIPE69:

Díky problémům s neefektivním zpracováním rozšířených hlaviček se nelze divit, že řada ISP realizuje ve svých sítích striktní politiku a pakety s rozšířenými hlavičkami zahazuje - většinou kromě hlavičky fragmentace. Organizace IETF, která je jako jediná schopna vyřešit věc na úrovní standardu, nicméně nemá na problematiku jednotný názor. Jedna snaha vedla směrem k vytvoření ještě univerzálnější rozšířené hlavičky než té z RFC 6564, kterou jsme popisovali minule. Změna formátu rozšířených hlaviček však nebyla podpořena.

Jiným směrem se ubírá aktuálně vznikající draft, který detailně rozebírá, který typ rozšířených hlaviček je přípustné filtrovat a který nikoliv. Otázka je, jestli získá podporu a bude schválen. Navíc, i pokud by schválen byl, nejedná se o standard, ale pouze o doporučení (Best Current Practice), takže i jeho reálný dopad je omezený.

Výsledkem je, že se v reálné síti rozšířené hlavičky téměř nepoužívají. Situaci v síti VUT popisuje následující tabulka, která zobrazuje počet jednotlivých protokolů a rozšířených hlaviček za jeden týden provozu. Data jsou získané z linky připojující VUT v Brně do sítě CESNET.

Vidíme, že kromě TCP, UDP, ICMPv6 a hlavičky fragmentace se ostatní hlavičky nepoužívají. Je třeba ale vzít v potaz, že tato statistika je trošku zkreslená, protože se jedná o páteřní linku - není zde tedy vidět například hlavička Hop-by-Hop, kterou běžně používá IPv6 multicast.

Závěr

Rozšířené hlavičky jsou často opomíjenou součásti protokolu IPv6. Často je na ně pohlíženo jako benefit protokolu IPv6. Tím částečně také jsou. Umožňují potenciální rozšíření protokolu do budoucna a dodávají mu flexibilitu. Je třeba ale také poznamenat, že nic není zadarmo. Za zvýšenou flexibilitu platíme daň v podobě složitějšího zpracování paketů. Jak jsme si ukázali, použití rozšířených hlaviček v reálném provozu je nyní zatím spíše omezené. Při implementaci protokolu IPv6 do sítě bychom však jejich existenci neměli ignorovat a jejich zpracování řešit jako součást bezpečnostní politiky. Zejména kvůli faktu, že se reálně dají použít pro obcházení filtrovacích pravidel nebo IDS systémů, jak bylo ukázáno na konferenci BlackHat. S jejich pomocí může také útočník v dnešní době většinou vcelku bez problémů obejít mechanismy First Hop Security, které jsme si popsali v předchozích dílech. Při nákupu zařízení, zejména těch řešících bezpečnost, je tedy dobré se informovat na schopnosti zařízení správně zpracovat rozšířené hlavičky. U některých zařízeních může výrobce v budoucnu podporu pro efektivní zpracování rozšířených hlaviček přidat v podobě aktualizace firmware. Někdy ale, pokud tuto funkcionalitu budeme vyžadovat, bude nutné vyměnit celé zařízení nebo jeho části.

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.