Hosting

Přihlášení

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

Bez šťávy by to nejelo

Čt, 07/18/2019 - 09:23

V předcházejícím dílu seriálu o budování našeho privátního datového sálu jsem psal o chlazení. Dnes bych se zaměřil na další klíčový prvek datových center a tím je napájení. Je to část, která je (společně s budovou) nejvíce technologicky sdílená s provozovatelem datového centra. Ne, opravdu nebudeme mít pro svůj privátní sál svoje tři VN přívody od distributorů elektrické energie nebo svoje trafostanice. Dokonce ani nebudeme mít svoje dieselové agregáty nebo UPS pro zajištění nepřetržitých dodávek elektrické energie při výpadku dodávek od distributora. Ekonomicky to prostě pro naše potřeby nedává smysl a tyto části sdílíme s provozovatelem datového centra. Ano, stávající UPS jednotky jsou již doplněny o dva 50 kW moduly (jeden pro napájecí větev A, druhý pro „Béčko“) a do nádrží dieselů provozovatel DC dolil „pár“ litrů nafty navíc, aby i při rostoucí zátěži dokázal garantovat 30 hodin kontinuálního provozu bez dodávek externích paliva (v případě výpadku napájení DC), ale to je vše, co bylo třeba udělat ve stávající energetické soustavě provozovatele datového centra. Ne, ani svoji jadernou elektrárnu si opravdu nestavíme :).

UPS jednotka

Baterie

Co máme logicky svoje, jsou dva nezávislé přívody napájení sálu, dva elektrické rozvaděče v sále pro napájení IT, tj. našich technologií v racích, a dva elektrické rozvaděče pro napájení non-IT (klimatizace, zvlhčovače, monitoring, atp.) Čistě pro nás je určeno i devět párů třífázových PDU (power distribution unit) pro zajištění dodávek elektrické energie k našim technologiím v racích. Aby dával koncept dvou nezávislých napájecích větví smysl, v racích budeme používat výhradně dvouzdrojové technologie. Maximální příkon, který každé PDU k racku dokáže dovést je 11kW (tři fáze po 16 A), což je výrazně nad plánovanými potřebami sálu. Každé PDU obsahuje 36 zásuvek typu C13 (pro běžné rackové technologie – zejména servery a switche), šest zásuvek C19 (pro výkonově náročnější rackové technologie – například routery) a tři zásuvky UTE (to jsou ty kulaté, které používáte u běžných spotřebičů v domácnosti). PDU je rozděleno do tří sekcí dle jednotlivých napájecích fází, tzn. že každá sekce obsahuje 12x C13, 2x C19 a 1x UTE. Pokud bychom v budoucnu potřebovali nějaké zásuvky ještě přidat, k PDU je možné sériově připojit další PDU s potřebným počtem a typem zásuvek nebo do racku přivést další dva napájecí kabely.

Důležitou součástí systému napájení je jeho monitoring včetně měření spotřeby. To je na našem sále řešeno měřícími transformátory, které jsou umístěny v sálových rozvaděčích. Přes rozhraní jsou pak informace předávány on-line do dohledových systémů provozovatele DC a uvidíme je spolu s dalšími parametry i na zákaznickém portálu. Máme tak pod neustálou kontrolou stavy napájení každého racku.

Elektrický rozvaděč

Elektrický rozvaděč uvnitř

Přívody napájení k rackům

Detail zásuvek PDU

Privátní sál jsme zatím do běžného používání nepřevzali. S dodavatelem řešíme několik nedokončených nebo nedokonalých věcí. Některé potřebujeme doladit před instalací našich technologií, jiné (méně podstatné) může dodavatel dokončit za běhu. U tak rozsáhlé a komplexní akce není nic neobvyklého, že se instalace některých částí zpozdí. My v každém případě pokračujeme v rozsáhlých přípravách instalace našich technologií. Nové (v provozu nezapojené) síťové prvky již konfigurujeme, pro stávající prvky naší infrastruktury dokončujeme plán přesunu do privátního sálu. Téměř každý prvek infrastruktury tak má v našem privátním sále, byť virtuálně, svoje místo. Ale o tom zase někdy příště.

Kategorie:

Chyba v implementaci DNSSEC v BIG-IP load-balancerech od F5

St, 07/10/2019 - 06:00

Při vývoji DNS resolveru Knot Resolver se Laboratořím CZ.NIC podařilo odhalit bezpečnostní chybu, která umožňuje obejít zabezpečení DNSSEC na load-balancerech výrobce F5 a způsobit tak nedostupnost služby. Tyto výrobky jsou nasazeny například na některých internetových bankovních aplikacích i českých bank a úřadů. Z pohledu uživatele se úspěšný útok pomocí této chyby projeví např. tak, že prohlížeč při práci s internetovým bankovnictvím náhle zahlásí chybu „adresu nelze nalézt“ a služba přestane být dostupná.

Výrobce byl o chybě informován již v srpnu 2018 a nyní vydal doporučenou konfiguraci k obejití problému. Protože operátoři DNS resolverů na chybu již naráží i v běžném provozu, publikujeme podrobný popis chyby, abychom informovali odbornou veřejnost a zvýšili povědomí o tomto problému.

Podstatou chyby, kterou jsme objevili při testování nové verze Knot Resolveru, byl technický detail skrytý v softwaru dodavatelské společnosti F5, který obsahuje chybnou implementaci technologie DNSSEC.

V první části tohoto článku je popsána samotná chyba a její důsledky, v druhé potom způsob jejího zneužití a poučení na závěr.

To hlavní zní: Pokud používáte load-balancer F5, požadujte od výrobce co nejdříve opravu pro chybu označenou jako Bugzilla ID 744937. Než bude oprava dostupná, použijte postup popsaný v článku výrobce.

Kde je chyba?

Celý příběh by se dal zkrátit do věty „příčinou chyby je nedodržení technického standardu RFC5155 sekce 3.1.8„, nejspíš jako důsledek snahy o zjednodušení si práce při implementaci.

Aby čtenáři mohli docenit celý princip chyby a její důsledky, ilustrujeme si chybu na příkladu, kde se uživatel snaží připojit na webový server se jménem „www.example.com.“, na němž je nasazen load-balancer. Jako první krok pro připojení musí webový prohlížeč přeložit doménové jméno „www.example.com.“ na IPv4 nebo IPv6 adresu. Překlad prohlížeč provede tak, že najednou odešle dva dotazy na DNS resolver:

  • www.example.com. AAAA (záznam pro IPv6 adresu; dejme tomu, že tato adresa neexistuje)
  • www.example.com. A (záznam pro IPv4 adresu; tato adresa v našem příkladu existuje)

Pořadí, v jakém budou dotazy obslouženy DNS resolverem, je v podstatě náhodné. V následujícím příkladu popisujeme situaci, kdy resolver zpracovává jako první dotaz na IPv6 adresu (typ DNS záznamu AAAA). Levý sloupec popisuje chování korektní implementace, pravý sloupec ukazuje chybu ještě nedávno přítomnou v load-balancerech F5:

Správná implementace Chyba v implementaci F5 1. Webový prohlížeč odešle DNS resolver dotaz na www.example.com. AAAA (typ záznamu AAAA je IPv6 adresa). – stejné – 2. DNS resolver v cache nemá odpověď, protože uživatel danou stránku otevírá poprvé, takže se DNS resolver zeptá autoritativního serveru skrytého za load-balancerem. – stejné – 3. Protože v našem hypotetickém příkladu existuje pouze IPv4 adresa (typ A) a neexistuje IPv6 adresa (typ AAAA), load-balancer musí zpět poslat „DNSSEC důkaz neexistence“. – stejné – 4. Load-balancer pošle zpět odpověď obsahující správný důkaz neexistence pro záznam www.example.com. AAAA: Load-balancer pošle zpět odpověď obsahující nesprávný důkaz neexistence pro záznam www.example.com. AAAA: MIFDNDT3NFF3OD.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OE A

Na konci důkazu je seznam typů záznamů, které na jméně www.example.com existují: V našem případě jsou to pouze záznamy typu A (IPv4 adresa). Důkaz je tedy správný a DNS resolver dostává signál: AAAA tu není, máme jenom A. MIFDNDT3NFF3OD.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OD TXT

