V Nizozemsku sídlí významné množství společností, které mají globální přesah. Jsou jimi například RIPE NCC, regionální internetový registr, NLnet Labs, společnost vyvíjející open source software, nebo třeba jeden z nejstarších peeringových uzlů AMS-IX. Není proto divu, že o technická témata není na konferenci NLNOG Day nouze.
OpenINTEL – dlouhodobá historie globálního DNS
OpenINTEL je společný projekt University of Twente a NLnet Labs pro dlouhodobé měření globálního DNS. Podobné systémy už existují v podobě Passive DNS – odposlouchávání provozu za rekurzivními servery a ukládání do databáze. Nevýhodou je, že jsou vidět pouze data, na která se lidé ptají. Další nevýhodou je, že není možné ovlivnit časování – dotazy se ukládají v okamžiku, kdy je někdo položí. OpenINTEL je systém aktivního měření DNS, který denně odešle milion DNS dotazů. Tímto se produkuje ohromné množství dat, denně tolik jako ¾ lidského genomu (2,3 × 109 záznamů). Měření je prováděno z vyhrazeného IP rozsahu, který je jasně označen jak v databázi Whois, tak i v reverzním DNS.
Příklady analýz provedených pomocí OpenINTEL: V .nl a .se se používá finanční motivace pro zavádění DNSSECu. Hypotéza je, že toto bude vyhovovat hlavně velkým operátorům. Ta se potvrdila – 14 operátorů .nl a 3 operátoři .se podepisují 80 procent všech domén s DNSSEC. Bylo zjištěno, že někteří operátoři používají slabé klíče jako 1024bit RSA, které nikdy nemění. Když toto zjištění prezentovali ve Švédsku, tamní registr změnil finanční motivaci tak, aby byla vyžadována vyšší úroveň bezpečnosti – začaly být vyžadovány i například TLSA záznamy pro bezpečné doručování pošty. Operátor Binero například zareagoval tak, že kompletně vypnul DNSSEC a následně ho zapnul znovu s použitím ECDSA.
Willem Toorop
Druhá analýza řeší, které služby jsou závislé na jednom DNS operátorovi, konkrétně operátorovi Dyn, který byl v roce 2016 pod velkým útokem. Také je možné analyzovat rozdíl TTL mezi nadřazenou a podřazenou zónou − například .com má TTL 2 dny, ale většina podřízených zón má TTL mnohem kratší. To je signál pro registr, že by měl dobu TTL zkrátit. Zajímavá je také analýza diverzity DNS serverů. Správce .nl kdysi vyžadoval dva servery v rozdílných autonomních systémech. Už to neplatí, přesto skoro polovina domén je takto nastavena.
Co všechno lidé vloží do TXT záznamů? „Viděli jsme JavaScript, PowerShell, bash, Python. Zdá se, že jde o zlomyslný kód,“ vyjmenovává Willem Toorop. Kromě toho se v TXT záznamech objevují i naprosté hlouposti, třeba privátní klíč od DKIM. „Lidé zřejmě nasazují DKIM systémem pokus omyl.“
Co si myslet o DNS-over-HTTPS?
Standard DNS-over-HTTPS v současné době rezonuje nejrůznějšími prostředími. Svůj příspěvek přidal i Bert Hubbert, vývojář PowerDNS.
Bert Hubbert
DNS je poslední nešifrovaný protokol na internetu. Problém je, že DNS není jednoduchý protokol jako HTTP, ve skutečnosti je v cestě mnoho přeskoků ze serveru na server a je nutné zabezpečit všechny. Když v devadesátých letech přišel nápad na šifrované DNS, bylo v té době šifrování nežádoucí pro USA, takže nakonec vznikl DNSSEC, který pomocí tisíců stránek RFC zajišťuje pouze autenticitu, nikoli šifrování. V roce 2009 vyvinul Daniel J. Bernstein šifrování přenosu pomocí DNSCurve/DNSCrypto, „Jenže to bylo tak Bernsteinovské, že to nikdo nepoužíval.“
V roce 2015 konečně přišlo IETF s DNS-over-TLS. Jenže to pořád nikdo nepoužíval. „Takže v roce 2018 přišlo DNS-over-HTTPS, protože HTTPS je TCP moderní doby.“ Jenže se pořád nic nedělo. Pro výrobce operačních systémů a hardwaru je DNS nudné a nikoho nezajímá. Proto pořád používáme původní nešifrované DNS. Nakonec přišli výrobci prohlížečů a velcí cloudoví operátoři, kteří se živí sběrem osobních dat, a začali společně tvrdit, že je nutné chránit soukromí. „Na tom něco je, ale je zajímavé sledovat, kdo se o toto snaží.“
Před časem začaly nizozemské úřady vyšetřovat člověka jen proto, že volal na číslo švýcarské banky. Z toho je vidět, že samotná metadata jsou někdy velmi důležitá. Metadata unikají v HTTP hlavičkách, DNS, SNI a OCSP komunikaci při ověřování certifikátů. Jedna z cest je použít tunel k někomu, komu důvěřujete. Jenže ten pak má přístup zcela ke všemu. To odpovídá definici soukromí podle Google: „Vaše soukromí je mezi námi a vámi.“ Problém je, že jde o trochu jinou definici, než jak chápou soukromí někteří lidé, jako „pouze moje tajemství“.
Přístup DNS-over-Cloud přináší velké problémy s DNS firewally, split-horizon DNS, nebo výkonem sítí CDN. „Pokud pošlete své DNS do Cloudflare, jak se zařídí, že vám bude dobře fungovat streaming z Akamai? Předpokládám, že v Cloudflare nemají speciální oddělení na zlepšování kvality služeb konkurence.“ Dále podniky usídlené v USA podle nařízení FISA 702 mají příkaz vydávat vládě data libovolných občanů cizích zemí. Dokonce i v případě, že jsou servery umístěné v Evropě. „Říkejme tomu DNS-over-Trump,“ vtipkuje Bert Hubbert.
Dálší potenciální zásah do soukromí u DNS-over-TLS představuje obnovení dřívější relace. Navázání šifrovaného spojení totiž nějakou dobu trvá, takže je výhodné nenavazovat nové spojení při každém požadavku, ale jednou sestavené spojení pouze uspat a později obnovit. To ale znamená uložení cookie, která dokáže sledovat uživatele i zatímco mění sítě. Takže zatímco dříve byla DNS data namíchaná ze všech uživatelů daného resolveru, při použití DNS-over-Cloud je možné sledovat jednotlivce.
Proč to cloudoví operátoři dělají? Cloudflare tvrdí, že je to proto, že můžou. Základní myšlenka je, že DNS od ISP je špatné, protože ISP například filtrují nežádoucí jména, nebo naopak odchytávají neexistující domény. „Když žijete v USA a přečtete si podmínky ochrany soukromí společnosti Verizon, zjistíte, že všechna vaše data prodají. Proti tomu je smlouva s Googlem mnohem výhodnější.“ Proto v USA může být DNS-over-Cloud lepší variantou.
Co se tedy stane? Mozilla se rozhodla, že zavede DoH systémem opt-out, kdy se pouze objeví notifikace, kterou naprostá většina uživatelů odklikne, aniž si uvědomí, co vlastně provádí. Google se chová trochu lépe, Android oportunisticky zkouší DoT s místním DNS resolverem. Je důležité, aby všichni provozovatelé DNS resolverů zavedli DoT, protože pokud ho nezavedou, nemohou se divit, že výrobci telefonů a prohlížečů budou vnucovat své vlastní šifrované DNS.
Má vůbec cenu zabývat se šifrováním DNS v rámci infrastruktury operátora, kterému beztak musíte věřit? Podle Berta Hubberta ano: problém je, že spousta operátorů neprovozuje svou infrastrukturu, navíc v nich pracuje až příliš mnoho lidí. Zašifrování proto má cenu i v takovém případě.
Jak probíhá neplánované hašení datacentra
Steve Wright
Steve Wrigt spravuje datacentra ve Velké Británii a nedávno zažil vypuštění hasicího systému FM-200.
Standardně se v elektronické požární signalizaci používají optické a ionizační detektory kouře. Problém je, že tyto reagují až v okamžiku zahoření, když už je požár celkem rozvinutý. Proto se v datacentrech používají systémy VESDA – Very Early Smoke Detection Apparatus. VESDA je až 1000krát účinnější než jednotlivé detektory, takže se aktivuje velmi často. Stačí například kouř uniklý z napájecího zdroje serveru. Proto je obvykle první reakcí poslat obsluhu na obhlídku. Teprve když se přidá hlášení i z dalších detektorů, se zřejmě bude jednat o skutečný požár a je na čase vypustit hasicí plyn. To je velmi drahá záležitost v řádu desetitisíců eur.
Pro samotné hašení se používá buď voda, omezení koncentrace kyslíku, nebo chemická hasiva. „Osobně jsem se nesetkal s hasicím systémem na bázi vody pro datacentra. Možná se používá hlavně tam, kde je potřeba ochránit samotnou budovu, nikoli IT vybavení.“ Při omezení koncentrace kyslíku zhruba pod dvanáct procent nemůže hoření probíhat. Používají se plyny Argonit nebo Inergen, které snižují koncentraci kyslíku na zhruba deset procent. Pro člověka nejsou nebezpečné, ovšem pokud má nějaké dřívější zdravotní problémy, mohou se pobytem v serverovně zhoršit. Jako chemická hasiva se používají plyny jako FM-200. Ani ty nejsou pro člověka nebezpečné.
V ve zmíněném datacentru došlo k nepravděpodobné závadě na jedné tlakové lahvi s hasicím plynem FM-200. Ventil se otevřel a začal vypouštět hasicí plyn. Ukázalo se, že výdechy hasicího systému jsou velmi blízko detektorům kouře, takže samotné mimovolné hašení vyvolalo ostrý požární poplach. Namísto prvního varování od VESDA došlo během sekundy ke změně stavu z „žádný požár“ na „požár velkého rozsahu“. Dohled datacentra neměl žádnou šanci zjistit, co se doopravdy děje, a případně zastavit řádné spuštění zbytku hasicího systému.
Vedlejším efektem vypuštění hasicího plynu je zamrznutí celého potrubí vlivem expanze. Po určité době začne námraza tát a z celého potrubí odkapávat. Dalším vedlejším efektem je nutnost odstavit po dobu hašení klimatizaci, aby nevháněla do místnosti čerstvý kyslík. To způsobí poměrně rychlý nárůst teploty, který sám o sobě hrozí poškozením IT vybavení. Nejzajímavější je ale vliv hašení na rotační pevné disky. Jedno hašení produkovalo tak intenzivní pískání, že vyřadilo z provozu všechny pevné disky. Ukázalo se, že pevné disky nemají rády hluk nad 110 dB. Dnes se proto používají speciálně tvarované výdechy hasicího systému pro datacentra, které hluk omezují.
Vypuštění hasicího plynu není pro člověka přímo nebezpečné, přesto je velmi dobré v místnosti, kde se hasí, nebýt. Předně, jedná se o plyn pod poměrně velkým tlakem, který dokáže vyrvat ze zdí a stropů nedokonale upevněné potrubí. Samotné tlakové nádoby jsou také velmi nebezpečné, musí být vždy připevněny a zajištěny proti pádu.
Co se může stát, když spadne nepřipevněná tlaková lahev na zem.
Pokud jedna spadne na zem, začne po zemi létat a ničit vše okolo. Pokud je lahví víc, spustí se řetězová reakce. „V jednom datacentru se to stalo, jednoho člověka to stálo život, dalších pět lidí skončilo s trvalými následky. Svému týmu vždycky říkám: ,začne-li v datacentru požár a jste uvnitř, raději odejděte. Servery dokážeme vyměnit, život vrátit nedokážeme,'“ uzavřel přednášku Steve Wright.
RPKI strmě roste
Job Snijders mluvil o aktuálních problémech na globálním Internetu. Při nastavování BGP je poměrně jednoduché nastavit správně zátěž ve směru dovnitř, mnohem horší je to pro směr ven, tedy od nás do zbytku Internetu. Na trhu se objevují různé optimalizátory, snažící se využít pronajaté linky tak, aby to bylo co nejefektivnější a nejekonomičtější. Dělají to pomocí vkládání falešných specifičtějších cest do interního BGP. Když takové záznamy uniknou, rozbije to celý internet. Všichni začnou posílat provoz do naší sítě, my ho začneme vracet zpátky.
Takové incidenty se bohužel dějí velmi často. Optimalizátory například ve výchozím stavu nevyplňují komunitu NO_EXPORT, přestože by mohla podobným incidentům zabránit. Záchranou nakonec je validace RPKI a správně nastavený parametr max_length, stejně jako přímý peering, který eliminuje únosy s delší cestou. Operátor NTT připravil nástroj BGPalerter, který sbírá data z RIS a když vidí něco podezřelého – podle nastavení monitorovaných prefixů – dokáže poslat e-mail, napsat na Telegram, do Slacku, a podobně.
Ben Cartwright-Cox měřil vývoj RPKI po roce od posledního měření. Narostl výrazně počet validních prefixů, počet nevalidních zůstává konstantní, kolem 6000 prefixů. Bylo změřeno, že ve skutečnosti do oněch nevalidních prefixů téměř žádný provoz neteče, takže není žádný problém je začít zahazovat. Častá stížnost spočívá v tom, že nejde o validaci celé cesty, ale jen zdrojového AS. Ve skutečnosti to není velký problém, protože cesty jsou krátké a tak unesený prefix prohraje v souboji délek.
O RPKI se dá také mluvit jako o vylepšené IRR databázi; ty jsou totiž známé tím, že obsahují nevalidovaná data, která může vkládat úplně kdokoli. Za rok vrostl počet autonomních systémů, které validují RPKI, z 50 na 616. Je tedy pokrytá velká část Internetu. „Pokud bude vývoj pokračovat nastoleným trendem, v roce 2021 bude počet validujících autonomních systému větší než počet všech autonomních systémů,“ vtipkuje na závěr Ben Cartwright-Cox.
ČLÁNKY DO MAILU