Tomáš Košňar: architektura připojení pro kritické služby
Kritické služby jsou ty, které jsou pro uživatele důležité. Mají obvykle široký záběr mezi uživateli.
Klíčem k tomu, aby tyhle věci fungovaly, je správa v rukou kompetentních lidí. Ďábel je skrytý v detailech.
Péče je zpravidla soustředěna na vlastní aplikaci, ale zapomíná se na celý řetězec mezi uživatelem a službou. Musíme mít v ruce strategii, podle které rozložíme zátěž na jednotlivé články řetězu.
Typicky jsou to: připojení k internetu, router, firewall, balancer a pak samotná služba. Často se dělá chyba v tom, že se nikdo nestará o celek, ale každý dodavatel si řeší svou část. V extrémních situacích to ale pro uživatele přestane fungovat.
Pokud správce přemýšlí nad celým řetězcem, může se zabývat řízenou regulací a v případě extrémního provozu je možné například zahazovat data podle připravené strategie a je možné udržet situaci pod stanovenými limity. Služba pak nemusí být dostupná pro všechny uživatele, ale máme kontrolu nad tím, pro koho podle naší strategie dostupná je.
Důležitou součástí strategie správy kritické služby je dobrý monitoring. Kdo nemonitoruje, prakticky neví nic o tom, co se mu v síti děje.
Je možné tak odhalit slabá místa. Důležité je časové rozlišení, ve kterém sbíráme data. Při příliš nízkém rozlišení totiž nevidíme krátké extrémní špičky, které například mohou překračovat kapacitu firewallu.
Podle Tomáše Košňara přitom není pro monitoring potřeba mít drahé nástroje, obvykle stačí Nagios, který sleduje input discards. Už to je základní indikace nějakých problémů. Člověk, který myslí, dokáže s open-source zázraky.
Provozovatel aplikací obvykle vnímá centralisticky svou službu, ale nevnímá komplexní hledisko topologie. Slabá místa obvykle vznikají v místě, kde se část infrastruktury sdílí.
V neposlední řadě je nutné se zamyslet na závislosti na dalších službách. Řešme služby vždy komplexně, vytvořme si podmínky pro možnost samostatného ošetření jednotlivých služeb.
Karel Kočí: Wi-Fi roaming a open source
Karel Kočí pracuje na projektu Turris a mimo jiné sleduje, jak dobře funguje bezdrátová část. Uživatelé nám často říkají, že by jim hodně pomohlo, kdyby jim dobře fungoval roaming.
K tomu se používá standard 802.11r, který umožňuje hladký přechod mezi různými přípojnými body v jedné síťové doméně.
Nepomůže to při úvodním navazování spojení, ale zrychlí to roamování.
Řeší se především problém předání šifrovacích klíčů, aby se uživatel mohl plynule přesouvat a nemusel se vždy znovu asociovat k jinému AP. Jednotlivé body na sebe musí v síti vidět a klíče si mohou vyměňovat bezdrátově nebo po drátové síti.
Podpora je součástí OpenWRT, respektive hostapd. Do všech propojených AP je potřeba vložit konfiguraci, ve které jsou informace o ID jednotlivých routerů a jejich šifrovací klíče. Router si pak najde svůj klíč a ví, jak je možné ho kontaktovat při přesunu k němu a jak je možné komunikovat s ostatními AP.
Karel Kočí provedl i měření na 5GHz Wi-Fi s OpenWRT pomocí iperf3. Sledoval přitom, jaké nejvyšší rychlosti může dosáhnout. K přepnutí mezi různými AP došlo v době kratší než 100 ms, při vypnutí roamingu se čas prodloužil. Vyplatí se vůbec takovou věc zapínat?
Většina Wi-Fi klientů není příliš ochotná roamovat a snaží se držet současné sítě. Pokud roaming zapnete, je například Android ochoten hladce se mezi AP přesouvat.
Standardu musí rozumět i klient, aby byl schopen jej využít. Například Windows a macOS neroamují, ale Linux, Android a iOS mají podporu dobrou.
Karel Tomala: měřící infrastruktura pro měření služeb elektronických komunikací
ČTÚ staví komplexní měřicí infrastrukturu MSEK, která je zaměřena na kontrolu a ověřování vybraných parametrů datových služeb elektronických komunikací. Máme povinnost dohlížet na plnění nařízení 2O15/2120 k síťové neutralitě, které říká, že poskytovatelé přístupu k síti internet by měli jasně a srozumitelně definovat rychlosti nabízené koncovým uživatelům.
Projekt také pomáhá splnit nároky kladené zákonem o kybernetické bezpečnosti. Zároveň potřebujeme splňovat koncepci ČTÚ, která zaštiťuje všechny systémy v našem úřadě.
Skládá se ze tří částí: měřicí systém, technická opatření pro bezpečnost informací a provozně-technická opatření.
V současné době už běží měřicí server pro mobilní sítě a jsou do něj zapojeny měřicí terminály. Chceme do něj připojit i uživatelské terminály, abychom mohli sbírat data crowdsourcingovým způsobem.
Systém nabízí také vizualizaci naměřených hodnot na mapách.
Pro měření v pevných sítích se používají měřicí terminály značky EXFO, které jsou připojeny k serveru schopném zpracovávat osm paralelních měření z různých míst. Definovali jsme si soubor datových parametrů, které měříme.
Patří mezi ně: propustnost TCP toku v obou směrech a zpoždění (podle RFC 6349), které je doplněné o rozptyl zpoždění rámců a ztrátovost rámců (podle ITU-T Y.1564).
Úřad definuje parametry, které musí operátor splňovat u služeb nabízených koncovým uživatelům. Definujeme takzvanou 50 % detekovatelnou změnu výkonu. Pokud k ní dojde na dobu delší než 30 minut, jde o velkou odchylku. Pokud k ní dojde třikrát v jedné hodině, jde o velkou opakující se odchylku.
Maximální rychlost musí být rovná nebo vyšší inzerované rychlosti. Rozhodně by inzerovaná rychlost neměla být vyšší než skutečná.
Viktor Kustein: WPAD a bezpečnost v DNS
WPAD je Web Proxy Autodiscovery Protokol, který používá většina webových prohlížečů k automatickému zjištění umístění proxy serveru na síti. Prohlížeč se dotáže do sítě, stáhne si konfigurační soubor a nastaví si proxy server pro připojení do internetu. Potud žádný problém.
Společnost Gransy si pro své účely zaregistrovala doménu wpad.domain.name a zjistila, že na ni začal proudit obrovský provoz. Šlo celkem o 300 milionů požadavků na stažení konfigurace proxy serveru za den z 2,7 milionu unikátních IP adres. Okamžitě jsme provoz ukončili a začali jsme hledat, kde je problém.
Ukázalo se, že v mnoha domácích routerech je nastavena doména na domain.name. Registrací domény jsme nechtěně přesměrovali spoustu uživatelů na naši proxy.
Vzniká tím velký bezpečnostní problém, ve firemní síti může být například nastavená doména, která už expirovala nebo ji vlastní někdo jiný. Pokud zůstane v konfiguraci počítačů nebo routeru stará konfigurace, může nový majitel na server nahrát vlastní konfiguraci proxy a může přesměrovat veškerou komunikaci firmy přes svůj server.
Pokud jsou zařízení používána i mimo interní síť, měla by firma zvážit vypnutí automatické konfiguraci. V době notebooků a mobilních telefonů je to velmi běžná situace. Měla by také zvážit použití FQDN z globálního DNS stromu, aby nedošlo ke kolizi s veřejnými doménami.
Petr Špaček: ochrana proti random subdomain útokům pomocí DNSSEC
Útočník má možnost generovat spoustu dotazů na neexistující jména. Protože je každý dotaz unikátní, nedá se použít keš a rekurzivní server musí vždy dotaz předložit autoritativnímu serveru. Ten vždycky odpoví, že doména neexistuje, ale tahle výměna informace umí velmi dobře vytížit oba DNS servery a linku mezi nimi.
Cílem je obvykle autoritativní server dané domény, na který se takto efektivně provádí DDoS.
Pokud doména nepoužívá DNSSEC, musí rekurzivní server používat heuristiku, kterou odhaduje, zda se klient neptá zbytečně na nesmyslné domény. Heuristika ale je zveřejněna v implementaci, takže se jí útočník může přizpůsobit. To zase znamená úpravu algoritmu a takto stále dokola.
Proti tomu domény podepsané DNSSEC umožňují nasadit deterministické řešení: agresivní cache. Funguje to ale jen u podepsaných domén, ale v .CZ máme výhodu v tom, že více než polovina domén je podepsaná, takže se nevýhoda v praxi stírá.
Součástí podepsané domény jsou i takzvané NSEC záznamy, které jsou důkazem neexistence jmen v určitém intervalu. V původním DNS vůbec taková informace nebyla, informace o neexistenci domény byla platná vždy pro jedno konkrétní jméno.
Kešující validující resolver tak má dnes možnost těžit z toho, že už má informaci o celém intervalu a nemusí se znovu ptát autoritativního serveru na každou neexistující doménu v něm.
V praxi to snižuje latenci, spotřebovává méně zdrojů, zlepšuje ochranu soukromí a zvyšuje odolnost DNS proti útokům. Další články v řetězci už neuvidí, že se uživatel ptá a neobtěžuje je.
Efektivita řešení závisí na charakteru provozu, zvoleném TTL a také na rozložení jmen v dané zóně. Pokud máme v zóně padesát jmen, máme jen malé množství NSEC záznamů, což znamená velmi málo dat. Pokud ale je v zóně milion domén, bude účinnost agresivní keše nižší.
CZ.NIC provedl praktická měření na svém veřejném resolveru při vypnuté a zapnuté agresivní DNSSEC keši. Velký přínos to má pro root zónu, která je poměrně malá a resolver se během několika sekund naučil, které domény neexistují a pak už se na ně neptal. Zastaví to 50 až 65 % dotazů na root.
Pro ostatní zóny je dopad za běžného provozu naprosto minimální. Já si to vysvětluji tak, že v globálním měřítku není rozšíření DNSSEC příliš vysoké.
V běžném provozu se tedy uživatel ptá na mnoho různých domén mimo .CZ, které nejsou podepsané.
Výrazně lepší je to v případě nesmyslných dotazů vznikajících během útoku. Nechtěli jsme útočit na skutečnou doménu, proto jsme si vygenerovali vlastní podepsanou zónu. Záměrně jsme použili algoritmus RSASHA256, abychom vygenerovali velké odpovědi.
Typy záznamu byly statisticky rozložené stejně jako ve skutečné zóně .CZ.
U malé zóny s 50 jmény byl útok účinný jen první dvě sekundy, poté jsou všechna data v keši rekurzivního serveru a není potřeba posílat dotazy k autoritativnímu serveru. Dokud nevyprší TTL, není potřeba vůbec autoritativní server kontaktovat. Došlo také k výraznému zlepšení zaplnění keše, protože není potřeba kešovat všechny odpovědi na nesmyslné dotazy.
Server pak není nucen vyhodit z keše smysluplné odpovědi, které mezi tím získal. Pomůže to jak autoritativnímu serveru, tak i resolveru.
U větší zóny s 14 tisíci jmény byla situace velmi podobná, po deseti sekundách přestává útok přecházet na autoritativní server. Zóna se 110 tisíci jmen už způsobuje výrazně vyšší tok k autoritativnímu serveru, stále se ale začíná zhruba na pětině proti nepodepsané zóně. Během minuty opět klesá počet dotazů k nule. Autoritativnímu serveru to výrazně pomůže.
U zóny srovnatelné s .CZ jsme na začátku komunikace přibližně na čtvrtině počtu paketů, ale objem dat je vyšší než v případě nepodepsané zóny. Na konci první minuty jsme asi na pětině objemu dat, po deseti minutách už útok autoritativní server spíše jen lechtá. Po dvaceti minutách už o něm neví.
Funguje to na obrovských zónách, ale jen v případě TTL 60 minut. U kratších TTL informace vyprší brzy, ale dotazy se v průběhu času rozloží a špičky se snižují.
Agresivní DNSSEC cache výrazně zlepšuje využití resolveru, přináší dramatické snížení vytížení sítě v případě útoku a provoz vygenerovaný útokem se zastaví. Nejefektivnější je to pro malé zóny, ale funguje to i pro opravdu velké. V České republice jsme na tom s DNSSEC velmi dobře, pomohlo by, kdyby více resolverů validovalo. Resolver je totiž ten prvek, který útok zastaví.
Tomáš Herout: útok skrz (ne)známou vlastnost síťových prvků
Ústecká síť TetaNet před časem zažila útok na své síťové prvky, který způsobil výpadek části sítě. Přemýšleli jsme nad tím, že jde možná o nějaký známý útok, o kterém nevíme jen my.
Ukázalo se, že jde skutečně o útok popsaný v CVE-2018–0171. Jde o útok na Cisco prvky, které umožňují automatizovanou instalaci pomocí protokolu smart install na TCP portu 4786, který je ve výchozím stavu zapnutý. Doporučení je jednoduché: vypněte to.
Obecně platí, že při zavádění nových služeb je potřeba brát v potaz nejen funkčnost, ale i bezpečnostní hledisko. My jsme o smart install věděli od začátku, ale protože jsme ho nepoužívali, nezajímal nás. To byla chyba.
Funkce umožňuje na dálku prvky ovládat, nahrávat do nich konfiguraci a podobně. Kdybych to navrhoval já, asi bych chtěl, aby to fungovalo bezpečněji. Ponaučení je, že je potřeba dávat pozor na bezpečnost.
Robert Šefr: boj s malware během resolvingu DNS dotazů
Malware má obvykle standardní životní cyklus: nejprve je stroj napaden, poté čeká na příkazy od řídicích serverů a především provádí zadané úkoly. Jednotlivé útoky se mohou kus od kusu lišit, ale bývá to velmi podobné.
K infekci může dojít přes exploit v prohlížeč nebo si uživatel sám nevědomky nainstaluje podvodný software. Dalším zdrojem může být e-mail, který v příloze obsahuje downloader. Mail neobsahuje samotné tělo malware, které je později staženo z internetu. Obvykle je v procesu zapojeno několik zřetězených domén.
Třetí možností je vzdálené zneužití bezpečnostní díry, které ale pak obvykle také pokračuje stažením malware z některé domény.
V březnu letošního roku byl velmi aktivní malware Locky, který se šířil právě pomocí downloaderu v e-mailové příloze. Je poměrně přímočarý, napadne stroj, zašifruje disk a poté vydírá uživatele.
Ne všechny útoky jsou perzistentní, například minery jsou staženy do prohlížeče a poté těží kryptoměny bez uživatelova vědomí. V prvním kvartálu letošního roku jsme zaznamenali, že 6,5 % našich zákazníků kontaktovalo jeden nejpopulárnější miner. Je to velmi rozšířená praktika.
Tyto útoky mohou být blokovány na úrovni DNS.
Každý malware po instalaci musí kontaktovat svůj řídicí server, aby mohl oznámit, že je na místě a uživatele je možné například vydírat. Použité domény mohou buď vypadat legitimně, nebo jsou generovány automatickým algoritmem. Malware si vygeneruje domény s pseudonáhodným jménem, na které je pak možné řídicí server umístit. Pokud konkrétní algoritmus neznáte, nemůžete efektivně blokovat předem danou skupinu domén.
Takto je možné pravidelně servery přemisťovat, protože domény jsou generovány každý den znovu.
Pokud se podaří infikovanému stroji zablokovat přístup k doménám, přestane být aktivní. Pokud jej blokujeme dlouhodobě, nebude dostávat instrukce a nebude aktivní. Sice ho nezlikvidujeme, ale můžeme ho takhle efektivně uspat.
Zajímavý je malware Cosiloon, který je předinstalován v některých telefonech s Androidem. V naší síti jsme letos viděli jen 59 infikovaných IP adres. Jsme schopni ten provoz blokovat, otázka je, co se stane, když uživatel s telefonem vyrazí do jiné sítě.
Podle dostupných měření se více než jedno procento IP adres snaží vyhledávat domény generované algoritmem. Používá to malware, ale i agresivní reklamy.
V běžném provozu je přibližně 0,28 % vedeno na náhodné domény, i když některé regulérní domény je těžké od náhodných odlišit: zusjjrrozmitalptr.cz, zbkjmkcr.cz, csvnmnm.cz a podobně. Pro nás nejsou falešně pozitivní hlášení problém, protože my hledáme jen pravidelná opakování.
Velmi dobře jsou v DNS vidět spamové kampaně, protože malware dostane od řídicího serveru seznam tisíců domén, na které má rozeslat poštu. Jde pak o neobvyklý provoz z IP adres, které dřív nikdy poštu neodesílaly a najednou komunikují se servery po celém světě.
Ondřej Surý: BIND 9: minulost, současnost a budoucnost
Ondřej Surý před časem převzal vývoj DNS serveru BIND. První verze v řadě 9.0 vyšla už v roce 2000, mezi tím vyšlo dalších 12 subverzí. Nějaký čas ISC podporovalo až čtyři různé verze. Snažíme se s tím něco udělat, aby to pro nás nebylo tak náročné. V týmu je v současné době jen pět lidí.
Nejnovější verze je 9.12, přinesla některé změny funkčnosti: agresivní kešování NSEC, Server Stale a Response Policy Interface. Proběhl také velký refaktoring, který způsobil zrychlení mezi 1,25 až šestinásobkem.
Přibyla také podpora záznamů CDS/CDNSKEY a algoritmů z rodiny EDDSA.
Připravuje se verze 9.13, která přinese poměrně drastické změny. O BINDu se vtípkovalo, že jde o nejvíc uzavřený open-source projekt. Chceme to změnit, celé to otevřít a zrychlit cyklus vydávání.
To sebou přinese také odlehčení celého kódu, takže bude zrušena část zpětné kompatibility.
Vývoj by měl být hodně otevřený, bude otevřeno nové fórum a nasadí se continuous integration. Chceme vidět naživo všechny své chyby, nikdo není neomylný a vývojář v céčku už vůbec ne. Není se za co stydět.
Vývoj už teď probíhá na gitlab.isc.org, kde je vidět mnohem otevřenější přístup vývojářů.
Změní se také značení verzi: liché verze budou testovací a budou vydávány bez složitých stabilizačních procesů. Sudá čísla naopak vyjdou ve chvíli, kdy je všechno dodělané a připravené. Podporované bude jen jeden rok, ale každé druhé vydání bude mít dlouhodobou ESV podporu po dobu čtyř let.
Verze 9.11 bude podporovaná až do roku 2021, během této doby přijde ESV verze 9.16 a tak dále.
V každém vývojovém cyklu bude znovu zváženo, které platformy budou podporovány. Dnes jsou to různé linuxové distribuce, tři nejpoužívanější BSD systémy a vybrané proprietární systémy: macOS, Windows a Solaris. Rádi bychom použili moderní céčkový standard, což je C11. Chceme také být závislí pokud možno jen na standardních knihovnách. V době, kdy BIND vznikal, ještě velká část standardů neexistovala.
Cílem je snížit množství kódu, který je potřeba podporovat.
Do verze 9.13.1, která vyjde na konci června, se připravuje podpora Root Zone Local Copy a QNAME minimizace. Na pozdější verze se připravuje podpora dynamických modulů a refaktorizace některých funkcí do těchto modulů. Zjednoduší nám to práci a hlavně bude možné si napsat vlastní moduly, kterými bude možné například nahlížet do funkce serveru, aniž by bylo nutné upravovat jeho jádro.
Martin Žádník: DDoS čistička provozu na FPGA
CESNET začal intenzivně řešit DDoS zhruba před třemi lety, kdy se objevily první vážnější útoky. Postupně jich začalo přibývat, ale nikdy jsme neodhalili jejich důvod.
Pravděpodobně je to tak, že akademická síť je velmi robustní, tudíž slouží útočníkům jako testovací prostředí.
Prvním opatřením bylo RTBH a rate limiting na routerech. Ten ale může ovlivnit legitimní uživatele, proto jsme hledali vlastní řešení, které by nám dovolilo čistit ještě jemněji.
Dostupná komerční řešení jsou velmi drahá a nedovolují dostatečně jemně řídit samotné čistění provozu. Hlavním cílem je ochrana infrastruktury do té míry, aby si pak už připojené organizace dokázaly se zbytkem útoku poradit samy.
Použití běžných procesorů je limitováno datovými toky, zatímco u 40 Gbps je na zpracování jednoho průměrného paketu 12 ns, při 400 GE už je to jen asi jedna nanosekunda, což je velmi málo. Proto bylo rozhodnuto, že bude lepší použít FPGA, tedy programovatelné hradlové pole.
Výsledkem je specializovaná síťová karta, která je připojená pomocí PCI Express do běžného serveru. Máme vlastní hardware a také vlastní firmware.
Karta se stará o přijetí síťového provozu, selekci zajímavé části provozu a předání do procesoru serveru. Tam se zvolí strategie zpracování provozu, která se předá opět do karty. Cílem je, aby co nejvíce provozu zůstalo uvnitř karty a tím se snižovala latence.
Obvyklý provoz běží přes router, pokud se v něm objeví podezřelý útočný tok, je přesměrován do čističky, která po svých zásazích přepošle vyčištěná data do sítě. Základní funkcionalita byla napsána velmi rychle, ale praktické nasazení vyžadovalo doplnění dalších vlastností: podporu překladu VLAN, podporu routování, ARP a ND. Snažíme se využít to, co už je hotové. Používáme třeba routovací démon Bird a chceme nasadit Suricatu.
V první fázi se vývojáři zaměřili na řešení zesilujících útoků, kdy jsou díky odražečům výrazně posíleny útočné toky. Naše čistička monitoruje cílové prefixy, pro které má nadefinovaná specifičtější pravidla zajímavého provozu. Pokud jsou překročeny limity, je nastaveno, na kolik by se měl ořezat.
Je pak možné provést selekci zdrojových IP adres a vybrat jen ty, které nejvíce přispívají k síle útoku.
Rozšířené jsou také útoky typu SYN flood, které čistička řeší tak, že hlídá, zda má odesílatel skutečně implementován TCP stack. Propuštěná je jen část SYN paketů a hlídá se, zda pak zdroj odpovídá na ACK. Pokud ano, tak se zdroj dostane na whitelist a provoz je propouštěn.
Druhou variantou je, že čistička původní SYN paket zahodí a odpoví nevalidním SYN/ACK. Protistrana by měla zareagovat paketem RST, pak je přidána na whitelist.
Výhodné je, že se s tímto postupem vyrovná už operační systém, takže si uživatel všimne maximálně nějakého drobného zpoždění.
Díky akceleraci v kartě se daří takto zpracovávat 100 Gbps s extrémně krátkou latencí v řádu mikrosekund. Ovládání probíhá přes CLI v Linuxu, přičemž pravidla se ukládají do databáze. Máme v plánu rozšiřovat blokovací kapacitu, podporovat další heuristiky, vybudovat univerzální rozhraní podobné Cisco CLI a umožnit ovládání přes BGP FlowSpec.
Projekt by měl postupně také opustit síť Cesnet a přejít do široce nasaditelného a použitelného stavu.
Zbyněk Pospíchal: bezpečnost při propojování sítí
Internet stojí na protokolu BGP, který má řadu mezer v zabezpečení. Čeká se na řadu nových standardů, ale některé věci hotové jsou a leccos se dělat dá.
Jednou z nich je GTSM podle RFC 5082, kdy jsou zahozeny všechny pakety z cizích zdrojů, které nemají TTL rovno 255. To se stane ještě před tím, než se zatíží procesor v control plane počítáním MD5 haše.
Zkušenosti s nasazením jsou velmi dobré.
Dalším opatřením je provozovat BGP relace v neoznamovaném adresním prostoru. Pak není možný útok na session, protože se k ní útočník zvenčí nedostane.
Je možné použít lokální adresy podle RFC 1918 nebo sdílený rozsah 100.64.0.0/10 dle RFC 6598. Adresy je dobré filtrovat firewallem před vlastními zákazníky.
Užitečný je také protokol BFD (Bidirectional Forwarding Detection), který hlídá živost daných rout a umožňuje jejich rychlou konvergenci. V českém NIX.CZ máme 21 IPv4 relací a 20 IPv6 relací. Zkušeností jsou velmi dobré, pokud vychytáte problémy při implementaci, za provozu už pak žádné nejsou.
Proti podvrhování příchozího provozu je možné použít uRPF, kdy pro příchozí paket musí existovat odpovídající záznam ve FIB, který navíc musí směrovat na příslušné rozhraní. Použitelně to nefunguje dobře při multi-homingu.
Cisco vymyslelo řešení v podobě VRF režimu, který ale později přestalo podporovat.
BGP FlowSpec je možné dobře nasadit na vnitřní síti, ale teoreticky i mezi sítěmi. To je věc, kterou bych nedoporučoval. Není možné to pořádně odfiltrovat a hacker pak může mít přístup k routovacím tabulkám a může dělat neuvěřitelné věci.
V každém případě je potřeba hodně testovat, než se FlowSpec nasadí do produkčního řešení.
Projekt Fenix má v současné době 20 členů a je dnes spíše organizační než technický. Máme tu ale jiný projekt, který umožňuje filtrovat DDoS útoky přímo v peeringovém uzlu.
Útok přicházející od jiného peera je možné pomocí BGP poslat na jiný next-hop, kde je připraveno zařízení schopné podle ACL provoz vyčistit. Teoreticky je možné takto zpracovat až čtvrt terabitu. Problém zatím je, že ovládání není uživatelsky přívětivé. Funguje to asi rok, ale zatím nám naštěstí přes NIX útoky příliš nechodí.
Tomáš Hlaváček: simulace dopadů nasazení validace RPKI (ROV)
Zkratka RPKI znamená Resource Public Key Infrastructure a cílem je zabezpečit směrování. Je opt-in, takže se do ní mohou účastníci postupně zapojit. Umožňuje podepsat vlastní prefixy, což je sváže s ASN, které je autorizováno ohlašovat je do internetu. Tyto kryptografické artefakty se zveřejní v repozitářích RIR. Obvykle je možné si vše naklikat jednoduše ve webovém rozhraní.
Pokud pak router dostane prefix přes BGP, může ověřit ROA, pokud existuje. Téměř 20 % prefixů už je podepsáno. Otázkou je, jak je na tom validace.
Každý router se pak může rozhodnout, co s prefixy, které jsou prohlášeny za nevalidní. Buď je mu možné snížit preferenci, zahodit ho nebo pustit a zalogovat.
Tomáš Hlaváček prováděl vlastní experiment, během kterého se řízeně snažil unést prefix tím, že ho ohlašoval z nepovoleného AS. Ukázalo se, že jen 0,1 % autonomních systémů validuje. Podle některých měření je jich dnes asi 40. Co tedy na ROV správcům vadí?
Nejčastěji uváděným důvodem je, že část ROA je chybných, podle NIST se to týká více než 6 tisíc prefixů.
Dopady nasazení ROV je možné simulovat, což Tomáš Hlaváček také vyzkoušel. Ve většině případů by bylo zahozeno méně než jedno procento paketů. Ve většině případů šlo o malé pakety, které byly odhaleny jako útok.
Kdyby se tedy dělala validace, zamezila by útokům, kterých si dnes ani nikdo nevšimne.
Technologie ROV je podle Hlaváčka životaschopná, ale stále ještě není tak rozšířená, aby nějak ovlivňovala bezpečnost na internetu. V plánu je vytvořit novou studii, která zpracuje řádově více dat a odpověděla by účastníkům, jaký dopad by mělo ROV na jejich síť. Popíšeme také výhody a nevýhody globálního nasazení ROV.
Pomohlo by, kdyby technologii nasadily velké sítě jako třeba peeringová centra.
Nishal Goburdhan: bezpečný DNS resolver Quad9DNS
DNS je internetový telefonní seznam, který je ale nešifrovaný a je otevřený k DDoS útokům. Pokud váš nejbližší server přestane fungovat, musíte se připojovat ke vzdálenějším. Stejně tak dotaz cestuje daleko, pokud není v keši vašeho resolveru.
Existuje také řada společností, která prodává logy z resolverů.
Iniciativa Quad9 je společným projektem IBM, Global Cyber Alliance a Packet Clearing House. Ti dodávají financování, data pro blacklist a hlavně know-how. DNS resolver od Quad9 nikdy neloguje zdrojovou IP adresu dotazu. Vaše adresa není nikdy zaznamenána. Pokud používáte DNS over TLS, nikdo nemůže dotazy sledovat ani po cestě.
Služba používá seznamy závadných domén od 19 různých společností. Na jejich základě pak odmítá resolvovat a při dotazu na ně posílá NXDOMAIN. Nesnažíme se na tom vydělat, celý projekt je neziskový. Nabízíme DNS servery, které můžete jednoduše využít.
Dnes jsou servery na 121 místech po celém světě, jsou veřejně dostupné na adresách 9.9.9.9 a 2620:fe::fe.
Jaromír Talíř: pět kroků k elipse
CZ.NIC nedávno v doméně vyměnil klíče v doméně .CZ a místo RSA nasadil ECDSA. Nápad je to velice starý, více než dva roky jsme se snažili přesvědčit organizaci IANA, aby umožnila registrům nový algoritmus nasadit.
Jedná se už o třetí výměnu KSK klíče a druhou spojenou se změnou algoritmu. Je to první nasazení algoritmu eliptických křivek v TLD.
Výhodou ECDSA je, že používá výrazně menší klíče, což zmenšuje celou zónu a snižuje její náchylnost na odrazové útoky. V prvním kroku byly publikovány ECDSA podpisy, což zvětšilo zónu z 850 na 1217 MB. Poté byly publikovány ECDSA klíče, což zvýšilo velikost odpovědi DNSKEY. Ve třetím kroku proběhla výměna DS záznamů v IANA, což trvalo 28 hodin. To je velmi dobré, podle SLA na to mají až sedm dnů.
Poté bylo potřeba počkat 24 hodin, až se změna zpropaguje.
Ve čtvrtém kroku byly odstraněny RSA klíče, ale zatím zůstaly podpisy obou algoritmů. V posledním kroku byly odstraněny staré RSA podpisy. Velikost DNSKEY odpovědi klesla z 1263 bytů na 387 bytů. Velikost zóny klesla z 850 na 695 MB. Odezva z celého světa je velmi dobrá, všechno proběhlo podle plánu.
Během letošního roku pravděpodobně dojde k výměně KSK v kořenové zóně, která byla plánována už na říjen roku 2017. Měli byste si opět zkontrolovat stav svých resolverů, projít konfigurační soubory a ověřit, že je adresář s klíči zapisovatelný.
Autorem fotografií je Roman Prachař.
ČLÁNKY DO MAILU