Bezpečné IPv6: zkrocení zlých směrovačů

Dříve než se podíváme, jak můžeme IPv6 síť zabezpečit proti útokům z minulého dílu seriálu, seznámíme se s možnostmi, které máme pro řešení obdobných typů útoků v protokolu IPv4. Jak už jsme zmínili v předchozím článku, falešný DHCP server může v IPv4 síti napáchat pořádnou neplechu. Obecně se tento typ útoku (podvržení zpráv protokolu DHCP) označuje jako DHCP Spoofing. Na rozdíl od falešného IPv6 směrovače sice není možné převzít kontrolu nad celou podsítí během několika milisekund, nicméně většina správců si je rizik a nepříjemností s falešným DHCPv4 serverem vědoma.

Díky možnosti podvržení zpráv u protokolu DHCP vznikly ve světě IPv4 postupem času mechanismy na ochranu proti typickým útokům. Jedním z nejběžnějších prostředků obrany je technologie známá pod označením DHCP Snooping. DHCP snooping se konfiguruje na portu přepínače, do kterého je připojen koncový uživatel (přístupová vrstva - access). Uživatelské porty se označí jako nedůvěryhodné a na těchto portech jsou zahazovány všechny pakety, které by ostatní mohli interpretovat jako odpověď DHCP serveru, tj. pakety s cílovým UDP portem 68 a zprávy DHCP Offer, DHCP Acknowledge aj. Tímto vcelku efektivně zajistíme, že za daným portem nemůže běžet DHCP server, který by nebyl pod kontrolou správce sítě. DHCP Snooping nejen že rozhoduje, které zprávy jsou validní a které nikoli, ale u těch validních si do interní tabulky také uloží informaci o tom, která IP adresa byla přidělena zařízení připojeném k příslušnému portu a jakou MAC adresu toto zařízení používá. Vzniká tak vazební tabulka (binding table) IP - MAC - port, tedy jaké zařízení (MAC adresa) používající danou IP adresu je připojeno na příslušném portu.

Na přepínači může databáze vypadat například takto:

Praxe však ukázala, ze pouhá ochrana před falešnými DHCP servery je v některých případech nedostatečná. Z toho důvodu umožňují některé přepínače aktivovat další stupeň ochrany, který je znám pod pojmem Dynamic ARP Inspection (případně u některých výrobců Dynamic ARP Protection). Pro své správné fungování využívá databázi vytvořenou mechanismem DHCP Snooping. Princip Dynamic ARP Inspection je pak vcelku jednoduchý. Na portech, kde je ochrana aktivována, jsou kontrolovány všechny pakety protokolu ARP, u kterých je prováděná analýza, zda se údaje v ARP odpovědích (IP a MAC adresy) shodují s příslušným záznamem v DHCP Snooping databázi. Tento typ kontroly znemožní připojenému zařízení provést útok typu ARP poisoning. Další často ceněnou vlastností tohoto mechanismu je fakt, že zařízení nedokáže rozumně používat síť, pokud předem nepožádalo o konfigurační údaje DHCP server. To prakticky znemožňuje uživatelům používat vlastnoručně nakonfigurované statické IP adresy, což je noční můra mnoha správců.

Je dobré si uvědomit, že popsaný mechanismus Dynamic ARP Inspection zkoumá pouze pakety protokolu ARP a mechanismus DHCP Snooping pouze pakety protokolu DHCP. Nic tedy nezabraňuje útočníkovi posílat data s podvrženými IP a MAC adresami, což je oblíbená kratochvíle zejména různých DDoS nástrojů. K zamezení tohoto útoku existuje třetí zbývající technika: IP Source Guard (Dynamic IP Lockdown). Využíva opět databázi vytvořenou mechanismem DHCP Snooping, nicméně kontrolu rozšiřuje i na hlavičky protokolů Ethernet a IP. Na příslušném portu tedy přepínač propustí pouze pakety obsahující správnou kombinaci MAC a IP adresy, čímž efektivně brání možnému podvrhávaní zdrojové IP nebo MAC adresy. Použití uvedených mechanismů tedy zajistí splnění podmínky na validaci zdrojové adresy dle doporučení BCP38 a to na nejdůkladnější možné úrovni.

Pokud se v tom všem ztrácíte, tak následující tabulka shrnuje typy útoků realizovatelné v rámci lokální IPv4 sítě a dostupné prostředky pro jejich eliminaci.