Úplně na konci důkazu je nekorektní část, která říká, že jméno www.example.com obsahuje pouze záznamy typu TXT. To zároveň znamená, že dotaz na typ A nemá smysl – z uvedeného důkazu by totiž DNS resolver získal chybnou informaci, že neexistuje. 5. Resolver si uloží důkaz neexistence do vyrovnávací paměti (cache). – stejné – 6. Nyní resolver stejným způsobem zpracovává dotaz www.example.com. A (IPv4 adresa). – stejné – 7. DNS resolver z předchozí odpovědi už ví, že A existuje, ale zatím neznal jeho hodnotu. Jinými slovy, v cache má důkaz, že existuje záznam www.example.com. A, který dosud není v cache, takže se zeptá autoritativního serveru. DNS resolver v cache má chybný důkaz, že neexistuje záznam www.example.com. A. 8. Resolver přijme A záznam od autoritativního serveru, zvaliduje DNSSEC podpis a odešle záznam webovému prohlížeči. Na základě chybné informace získané v kroku 4 resolver ihned odpoví webovému prohlížeči, že záznam s IPv4 adresou neexistuje. 9. Webový prohlížeč má IPv4 adresu a může se připojit na web. Webový prohlížeč nemá žádnou IP adresu a nemůže se připojit na web. Útok odepření služby

Chybu ilustrovanou výše může útočník zneužít k útoku typu odepření služby (DoS), a to dokonce dvěma způsoby:

  • Prostým posláním dotazu na DNS resolver s podporou agresivní cache. Útočníkovi se stačí zeptat na cílové jméno a libovolný neexistující typ. Jediným dotazem tak způsobí nedostupnost konkrétní domény a s ní spojené služby pro všechny uživatele daného DNS resolveru, typicky např. všechny zákazníky daného poskytovatele připojení k Internetu.
  • V případech, kdy útočník nemůže poslat dotaz na resolver, nebo daný resolver nepodporuje agresivní cache, lze použít dlouho známou techniku podvržení DNS odpovědi. V tomto případě je útok proveden ve dvou fázích, přípravné a útočné, které popisujeme níže:
Příprava na podvržení odpovědi
  1. Útočník pošle zranitelnému load-balanceru dotaz na cílovou doménu a neexistující typ, např.
    www.example.com. AAAA (nebo kterýkoliv jiný neexistující typ, např. HINFO)
  2. Zranitelný load-balancer odpoví důkazem neexistence, který stejně jako v předchozím příkladě obsahuje nekorektní informaci, ale je validně podepsán podepisovacím klíčem domény:
    MIFDNDT3NFF3OD53O7TLA1HRFF95JKUK.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OD53O7TLA1HRFF95JKUL TXT
  3. Útočník si uloží nekorektní důkaz neexistence pro pozdější použití.
Útok podvržením odpovědi
  1. Oběť se zeptá na cílovou doménu a existující typ, např.
    www.example.com. A
  2. Útočník podvrhne dříve získanou odpověď místo „pravé“ odpovědi od load-balanceru.
  3. Podvržený důkaz neexistence zdánlivě splňuje všechny požadavky DNSSEC standardu a dokazuje, že typ A neexistuje, a je proto uložen do cache resolveru.
  4. Resolver na základě podvrženého důkazu neexistence odpoví oběti, že požadovaný záznam neexistuje.
  5. Oběť se nemůže na cílový web připojit.
Jak jsme chybu odhalili?

V Laboratořích CZ.NIC se zabýváme vývojem vlastního DNS resolveru a chceme, aby patřil mezi nejefektivnější na trhu. Proto jsme vloni náš software rozšířili o podporu tzv. „agresivní cache s podporou NSEC3“, kterou doposud nemá žádný „konkurenční“ software. Jedná se o novou techniku popsanou ve standardu RFC 8198, která umožňuje DNS resolveru používat všechny informace zabezpečené DNSSEC a odpovídat na některé dotazy přímo z cache resolveru (viz kroky 7 a 8 výše, v odstavci „Kde je chyba“). Když jsme toto rozšíření nasazovali, setkali jsme se s tím, že uživatelé sice získali zefektivnění odpovídání na DNS dotazy, ale zároveň si někteří z nich stěžovali na nevysvětlitelné potíže s připojením na weby některých bank a státních úřadů, a co je nejhorší, „problém sám po chvíli zmizel“, což velmi ztěžovalo analýzu.

Podrobně jsme analyzovali problematické dotazy a odhalili, že problém není v naší implementaci standardu, ale je na straně autoritativního serveru (přesněji load-balanceru) a že se projeví, jen když se dotazy sejdou „v nešťastném pořadí“. Problém pak trvá do vypršení platnosti záznamů v cache DNS resolveru. Chybu jsme nahlásili výrobci a čekali na opravu. Výrobce F5 původně žádný termín opravy nesliboval, ale když jsme podrobně popsali potenciál ke zneužití, tak během několika měsíců publikoval návod, jak chybu obejít změnou konfigurace.

Závěrem

Snad se nám podařilo ilustrovat, jak nebezpečné je používat při implementaci „zkratky“, které jsou v rozporu se standardem. Každá taková nestandardní zkratka sebou nese riziko zavlečení bezpečnostních chyb.

V tomto případě paradoxně byly postiženy systémy institucí, které uživatelé považují za nejbezpečnější a které aktivně investují do „obrany“ pomocí řešení od externího dodavatele. Inu, i subdodavatelé se musí držet technických standardů.

Pokud se chcete o technologii DNSSEC dozvědět víc, zveme vás na kurz v Akademii CZ.NIC.

Kategorie:

Teplo je třeba uchladit

St, 07/03/2019 - 10:13

Venkovní teploty oproti včerejšku sice poněkud opadly, ale i tak bude myslím ideální, když dnešní díl seriálu o budování privátního sálu pojedná o jeho chlazení. Technologie v datovém centru totiž generují obrovské množství tepla (my kalkulujeme s řádově desítkami kW) a bez chlazení, nebo při jeho výpadku, se za pár minut „upečou“. Myšleno v nadsázce. Dnes to již neplatí. Všechny technologie, které budeme v privátním sále provozovat, se při případném přehřátí automaticky vypnou, což dává vlastně stejný výsledek, protože služby na nich přestanou běžet. A výpadky chlazení se opravdu stávají. Ve své praxi jsem je zažil několikrát a často přispěly i ke změně provozovatele datového centra.

V předcházejícím dílu seriálu jsem psal, že máme v privátním sále opravdu hodně vysoko do stropu a že budeme používat racky o výšce 52U, mimo jiné i kvůli získání dalšího prostoru pro naše technologie. Dnes dodávám, že v privátním sále nebudeme mít, oproti tomu stávajícímu zdvojenou podlahu. Nebude ani zapotřebí, protože pro chlazení budeme používat jiný způsob distribuce chlazeného vzduchu. Oproti často používané distribuci pod zmíněnou zdvojenou podlahou je v našem případě použito chlazení tzv. „záplavou“. V obou případech je chladný vzduch nasáván ze studené uličky přes perforované dveře a vyfukován, potom co projde chlazenými technologiemi, do uličky teplé. Dodávky studeného vzduchu na našem privátním sále zajistíme pomocí dvou nadrackových (máme opravdu vysoko do stropu, kolikrát jsem to již psal? :)) klimatizačních jednotek Conteg CoolTop (každá se třemi EC ventilátory), čtyř vnějších jednotek a dvou zvlhčovačů. Obě vnitřní jednotky budou v provozu maximálně na 50 % výkonu v redundanci 1+1. Při výpadku jedné jednotky najede druhá jednotka do plného výkonu. Distribuce chladného vzduchu z CoolTop jednotky je velice plynulá, protože máme přístup vzduchu rovnoměrný před všechny racky ve studené uličce. CoolTop má jednu obrovskou výhodu, tj. velký průtok vzduchu. Jen pro zajímavost, pokud bude v chodu jeden CoolTop na 100 %, tak se vzduch ve studené uličce vymění za šest sekund, což je výkonově více než dostatečné. Ohledně sání teplého vzduchu do jednotky je z pohledu projektu uděláno maximum, tj. nad i kolem jednotek je dostatek volného prostoru pro sání vzduchu z druhé poloviny sálu. Z fyzikálního principu, kdy teplo stoupá vzhůru ke stropu, si jednotky Cool Top tento teplý vzduch dokáží nasát i z protilehlé teplé uličky. Níže je několik fotek z minulého čtvrtka, kdy byla instalace chlazení ještě v běhu a například ještě nebyla zakrytována studená ulička. Na poslední z fotek jsou výše zmíněné zvlhčovače, které doplňují vlhkost v sále, aby neklesla pod 20 %. Pak se totiž zvyšuje riziko statického výboje.

Nadrackovým jednotkám jsme zpočátku poněkud nedůvěřovali. Provozovateli DC Tower nám ale byla názorně předvedena již delší dobu provozovaná podobná instalace, přičemž po exkurzi přímo u výrobce jsme přišli i o poslední pochybnosti. Měli jsme obavy zejména z možného průsaku kondenzátu, který se při chlazení vytváří, ale tomuto je zabráněno instalací kovové vany s aktivním odčerpáním a záložním pasivním odtokem.

