Tomáš Hála: Bezpečná VLAN v NIX.CZ
Tomáš Hála z Active24 začal svou přednášku tím, co bylo impulzem pro založení bezpečné VLAN v NIX.CZ: DDoS útoky z loňského roku. Podle jeho slov tehdy nešlo o nijak zásadně velký datový tok, přesto způsobil značné problémy v mnoha sítích. Zasáhly nás řádově jen stovky megabitů, ale bylo to obrovské množství malých paketů.
Ukázalo se, že nejde o útok z botnetu, ale provoz tekl z jediné sítě ruského poskytovatele RETN. Ten ale peeruje v NIX.CZ, takže pro nás šlo o český provoz.
Řešením nebylo se jednoduše odříznout od zahraničí a poskytovat služby dočasně jen českým uživatelům. Společnost RETN navíc nebyla příliš aktivní v komunikaci a zároveň chyběly informace o motivu. Když někdo zaútočí před Vánoci na e-shopy, je motivace jasná. Tady ale vůbec nebylo zřejmé, proč to někdo dělal.
Problémem podobných útoků je, že je velmi levné je vytvořit a velmi drahé se jim bránit. Vygenerovat řádově miliony paketů za sekundu je možné se serverem za třicet čtyřicet tisíc korun. Na jeho zvládnutí budete potřebovat firewall za dva miliony,
řekl Hála. Vlivem toho podobných DDoS útoků přibývá, běžně se setkáváme s toky v řádech stovek gigabitů, a bude hůř.
Takový útok zahlcuje infrastrukturu v koncové síti, což způsobí nedostupnost služeb všem uživatelům. Proto se používá technika RTBH, která umožňuje konkrétní provoz zahazovat ještě před tím, než dorazí do sítě. V případě zahraničního útoku je to jednoduché, odpojíte zahraniční konektivitu. Ovšem co v situaci, kdy útok přichází přes NIX.CZ, tedy z Česka?
Pro tento případ vznikla myšlenka Bezpečné VLAN, což je uzavřené prostředí, do kterého jsou přijímáni jen prověření členové NIXu, kteří splní předem daná bezpečnostní pravidla: BCP38, ochrana proti amplifikačním útokům, dodržování RFC 6192, funkční dohledové středisko, registrovaný CSIRT tým, podpora IPv6 a DNSSEC a smluvní ošetření zneužívání sítě vlastními zákazníky. Řada společností používá jako konkurenční výhodu to, že si zákazníci mohou na síti dělat, co se jim zlíbí. Takovou společnost ale nikdo v Bezpečné VLAN pochopitelně nechce.
Takto vytvořená VLAN pak zajistí ostrovní provoz v případě skutečně velkých útoků, kdy se budou muset členové VLAN odpojit od zbytku internetu. Pokud bude členů hodně, budete se moci v takové situaci ze svého domácího připojení dostat třeba ke své české bance nebo odeslat daňové přiznání.
Podle Hály je důležité, že se vůbec o bezpečnosti v NIXu mluví a že se aktivně pracuje na bezpečnostních projektech a opatřeních.
VLAN už existuje, zakládajících členů bylo zatím šest: Active24, CESNET, CZ.NIC, Dial Telecom, Seznam.cz a Telefonica O2. Důležité je, že se zapojili velcí hráči. Tím to celé získává na významu. Pokud dojde k problému, budou se moci všichni zákazníci O2 dostat na stránky hostované u Active 24, třeba na iHned.
Další členové prý „stojí ve frontě“ a mají zájem se přidat. Část členů vyčkává, co bude dál a nechtějí se zatím aktivně zapojit.
Zatím také chybí člen ze státní správy, což by podle Hály rozhodně nebylo v budoucnu od věci. Zhruba pět až deset subjektů by se mělo stát členy Bezpečné VLAN v další vlně.
Samotná implementace všech podmínek byla podle Hály poměrně jednoduchá, protože drtivá většina požadavků byla v Active 24 splněna předem. Bylo jen potřeba doladit podporu IPv6, zajistit se proti zneužití NTP a splnit několik dalších technických požadavků. Výhoda přípravy je v tom, že v případě skutečného útoku probíhá komunikace mezi klienty velmi rychle a ti jsou schopni pouhou změnou konfigurace rychle reagovat.
Proto bude členství přínosné při mnoha různých příležitostech, nejen u tolik diskutovaného ostrovního provozu. Ostrovní provoz je úplný extrém a došlo by k němu jen v případě opravdu velkých útoků, které jsme ještě nezažili,
uzavřel Hála.
Bronislav Robenek: IPv6 na Strahově
Bronislav Robenek je jedním z administrátorů na pražském Strahově. Ve své přednášce se zabýval především tím, jak byla v síti implementována podpora IPv6. Tou se zdejší síťaři zabývají už mnoho let, teprve teď je ale podle Robenka vše konečně uděláno stoprocentně funkčně a především bezpečně. Na začátku bylo vysvětleno, jak se na Strahově přidělují klasické IPv4 adresy – staticky. Když přijde nový student, jde za svým nejbližším registrátorem a ten si zapíše MAC adresu a přidělí mu statickou IP adresu, kterou pak uživatel síťuje.
IP adresu si pak uživatel nastaví sám nebo ji dostane pomocí DHCP. Bezpečnost je zajištěna už na L2. Pokud by z jeho portu přišel paket s jinou MAC adresou, port se odpojí a za 30 sekund se zkusí znovu připojit.
To znemožňuje připojení cizího zařízení k síti. Zároveň se na L3 hlídá používání IP adres a jsou nasazeny další bezpečnostní ochrany. Tento systém funguje plně automaticky, registrátoři jen naklikají nové uživatele, nastavení sítě proběhne automaticky.
IPv6 je dnes poměrně dobře podporovaný na straně velkých poskytovatelů obsahu, naopak problém je obvykle na straně uživatelů. Robenek se zmínil o největších rozdílech IPv6 proti IPv4. Například neexistuje broadcast, ale role multicastu byla výrazně posílena. Bez multicastu vám nebude fungovat třeba objevování sousedů, tedy náhrada za ARP.
Stejně tak byla posílena role linkových adres nebo se objevila novinka jménem router advertisement. Každý router vysílá do sítě oznámení o své existenci. Takových routerů může existovat víc a klienti si mezi nimi vybírají.
To nabízí jednoduchý způsob, jak vyřešit výpadky routerů. Klienti si jednoduše vyberou jiný router.
Novinkou je také přidělování IPv6 adres. Existují dvě možnosti: autokonfigurace pomocí SLAAC a DHCPv6. V případě SLAAC si klient doplní prefix (který dostane od routeru) o svou MAC adresu. Uživatelé se ale začali bát o své soukromí, protože v každé síti mají stejný suffix. Proto přišlo rozšíření zvané privacy extension, které umožňuje klientům vygenerovat si adresu libovolně. To je pro klienta fajn, ale z hlediska správce sítě je to průšvih. Pokud potřebujete v síti zajistit identifikaci uživatele, máte problém, protože klienti mají náhodnou adresu, která se navíc často mění.
Druhou variantou je DHCPv6, který sice funguje podobně jako DHCPv4, ale v dotazu na server neputuje klientova MAC adresa. Není proto možné přidělovat IP adresu na základě MAC adresy. Druhým problémem je, že DHCP nepřiděluje výchozí routu. To je sice možné obejít kombinací s RA, ale i tak nejde o ideální řešení.
Na Strahově bylo zvoleno a nasazeno zajímavé řešení, které umožňuje DHCP serveru přidělovat v6 adresy podle MAC. My jsme si na Strahově vybrali DHCPv6 a podařilo se nám obejít omezení s přidělováním adres pomocí MAC. Funguje nám to dobře už tři měsíce.
Prioritou bylo především to, aby změna nijak neovlivnila uživatele a aby byla správa i bezpečnost stejná jako u IPv4. Zase přidělujeme IP adresy a používáme MAC port security.
Novinkou je RA guard, který zakazuje ohlašování routeru z klientského počítače. To často dělají Windows, které si udělají tunel a pak do něj stahují okolní IPv6 provoz.
Konkrétně bylo použito řešení zvané dhcpy6d, což je implementace DHCPv6 napsaná v Pythonu. Celé to má jen 1360 řádků a dá se to krásně upravovat, což jsme přesně udělali.
Ve všech 50 klientských VLAN poslouchá DHCP server, který má tabulku párující link local adresy s MAC adresami zařízení. Při příchodu požadavku na DHCPv6 se vyvolá komunikace s použitou lokální adresou (pošle se ping) a tím se vyvolá zjištění MAC adresy pomocí neighbour discovery. Takto je zjištěna MAC adresa klienta, ke které pak DHCPv6 umí přidělit IP adresu z databáze.
Na Strahově byla IPv6 zprovozněna už před mnoha lety, ale podle Robenka nikdo nikdy neřešil bezpečnost. Teď klienti konečně bezpečně a spolehlivě síťují po IPv6 a adresy můžeme přidělovat pomocí MAC adres.
Navíc vše funguje ve většině případů i když nastanou problémy. Když RA vynucuje použití DHCPv6 a klient ho neumí, tak jednoduše nedostane IPv6 adresu a síťuje dál jen na IPv4. Připojení mu funguje dál.
Server dhcpy6d je naprostou novinkou, kterou napsal Henri Wahl na univerzitě v Drážďanech. Co víme, je to nasazeno jen ve dvou sítích. Autor má v Drážďanech síť s 600 klienty, my na Strahově máme asi 4000 klientů.
Problémem zatím zůstává WiFi, kde je na Strahově IPv6 vypnutá. V současnosti pro nás neexistuje řešení, které by na Wi-Fi zajistilo obdobné IPv6 zabezpečení jako na IPv4. Není možné snadno zajistit, aby uživatelé síťovali pouze ze svých adres. Snad na tom výrobci W-Fi řešení zapracují,
uzavřel přednášku Bronislav Robenek.
Pavel Šnajdr: kontejnerová virtualizace
Pavel Šnajdr z vpsFree.cz mluvil právě o tom, čím se toto sdružení zabývá: virtualizací. Nejznámější je hypervizorová virtualizace, kterou prosazuje například VMware, což je společnost ovládající 89 % komerčního virtualizačního trhu. I velké firmy se ale nyní začínají zajímat o kontejnerovou virtualizaci. Hlavním rozdílem je, že pod hypervizorem jsou spouštěny celé operační systémy včetně jádra a všech knihoven, zatímco kontejnery sdílí operační systém a oddělují se jen části uživatelského prostoru. Nemůžete tak spouštět jiný operační systém a je na společném jádře, aby tyto prostory oddělilo.
Není tak potřeba například emulovat hardware či jej paravirtualizovat, všechny aplikace stále komunikují s hardware přes standardní rozhraní operačního systému.
Další výhodou je pohodlnější správa paměti, kdy není potřeba pevně přidělovat části fyzické paměti jednotlivým virtuálům, ale je možné efektivně přidělit tolik paměti, kolik je právě potřeba. Když některý kontejner část paměti uvolní, jádro se to dozví a může ho okamžitě přidělit jinému kontejneru.
Další nevýhodou hypervizoru je nutnost podpory na straně hardware. To přináší velkou závislost na podpoře hardware a každá nová generace procesorů přidává berličku pro nové funkce hypervizorů.
Naopak kontejner je možné spustit kdekoliv, kde běží jádro daného systému.
Mezi dalšími výhodami byl zmíněn bleskový start kontejnerů, výrazně efektivnější využití hardware a minimální spotřeba prostředků. Naopak mezi nevýhody patří sdílené jádro, jehož chod nemohou uživatelé kontejnerů ovlivňovat a které nemusí podporovat všechny funkce. V OpenVZ chybí například podpora pokročilejších iptables modulů nebo bezpečnostních modulů. Oficiální stanovisko vývojářů SELinuxu je, že když chcete oddělit procesy, máte si založit další kontejner.
Podle Pavla Šnajdra může dnes většina internetu běžet na kontejnerech. Reálně se to děje, pokud jdete hledat na Google nebo používáte Facebook, používáte kontejnery.
Navíc se využívání kontejnerů stále rozšiřuje. Hlavním důvodem je tu už zmíněné šetření zdrojů, které velké firmy zajímá.
S kontejnery začalo v roce 1998 FreeBSD 4, které přišlo s Jails. Tři roky na to se v Linuxu objevil vServer, což byla podle Šnajdra první použitelná kontejnerová virtualizace pro Linux. V roce 2005 pak vzniklo OpenVZ, které je dnes postupně přetvářeno do podoby LXC. OpenVZ je dnes nejlepší varianta pro Linux, ale LXC je budoucnost kontejnerové virtualizace.
Zbytek přednášky se zabýval právě současnému řešení OpenVZ. Říká se, že jde o nestabilní řešení. Není to pravda. Vyzkoušejte si to.
Naopak podle Pavla Šnajdra je na OpenVZ strašidelné, že jde o několikamegabajtový patch do jádra, který na všechna důležitá místa přidává kontrolu související s použitím kontejneru. Současná verze je postavená na linuxovém jádře 2.6.32. Přestože je to tak stará verze, spustíte v ní libovolnou linuxovou distribuci.
Z hlediska uživatelských funkcí je podstatná podpora podstatných funkcí v kontejneru: funguje NFS (klient i server), VPN (tun/tap), FUSE, IPSec a další. Výbornou funkcí je checkpointing, což je ukládání stavu konkrétního kontejneru pro pozdější použití. To se hodí například při živé migraci mezi různým hardware, jen je potřeba zajistit, že na obou serverech běží stejné jádro.
Ondřej Caletka: Provozování DNS
Ondřej Caletka pracuje ve sdružení CESNET jako správce DNS. Na začátku své přednášky vysvětlil, že v DNS existují tři různé entity: stub resolver, rekurzivní resolver a autoritativní server. Stub resolver umí jen položit dotaz rekurzivnímu, který se pak dotazuje u autoritativních serverů.
Caletka pak popsal princip, jakým je celý dotaz vyřízen, aby klient získal v odpovědi IP adresu.
Stub resolver je velmi jednoduchá funkce, která je v Linuxu implementovaná v GNU C knihovně. Má minimální cache a není příliš robustní. Obvykle je to tak, že pokud vám vypadne první rekurzivní server, který máte v konfiguraci, stane se váš počítač nepoužitelným. Přestože je DNS vytvořen tak, aby k tomu nedošlo.
Podle Caletky je navíc změna linuxového stub resolveru v nedohlednu. Vývojáři GNU Lib C jsou velmi konzervativní a nechtějí do této funkce příliš zasahovat.
Rekurzivní server už je výrazně komplexnější, musí být schopen vyhledat odpověď a reagovat na řadu různých situací. Když třeba dva ze tří autoritativních serverů obsluhujících konkrétní doménu nefungují, vy to obvykle ani nepoznáte.
Součástí rekurzivních serverů je také agresivní cache, která celou jejich funkci zrychluje.
Rekurzivní server potřebuje každý poskytovatel připojení a hlavních implementací existuje několik. Tou nejběžnější je BIND, jehož alternativou je Unbound. Na rozdíl od BIND umí fungovat jen jako rekurzivní server, nemá autoritativní funkce.
Další variantou je PowerDNS, který ale v rekurzivním režimu neumí DNSSEC. Proto bych vám ho nedoporučil, v dnešní době je to škoda.
Dále byl zmíněn Dnsmasq, který je slavný tím, že je nainstalován na mnoha domácích routerech a je často zneužíván k zesilujícím DNS útokům. Je to nejčastější DNS server otevřený do internetu a někteří poskytovatelé s tím mají velké problémy.
Vysoké dostupnosti rekurzivních serverů je možné dosáhnout pomocí anycastu. Více routerů má stejnou IP adresu, ale dotaz je doručen vždy jen jednomu z nich. Nedávno jsme to takto nasadili v síti CESNET.
Na DNS serverech v různých datacentrech je nainstalovaný démon BIRD, který oznamuje do sítě IP adresu z rozsahu /32. Pokud některý server vypadne, BIRD ho přestane ohlašovat do sítě a uživatelé začnou využívat ten druhý a ničeho si nevšimnou.
Autoritativních serverů existuje podstatně více implementací než těch rekurzivních. Opět je možné využít BIND, případně čistě autoritativní server NSD. Tyto dva jsou používány v kořenové zóně a využívá je většina TLD registrátorů.
Českým projektem je Knot DNS, který se zaměřuje na rychlost práce s obrovskými zónami. Zatímco třeba běžný web hosting má tisíce zón s několika málo záznamy, registrátor má obvykle jednu zónu s miliony záznamu.
Podle Caletky jde sice o mladý projekt, ale je už ve velmi dobrém stavu.
Dalšími zajímavými projekty jsou nová YADIFA a PowerDNS. Ten je oblíben u hostingů, protože umí posílat data z databáze v reálném čase, není ale nasazen na žádné TLD.
Důvodem je prý jeho nestabilita. Pokud se pokusíte ho nasadit na velké zóně, tak spadne. Není připraven na velké škálování.
To ale vůbec nevylučuje jeho použití na běžných zónách, kde funguje velmi dobře. Tím končí seznam opravdu dobrých autoritativních serverů, žádný jiný bych vám nedoporučoval.
Ondřej Caletka se pak věnoval podepisování zóny pomocí DNSSEC. Jediný server, u kterého stačí zapnout volbu a vše se zařídí samo, je PowerDNS.
U ostatních serverů je potřeba minimálně vygenerovat klíče určené k podepisování. Zóny se pak mohou podepisovat až na vyžádání nebo se podepíší předem a pak se už jenom distribuují. Takto fungují všechny TLD, které znám.
Na konci přednášky byly zmíněny nejčastější problémy při provozu DNS serverů. Často se například kombinuje autoritativní a rekurzivní server na jedné IP adrese.
Obvykle administrátor nasadí BIND a nechá jej plnit obě funkce. V takovém případě například server neprovádí validaci DNSSEC. Odpověď přijde z autoritativního serveru, který nevaliduje, protože věří datům z disků.
Další problém může nastat, když dojde ke změně poskytovatele, který na svém serveru zónu nevymaže. Jeho klienti pak používají staré informace skrze rekurzivní server a například pošta od nich pak dochází na starý server u původního poskytovatele,
popsal Caletka nejčastější problémy, se kterými se můžeme v praxi setkat.