Čistě teoreticky tedy můžeme být nadšení, že máme pokryty všechny výše zmíněné bezpečnostní problémy, a prostě jen stačí v celé síti tyto ochranné prvky aktivovat a je vystaráno. Aktuálně navíc nejsou známy další závažné útoky, které by bylo možné realizovat v rámci lokální sítě IPv4 a dané obranné mechanismy jim nezabránily.

V praxi však bohužel není vše tak jednoduché. Uvedené ochranné prvky vnášejí do chodu sítě složitost, která pak vyžaduje více kvalifikovaného správce, komplikují analýzu případných problémů a v neposlední řadě mohou, vlivem chyb v implementaci, vnést do sítě problémy nové. Neméně významným faktorem je rovněž skutečnost, že za přepínač podporující tyto vlastnosti si budeme muset o něco připlatit. Nutnost nasazení tedy vždy záleží na posouzení konkrétní sítě - zatímco ve vaší domácí síti nebo v malé kanceláří jsou zřejmě bezpředmětné, v síti sídlištního operátora s tisíci uživateli jsou prakticky nezbytné. Pro úplnost ještě uveďme, že uvedená zabezpečení se označují souhrnným pojmem First-Hop-Security.

V souvislosti s bezpečnostními prvky možná někoho napadlo, zda by nebylo snazší v síti jednoduše implementovat autentizovaný přístup prostřednictvím IEEE 802.1X. Bohužel autentizace klinetů prostřednictvím 802.1X nám v tomto případě příliš nepomůže. Protokol 802.1X na základě certifikátu nebo jména a hesla pouze zpřístupní port pro daného uživatele. Přidělení L3 informací - IP adresa aj. jde ale typicky již mimo něj. Nic tedy nezabrání uživateli si nastavit adresu vlastní, podvrhnout cizí nebo provést přeplnění či otrávení tabulky MAC adres na přepínači. Proto i v tomto případě bude nutné výše zmíněné bezpečností mechanismy použít, abychom těmto útokům zabránili.

Jak je to v IPv6

Jistě vás napadá myšlenka, že by asi nebyl problém převzít jednou ověřené postupy ze světa IPv4 rovnou do IPv6. Byť jsou signalizační protokoly z hlediska formátu zpráv v IPv6 trochu jiné, v principu fungují stejně. To částečně platí, nicméně je zde několik drobností, které nám situaci budou poněkud komplikovat:

• IPv6 používá k autokonfiguraci buď bezstavovou konfiguraci (SLAAC) s jednoduchou výměnnou zpráv: výzva směrovači, odpověď, nebo je SLAAC doplněn o protokol DHCPv6. Tím se nám množina protokolů pro zabezpečení rozšiřuje na dva.
• Podpora protokolu DHCPv6 je na koncovém systému pouze volitelná a řada zařízení ho nepodporuje (např. Android). Vazební tabulku IP - MAC - Port vytvořenou na základě protokolu DHCPv6 tedy nemůžeme využít ve všech případech.
• V případě bezstavové konfigurace je tvorba výsledné IPv6 adresy plně v moci koncového systému a při použití Privacy Extensions (RFC 4941 a RFC 7217) je adresa, kterou zařízení použije pro komunikaci vygenerovaná náhodile a tedy předem nepredikovatelná.
• Uvedené mechanismy musí podporovat hardware přepínače (např. v ASIC chipu), který zajišťuje připojení takto chráněného koncového systému. Pokud by je totiž zpracovával přepínač pouze procesorem, lze ho vygenerováním tisícem zpráv zahltit.

Další nemalý problém je, že díky pomalému zavádění protokolu IPv6 je obrovská asymetrie mezi útočníky a mechanismy pro ochranu sítě. Nástroje pro útočníky jsou již dávno k dispozici, nástroje pro ochranu sítě IPv6 ale stále chybí. Příkladem může být nástroj THC-IPV6, který jsme využili v minulém díle a který implementoval většinu útoků pro IPv6 v roce 2005, nicméně obranné mechanismy byly standardizované až v roce 2011 (například RA-Guard, RFC 6105). Navíc, jak si ukážeme v následujících dílech seriálu, ani jejich použití neznamená, že je problém vyřešen.

V praxi pak můžeme stát před obtížným rozhodnutím: Jaké řešení použít tak, aby konfigurace sítě současně vyhověla požadavkům na bezpečnost, spolehlivost a odpovídala definovaným RFC? Pojďme si tedy probrat reálné možnosti, které máme v dnešní době k dispozici:

RA-Guard

Směrem, který je aktuálně považován za správné řešení je použití nástroje jménem RA-Guard. Před několika lety tuto problematiku rozebíral Pavel Satrapa ve svém článku na Lupě. V mezičase práce na standardizaci nástroje RA-Guard pokročila a na jaře 2011 byl vydán popis nástroje ve formě informačního RFC 6105

Základní myšlenka, kterou RA-Guard používá je v celku jednoduchá a ilustruje ji následující obrázek.

Na portu přepínače, kde je koncové zařízení připojeno, budeme na vstupu zahazovat všechny pakety obsahující zprávy Oznámení směrovače. Tj., všechny ty, které lze identifikovat jako zprávu ICMPv6 typ 134. Případný útočník, který bude chtít zneužít zpráv Oznámení směrovače je sice může vytvořit a odeslat do sítě, tyto zprávy ale neprojdou dál než na port, kterým je útočník připojen. Ostatní uživatele tedy nebudou takovými aktivitami nijak ohrožení. Jedná se tedy téměř o stejný mechanismus jako DHCP Snooping, který jsme si popsali u IPv4.

Na síťových prvcích se RA-Guard aktivuje jednoduchou kombinací příkazů. Příklad nastavení pro zařízení Cisco:

Switch(config)# ipv6 nd raguard policy POLICY-NAME
Switch(config-ra-guard)# device-role {host | router}

Nejprve vytvoříme politiku, kterou budeme později aplikovat na síťové rozhraní. Role zařízení pro danou politiku může být vícero, nás ale zajímají pouze následující dvě.

• Host: všechny zprávy Ohlášení směrovače a Přesměrování jsou zahazovány, tato volba je implicitní
• Router: Zprávy Ohlášení směrovače a Přesměrování jsou propouštěny.

V dané politice lze nastavit ještě celou řadu dalších kontrol zprávy Ohlášení směrovače - zda je správná priorita směrovače, správný prefix, byla odeslána ze správné adresy aj. Tyto další kontroly se používají pro politiku určenou pro porty směrovače, podrobnosti lze nalézt v dokumentaci. Danou politiku pak aplikujeme na rozhraní pomocí následujících příkazů:

Switch(config)# interface INTERFACE
Switch(config-if)# ipv6 nd raguard attach-policy POLICY-NAME

Politiku pro koncová zařízení aplikujeme na uživatelské porty, politiku pro směrovač na port směrem k nadřazenému přepínači nebo směrovači (uplink). Konfigurace u zařízeních HP se pak liší v závislosti na použité platformě. U řady přepínačů používající firmware ProVision lze pro jednotlivé porty nastavit pouze jednoduchou filtraci:

HP Switch(config)# ipv6 ra-guard ports <port-list>

Tímto příkazem dojde k zahození zpráv Ohlášení směrovače a Přesměrování. Žádné složitější validace nastavit nelze. Pro port vedoucí ke směrovači samozřejmě filtraci nenastavujeme.

U zařízeních HP používající firmware Comware je RA-Guard součástí obecnějšího mechanismu ND-Snooping, který popíšeme podrobně později. RA-Guard na těchto prvcích povolíme následovně:

[Switch] vlan 1
[Switch-vlan1] ipv6 nd detection enable

[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] ipv6 nd detection trust

Pro zvolenou VLAN povolíme RA-Guard. Nesmíme také zapomenout nastavit port, který vede ke směrovači jako důvěryhodný, abychom nezahazovali validní zprávy.

ND-Snooping

RA-Guard řeší pouze část problému, protože dokáže filtrovat pouze zprávy Ohlášení směrovače. Již jsme zmínili, že IPv6 adresy mohou být přiděleny bezstavově nebo pomocí protokolu DHCPv6. V dnešní době se k adresaci lokální sítě používá primárně bezstavová konfigurace. Hlavním důvodem je kompatibilita, jelikož ne všechna zařízení podporují protokol DHCPv6. Dalším důvodem jsou chybějící vlastnosti u DHCPv6 serverů - např. zálohování jednoho serveru druhým (High Availability). Výjimku tvoří sítě ISP, kteří přidělují pomocí protokolu DHCPv6 prefix uživatelskému zařízení (CPE). Adresace CPE nicméně často probíhá bezstavově.

