Matěj Grégr: (Ne)bojím se IPv6!
Matěj Grégr je jedním ze spoluautorů seriálu Pohněme s IPv6, který vycházel před časem na serveru Lupa.cz. Jeho pohled na IPv6 je velmi kritický, protože jej spravuje ve velké síti a vnímá především rizika s takovým provozem spojená. Grégr se na začátku své přednášky opřel do obhájců a nekritických propagátorů šestky. Podle popularizátorů je většina bezpečnostních rizik z IPv6 známá už z IPv4. Obrázek nechť si každý udělá sám,
začal svou přednášku Matěj Grégr.
Síťový administrátor se mimo jiné v síti na nejnižší úrovni stará o to, aby uživatel dostal správnou adresu a aby si jiný uživatel tuto adresu nemohl zabrat. Bráníme se man-in-the-middle útokům a chráníme síťové prvky.
Na IPv4 se můžeme na přepínači bránit technikami jako například DHCP snooping, ARP protect/IP lockdown. Ty chrání ARP tabulku tak, aby do ní útočník nemohl podvrhnout falešné údaje. Ve výsledku má do sítě přístup jen klient, který je povolen na DHCP serveru. To nás chrání před útočníky, chybami v konfiguraci nebo třeba vadnými ovladači síťových karet.
V IPv6 je rozdíl zejména v tom, že podporuje bezestavovou konfiguraci a síťové rozhraní může mít více IPv6 adres. Konfigurace jednoho klienta je v IPv6 složitější, protože kombinuje stavovou a bezestavovou konfiguraci a přidává další vlastnosti.
Navíc se kvůli chybějícímu broadcastu zařízení musí přihlásit do multicastových skupin, aby mohlo odebírat konfigurační zprávy. Nakonec řešíme stejnou věc výrazně složitější cestou.
Konkrétně je možné útočit například pomocí DAD útoku. Jde o formu DDoS útoku, kdy útočník na všechny dotazy na adresy odpovídá, že jsou už využívány. Nakonec to zařízení po opakovaném neúspěchu vzdá a my tím znemožníme jeho připojení do IPv6 sítě. Windows to zkouší třikrát, Linux DAD úplně ignoruje a CISCO směrovače adresu nepoužívají.
Pro tento útok je možné použít automatizovaný nástroj thc-toolkit.
Dalším zmíněným útokem je Router Advertisement flood, kdy se do sítě posílá velké množství RA paketů. Klienti si pak ve své směrovací tabulce musí pro každou adresu založit záznam.
Různé systémy se k velkému přetížení RA staví různě: Windows se neúnosně zpomalí nebo dokonce zamrznou, Linux útok ustojí. Linux je obvykle nastaven tak, že může do paměti uložit maximálně 30 záznamů a další nepřijímá.
O tomto problému se podle Grégra ví nejméně tři roky.
Kromě DDoS je možné zaútočit sofistikovaněji pomocí MitM. Většina systémů má dnes ve výchozím stavu podporu IPv6 zapnutou, takže jsou tímto útokem ohroženy. Klientovi pomocí RA řekneme, ať si informace zjistí od DHCPv6, který ovládáme. Tam můžeme například nadiktovat vlastní DNS servery a tím přesměrovat provoz.
Tento útok je možné realizovat i na čistě IPv4 sítích, protože předstíráme, že v síti IPv6 je.
Podle Grégra existují dvě až tři metody obrany. Jedním z nich je SeND, který umožňuje podepisovat NS/NA zprávy, tedy zprávy sloužící pro ARP. Je ovšem nutné vnutit klientovi platný certifikát. Administrační složitost je obvykle ale taková, že je nasazení SeND nereálné. Navíc to nikdo nepodporuje.
Druhým způsobem je RA guard, který je podobný DHCP snoopingu. Zahazuje falešné RA zprávy, které síťový administrátor nechce. I tuto obranu je ale možné poměrně snadno obejít. Je možné využít vlastnost IPv6: zřetězené hlavičky. Těch je možné použít víc a přepínače mají omezené zdroje k jejich parsování.
Většina přepínačů zkontroluje jen několik prvních hlaviček a zbytek ignoruje. Koncový klient pak provede kompletní rozparsování a za hlavičkami objeví RA, které použije.
Stejným způsobem je možné obejít i ACL pravidla. Přepínač má opět limitované parsovací zdroje, takže stačí dostatečně zřetězit hlavičky a je možné prorazit ACL. Předvedena byla blokace SSH provozu, která byla překonána pomocí upraveného jaderného modulu a zřetězení tří hlaviček. Tento útok funguje na přepínačích HP, CISCO si s tím poradí líp. Tam si ale zase můžeme pomoci fragmentací paketů. Pokud je payload ve druhém paketu, přepínač se nemůže rozhodnout pomocí prvního paketu a obvyklá politika je celou komunikaci propustit.
Problémem nových bezpečnostních prvků je také jejich vysoká cena. Při nákupu zařízení se 150 gigabitovými porty se náklady podle Grégra zvýší o 150 %, pokud pro IPv6 trváme na všech bezpečnostních vlastnostech, které máme k dispozici na IPv4. Získám tak stejně bezpečnou síť s politikou, kterou mi ale stejně útočník projde.
IPv6 tak může podle Grégra přinášet úplně nové bezpečnostní problémy. Bezpečnostní politiky pro IPv4 se například automaticky neaplikují na IPv6. Vše je tedy potřeba konfigurovat dvakrát, včetně firewallu, IDS a podobně. Všechny politiky by měly být shodné s IPv4.
Dalším problémem jsou tunelovací mechanismy, které není většina zařízení schopna filtrovat. Firewally a IDS se obvykle neumí dívat dovnitř tunelů. Provoz z nich je pak přeposlán běžně do světa, kde se vybalí a dále použije.
Při implementaci IPv6 je tak potřeba uvažovat nad tím, v jaké síti nasazení probíhá. Zatímco univerzitní prostředí je vcelku otevřené a je neatraktivní pro útok, firmy nesou podstatně vyšší riziko. Podle Matěje Grégra není nutné IPv6 zakazovat, ale je potřeba se s ním dobře seznámit a znát rizika.
Jan Včelák: Snadné nasazení DNSSEC s Knot DNS
DNSSEC začal vznikat v roce 2005 a pomocí kryptografie s veřejným klíčem zajišťuje autentizaci a integritu dat. Chrání uživatele před DNS spoofingem, tedy podvržení informace v odpovědi. Útočník tak může přesměrovat uživatele na falešný server. DNSSEC má celý tento problém eliminovat,
vysvětlil na začátku přednášky Včelák.
Poté se přednáška věnovala detailům implementace DNSSEC, jednotlivým záznamům a jejich roli při ověřování údajů v zónách. Podrobně jsme se této problematice věnovali v seriálu Seriál DNSSEC a bezpečné DNS.
Výhodou je zajištění bezpečnosti DNS, ale podpora musí být součástí resolveru. V Linuxu tomu tak není, ale je možné si nainstalovat třeba Unbound nebo požádat o podporu svého poskytovatele.
Další nevýhodou je bobtnání zóny, na které navazují zesilující útoky využívající dramatického rozdílu mezi velikostí dotazu a odpovědi.
Čtěte: Bezpečný DNS server s podporou DNSSEC za dvě minuty
Další problémy vznikají při implementaci, kdy je potřeba se starat o podepisování, generování klíčů, jejich rotaci a podobně. Nejjednodušší je ruční podepisování, ke kterému stačí použít správné utility, vygenerovat klíče a automaticky zónu podepsat.
Průkopníkem tohoto způsobu je server Bind.
Lepším způsobem je automatické podepisování pomocí OpenDNSSEC. Jde o poměrně robustní řešení, protože stojí mimo DNS server a případná chyba neovlivní server samotný.
Nevýhodou je, že nepodporuje DDNS, takže není možné v reálném čase měnit záznamy v zóně.
Na konci přednášky byla předvedena nová schopnost serveru Knot DNS verze 1.4, která vyšla nedávno v první betaverzi. Ta umí automaticky podepisovat zóny jen na základě předložených klíčů. Stačí k tomu v konfiguraci zapnout dvě volby. Automaticky se tak vytvoří všechny podstatné podpisy při načítání zóny.
Plány pro další vývoj jsou už v CZ.NIC vymyšlené. Chceme vytvořit alternativu k OpenDNSSEC a dotáhnout automatickou správu klíčů na základě politiky.
Nakonec by měla vzniknout knihovna, která tyto funkce implementuje nezávisle na DNS serveru. To vše by nás mělo snad čekat už ve verzi 1.5.
Bedřich Košata: Turris – otevřený domácí router made in Czech Republic
Bedřich Košata ze sdružení CZ.NIC přišel představit projekt routeru Turris. Název latinsky znamená věž. Ty se stavěly kvůli rozhledu po krajině, aby bylo možné zjistit, zda se neblíží nějaké vojsko nebo další nebezpečí,
vysvětluje název a poselství projektu Košata. Samotný router není cílem, nýbrž pouze prostředníkem.
Abychom mohli domácím uživatelům pomoct, potřebovali bychom vědět, co se u nich děje. Nabídneme jim tedy sondu, která bude sedět na jejich síti a analyzovat provoz.
Cílem projektu je tedy sledování síťových trendů a například i průběh šíření malwaru. V routeru budeme analyzovat, co se děje a až při zjištění anomálie odešleme data na centrální server… Umožní nám to odlišovat lokální události od událostí s širším dosahem,
popisuje Košata.
„Všemocný“ a chytrý router pochopitelně vzbuzuje obavy o soukromí uživatelů. Košata ale ujišťuje, že jsou bezpředmětné. Zařízení totiž bude řešit pouze hlavičky paketů, nikoliv jejich obsah. CZ.NIC navíc slibuje, že číslo routeru v systémech sběru dat nebude spárováno se jménem uživatele a data se budou skladovat jen po krátkou dobu. Dlouhodobější uchovávání dat bude možné pouze v kompletně anonymizované podobě.
Od začátku bylo jasné, že operačním systémem bude Linux. Vybrali jsme OpenWrt, linuxovou distribuci zaměřenou na routery. Obsahuje všechny záležitosti, které potřebujeme.
OpenWrt to ale samozřejmě bude řádně upravené a obohacené například o vlastní monitor síťového provozu ucollect nebo systém pro vzdálenou správu nuci (založen na netconfu). Připravena je také podpora DNSSEC a počítá se s automatickými aktualizacemi systému.
Původně jsme na trhu chtěli vybrat vhodné zařízení, případně se s některým výrobcem domluvit na výrobě speciální sady. Narazili jsme ale na to, že domácí routery jsou optimalizované na cenu a není tam žádná rezerva,
popisuje Košata potíže při hledání vhodného hardwaru. Většina domácích routerů má paměť od 32 do 128 MB, ty nejlepší potom i 256 MB. Ani to by do ale budoucna nejspíš nebylo dostatečné.
Proto se v CZ.NIC rozhodli pro návrh vlastního routeru.
Zařízení to bude opravdu špičkové. S dvoujádrovým PPC procesorem o taktu 1,2 GHz, 2 GB operační paměti a 256 MB flash paměti pro uložení systému a dat. Jako porty budou k dispozici 1 WAN, 5 LAN, 2 USB 2.0 a microUSB určené pro přístup do konzole. WiFi nakonec bude řešeno kartou v miniPCIe slotu, to aby jej do budoucna bylo možno snadno vyměnit či nahradit novějším modelem. Krom toho router bude umět i takovou specialitu jako například regulaci intenzity LED diod. Celý návrh bude open-source.
Koncem tohoto roku by v Česku měla proběhnout výroba tisíce kusů routeru. Výrobní náklady se pohybují kolem 9 tisíc korun za kus. Jednak kvůli výkonnému hardwaru a jednak kvůli tomu, že výroba v tak malém objemu je velmi nákladná. CZ.NIC ovšem nabídne Turris k pronájmu za pouhou 1 Kč s možností kdykoliv vypovědět smlouvu. Podmínky? Nezasahovat do sběru dat, jinak si s routerem můžete dělat prakticky cokoliv. Nelze se tedy divit, že počet zájemců již onen tisíc značně převyšuje. Stále se však můžete registrovat a doufat, že se na vás usměje štěstí.
Václav Pavlín, Lukáš Nykrýn: Cool „fičury“ v systemd
Poslední přednáška, o které se v dnešním článku zmíníme, se věnovala zajímavým vlastnostem systemd, o kterých uživatelé příliš nevědí a přitom dokáží zjednodušit život. Jako první byl zmíněn Journal, který má za úkol nahradit syslog moderním databázovým logovacím systémem zachovávajícím kontext. V syslogu je informace uložena jen jako jeden řádek textu bez kontextu, který jste ztratili při uložení této informace a musíte jej dodatečně dohledávat.
Journal umožňuje získávat z databáze informace například podle jednotlivých procesů.
Journal je se Systemd velmi úzce svázán. Systemd bez Journalu bude fungovat, ale nebude to úplně ono.
Výhodou jeho používání je, že na rozdíl od syslogu běží od úplného začátku až po vypnutí systému. Ukládá informace pocházející ze startu jádra, initramfs a funguje po celou dobu běhu systému. Pokud se v systému objeví nějaký problém, obvykle je to při bootu nebo při vypnutí. V Journalu máte podrobné záznamy ke zkoumání.
Ovládací utilita journalctl pak nabízí možnost vypsání informací podle různých kritérií jako je PID procesu, druh události, datum nebo kontextu SELinuxu. Je možné si nechat vypisovat i aktuálně přicházející záznamy, které mohou být opět omezeny třeba na konkrétní aplikaci.
Další část přednášky se věnovala Control Groups, tedy jadernému mechanismu schopnému slučovat procesy do skupin a vytvářet hierarchii. Různým skupinám můžeme přiřazovat různé vlastnosti jako je spotřeba paměti nebo maximální využití procesoru.
V současné době se nejčastěji CGroups ovládají pomocí virtuálního souborového systému a přímého zápisu do souborů a vytváření adresářů.
V současné době je podle přednášejících v CGroups zmatek, může existovat několik nezávislých stromů, jeden proces může být ve více stromech a různé procesy mohou zasahovat do nastavení. Do jádra se dostávají úpravy, jejichž cílem je tento problém vyřešit, bude existovat jen jeden strom a starat se o něj bude jediný proces.
Vznikne tak množina slices, tedy konfiguračních kontextů, ve kterých se jednotlivé procesy mohou nacházet. Tyto kontexty pak definují omezení pro jednotlivé procesy.
Další zajímavou novinkou jsou kontejnery, které dovolují oddělovat prostředí jednotlivých aplikací. Kontejner systemd-nspawn je chroot na steroidech.
Hlavní výhodou proti plné virtualizaci je nižší náročnost na paměť a rychlejší správa, protože nemusíme pracovat s celými virtuálními operačními systémy. Velmi užitečné je to při vývoji nebo testování. Když se něco rozbije, smažete si rozbitý nspawn a vytvoříte si nový.
Nejde ale o řešení nasaditelné třeba v produkci na serveru, podle přednášejících jde spíše o nástroj pro vývojáře.
