Hosting

Přihlášení

@ IN SOA domény.dns.enum.mojeid.internet. nic.cz.
Aktualizace: 9 min 15 sek zpět

ODVR – vypnutí ochrany Rebinding a úpravy DoH

St, 07/08/2020 - 14:30
DNS rebinding

Naše otevřené DNSSEC validující resolvery měly od začátku provozu (tedy i v době, kdy ještě běžely na DNS resolveru Unbound) nastavenu ochranu proti DNS Rebindingu. Toto nastavení jsme zachovali i při spuštění nového ODVR anycastu postaveného již na našem Knot Resolveru.

V praxi taková ochrana funguje tak, že pokud se v DNS zóně vyskytují A/AAAA záznamy s IP adresami z privátních rozsahů, resolver zablokuje doménový překlad. Uživateli se vrátí odpověď se stavem „REFUSED“ a v textové formě pak hlášení „blocked by DNS rebinding protection“.

O filtrování privátních rozsahů na veřejném DNS jsme v době spouštění ODVR moc neváhali. Nebyl rozumný důvod, proč by se měly privátní adresy v těchto zónách objevovat. Jenomže vše se vyvíjí a DNS nezůstává pozadu. Ukazuje se, a zpětná vazba uživatelů ODVR to jen potvrzuje, že pro některé účely překládat privátní adresy smysl má. Níže uvádím několik příkladů, které potřebu ochrany proti DNS rebindingu na ODVR oslabují:

  • filtrování e-mailů založené na DNSBL. Jedná se o jednu z účinných metod, jak ještě před přijetím e-mailu zjistit, že příchozí e-mail je s největší pravděpodobností spam. DNSBL servery pracují s privátními adresami a zapnutá ochrana proti DNS rebindingu je v podstatě blokuje
  • doménové záznamy, které jsou záměrně směrovány na privátní rozsahy v interní síti, v domácnostech či menších sítích, kde nemá smysl nastavovat a udržovat další DNS služby. Typickým příkladem mohou být různé interní webové služby nebo vývojová prostředí.
  • smysluplnou konfiguraci ochrany proti DNS Rebindingu stejně není možné univerzálně nakonfigurovat, protože někteří uživatelé potřebují IP adresy z rozsahu 172.16.*.*, jiní z 192.168.1.* apod.
  • Google, Cloudflare a velká část poskytovatelů připojení má na svých DNS resolverech tuto ochranu standardně vypnutou, což uživatele ODVR může mást

Na základě výše uvedeného jsme se shodli, že ochranu DNS Rebinding na celém ODVR anycastu k dnešnímu dni zcela vypneme.

DoH

Přibližně před rokem jsme na novém ODVR anycastu zprovoznili i DNS-over-HTTPs. Jelikož šlo poměrně o novou implementaci, rozhodli jsme se, že tento protokol budeme zatím zkušebně provozovat pouze na jedné z IP adresy ODVR anycastu, konkrétně na 185.43.135.1/2001:148f:fffe::1, abychom získali zkušenosti s jeho podporou. Spolu s kolegy z týmu Knot Resolveru jsme implementaci postupně odladili, a tak jsme se rozhodli, že spustíme protokol DoH i na druhé anycastové IP adrese 193.17.47.1/2001:148f:ffff::1 a to také k dnešnímu dni.

Věřím, že vypnutím DNS Rebindingu si naše veřejné resolvery najdou zase další spokojené uživatele.

Kategorie:

Evropská komise vydala zprávu DESI. Česká republika si polepšila, ale…

Út, 06/16/2020 - 06:15

Od roku 2014 Evropská komise pravidelně sleduje a porovnává pokrok členských států EU v digitální oblasti v rámci tzv. Indexu digitální ekonomiky a společnosti (DESI). Dne 11. června 2020 Evropská komise vydala nejnovější zprávu DESI za rok 2020. Česká republika se umístila na 17. místě (vloni 18. místo), pozitivně byla hodnocena v kapitolách Lidský kapitál, Integrace digitálních technologií a Využívání internetových služeb. Naopak meziroční propad byl zaznamenán v kapitole Konektivita (z 19. na 24. místo) a Digitální veřejné služby (z 21. na 22. místo). Pojďme se na srovnání podívat blíže.

Zpráva je založena na datech sesbíraných v roce 2019 a tím, že je zpráva DESI vydávaná v podstatě v polovině roku 2020, subjektivně můžeme některá čísla vnímat jinak. Nicméně cíl Evropské komise je jasný – podpořit trošku té přirozené digitální soutěživosti mezi členskými státy a správně zvolenými slůvky pochválit nebo naopak jemně dloubnout pod žebra. U každého státu je navíc ke zprávě připojena podrobná kapitola o telekomunikacích.

Základní data sbírá Evropská komise od vládních úředníků a subjektů, které se pohybují na trhu. A i když se všichni snaží prodat úspěchy v daném roce a vyleštit powerpointové prezentace, úředníci Evropské komise mají většinou ten luxus pospojovat si všechny izolované grafy a čísla do souvislostí. Pamatuji si, že když Evropská komise začala tato srovnání v roce 2014 vydávat, jeden z náměstků ministerstva vnitra v růžových barvách líčil rozvoj českého e-governmentu a básnil o tom, jak jsou české datové schránky úžasná a skvělá záležitost, která pomáhá všem občanům v komunikaci s úřady. Úředník Evropské komise ho nechal dokončit oslavnou ódu a pak se jen suše zeptal (ano, myslím, že to byl Brit) – „A vy máte datovou schránku?“ Náměstkovo suché polknutí a slabé „Ne“ vydalo v tu chvíli za všechny prezentace.

Základní oblasti hodnocení jsou konektivita, lidský kapitál, využívání internetových služeb, integrace digitálních technologií a digitální veřejné služby.

Jak je hodnoceno Česko?

Česko je nejsilnější v integraci digitálních technologií, kde jeho výsledky převyšují průměr EU. Je to hlavně díky dobrým výsledkům v oblasti elektronického obchodu. Podíl osob zaměstnaných v oboru ICT a podíl absolventů v tomto oboru významně vzrostl, nicméně české (a nejen české) firmy stále hlásí potíže při hledání odborníků s digitálními dovednostmi. I když vláda zavádí nové digitální veřejné služby (míněn asi portál občana?), jejich využívání je však dosud omezené. Konektivita se nezlepšuje dostatečně rychle, zejména z důvodu nedostatečného pokrytí pevnými sítěmi s velmi vysokou kapacitou. Ani 4G pokrytí už ve srovnání s ostatními zeměmi EU nepůsobí nijak výjimečně. Velká část obyvatel čte zprávy na internetu a používá internetové bankovnictví.

I. Konektivita

S celkovým skóre konektivity ve výši 44,9 se Česko mezi zemeěmi EU řadí na 24. místo. Celkové využití pevného vysokorychlostního připojení je stejné (74 %) jako v předchozím roce a je o něco nižší než průměr EU. Pokrytí rychlým širokopásmovým připojením je v Česku stabilní (90 % v roce 2018 a 92 % v roce 2019), což je stále méně než EU stanovený cíl ve výši 100 % určený pro rok 2020. Pokrytí pevnými sítěmi s velmi vysokou kapacitou (28 % domácností v roce 2018) se nevýrazně zvýšilo na 29 %, a to výhradně v důsledku zavedení nových sítí FTTP, dosud však zůstává pod průměrem EU ve výši 44 % (včetně kabelových sítí modernizovaných na DOCSIS 3.1).

Počet domácností s pevným širokopásmovým připojením o rychlosti nejméně 100 Mb/s rovněž zaznamenal pouze mírný nárůst (z 18 % na 20 %) a Česko se u tohoto ukazatele dosud řadí relativně nízko (19. místo). Země vykazuje plné průměrné pokrytí 4G – touto technologií je nyní v Česku pokryto 100 % domácností.

Maloobchodní ceny v Česku jsou vyšší než průměr EU – Česko dosáhlo u indexu cen širokopásmového připojení skóre 57 oproti průměru EU ve výši 64, což je mezi všemi členskými státy EU řadí v této kategorii na 21. místo. Navzdory relativně vysokým cenám, zejména v mobilním segmentu, je využití širokopásmového připojení v Česku jen mírně pod průměrem EU.

U ukazatele připravenosti na 5G se Česko řadí na 15. místo. V zemi bylo zatím přiděleno 42 % spektra harmonizovaného na úrovni EU pro bezdrátové vysokorychlostní služby.

II. Lidský kapitál

Pokud jde o lidský kapitál, Česko obsadilo 14. místo, přičemž jeho skóre je těsně pod průměrem EU. Vzrostl podíl obyvatel s alespoň základními (62 %) a vyššími než základními (26 %) digitálními dovednostmi. Podíl osob zaměstnaných jako odborníci v oblasti ICT stoupl na 4,1 %, což je více než průměr EU (3,9 %). Největší koncentrace odborníků v oblasti ICT je v Praze, kde představují 7,9 % celkové zaměstnanosti. V segmentu ICT silně převládají muži. Pouze 10 % všech odborníků v oblasti ICT tvoří ženy – to je druhé nejnižší skóre v EU. Přesto (nebo právě proto) se DESI zpráva věnuje aktivitám organizace Czechitas.

Česko se více zapojilo do Evropského týdne programování. Počet registrovaných aktivit vzrostl o 54 % na 232 a zúčastnilo se jich více než 13 000 osob. 49 % účastníků tvořily dívky nebo ženy. Většina aktivit se uskutečnila ve dvou největších městech a 65 % ve školách. Zpráva také zmiňuje činnost české Digikoalice, která sdružuje 204 členů, kteří se pravidelně setkávají a řídí iniciativy, jež poskytují příležitosti v oblasti odborné přípravy a vzdělávání mladým lidem, zaměstnancům, starším občanům a uchazečům o zaměstnání.

Nedobré hodnocení v rámci srovnávání dostává české školství. Zpráva konstatuje, že české školy postrádají učitele s příslušnou kvalifikací v oblasti digitálních dovedností. Nejvyšší kontrolní úřad a Česká školní inspekce uvádějí, že navzdory stávající strategii digitálního vzdělávání se vzdělávací systém nepřizpůsobuje dostatečně rychle digitální transformaci. Mnozí učitelé nemají dostatek materiálů a necítí se dostatečně připraveni na to, že by měli vyučovat digitální dovednosti. Školy nemají přístup k odpovídající digitální infrastruktuře. Stáří 80 % počítačů, jež mají žáci k dispozici, je více než tři roky a školy nemají dostatek finančních prostředků na investice do moderního digitálního vybavení.

III. Využívání internetový služeb