Při bezstavové konfiguraci si koncové zařízení vygeneruje samo náhodnou IPv6 adresu a správce sítě nad tím nemá kontrolu. Jakým způsobem ale zabránit podvržení adresy? Jakým způsobem zamezit útočníkovi, aby nepodvrhl záznamy v tabulce CAM přepínače?

ND-Snooping je technika, kterou je možné pro tyto účely použít. ND-Snooping se snaží na přístupovém přepínači vytvořit mapování mezi MAC a IPv6 adresou. Protože nemůže použít zprávy protokolu DHCPv6, snaží se mapování vytvořit odposlechem zpráv Výzva sousedovi a Ohlášení souseda (Neighbor Solicitation, Neighbor Advertisement - ekvivalenty zpráv ARP Request a ARP Reply pro IPv6). Před nakonfigurováním IPv6 adresy totiž zařízení ověřuje její unikátnost - zjednodušeně řečeno se ptá, zdali vygenerovanou adresu v síti již někdo nepoužívá. Pokud se mu do určité doby nikdo neozve, tak zařízení ví, že může adresu použít. Pokud tedy přepínač odchytne tuto počáteční výměnu zpráv, může si vytvořit mapování mezi vygenerovanou IPv6 adresou a MAC adresou.

Na zařízeních Cisco se mechanismus konfiguruje podobně jako RA-Guard: (možnosti příkazů se liší na jednotlivých platformách, tyto příkazy jsou pro 3750-X a 2960-S):

Switch(config)# ipv6 nd inspection policy POLICY-NAME
Switch(config-nd-inspection)# device-role {host | monitor | router}
Switch(config)# interface INTERFACE
Switch(config-if)# ipv6 nd inspection attach-policy POLICY-NAME

Opět vytvoříme politiku, kde definujeme typ zařízení (host je implicitní volba) a ta se pak aplikuje na jednotlivá rozhraní. Na základě odposlechu zpráv potom přepínač vytváří vazební tabulku, jak lze vidět na obrázku.

V případě, že by chtěl útočník připojený na portu Gi1/0/4 provést otrávení tabulky CAM například pro link local adresu FE80::200:FF:FE00:BOB, tak bude podvržená zpráva zablokována, jelikož neodpovídá adrese ve vazební tabulce.

Pro zařízení HP využívající Comware, lze ND snooping nakonfigurovat také, pomocí následujících příkazů:

[Switch] vlan 1
[Switch-vlan1] ipv6 nd detection enable
[Switch-vlan1] ipv6 nd snooping enable
[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] ip check source ipv6 ip-address mac-address

Zde si je ale třeba dát pozor, jelikož u zařízení HP nevytváří ND Snooping vazební informace z jakéhokoliv paketu Výzva sousedovi a Ohlášení souseda, nicméně pouze když se zařízení poprvé připojuje do sítě a testuje unikátnost vytvořené adresy (zdrojová IPv6 adresa je ::). Pokud tedy povolíte tento mechanismus v sítí kde jsou aktuálně připojená koncová zařízení, vypnete jim IPv6 konektivitu, dokud se znovu nepřipojí do sítě nebo si nevygenerují novou adresu. Je si také třeba pohlídat správnou verzi firmware. Některé verze (release 1211 a starší) nepodporovaly vytvoření IP - MAC - port databáze z link-local adres, což je problém, protože klient pak není schopen zjistit MAC adresu výchozí brány, která typicky používá pouze link-local adresu. Release 18xx tyto chyby opravil a je možné funkčnost aktivovat pomocí příkazů:

[Switch] ipv6 nd snooping enable link-local
[Switch] ipv6 nd snooping enable global

Na první pohled by se mohlo zdát, že s použitím ND-Snooping lze dosáhnout podobné míry zabezpečení jak je tomu u IPv4. Bohužel realita není tak jednoduchá. Problémem tohoto mechanismu je fakt, že přepínač netuší, jestli za připojeným portem je útočník nebo regulérní uživatel. U IPv4 to bylo snadné, tam jsme si vynutili, aby všechna zařízení získala adresu od centrální autority (DHCP serveru) a následně přepínač nakonfigurovali, aby pracoval pouze s informacemi přidělenými touto autoritou. Při bezstavové konfiguraci v IPv6 to ale funguje na principu - Kdo se první přihlásí na daném portu, ten je více důvěryhodný. Nasazení tohoto obranného mechanismu paradoxně otevírá vrátka pro útočníky, kteří pak mohou ostatním uživatelům zablokovat přístup do sítě tím, že si počkají až se jejich zařízení odpojí a pak si jeho adresu “zaregistrují” na svůj port. Pokud se zařízení s původní adresou opět připojí do sítě, nebude mu to umožněno, jelikož jeho adresu má již útočník v databázi IP - MAC zaregistrovanou pro jiný port. Díky tomu, že pakety budou zahozeny, neproběhne ani kontrola duplicity adresy. Zařízení si tedy ani nemůže vygenerovat novou adresu, jelikož neví, že danou adresu již v síti někdo používá. V principu se tomu nedá zabránit, protože se využívají zcela legitimních vlastností protokolu IPv6: a) rozhraní může mít více IPv6 adres; b) IPv6 adresu lze generovat nahodile; c) přepínač nemá při bezstavové konfiguraci žádnou autoritativní odpověď, jako měl u IPv4 při použití DHCP. Přepínač tudíž nemůže rozlišit, kdo má pravdu a kdo ne. Bohužel pro tento problém není aktuálně známo žádné řešení a nasazení mechanismu ND-Snooping tak může útočníkovi některé útoky zkomplikovat, ale nemůže mu zcela zabránit.

DHCPv6

V sítích, kde se pro autokonfiguraci využívá primárně protokol DHCPv6 je nutné, kromě zabezpečení Ohlášení směrovače pomocí RA-Guard, dořešit ještě ochranu protokolu DHCPv6. K tomuto je možné použít DHCPv6 Snooping, který funguje de facto stejně jako u protokolu DHCP. Snaží se tedy získat informaci o IPv6 adrese ze zpráv, které si vyměňují DHCPv6 klient a server. Pokud se mu to podaří, vytváří si vazební tabulku, kterou jsme viděli již dříve. Tato funkcionalita je podporována na zařízeních HP používající firmware ComWare, kde ji můžeme aktivovat pro danou VLAN následujícími příkazy.

[Switch] ipv6 dhcp snooping enable
[Switch] vlan 1
[Switch-vlan1] ipv6 dhcp snooping vlan enable
[Switch] interface GigabitEthernet 1/0/1
[Switch-GigabitEthernet1/0/1] ip check source ipv6 ip-address mac-address

Nejprve povolíme DHCPv6 snooping globálně, potom ho aktivujeme pro vybranou VLAN. Přepínač začne odposlouchávat DHCPv6 komunikaci a z výměny zpráv si vytvoří vazební tabulku. Nesmíme také zapomenout nastavit port vedoucí k serveru DHCPv6 jako důvěryhodný, aby nedošlo k zahození odpovědí od serveru.

[Switch] interface GigabitEthernet 1/0/2
[Switch-GigabitEthernet1/0/2] ipv6 dhcp snooping trust

Opět připomínáme, že je třeba použít novější firmware a také aktivovat mechanismus ND Snooping. Pokud totiž zapnete pouze DHCPv6 snooping a povolíte kontrolu adres IPv6 a MAC, tak klienty odstřihnete od IPv6 konektivity, jelikož nebudou moci používat link-local adresy - pro link-local adresy totiž samotný DHCPv6 snooping nebude moct vytvořit ve vazební tabulce žádný záznam.

Cisco zařízení jsou na tom s podporou DHCPv6 snooping vcelku bídně. Aby se vytvářela vazební tabulka, musí se aktivovat podpora pro DHCPv6 Guard, který je zatím podporován pouze u řad 4500, 4900, 7600. Tato zařízení jsou pro přístupovou vrstvu vcelku drahá a většinou se využívají jako přepínače vrstvy distribuční. Při nastavení se pak musí DHCPv6 Guard kombinovat s mechanismem ND Snooping, který jsme si popsali výše. Příklad nastavení lze nalézt v oficiální dokumentaci nebo na Insinuator.net.

PACL

Jednou z dalších možností, jak vyřešit zabezpečení Oznámení směrovače a protokolu DHCPv6, je nastavení filtru (ACL) na vstupním portu, kde je zařízení připojeno. ACL pak může vypadat třeba následovně:

Switch(config)# ipv6 access-list DENY-RA-DHCP
Switch(config-ipv6-acl)# deny icmp any any router-advertisement
Switch(config-ipv6-acl)# deny udp any eq 547 any
Switch(config-ipv6-acl)# permit ipv6 any any

Následně pak aplikujeme na rozhraní:

Switch(config)# interface INTERFACE
Switch(config-if)# ipv6 traffic-filter DENY-RA-DHCP in

Je třeba si ale pohlídat, jestli přepínač umí rozpoznat typ zprávy ICMPv6. U zamezení DHCPv6 většinou problém není, jelikož se jedná o standardní komunikaci protokolu UDP na portu 547.

Výhodou tohoto řešení je, že filtraci typicky zpracová hardware daného přepínače (více o této problematice si řekneme v dalším díle). Nevýhodou je, že pomocí tohoto řešení nelze zamezit útočníkovi podvrhávat adresy a páchat další útoky typu Man-in-the-Middle (MitM).

Ani tento přístup tak není zcela bez problému. Řada přístupových přepínačů navíc nepodporuje vůbec filtraci IPv6. Pokud už příslušná platforma filtry (ACL) pro IPv6 podporuje, je velice pravděpodobné, že bude rovněž podporovat RA Guard či základní podobu ND-Snooping a je tedy lepší použít přímo tyto mechanismy. V případě, že nemáme možnost nakonfigurovat obranné mechanismy na přístupových přepínačích, může přijít vhod některá z následujících možností.

Oddělení klientů

Vzhledem k tomu, že se problém týka pouze zařízení umístěných v jedné podsíti, tak se celkem logicky nabízí možnost síť dále rozdělit na více VLAN. V případě IPv6 máme adres pro vytváření podsítí relativně dost a z hlediska adresace by se tedy nemělo jednat o závážný problém. Možnosti útoku tímto sice neeliminujeme, ale výrazně tím omezujeme útočníkův manipulační prostor, resp. zmenšíme počet zařízení, které je schopen takto ovlivnit. Takový plán nám do značné míry znepříjemňuje současná koexistence sítí IPv4 a IPv6. Pokud nechceme mít dvě naprosto oddělené a nezávislé infrastruktury, musela by se rozdělit na více podsítí i síť IPv4. To by vedlo k přeadresaci, což je krok zpravidla velice bolestivý, a hlavně, rozdělení na více podsítí vede ke značnému plýtvaní s IPv4 adresami. Pokud bychom akceptovali myšlenku, že rozdělíme pouze síť IPv6, tak lze v ne-Cisco světě použít protocol-based VLAN - například tak, že na uživatelském portu si pouze IPv6 provoz přesměruji do unikátní VLAN pro daného uživatele. Zachováme tak stávající infrastrukturu pro IPv4 a klienty využívající IPv6 máme od sebe oddělené. Administrační náročnost celého procesu - hlavně pokud musíme pro dané podsítě nastavit zálohování výchozí brány např. pomocí VRRP - je extrémní. Stejně tak jsme limitování počtem VLAN, které přepínače zvládnou. Tomuto kroku se je tedy ve větší síti nejlépe vyhnout.

Použití privátní VLAN (RFC 5517) je někde na pomezí mezi rozdělením sítě na více VLAN a plnohodnotným řešením First-hop-security na přístupovém přepínači. V případě využití privátní VLAN degradujeme přístupový přepínač do role přeposílače paketů do nadřazené distribuční vrstvy. Koncová zařízení připojená ve stejném přepínači, byť jsou ve shodné VLAN, nedokážou potom komunikovat napřímo, ale data musí vždy putovat přes nějaký nadřazený prvek.

Tato funkčnost nicméně není podporována na čistě přístupových prvcích (např. řada Catalyst 2960), ale spíše na L3 (např. řada Catalyst 3560 a vyšší). Podobného účinku lze ale dosáhnout pomocí techniky označována jako Private VLAN edge, kdy uživatelským portům zamezíme komunikaci mezi sebou. Tato vlastnost navíc bývá podporována i na levných přepínačích. Funkčnost ilustruje následující obrázek. V klasické síti by komunikaci mezi klientem A a B odbavil přímo přepínač v přístupové vrstvě. Pokud ale použijeme některou ze zmíněných technik pro separaci klientů, komunikace mezi A a B půjde vždy přes přepínač v distribuční vrstvě.

Jistě si říkáte, k čemu je takový postup dobrý. Podpora bezpečnostních prvků pro IPv6 je totiž dostupná zpravidla až ve vyšších řadách přepínačů, které se spíše používají pro vrstvy distribuční nebo páteřní. Využitím Private VLAN edge tak můžeme koncová zařízení připojit prostřednictvím “hloupého” a tedy i levného přístupového přepínače, který všechna data předává nadřazenému “chytřejšímu” přepínači, který může zajistit náležitou filtraci procházejícího provozu.

Funkčnost lze zapnout u zařízeních Cisco pomocí následujících příkazů:

Cisco Switch(config)# interface INTERFACE
Cisco Switch(config-if)# switchport protected

Porty označené jako protected nemohou komunikovat mezi sebou napřímo. Jejich provoz je tudíž přeposlán na port, který takto označen není - typicky uplink.

U zařízeních HP využívající firmware ProVision lze obdobný filtr nastavit následovně:

HP Switch(config)# filter source-port 2-24 drop 2-24

Porty 2 - 24 nemohou komunikovat mezi sebou a jejich provoz bude přeposílán na port 1.

Je ovšem třeba ale upozornit na několik nevýhod tohoto řešení.

• Pokud zamezíme komunikaci mezi jednotlivými porty, tak zamezíme i komunikaci uživatelů mezi sebou. Řešením tohoto problému může být nastavením proxy-ARP na distribučním přepínači. Získáme tak separaci klientů na L2, kdy broadcast a multicast neprojde distribučním prvkem, nicméně unicast komunikace mezi klienty bude fungovat. U IPv4 sítě nám bude vše bez problémů fungovat, u IPv6 provozu je ale problém, jelikož např. zařízení Cisco nepodporují ND-proxy. Platforma HP s Comware tuto možnost podporuje.
• Data ze všech portů přístupového přepínače putují vždy na distribuční přepínač a zpět, a to i přesto, že za normalních okolností by byla odbavena v rámci jednoho přepínače. Toto řešení tedy můžeme použít v situaci, kdy je linka mezi distribučním a přístupovým přepínačem dostatečně dimenzovaná anebo charakter provozu je takový, že komunikace mezi zařízeními připojenými v jednom přepínači je minimální.

SEND

Dalším řešením, které bylo jistou dobu považováno za správné a koncepční, je použití kryptograficky podepsaných zpráv protokolu NDP - tedy Oznámení směrovače, Ohlášení souseda atd. Každý klient si potom může, na základě PKI, ověřit validitu těchto zpráv pomocí příslušného certifikátu. Samotná specifikace protokolu SEND pochází z roku 2005, přesto jsme se do dnešního dne nedočkali prakticky žádného rozšíření v existujících systémech. O protokolu se raději přestalo mluvit a dnes je sice občas zmiňován jako způsob zabezpečení lokální sítě, ale tězko bychom našli někoho, kdo by uvažoval o protokolu SEND jako o reálné možnosti pro zabezpečení současných lokálních IPv6 sítí. Je to dáno několika faktory. Jednak klade protokol SEND enormní administrativní nároky na provoz sítě - je nutná pravidelná obměna klíčů na směrovačích, distribuce certifikátů klientům, udržování PKI infrastruktury atd. Navíc se SEND nedá využít s adresami, které jsou nakonfigurovány manuálně, přiděleny pomocí DHCPv6 nebo vygenerovány s využitím privacy extensions. SEND vyžaduje vlastní formát kryptograficky generovaných adres (CGA), kterou si vytvoří dané zařízení. Pokud si ale zařízení vygeneruje vlastní CGA adresu, dostáváme se opět před klasický problém v síti IPv6, kdy nelze rozpoznat, jestli je daná IPv6 adresa útočníka nebo ne. Protokol tak dává smysl pouze pro ověření pravosti zpráv Ohlášení směrovače, nicméně aktuální trend je řešit tento problém spíše filtrací na úrovni síťové infrastruktury, jak jsme si popsali výše. V neposlední řadě je protokol patentován, což snižuje touhu výrobců protokol implementovat na svých zařízeních k nule. V současné době existuje implementace protokolu SEND pouze na zařízeních firmy Cisco (která patent vlastní). Edward Horley, autor knihy Practical IPv6 for Windows Administrator, nepředpokládá, že by Microsoft přidal podporu pro daný protokol a to i přes to, že za specifikací protokolu stojí lidi z firmy Microsoft. Existuje sice často odkazovaná verze WinSend, která od roku 2011 tvrdí, že přidala podporu daného protokolu pro Windows, nicméně, i přes proklamace autorů, do dnešního dne program ani kód nebyl zveřejněn. Pokud používáte systém Linux a chtěli byste si zabezpečit svou lokální síť, můžete zkusit volně dostupnou implementaci Ing. Lukáše Bezdíčka, kterou zpracoval ve své diplomové práci. V dané diplomové práci jsou také rozebrány současné implementace protokolu SEND, včetně těch, které se pouze tváří, že fungují.

Pasivní monitorování a aktivní protiútok

Pokud nemáme žádnou z uvedených možností, je více než vhodné zajistit alespoň pasivní monitorování. Jedna z možných technik je rozebrána v článku Ondřeje Caletky. Tento způsob monitorování je víceméně výhodné použít vždy, i pokud byste používali nějakou z technik popsaných výše - alespoň máte přehled, co se v síti děje. Dané nástroje pro monitorování falešných směrovačů se občas dají rozšířit o možnost "odregistrace" falešných prefixů. Síťový administrátor se tak vlastně stane útočníkem ve vlastní síti a použije techniku, kterou jsme si popsali v předchozím díle v části Zamezení konektivity. Tedy, pokud je detekováno falešné Ohlášení směrovače, zasílá se obratem zpět podvržené Ohlášení směrovače, ve kterém se nastaví dostupnost (Router Lifetime) falešného směrovače na 0. Tím se koncoví klienti donutí k odebrání falešného směrovače ze svých směrovacích tabulek.

Když dojdou všechny možnosti

V případě, že žádná z dříve popsaných možností pro vás nepřipadá v úvahu a nechcete nechat chod protokolu IPv6 ve vaší síti v rukou osudu, pak zbývají poslední dvě možnosti. První z nich je deaktivovat podporu IPv6 na koncových systémech. Tuto možnost ovšem máme pouze v případě, že dokážeme ovlivnit konfiguraci operačního systému na koncových zařízeních (například ve firemní síti). U systémů Windows to však není příliš doporučováno, protože IPv4 a IPv6 stack je u Windows zkombinován do jednoho. IPv6 tedy nelze kompletně vypnout. I přes toto doporučení se v řadě firemních prostředí setkáváme s politikou, kde maximální možné potlačování IPv6 je naprostou samozřejmostí a zatím nemáme informace, že by to mělo nějaký negativní vliv na funkčnost systémů. Výrazně složitější situace je například na mobilních platformách, kde IPv6 zpravidla není možné deaktivovat.

Druhou možností je blokace protokolu na portech přepínače tak, aby přepínač filtroval všechny pakety obsahující v hlavičce protokolu Ethernet identifikaci protokolu (EtherType) nastavenou na 0x86DD (IPv6). Tato filtrace musí být opět podporována přepínačem, což také nebývá vždy pravidlem. Pokud zařízení podporuje klasické IPv6 ACL, lze si vytvořit filtr zakazující IPv6 a aplikovat ho na jednotlivé porty přepínače.

Pro lepší orientaci v jednotlivých technikách zabezpečení lokální IPv6 sítě může pomoci následující tabulka.

¹ Podpora protokolu SEND je nutná pouze na příslušném směrovači.

Závěr

Společně s rozšiřováním protokolu IPv6 bychom měli brát na zřetel i ochranu IPv6 sítě, která by měla odpovídat bezpečnostní politice aplikované pro IPv4. Pokud v síti nemáme oba protokoly stejně zabezpečené, jakékoliv zabezpečení je pak vůči cíleným útokům vcelku bezpředmětné, protože ho útočník dokáže obejít přes druhý protokol. Zabezpečení protokolu IPv6 ale není záležitost úplně jednoduchá a v praxi musíme velice často volit nějakou formou kompromisního řešení mezi cenou zařízení, složitostí implementace a mírou zabezpečení. V případě existujících instalací se staršími prvky pak mnohdy skončíme u řešení s pasivním monitorováním a nadějí, že IPv6 útoky ještě po nějakou dobu nebudou dostatečně atraktivní pro páchání záškodnické činnosti. V případě nových instalací můžeme stát před relativně těžkou volbou. Buď ušetřit peníze a pořídit přístupové přepínače bez ochranných prvků IPv6 a zařízení s plnohodnotnou podporou koupit později, kdy jejich cena bude o něco příznivější. Druhá možnost je si připlatit a mít ochrané prvky pro IPv6 k dispozici už teď. Bohužel ani tato volba není v dnešní době plnohodnotnou ochranou proti některým typům cílených útoků. Na tyto problémy se ale podíváme v příštím díle.