Hlavní navigace

Změní IPv6 dnešní principy bezpečnosti?

6. 12. 2007
Doba čtení: 4 minuty

Sdílet

 Autor: 29
Letošní podzim byl poměrně bohatý na RFC související s IP verze 6. Částečně se jednalo o aktualizované verze starších specifikací (vyšla například revize bezstavové automatické konfigurace a objevování sousedů), částečně o zcela nové texty. Podívejme se dnes na jednu zajímavou.

Lehce depresivní RFC 4942 shrnuje bezpečnostní otázky související s přechodem na IPv6 a vzájemnou koexistencí obou protokolů.

Jedná se v podstatě o souhrn vlastností nového protokolu a souvisejících mechanismů, které by mohly způsobovat bezpečnostní problémy. Jako každý dokument podobného charakteru se nejedná zrovna o veselé čtení, jež rozhodně nedoporučují čtyři z pěti paranoiků.

Mimo jiné se v něm dočtete, že progresivní koncept rozšiřujících hlaviček představuje dost velký klacek hozený pod nohy firewallů, směrovačů a dalších zařízení, která by chtěla zkoumat obsah paketů během přepravy. Minimalizovaná pevná hlavička a přesun různých doplňkových a ne vždy využívaných informací do řetězce rozšiřujících hlaviček je sice lákavý a v praxi bude pro „normální“ datagramy slušně fungovat, ale skýtá zároveň nemalý prostor pro zneužití. Zlý odesilatel může úmyslně datagram napěchovat nejrůznějšími rozšiřujícími hlavičkami, aby zkomplikoval práci zařízením po cestě.

Například současné firewally často k posouzení přípustnosti datagramu využívají informaci o TCP či UDP portech, a tedy síťových službách. Jenže aby se k této informaci dostal v IPv6 datagramu, musí projít celý řetěz rozšiřujících hlaviček až na konec. A hned se objevuje několik nepříjemných otázek. Co když některou z použitých hlaviček nezná? Zahodit datagram? Pak ale může narušit činnost některého z nově definovaných mechanismů. Nevšímat si jí? To by mohlo znamenat narušení bezpečnosti. A co když je díky dlouhému řetězci hlaviček a použité fragmentaci hlavička transportní vrstvy odsunuta až do dalšího fragmentu?

Celkově se zdá, že firewally to budou mít v budoucím Internetu těžké. V souvislosti s IPv6 se očekává znatelný nárůst používání zabezpečeného přenosu dat mezi koncovými počítači díky IPsec. Obsah řady přenášených datagramů bude tedy zcela nedostupný. Autoři předpokládají, že pro IPv6 postupně vznikne bezpečnostní model významně odlišný od současného, kdy je typická síť chráněna na svém obvodu – její vstupní body představují firewally a/nebo NATy, které prolustrují vstupující a odcházející datagramy.

V budoucí bezpečnostní architektuře by měly hrát aktivnější roli koncové počítače. Vyvíjejí se nástroje pro zvýšení jejich důvěryhodnosti (trusted computing) i pro centrální správu bezpečnostních politik v rámci sítě a jejich distribuci koncovým strojům. Stávající hodně centralizovaný přístup by se měl proměnit na model podstatně distribuovanější. Místo pasivního spoléhání na ochranu firewallem na vstupu do místní sítě se o svou bezpečnost postará každý sám. S tím souvisí i návrat transparentnosti do sítě, který znamená na jedné straně prostor pro inovace, na straně druhé ale zvyšuje bezpečnostní rizika.

Také detekce neplech v síti bude muset přejít na jiné metody. Místo současného zkoumání obsahu paketů (které bude komplikovanější, či zcela nemožné) se nabízí analýza vzorců provozu a charakteru datových toků, tedy de facto vnějších příznaků.

Ale pokud se vrátíme od vizí zpět ke konkrétním varováním obsaženým v RFC 4942, najdeme v něm samozřejmě upozornění na možné způsoby zneužití směrovací hlavičky k obcházení různých omezujících pravidel či na možnost zneužití skupinových adres ke zjišťování zajímavých informací o „vnitřnostech“ sítě. Také ICMPv6 poskytuje zlým hochům a dívkám některé možnosti, například je lze zneužít pro výměnu informací mezi koncovou sítí a jejím okolím ve fiktivních chybových zprávách.

Samostatnou kapitolu představují útoky typ DoS či DDoS, které najdou živnou půdu v celé řadě konstrukcí – ve směrovacích hlavičkách, skupinově adresovaných ICMP zprávách či v ohlášení směrovače pro automatickou konfiguraci (útočník může ohlásit nulovou životnost pro adresní prefix, který síť používá). A ostatně i IPsec se hodí, pokud se cíl zahltí množstvím (špatně) zašifrovaných datagramů, jejichž zpracování jej zatíží podstatně víc než ty obyčejné.

Možný cíl různých útoků představují také tunely, jejichž prostřednictvím lze procházet ochrannými mechanismy. Proto je třeba důsledně testovat procházející datagramy na obou koncích. Výrazně horší situace je u tunelů automaticky navazovaných (které používá například 6to4 či Teredo), jejichž konce vznikají dynamicky, a jsou tudíž podstatně hůře kontrolovatelné.

BRAND24

Vzhledem k tomu, že nasazení IPv6 má stále ještě v řadě sítí charakter spíše experimentální, jejich zabezpečení mívá zhusta k dokonalosti daleko. Správci sítě se často spokojí s „ono to funguje“ a nedělají si komplikace s bezpečnostními opatřeními. Ostatně dostupné prostředky jim občas poskytují alibi, protože kvalitní implementace bezpečnostních prvků pro IPv6 stále ještě není samozřejmostí.

Zatím tento přístup celkem prochází a útoky vedené po IPv6 jsou spíše vzácností. To ale neznamená, že by k nim nedocházelo vůbec. Proto je rozhodně dobré otázku zabezpečení IPv6 nepodceňovat. Společně s autory textu bych vám doporučil publikaci IPv6 Deployment Guide [PDF, 5,49 MB], která vznikla jako nejvýznamnější výstup projektu 6NET a najdete v ní řadu informací, nejen o bezpečnosti.

Staráte se aktivně o bezpečnost svého počítače?

Byl pro vás článek přínosný?

Autor článku

Autor dělá nepořádek v příslovích, protože sítě nejen dělá, ale i učí a dokonce také řídí. Působí na Ústavu nových technologií a aplikované informatiky na Technické univerzitě v Liberci. Píše knihy.
Upozorníme vás na články, které by vám neměly uniknout (maximálně 2x týdně).