Pokud jde o využívání internetových služeb, Česko i nadále postupuje na vyšší příčky. Země je nyní na 17. místě a má vyšší skóre než v roce 2019, dosud je však pod průměrem EU. Digitální mezera ve společnosti se zmenšuje, jelikož podíl osob, které internet nikdy nepoužily, klesl na 9 % (stejný jako průměr EU). 92 % uživatelů internetu v Česku čte noviny a časopisy on-line. To je nejvyšší skóre v celé EU.

„Podíl uživatelů, kteří prodávají on-line, se však snížil a podíl osob, které využívají komerční služby videa na vyžádání, je nejnižší v EU. To by mohlo souviset s vysokou cenou mobilních širokopásmových služeb. V důsledku toho mohou spotřebitelé omezovat používání internetových služeb na svých telefonech a tabletech.“ Dopad „vždyť vám to stačí“ nízkých datových limitů na digitální svět v jednom odstavci.

IV. Integrace digitálních technologií

Pokud jde o integraci digitálních technologií, Česko se posunulo na 9. místo a má skóre nad průměrem EU. Hlavní hnací silou v této oblasti je i nadále elektronický obchod. V Česku prodává on-line 28 % malých a středních podniků a obrat z elektronického obchodování již představuje více než pětinu jejich příjmů. To je druhé nejvyšší skóre v EU.

V zavádění nových digitálních technologií (analýza big data, cloud) jsou však české společnosti pod průměrem EU.

Česko je patnáctým největším konečným uživatelem průmyslových robotů na světě. Podle Svazu průmyslu a dopravy plánuje více než polovina společností v průběhu příštích pěti let zvýšit investice do aplikací Průmyslu 4.0. V tomto ohledu jsou větší společnosti aktivnější než malé a střední podniky. Hlavními důvody pro zavádění prvků Průmyslu 4.0 je zvýšení produktivity a snížení jednotkových nákladů na zaměstnance.

V. Digitální veřejné služby

V oblasti digitálních veřejných služeb kleslo Česko v pořadí EU na 22. místo, přičemž jeho skóre je výrazně pod průměrem EU. Země zvyšuje objem veřejných služeb, které mohou lidé a podniky využívat on-line. Žádný z ukazatelů však není vyšší než průměr EU a pouze polovina osob, které potřebují předložit orgánům veřejné správy úřední formuláře, tak činí elektronicky (průměr EU je 67 %).

Na konci roku 2019 nabízel Portál občana již 120 služeb on-line, měl však pouze 45 000 registrovaných uživatelů (0,7 % Čechů ve věku 15–64 let). Pozitivní vývoj se odehrává ve vydávání elektronických receptů, kdy v roce 2019 se vydává v průměru 6 milionů e-receptů měsíčně.

Evropská komise si všimla i slavného hackathonu na „vytvoření beta verze e-shopu“ pro elektronické dálniční známky (který byl původně plánován za 16 milionů EUR), a uvádí ho jako příklad alternativního přístupu k zadávání veřejných zakázek v oblasti IT. Nevíte, jak to skončilo…? Evropská komise pléduje za využívání open source, když píše že „přístup založený na otevřeném zdrojovém kódu by mohl více poskytovatelům umožnit nabízení nových služeb, které do již existujících systémů přilákají více lidí. Zátěž nadále představují i neúspěšné a předražené zakázky na služby ICT ve veřejné správě.“ Snad dočte státní správa i na tuhle poslední stránku.

Kdo dočůrá dál…

Po přečtení konkrétního hodnocení České republiky, pojďme splnit primární cíl DESI indexu a porovnat Českou republiku. Využijeme k tomu webu, kde Evropská komise umožňuje srovnání různých členských států a různých indikátorů, které vstupují do DESI indexu.

I. Konektivita

II. Lidský kapitál

III. Využívání internetových služeb

IV. Integrace digitálních technologií

V. Digitální veřejné služby

Vidíme, že ve V4 regionu vedeme v integraci digitálních technologiích a lidském kapitálu. A jak budou grafy vypadat, když se porovnáme s nejlépe hodnoceným státem v DESI hodnocení – Finskem.

I. Konektivita

II. Lidský kapitál

III. Využívání internetových služeb

IV. Integrace digitálních technologií

V. Digitální veřejné služby

Nemá se to dělat, ale pojďme se srovnat ještě s nejhůře hodnoceným státem.

I. Konektivita

II. Lidský kapitál

III. Využívání internetových služeb

IV. Integrace digitálních technologií

V. Digitální veřejné služby

Z těchto pár grafů si každý dokáže představit, jak si zhruba Česká republika stojí v mezinárodním srovnání. Už nyní je jasné, že srovnání pro rok 2020, které bude Evropská komise dělat příští rok, bude ovlivněno pandemií COVID-19. Zda Česká republika využije této krize, při které i největší odpírači digitálního světa viděli, že digitální nástroje pomáhají zmírnit dopady pandemie a mohou přinést nová řešení starých i nových problémů, uvidíme brzy. Držme si palce (i když to vlastně nestačí…).

Kategorie:

Nová verze Turris OS 5.0 je venku

Po, 06/08/2020 - 15:00

Vydali jsme novou verzi Turris OS 5.0, která je založená na nejnovější verzi OpenWrt 19.07.3 a je určená pro všechny routery Turris. Co se týče „modrých“ routerů Turris 1.x, tak v tomto případě se aktuálně jedná o experimentální podporu (týká se zařízení s microSD kartou a se souborovým systémem Btrfs). V článku vám představíme, co je nového, včetně možnosti zvolit si migraci z operačního systému Turris OS 3.x. Zmíníme se také o překážkách, které nám bránily v dřívějším vydání a také přidáme, na co se můžete těšit do budoucna.

Turris OS 5.0 – Úvod

Verze operačního systému označená 4.0 byla založena na stále podporované verzi OpenWrt 18.06. Té by ale měla v nejbližší době skončit podpora ze strany vývojářů OpenWrt. S vydáním nové hlavní verze jsme zase o krůček blíže k nejnovějším verzím OpenWrt. Během vývoje Turris OS 5.0 jsme narazili na několik překážek, s nimiž jsme se museli vyrovnat. Týkaly se různých kolizí balíčků, které poskytují stejně nazvaný soubor v totožné cestě, nebo neexistující balíčky, ty byly v upstreamu odstraněny, protože je nikdo neudržuje, nebo že daný software již není udržován. V našem systému jsme také neměli zapnutou jednu volbu v kernelu, díky čemuž v některých případech nebylo na routeru Turris Omnia možné načíst Wi-Fi ovladač pro ath9k. Za toto upozornění děkujeme našim beta testerům z fóra. Dále byl před vydáním nové verze OpenWrt aktualizován hostapd, který by sám o sobě nebyl problematický, jenže po aktualizaci tohoto balíčku se vypnuly všechny Wi-Fi sítě a nenaběhly, dokud nedošlo k restartu routeru. Ukázalo se, že se jedná o problém s netifd, který je konfiguračním daemonem pro síť v OpenWrt, a jeho chybné implementací sledovaní procesů. Většinu překážek se nám ale podařilo překonat. Na odstranění zbývajících problémů, které jsme zjistili při důkladném testování, usilovně pracujeme.

Novinky

Nyní se pojďme podívat na to nejzajímavější, co nám OpenWrt 19.07 přináší. Současně s tím vám představíme změny, které jsme si pro vás přichystali, a na kterých ještě děláme.

reForis

Velkou novinkou je postupný redesign webu Foris (reForis), kterým bychom rádi nahradili ten současný. Foris je tu s námi již delší dobu, a proto si zaslouží nový kabát „ušitý“ z moderních technologií jako jsou například Bootstrap, React a Flask. V aktuální verzi nám reForis přináší podporu snapshotů v grafickém rozhraní a také například umožňuje nastavení přesměrování na vlastní DNS server, který jsme si sami neurčili.ja

Pokud byste chtěli vyzkoušet reForis a poskytnout nám zpětnou vazbu, tak budeme samozřejmě velice rádi. Je jen nutné jej v tuto chvíli doinstalovat ve Forisu (záložka Aktualizace). Ještě několik verzí tu s námi budou obě rozhraní, abychom je mohli lépe otestovat, než reForis nahradí Foris úplně.

Migrace z verze Turris OS 3.x na Turris OS 5.x

Protože aktuálně podporujeme dvě verze Turris OS, ptali se nás uživatelé, zda plánujeme automatickou migraci z verze Turris OS 3.x na 5.x (abychom nemuseli udržovat dvě velmi rozdílné verze, které od sebe dělí řada let vývoje). Ano, automatickou migraci připravujeme a už teď najdete v naší dokumentaci návod, podle kterého můžete postupovat. Opět, budeme velice rádi, když nám na fóru poskytnete zpětnou vazbu.

Mezi další zajímavosti patří například používání cronie jako plánovače úloh, místo vixie-cronu, který již není vyvíjen. Dále je zde nová verze Updateru, u kterého došlo k výraznému přepisu zdrojového kódu a ve výsledku nyní zabírá méně operační paměti během aktualizačního procesu. Také jsme přidali ovladače pro další DVB tunery jako je třeba velmi rozšířená Astrometa DVB-T2 2018.

Pojďme se nyní podívat na novinky OpenWrt verze 19.07:

Samba 4

Ve verzi OpenWrt 18.06 najdete Sambu, ale ve verzi 3, která je zranitelná vůči bezpečnostním chybám. Samba je služba pro sdílení souborů, dokumentů a fotek především v rámci lokální sítě, ale také do Internetu. Ve verzi OpenWrt 19.07 najdete Sambu 4. Ta je stále aktivně vyvíjena, a proto jsme se rozhodli připravit základní migraci nastavení ze Samby 3 na Sambu 4.

Podpora WPA3

OpenWrt přináší základní podporu pro standard WPA3. Ten ale není ve výchozím stavu nastaven a vyžaduje instalaci dodatečných balíčků. Prozatím neuvažujeme o tom, že bychom tyto balíčky zahrnuly do základní instalace, jelikož u některých zařízení by se mohla projevit nekompabilita a problémy s Wi-Fi připojením při používání WPA2+WPA3 módu (velká část zařízení podporuje stále pouze WPA2).

LuCI

Ani vývojáři v OpenWrt nezahálí a pracují na přepisování jednotlivých částí administračního rozhraní LuCI. Zde došlo k výrazné změně chování – většina procesů probíhá na straně klienta a to za pomocí Javascriptu.

A to je za nás v tuto chvíli vše. Za vývojový tým projektu Turris bych chtěl poděkovat všem uživatelům routerů Turris, kteří se podíleli na testování nové verze. Velice si vážíme vaší pomoci a podpory a věříme, že pro vás naše novinky budou zajímavě a přínosné. O své připomínky se můžete podělit jak našem fóru, tak zde na blogu sdružení CZ.NIC.

Kategorie:

Průzkum: Jak nastavujete DNS resolvery?

Po, 06/08/2020 - 10:25

DNS resolvery neustále přidávají nové funkce, aniž by odstraňovaly ty staré. Tento trend však nemůže pokračovat donekonečna, protože by se software nakonec zhroutil pod vlastní vahou. Které funkce jsou v praxi využívány a které je možné odebrat? Předkládáme předběžné výsledky průzkumu mezi správci DNS resolverů a také zveme čtenáře, aby se zapojili do průzkumu napříč výrobci, který běží do 30. června 2020.

Proč potřebují výrobci zpětnou vazbu

DNS protokol je tu už 33 let a je velice komplexní: jeho specifikace se rozrostly ze 132 stránek v roce 1987 na více než 3 000 stránek a nadále roste! DNS software nabízí také mnoho funkcí specifických pro výrobce, což ještě zvyšuje jeho složitost, a ta zase vede k delším manuálům, konfiguraci náchylnější na chyby a zabugovanému, méně spolehlivému softwaru.

Výrobci se teoreticky mohou rozhodnout zastaralé funkce a části kódu odstranit, čímž sníží pravděpodobnost výskytu chyb, jenže to by museli vědět, které funkce jejich uživatelé ve skutečnosti používají. Odstranění zastaralého kódu by jistě pomohlo oběma stranám. Avšak právě k tomu chybí zpětná vazba od správců. Výrobci se navíc snaží být konzervativní – přidávají nové funkce a neodebírají staré – a to je samozřejmě strategie, která není dlouhodobě udržitelná.

Jak taková historická zátěž vypadá v praxi? Pojďme se podívat na dokumentaci k různým softwarovým balíčkům, odhadnout počet možností a porovnat celkový počet možností s používáním popsaným v dosud obdržených 120 vyplněných detailních dotaznících.

BIND: $ man named.conf | sed -e 's/ //g' | sort -u | wc -l

Konfigurační soubor named.conf pro BIND 9.16 podporuje zhruba něco přes 400 různých nastavení, z nichž mnohé mohou být použity v různých kontextech (global, view, zone) a interagovat spolu, a to také s autoritativní částí DNS serveru, který je součástí BINDu. Údaje z průzkumu momentálně ukazují, že se v praxi využívá jen 65 ze 400 možností.

Kandidát na nejobskurnější nastavení, které se v odpovědích v průzkumu zatím neobjevilo: „dialup” s výběrem z 6 režimů. Používá to ještě někdo? (Pravděpodobně ano.)

Unbound: $ man unbound.conf | grep '^ *[a-zA-Z0-9_-]*:' | sed -e 's/ //g' -e 's/:.*$//' | sort -u | wc -l

Konfigurační soubor unbound.conf Unbound 1.10.0 podporuje zhruba něco přes 230 možností, ale z průzkumu momentálně vyplývá, že jich je aktivně využíváno pouze 30, což může být dáno tím, že své konfigurace v rámci průzkumu dobrovolně sdílelo jen několik správců Unboundu.

Kandidát na nejobskurnější možnost, která se v odpovědích v průzkumu zatím neobjevila: „dlv-anchor

PowerDNS Recursor: $ pdns_recursor --help | fgrep -- -- | wc -l

PowerDNS Recursor 4.3.0 máv konfiguračním souboru 152 možností, což je výrazně méně, ale také má pro účely konfigurace zabudovaný jazykLua, díky čemuž je jeho konfigurační soubor Turingovsky kompletní.

Průzkum nyní nemá dostatek dat od uživatelů funkce PowerDNS, ale zato má kandidáta na nejobskurnější možnost: „distribution-pipe-buffer-size“.

Knot Resolver 5.1.1 je nejnovější přírustek do rodiny rekurzivních resolverů, ale jeho nevině vypadající konfigurační soubor je prakticky programem v jazyce Lua s nekonečnými možnostmi. Data průzkumu momentálně ukazují, že někteří uživatelé jazyk Lua používají ke skriptování svých vlastních funkcí uvnitř resolveru, ale většina respondentů používá pouze předpřipravené funkce dodávané se softwarem. To vede k otázce, zda konfigurace v jazyce Lua stojí za to, nebo zda by bylo možné ji nahradit něčím uživatelsky přívětivějším.

Kandidát na nejobskurnější možnost, která se v odpovědích v průzkumu zatím neobjevila: modules.unload(‘detect_time_jump’)

Jak vidíte, všechny čtyři implementace nabízejí široké možnosti konfigurace – to je spousta kódu, který je potřeba udržovat a testovat, a to hlavně proto, že spolu funkce vzájemně interagují. Náš průzkum zároveň ukazuje, že mnohé funkce pravděpodobně nejsou využívány, což nabízí příležitost odstranit historický balast. Proto vás prosíme, zúčastněte se průzkumu, a pomozte nám tak zjistit, které zastaralé části mohou být odstraněny a s nimi i chyby které způsobují. Povede to k spolehlivějšímu software a zároveň i jednodušší konfiguraci.

Snad je teď jasnější, proč výrobci potřebují více zpětné vazby od uživatelů.

Jak špatné je to s nedostatečnou zpětnou vazbou?

Abychom ilustrovali rozsah problému, uděláme si hrubý odhad toho, kolik provozovatelů poskytuje výrobcům DNS resolverů zpětnou vazbu.

Odhad č. 1: Počet osob, které komunikují s výrobci

Tady použijeme veřejně dostupné zdroje k odhadnutí počtu lidí, kteří s výrobci komunikovali.

Všechny čtyři projekty mají elektronický mailing list, takže můžeme stáhnout archivy a použít několik regexů k získání počtu unikátních e-mailových adres:

$ grep -o -h '^From [^ ]\+ at [^ ]\+ ' *-users/2019-*.txt | sort -fu | wc -l

Výsledek je 534 e-mailových adres včetně přispěvatelů, kteří pracují na všech čtyřech projektech.

Všechny čtyři projekty mají také veřejné bug trackery, tudíž můžeme spočítat uživatele, kteří během roku 2019 nahlásili problém nebo nějaký okomentovali. Aby byl tento úkol proveditelný, analýzu si trochu zjednodušíme:

  • Nebudeme se pokoušet odečítat interakce zaměstnanců samotných výrobců.
  • BIND a PowerDNS neoddělují své repozitáře pro rekurzivní a autoritativní servery – proto budeme počítat všechny komunikace v těchto dvou repozitářích.
  • Nebudeme deduplikovávat uživatele mezi GitHubem a soukromými instancemi GitLabů používanými různými výrobci.

Jednoduchým skriptem založeným na exportu GitHub API a Gitlab CSV získáme 400 účtů, které přidali v roce 2019 alespoň jeden komentář ve veřejných trackerech (určitě přemrštěný odhad).

V poslední řadě také musíme započítat zákazníky komunikující s výrobci soukromě, což je mnohem složitější. ISC naštěstí zveřejňuje podrobný roční přehled, který odhaluje, že dalších zhruba 100 zákazníků může komunikovat s ISC soukromě. Další výrobci tyto čísla nezveřejňují, takže můžeme extrapolovat čísla z ISC na všechny čtyři open-source výrobce, a získáme tak dalších 400 uživatelů komunikujících soukromě.

Nakonec můžeme shrnout celkový počet lidí komunikujících s výrobci během roku 2019:

  • veřejné mailing listy = 530 (včetně zaměstnanců výrobců)
  • veřejné bug trackery = 400 (bez deduplikace napříč projekty)
  • odhadovaný počet zákazníků komunikujících soukromě = 4 x 100 = 400 (extrapolováno z dat ISC)

Celkem je to 1330 lidí, což je téměř jistě nadsazený odhad. Co to ale znamená? V jakém je to poměru k počtu provozovatelů DNS resolverů?

Odhad č. 2: Počet provozovatelů

Získat přesné číslo je nemožné, ale můžeme určit horní a spodní mez.

Velmi konzervativní spodní hranice by mohl být počet Autonomních systémů používaných na Internetu. V současnosti existuje zhruba 67 000 provozovatelů, kterým záleží na infrastruktuře Internetu natolik, aby provozovali svůj vlastní AS, a proto pravděpodobně provozují i další zásadní internetové služby, jako je DNS resolver.

Stanovit horní hranici je daleko složitější. Kdybychom se omezili jen na rekurzivní DNS resolvery, mohli bychom náš odhad založit na počtu unikátních IP adres odesílajících DNS dotazy na DNS root servery během jednoho dne, ale počet unikátních zdrojových IP adres vypočítaný pro všechny instance root serverů není k dispozici. Musíme proto využít nezávislých statistik jednotlivých provozovatelů root serverů. Z nich má nejvyšší počet unikátních zdrojových IP adres zaznamenaných za jeden den server L-root – toto číslo se pohybuje kolem 8 milionů.

Tím jsme získali velmi široké rozpětí od 67 000 do 8 000 000.

Jaká část provozovatelů komunikuje s výrobci?

Nakonec můžeme odhadnout, kolik provozovatelů během roku 2019 komunikovalo s výrobci DNS software:

horní hranice = (1330 lidí komunikujících s výrobci v roce 2019) / (67 000 autonomních systémů) = 2 %

spodní hranice = (1330 lidí komunikujících s výrobci v roce 2019) / (8 000 000 zdrojových adres) = 0,017 %

Z toto můžeme usoudit, že pouze 0,017 až 2 % provozovatelů během roku 2019 komunikovalo s alespoň jedním výrobcem DNS software. Výrobcům tak chybí zpětná vazba, a mají tak v principu dvě možnosti:

  • Nadále udržovat všechny funkce, včetně těch nepoužívaných, a vytvářet tak software, který obsahuje více bugů a je pro všechny složitější na konfiguraci.
  • Odstranit funkce, které malý zlomek „komunikujících“ uživatelů nepoužívá, což ale může vést k odstranění funkcí, které potřebují „mlčící“ uživatelé.

Pokud se vám ani jedna z těchto možností nezamlouvá, zapojte se do našeho průzkumu a pomozte nám to změnit.

Lepší pozdě než nikdy

Průzkum běží do 30. června 2020 a dává vám příležitost říct výrobcům, které funkce potřebujete a neměly by být odstraněny, vyjádřit svá přání ohledně budoucího vývoje konfiguračních rozhraní, podpory DNS-over-TLS a DNS-over-HTTPS atd.

Manuální průzkum umístěný na webu s formuláři má samozřejmě značné limity. Proto se u dotazník také ptá na postoje k zabudovaným funkcím „call home“, které by mohly v budoucnu sběr dat automatizovat.

Dejte nám vědět, co si myslíte.

Kategorie:

Spouštíme DNS crawler

Po, 06/01/2020 - 10:18