Jinak stav instalace privátního sálu má menší zpoždění. Ke dnešku máme osazeny vstupní dveře, plní se klimatizace, dnes se instaluje slaboproud (kamery, zabezpečovačka, čidla, atp.), PDU v racích jsou již pod napětím, probíhá instalace potřebných propojů, finalizuje se instalace vzduchotechniky a zvlhčovačů. Dnes dojde k zakrytování studené uličky, kontrole funkčnosti čidel a k drobným stavebním dodělávkám. Čekáme dále na dokončení systému hašení, kde schází instalace přetlakových klapek a trysek s tlumiči. Do konce týdne by ale mělo dojít i k úklidu a připraví se provozní testy. Během příštího týdne by mělo dojít k zaškolení našich lidí, možná i k předání sálu k našemu využívání. Pak začneme s instalací našich technologií.

Kategorie:

Knot Resolver slaví páté narozeniny

Čt, 06/27/2019 - 10:10

Knot Resolver je moderní open-source implementace rekurzivního DNS serveru (resolveru), vytvořená a udržovaná relativně malým vývojovým týmem v Laboratořích CZ.NIC. Tomuto projektu, který vznikl jako mladší bratříček úspěšného autoritativního serveru Knot DNS, je právě dnes pět let! V první řadě je tedy na místě velká gratulace a poděkování všem, kdo se na něm podíleli. Zároveň je ale takovéto výročí i vhodnou příležitostí k malému ohlédnutí a bilancování.

Na rozdíl od supernov se softwarové projekty obvykle rodí skromně, bez velkých spektakulárních efektů. Faktickou existenci Knot Resolveru zahájil tento commit v GitLabu:

commit 47fcc12deaffe75a02bb15da23a18708abd265de
Author: Jan Vcelak <jan.vcelak@nic.cz>
Date: Fri Jun 27 14:58:55 2014 +0200

V té době již existovalo několik široce používaných implementací resolverů, z toho přinejmenším dvě open-source (BIND a Unbound). Jaký tedy mělo smysl pouštět se do nové? Ještě před tím, než se podíváme na vlastnosti Knot Resolveru, je třeba říct, že přínosem je nová implementace „an sich” – zvyšuje totiž diverzitu internetového ekosystému a tím i jeho stabilitu. Všichni provozovatelé veřejných resolverů, jako je Google, Cloudflare nebo i CZ.NIC, používají zároveň několik různých implementací, čímž snižují riziko totálního výpadku této služby v případě, že by se u jedné z nich objevila nějaká zranitelnost. Knot Resolver je pro ně jedna ze solidních alternativ, využívá ho třeba Cloudflare na svém resolveru 1.1.1.1, a samozřejmě i CZ.NIC v případě ODVR.

Toto jsou základní milníky uplynulých pěti let vývoje:

  • 2014 – interní experimenty
  • 2015 – představení veřejnosti
  • 2016 – verze 1.0.0, nasazen jako výchozí resolver pro routery Turris Omnia
  • 2017 – podpora DNS-over-TLS a agresivní DNSSEC cache
  • 2018 – verze 2.0.0, nasazení u Cloudflare
  • 2019 – verze 4.0.0, první implementace DNS-over-HTTPS

Největší komparativní výhodou Knot Resolveru je nejspíš jeho modulární architektura. Vlastní jádro je minimální implementace validujícího DNS resolveru napsaná v jazyku C. Tu je možné doplňovat o různé další funkce prostřednictvím modulů, napsaných nejen v Céčku, ale i v Lua. Řadu takových modulů najdeme přímo v distribuci. Z těch, které doplňují či upravují vlastní službu DNS, můžeme jmenovat třeba filtrování dotazů podle předepsaných pravidel, DNS64 anebo aktuálně DNS-over-HTTPS. Příkladem poněkud rozmařilejší funkce, která by v klasickém monolitickém programu neměla co pohledávat, je HTTP/2 rozhraní pro správu resolveru. Své moduly, i neveřejné, si samozřejmě mohou přidávat v případě potřeby také jednotliví uživatelé a operátoři.

DNS je jednou z nejstarších, ale také nejexponovanějších služeb v Internetu. Není proto divu, že je hlavním terčem i nástrojem kybernetických útoků a zneužití všeho druhu. DNS komunita, jíž je CZ.NIC aktivním členem, na tyto hrozby průběžně reaguje jak vývojem nových standardů, tak i nasazováním bezpečných a zodpovědných operativních postupů a politik. Obě součásti projektu Knot se snaží být stále nejen na špičkové technologické úrovni, ale i takříkajíc v první frontové linii. Modulární architektura je i v tomto ohledu neocenitelnou předností – konzervativní uživatelé nemusí podstupovat riziko spojené s nasazováním nových a nevyzkoušených technologií, jakou je třeba výše zmíněné DNS-over-HTTPS.

Co čeká Knot Resolver a jeho vývojáře v blízké budoucnosti? Jedním z velkých a složitých úkolů bude zvýšení výkonu, na němž se negativně projevují některé nedostatky původní softwarové architektury. Zdá se, že jakékoliv výraznější „vytunění” bude vyžadovat spousty mravenčí práce a také celkem zásadní změny kódu.

Dalším poměrně urgentním problémem je rozhraní pro konfiguraci a správu. Zatím jsem se o tom nezmínil, ale běžící procesy Knot Resolveru je možné dynamicky rekonfigurovat i jinak ovlivňovat pomocí skriptů v jazyce Lua. To je ovšem dvousečná zbraň – na jedné straně nabízí uživateli nevídané možnosti, na straně druhé ale také dostatek provazu, na němž se může nechtěně oběsit. Cílem je proto skrýt tuto komplexitu do samostatné nadstavby, která poskytne unifikované a bezpečné API pro konfiguraci a správu, včetně asynchronních notifikací a telemetrických dat.

Na závěr chci popřát vývojářům i uživatelům Knot Resolveru ještě řadu úspěšných pětiletek s dobře a svižně fungujícím softwarem. Na oslavu si dnes večer ke skleničce pustím i oblíbenou píseň Suchého a Šlitra.

Kategorie:

Kolik je 52U aneb Jaké budeme používat racky

St, 06/26/2019 - 11:21

Kdo se těší, že budu psát o německých válečných ponorkách nebo o využití racka chechtavého při správě registru, ten nechť zavítá na jiné webové stránky. Mým záměrem je pokračovat ve sdílení informací o budovaném privátním datovém sále. Instalace v privátním sále totiž za poslední tři týdny výrazně pokročily, nejrozpoznatelnější změnou jsou nainstalované rackové skříně neboli racky neboli speciální skříně na IT technologie umístěné v datovém centru. A právě o nich bych rád dnes zmínil pár detailů. Nejdřív ale fotka, jak vypadal sál před instalací racků.

Jedním z cílů přechodu do privátního sálu (pro jedno datové centrum) bylo získání více prostoru pro umístění IT technologií. Při návrhu osazení sálu jsme se proto od začátku snažili, abychom poskytnutý prostor využili co nejlépe. Ve sdílených sálech je v lepším případě možné ovlivnit pouze velikost racků v půdorysu (šířku a hloubku), výška je definována sdíleným sálem. V případě nově budovaného privátního sálu tomu mohlo být jinak. Na plochu sálu jsme tak rozmístili optimální kombinaci racků s šířkami 60 a 80 cm a hloubkou 120 cm. To by ještě nebylo tak neobvyklé, „šedesátky“ i „osmdesátky“ racky jsou běžný standard nebo spíš „šedesátky“ standard a „osmdesátky“ komfort – pro manipulaci v racku jsou rozhodně výrazně lepší. Větší odchylkou od běžného standardu je ale použitá výška racků, která je ve všech případech 52U, oproti nejčastěji využívaným 42U. „U“ znamená tzv. rack unit, tedy rackovou jednotku (1,75 palce (44.45 mm)), ve které se udává velikost zařízení umísťovaných do racků. A právě těch 10U navíc u všech devíti nově instalovaných racků nám dává požadovaný upgrade o více jak 50 % kapacity privátního sálu oproti výchozímu stavu se sedmi racky po 42U. Využití 52U racků je možné proto, že máme v privátním sále „vysoko do stropu“. V podstatě jde o podobný princip jako při stavbě výškových budov, kdy se na metr čtvereční vejde daleko více bytů, kanceláří atd. Rozmístění racků v sále je na následujícím schémátku.

Vyšší racky si vynucují specifický přístup, třeba v tom, že běžný smrtelník s průměrnou výškou (tj. třeba já) bude muset pro práci ve vyšších sférách racku vždy využívat schůdky. Vzhledem k tomu, že většina technologií se instaluje na období řádu let, je tato „komplikace“ určitě akceptovatelná. A nejen to, třeba takový kolega Vašek Steiner s výškou přes 200 cm, tyto malicherné problémy třeba vůbec neřeší :).

Zcela konkrétně máme v novém sále tři racky Conteg RSF-52-60/12A-WWFWA-2EF-H a šest racků Conteg RSF-52-80/12A-WWFWA-2EF-H s vertikálními vyvazovacími panely HDWM-VMR-42-19/10F a HDWM-VMR-48-12/10F a horizontálními vyvazovacími panely HDWM-VMR-48-12/10F. Vyvazovací panely jsou velmi důležitou „bižuterií“ racků, kterou pečlivě vybírala kolegyně Irča Hovorková, kdo jiný :). Panely nastavují standard pro budoucí vnitřní uspořádání technologií v racku a výrazně ovlivňují efektivitu chlazení. Neméně důležité je i další vnitřní uspořádání v racku; budeme mít tandem PDU na jedné straně, vyvazovací panel na druhé. A pozor, určitě není možné zapomenout ani na uspořádání otevírání dveří racků.

Níže jsou reálné fotografie ze sálu, na kterých jsem se snažil znovu zdůraznit výšku racků a neukázat podlahu, kde je ještě spousta kartónů. Přeci jen, práce se zprovozněním sálu ještě nejsou dokončeny. V řádu hodin budou instalovány klimatizační jednotky nebo budou racky osazeny napájecími jednotkami PDU. K nim a dalším technologiím se ale dostaneme zase příště. Mimochodem, ještě Vám dlužím odpověď na to, kolik je tedy těch 52U. Ale to byste měli zvládnout spočítat sami. Prvnímu, kdo do komentáře napíše správný údaj v cm, pošleme nějakou pěknou odměnu :).

Kategorie:

Na zlínském festivalu pro děti a mládež jsme představili Maturanta a náš projekt Bezpečně na netu

Pá, 06/07/2019 - 13:03

S projektem Bezpečně na netu, který si dává za cíl zlepšení internetového prostředí, jsme se představili v rámci doprovodného programu na 59. Mezinárodním festivalu filmů pro děti a mládež ve Zlíně.

Naší první akcí bylo setkání dětí z krajů celé České republiky, se kterými jsme na mládežnickém panelu debatovali o nástrahách Internetu. Z diskuze jsme se dozvěděli, že tyto děti tráví průměrně na Internetu tři hodiny denně a jejich nejoblíbenějším místem je zde Instagram nebo Youtube. Docela překvapující pro nás bylo, že nám děti vyvrátily domněnku o oblibě sledování internetových seriálů. Tento formát je pro ně zatím nezajímavý, přičemž často dávají přednost kratším videím. Dále jsme se dostali i k tématu používání mobilů ve školách. Podle názorů dětí by jim omezení mobilů ve výuce nevadilo a naopak by ho uvítaly. Pokud jde o získávání informací, tak se o dění ve společnosti moc nezajímají a cíleně nechodí na žádné stránky se zpravodajstvím. O tom, co se děje ve světě, se nejčastěji dozvídají od kamarádů nebo ve škole.

Po diskuzi s dětmi následovalo setkání odborné veřejnosti na Advisory panelu. Přítomni byli nejen zástupci organizací, které se věnují prevenci, ale i představitelé státních institucí, policie nebo komerčního sektoru. V neformální atmosféře jsme diskutovali o vzdělávacích projektech a situaci na školách. Dozvěděli jsme se, že problémem není nedostatek peněz na prevenci, ale počet odborníků, kteří by se aktivně věnovali vzdělávání dětí. Problémem, se kterým si zatím moc organizací neví rady je, jak dostat na akce rodiče.

Druhý den se ve Zlíně konala jednodenní odborná konference Bezpečně na netu. Tématy setkání s mezinárodní účastí bylo bezpečí dětí v online prostoru a zmapování a prodiskutování dané problematiky. Po přednáškovém bloku, v němž vystoupili opravdové kapacity z oboru – Karel Strachota (Jeden svět na školách), Kamil Kopecký (UP Olomouc), Jan Kolouch (CESNET), byl účastníkům konference představen nový film režiséra Braňa Holička Maturant. Snímek upozorňuje na vliv dezinformací a kybergroomingu. Při následné debatě s tvůrci a herci filmu jsme oznámili, že pro školy připravíme metodiku, jak s filmem ve výuce pracovat. Současně s tím jsme oznámili, že kdo má zájem o komentovanou projekci, ve školách, může se na nás obrátit a domluvit se na konkrétním termínu.

Další den byl Maturant představen dalším (běžným) návštěvníkům zlínského festivalu. V rámci dvou projekcí se na film přišlo podívat přes 500 dětí, se kterými jsme po jeho promítnutí vedli zajímavou diskuzi.

Můžeme jen doufat, že se s příběhem, který odkrýváme, setká co nejméně dětí a Internet pro ně bude jen bezpečným místem, plným inspirace, zábavy a informací.

Kategorie:

Privátní sál – upgrade a vyšší bezpečnost v jednom

St, 06/05/2019 - 10:10

Na úvod si dovolím popis současného stavu. Pro účely provozu infrastruktury (včetně infrastruktury registru .CZ domén a české části DNS anycastu) si sdružení pronajímá kapacity ve třech datových centrech:
– DC TOWER Českých radiokomunikací
– CE Colo
– neveřejné lokalitě

Ve všech případech jsou naše technologie umístěny ve sdílených datových sálech, fyzické zabezpečení je provedeno pomocí zaklecování a upgrade není ani v jednom ze sálů možný.

V případě DC Tower a CE Colo jsme blízko vyčerpání kapacity týkající se místa, chlazení a napájení, respektive elektrického jištění. Zprovoznění velkých DNS stacků znamenalo instalaci nových racků v obou zmíněných datových centrech. V neveřejné lokalitě je ještě větší část kapacity volná a je tedy nyní nejčastěji využívanou lokalitou pro instalaci nových technologií.

Popis záměru

Pro potřebný upgrade kapacit jsme proto uvažovali různé možnosti, včetně budování zcela nové lokality, ale nakonec nám ze všech variant vyšlo jako nejvýhodnější vybudovat tzv. „privátní sál“ v datovém centru Českých radiokomunikací, protože po migraci do privátního sálu nedojde ke zvýšení provozních nákladů na provoz infrastruktury. Naopak budeme mít možnost provozní náklady snižovat. V privátním sále budeme totiž jediným subjektem, kromě provozovatele datového centra, který ovlivňuje efektivitu chlazení (koeficient PUE). Lepší efektivitu chlazení (nižší PUE) docílíme již tím, že náš privátní datový sál bude postaven na principu teplé a studené uličky, budeme striktně zamezovat nežádoucímu míchání teplého a studeného vzduchu nebo tím, že budeme chladit na vyšší teplotu. Snižování PUE se okamžitě projeví na fakturaci za spotřebovanou elektrickou energii. Toho lze docílit ve sdíleném datovém sále velmi obtížně.

V rámci DC TOWER jsme tedy začali budovat privátní sál, který nám poskytne o 50 % více místa v racích a téměř dvojnásobnou kapacitu napájení a chlazení. Privátní sál dál zvyšuje fyzickou bezpečnost naší infrastruktury, protože je „za zdí“ a zákazníci, kteří navštěvují sdílené prostory datového centra, ji vůbec neuvidí.

V současné době jsou:

– dokončeny hrubé stavební práce
– nataženy silnoproudé rozvody
– v rámci sálu připraveny žlaby pro vedení silnoproudu, slaboproudu i konektivit
– vyrobeny a dodány jednotky UPS
– dokončeny instalace potrubí chlazení s přípravou na následné napojení na jednotky CoolTop
– hotové instalace pro vzduchotechniku
– připraveny instalace zabezpečovacích zařízení
– nainstalovány rozvody pro hašení a větší část s ním souvisejících technologií
– dokončeny práce s podlahou, je položeno antistatické linoleum včetně uzemnění
– připraveny trasy pro konektivity

Nyní netrpělivě čekáme na dodávku racků (dodavatel Conteg, konkrétně se jedná o racky 600x1200x52U a 800x1200x52U pro optimální využití prostoru) a celou řadu dalších kroků dle plánu a projektu.

Pokud nedojde k zásadnějšímu zpoždění, začneme začátkem července práce na zprovoznění síťové infrastruktury v privátním sále, která bude předcházet prvním fyzickým přesunům technologií. Jak v případě síťových prvků, tak v případě serverů, ale i dalšího vybavení datového sálu, provádíme generační obměnu technologií. Výsledkem bude 10G konektivita ke všem serverům, ale také 100G propojení lokalit. Jde tedy o upgrade i z tohoto pohledu.

Do konce roku bychom se v datovém centru Českých radiokomunikací rádi kompletně přesunuli do privátního sálu. O dalším průběhu a také o nových technologiích vás budeme průběžně informovat na tomto blogu.

A takto by měl, dle projektu náš privátní sál vypadat. Jak se vám líbí?

Kategorie:

Bezpečnostní školení, které dává smysl

St, 05/22/2019 - 11:15

Kyberbezpečnost, bezpečnost IoT a další bezpečnostní termíny jsou skloňované čím dál tím častěji. Souvisí s nimi také školení, která mají internetové profesionály na problémy a problematické situace s internetovou bezpečností připravit. Jedním takovým je školení od společnosti SANS, které patří celosvětově mezi nejprestižnější a nejvyhledávanější. Společnost SANS nabízí celou řadu těchto školení. Konkrétně jedno z nich nese název SEC542: Web App Penetration Testing and Ethical Hacking.

Úvod je věnovaný základní problematice, tedy takzvanému “Intofmation gathering”. Účastníci zjistí, jaké všechny informace mohou získat pomocí nástroje „whois“. Pomocí proxy nástrojů „ZAP“ a „BurpSuite“, se dostanou do komunikace mezi prohlížečem a webovým serverem, kterou poté mohou libovolně upravovat a při tom si vyzkoušet různé útoky na webový server. Nástroje neumožňují pouze manipulovat s HTTP komunikací, ale jsou také schopné automaticky procházet weby, objevit známe zranitelnosti na stránkách, automaticky vyplňovat přihlašovací pole podle slovníků a plno dalších užitečných funkcí.

V další části školení na účastníky čekají příklady spojené s problematikou konfigurace serveru a autentizací klientů. Prostor dostane také nástroj „nikto“, který hledá základní konfigurační chyby u vlastních webových aplikací a serverů. Například dokáže vyhledat dosud neodstraněné základní instalační soubory na serveru, a zjišťuje, jestli je bezpečně nastavená hlavička odpovědi serveru podle aktuálních standardů.

Na to navazuje kapitola věnovaná práci s webem, a to konkrétně hledání citlivých informací. Například v nesmazaných konfiguračních souborech, poznámkách v html kódu nebo metadatech. Lektor posluchačům ukazuje různé druhy autentizace, jejich výhody, nevýhody a způsoby zneužití.

Přibližně v půlce kurzu dostane slovo správa relace, která slouží k tomu, aby webový prohlížeč věděl, jaký uživatel je zrovna přihlášený. Posluchači se tak naučí způsoby, jak je možné vytvářet relace, sledovat je a zneužívat.

Potom následuje část týkající se útoku typu SQL injection. Tento typ využívá neošetřeného vstupu do webové aplikace, při které pomocí SQL příkazů umožní útočníkovi získat přístup k citlivým datům uživatelů uložených v dané databázi, v nejhorším případě dokonce k přihlašovacím údajům.

Postupně se dostane i na problematiky „Cross-Site Scripting (XSS)“, základní strukturu modelu DOM, politiku Same-Origin-Policy a „Cross-Site Request Forgery (CSRF)“. Útok XSS má za cíl podstrčit škodlivou část javascriptu do html stránek, které se pak spustí v prohlížeči návštěvníků. Každého milovníka XSS zranitelností, pak potěší seznámení s nástrojem BeEF. Jedná se o framefork, který obsahuje již předpřipravenou sadu útočných javascriptů. V tomto případě může jednoduše útočník přes uživatelské rozhraní napadnout uživatele zranitelné webové aplikace. Příkladem útoků může být zobrazení upozornění, že je nutné aktualizovat webový prohlížeč. Místo slíbené aktualizace, by v případě reálného útoku proběhla instalace malwaru.

Závěr kurzu je věnován psaní finální zprávy, která je důležitou částí samotného penetračního testování. Ve zprávě je nutné popsat, jakým způsobem daný problém vyřešit. Dokument slouží nejen k vyřešení nahlášených zranitelností, ale je v něm také uvedeno, jak otestovat danou zranitelnost, aby každý, kdo si objedná penetrační testy, byl schopný po odstranění nalezených zranitelností ověřit, zda opravdu došlo k jejich opravení. Schopnost pentestera psát finální zprávu je stejně důležitá jako schopnost umět najít zranitelnosti na webu.

Pokud se absolvent kurzu rozhodne získat certifikát, je nutné během následujících čtyř měsíců absolvovat certifikační zkoušku. K dispozici jsou dva zkušební testy, pro jejichž absolvování je povoleno používat veškeré studijní materiály ze školení, pochopitelně včetně vlastních poznámek. Test je tvořený z oblastí, které byly probírány v průběhu týdenního školení.

Kurz SEC542: Web App Penetration Testing and Ethical Hacking má svoji cenu a ta není nijak nízká. Absolvování týdenního školení stojí přibližně sto padesát tisíc korun. Této částce ale odpovídá jak úroveň přednášejících, tak rozsah teoretické i praktické části. Závěrečný test je potom velice náročný, jak obsahově, tak časově. Absolventi jsou ale považováni za skutečné odborníky, kteří se velice dobře vyznají v dané oblasti. Protože posilování schopností bezpečnostních týmů v oblasti kybernetické bezpečnosti je jedním z cílů projektu Strengthening cyber-security capacities in the Czech Republic, spolufinancovaném Nástrojem Evropské unie pro propojení Evropy, mohl jsem se tohoto školení zúčastnit. V rámci uvedeného projektu pak vznikl i tento článek.

Kategorie:

Na ODVR podporujeme také DNS-over-HTTPS

Po, 05/20/2019 - 09:34

V mém nedávném blogpostu jsem informoval o spuštění nového ODVR, tedy našich DNS resolverů pro veřejnost. Nové ODVR provozujeme na k tomu určeném DNS anycastu s námi vyvíjeným resolverem, kterým je KNOT Resolver. Současně se spuštěním nového ODVR jsme zprovoznili i podporu šifrované komunikace DNS-over-TLS (DoT).

Nyní přicházíme ještě s podporou protokolu DNS-over-HTTPS (DoH). Vedle DoT se tedy jedná o další možnost, jak šifrovat spojení mezi klientem a DNS resolverem. Pro využití DoH zbývá už jen správně nastavit váš internetový prohlížeč.

Nastavení DoH

DoH si můžete vyzkoušet ve Firefoxu od verze 62, Chrome od verze 66 nebo Bromite od verze 67.

Nastavení ve Firefoxu je velice jednoduché. Přejděte do menu „Předvolby“, v menu „Obecné“ zcela dole najděte sekci „Nastavení sítě“ a klikněte na tlačítko „Nastavení“. Zaškrtněte „Zapnout DNS přes HTTPS“ a do pole „Vlastní“ vložte URI „https://odvr.nic.cz/doh“.

Alternativně lze DoH aktivovat i v pokročilém nastavení „about:config“ vyhledáním řetězců network.trr.uri, network.trr.mode a případně i network.trr.bootstrapAddress.

Výše uvedené nastavení, stejně tak i pro protokol DoT, je dostupné také v rámci webové prezentace https://www.nic.cz/odvr.

Protokol DNS-over-HTTPS je provozován v experimentálním modu a doporučujeme spíše používat pro šifrovanou komunikaci protokol DNS-over-TLS. Určitě ale budeme moc rádi za Vaši zpětnou vazbu s použitím DoT a zejména DoH.

Ověřit funkčnost DoH si můžete např. pohledem do síťového provozu, pomocí nástroje tcpdump.

Měli byste vidět podobný výstup jako na obrázku výše, tedy provoz na portu TCP/443 a nečitelný obsah packetů.

I při použití protokolu DoH platí, že nefiltrujeme žádné DNS dotazy, vyjma privátních IPv4 a IPv6 rozsahů.

Vypnutí původního ODVR

Původní ODVR běží z jedné části na samostatných serverech s fail-overem (IP adresy 217.31.204.130, 2001:1488:800:400::130) a z druhé části na DNS anycastu pro .CZ doménu (IP adresy 193.29.206.206, 2001:678:1::206). Využití obou prostředí je nerovnoměrné a většinu provozu odbavují právě ne-anycastové servery, jak ukazuje následující graf.

Využití anycastových serverů se pohybuje okolo 25 % celkového provozu. Protože chceme ODVR z bezpečnostích důvodů zcela oddělit z DNS anycastu pro .CZ doménu, přednostně odstavíme právě tuto skupinu IP adres, tedy 193.29.206.206, 2001:678:1::206. Jelikož jde o dlouhodobý proces, provedeme to až v okamžiku, kdy provoz na této části ODVR klesne pod 1 % celkového provozu.

Vzhledem k tomu, že se ODVR používá i na routerech Turris, částečný pokles provozu zajistíme změnou DNS resolverů v rámci release TurrisOS. Nové adresy jsou již použity v nedávno vydané verzi TurrisOS 4.0 beta 1, pro TurrisOS 3.x budou dostupné v následující aktualizaci.

Další oslabení provozu zajistíme kontaktováním ISP poskytovatelů, od kterých přichází nejvíce DNS provozu.

Kategorie:

Validace mojeID na jakémkoliv Czech POINTu! Jak na to?

Út, 05/14/2019 - 10:42

Na základě značného úspěchu validací účtů služby mojeID pomocí datových schránek (viz článek kolegy Talíře), kterou každý měsíc využije kolem stovky uživatelů mojeID, jsme pro uživatele připravili další možnost validace. Od dnešního dne, tedy 14. května, mohou fyzické osoby zdarma podávat žádosti o validace na kterémkoli pracovišti Czech POINT.

Možnost validovat účet zdarma tak je na více než 7 000 místech po celé republice.

Služby Czech POINT jsou navíc dostupné i v zahraničí na vybraných zastupitelských úřadech. Uživatelům služby mojeID se tak výrazně urychlí a usnadní validování. Na rozdíl od validace s ověřeným podpisem je tento způsob validování účtu navíc zdarma.

Validované účty služby mojeID využijete například na portálu Hlídačky.cz, na stránkách Technologické agentury ČR, pro hlasování v obecních referendech, při výběru větších výher v Účtenkovce, k zapůjčení studijních materiálů v různých knihovnách či ke správě svých domén prostřednictvím naší aplikace Doménový prohlížeč.

Postup validace prostřednictvím pracoviště Czech POINT

Po přihlášení do vašeho účtu na www.mojeid.cz si v profilu vyplníte datum narození. Přejdete na záložku Nastavení a zde je v sekci Validace tlačítko Validovat přes Czech POINT.

Pokud tlačítko není zobrazeno, máte vyplněné položky Organizace nebo IČO. Validace přes Czech POINT je dostupná pouze pro fyzické osoby.

Dále se vám zobrazí stránka s informacemi pro vytvoření žádosti.

Klikněte na tlačítko Vytvořit žádost o validaci

Zobrazí se žádost o poskytnutí údajů z registru obyvatel třetí osobě. Tu vytisknete a s dokladem totožnosti žádost donesete na pracoviště Czech POINT.

Žádost obsahuje potřebné informace, identifikátor a tlačítko tisku jsou zvýrazněné

Na pracovišti Czech POINT požádáte o jednorázové poskytnutí údajů z registru obyvatel další osobě, referenční kód služby je 462. Zkontrolujte, že ve zprávě pro příjemce je vyplněn identifikátor žádosti mojeID.

Pracoviště Czech POINT pak odešle požadavek na Správu základních registrů, která následně zašle do naší datové schránky informace k validaci.

Dle času podání žádosti na Czech POINT dojde k jejímu zpracování stávající nebo následující pracovní den. Po zpracování obdržíte upozornění e-mailem. Žádost o validaci pak potvrdíte po přihlášení do vašeho účtu. Doporučujeme si poznamenat identifikátor žádosti pro případné reklamace či dotazy.

Tlačítko pro potvrzení žádosti

Pokud ani během několika dnů neobdržíte upozornění e-mailem, pravděpodobně se nepodařilo identifikátor spárovat s požadavkem na validaci.

Ještě jednou proto ověřte, že v potvrzení z pracoviště Czech POINT je správný identifikátor žádosti. Pokud ne, je třeba zajít na Czech POINT znovu. V případě, že na potvrzení je identifikátor správně, obraťte se prosím na naši technickou podporu na e-mailu podpora@mojeid.cz.

Již vytvořenou ale zatím nezpracovanou žádost je možné stornovat pomocí tlačítka Zrušit žádost o validaci přes Czech POINT.

Tlačítko pro zrušení žádosti o validaci

Po zrušení stávající žádosti je pak možné kdykoli vygenerovat novou žádost o validaci.

Kategorie:

Nebojíme se být spolu offline

Po, 05/06/2019 - 11:03

Sdružení CZ.NIC se zapojilo do kampaně – Týden rodiny offline s podtitulem „Nebojíme se být spolu offline“, která se letos koná v termínu od 11. do 19. května 2019. Účelem již 4. ročníku kampaně je nejen oslavit Mezinárodní den rodiny, který připadá na 15. května, ale především se zamyslet nad nadměrným užíváním digitálních technologií. Přílišné používání mobilních telefonů, tabletů a počítačů způsobuje nejen zdravotní problémy, ale bohužel zhoršuje i mezilidské vztahy. Děti si již od útlého věku hrají s tablety a mobily, čímž mnohdy ztrácí sociální kontakt se svými vrstevníky.

Proto bychom chtěli společně s ostatními zapojenými organizacemi vyzvat rodiny ke společným offline aktivitám a motivovat je, aby se alespoň na chvíli odpojili od virtuálního světa. Všechny registrované akce musí splňovat podmínku, že při nich nebudou využívané žádné digitální technologie. CZ.NIC přispěje do kampaně besedou nad knihou ON-LINE ZOO, kde si budeme s dětmi povídat o nástrahách v online světě za použítí tištěné knížky, obrázků a her. V sobotu 18. května tak zakončíme v Ústřední knihovně v Praze „šňůru“ sedmi besed, přičemž prvních šest proběhne na ZŠ Hornoměcholupská v Praze a na ZŠ v Tisé v Ústeckém kraji. Již nyní se těšíme na putování s dětmi za zvířátky do zoologické zahrady a příjemně strávené chvíle.

Další možnosti, jak prožít společné chvíle offline a trochu se vzdělat, nabízí naše bezpečnostní pexeso, které si můžete stáhnout, vytisknout, vystřihnout a rovnou začít hrát. Přestože se toto pexeso zaměřuje na rizika online světa, nemá elektronickou variantu. Ta totiž, na rozdíl od papírové, neumožňuje rozvíjet jemnou motoriku. Naučí nás být trpěliví (reálný soupeř není tak rychlý jako elektronický) nebo si po sobě uklidit hrací plochu. U elektronické varianty je člověk zároveň ochuzen o mnohdy zajímavé povídání nad jednotlivými obrázky a termíny, k jejichž pochopení může posloužit výkladový slovníček.

Moderní technologie jsou jistě dobrým pomocníkem, ale umí být i zlým pánem. Mají praktické využití, usnadňují nám život, avšak pokud s nimi pracujeme bez rozmyslu, mohou nás snadno ovládnout. Především rodiče by měli jít svým dětem příkladem a nekoukat přespříliš do displejů svých mobilních telefonů. I krátká každodenní společná činnost, jako je čtení knížky, vyprávění, hraní deskových her, procházka či sport, přispívá k budování lepších vztahů a důvěry mezi rodičem a dítětem.

Tímto bychom chtěli vybídnout vás všechny, pojďme se na chvíli zastavit a třeba na dvě hodiny vypnout mobilní telefon a věnovat se svým dětem, rodičům, kamarádům. Zůstat offline může být zprvu pro některé z nás nelehký úkol, ale pokud se o to alespoň pokusíme, budeme mít ze sebe dobrý pocit, že jsme o krůček blíže k nezávislosti na digitálních technologiích a ke svým bližním, kterým se budeme moci věnovat bez jediného vyrušení pípnutím zprávy či vyzvánením mobilního telefonu. Není to lákavá výzva?

 

Kategorie:

Spouštíme nové ODVR

Út, 04/30/2019 - 10:02

Již více než 10 let mají uživatelé Internetu, nejen v České republice, možnost volně využít tzv. Otevřené DNSSEC Validující Resolvery CZ.NIC, zkráceně ODVR, namísto DNS resolverů od poskytovatelů internetového připojení. Jedná se o českou alternativu k veřejným DNS resolverům od společností Google (tzv. „čtyři osmičky“) nebo Cloudflare (tedy „čtyři jedničky“). Mimochodem i v případě Cloudflare resolverů jde tak trochu o „českou“ alternativu, protože využívá námi vyvíjený KNOT Resolver (viz blogpost kolegy Petra Špačka.

Původní ODVR

Původní ODVR bylo provozováno na dvou oddělených platformách. Na první s IPv4+IPv6 adresou (217.31.204.130, 2001:1488:800:400::130) naslouchaly samostatné servery umístěné pouze v pražských datacentrech, kde byl fail-over řešen softwarovou implementací. Druhá platforma s IPv4+IPv6 adresou (193.29.206.206, 2001:678:1::206) byla propagována z vybraných serverů v anycastu pro .CZ. Tyto servery byly umístěny jak v České republice, tak i Evropě a na dalších kontinentech. Fail-over byl v tomto případě realizován přímo BGP protokolem.

Na servery jsme instalovali zejména Debian a Ubuntu Linux a jako DNS resolver jsme na všech serverech použili Unbound, samozřejmě se zapnutou validací DNSSEC.

Právě společné prostředí .CZ anycastu a části ODVR bylo hlavním impulsem k tomu, abychom tyto dvě součásti zcela oddělili a provozovali nezávisle na sobě. Nasazováním převážně malých DNS stacků, viz také můj dřívější blogpost, do zahraničních lokalit vedlo k větší složitosti správy celého řešení. Současně také logicky docházelo ke sdílení prostředků jednotlivých serverů, které jsme navrhovali zejména pro provoz .CZ domény, a s ohledem na odolnost proti případným útokům jsme se rozhodli provoz ODVR oddělit.

Využití ODVR v České republice v průběhu několika let ukazuje následující graf. Každý modrý sloupec představuje průměrný počet požadavků za sekundu v daném měsíci získaný z průměrných hodnot z každého dne. Maximální využití ve špičkách pak znázorňuje červená linka.

Dle grafu je zřejmé, že zájem o tyto DNS resolvery mezi uživateli Internetu v České republice neustále roste. Naše stávající infrastruktura ale zvládala i daleko větší objem provozu. Důkazem budiž graf provozu (viz níže) z 22. listopadu 2016, kdy došlo k výpadku DNS resolverů společnosti Google (viz také dřívější blogpost kolegy Zdeňka Brůny.)

Nové ODVR

V čem je nové ODVR jiné? Za prvé, všechny servery běží na novém DNS anycastu, který však není součástí .CZ anycastu. Propagují novou dvojici IPv4+IPv6 adres z nového ASN 20701. A protože, na rozdíl od situace před deseti lety, máme svůj vlastní resolver, nahradili jsme Unbound za KNOT Resolver (v době vydání tohoto blogpostu ve verzi 4.0), a to se zapnutou podporou DNS over TLS.

Nové servery jsou nyní umístěny “pouze“ ve všech našich datacentrech v České republice. Zahraniční instance jsme v této chvíli nezprovozňovali, protože objem provozu mimo ČR není příliš významný. Na následujícím grafu je navíc patrná klesající poptávka v posledních dvou letech (jedná se o procentuální zastoupení z celkového počtu požadavků) po ODVR resolverech ze zahraničních lokalit. Jakmile se tento trend podle našich statistik provozu otočí, jsme připraveni servery spustit i ve významných zahraničních lokalitách.

Vyzkoušejte si nové ODVR!

Je to jednoduché. Stačí si v konfiguraci síťového připojení ve vašem PC, telefonu nebo tabletu nastavit IPv4 adresy 193.17.47.1 a 185.43.135.1. Pokud máte k dispozici i připojení pomocí protokolu IPv6, můžete použít i adresy 2001:148f:ffff::1 a 2001:148f:fffe::1.

Podpora šifrované komunikace DNS over TLS je dostupná na adrese odvr.nic.cz, na standardním portu TCP/853. DoT si můžete sami vyzkoušet v Linuxu pomocí stub resolveru Stubby a nebo na mobilních zařízeních s Androidem verze 9, který má tuto podporu přímo integrovanou.

Adresy nového ODVR budou také k dispozici uživatelům routerů Turris jako první volitelné DNS resolvery namísto DNS resolverů od poskytovatele internetového připojení. Pro Turris Omnia od aktualizace TurrisOS verze 3.11.5 a pro Turris MOX od verze 4.0 beta 1.

Přeji vám příjemné (a šifrované) brouzdání po Internetu s našimi novými DNS resolvery a budu se těšit na další stoupající využití ODVR.

Kategorie:

Nový zákon o zpracování osobních údajů

Po, 04/29/2019 - 10:58

Od účinnosti Obecného nařízení o ochraně osobních údajů (č. 2016/679), které znáte spíše pod zkratkou GDPR, uplynul bezmála rok a nyní, nabízí se říci konečně, vstupuje v účinnost zákon o zpracování osobních údajů č. 110/2019 Sb.

Že to ten rok šlo i bez něj, je už patrně zjevné, urban legends typu „bez adaptačního zákona není třeba GDPR řešit“ už snad byly definitivně vyvráceny. GDPR lze vykládat nejen za použití recitálů, ale také pokynů vydávaných Evropským sborem pro ochranu osobních údajů (dříve Pracovní skupina WP29, která vydávala „vodítka“). Ty najdete mj. na webových stránkách Úřadu pro ochranu osobních údajů a jejich četbu lze těm, kdo se ochranou osobních údajů zabývat chtějí či musejí, doporučit.

Přesto je dobře, že tu adaptační zákon nakonec máme. Zákon zpřesňuje některá ustanovení Nařízení, případně stanoví výjimky z jeho ustanovení, pokud to Nařízení připouští.

Zákon mimo jiné stanoví výjimku z povinnosti posuzovat před zpracováním slučitelnost účelu zpracování v případech, kdy správce zpracovává při zajištění chráněného zájmu dle povinnosti uložené právním předpisem osobní údaje, které získal k jinému účelu, avšak toto zpracování musí být nezbytné a přiměřené (tzn. posuzování se ale nevyhne, aby mohl konstatovat, že takové zpracování přiměřené a nezbytné je).

Konečně se také dočkali ti, kteří zpracovávají osobní údaje dětí v souvislosti s nabídkou služeb informační společnosti na základě souhlasu. Nařízení totiž stanovilo věkovou hranici 16 let, zákon ji snižuje o rok, a to na 15 let. Na tomto místě bych chtěla připomenout, že je třeba pečlivě zvažovat právní důvod zpracování osobních údajů dětí, a zda skutečně jejich údaje zpracováváme na základě souhlasu. V ostatních případech totiž nastupuje posouzení jednak právního důvodu, a je-li jím smlouva, pak jejího předmětu ve vztahu k rozumové a volní vyspělosti dítěte (viz občanský zákoník).

Zákon rovněž výslovně umožňuje správcům oznámit příjemcům osobních údajů (pozor, nezaměňovat se subjekty osobních údajů) provedení opravy, omezení zpracování nebo výmazu osobních údajů změnou evidence, pokud do ní mají pravidelně přístup. Tím samozřejmě není dotčena informační povinnost správce vůči osobám, jejichž osobní údaje zpracovává, dle GDPR (čl. 19).

Rovněž je zpřesněna povinnost jmenovat pověřence na ochranu osobních údajů pro případy dle čl. 37 odst. 1, písm. a), a to na orgány veřejné moci a orgány zřízené zákonem, které plní zákonem stanovené úkoly ve veřejném zájmu. Smyslem výše uvedeného čl. Nařízení totiž není kontrola moci ze strany veřejnosti ani kontrola hospodaření s veřejnými prostředky, jako u zákona „stošest“ (o svobodném přístupu k informacím), a tak nemá smysl tuto povinnost v rozsahu dle „stošestky“ vykládat. Povinnost zřídit pověřence tedy má dopadat na subjekty, které se povahou blíží orgánům veřejné moci (ne tedy např. příspěvkové organizace; pozor však, aby na ně nedopadala z jiných důvodů – čl. 37 odst. 1 písm. b) a c) Nařízení!).

Jmenovat lze dále zpřesnění zpracování osobních údajů za účelem vědeckého nebo historického výzkumu a vývoje nebo pro statistické zpracování (zde je vhodné si povšimnout výčtu opatření k ochraně zájmů subjektů údajů, která mohou posloužit i v jiných případech zpracování).

Pozornost si zaslouží i § 17 týkající se zákonnosti zpracování pro novinářské účely nebo pro účely akademického, uměleckého nebo literárního projevu. Zpracovávat lze v takových případech i zvláštní kategorie osobních údajů (např. týkající se náboženského vyznání, politických názorů…), jen je třeba posuzovat nezbytnost jejich zpracování s ohledem na cíl. Důvodová zpráva hovoří o tom, že test proporcionality by měl být prováděn v okamžiku zveřejnění, resp. těsně před ním (což klade nároky na osobu editora). Uvidíme, jakým směrem se bude v tomto směru ubírat rozhodovací praxe Úřadu, případně soudů.

Tím se dostáváme k poslední části, které bych se chtěla v tomto stručném příspěvku věnovat, a to jsou sankce. Zákonodárce očekávaně využil možnosti upravit pravidla ukládání sankcí orgánům veřejné moci a veřejným subjektům. Jednak je tedy omezena výše pokuty v případě porušení povinností zákazu zveřejnění osobních údajů, které stanoví jiný právní předpis (až 1 mil. Kč, resp. až 5 mil. Kč, pokud jsou osobní údaje zveřejněny zvlášť účinným způsobem, např. televizí či prostřednictvím Internetu) .

Dále se omezuje výši pokuty v případech zpracování pro účely předcházení, vyhledávání nebo odhalování trestné činnosti, stíhání trestných činů, výkonu trestů a ochranných opatření, zajišťování bezpečnosti ČR nebo zajišťování veřejného pořádku a vnitřní bezpečnosti, a to na maximálně 10 mil. Kč. V případě osoby, která je orgánem veřejné moci nebo veřejným subjektem (zde je určitá terminologická nekonzistence s § 14, kde je Nařízením užívaný pojem „veřejný subjekt“ nahrazen „orgánem zřízeným zákonem“) může dozorový orgán (tedy ÚOOÚ) upustit od uložení správního trestu.

I v případě ostatních správců může úřad rozhodnout o odložení věci; to když bylo dosaženo účelu, ke kterému by jinak vedlo řízení o přestupku, bylo dosaženo jinak – např. správce provedl opatření k ochraně osobních údajů, odstranil zjištěné nedostatky a podobně.

Závěrem jen drobná informace pro ty, kteří nahlíželi do registru zpracování osobních údajů na stránkách Úřadu – ten bude veřejně dostupný ještě rok a půl počínaje dneškem.

Kategorie:

Akademie CZ.NIC slaví desáté narozeniny

Út, 04/23/2019 - 09:48

Na začátku dubna tomu bylo deset let, kdy se po českém Internetu rozlétla zpráva, že správce české národní domény otevřel vlastní vzdělávací centrum – Akademii CZ.NIC. Za tu dobu se stihla dostat do povědomí odborné veřejnosti, na její služby se obrací soukromé i veřejné instituce včetně škol, hostí tuzemské i mezinárodní organizace, má tři pobočky (Praha, Brno, Ostrava) a v prosinci jí pravidelně navštěvuje Mikuláš, čert a anděl.

Psal se rok 2008, kdy se sdružení CZ.NIC rozhodlo, že v rámci svých osvětově vzdělávacích aktivit zřídí výukové středisko. V Čechách bylo tehdy totiž málo míst, kde by mohli zájemci získat nejnovější a relevantní informace ze světa specifických internetových technologií a infrastruktury a zároveň si je vyzkoušet v praxi. Do konce roku se povedlo zrekonstruovat a vybavit prostory v Americké ulici, kde tehdy sídlilo i sdružení CZ.NIC, a mohly tak proběhnout neveřejné zkušební kurzy pro členy a registrátory. O několik měsíců později byl připravený oficiální program na první období.

Kurz sem, kurz tam

První kurz, ENUM v praxi, se uskutečnil 21. května 2009 a měl pět účastníků. Během existence akademie prošlo jejími dveřmi přes 5 000 posluchačů, kteří navštívili více než 450 kurzů. Pokud bychom měli vypíchnout ty, o které byl nebo je největší zájem, tak se jedná o Implementaci IPv6, Git – univerzální verzovací systém a Počítačovou bezpečnost prakticky. Zajímavostí je, že se dodnes vyučují tři z původních sedmi kurzů, jsou to DNSSEC – zabezpečení DNS, Principy a správa DNS a Směrovací protokol BGP. Nabídka kurzů je pravidelně obměňována a tak je stále z čeho vybírat. Posuďte sami, aktuální přehled je k nalezení na webových stránkách.

Jak plynul čas, ukázalo se, že by byl zájem o modifikace našich kurzů. V roce 2012 tedy přibyly školení na míru, která od začátku využívaly jak komerční subjekty, tak i veřejná správa. Zájemcům se upraví program dle jejich potřeb; může se jednat nejen o zkrácení nebo naopak rozšíření tématu, ale také o případnou kombinaci více témat. Tyto skupiny jsme schopni vyškolit nejen v naší pražské učebně, ale i přímo u nich. V tomto směru je nejčastěji poptávaným kurzem Git – univerzální verzovací systém.

Od začátku nezapomínáme ani na školy a rádi za nimi vyrážíme tam, kde mají zájem. Na přednáškách týkajících se DNS, Internetu a internetové bezpečnosti bylo dosud proškoleno přes 4 500 žáků základních škol a studentů středních a vysokých škol a univerzit. Pro studenty zároveň platí, že u nás mají na všechny pořádané kurzy slevu.

Další rozšíření výuky nastalo v roce 2014, kdy akademie zavedla e-learning. První e-kurz byl věnovaný protokolům TCP/IP. V současné době mohou zájemci absolvovat pět e-kurzů.

Škatula, škatula, hejbejte se
Během těch deseti let jsme zažili i změny, které se netýkaly výuky, ale provozu. Se začátkem školního roku v září 2013 byla zřízená pobočka Akademie CZ.NIC v Brně. Tím to ale neskončilo a na podzim roku 2014 se otevřela, ve spolupráci s Fakultou elektrotechniky a informatiky na Vysoké škole báňské, nová pobočka v Ostravě. Obě nabízejí stejný program jako v Praze, ale jsou dostupnější pro posluchače z Moravy a Slezska, potažmo ze Slovenska.

Pražská akademická centrála zároveň změnila dvakrát své působiště. Poprvé v roce 2015, když se stěhoval celý CZ.NIC do Milešovské ulice a po druhé v minulém roce, kdy jsme se s akademií přesunuli na Olšanské náměstí.

Host do domu…
Akademie dlouhodobě hostí akce českých i zahraničních organizací, které se podílí na rozšiřování IT znalostí nebo na rozvoji internetové infrastruktury.

Z těch zahraničních u nás proběhlo například setkání pracovní skupiny Euro ISPA, CENTR, IPv6 Hackers Meeting, cvičení Cyber Europe nebo kurzy RIPE NCC. Z těch českých se jedná například o hostování kurzů programování PyLadies, Czechitas, VISK, dále také workshopů pro technické dokumentaristy, Turris Hackathon nebo se zde koná již dva roky dětský Kybertábor.

Bez lidí by to nešlo a jedno přání k tomu
Aby se všechny výše zmíněné aktivity mohly uskutečnit, musel je někdo vymyslet, navrhnout, realizovat a odškolit. Ráda bych proto nejmenovitě vyzdvihla všechny, kteří se na tom podíleli nebo dosud podílí. Počínaje lektory a konče celým týmem Akademie CZ.NIC, který se stará, aby vše šlapalo jako hodinky.
A na závěr narozeninové přání. Hodně spokojených posluchačů, nových kurzů, akcí a stále tak nadšených lektorů. Deset let Akademie CZ.NIC je za námi, tak ať je těch dalších deset stejně inspirativních a pestrých!

Kategorie:

O zkušenosti se Safer Internetem jsme se podělili s kolegy z Bosny a Hercegoviny

Po, 04/01/2019 - 09:09

V březnu navštívila naše sdružení delegace expertů z pěti různých organizací v Bosně a Hercegovině zaměřených na bezpečnost dětí na Internetu a ochranu osobních dat.

Účastníci se věnovali především aktivitám v projektu Safer Internet, na kterém se CZ.NIC podílí již čtvrtým rokem. Od letošního roku dokonce vystupujeme v roli koordinátora a společně s Linkou bezpečí pracujeme na ochraně dětí v kyberprostoru a včasném řešení problémů spojených s kyberšikanou, kybergroomingem, kyberstalkingem a jinými tématy tohoto druhu.

Kolegové z Bosny a Hercegoviny navštívili i prostory Linky bezpečí, kde její pracovníci vysvětlili (především zástupcům organizace IFS-EMMAUS) chod linky a s jakými případy se z oblasti kyberšikany nejčastěji setkávají a jak je řeší.

Organizace IFS-EMMAUS byla v Sarajevu založena původně za účelem pomoci obětem války, ale nyní se chystá více zaměřit na pomoc dětem v oblasti kyberbezpečnosti. V nejbližší době plánují zřídit linku pomoci, proto exkurzi u Linky bezpečí vnímali jako velice pozitivní a cenný přínos.

Elma Zahirovic z IFS-EMMAUS se k návštěvě vyjádřila slovy: „Studijní návštěva nám umožnila získat mnoho nových, užitečných informací, které nám lépe poslouží při provozu našeho informačního centra a linky pomoci, ale i k lepšímu shromažďování a vyhodnocování dat získaných právě prostřednictvím helpline i hotline. Jsme opravdu vděční, že jste se s námi podělili o své zkušenosti a poskytli nám praktické příklady z praxe.“

Bezpečnostní specialisty z Bosny a Hercegoviny zaujal i náš seriál „Jak na Internet“ a s ním související knihy „Jak na Internet“ a „Jak na Internet – bezpečně“. Dále je oslovilo bezpečnostní pexeso, které je dostupné i v anglické verzi a v budoucnu by se mohlo dočkat lokalizace do bosenštiny.

Skutečnost, že si zástupci z Bosny a Hercegoviny vybrali právě Českou republiku, tedy sdružení CZ.NIC, vypovídá o našem dobrém jménu, které si postupně budujeme doma i v zahraničí, a to nejen díky projektu Safer Internet.

Kategorie: