Hlavní navigace

Uzel NIX.CZ bude chráněn DDoS Protectorem sdružení CESNET

Petr Krčmář

Sdružení CESNET pořádalo další Seminář o bezpečností sítí a služeb, mluvilo se na něm o nasazení RPKI v e-infrastruktuře CESNET, ochraně propojovacího uzlu NIX.CZ či zavedení unicodových znaků do domény .CZ.

Doba čtení: 14 minut

Sdílet

Ondřej Caletka: Nasazení RPKI v e-infrastruktuře CESNET

Internet je síť sítí, kterým se říká autonomní systémy. Ty nabízejí své IP adresy svým sousedům, kteří si pak na základě těchto informací budují směrovací tabulky. Každý by měl nabízet jen své adresy a ne cizí. Zároveň by každý měl přijímat jen takové adresy, které patří danému autonomnímu systému. Tyhle idealistické představy na skutečném internetu neplatí, takže je potřeba tato pravidla vynucovat.

K problémům pak v praxi dochází kvůli chybám v konfiguraci, cíleným únosům konkrétních adres nebo odklonu provozu za účelem odposlechu. Nejčastější je chyba konfigurace, za kterou není zlý úmysl, ale má potenciál způsobit na internetu fatální problémy.

Klíčovým prvek tvoří Internet Routing Registry, což jsou veřejné databáze obsahující informace o tom, komu dané rozsahy IP adres patří. Svazují IP adresy s čísly autonomních systémů a definují vztahy autonomních systémů. Takových databázi existuje několik a žádná z nich není globální. Důvěryhodnost dat je bohužel nízká, protože jsou často zastaralá a ověření oprávněnosti editace je minimální nebo dokonce žádné. Z těchto databází je ovšem možné vytvořit filtry, podle kterých může router odmítat nesprávná data ostatních routerů.

RPKI (Resource Public Key Infrastructure) je pokus udělat to celé znovu a lépe. Jde o kryptograficky zabezpečenou databázi prefixů a zdrojových AS. Kvalita dat garantovaná regionálními internetovými registry. Výhodou je, že pro použití není potřeba kupovat nové routery, protože validace obvykle probíhá mimo samotný router.

Regionální registry (RIR) zde vystupují jako certifikační autority a každému držiteli adres vystaví certifikát. Jeho součástí je seznam všech adres, které má daný držitel k dispozici. Díky tomuto certifikátu a příslušného privátního klíče pak může vystavit objekt zvaný ROA. V něm je uvedený adresní prefix, maximální povolená délka prefixu a číslo zdrojového autonomního systému (AS). V ROA můžou být jen adresy, které jsou podmnožinou adres uvedených v certifikátu. Naopak ASN není v certifikátu uvedeno, takže je na držiteli adres, aby ohlašoval rozsahy z libovolných AS.

Tím vzniká ověřitelná informace o tom, které adresy jsou ohlašovány z jakého autonomního systému. Příjemce takové informace pak použije validátor, který dokáže ověřit platnost získaných ROA. Potřebuje k tomu pět bodů důvěry od všech regionálních registrů. Validátor stáhne všechny certifikáty a ROA, všechno ověří a vydá soubor formátu CSV. Tím pak musíte krmit svůj router, aby zahodil všechny neověřené prefixy, které nebyly součástí souboru. K tomu se používá protokol RPKI-RTR. Router na základě dat přidělí přijatým síťovým prefixům jeden ze stavů: VALID, INVALID a UNKNOWN.

Jak se naloží s výsledkem validace, záleží na lokálním nastavení. Obvykle se prefixům ve stavu INVALID nastaví nižší preference, aby se pokud možno použilo cokoliv lepšího. Místní preference se ale vyhodnocuje až po vyhodnocení délky prefixu. Pokud nám tedy někdo pošle delší prefix, stejně po něm skočíme bez ohledu na místní preferenci. Naopak funguje to, když se prefixy označené jako INVALID zahodí, jako by nikdy neexistovaly. Problém je ale v tom, že pokud validní i nevalidní prefix míří stejnou cestou, stejně data putují špatným směrem. Jediným řešením je, aby validovali pokud možno všichni.

Sdružení CESNET využívá pro podepsání prefixu hostované služby přímo od RIPE NCC. Je to strašně jednoduché, protože RIPE NCC drží náš privátní klíč a vydává ROA podle zadání. Problém je, že CESNET vystupuje jako správce různých adresních bloků svých členů a není schopen vystavovat společný ROA pro agregované prefixy. Každý prefix totiž má svého držitele a tedy i svůj certifikát a ROA je platná jen tehdy, pokud obsahuje prefixy vyjmenované v jednom certifikátu. Budeme muset některé prefixy deagregovat, aby sítě vystupovaly v globální routovací tabulce samostatně. Zatím jsou ve stavu UNKNOWN.

Validaci pak CESNET provádí na dvojici validátorů na virtuální infrastruktuře, jeden server je v Praze a druhý v Brně. Na jednom z nich běží RIPE NCC validator 3.1 a na druhém mladý projekt Routinator 3000. Přenos filtrovacích pravidel pak probíhá protokolem RPKI-RTR na směrovače Cisco a Nokia. Dlouho jsme ROA jen vyhodnocovali, ale s výsledky jsme nic dalšího nedělali. Od od 24. června 2019 jsme ale podporu zavedli a nikdo si zatím nestěžoval.

Na routerech sítě CESNET je zahazováno asi 5000 prefixů, ale v praxi to nepřináší žádné problémy. Zároveň jsme zatím nezaznamenali žádný incident, před kterým by nás to nějak ochránilo. RPKI portál RIPE NCC umí posílat notifikace, takže se dozvíte o tom, že někdo jiný udělal chybu a ohlašuje některou z vašich adres.

Tomáš Podermański, Josef Verich: DDoS Protector v prostředí propojovacího uzlu NIX.CZ

Nežádoucí provoz je možné omezit přímo na hraničním routeru, případně už v síti operátora. Můžeme k tomu použít protokoly BGP FlowSpec nebo RTBH. První z nich dovoluje velmi jemné škálování toho, co bude zahazováno, ale můžeme jej použít jen ve vlastní síti. Naopak RTBH je velmi široce podporovaný v tranzitních sítích, ale umí zahazovat jen celý provoz na uvedený prefix. Pokud je jasné, že veškerý definovaný provoz je nežádoucí, je možné provést omezení provozu přímo na směrovači.

Někdy ale může provoz obsahovat užitečnou část, pak je vhodnější přeposlat celý tok na čističku. Přesměrovat by se měl provoz podle IP adres bez ohledu na protokol a porty. Správně by se měly na čističku přesměrovat oba směry provozu, aby čistička měla k dispozici všechny potřebné informace. Obvykle není možné problém odstranit zcela, ale provoz už bývá natolik vyčištěný, že nezahltí koncovou linku.


V peeringovém uzlu NIX.CZ probíhá velká část komunikace přes důvěryhodné route servery. Pokud pak přichází útok od některého z peerujících operátorů, můžu mu oznámit, aby nám daný provoz neposílal. Jakmile už dostanu linku pod kontrolu a ona není zahlcená, můžu zbytek provozu filtrovat u sebe. Problém je v tom, že nové DDoS útoky si jako cíl vybírají větší množství adres. Pokud potřebuji blokovat jen několik adres, nevadí nám to. Jakmile ale útok míří na desítky tisíc různých cílů v naší síti, nemůžeme jednoduše zablokovat veškerý provoz na ně. Proto je snaha, aby tranzitní sítě implementovaly ochranu proti DDoS už u sebe a posílaly do koncové sítě jen užitečný provoz.

Takové řešení se nyní nasazuje v NIX.CZ a provozovatel sítě má pak možnost přesměrovat v peeringovém uzlu provoz na čističku a přidat informaci o tom, jak se má daný provoz čistit. To je zajištěno zařízením DDoS Protector, které vyvíjí sdružení CESNET. Je to hardwarově akcelerovaná FPGA karta se 100GE porty, která je zapojená v 1U serveru. Nějakou dobu je toto řešení nasazené v síti CESNET, ale s novými DDoS útoky klesá jeho účinnost. Nasazení v peeringovém uzlu je logickým řešením.

NIX.CZ je pro fungování internetu v Česku naprosto kritický, proto není prostor pro žádné experimentování nebo hrubé zásahy do provozu. NIX.CZ je navíc neutrální, takže nesmí sám ze své vůle zasahovat do provozu. Jakékoliv změny musí být iniciovány ze strany některého z členů. Musí být také zajištěno, že každý člen musí být schopen zasahovat jen do provozu, který směřuje do jeho sítě.

Propojovací uzel funguje jako jeden velký switch, do kterého jsou připojené routery jednotlivých účastníků, kteří si chtějí vyměňovat data. Je to prostá L2 infrastruktura, kde na sebe sítě přímo vidí a dokáží si vyměňovat data. Pro komunikaci mezi routery se používá standardní protokol BGP, který dovoluje předávat informace o jednotlivých síťových prefixech. Aby každý správce sítě nemusel navázat BGP relaci se všemi dalšími operátory, vznikly route servery. Každý účastník si vytvoří jen jednu relaci právě s route serverem, který mu předá všechny informace o ostatních sítích. Vyměňují se zde samozřejmě jen směrovací informace, samotný provoz probíhá přímo mezi účastníky.

V případě útoku se začne do jedné sítě valit velké množství provozu z různých směrů. V podstatě se pak ucpe linka k němu, takže cílový operátor není schopen s tím už nic udělat. Je pak možné použít RTBH, což znamená, že se cílový prefix „hodí přes palubu“ a ten pak není dostupný. Tím sice vlastně podpoří útočníkův záměr, ale ochrání zbytek své sítě.

Cílem při nasazení DDoS Protectoru bylo přesměrovat provoz do čističky, která je schopná si s problematickým provozem poradit. Operátor sítě, která je pod útokem, je schopen přibalit ke směrovací informaci speciální záznam (komunitu), která instruuje route server, aby s prefixem zacházel jinak. Ten přepíše adresu next hop na adresu DDoS Protectoru. Všechny okolní směrovače se tak naučí upravenou informací a provoz se pak začne posílat do čističky.

DDoS Protector sám neví, jak se má k provozu chovat. Správce cílové sítě ale může pomocí BGP komunit signalizovat další volby. Zařízení počítá s určitou sadou opatření, která je možné si objednat. Je tak možné omezit celkový datový tok na určenou hodnotu, omezovat provoz UDP nebo UDP/SYN a podobně. Máme připravené řešení, kdy bude možné uvést přímo číslo portu nebo protokolu.

Správce sítí potřebuje také zpětnou vazbu o tom, jak čistění probíhá a zda ještě útok trvá. Mají tak přístup k rozhraní, kde získají všechny podrobnosti a v reálném čase mohou sledovat stavové informace. Máme k dispozici kapacitu 100 gigabitů, což zatím stačí, ale do budoucna budeme potřebovat víc. Vyvíjíme řešení nad 400GE kartami. Diskutuje se také o tom, zda by v rámci NIX.CZ nemělo být nasazeno více DDoS Protectorů, aby v případě velkého útoku nemusel provoz putovat celou infrastrukturou.

Ondřej Caletka: Proč se nebát háčků a čárek v doménových jménech

IDN je možnost, jak psát různé unicodové znaky do doménových jmen. Aby byla zachována zpětná kompatibilita, je IDN implementováno jen v koncových systémech. DNS o unicode vůbec nic neví, jen se definovalo jednoznačné mapování na ascii znaky. Pokud chceme IDN, povolíme v registru možnost některých speciálních kombinací znaků a vše začne fungovat.

V Evropské unii už IDN zavedly všechny země kromě Nizozemska, Slovenska, Chorvatsko, Kypr a Česko. Situace v české doméně je zvláštní, protože už od roku 2004 se opakují ankety, jestli bychom chtěli háčky a čárky zavést. Podpora je dlouhodobě okolo 35 procent mezi uživateli, mezi firmami je to ještě méně. CZ.NIC provozuje doménu háčkyčárky.cz, která jako jediná porušuje pravidla registrace, protože taková doména je v .CZ zakázána. Tam je mimo jiné napsáno několik argumentů proti zavádění IDN.

Hovoří se například o problému zápisu takových adres. To není něco, co by měl řešit doménový registr a na základě toho zakazovat registraci některých domén. Pokud uživatel nemá k dispozici správné rozložení klávesnice, může například využít vyhledávač. Pokud do Google zadáte „nebezi.eu“, najde vám na prvním místě doménu neběží.eu.


Podobně nebezpečně vypadá problém podobných znaků, který ale máme i bez IDN: l je podobné jedničce, O zase nule. S cizími znaky by to ale bylo samozřejmě zásadně horší. Tenhle problém se ve všech registrech řeší. ICANN například trvá na tom, že TLD koncovky musí být nezáměnné. U národních domén jsou obvykle povoleny jen relevantní znaky. Například v maďarské doméně je v pravidlech přesně vyjmenováno, které znaky jsou povolené. V generických doménách, například .com nebo .eu, je zakázáno míchání znakových sad. Můžete zapsat celou doménu v cyrilici nebo v latince, ale ne dva znaky v cyrilici a zbytek v latince.

Držitelé domén často argumentují nutností registrace více domén. To sice problém je, ale stejná situace už existuje dnes. Máme překlepové domény, pomlčkové a nepomlčkové varianty a to nikdo nereguluje. Stejně tak v praxi nejsou problémy se soudními spory, jak před časem potvrdila na konferenci Internet a Technologie 19 Regina Fuchsová z EURid: V souvislosti se zavedením IDN v .eu v roce 2009 jsme nezaznamenali vůbec žádný nárůst soudních sporů.

Proč tedy IDN vlastně zavádět? V latinkovém světě to nemá příliš velký význam, oblíbenost je okolo jednoho procenta. Na druhou stranu, svět se nás neptal a IDN zavedl. V současné době tedy najdeme unicodové domény prakticky všude, jen ne v doméně druhého řádu před .CZ. Starší generace si ještě pamatuje ZX Spectrum, kde ještě nebyla možnost psát české znaky. Jsou tu ale mladší lidé, pro které je to už nepřirozené. Proč bychom někde měli odstraňovat diakritiku, když to není technicky nutné? Ve veřejném prostoru navíc doménová jména s háčky a čárkami běžně existují, přestože nefungují.

Na základě memoranda s Ministerstvem informatiky je registr CZ.NIC povinen stanovit podmínky tak, aby nebyly diskriminační. Tím není dotčeno právo stanovit technická omezení registrací, pokud vyplývají z mezinárodně uznávaných standardů nebo zvyklostí. Před patnácti lety byla možná nepodpora IDN standardem, ale dnes je spíš standardem IDN podporovat. Registr by mohl povolit jen vázanou registraci, kdy by unicodová doména byla pevně svázaná s tou původní ascii.

Jan Vondráček: Obrana proti nechtěné těžbě kryptoměn pomocí DNS

Kryptoměny jsou dnes sexy, jsou trendem a všichni je používají. Hlavně jako výpalné za zašifrované disky. Jejich těžba je ale velmi drahá, takže chlapci z Pirate Bay vymysleli, že by se dalo těžit v prohlížečích. Výhodou je, že kód je velmi univerzální, je možné těžit na mobilu, tabletu, desktopovém počítači, prostě kdekoliv. Poměrně rychle vzniky ochrany proti takové těžbě, protože výsledkem je vyšší zátěž zařízení a vyšší spotřeba baterie.

Kromě rozšíření do prohlížečů by bylo potřeba také něco univerzálnějšího, co nevyžaduje aktivní zásah od uživatele. Celá ochrana spočívá v tom, že se nestáhne JavaScript, který provádí těžbu. Stránka se ale normálně načte a zobrazí. Inspirací byla RPZ pro blokaci hazardních her implementovaná v síti CESNET. Data byla získána z filtrů NoCoin. Rozhodl jsem se výslednou RPZ provozovat jako veřejnou službu. RPZ je možné chápat jako implementaci aplikačního firewallu, který v případě snahy o překlad vyjmenovaných domén hlásí, že neexistují. Jan Vondráček o celé problematice napsal pro Root.cz dva podrobné články.

Univerzita Pardubice provozuje také vlastní eduroam a na něm sleduje, kolik blokací pomocí tohoto filtru provede. Počet více méně odpovídá počtu uživatelů sítě, můžete tam pozorovat začátek akademického roku nebo třeba pokles o Vánocích. I takto malá univerzita ovšem během týdne na eduroamu provede 27 tisíc blokací. To mi přišlo jako obrovské číslo, těží se na všem: mobily, tablety, všechno.

Radko Krkoš: Využití PassiveDNS

PassivDNS je projekt ukládající historii DNS. V principu se sbírají odpovědi z DNS, obvykle z rekurzivních serverů. V databázi máme asi deset miliard záznamů, denně nám přijde asi sto milionů nových odpovědí. Do budoucna se plánují přidat ještě další sondy na periferii sítě, aby bylo k dispozici ještě více dat. Do databáze mají přístup akademičtí pracovníci, kteří mohou využívat webové rozhraní či REST API.

Data najdou využití především v oblasti bezpečnosti, kdy je možné sledovat vývoj v případě ukradené domény, nebo monitorovat rychle se měnící fast-flux domény. Ty se typicky používají k řízení botnetů. IP adresy u takových domén se velmi často mění. Podobně se pak pro phishing používají záchytné domény, které opět rychle mění adresy.

Jan Mach: MSMS, aneb když Ansible, Git a Sphinx táhnou za jeden provaz

Moderní správce serverů používá automatizaci, která postupně nahradila klasickou textovou dokumentaci ve firemní wiki. V případě sdružení CESNET je to Ansible, který ale sám o sobě stále ještě není dokonalý. Například je tu problém se zástupnosti, co když budu nemocný? Jak zaučím nového správce používat své role? Dalším problémem je například jednoduchá aktualizace rolí.

Výsledkem je přelití konfigurace Ansible do Gitu a oddělení jednotlivých rolí do samostatných submodulů. Tím je jednoduše vyřešená aktualizace rolí a další vývoj. To všechno je v jakési obálce, která obsahuje konfiguraci, dokumentaci a Makefile pro pohodlnější používání.

Každý správce pak má vlastní instalaci MSMS a ze sdíleného repozitáře si stahuje konkrétní konfiguraci pro svůj inventář, provede změny, aplikuje změny a zase je pushne do sdíleného repozitáře pro ostatní správce.


Součástí tohoto prostředí je také dokumentace, pro kterou se používá nástroj Sphinx. To je de facto standard pro dokumentaci projektů napsaných v Pythonu. Každá role má dokumentaci, aby správci znali jednotlivé konfigurační volby. Samotný nástroj MSMS má také svou dokumentaci, stejně jako inventáře. Vznikla k tomu utilita util-inspector, která sama podle existujících inventářů vygeneruje dokumentaci. Kód projektu MSMS můžete najít na GitHubu.

Aleš Padrta: Dej nám heslo a nic se ti nestane

Na naivní uživatele často platí jednoduché psychologické postupy jako něco nám dej a nic se ti nestane. Není to vydírání, obvykle je to opačně: nabídka pomoci je účinnější. Uživatel přece chce nabízenou pomoc. Útočnici často uživatele oslovují phishingovými maily, ve kterých nadnesou problém a nabídnou jednoduché řešení, pokud jim uživatel předá své jméno a heslo. My se tady tomu smějeme, ale jak na takovou věc zareaguje uživatel?

Uživatel má obvykle svou vlastní práci, za kterou je hodnocen. Účetní má spoustu své práce a nezajímá ji ani IT ani bezpečnost. Na takové lidi tedy velmi dobře funguje sociální inženýrství. V mailu se píše, že mají problém, ale ten je zdržuje od práce. Je tam zároveň řešení, které je nebude zdržovat od práce. Uživatel je tak nakonec rád, že za něj někdo vyřeší problém, o kterém ani nevěděl, že ho měl.


Výsledek je takový, že 20 % uživatelů běžně poskytne údaje mailem nebo do připraveného formuláře. Pak se diví, že dojde ke zneužití jejich osobních údajů. Co se s tím dá dělat? Prosté zákazy a jednoduchá opatření tu nepomůžou, stejně jako v jiných případech.

Pomůže jen odolný uživatel, který podvod odhalí a nahlásí ho. Takoví uživatelé ale nevznikají sami, musíte si je vychovat. Uživatele musíte vzdělávat a oni vám pak budou pomáhat.

Stejně důležitý je ale připravený správce, který je schopný podobný pokus o útok zachytit, oslovit uživatele a aktivně narušovat průběh kampaně. Můžete blokovat závadné e-maily nebo bránit uživatelům v přístupu na phishingové domény. Je potřeba své prostředí nastavit správně, v čemž pomáhají běžně používané postupy a nejrůznější penetrační testy.