V rámci projektu ADAM (Advanced DNS Analytics and Measurements) uvádí Laboratoře CZ.NIC ve spolupráci s CSIRT.CZ do produkčního provozu nástroj DNS crawler. Naším záměrem je periodicky procházet všechny domény 2. úrovně pod TLD .cz, získávat o nich různá veřejně dostupná data a ta pak dále zpracovávat. I když to jeho jméno přímo nenapovídá, DNS crawler bude kromě sběru dat z DNS také komunikovat s webovým a e-mailovým serverem každé domény. Počítáme s pravidelnými běhy ve dvou periodách: většina datových položek se bude sbírat každý týden, pouze obsah hlavních webových stránek <doména>.cz nebo www.<doména>.cz se bude stahovat jen jednou měsíčně. Zvláštnímu dohledu budou navíc podrobeny nově zaregistrované domény, u nichž je větší pravděpodobnost výskytu nějakého problému – jejich data se budou po dobu prvních dvou týdnů jejich existence stahovat denně. Software i režim jeho použití jsou navrženy tak, aby dopady na provoz domén druhé úrovně a síťovou infrastrukturu obecně byly prakticky zanedbatelné. Získaná data budou využita ke třem hlavním účelům:

  • pro různé statistiky a analýzy, které budou pravidelně i jednorázově zveřejňovány a poslouží mimo jiné k efektivnější správě a plánování dalšího rozvoje služby DNS, kterou sdružení provozuje
  • pro včasné odhalování problémů a anomálií v DNS, které mohou být způsobeny jak poruchami zařízení nebo chybami v konfiguraci a zónových datech, tak i zlovolnými aktivitami
  • pro klasifikaci webových stránek metodami strojového učení, především s cílem zvýšení bezpečnosti zóny .cz (např. odhalováním falešných e-shopů nebo domén využívaných malwarem).

Jsme si dobře vědomi toho, že podobné skenování síťových zdrojů ve velkém je dvojsečná záležitost – profylaktické skenování (náš případ) se na první pohled téměř neliší od vyhledávání vhodných obětí pro síťové útoky. Proto se snažíme o maximální otevřenost:

  • Software DNS crawleru, který ke skenování zóny .cz používáme, je open source – každý si ho proto může vyzkoušet, případně prohlédnout jeho zdrojový kód (v jazyku Python).
  • Zveřejňujeme kompletní soupis všech dat, která sbíráme, i interní pravidla pro jejich použití.
  • Zveřejňujeme i identitu (IP adresy) serverů, které skenování provádějí.

Podrobné informace týkající se provozu DNS crawleru včetně kontaktních adres jsou k dispozici na webové stránce https://csirt.cz/cs/dns-crawler. Chtěli bychom touto cestou požádat o spolupráci operátory sítí, ISP a poskytovatele služeb, kterých se bude tak či onak tato naše aktivita dotýkat. Zjistíte-li jakékoli problémy spojené s provozem DNS crawleru, dejte nám o nich prosím vědět, například e-mailem na adresu dns-crawler@nic.cz. Děkujeme!

Kategorie:

Mladí lidé chtějí srozumitelnější uživatelské podmínky

Ne, 05/24/2020 - 22:30

U příležitosti Dne bezpečnějšího internetu proběhlo v sídle Evropské komise setkání zástupců iniciativy „Better Internet for Kids“ (BIK) s globálními technologickými firmami. Českou republiku reprezentoval Matěj Bednář, student kvinty Gymnázia Ústí nad Orlicí, a spolu s dalšími pěti mladými ambasadory ze zemí EU zde přednesl svůj názor na uživatelské podmínky. Rád by se zasadil i o bezpečnější výchozí nastavení profilů na sociálních sítích.

Matěj upozornil na nesrozumitelnost většiny uživatelských a smluvních podmínek, které najdeme u každé internetové služby, platformy či aplikace. Texty často bývají velmi dlouhé, nepřívětivé, psané drobným písmem a mnohdy nejsou ani přeložené do všech jazyků zemí, kde je možné aplikaci stáhnout a používat. I přesto, že je to v rozporu s Obecným nařízením na ochranu osobních údajů (GDPR), které společnostem ukládá povinnost poskytovat informace v jednoduché, rozpoznatelné a přístupné formě, internet se stále nesrozumitelnými texty jen hemží.

Mladí zástupci BIK se rozhodli v rámci své iniciativy #Pledge2Youth bojovat za větší srozumitelnost uživatelských podmínek pro děti (a nejen pro ně). Apelují na to, aby byly psané jednodušší formou a aby jejich tvůrci používali pro lepší pochopení např. infografiky, animace či krátká videa: „Naším cílem je pomoci všem pochopit, jaká práva a povinnosti uživatelé mají. Víme, že z právních důvodů nemůžeme změnit uživatelské podmínky, místo toho však chceme změnit způsob, jakým je vysvětlujeme.“

Další téma, které skupina mladých lidí otevřela, se týkalo nastavení ochrany soukromí, jež před několika lety zavedlo mnoho sociálních sítí. Rádi by prosadili, aby výchozí nastavení profilů obsahovalo vyšší míru zabezpečení než dosud. Děti a mladiství tak budou více chráněni před kyberšikanou, kybergroomingem a dalšími nebezpečnými jevy. Ambasadoři mají v plánu propagovat především ty sociální sítě, které již takové bezpečné výchozí nastavení mají.

Nezbývá, než držet zástupcům „Better Internet for Kids“ palce, aby se jim jejich návrhy podařilo prosadit a pomohli tak vybudovat „lepší internet“ pro naše děti.

Kategorie:

NXNSAttack: aktualizujte své resolvery a zastavte nový druh útoku náhodnými dotazy

Čt, 05/21/2020 - 11:13

Tento článek popisuje NXNSAttack, nově objevenou zranitelnost protokolu DNS, která postihuje většinu rekurzivních DNS resolverů. Umožňuje provádět útok dotazováním na náhodné subdomény (random subdomain attack) pomocí delegačního mechanismu DNS, což vede k vysokému zesílení počtu paketů od útočníka směrem k oběti.

Než začneme

Pokud spravujete nějaký DNS resolver, ať už jakékoliv výrobce, prosím aktualizujte ho na nejnovější verzi. (Pokud jste teď zklamaní, že musíte narychlo aktualizovat, zeptejte se svého výrobce na včasná upozornění na bezpečnostní aktualizace.)

Pokud chcete vědět, jak útok funguje a jak před ním můžete příště ochránit své systémy, čtěte dál.

Princip NXNSAttack

Nově objevená zranitelnost zneužívá delegační mechanismus v DNS protokolu k tomu, aby DNS resolvery posílaly velké množství DNS dotazů na autoritativní servery podle přání útočníka. Jak je to možné?

Celý DNS je postaven na principu delegování, kdy autoritativní servery DNS odpovědné za vyšší úrovně hierarchie DNS delegují (můžeme také říci přesměrovávají) dotazy pro domény nižší úrovně na jiné servery, čímž odpadá potřeba mít jednu obrovskou databázi s DNS daty pro celý Internet.

Takto například autoritativní DNS server pojmenovaný „a.gtld-servers.com.“, který odpovídá za doménu „com.“, deleguje dotazy „example.com. A” na jinou sadu serverů:

$ kdig @a.gtld-servers.com example.com A ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10976 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.com. IN A ;; AUTHORITY SECTION: example.com. 172800 IN NS a.iana-servers.net. example.com. 172800 IN NS b.iana-servers.net. ;; From 2001:503:a83e::2:30@53(UDP) in 46.9 ms

Zde vidíme, že i když jsme se dotazovali na „example.com. typ A“, autoritativní server pro doménu „com.“ nám odpověděl delegací pro doménu „example.com.“, která obsahuje názvy dvou jiných autoritativních DNS serverů, ale neobsahuje odpověď na náš původní dotaz.

Jedná se o tzv. „glueless“ delegaci, tj. delegaci, která obsahuje pouze jména autoritativních DNS serverů (a.iana-servers.net. and b.iana-servers.net.), ale neobsahuje jejich IP adresy. DNS resolver samozřejmě nemůže poslat dotaz na „jméno“, takže musí nejprve získat IPv4 nebo IPv6 adresu autoritativního serveru „a.iana-servers.net.“ nebo „b.iana-servers.net.“ a až poté může pokračovat v řešení původního dotazu „example.com. A“.

Tato glueless delegace je základním stavebním kamenem zranitelnosti NXNSAttack: Útočník pošle zpět delegaci s falešnými (náhodnými) jmény serverů směřujícími do DNS domény oběti, čímž nutí resolver, aby generoval dotazy na DNS doménu oběti (v marném pokusu o překlad falešných jmen autoritativních serverů).

Dopad

Hlavním poznatkem studie o NXNSAttack je, že útočníci jsou schopni významně „zesílit“ jeden dotaz na DNS resolver + jednu DNS odpověď s falešnými delegacemi (tj. 2 pakety), a výsledným provozem bombardovat autoritativní servery oběti náhodnými dotazy, přičemž účinně využívají standardní DNS resolver jako zesilovač. V praxi poměr zesílení (packet amplification factor, PAF) záleží zejména na strategii řešení dotazů používané konkrétní implementací DNS resolveru, na který cílí útok. Například:

  • Resolver BIND 9.12.3 se snaží získat IPv4 a IPv6 adresy pro všechny autoritativní servery z delegace paralelně, což vede k zesílení 1000x.
  • Knot Resolver 5.1.0 překládá jména jmenných serverů jedno po druhém a navíc vynucuje další limity na počet kroků generovaných jediným dotazem klienta, což snižuje zesílení na hodnotu v řádu desítek. Polovina z maximálního zesílení 48x je ve skutečnosti způsobena kódem který se snaží vylepšit kompatibilitu s nestandardně se chovajícími autoritativní servery. Bez hacků pro obcházení nekompatibilit s RFC8020 a RFC7816 by byl PAF Knot Resolveru pouze 24x. (Což je doklad toho, že snažit se řešit problémy jiných implementací je špatný nápad, ale o tom někdy příště.)

Žádná z těchto strategií není sama o sobě špatná; pouze představují různé kompromisy mezi prostředky investovanými do jednotlivého dotazu od klienta vs. paralelního zpracování více klientských dotazů najednou.

Tím, co nakonec rozhodne, která strana bude „obětí“ NXNSAttack, je volná kapacita resolveru a autoritativních serverů, protože jedna ze stran bude přetížena jako první. Dokud bude kapacita dostatečná, budou servery fungovat normálně dál, což může vést k tomu, že jedna ze stran bude prakticky neovlivněna a bez správného monitoringu si útoku ani nemusí všimnout.

NXNSAttack bohužel zneužívá nejzákladnější princip DNS protokolu, což v praxi znamená, že neexistuje žádné skutečné řešení a jsme odkázáni pouze na zmírňování jeho následků.

Vědci naštěstí dodrželi pravidla responsible disclosure (zodpovědného hlášení chyb) a umožnili výrobcům implementovat a vydat verze software se „zmírňujícími opatřeními“ ještě před zveřejněním útoku.

NXNSAttack je zvláštní případ dobře známého útoku dotazováním na náhodné subdomény, takže možnosti obrany spadají do dvou kategorií: Specifické pro NXNSAttack a obecné pro útoky dotazováním na náhodné subdomény.

Zmírnění následků NXNSAttack

Na rozdíl od klasických útoků pomocí dotazů na náhodné subdomény (random subdomain attack) jsou v případě NXNSAttack dotazy generovány samotným resolverem. Tento rozdíl umožňuje výrobcům implementovat jednoduchá zmírňovací opatření, jako je omezení počtu překládaných jmen při zpracování jedné delegace, jednoho dotazu atd.

Zřejmou výhodou této techniky je její jednoduchost, alespoň teoretická.

Nevýhodou technik založených na počítadlech je, že nutí výrobce zavést svévolně stanovené limity, které nejsou založeny na specifikaci protokolu DNS, a v zásadě tím vybrat maximální možné zesílení pro jejich konkrétní implementaci.

Tyto limity ale mohou způsobit potíže u některých domén, a bohužel ne jen teoreticky. Nedávno zveřejněný výzkum odhalil, že 4 % domén druhé úrovně (např. example.com.) má problém v delegování z první úrovně (např. com.), takže jakákoli změna, která přidává limity pro počty pokusů během procesu překládání je riziková a musí být velmi pečlivě zvážena.

V nadcházejících dnech uvidíme, jak byli výrobci úspěšní při určování svých „magických konstant“ a jestli se jim podařilo nerozbít DNS některé z velkých domén.

Univerzální obrana proti útokům náhodnými dotazy

Jakýkoli útok pomocí náhodných dotazů, NXNSAttack nevyjímaje, používá náhodná jména k obejití DNS cache. Z toho vyplývá, že univerzální obrana musí zabránit útočníkům v obcházení cache – a naštěstí již máme technologii, která to dokáže.

Tzv. agresivní použití cache validované pomocí DNSSEC (RFC 8198) využívá „metadata“ DNSSEC ve formě záznamů NSEC(3) a RRSIG ke generování negativních odpovědí bez nutnosti kontaktovat autoritativní servery. Jak to funguje?

Nejprve se podívejme na příklad NSEC záznamů:

$ kdig +dnssec @l.root-servers.net example. ;; ->>HEADER<<- opcode: QUERY; status: NXDOMAIN; id: 55933 ;; Flags: qr aa rd; QUERY: 1; ANSWER: 0; AUTHORITY: 6; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: do; UDP size: 4096 B; ext-rcode: NOERROR ;; QUESTION SECTION: ;; example. IN A ;; AUTHORITY SECTION: events. 86400 IN NSEC exchange. NS DS RRSIG NSEC events. 86400 IN RRSIG NSEC 8 1 86400 20200531170000 20200518160000 48903 . bWcSkQHURJGO... . 86400 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY . 86400 IN RRSIG NSEC 8 0 86400 20200531170000 20200518160000 48903 . Ru23msHh23... . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020051801 1800 900 604800 86400 . 86400 IN RRSIG SOA 8 0 86400 20200531170000 20200518160000 48903 . pIolh2KxjZbgtwuePLA4...

Poslali jsme ukázkový DNS dotaz example. A na jeden z kořenových DNS serverů, který nám odpověděl odpovědí NXDOMAIN. Tím nám říká, že požadované jméno neexistuje. Zároveň jsme obdrželi dva důkazy o neexistenci ve formě záznamů NSEC (a jejich DNSSEC podpisy v záznamech RRSIG).

První záznam events. 86400 IN NSEC exchange. NS DS RRSIG NSEC znamená, že kořenová zóna obsahuje doménu events. s typy záznamů NS DS RRSIG NSEC, a co je důležitější, že mezi jmény events. a exchange. nejsou žádné jiné domény.

Druhý záznam . 86400 IN NSEC aaa. NS SOA RRSIG NSEC DNSKEY znamená, že kořenová zóna obsahuje kořen DNS stromu . (překvapení!) s typy záznamů NS SOA RRSIG NSEC DNSKEY, a také že mezi jmény . a aaa. nejsou žádné jiné domény. Tento druhý záznam dokazuje, že neexistuje žádný wildcard záznam *., a proto je NXDOMAIN skutečně správnou odpovědí na dotaz example. A.

Každý ze záznamů v našem příkladu má time-to-live (TTL) specifikované jako 86400 sekund. To umožňuje resolverům syntetizovat odpovědi NXDOMAIN pro všechny dotazy spadající do uvedených rozsahů (. – aaa., events. – exchange.) po celý jeden den, čímž se účinně omezí komunikace s autoritativními servery.

Jedním z důsledků agresivního použití „DNSSEC důkazů“ je, že náhodné dotazy směřované do DNS zóny, která obsahuje N jmen, zaplní cache resolveru důkazy neexistence za zhruba O(N) odpovědí a pak už není potřeba komunikovat s autoritativním serverem. Jinými slovy, náklady na zastavení útoku náhodnými dotazy mezi DNSSEC validujícím resolverem a autoritativními servery na dobu jednoho TTL rostou lineárně s počtem jmen v cílové DNS zóně, bez ohledu na to, kolik paketů pošle útočník. Funguje to překvapivě dobře i pro velké zóny s 1 milionem domén – výmluvné grafy k této technice najdete v mé starší prezentaci (z roku 2018).

Co dál?

Ze všeho nejdříve si aktualizujte své DNS resolvery, abyste NXNSAttack alespoň trochu zmírnili.

Až se situace uklidní, zauvažujte prosím o zabezpečení svých zón pomocí DNSSEC na autoritativních serverech, a také o zapnutí DNSSEC validace na svých na DNS resolverech.

Agresivní použití cache validované pomocí DNSSEC zeslabuje účinek útoků náhodnými dotazy. My v Knot Resolveru už je máme plnou podporu. Částečnou podporu má i Unbound (pouze pro NSEC) a prototyp najdete i v BINDu. Pokud to váš výrobce DNS resolveru ještě nemá naimplementováno, dejte mu vědět, že máte zájem a pomozte zastavit útoky náhodnými dotazy jednou provždy!

Pokud nejste zvyklí komunikovat se svým výrobcem DNS softwaru, prosím vyplňte tento dotazník a my už se postaráme, aby se dozvěděl souhrnné výsledky.

Autorem ikon je Bernar Novalyi z Noun Project.

 

Kategorie:

DNSSEC kořenové zóny v době koronavirové

Pá, 04/24/2020 - 08:55

Tento příspěvek píšu trochu smutně se dívaje přes Internet na ceremonii podepisování klíče v americkém městečku El Segundo poblíže Los Angeles. A proč jsem smutný? Začnu od začátku.

Technologie DNSSEC přinesla do starobylého protokolu DNS zcela nové věci. Hlavní motivací bylo pochopitelně zvýšení bezpečnosti, ale taková akce s sebou vždy přináší nutnost dodržovat nějaké nové rituály. Asi jako, že přidáním zámku do vnějších dveří zvýšíte bezpečnost vašeho domu. Ale musíte se naučit pamatovat na to, že máte mít u sebe klíče, pokud znovu vycházíte. Podobně DNSSEC zavedením kryptografických klíčů vyžaduje, aby se o ně správci starali. V případě DNSSECu jsou dokonce hned dva druhy podpisových klíčů. První druh je jakýsi hlavní klíč podepisující další klíče neboli Key Signing Key (KSK). A tím druhým jsou klíče přímo podepisující zónu neboli Zone Signing Key (ZSK). Myšlenka stojící za tímto rozdělením je poměrně jednoduchá, KSK se příliš často nemění a obvykle bývá kryptograficky co nejsilnější, zatímco ZSK mohou být trochu slabší, ale zase mají výrazně kratší časovou planost.

Ne jinak tomu je u kořenové zóny DNS. Zde je situace o to pestřejší, že správa této domény je rozdělena mezi více subjektů. Co má být v zóně, určuje IANA, což je součást organizace ICANN. Samotnou zónu ovšem publikuje společnost Verisign a ta ji distribuuje jednotlivým správcům kořenových serverů. V případě DNSSECu je situace taková, že IANA spravuje KSK a Verisign si každý čtvrtrok chodí nechat podepsat nový ZSK. Tato čtvrtletní akce není jen tak jednoduchým předáváním kryptografického materiálu, ale je o poměrně komplikovanou ceremonii.

Totiž tajná část KSK je uložena ve dvou kryptovacích zařízeních (Hardware Security Module – HSM) ve dvou velmi kvalitně zabezpečených telehousech v USA. Kvůli geografické bezpečnosti je jedno z těch HSM umístěno na východním pobřeží, ve městě Culpeper ve Virginii, a druhé je právě v El Segundo v Kalifornii. Od každého HSM existuje sedm elektronických klíčů, přičemž HSM je ochotno provést podpis pouze v případě, že se sejdou alespoň tři z nich. Každý z těchto klíčů má jednoho majitele, kteří pocházejí z různých koutů světa. Říká se jim Cryptographic Officers (CO) nebo chcete-li držitelé klíče. Jsou to vysoce respektovaní lidé z komunity, která se pohybuje kolem DNS, jejich seznam naleznete zde. Těchto lidí je celkem čtrnáct, sedm pro každé pobřeží. Jak už jsem napsal, ceremonie se konají čtyřikrát ročně, pokaždé na jiném pobřeží, a každý CO má povinnost se dvakrát ročně ceremonie zúčastnit.

Když se tento podpisový mechanismus navrhoval, bylo pamatováno pochopitelně i na množnost, že nějaká globální událost znemožní CO na danou ceremonii přijet. Proto CO přímo klíče nevlastní, ale jsou uschovány ve velmi bezpečném a dvacet čtyři hodin monitorovaném sejfu. Samotné HSM je uloženo v jiném sejfu, přičemž každý z těchto sejfů pochopitelně může otevřít jiná osoba. Na začátku ceremonie jsou vždy oba sejfy odemčeny a CO otevřou svou vnitřní přihrádku, která obsahuje čipovou kartu pro odemknutí HSM. Každá čipová karta je ještě uložena ve speciálním unikátním ochranném obalu, podle kterého si CO může ověřit, že s její či jeho kartou nikdo nemanipuloval. Pokud by CO nemohli přicestovat, IANA by prostě sejf otevřela, schránky vyvrtala a mohla by provést ceremonii i bez CO. Trochu si tuto akci mohla nacvičit při předposlední ceremonii číslo 40 v El Segundo, kdy selhal elektronický zámek jednoho sejfu a bylo nutné jej odvrtat, což ovšem není jednoduché. Byla to tehdy operace na téměř dva dny.

Jistě vás napadne, co se tedy dělo právě teď, v době koronavirové krize, kdy není možné cestovat. IANA provedla dvě opatření. Ačkoliv ceremonie číslo 41 měla být na východním pobřeží, byla uspořádána k Kalifornii, protože tam ICANN/IANA sídlí a jejich zaměstnanci tam mohli přijet automobily a nemuseli létat. A protože se IANA chtěla vyhnout dalšímu vrtání, rozhodla se, že požádá čtyři CO, aby jim poslali své klíče ke schránkám v sejfu poštou. Tak mohla proběhnout ceremonie bez CO. Vše je pochopitelně opět velice detailně zachyceno na kamerách a kdokoliv si můžete celou ceremonii zkontrolovat.

No a proč ten můj mírný smutek? Dostalo se mi velké cti, že jsem byl vybrán, abych byl jedním z oněch CO. Právě v průběhu ceremonie 41 mi měl být ve Virginii předán klíč, což jsem pochopitelně vnímal jako obrovské ocenění jak mé práce, tak i celého našeho sdružení. Jak to bude do budoucna, je pochopitelně ještě nejasné. Je možné, že systém ceremonií podepisování kořenové zóny projde velkou revizí, aby byla odstraněna nutnost cestování. Uvidíme, tento virus už konec konců změnil nejednu ceremonii.

Kategorie:

DNS stack už také v CESNETu

Po, 04/20/2020 - 09:22

Jak jsme již několikrát avizovali, po masivních upgradech DNS anycastu pro .CZ doménu v posledních letech a vybudování 100GE DNS infrastruktury se nyní zaměřujeme spíše na cílené ladění provozu anycastu. Snažíme se tak například spouštět nové DNS stacky v místech zdrojů významného DNS provozu, a to jak v zahraničí, tak v České republice. Spuštění DNS stacku v síti CESNETu na začátku dubna budiž této naší činnosti důkazem.

V síti české akademické e-infrastruktury CESNET jsme zprovoznili tzv. ISP DNS Stack, o kterém jsme už na našem blogu psali. Kolegové ze sdružení CESNET se k nasazení ISP DNS Stacku ve své síti rozhodli zejména proto, aby zajistili větší bezpečnost v případě útoků na DNS infrastrukturu a z důvodů zajištění vyšší kvality služeb pro své uživatele.

ISP DNS stack je označení pro instanci autoritativního DNS serveru obsahující .CZ zónu v interní síti cizího subjektu, typicky poskytovatele připojení (proto tedy „ISP“). Tuto službu poskytujeme primárně velkým ISP (před CESNETem jsme již spustili Vodafone a Seznam.cz), kteří poskytují internetové služby většímu množství zákazníků a jsou tedy z našeho pohledu významným uživatelem DNS provozu. ISP DNS stack propaguje anycast prefix právě jednoho z CZ.NIC DNS anycastů do sítě takového poskytovatele připojení, avšak ten nemá povolen tento prefix propagovat dále do svých upstreamů nebo svým peerům. Je tedy určen výhradně pro síť poskytovatele připojení.

Hlavní výhodou provozu takové DNS instance z pohledu ISP je plná dostupnost služby DNS v případě útoku proti našim veřejným autoritativním DNS serverům. Zákazník v síti ISP tak není útokem ovlivněn a služba DNS je pro něj plně dostupná. Vzhledem k principu anycastu snižuje sekundárně umístění ISP DNS stacku v síti ISP latenci a pomáhá zrychlení odezev DNS dotazů zákazníkům v síti ISP.

Naopak výhodou pro nás je, že pokud by došlo k útoku na ISP DNS Stack z interní sítě ISP, bude ukončen pouze na této DNS instanci. Útok se tak dále nešíří, tedy nedochází k ovlivnění veřejných autoritativních DNS serverů. Současně může ISP na tuto událost reagovat, útok řešit a nezávadný DNS provoz přesměrovat na naše veřejné autoritativní DNS servery.

Pro většinu ISP, a je to tak i v případě CESNETu, postačuje pro vybudování ISP DNS Stacku jeden nezávislý DNS server, viz obrázek níže, který je schopen obsloužit řádově jednotky milionů DNS požadavků za sekundu. Jedná se o takzvanou základní variantu ISP DNS stacku.

V případě vyššího objemu DNS požadavků umíme řešení rozšířit, konkrétně například na řešení z pěti serverů na takzvanou Rozšířenou varianta ISP DNS stacku s oddělenými službami (3x DNS server, 1x management a monitoring server, 1x router), který dokáže obsloužit trojnásobek DNS provozu.

Konkrétně ISP DNS stack CESNETu je umístěn v datovém centru ČRa Tower na pražském Žižkově a provozován na serveru Dell PowerEdge R640. Ten je osazen dvěma Intel Xeon Silver 4110 procesory, každé nabízí 8 jader s technologií Hyper-threading a taktovací frekvenci 2,10 GHz. Dále disponuje 32GB RAM, HW diskovým řadičem, 3x 300GB SAS 15k disky (jeden z nich je použit jako hot-spare), dvouportovou 1GE síťovou kartou Intel i350 a dvouportovou 10GE síťovou kartou Intel X710 SFP+. Jsme rádi, že se i zde podařilo dodržet diverzitu dodavatele a modelu serveru, neboť u starších ISP DNS stacků je použit buď server HPE ProLiant nebo Dell PowerEdge jiné/starší řady.

Server má OOB interface (rozhraní pro správu serveru) a MGMT interface (iDrac remote-management) připojen pomocí 1GE linek do Internetu. Rozhraní iDrac je jako jediné filtrováno na firewallu CESNETu výhradně na vybrané IP prefixy CZ.NIC a současně je dostupné pouze po IPv6. Ostatní síťová rozhraní filtrujeme již sami pomocí linuxového firewallu iptables. Server je připojen přímo do páteřní infrastruktury CESNETu na router, kde je navázáno BGP spojení. Komunikace s DNS serverem probíhá pouze a jedině ze sítě CESNET, kde je zároveň aplikována ochrana proti DDoS útokům.

Server je výhradně v naší správě a jelikož je umístěn v racku, kam naši administrátoři nemají fyzický přístup, veškeré záležitosti spojené s provozem hardware (monitoring, servis apod.) zajišťují kolegové z CESNETu. My se staráme o veškerou softwarovou implementaci. Samozřejmostí je šifrovaný filesystém pomocí technologie LUKS. Na serveru běží Debian Linux 10, jako routovací/BGP démon je použit Bird a jako DNS démon KNOT DNS. Server získává aktualizace .CZ zóny standardním způsobem, tedy pomocí AXFR z našich hidden-master DNS serverů. Do sítě CESNET se oznamuje DNS anycast C (194.0.14.1/24 + 2001:678:11::1/48). Tento anycast byl pro všechny ISP DNS stacky vybrán záměrně, protože není oznamován z žádného veřejného DNS stacku v České republice a je dostupný výhradně z vybraných zahraničních lokalit.

Jsme moc rádi, že nám ISP DNS Stacky přibývají, děkujeme CESNETu za možnost v této oblasti spolupracovat! Pro další zájemce jsme zpracovali podrobnější dokument, který popisuje, jak technické detaily, tak náklady na provoz. Jen podotýkám, že sleva pro sítě zapojené ve FENIXu je i nadále platná! Rádi se ale určitě budeme věnovat nejen FENIXářům! :)

Kategorie:

Aktuální statistiky o celosvětovém vývoji COVID-19 na jednom místě

St, 04/08/2020 - 15:10

Na Internetu se v souvislosti s koronavirem vynořilo mimo jiné i mnoho webových stránek, které se snaží zpracovávat data do různých statistických výstupů. Jen v českém registru se jich objevilo hned několik. Jestliže patříte mezi ty, kteří rádi sledují aktuální „koronavirová“ čísla nebo z nich čerpáte informace při své práci, můžete narazit na několik překážek. Některé statistiky totiž sice přináší údaje, které zrovna potřebujete, ale jsou staré a pravidelně se neobnovují. V případě dynamických vizualizací jste zase při práci svázáni pevně danými mantinely. Pokud vám to nevyhovuje, můžete vyzkoušet nově vytvořený nástroj na generování dynamických vizualizací z dílny sdružení CZ.NIC, který má široké možnosti a lze jej různě nastavovat. Můžete si tak navolit například libovolné světové území, vzorec pro danou křivku, můžete kopírovat URL a samozřejmě pro update stačí zmáčknout F5. Vše důležité najdete na https://covid-19.nic.cz/.

Jak to funguje?

Prioritou pro nás bylo umožnit zobrazit všechna dostupná území. Chtěli jsme tak dosáhnout toho, aby si ladné křivky mohly zobrazit všechny země, které mají statistiky veřejně dostupné, ale nejsou třeba dostatečně atraktivní pro běžně prezentované vizualizace na Internetu.

A teď už k funkcionalitě. Z důvodu velké složitosti je většina ovládacích prvků zpočátku skryta. Vpravo naleznete menu, kde lze zapnout jednotlivé panely.

1. Axes

V panelu Axes si vyberete varianty použitých os. Osa Y je buď lineární, logaritmická nebo procentuální. Logaritmickou použijete, když chcete srovnat malé a velké území – například Českou republiku s Evropou. Takže i přesto, že je naše země mnohem menší, tvar obou křivek je patrný.

Procentuální zobrazení doporučujeme v případě, že chcete zobrazit informace, které porovnávají více faktorů najednou. Například kontinenty utvoří sloupce, rozdělené podle počtu potvrzených a skončených případů. Nebo naopak (počty potvrzených a skončeným utvoří skloupce, rozdělené podle kontinentů).

Na ose X lze pak volit buď čas, nebo počet potvrzených případů. Můžete si zobrazit křivku nově potvrzených případů vůči jejich celkovému množství. Přehledně tak můžete vizualizovat, zda se země veze na vlně exponenciálního růstu (což z časové osy není vizuálně snadné odvodit), či zda se jí daří změnit průběh epidemie.

Přepínačem si můžete navolit, zda monitorujete vývoj trendu pro rozsah dní, či zda zobrazíte situaci v jeden konkrétní den. Posuvník pak graf překreslí pro daný časový rozsah.

2. Computation

Záložka Computation umožňuje ovlivnit výpočet dvěma způsoby. Přepínač „Average“ zapne průměrování dat za poslední týden, přesněji je použitý klouzavý průměr sedm dní zpětně. I v zemích, které reportují poctivě, se vyskytnou výpadky a chyby. Kupříkladu Itálie nahlásila 11. března přírůstek 3 000 potvrzených případů, o dva dny později 6 000, ale 12. března není ve statistikách uvedeno nic.

Druhý přepínač „Outbreak“, česky bychom řekli prudké šíření, posune všechny datasety tak, že začínají v den, kdy v daném teritoriu bylo hlášeno jisté množství případů. Jaké? To si určíte buď konstantou absolutní, nebo vztaženou k populaci. Například lze ukázat vývoj v evropských státech v momentě, kdy dosáhly sta nakažených nebo kdy na jejich území byl hlášen počet případů odpovídající promile populace, což bylo v případě Itálie 8. března. V březnu to ale z evropských států stihlo, jak je vidět z grafu, ještě dalších deset od Islandu po Monako.

3. Equation

Neméně zajímavé menu je Equation, jež umožňuje nastavit elegantní rovnici, kterou graf konkrétně vykreslí. Do rovnice zadáte libovolné aritmetické parametry a některé ze 17 připravených proměnných.

Základní rovnice zní prostě: C (confirmed cases) neboli počet potvrzených případů. Analogicky k ní je RD, to jest případy, které skončily uzdravením či smrtí. Z nich předpona N (new) udělá rovnice v daný den nově se vyskytující případy a předpona dN jejich derivaci.

Tedy kupříkladu pokud se včera nově uzdravilo pět lidí a dnes sedm, nabude proměnná dNR hodnoty +2, neboť počet nově uzdravených se o dva zvýšil. Proměnná P obsahuje populaci (pokud ji pro dané území máme) a T počet testovaných (dostupné jen pro ČR).

Nyní si uveďme několik příkladů s vysvětlením, abychom věděli, co jsme si vlastně zobrazili.

Rovnici je možno agregovat, to jest sečíst data ze všech použitých území do jediné datové sady. Lze tak snadno porovnávat severní a jižní Evropu nebo jak si vede ČR oproti jejím sousedům a vykreslit přitom jen dvě čáry. Případně sloupce, které je možné skládat na sebe, ať už podle rovnice (potvrzené případy na potvrzené) nebo podle území (Evropa na Evropu).

Můžeme se pustit do vytváření vícera rovnic naráz. Užitečným příkladem je porovnání tří různých kontinentů podle počtu případů daného typu. Každá rovnice pak může být na vlastním grafu. Místo, aby se tísnilo devět čar na jednom grafu, můžeme mít tři grafy o třech čarách. Nebo mohou být jednotlivá data na nezávislé ose Y, jak je možné vidět na grafu vývoje ČR a Evropy. Všimněte si, že každá spojnice má vlastní osu Y, takže můžeme vidět přehledně data z ČR i z Evropy, přestože zobrazení není lineární.

4. Display menu

Menu Display přináší další užitečné volby. Můžete popsat křivky hodnotami či názvy jejich rovnic. Změnit, pokud nejste spokojeni s implicitním nastavením, při kterém jsou v grafech bez spojnicových grafů popsány názvy sloupců. Dále si můžete určit barevná schémata a barvit křivky podle rovnice či podle teritoria. Nebo si můžete určit, jak mají být seřazeny položky, zobrazené při najetí myši. Vyberte si.

Jak zobrazím data pro jinou zemi?

To byla v návrhu aplikace poměrně složitá věc. Nakonec jsou území členěna do tří celků – kontinenty, země a státy nebo řekněme provincie. Každou rovnici lze spojit s množinou území nebo jejich agregací. Pokud má území závislá teritoria, najdeme vedle něj ikonku oka a fajfky. Oko zobrazí a skryje všechna závislá území, která nejsou spojena s aktivně editovanou rovnicí. Fajfka pak asociuje k rovnici všechna závislá území. Implicitně jsou zobrazeny kontinenty a všechna území spojená s aktivní rovnicí.

Tento mechanismus napomáhá orientaci ve stovkách možností, zvlášť, když dochází k následujícím případům:

  • Čínská lidová republika – skládá se z jednotlivých závislých území jako je například Chu-pej. Můžeme si zobrazit tedy celé území Čínské lidové republiky nebo jen Chu-pej.
  • Francouzská republika – je také složena z několika území. Lze tedy zobrazit Francii jako zemi a jako region (kam je zahrnuta země i její provincie) nebo třeba Reunion jako provincii, případně jednotlivé provincie.
  • Teritorium patří pod více nadřazených území.
A co možnosti sdílení?

Aplikace je navržena tak, aby se veškerá vaše činnost okamžitě promítla do URL. Jakmile jste spokojeni, stačí si nastavit záložku nebo zkopírovat URL a až přijdete příště, najdete editor, jak jste jej opustili. Pokud chcete s daty dále pracovat po svém, v každém okamžiku je lze vykopírovat z dynamické tabulky. Nebo stáhnout jako CSV, JSON či obrázek.

Teď už nezbývá než si novinku vyzkoušet a dostat se tak k datům, na která už netrpělivě čekáte. Stále však platí, že až budete mít na světě svoji vysněnou vizualizaci, to, co popisuje, není skutečný svět, ale jenom jeho digitální odraz. Jsou to data získaná z dostupných zdrojů. Mohou tak být zpožděná, neúplná a v některých případech i manipulovaná. Je důležité si uvědomit jednotlivé souvislosti. Například, jestliže je dnes nově uvedeno 1 000 otestovaných jedinců a 500 potvrzených, neznamená to, že se dnes nakazilo 500 lidí. Protože testy byly prováděny před několika dny a testovaní se nakazili ještě dříve. Naopak těm, co se nakazí dnes, se příznaky projeví až za pět dní, budou testováni za týden a v kolonce otestovaní se tak objeví v lepším případě za deset dní. V tom horším i za dvacet, nebo také nikdy. Také se může stát, že budou ve statistikách dvakrát, pokud se testuje dvakrát stejný pacient. Je nutné si uvědomit i fakt, že se metodika měření v různých zemích liší. Tudíž například někde nemusí být mezi nakažené započítaní ti jedinci, kteří jsou sice pozitivně testovaní, ale zrovna nevykazují příznaky. Takže buďte obezřetní a mějte na paměti, že to jsou jen data.

Kategorie:

Vývojáři ACTIVE 24 představili nového EPP klienta pro komunikaci s registrem domén .CZ

Út, 04/07/2020 - 13:00

Jeden z doménových registrátorů, společnost ACTIVE 24, nedávno z vlastní iniciativy vytvořil nového open-source klienta v jazyce Java pro komunikaci s doménovým registračním systémem FRED. Tento klient umožňuje komunikaci se systémem FRED pomocí protokolu EPP a je alternativou ke klientu napsaném ve sdružení CZ.NIC v jazyce Python. Oba slouží k provádění běžných operací registrátorů ve vztahu k registru: vytváření, aktualizace, převod, obnova či mazání domén, kontaktů a dalších objektů v registru. Nový Java klient nabízí vylepšené příkazy přípravy dat, oproti Python klientovi již není nutné po zavolaní příkazu „prep_domain_by_nsset“ a dalších volat příkazy „get_results“ pro získání výsledků. Java klient toto volaní udělá automaticky a vrátí kompletní ucelené výsledky.

Aby kolegové ze společnosti ACTIVE 24 zajistili co nejvyšší kvalitu svého nového klienta, požádali naše testery o aplikaci stávajících automatických testů, které jsou používány k testování systému FRED přes protokol EPP a které využívají knihovnu klienta v Pythonu. Jelikož je registrační systém FRED vytvořený jako open-source a my velmi rádi podporujeme každé open-source rozšíření našeho softwaru, rádi jsme této žádosti vyhověli a pustili se do práce. Stávající automatické testy vytvořené pro Python klienta bylo potřeba přizpůsobit vytvořením vlastní vrstvy s použitím knihovny tohoto klienta upravené tak, aby posílala data do nového Java klienta. Testování nového klienta jsme samozřejmě prováděli na operačním systému Linux a testy jsme my i autor spouštěli vůči veřejné testovací instanci systému FRED.

Již v průběhu „ohýbání“ stávajících automatických testů z dílny sdružení CZ.NIC na nového Java klienta jsme získali poznatky o drobných nedokonalostech našeho testovacího frameworku, které mohou ve výjimečných situacích způsobit nesprávný výsledek testů, na který však test neupozorní. Vývojář Java klienta ze společnosti ACTIVE 24, Radek Novotný, také odhalil několik nedostatků v dokumentaci systému FRED, které jsme díky němu mohli opravit. Dále pomohl identifikovat chování v XML schématech pro protokol EPP, které přesně neodpovídá standardům dle RFC. Naopak naše testování Java klienta odkrylo několik jeho slabin, ale protože byl Radek v opravách neuvěřitelně aktivní, jsou již všechny minulostí. Například bylo nutné umožnit v nastavení Java klienta vypnutí validace vrácených dat z registru. Registr .CZ domén může obsahovat velmi stará a stále platná data, která by se vyhodnotila jako nevalidní.

Spolupráce mezi sdružením CZ.NIC a registrátorem ACTIVE 24 byla a i nadále může být oboustranně prospěšná – náš testerský tým získá lepší pohled na procesy registrátora a druhá strana zase rychlou technickou pomoc od .CZ registru při nasazování Java klienta do ostrého provozu.

Klient je volně ke stažení na githubu autora, kde je k dispozici i stručná nápověda. Stejně tak je k dispozici i na stránkách projektu FRED, konkrétně v sekci Get FRED. Podrobnější informace o protokolu EPP implementovaném pro komunikaci s registračním systémem FRED poskytne jeho dokumentace.

Pro ilustraci uvádím ukázku implementace příkazu check_domain a create_domain:

import fred.client.FredClient;
import fred.client.FredClientImpl;
import fred.client.data.check.CheckRequest;
import fred.client.data.check.CheckResponse;
import fred.client.data.create.domain.DomainCreateRequest;
import fred.client.data.create.domain.DomainCreateResponse;
import fred.client.exception.FredClientException;

public class FredClientTest {

public static void main(String[] args) throws FredClientException {
FredClient client = new FredClientImpl(„conf/fred-client.properties“);

# Check domain
CheckRequest domainCheckRequest = new DomainCheckRequest(„nic.cz“, „active24.cz“);
CheckResponse domainCheckResponse = client.callCheck(domainCheckRequest);
System.out.println(domainCheckResponse);
# Create domain
DomainCreateRequest domainCreateRequest = new DomainCreateRequest(„testdomainname.cz“, „A24-CONTACT“);
DomainCreateResponse domainCreateResponse = (DomainCreateResponse) client.callCreate(domainCreateRequest);
System.out.println(domainCreateResponse);

Kategorie:

DNS crawler: tři, dva, jedna, start!

Po, 04/06/2020 - 09:40

V rámci projektu ADAM (Advanced DNS Analytics and Measurements) uvádíme do produkčního provozu nástroj DNS crawler. Naším záměrem je periodicky procházet všechny domény 2. úrovně pod TLD .cz, získávat o nich různá veřejně dostupná data a ta pak dále zpracovávat.

I když to jeho jméno přímo nenapovídá, DNS crawler bude kromě sběru dat z DNS také komunikovat s webovým a e-mailovým serverem každé domény. Počítáme s pravidelnými běhy ve dvou periodách: většina datových položek se bude sbírat každý týden, pouze obsah hlavních webových stránek <doména>.cz nebo www.<doména>.cz se bude stahovat jen jednou měsíčně. Zvláštnímu dohledu budou navíc podrobeny nově zaregistrované domény, u nichž je větší pravděpodobnost výskytu nějakého problému – jejich data se budou po dobu prvních dvou týdnů jejich existence stahovat denně. Software i režim jeho použití jsou navrženy tak, aby dopady na provoz domén druhé úrovně a síťovou infrastrukturu obecně byly prakticky zanedbatelné.

Získaná data budou využita ke třem hlavním účelům:

  • pro různé statistiky a analýzy, které budou  pravidelně i jednorázově zveřejňovány a poslouží mimo jiné k efektivnější správě a plánování dalšího rozvoje služby DNS, kterou sdružení provozuje
  • pro včasné odhalování problémů a anomálií v DNS, které mohou být způsobeny jak poruchami zařízení nebo chybami v konfiguraci a zónových datech, tak i zlovolnými aktivitami
  • pro klasifikaci webových stránek metodami strojového učení, především s cílem zvýšení bezpečnosti zóny .cz (např. odhalováním falešných e-shopů nebo domén využívaných malwarem).

Jsme si dobře vědomi toho, že podobné skenování síťových zdrojů ve velkém je dvojsečná záležitost – profylaktické skenování (náš případ) se na první pohled téměř neliší od vyhledávání vhodných obětí pro síťové útoky. Proto se snažíme o maximální otevřenost:

  • Software DNS crawleru, který ke skenování zóny .cz používáme, je open source – každý si ho proto může vyzkoušet, případně prohlédnout jeho zdrojový kód (v jazyku Python).
  • Zveřejňujeme kompletní soupis všech dat, která sbíráme, i interní pravidla pro jejich použití.
  • Zveřejňujeme i identitu (IP adresy) serverů, které skenování provádějí.
  • Jediná věc, kterou nedáváme každému k dispozici, je aktuální seznam domén v zóně .cz.

Podrobné informace týkající se provozu DNS crawleru včetně kontaktních adres jsou k dispozici na webové stránce https://adam.nic.cz/dns-crawler-operation.

Chtěli bychom touto cestou požádat o spolupráci operátory sítí, ISP a poskytovatele služeb, kterých se bude tak či onak tato naše aktivita dotýkat. Zjistíte-li jakékoli problémy spojené s provozem DNS crawleru, dejte nám o nich prosím vědět, například e-mailem na adresu dns-crawler@nic.cz. Děkujeme!

Kategorie:

„Kritické“ opkg CVE a Turris

Po, 03/30/2020 - 13:10

Možná jste již někde slyšeli o „kritické“ zranitelnosti v systému OpenWrt. Můžete si tak právem dělat starosti s tím, jestli se to týká i Turrisu. A to je důvod, proč je slovo „kritické“ v uvozovkách. Ve zkratce: Turrisu žádné nebezpečí nehrozí.

Kontext

Jak to celé funguje? Kdykoli chcete nainstalovat balíček v systému OpenWrt, musíte mít nejdřív aktuální kopii seznamu dostupných balíčků. Tento seznam obsahuje název, velikost a kontrolní součet všech souborů v úložišti. Balíček, který si chcete nainstalovat, lokálně vyhledáte, pak se balíček během instalace stáhne, je ověřena jeho velikost a kontrolní součet, a pokud vše sedí, instalace proběhne.

Ale kde jsou tu kontroly zabezpečení? Seznam balíčků je podepsán a ověřen pokaždé, když ho stahujete. Jelikož tento seznam obsahuje i kontrolní součty a velikost všech balíčků, jste schopni s jeho pomocí ověřit balíčky, které stahujete. Dokonce i při stahování přes obyčejné http. Právě to totiž na některých zařízeních systém OpenWrt provádí, jelikož https vyžaduje zahrnutí knihovny SSL, která může v zařízení s omezenou pamětí zabírat příliš drahocenného místa.

V čem je tedy problém? Zmíněné CVE ovlivňuje ověření kontrolního součtu, takže když router stahuje balíček přes http a dojde k útoku typu „man in the middle“, může tento bug vést k tomu, že nedojde k ověření kontrolního součtu. Díky tomu bude útočník moci oklamat oběť a donutit ji nainstalovat jiný balíček se zadními vrátky (pokud je schopný vytvořit škodlivý balíček se stejným názvem a stejnou velikostí jako ten, který chcete nainstalovat).

Turris

Proč to neovlivňuje routery Turris? Zaprvé, většina správy balíčků na našich routerech používá updater. Ten používá stejný formát souborů a stejný seznam balíčků, ale je implementován úplně od začátku, takže neobsahuje zmíněnou chybu.

Ale i v případě, že se rozhodnete použít na routerech Turris starý dobrý opkg, je tu ještě jedno protiopatření, které už máme dlouhou dobu zavedené: jak seznam balíčků, tak i samotné balíčky stahujeme přes https. Proto nebude jednoduchý „man in the middle“ fungovat – museli byste nejdříve získat platný a podepsaný certifikát pro https://repo.turris.cz.

Takže přestože to představuje docela velké riziko pro osekané verze systému OpenWrt, operačního systému Turris s jeho výchozím nastavením se to tolik netýká.

Kategorie:

Jak zabavit děti v období koronavirových prázdnin? Bezpečně.

Čt, 03/19/2020 - 14:23

Mnozí z nás teď řeší situaci, jak doma zabavit své děti a zároveň je účinně vést ke vzdělávání. Se životy nás všech se již neodmyslitelně pojí digitální technologie a Internet. Využijte volných chvil doma a zaměřte se spolu s dětmi na svou kyberbezpečnost.

Níže vám dáváme náměty, jakým způsobem můžete s dětmi pracovat a o čem si s nimi povídat. Zadejte jim nejprve úkol (najdete v odkazech) a poté ho s nimi rozeberte. Popovídejte si o tom, co je nejvíce zaujalo a čemu případně nerozuměly. Bude vás to nakonec všechny bavit, nebojte se.

Materiály jsme rozdělili dle doporučených věkových kategorií dětí:

1) Děti ve věku 5 – 9 let

Pro předškoláky a děti mladšího školního věku máme k dispozici výukovou audioknihu ON-LINE ZOO. Pusťte dětem nahrávku s příběhy zvířátek, která používají moderní technologie, a nechte je vytvořit si svůj vlastní názor. Poté si knihu poslechněte spolu nebo ji svým ratolestem přečtěte sami. Najdete ji ke stažení v naší Edici CZ.NIC. Popovídejte si o tom, k čemu zvířátka v knize používala Internet, a řekněte si, k čemu jej používají vaše děti. Vysvětlete jim, že to, co se v knize přihodilo zvířecím hrdinům, se může stát i lidem v reálném světe. Ať si raději stále dávají pozor. Především jim zdůrazněte, že jste tu pro ně a že jim kdykoli s čímkoli pomůžete, aby se vám v případě potřeby nebály svěřit.

2) Děti ve věku 10 – 12 let

Vytiskněte dětem křížovku a nechte je v klidu si projít otázky a vyluštit tajenku. V případě, že budou chtít poradit, pomozte jim. Digitální gramotnost se u dětí velice liší. Někdo křížovku vyluští bez sebemenších obtíží, zatímco jinému zabere trochu více času. Potom si s nimi projděte jednotlivé pojmy, které jim z křížovky vzešly: Wi-Fi, kyberšikana, digitální stopa, heslo, Minecraft, antivir, fake-news, závislost. Postupně si o všech tématech popovídejte, ale také naslouchejte, co vám bude dcera či syn říkat. Mnohdy je dobré se nechat od dětí poučit a na oplátku jim zase sdělit svůj vlastní názor.

Co je to digitální stopa, mohou děti zjistit i pomocí online kurzu Digistopa, který je navede, jak si mají chránit své digitální soukromí a jak mají bojovat proti kyberšikaně. Kurzem provází komiksová postava Bára Bezhlavá, která musela nastoupit do nové školy a seznámit se s novými spolužáky. Jestli to mělo hladký průběh už se vy i děti dozvíte právě v tomto vzdělávacím kurzu.

Hrají vaše děti rády online hry? Také u vás doma „frčí“ Brawl Stars, Roblox či Minecraft? Zkuste si některou z her nainstalovat a společně se svými potomky zahrát. Zpočátku zřejmě zjistíte, že nechápete smysl hry, ale nechte své děti, aby vám ji vysvětlily. Budou to dělat ochotně a rády, uvidíte. Také vám jistě prozradí své taktiky a možná vás i vpustí do svého virtuálního týmu. Je to dobrá příležitost, jak s dětmi navázat dobrý vztah a utužit vzájemnou důvěru. Třeba se vám pak budou doma lépe nastavovat některá pravidla. Zároveň je však poučte o tom, co o sobě smí ostatním hráčům sdělovat a co je již jejich soukromá záležitost.

3) Děti ve věku 13 let a výše

Mají vaše děti rády komiksy? Ukažte jim naši knihu Jak na Internet, kde se například dozvědí, jak a kdy vznikl Internet, co je to cloudové úložiště, jak bezpečně nakupovat online a mnoho dalšího. Možná i vy zjistíte, že jsou pro vás některé informace nové, a necháte se spolu s dětmi vtáhnout do světa digitálních technologií. Kniha je nejen poučná, ale i zábavná a vtipná.

V současné době se všichni potýkáme s plížícím se útokem koronaviru. Osvojili jsme si během krátké doby důsledné dodržování hygienických pravidel, která nás mají ochránit před šířící se nákazou. Ale ruku na srdce, hlídáme si stejně pečlivě i svůj chytrý telefon? Zkontrolujte si raději platnost svého antivirového programu a v případě, že ho ještě nemáte, zkuste to co nejdříve napravit. Přeci byste si do domu nechtěli přizvat nevítaného hosta.

Podívejte se například na video s Romanem Zachem, který vás poučí o tom, jaké nástrahy na nás mohou číhat v mobilních aplikacích a jak si na ně dát pozor a svůj mobil ochránit.

Přejeme vám klidný průběh tohoto pro všechny nelehkého období a nezoufejte, zase bude lépe.

Hodně zdraví.

Kategorie: