Hosting

Přihlášení

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

Jak přežít plánovanou údržbu DNS

Čt, 09/20/2018 - 09:20

Systém DNS se na Internetu používá již více než 30 let – nyní je naplánována jeho celosvětová údržba, která poprvé za dobu existence DNS potřebuje koordinaci s provozovali DNS serverů a DNSSEC validátorů.

Následující článek shrnuje zásadní kroky, které by provozovatelé DNS serverů měli provést, aby jejich uživatelé neměli potíže po plánované údržbě DNS na konci roku 2018 a začátku roku 2019.

Kroky nutné pro „přežití“ údržby DNS se liší pro provozovatele DNSSEC validujících resolverů a autoritativních serverů:

  • DNSSEC validátory musí být aktualizovány nejpozději 10. října 2018
  • Autoritativní servery musí být aktualizovány nejpozději do 31. ledna 2019

Po uvedených termínech přestane software se zastaralou konfigurací fungovat správně. Dopad jednotlivých změn podrobněji uvádíme v příslušné kapitole níže.

Rekurzivní servery a DNSSEC validátory Nejpozději do: 10. října 2018

Provozovatelé rekurzivních serverů a dalšího softwaru, který provádí DNSSEC validaci, musí nejpozději 10. října 2018 aktualizovat DNSSEC root klíč (anglicky trust anchor), který slouží k validaci podpisů získaných z veřejného DNS. Dne 11. října 2018 v 18:00 CEST bude (historicky poprvé) DNS root zóna podepsána novým klíčem.

Z tohoto důvodu software, jehož konfigurace neobsahuje nový DNSSEC root klíč, nebude od 11. října 2018 schopen resolvovat žádná data pomocí DNS a z hlediska běžného uživatele „Internet nebude fungovat“.

Jak se připravit?

Provozovatelé DNSSEC validátorů by proto měli zkontrolovat, že jejich konfigurace obsahuje oba DNSSEC root klíče, aby přechod ze starého na nový klíč mohl proběhnout bez lidského zásahu. Konfigurační soubor s klíči by měl obsahovat následující dva řádky (nebo jejich ekvivalent, v závislosti na formátu používaném konkrétním softwarem):

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

První řádek obsahuje klíč s ID 19036 používaný do 10. října 2018, zatímco druhý řádek obsahuje nový klíč s ID 20326, který se bude používat od 11. října 2018.

Software BIND na rozdíl od většiny používá jiný formát souboru s klíči, takže správci BINDu by měli zkontrolovat, že jejich soubor s klíči obsahuje následující text:

managed-keys { . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; . initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU="; };

Pojmenování a umístění souborů i jejich přesný formát záleží na konkrétní verzi softwaru a použitém operačním systému. Z toho důvodu doporučujeme podívat se na návody pro obvyklé případy na stránkách organizace ICANN (anglicky).

Uživatelé Turris Omnia s aktualizovaným operačním systémem se nemusí přechodu obávat, protože nový klíč mají již automaticky nainstalovaný na svých zařízeních.

Autoritativní servery Nejpozději do: 31. ledna 2019

Provozovatelé autoritativních serverů by měli nejpozději do 31. ledna 2019 zajistit, že jejich implementace jmenného serveru správně odpovídá na dotazy s rozšířením EDNS. Přesně podle zveřejněného plánu přestanou významní výrobci DNS software po 1. únoru 2019 (také historicky poprvé) podporovat servery, které porušují DNS standard RFC 6891 i jeho předchůdce RFC 2681.

To prakticky znamená, že servery, které po 1. únoru nebudou odpovídat na dotazy s EDNS rozšířením přestanou z pohledu klientů fungovat a domény hostované na těchto serverech se stanou nedostupné!

Jak se připravit?

Prvním krokem je kontrola, že váš autoritativní DNS server odpovídá správně. K tomu slouží samostatný informační web s testovacím nástrojem dnsflagday.net. Do formuláře na tomto webu zadejte jméno libovolné domény, která je hostována na vašem DNS serveru:

Drtivá většina čtenářů tohoto článku uvidí po kliknutí na tlačítko „Testuj!“ následující hlášení:

V takovém případě nemusíte nic dělat – váš autoritativní server je již připraven.

Pokud testovací nástroj nalezne problém, bude vás informovat např. takto:

Typicky se dají nalezené problémy vyřešit pouhou aktualizací DNS software na jmenných serverech, které hostují testovanou doménu. V ojedinělých případech může být problém způsoben také příliš striktním firewallem, který zahazuje DNS dotazy s některým z rozšíření EDNS.

Další informace spolu s testovacím nástrojem a doporučeními k řešení problémů naleznete na webu dnsflagday.net/cs/.

Závěrem nezbývá než popřát všem provozovatelům DNSSEC validátorů i autoritativních serverů hladkou aktualizaci software a bezproblémový vstup do dalšího třicetiletého období DNS.

Kategorie:

ID4me – jednotná identifikace a domény na německý způsob

Út, 09/11/2018 - 11:02

V sídle německého doménového registru DENIC se 14. srpna sešlo přes 50 zástupců internetových společností, aby se zúčastnili prvního ročníku ID4me summitu. ID4me je aktuální název projektu, který pod názvem DomainID vznikl již loni, a zmínil jsem ho krátce v prezentaci na naší loňské konferenci IT 17.2. Za jeho vznikem stojí právě správce domény .DE spolu s významným německým registrátorem 1&1 a společností Open-Xchange, provozovatelem internetových kolaborativních nástrojů. Společností, které se aktivně hlásí jako podporovatelé, je ale více a nechybí mezi nimi například britský doménový registr Nominet. Cíle, které si projekt stanovil, jsou nám poměrně známé – redukovat množství hesel a registrací při pohybu uživatelů po Internetu. Podobně jako CZ.NIC s projektem mojeID, došli autoři ID4me k závěru, že doménový svět je právě tím místem, kde je možné pokusit se těchto cílů dosáhnout.

Na rozdíl od mojeID, které je samo o sobě službou k okamžitému použití, snaží se ID4me spíše o vytvoření ekosystému spolupracujících organizací, které budou podporovat řešení popsané sadou standardů vznikajících postupně v rámci projektu. Do tohoto ekosystému se již podařilo poměrně rozsáhlou kampaní zapojit řadu zajímavých společností. Relativně nedávno došlo k založení společnosti ID4me AISBL (nadace) se sídlem v Bruselu, která bude členskou organizací a která by měla veškeré aktivity související s projektem zaštiťovat. V tuto chvíli se rozvoj projektu soustředí kolem tří pracovních skupin a jim odpovídajících mailinglistů. V technické pracovní skupině se řeší protokoly a specifikace, na kterých projekt stojí. V organizační pracovní skupině se řeší, jak má ekosystém fungovat na úrovni různých (např. právních) vztahů mezi jeho členy. Poslední adopční pracovní skupina je zaměřená na marketing celého projektu.

Z technického pohledu staví ID4me na používaném standardu OpenID Connect, což mu zajišťuje poměrně dobrou výchozí pozici pro interoperabilitu s existujícími systémy. V mojeID podporujeme tento protokol od roku 2015. ID4me ale přidává tři koncepty, které nejsou příliš obvyklé a reflektují snahu propojit doménový svět se světem identitním.

První z těchto konceptů je rozdělení autentizační služby na dva subjekty. V terminologii ID4me se jedná o Autoritu a Agenta. Agent je subjekt, ke kterému přijde zákazník jako první, předá mu svoje údaje a požaduje zřízení služby. Jak už asi tušíte, v doménovém světě se tomu subjektu říká Registrátor. Autorita je naopak služba, která garantuje vlastnictví identifikátoru a přiděluje ho konkrétnímu uživateli. Opět, analogický subjekt pro doménový svět je Registr. Autorita je tedy zodpovědná za ověření přihlašovacích údajů uživatele a Agent je zodpovědný za uchovávání a předání jeho dalších údajů. Způsob, jakým je tento koncept namapován na OpenID Connect protokol, je poměrně originální. V terminologii OpenID Connect je tento přístup označován jako „Distributed claims“. Uživatel se protokolem OpenID Connect standardně přihlásí u Autority, nicméně místo předání údajů přihlášeného uživatele Autorita poskytne adresu ze systému Agenta, na které je možné se k údajům dostat. Jeden konkrétní subjekt může ale plnit roli jak Autority tak Agenta. Pro standardní službu, která umožňuje přihlášení přes OpenID Connect, by toto rozdělení nicméně neměl být problém.

Druhým konceptem je myšlenka ustanovit doménové jméno jako primární identifikátor. Uživatel si pořídí doménu a bude jí používat pro přihlášení do všech systémů podporujících ID4me. Pouze manipulací s DNS záznamem u této domény si uživatel může určit, kdo je Autorita a Agent pro toto doménové jméno. Toto je určeno speciálním TXT záznamem u poddomény _openid. Samozřejmostí je, že záznamy u této domény musí být zabezpečeny pomocí DNSSEC. Majitel doménového jména by měl tak mít teoreticky možnost jednoduchou změnou TXT záznamu přejít k jinému poskytovateli identitních služeb. Přestože je snaha tento způsob počáteční identifikace uživatele standardizovat, není aktuálně součástí standardu OpenID Connect a vyžaduje tak změny na straně poskytovatelů služeb.

Třetí koncept, který úzce souvisí s předchozím, ale který přesto vidím jako samostatný prvek, je snaha poskytnout službě, která použije ID4me informaci, že přihlášený uživatel je opravdu držitelem zvolené domény. Tuto informaci se služba po přihlášení dozví se speciálního atributu id4me_identifier. Určitou úroveň důvěry tomuto atributu dává proces ověření pomocí DNS varianty ACME protokolu, které by měla provést Autorita předtím, než uživateli vytvoří účet. Jedná se ale o jednorázové ověření při registraci a tudíž nic neříká o aktuálním stavu. Navíc pokud by toto ověření bylo povinné, limituje to zapojení existujících služeb. Dle mých informací se ale zatím neuvažuje, že by tato povinnost byla vynucována.

Autoři ID4me nezůstávají v teoretické rovinně a připravili i sadu knihoven, která zmíněné koncepty implementuje. Existuje projekt na Gitlabu, kde je možné si stáhnout kód, nebo případně diskutovat nad požadovanými změnami. Existují již i některé pilotní projekty, které umožňují přihlášení přes ID4me. Abychom si otestovali kompatibilitu ID4me, zavedli jsme do DNS požadovaný záznam v následujícím formátu:

_openid.mojeid.cz. IN TXT „v=OID1;iau=mojeid.cz/oidc;iag=mojeid.cz/oidc“

Pokud se chcete přihlásit ke kolaborativnímu řešení Open-Xchange s využitím mojeID, stačí když do formuláře napíšete mojeid.cz a kliknete na tlačítko „Sign with ID4me“. Pokud si navíc zaregistrujete doménu a přidáte si k ní tento stejný TXT záznam, budete se nově moci přihlašovat s použitím vaší domény. Obdobným způsobem je možné otestovat si přihlášení u technologického zpravodajského serveru AndroidPIT. Bude určitě zajímavé sledovat, kam se bude celý tento projekt dál rozvíjet.

Kategorie:

Aplikace Open Nettest měřila rychlost Internetu až ve Francouzské Polynésii

St, 09/05/2018 - 11:32

Kdo si chce otestovat rychlost svého připojení k Internetu, nabízí se mu v obchodě s aplikacemi hned několik možností. V rámci mezinárodního projektu “Open crowdsourcing data related to the quality of service of high-speed Internet” (zkráceně MoQoS) vznikla aplikace na měření vysokorychlostního Internetu s názvem Open Nettest. Pomocí této aplikace je možné otestovat např. rychlost připojení v telefonu, které nám poskytuje mobilní operátor, či rychlost připojení prostřednicvím Wi-Fi sítě.

Jaká je kvalita připojení v České republice?

To je možné zjistit pomocí vizualizační mapy, která se nachází přímo v aplikaci. Do této mapy se zároveň propisují měření provedená pomocí českého NetMetru, na jehož vývoji se v CZ.NIC podílíme. Díky barevným bodům je na první pohled patrné, v jakých oblastech je silnější či slabší signál. Zatímco hlavní město se doslova “zelená”, tedy pyšní kvalitním pokrytím, v některých oblastech naší vlasti se stále ještě nacházejí místa s velmi slabým, ba dokonce s nulovým signálem.

Jak jsou na tom ostatní státy světa?

Aplikace Open Nettest měřila rychlost připojení k Internetu i v exotických zemích jako je Francouzská Polynésie, Východní Timor, Fidži či Svazijsko. Nejvíce měření však bylo provedeno ve Slovinsku, dále v Německu a na Slovensku. Rakousko, odkud Open Nettest pochází, se překvapivě nachází až na čtvrté příčce.

Které dny a časy jsou nefrekventovanější?

Zajímavostí je, že testy pomocí aplikace Open Nettest jsou nejčastěji prováděny v úterý odpoledne (mezi 13. a 15. hodinou) a později večer (mezi 21. a 23. hodinou). Aplikace je dále hojně využívána během pátečních, sobotních a nedělních večerů.

Kolik měření již bylo provedeno?

Od počátku projektu (1. leden 2017) bylo pomocí Open Nettestu provedeno cca 400 000 měření. 71 % z nich učinili uživatelé mobilních telefonů s operačním systémem Android, 17 % testů uskutečnili vlastníci iPhone, 11 % měření bylo realizováno prostřednictvím hardwarových sond (routerů Turris) a 1 % spadá na testy z webového prohlížeče. Open Nettest totiž umožňuje, stejně jako NetMetr, provést měření přímo na webu, např. z domácího počítače.

V rámci projektu MoQoS dochází k neustálému vyvíjení jak aplikace Open Nettest, tak aplikace NetMetr. V obou aplikacích je možné spustit tzv. kontinuální (cyklické) měření, které je prováděno v pravidelných intervalech a s menším nárokem na spotřebu dat od mobilního operátora. Dále aplikace umí odhalit a následně zobrazit ve vizualizační mapě takzvaná bílá místa, což jsou body, kde byl zachycen nulový signál.

Abychom dosáhli větší relevance výsledků měření a mohli z nich všichni těžit, je důležité provést co největší množství měření. Poté se lépe podaří zmapovat situaci mobilního datového připojení v České republice i ve světě a v neposlední řadě tak přispět ke zlepšování pokrytí signálem a jeho kvality mobilními operátory. Kromě marketingových kampaní se za účelem zvýšení počtu uživatelů a uskutečněných měření, v rámci aplikace Open Nettest, zavádí takzvaná gamifikace (odměňování) ve formě postupného získávání odznaků, které jsou opatřeny veselými dětskými ilustracemi.

Kategorie:

Fotka

Čt, 08/16/2018 - 14:06

Díky zajímavému projektu s názvem Kdo jiný, který vede nezisková organizace Člověk v tísni, jsem měla to štěstí poznat dvě (na svůj věk) skutečně velké osobnosti. Říkejme jim Kristýna a Sandra. Tyhle dvě holky se na své škole setkaly s poměrně závažnou kyberšikanou, avšak namísto toho, aby se litovaly nebo očekávaly, že se problém vyřeší sám, proměnily tyto nepříjemné životní události ve svou životní zkušenost tím, že se rozhodly problém řešit. Nejen pro sebe, ale i pro ostatní děti, které by mohly podobný osud potkat. Díky aktivnímu přístupu těchto holek a jedné paní učitelky vám mohu přiblížit jejich příběh.

Vše začalo fotkou na Instagramu. Když si na této sociální síti najdete profily slavných modelek a podíváte se na jejich selfie, tak byste bez znalosti nějaké další informace nepoznali, který z profilů patří modelkám a který dívkám. Dívky, jichž příběh vyprávím, si však za svou fotografii nevysloužily obdiv a lajky, ale kyberšikanu. Jejich fotografie se začala naprosto nekontrolovatelně šířit napříč školou. Když dívky zapochybovaly nad rozhodnutím fotografii zveřejnit, bylo již pozdě. Spolužáci si ji mezitím stáhli do svých zařízení a bez jakýchkoli servítek odstartovali aktivity, jež byly pro dívky velmi bolestivé. Toto chování se brzy stalo velkou noční můrou holek a znepříjemňovalo jim téměř každou minutu jejich života, kyberšikana je totiž o to závažnější, že její fyzické projevy nekončí ani zabouchnutými dveřmi od třídy.

Spolužáci, se kterými se dívky nikdy v životě osobně nebavily, je na Internetu napadali způsobem, který skutečně nebylo možné přejít s úsměvem ani bez povšimnutí. Škola se k problému postavila až na jednu pedagožku z mého pohledu velmi zvláštně. Kyberšikana v tuto chvíli pro nikoho nebyla problémem, vedení školy začalo řešit, jak je možné, že dívky vůbec takovou fotografii na Internet daly, a protože se jednalo prokazatelně o fotografii pořízenou v prostorách školy, začal dívkám hrozit školní trest. Naštěstí ve škole působí aktivní pedagožka, která s dětmi pracuje na individuálních projektech. Když se o situaci dozvěděla, navrhla dívkám, zda nechtějí téma zpracovat. Postih dívky sice neminul, ale mohly situaci alespoň trochu uchopit do vlastních rukou. Dívky tedy společně se dvěma spolužáky z ostatních ročníků připravily projekt, jehož výstupem byla osobní konfrontace hlavních iniciátorů kyberšikany s oběťmi.

Dívky si ve spolupráci s pedagožkou a po pečlivé přípravě a spolupráci s odborníky zavolaly útočníky do třídy, kde se jich ptaly, zda by jim věci, které psali na Internetu, byli schopni říci do očí a zda si uvědomují, že svým chováním na sociálních sítích způsobili skutečnou a nemalou bolest. Aktéři zapojení do kyberšikany se až na výjimky v reálné situaci chovali pokorně a byli velice překvapeni ze skutečné konfrontace s reálnými dívkami.

Většina z útočníků uvedla, že z jejich pohledu šlo o legraci, která je v jejich kolektivu naprosto běžná, normální a rozhodně si ji nikdo nebere osobně ani nikomu neubližuje. Já jsem se osobně se dvěma útočníky sešla a mohu potvrdit, že jsem z nich měla pocit, že mluvím s naprosto rozumnými a hodnými lidmi, kteří mají sice drsný smysl pro humor a odlišný přístup k životu, ale rozhodně se nejedná o žádné agresory.

Přesto jejich chování způsobilo nemálo bolesti. Musím říci, že být na místě vedení, zřejmě bych situaci také nevyřešila správně, nevím totiž, má-li vzniklá situace vlastně nějaké správné řešení. Myslím si, ale že podobným situacím lze do jisté míry předcházet patřičnou osvětou. Děti by měly vědět, že pokaždé, když na Internet posílají jakékoli informace, je možné, že se setkají s negativní reakcí nespecifikovatelného okruhu lidí. Obecně je dobrou pomůckou, zeptat se před zveřejněním fotografie sám sebe, zda by se nás dotklo, kdyby fotografie, kterou posíláme na Internet, viděla celá naše třída na velké obrazovce nebo zda by se líbila naší babičce. Zároveň bychom měli naše děti učit respektu. Tím mám na mysli především to, že je naprosto zřejmé, že na světě neexistují dva stejní lidé, vždyť stačí znalost o jedinečnosti otisku prstu. Pokud tedy někdo řekne, že mu nějaké jednání ubližuje, neměla by být reakce „ale vždyť je to sranda“ považována za normální. Naopak, měli bychom naše děti učit omluvit se a přijmout pocit druhého člověka jako fakt, kterému nemusí rozumět, ale stačí jej respektovat.

Kategorie:

Druhý ročník kybertábora je úspěšně za námi

St, 08/15/2018 - 10:36

V Akademii CZ.NIC jsme minulý měsíc spolupořádali druhý kybertábor pro dvacet dětí z Domova dětí a mládeže Prahy 9.

Seznamovací hry jsme po zkušenosti z loňského roku rovnou vynechali a s dětmi jsme se hned pustili do věcí, které pro ně měli přichystané Nora s Lukášem, naši kolegové od 3D tisku. Kromě této zábavy měly děti za úkol ještě „offline“ výrobu herních desek, na kterých si potom mezi sebou zahrály turnaj. Milým zjištěním pro nás bylo, když jsme se dozvěděli, že některé děti hrály hru i večer s rodiči. Turnaj se dohrával ještě v průběhu týdne a jeho vítěz si odnesl malý přenosný repráček. Odpolední program potom čekal děti až v Bohnicích, ale za to cestování stál, hrály se totiž laser games.

Úterý zahájil velkolepě kolega Edvard Rejthar, který má dlouholeté zkušenosti s organizací dětských programů a her. K tomu má navíc zkušenosti z divadelního kroužku, takže děti dokázal svým projevem neuvěřitelně nadchnout. Děti si musely na celé dopoledne vypojit myš a plnit jednotlivé úkoly, které nedoprovázela zábavná grafika. Člověk by si řekl, že to ty děti v životě nemůže bavit. Jenže to, jak to měl Edvard promyšlené a připravené, bylo až neuvěřitelné. Děti žádnou grafiku nepotřebovaly, bavilo je posouvat se o úroveň dál, zjišťovat, že „to nejde“ jsou jen slova, která když přestanou říkat, půjde jim to rychleji. Pod Edvardovým vedením se nejeden účastník kybertábora dozvěděl, jak moc přínosné je umět pracovat s počítačem pomocí klávesových zkratek. Děti, kterým bylo mezi 10 a 15 lety, se tak naučily bez pomoci myši klasické vychytávky jako je přepínání, otevírání a zavírání oken, instalaci programů přes terminál, tvorbu a organizaci nových složek a mnoho dalšího.

Středa i čtvrtek byly pod taktovkou úspěšného absolventa Cyber Security Competition Jirky. Jirka měl pro děti na středu připravený program, který se týkal kybernetické bezpečnosti. Děti se během něj zábavnou formou dozvěděly, jak se mohou starat o svá tajemství a jak je důležitá jejich identita na Internetu. Odpoledne potom děti dostaly malé robůtky, které si sami poskládaly.

Ve čtvrtek jsme důkladně prověřili Jirkovy lektorské dovednosti, když jsme po objevení chyby zjistili, že původní program nelze realizovat. Jirka nám hned oznámil, že to vůbec nevadí, protože má plán B i C. Troufám si tvrdit, že plán B byl asi nejúspěšnějším dopoledním programem celého týdne. Děti se velice snadnou a zábavnou formou učily programovat vlastní hru. Jirkovi to ale nestačilo, chtěl pro děti udělat ještě víc, a tak jim od anglicky hovořícího vývojáře této hry sehnal klíče k jinak placené hře a tuto hru jim na páteční odpoledne nejen že stáhl, ale ještě ke všemu ji přeložil, aby ji děti měly česky. Odpolední program se díky dobrým vztahům našeho kolegy s pány z Českých radiokomunikací a jejich velké laskavosti přesunul na Žižkovskou věž, kde jsme se kromě vyhlídek podívali i na to, jak funguje velké datacentrum.

V pátek k nám zavítaly slečny z Národního úřadu pro kybernetickou bezpečnost, aby děti provedly příběhem Báry Bezhlavé, která si myslela, že Internet je anonymním místem. Jednalo se o workshop, v rámci kterého měly děti prostřednictvím klasického internetového vyhledávače zjistit co nejvíce informací o Báře Bezhlavé. Koneckonců, tento úkol si můžete vyzkoušet také.

Kybertábor se i tentokrát povedl a tak jsem přesvědčená, že bude pokračovat i nadále.

Kategorie:

Upgrade .cz DNS aneb Zákulisí příprav a realizace – část čtvrtá

Út, 08/14/2018 - 09:24

Na začátku roku 2017 jsme začali pracovat na projektu celkového posílení infrastruktury autoritativních DNS serverů zabezpečujících provoz .CZ domény. Hlavní motivací bylo zvýšit odolnost DNS infrastruktury proti DoS útokům, jejichž riziko se zvyšuje stále více. Základní stavební jednotkou nové DNS infrastruktury je tzv. „DNS Stack“.

V předchozím díle seriálu o upgrade DNS infrastruktury jsem popsal proces výběrového řízení na 100GE router, switche a servery. Dnešní díl bude věnován přípravě zázemí v datacentru, konkrétně výběru racku a jeho součástí.

Nový rack

Nejdůležitější diskuze nás čekala hned na začátku. Jaký rack potřebujeme, jaké součásti má obsahovat, jak řešit různé proudění vzduchu zařízení, chlazení, napájení apod. Hlavním požadavkem jsme si byli jisti. Potřebujeme do racku umístit 31 serverů, každý o velikosti 1U, dále dva switche (2U), console server (1U), ODF pro vedení optické kabeláže (1U), horizontální vyvazovací panely (2U) a router o velikosti 5U. Vyšlo z toho tedy, že potřebujeme 42U. Připravili jsme návrh zapojení tak, jak bychom si jej představovali a začali řešit veškeré možnosti od návrh až po finální zapojení se zástupci datacentra.

Proběhlo několik setkání, prohlídka konkrétních racků v sálech, úpravy návrhu zapojení podle technologických možností a další a další změny našeho původního návrhu.

Jak nakonec vypadá rack pro Velký DNS Stack?

Jedná se o Conteg RSF-42-80/120. Jeho výška je 42U, šířka 800mm a hloubka 1200mm. Přední i zadní dveře (dělené) jsou perforované z 86 %, obsahují výklopnou pákovou kliku, uzavírání je vícebodové. Rovnoměrné zatížení více než 1000 Kg. Rack je osazen vertikálními lištami (stojnami) 12x1U, na nichž je uchyceno tzv. STS (side-to-side) řešení. Na tyto lišty se také umísťují vertikální HDWM (vyvazovací panely).

Řešení STS umožňuje dokonale oddělit zónu horkého a studeného vzduchu a je tak možné bezpečně osadit síťové prvky s bočním prouděním vzduchu přímo do blízkosti jednotlivých serverů, které mají proudění vzduchu předozadní. V praxi to vypadá tak, jak ukazuje níže uvedený obrázek:

Zdroj: https://www.conteg.cz

Pravá část (vyznačena žlutě) je zaslepena v celé své výšce od vertikální lišty (stojny) k boku racku. Jedná se o podobné zaslepovací panely, které se umisťují do volných U prostorů, kde nejsou umístěné servery, aby nedocházelo k nechtěnému mísení teplého a studeného vzduchu. Do požadované výšky se pak umisťuje adaptér (vyznačen modře) pro konkrétní síťová zařízení, v našem případě pro router Juniper MX240. Tento adaptér zajistí, že se vzduch dostane pouze k routeru. Prostorem mezi STS a bokem racku je možné umístit např. kabelové tunely pro vedení kabeláže zepředu dozadu.

Výhodou STS řešení je možnost mít všechny technologie umístěné v jednom racku. To je v našem případě zásadní, protože vybraný router má proudění vzduchu právě side-to-side, zatímco ostatní zařízení front-to-back. V opačném případě by musely být servery, router a síťové prvky rozděleny do dvou racků. Nevýhodou je, že STS nastaví pevnou rozteč mezi vertikálními lištami (stojny) na 80 cm. Tato skutečnost nás limitovala ve výběru vertikálního HDWM (vyvazovacího panelu), protože jsme původně požadovali variantu s 19 cm žebry. Použili jsme tedy variantu s 12 cm žebry, konkrétně HDWM-VMR-42-12/10F. Jedno HDWM je umístěno vlevo při pohledu zepředu a druhé vlevo při pohledu zezadu.

Pro napájení všech zařízení jsme použili 2x PDU APC 7857. Každé obsahuje 36 zásuvek IEC320 C13 a 6 zásuvek IEC320C19. PDU jsou umístěné vpravo při pohledu zezadu za sebou a jsou samozřejmě připojeny do třech fází.

ODF a optické moduly

Pro vedení optických vláken k jednotlivým serverům a novému racku jsme na základě doporučení vsadili na řešení rozvaděče ODF od společnosti Huber+Suhner. Jedná se o 19“ 1U nebo 4U šasí, do kterého se vkládají moduly v různých provedeních dle zvoleného typu konektorů, celkového počtu, použití pro single-mode či multi-mode apod.

Zdroj: https://www.hubersuhner.com

Pro naše potřeby jsme vybrali variantu IANOS EDR 1U, která umožňuje osadit až 12 modulů (tj. až 72 konektorů LC/MTP), včetně zadního kabelového managementu. Šasí jsme osadili těmito moduly:

  • 7x patching module, single size, Base-2, 6x LCD violet, OM4 PC

    Zdroj: https://www.hubersuhner.com

    Jedná se o základní propojovací modul, v tomto případě s růžovými konektory. Tato barva na první pohled udává, že jde o multi mode variantu. Do tohoto typu modulů je potřeba zapojit vhodná optická vlákna. My jsme použili kabely multipatchcord 1x MTP(F) – 8xLC/PC OM4. Do těchto modulů jsme klasickými LC/PC-LC/PC MM 50/125 OM4 optickými patchcordy připojovali jednotlivé servery. Tyto kabely jsme si nechali vyrobit na míru v různých délkách od 0,8 do 2 metrů tak, abychom zajistili optimální uložení ve vertikálních vyvazovacích panelech.

  • 1x patching module, single size, Base-2, 6x LCD blue, SM PC

    Zdroj: https://www.hubersuhner.com

    Modrý patching modul je oproti předchozího modulu určen pro single mode a použili jsme ho k připojení tranzitní konektivity.

  • 1x transition module, double size, Base-12, front 12xLC/PC, rear 2xMTP, OS2

    Zdroj: https://www.hubersuhner.com

    Tento modul je uvnitř plně osazen a realizuje přechod mezi MTP na vstupu a LC na výstupech. Použili jsme jej pro propojení mezi nových rackem a stávající infrastrukturou za použití 2x MTP-MTP / 12F SM kabelů. Těmito vlákny jsme přivedli všechny důležité propoje k novému routeru.

 

Další díl bude věnován instalaci, testování a přípravě pro nasazení do provozu.

Kategorie:

Dílna technických pisálků po třetí

Po, 08/13/2018 - 10:58

Dne 14. června proběhl v Akademii CZ.NIC 3. ročník, pomalu již tradičního, workshopu výměny zkušeností mezi technickými dokumentaristy, nebo-li TW workshop. Mluvčí opět přednesli velmi zajímavá témata, jejichž přehled můžete najít na stránce workshopu. Na tomto ročníku se sešlo zatím nejvíce účastníků (17) a jejich hodnocení pro nás byla velkým povzbuzením pro další opakování této akce. Pojďme se podívat podrobněji na jejich i moje dojmy.

Kupříkladu Marie z RedHatu o workshopu napsala:

„TW workshop je vcelku komorní akcí s omezeným množstvím účastníků, což je skvělé z několika různých důvodů. Setkávají se tu totiž techwriteři působící v České republice, kteří přicházejí z firem rozdílných velikostí. Někteří účastníci workshopu mají dlouholeté zkušenosti, jiní teprve začínají. … Když jsem se skrze své kolegy dověděla o existenci TW workshopu, věděla jsem, že tohle je pro mě skvělá příležitost jak ‚vplout‘ do světa konferencí v oblasti techwritingu. Vzhledem k limitovanému počtu 20 účastníků jsem věděla, že v pozici nováčka nebudu stresována velkým publikem a navíc propozice deklarovaly důležitost prostoru pro diskuzi, na kterou byl vymezen opravdu dostatek času. Tedy skvělá příležitost pro výměnu zkušeností, učení se od zkušenějších, diskuzi aktuálních problémů … Tehdy mi to velmi pomohlo!“

Prezentace tvoří hlavní program workshopu a dávají především prostor pro sdílení zkušeností v techwritingu (technické dokumentaristice). Nabízejí současně také příležitost začínajícím mluvčím, aby si mohli vyzkoušet prezentovat a rozvíjet své prezentační dovednosti před malým publikem. To ale není jediný pilíř workshopu.

Stejně důležitá, možná i nejdůležitější, je možnost si volně a neformálně popovídat s techwritery z jiných společností. Jak říká naše pravidelná účastnice Vendula z Dativery, jejíž slova volně parafrázuji: „Tu nejdůležitější věc dne se obvykle dozvím při přestávce na kávu.“. Já jsem se tak například doslechla o první vlaštovce v akademickém vzdělávání techwritingu, která přiletí na Technickou univerzitu v Liberci. Proč je to tak důležité?

Dlouhodobě se totiž zabývám tím, jak dostat profese technické komunikace jednak do povědomí na trhu práce i obecně a jednak na akademickou půdu. Jak jsme se shodli v jedné z diskuzí, to, čím se zabýváme, je svébytná oblast odborných znalostí, která navíc těží z překvapivě bohaté kombinace vědních oborů, a jako taková si zaslouží respekt a odborné vzdělávání.

Ale ještě zpět k prezentacím a jejich tématům. Vendula se také rozepsala o obsahu prezentací workshopu a její reportáž si můžete přečíst na blogu Dativery.

Zatímco první ročník měl pevně stanoven společný námět, vloni a letos jsme zvolili jiný přístup, který dovolil účastníkům přijít s vlastními tématy. Díky tomu se jich sešla pestrá škála, která dovolila jejich rozvinutí do větší šíře. Jeden z účastníků, Milan z NetSuite/Oracle, komentoval témata následovně (volný překlad z komentáře v angličtině):

„Navštívil jsem workshop již v minulých letech a témata mi připadala lépe uplatnitelná v mojí práci (tehdy jsem pracoval pro RedHat). Letos jsem shledal témata super-zajímavými, ale méně relevantními pro mou současnou práci. Ale nemyslím si, že by to bylo nutně na škodu, protože profesnímu rozvoji prospívá i rozšiřování obzorů.“

Díky, Milane! Možná znovu zvážíme, zda na příštím ročníku opět nezkusit stanovit společný praktičtější námět, ale nevytratila by se tím kýžená pestrost?

A víte co? Teď se díky našemu nově založenému mailinglistu s námi můžete spojit i během roku. Pozdravte nás, požádejte o radu nebo nám něco poraďte vy sami, a případně nám pomozte začít plánovat další ročník!

Kategorie:

Pohled do zákulisí výroby prototypů Turris MOX

Út, 07/31/2018 - 10:10

Nový produkt řady routerů Turris se jmenuje MOX a je koncipován jako modulární systém. K základnímu CPU modulu MOX A bude možné připojit řadu dalších modulů, které uživateli umožní využívat pouze funkce, které potřebuje a nebude muset platit za periferie, které zatím nevyužije. A samozřejmě celý router v budoucnu rozšířit, když bude potřebovat. Moduly označené písmeny A až E se nyní nachází ve fázi prototypů, tedy oživování, testování jednotlivých funkcí, ale také ladění výroby a přípravě na tisícové výrobní série. A jak taková výroba prototypů vypadá, to se dozvíte v tomto článku.

Stejně jako druhá výrobní série routeru Turris Omnia, bude se i Turris MOX vyrábět v Lanškrouně, ve společnosti Morelli Electronics, s. r. o. Výroba elektrotechniky má na Lanškrounsku dlouholetou tradici, protože zde fungovala Tesla Lanškroun a nyní je zde několik jejích nástupců.
Do výroby jsme mohli nahlédnout ve chvíli, kdy se na lince vyráběly prototypy modulu MOX C – modul se čtyřmi metalickými gigabitovými konektory RJ 45 a gigabitovým switchem Marvell Topaz. Ještě před samotnou výrobou je nutné, na základě dat od hardwarových vývojářů, nechat vyrobit PCB – Printed Circuit Board, česky DPS – desky plošných spojů (dále desky) a nakoupit komponenty pro jejich osazení. Desky necháváme vyrábět v Číně, zejména kvůli rychlosti a ceně. Výroba a doručení do ČR trvá přibližně dva až tři týdny.

Komponenty, veškeré součástky, na prototypy pak nakupujeme na některém z on-line shopů, kde jsou okamžitě skladem. Pokud jde vše bez problémů a zásilka nezůstane na celnici, tak máme komponenty k dispozici za cca tři dny od objednání.

U sériové výroby je to však zcela něco jiného. Je rozdíl, když potřebujete stovky kondenzátorů nebo dva miliony. Ceny a především dodací lhůty jsou výrazně odlišné a v dnešní době bohužel značně nevyzpytatelné. Celý popis nákupu komponent by vydal na další článek, který zveřejníme třeba někdy příště.

Máme tedy vše potřebné k výrobě přichystané, naše prototypy jsou zařazeny do plánu výroby a můžeme vyrábět. Jako první se osazují SMD součástky, tedy součástky pro povrchovou montáž. Laicky řečeno jsou to ty malé součástky bez viditelných vývodů. Na MOXu C tedy téměř vše, kromě ethernetových konektorů.

Prvním krokem je nanesení pájecí pasty na desku. Desky se nedodávají samostatně, ale v tzv. panelech, ze kterých se až po osazení vylomí. Díky panelům lze PCB umístit na dopravníky jednotlivých strojů, přičemž každý krok je realizován na větším množství desek současně. V našem případě jsou v jednom panelu čtyři desky MOX C. Nanesení pájecí pasty se pak realizuje pomocí sítotisku. Sítotiskový stroj má navíc svoji vlastní inspekci, kterou kontroluje tloušťku, rovnoměrnost, množství a tvar nanesení pasty na jednotlivých bodech desky.

Sítotisk s připojeným vstupním podavačem

Detail vnitřku sítotisku

Desky umístěné ve vstupním podavači

Po vyjetí ze sítotisku je na všech ploškách pro SMD součástky nanesena bezolovnatá pájitelná pasta šedé barvy.

Pohled na přepravník na výstupu sítotisku

Do takto nanesené pájecí pasty se v dalším kroku umístí komponenty. Tento krok se provádí v osazovacím automatu. Komponenty jsou dodávány v několika typech balení, většinou však v tzv. reelech – kotoučích.

Komponenty na osazení prototypu MOX C

Tyto kotouče se umístí do podavače, tzv. feederu, který se nacvakne do osazovacího automatu. Ten pak na základě programu umístí jednotlivé komponenty na správné místo. Podklady pro tvorbu tohoto programu dodávají naši hardwaroví vývojáři.

Feeder s namotaným kotoučem kondenzátorů

Pohled do vnitřku osazovacího automatu, v pravém dolním rohu několik feederů

Osazovací automat má také možnost kontrolovat jednotlivé komponenty, zda jsou vhodné k osazení – spočítá počet vývodů na součástce a porovná ji s uloženým vzorem v programu. Lze tak odhalit případnou chybu v nabití feederu, nebo chybu součástky.

Kontrola součástky – zapnuté kamery

Kontrola součástky – vypnuté kamery, je možné vidět pipetu pro uchopení součástky

Obsluha osazovacího automatu není nic jednoduchého. Trvá zhruba dva měsíce, než se operátor naučí základní obsluhu, jeden rok pak než zvládne všechny procedury a programování stroje. A dále se učí celý život.
Daní za modulárnost MOXe je použití tzv. Straddle mount konektorů, kterými se jednotlivé moduly spojují. Jejich osazování a pájení není jednoduchou záležitostí a nelze je v našich podmínkách provádět automatizovaně. V našem případě jsou nasazovány ručně pomocí speciálního přípravku, který si v Morelli vyrobili.

Balení straddle mount konektorů

Ve výrobní lince, na které se osazovaly prototypy MOX C, jsou umístěny dva osazovací automaty za sebou. V jednom se osadí část součástek, ve druhém zbytek. Díky tomu lze zároveň osazovat dva panely, místo jednoho.

Osazená deska po výjezdu z prvního osazovacího automatu

Deska po kompletním osazení SMD součástkami

Pohled na linku, zleva sítotisk a dva osazovací automaty

Osazené desky se pak posílají skrz reflow pec, kde dojde k přetavení pájecí pasty a vodivému spojení jednotlivých vývodů součástek s deskou. V Morelli mají dvě reflow pece, bohužel ta větší, do které vede přepravník v námi používané lince, byla v době naší návštěvy mimo provoz. Mohli jsme si alespoň vyfotit její vnitřní část. Tato větší pec má příkon 45 kW při zahřívání, které trvá 20 minut.

Reflow pec, použitá při výrobě prototypů MOX C, v popředí stojan na feedery pro osazovací automaty

Otevřená reflow pec, na které poběží výroba Turris MOX

Výjezd desek z reflow pece

Po osazení a zapájení všech komponent na SMT linkách přichází na řadu kontrola na AOI – Automated Optic Inspection. Zde je u všech součástek prověřeno, zda jsou správně zapájeny a zda jsou na správných pozicích. Jak AOI funguje je nejlépe vidět z následujícího videa.

Posledním krokem u našich prototypů je osazení ethernetového konektoru. V sériové výrobě půjde o tzv. pájení vlnou, u malého počtu prototypů je výhodnější konektory osadit a zapájet ručně.

Osazené moduly jsou zabaleny do ESD bublinkové folie a odeslány do CZ.NIC do rukou našich vývojářů, kteří je oživí a začnou testovat jejich funkcionalitu. To už je zcela jiný příběh.

Kategorie:

Na uživatele domácích routerů směřuje i více než 250 útoků denně

St, 07/25/2018 - 11:26

O tom, jak zranitelné mohou být SOHO routery, se můžeme prakticky každý týden dočíst v analýzách nejrůznějších bezpečnostních firem. Zpráva společnosti Symantec za rok 2017 uvádí meziroční nárůst počtu útoků na IoT zařízení o 600 %. Mezi nejzranitelnější části pak patří právě nezabezpečené routery, prostřednictvím kterých je často možné získat snadný přístup k jednotlivým připojeným zařízením. O narůstajícím počtu těchto útoků a jejich závažnosti svědčí rovněž dubnové varování oficiálního amerického CERT.

Převést všechny tyto útoky a výsledky práce analytiků do srozumitelnějších čísel jsme se pokusili v rámci projektu Honeypot as a Service (HaaS), který nabízí možnost přesměrování útočníků na centrální honeypot. Do projektu podpořeného Technologickou agenturou ČR, se podařilo zapojit již více než 2 000 uživatelů, z nichž necelé tři čtvrtiny tvoří uživatelé routerů Turris.

Vysoký počet uživatelů se následně odrazil rovněž na objemu zachycených dat, resp. sezení a příkazů, které útočníci na centrálním honeypotu uskutečnili. Na cílovém honeypotu, na který byli útočníci přesměrováváni, bylo za první pololetí letošního roku celkem zaznamenáno více než 73 milionů sezení a téměř 42 milionů příkazů (někteří útočníci neuskutečnili žádný příkaz), viz graf.

Pokud přistoupíme na prostou kalkulaci, že jedno sezení se rovná jeden pokus dostat se do routeru, vyjde nám, že každý den je naše „vstupní brána Internetu“ cílem i více než 250 útoků, tj. přibližně deseti útoků za hodinu. Je sice pravdou, že ne všechny pokusy představují sofistikované útoky, avšak podrobnější analýza ukazuje, že v některých případech by útočník mohl napáchat významné škody.

Nahlédnout útočníkům více pod prsty nám umožnila právě analýza jednotlivých vzorků, která byla v rámci projektu HaaS, jenž je podpořen Technologickou agenturou ČR, prováděna ve spolupráci s tchajwanským partnerem – Institute for Information Industry (III).

Za první pololetí letošního roku bylo na server nahráno celkem 8 071 unikátních souborů zabírající v součtu více než 6 GB. Díky tomu, že byly zkoumány pouze unikátní soubory (tj. pokud byl soubor zachycen v únoru, jeho další zachycení v březnu již není započítáváno), je klesající tendence zachycených vzorků logická.

Co se týče cílových architektur, zachycené binární soubory byly velmi rozmanité – od ARM přes MIPS až po x86 včetně nejrůznějších pod-variant. Dva největší soubory měly stejný začátek jako instalační media Debian 9.3 a Linux Mint 18.3, což se dá nejpravděpodobněji vysvětlit snahou útočníků ověřit, kolik si můžou na nově získaný stroj uložit dat. Dalším zajímavým nálezem byl 17 MB textový soubor obsahující přes milion domén, ze kterých se 945 nacházelo v doméně .CZ. Vzhledem k faktu, že se mezi českými doménami nápadně často vyskytovaly domény státní správy, byl tento soubor poskytnut Národnímu úřadu pro kybernetickou bezpečnost (NÚKIB).

Na základě provedené dynamické analýzy byly odhaleny například snahy o komunikaci s Command and Control (C&C) serverem, tj. řídícím počítačem pro botnet. Taková komunikace vypadala typicky tak, že po úvodní inicializaci docházelo pouze k pravidelnému udržování spojení (keep-alive). Další zachycené vzorky se snažily připojit do takzvaného těžebního poolu, kde bylo jejich úkolem těžit virtuální měnu pro útočníky. U jiných vzorků byla zaznamenaná snaha o DDoS útok, která se ale později projevila jako snaha o detekci schopnosti napadeného počítače podvrhovat zdrojové IP adresy.

Na rozdíl od DDoS útoku se malware pokusil poslat pouze několik paketů s odlišnou zdrojovou IP adresou na adresu svého C&C serveru. V případě, že by bylo detekováno, že čerstvě získaný počítač toho schopen je, byl by s největší pravděpodobností zneužit právě k DDoS útokům. Ty dnes patří k velmi častému typu útoku, jehož cílem je vyčerpání prostředků cíle, který nemá šanci poznat, zda se jedná o legitimní požadavek uživatele zobrazujícího obsah webových stránek nebo uměle vygenerovaný provoz.

Analýza dat z veřejného honeypotu ukázala, že útoky na domácí routery představují bohužel každodenní realitu. Dbát na bezpečnost svého routeru by tak měla být stejná samozřejmost, jako používat antivirový program.

Kategorie:

Případová studie: CSIRT.CZ a statická analýza malware

Po, 07/09/2018 - 11:13

Na základě upozornění nejmenované hostingové společnosti jsme se dostali k analýze souboru WindowsDefenderService.ini), který aktuálně není rozpoznán žádným z běžných antivirů, a dále souboru (EventManager.dll), jenž rozpoznají pouze tři antivirové systémy. Po prozkoumání obou jsme se rozhodli publikovat tento blogpost, který by měl ostatním pomoci zjistit, zda jejich servery nebyly napadeny; v závěru článku jsou uvedeny IoC, s jejichž využitím by mělo být možné ověřit, zda i vaše servery nebyly kompromitovány.

K samotné analýze jsme dostali čtyři soubory: a.ps1, EventManager.dll, EventManager.logs a WindowsDefenderService.ini. Během počátečního zkoumání vyšlo rychle najevo, že soubor a.ps1 obsahuje skript v powershellu pro tvorbu snímků obrazovky a jejich ukládání do C:\ProgramData\icon.png. Dále se ukázalo, že soubor EventManager.dll není klasická knihovna, ale xml soubor obsahující javascript. Soubor EventManager.logs je ve skutečnosti ini file a WindowsDefenderService.ini změtí textových znaků, které se po chvíli ukázaly jako payload pro zmíněný javascript, který volá powershell s deobfuskovaným obsahem WindowsDefenderService.ini jako command argumentem. Po deobfuskaci pomocí částečného spuštění kódu, dekompresi a přeložení z base64 byl poprvé vidět i samotný zdrojový kód, který byl napsaný pozpátku.

Po přečtení kódu od konce byla jasně vidět struktura jednotlivých funkcí, nicméně kód zůstával i nadále obfuskován. Již byly ale čitelné některé konstanty. Bylo například zjevné, že malware používá api.ipify.org k zjištění veřejné IP adresy. Malware si sebou rovněž nesl 600 delších řetězců (~65 znaků) kódovaných v BASE64, které ovšem po dekódování nedávaly smysl. Rovněž bylo zřejmé, že malware kontroluje existenci antivirových řešení na infikovaném počítači pomocí řetězců „Kasper“, „Panda“, „ESET“, „Symantec“ a „McAfee“.

Po další chvilce zkoumání a několika substitucích se ukázalo, že názvy funkcí a proměnných jsou zakódovány pomocí funkce ROT13. Po jejich dekódování jsme již dostali čitelný zdrojový kód. Ukázalo se, že malware se připojuje na Command & Control server, odkud dostává další příkazy a krom pořizování snímků obrazovky může vykonat prakticky libovolný příkaz.

Při zjišťování k čemu přesně a jak slouží přiložené BASE64 řetězce, byla nalezena funkce, která je kromě dekódování i „dešifruje” pomocí funkce xor a klíče (slova) „secretkey”. Z těchto řetězců se následně vyklubaly URL pro C&C servery, z nichž se náhodně vybíralo pomocí funkce „get-random”. K tomuto výběru docházelo vždy, pokud došlo ke spuštění nebo k problému v komunikaci.

Persistence malware byla zajištěna využitím registrů, konkrétně ve větvi „run” a to jak „HKLM”, tak „HKCU”, a to díky naplánovaným úlohám „schtasks”. Snímky obrazovky malware ukládal do C:\ProgramData\icon.png. Komunikace s Command & Control serverem probíhala každých 135 +/-15 vteřin. V případě pořizování snímku obrazovky se čekalo dalších 15.

Během následujícího víkendu jsme tak dali dohromady potřebné informace, které jsme pak předali dotčené hostingové společnosti. Bohužel nemáme k dispozici informace o vektoru, kterým k napadení serverů došlo. Proto není možné posoudit, zda se jednalo o náhodný útok, nebo zda někdo záměrně útočil na hostingovou společnost. Nicméně právě z těchto důvodů jsme se rozhodli publikovat informace, které mohou pomoci případným dalším obětem zjistit, zda nebyly jejich servery kompromitovány.

Pokud se tedy chcete přesvědčit, zda tento malware nenapadl i vaše servery, můžete využít následující IoC: Seznam C&C serverů a Manipulace s registry.

Martin Kunc, Jan Neduchal

Kategorie:

Tox a jeho použití v CZ.NIC

Čt, 06/28/2018 - 09:36

Před nějakou dobou jsme se v CZ.NIC rozhodli k testování našich projektů v Pythonu použít projekt Tox. Tento projekt umožňuje sjednotit testování projektů v různých prostředích (lokálních vývojových i těch na integračních serverech) a také usnadňuje testování možných kombinací závislostí. Obzvláště druhý bod se nám s přechodem na Python 3 zdál důležitý.

Postupným vývojem a překonáváním drobných (i větších) překážek jsme nakonec dospěli ke stabilní Tox konfiguraci, která splňuje všechny naše požadavky. Níže se pokusím jednotlivé vlastnosti této konfigurace trochu osvětlit a rozebrat.

Konfigurace projektu Tox

Naše finální konfigurace pro projekt „rdap“ vypadá následovně:

[tox] minversion = 3.0.0 envlist = quality,clear-coverage,{py27,py35}-django{10,11},compute-coverage [testenv] setenv = PYTHONPATH = {toxinidir}/test_cfg:{env:IDL_DIR:} DJANGO_SETTINGS_MODULE = settings passenv = IDL_DIR PYTHONWARNINGS debian_deps = py27: python-omniorb py35: python3-omniorb skip_install = coverage: True install_command = pip install --process-dependency-links {opts} {packages} extras = testing deps = coverage !thaw: -cconstraints.txt django10: Django>=1.10,<1.10.99 django10: pytz django11: Django>=1.11,<1.11.99 commands = coverage run --parallel-mode --source=rdap --branch -m django test rdap [testenv:clear-coverage] commands = coverage erase [testenv:compute-coverage] commands = coverage combine coverage report --include=*/tests/* --fail-under=100 coverage report –omit=*/tests/* [testenv:py27-thaw] [testenv:py35-thaw] [testenv:quality] extras = quality # Do not fail on first error, but run all the checks ignore_errors = True deps = commands = isort --recursive --check-only --diff rdap flake8 --format=pylint --show-source rdap pydocstyle rdap

První částí je základní hlavička konfiguračního souboru, která specifikuje minimální požadovanou verzi Tox (kvůli použití negativních faktorů) a také seznam prostředí, která se mají spustit při použití příkazu „tox“. Ta jsou specifikována pomocí tzv. faktorů (výčet uvedený ve složených závorkách, jednotlivé faktory jsou odděleny pomlčkou) a při provádění pak dochází k expanzi do matice. Výsledný seznam prostředí (a jejich pořadí) je tedy následující:

quality clear-coverage py27-django10 py27-django11 py35-django10 py35-django11 compute-coverage

Následuje blok specifikující základní nastavení testovacího prostředí a také definuje, jaké příkazy se budou provádět. Blok „debian_deps“ je konfigurací pro„tox-debian-plugin“, který se stará o instalaci Debianích balíků přímo do daného virtuálního prostředí. Tento blok také využívá faktorů a specifikuje různé závislosti v návaznosti na verzi Pythonu. Pomocí volby „skip_install“ specifikujeme, že pro prostředí, které obsahují faktor „coverage“ není nutné balík instalovat. Dále potřebujeme definovat vlastní instalační příkaz (přidána volba „–process-dependency-links“ – je důležité pro implementaci hooku) a také definujeme, jaké extra komponenty testovaného projektu se mají instalovat a jaké další balíky (kromě tech uvededených v setup.py) je nutné doinstalovat. Zde je opět použito faktorů a to i negativních („!thaw“ značí všechna prostředí, která neobsahují faktor „thaw“). Volbou „commands“ jsou specifikovány příkazy, které se mají provést v rámci běhu daného virtuálního prostředí.

Nastavení uvedená v bloku „[testenv]“ jsou brána jako základní a je možno je přetěžovat či k nim přidávat. Toho se využívá při definici prostředí pro zpracování výsledků coverage, kde se sice používá stejné natavení jako v základním bloku, ale jsou zde změněny příkazy, které se provádějí.

Dále je také možné specifikovat jiná prostředí, která nejsou uvedená v definici „envlist“. Takto definovaná prostředí je možno spustit ručně pomocí přepínače „-e“. Takto máme definována prostředí pro testování aktuálních verzí závislostí. Posledním použitým prostředím je statická kontrola kvality, kde je vynulován seznam závislostí kvůli urychlení vytváření prostředí a také jsou tu ignorovány výsledky jednotlivých příkazů. To donutí Tox dokončit všechny příkazy uvedené v bloku „commands“ a nahlásit až souhrnný výsledek.

Správa závislostí na interních projektech

V našem vývojovém cyklu a prostředí našich aplikací dochází často k tomu, že vývojová větev závisí na ješte nezačleněných větvích v jiných interních projektech. Tento stav pro Tox (i pro nás) představuje problém, protože bychom museli v „setup.py“ vždy uvádět konkrétní vývojovou větev závislých projektů. Tento způsob je ale zcela nevhodný, protože by bylo nutné setup.py při integraci do hlavní větve měnit a mohlo by docházet k chybám.

Rozhodli jsme se tedy využít možností psaní pluginů pro Tox a napsat si plugin, který se o podobnou věc postará za nás.

Nejprve jsme vytvořili repozitář pro správu závislostí mezi projekty. Z formátů nakonec vyhrál JSON díky své jednoduché struktuře a přítomnosti parseru přímo ve standardní knihovně. Náš konfigurační soubor má následující strukturu:

{ „project1“: { „origin“: „project_1_url“, „revision“: „an_awesome_feature“ }, „project2“: { „origin“: „projectu_2_url“, „revision“: „yet_another_feature“ } }

Tento konfigurační soubor se jmenuje „our_feature.conf“ a jednoduše znamená, že aby někomu fungovala naše vývojová větev pojmenovaná „our_feature“, musí si v projektech 1 a 2 přepnout na větve „an_awesome_feature“, resp. „yet_another_feature“.

Toto nastavení jednotlivých větví je tedy třeba provést i při automatickém testování v rámci continuous integration. K nám tomu slouží implementace Tox pluginu. Ten se pomocí „pluggy.hookimpl“ zapojí do procesu instalace závislostí a provede následující kroky:

1) Naklonuje výše uvedený repozitář s konfiguracemi prostředí do dočasného adresáře,

2) zkontroluje, zda se tam nachází konfigurační soubor pro aktuální větev,

3) zmodifikuje soubor instalovaného projektu obsahující URL repozitáře pro závislé projekty a přidá k nim specifikace větve (volba „dependency_links“ v setup.py),

4) spustí znovu instalaci závislostí daného projektu.

Tento postup není ideální, protože se dané prostředí vytváří dvakrát, ale v současné době pro nás asi neexistuje lepší řešení. Naše interní projekty nejsou umístěny v PyPi a jsou tedy instalovány přímo přes URL repozitářes pomocí přepínače „–process-dependency-links“.

Celá implementace hooku pak vypadá následovně:

@hookimpl def tox_testenv_install_deps(venv, action): """Parse dependency links and update dependencies.""" if not os.path.isfile(venv.envconfig.dep_links): return None action.setactivity('PR-VERSION', 'parse version depencencies') tmp_dir = mkdtemp(prefix='pr-version-') try: action.setactivity('PR-VERSION', 'git clone') action.popen(['git', 'clone', 'git@gitlab.office.nic.cz:pr-utils/pr-version.git', '--depth', '1', tmp_dir]) action.setactivity('PR-VERSION', 'parse dependency links {}'.format(venv.envconfig.dep_links)) # Make a copy of dep_links copy(venv.envconfig.dep_links, tmp_dir) update = parse_deps(venv, venv.envconfig.dep_links, action, tmp_dir) if update: action.setactivity('PR-VERSION', 'dependencies changed - running sdist again') # This will recreate the package according to the settings and tox params venv.session.get_installpkg_path() # Replace the modified dep_links from backup copy(os.path.join(tmp_dir, venv.envconfig.dep_links), venv.envconfig.dep_links) finally: rmtree(tmp_dir)

Veškerá práce se zjišťováním aktuální verze a přepisováním konfiguračního souboru je bohužel natolik specifická, že je zbytečné ji zde uvádět. Závisí dost značně nejen na struktuře projektu jako takového, ale i na tagovacích a releasovacích zvyklostech projektů.

Shrnutí

Celkově jsme s použitím projektu Tox pro sjednocení vývojových prostředí velmi spokojeni a postupně na testování pomocí Tox přecházíme se všemi projekty. Za hlavní výhody považujeme jednoduchou rozšiřitelnost na další prostředí, reprodukovatelnost prostředí a komplexní správu sestavovací matice.

Kategorie:

Kolektor DNS provozu

St, 06/27/2018 - 09:45

Vydáváme dns-collector, vstupní část našeho systému pro monitorování a analýzu provozu našich DNS serverů. Spolu s pokročilou analýzou shromážděných dat můžeme nejen sledovat provoz DNS a detekovat naléhavé problémy, ale také zjišťovat a zkoumat dlouhodobé trendy a problémy (například nesprávnou konfiguraci vnějších serverů). Tento systém jsme prezentovali už na konferenci IT 15.2 (video a prezentace v češtině).

Kolektor je první částí analytické pipeline, sleduje provoz DNS a vytváří předzpracovanou formu dotazů vhodných pro efektivní archivaci, transport a další analýzy. Požadavky jsou párovány s odpověďmi podle IETF draftu, kolektor podporuje několik rozšíření EDNS, výstupy jsou buď CSV nebo datové struktury CBOR. Kolektor podporuje BPF filtry, volbu sbíraných atributů, kompresi a rotaci výstupních souborů a samozřejmě podporují offline zpracování PCAPů. Pro efektivitu je kolektor napsán v C nad knihovnou libknot (součást serveru Knot DNS) a spolehlivě zvládne více než 100 000 dotazů za sekundu. Můžete jej spustit buď přímo na serveru DNS nebo na vyhrazeném serveru s port-mirroringem.

Dns-collector vydaný pod GPLv3 najdete na našem githubu a jako hotové balíčky pro Ubuntu, Debian a další v OpenBuildService repozitáři.

Kategorie:

Olomouc hostila 40. ročník soutěže Středoškolská odborná činnost

Út, 06/26/2018 - 09:56

V neděli 17. června jsem měla možnost být v Olomouci na slavnostním vyhlášení vítězů 40. ročníku celostátní přehlídky Středoškolské odborné činnosti. Sdružení CZ.NIC podporuje tuto akci již pátým rokem a i po těch letech se nestačíme divit, co se najde za talenty mezi dnešními středoškoláky. Ale vezměme to od začátku, protože než se studenti probojují na celostátní přehlídky, čeká je dlouhá cesta.

Máte pocit, že jste o Středoškolské odborné činnosti (SOČ) nikdy neslyšeli? Nevadí, pojďme si jí představit. Jedná se o soutěž pro středoškolské studenty, kterou pořádá Národní institut pro další vzdělávání. Její historie sahá až do roku 1978. Účastí v soutěži dostanou studenti možnost si v praxi vyzkoušet, co obnáší vědecká činnost nebo psaní a obhajoba odborné práce, mohou zjistit, jak by je bavil vybraný vysokoškolský obor a pokud se někteří umístí na předních místech, mají šanci tím začít vědeckou kariéru. Vyhlašované obory jsou vždy z přírodovědné, humanitní a technické oblasti, takže si každý najde to svoje. Jak jsem naznačila v úvodu, než jsou vyhlášení ti nejlepší z nejlepších, čeká středoškoláky dlouhá cesta, která trvá od února do června, a to nepočítám samotnou tvorbu práce, která tomu všemu předchází. Nejprve studenti se svou prací účastní tzv. školní přehlídky. Z ní vzejdou jedinci, kteří postoupí do okresní přehlídky a odtud ti nejlepší putují na krajskou přehlídku. Vítězové z krajských kol se pak utkají na celostátní přehlídce, která vrcholí slavnostním vyhlášením.

Celostátní přehlídka je putovní a koná se vždy v jiném městě v rámci České republiky a nad jejím konáním přebírá záštitu jedna z místních škol. Pro 40. ročník byl vybrán Olomouc a hostování se ujalo Slovanské gymnázium v čele s ředitelem Radimem Sloukou. Slavnostní vyhlášení vítězů se pak odehrálo na půdě Moravské vysoké školy Olomouc.

Když jsem vešla do auly, panovala tam atmosféra plná očekávání a lehké nervozity. Kdo se asi stane vítězem jednotlivých oborů? Pro 40. ročník byly vyhlášeny tyto obory: matematika a statistika, fyzika, chemie, biologie, geologie, geografie, zdravotnictví, zemědělství, potravinářství, lesní a vodní hospodářství, ochrana a tvorba životního prostředí, strojírenství, hutnictví, doprava a průmyslový design, elektrotechnika, elektronika a telekomunikace, stavebnictví, architektura a design interiérů, tvorba učebních pomůcek, didaktická technologie, ekonomika a řízení, pedagogika, psychologie, sociologie a problematika volného času, teorie kultury, umění a umělecké tvorby, historie, filozofie, politologie a ostatní humanitní a společenskovědní obory a informatika.

Konečně zazněla slavnostní fanfára a přistoupilo se k vyhlašování a předávání cen. Vše šlo jako po másle, až jsme najednou byli u oboru s číslem 18 – Informatiky. Při této kategorii dávám vždy největší pozor, protože si kladu otázku, jestli někdo z těchto studentů nebude náhodou za pár let pracovat u nás v CZ.NIC. Kdo ví, jestli se v budoucnu na chodbě nepotkám s Antonínem Říhou, Ivem Meixnerem nebo Danielem Krejčím, kteří letos uspěli na předních příčkách.

Antonín Říha se umístil na třetím místě s prací „Implementace a rozbor algoritmu NEAT pro problémy reinforcement learningu“. Cílem práce bylo prozkoumání teoretických východisek pro použití genetických algoritmů na problémy reinforcement learningu a jejich následná implementace. Antonín aplikoval NEAT algoritmus, pro který navrhl vlastní rozšíření a prozkoumal jeho schopnosti pomocí experimentů. V praktické části došlo na samotnou implementaci a na vytvoření prostředí pro další vývoj. Výsledkem bylo, že nové rozšíření algoritmu NEAT je dobrou alternativou pro některé domény.

S prací „Hlasový asistent TERMIX“ uspěl na druhém místě Ivo Meixner. Ve své práci se zabýval hlasovým asistentem a ovládáním počítače pomocí hlasu. Záměrem bylo navrhnout a naprogramovat takový počítačový program, který by běžnému uživateli umožnil ovládat počítač pomocí hlasových příkazů. K dosažení cíle použil Ivo programovací jazyk C#, platformu Microsoft .NET Framework, vývojové prostředí Microsoft Visual Studio a systém pro převod hlasu na text Google Speech API. Výsledkem hlasového asistenta je možnost ovládat hlasem webový prohlížeč, psát text, dále může sloužit k vyhledávání informací na Internetu a přehrávat videa na YouTube.

A konečně celorepublikovým vítězem se stal Daniel Krejčí, který se ve své práci s názvem „Lovci perel“ věnoval vývoji webového informačního systému pro stejnojmennou hru. Tu již provozují knihovny a školy po celé České republice. Podnětem pro vznik systému byla neexistence centrální správy hry bez možnosti prezentace projektu veřejnosti. Nový systém přenáší správu hry do internetové podoby. Přínosem pro knihovny a školy jsou nové možnosti organizace, čtenáře informuje o jejich čtenářské aktivitě a veřejnosti nabízí jednotný a ucelený pohled na projekt, jeho funkcionalitu a přináší jednodušší možnost registrace. Daniel použil k napsání jádra projektu PHP za pomoci MVC frameworku CodeIgniter. Výstup je posílán do prohlížeče uživatele v HTML, CSS a JavaScriptu. Nebyla opomenuta ani bezpečnost, která zajišťuje aktivní obranu před SQL injection, Brute force attack a Cross-site scripting.

Vítězové této kategorie uzavřeli 40. ročník Středoškolské odborné činnosti, vše, co mělo být rozdáno, se rozdalo a byl čas, aby zazněla opět fanfára a my jsme se mohli rozjet do svých měst. Při odchodu jsem nemohla myslet na nic jiného, než že jsem měla opět možnost stát na pódiu ve společnosti skromných, mladých, nadějných lidí, kteří s nesmělostí přebírali své diplomy a ceny. Nemohli uvěřit, že vyhráli a že jejich snažení mělo kýžený výsledek. Nejvíc mě překvapuje, že bych čekala sebevědomé a průbojné jedince, ale opak je pravdou. V mnohých očích byla vidět nevěřícnost, radost, zklamání, ale také odhodlání se účastnit další rok. I já doufám, že budu mít možnost u toho opět být. Takže snad na shledanou příští rok v Opavě.

Kategorie:

Novinky v oblasti školních webů – sCOOLweb 2018

So, 06/16/2018 - 07:10

Ve středu 6. června proběhla na pražském magistrátu konference o školních webech sCOOLweb. Čtvrtý ročník konference, kterou tradičně pořádá informační centrum o vzdělávání  EDUin, o. p. s., se nesl v duchu tématu GDPR. Na konferenci byly vyhlášeny nejlepší školní weby v kategoriích úplně či neúplně organizovaných základních a středních škol.

Sdružení CZ.NIC se soutěže účastní téměř každý rok v roli hodnotitele. Letošní ročník měl za cíl přinést auditoriu z řad ředitelů, učitelů a správců školních webů důležité informace ke správnému nakládání s osobními údaji. K GDPR nicméně padly i lehce úsměvné příběhy z praxe. Vyučující Zdeněk Heteš (ZŠ Mládežnická, Trutnov), Václav Fišer (ZŠ Komenského, Trutnov) ze dvou trutnovských škol vyprávěli o tom, jak se ocitli na tenkém ledě, když se rozhodli založit každému žákovi své školy e-mailové adresy obsahují jméno a adresu v cloudu.

Středoškoláci pomáhají testovat bezpečnost školních webů

Přestože EDUin nechal vypracovat poměrně detailní návod, jak správně vést školní web, stále spousta školních webů nedokáže dodržet bezpečnostní kritéria. Proto mě velmi zaujal aplikovaný projekt, který středoškolské studenty vtahuje do problematiky penetračních testů webových stránek. Katka a Rostislav, studenti SŠIS Dvůr Králové nad Labem a Marek Hencl z firmy AARTKOM na konferenci hovořili o společném aplikovaném projektu odborné firmy a střední školy. Principem nástroje je skenování stránek školy, kde se sleduje komunikace, zabezpečení a ochrana dat. Pro zadavatele je následně zpracována závěrečná zpráva s doporučením, jak lépe zabezpečit web a ochránit soukromí uživatelů. Že by doplnění k našemu projektu Skener webu?

Výsledky

A jak to letos všechno dopadlo? První místo v kategorii škol tvořených pouze třídami prvního stupně získala Škola Na Pohodu Hodonín, z plně organizovaných škol pak ZŠ Čelákovice. V kategorii středních škol zvítězila SŠ polytechnická Brno.
Soutěž, která je pro školy zdarma, probíhala od letošního dubna ve dvou kolech. Nejprve weby posuzovali hodnotitelé nominovaní samotnými školami, ve druhém kole mezi 30 finalisty rozhodovala odborná porota. Souběžně s tím probíhalo i online hlasování veřejnosti.
Počet zájemců o soutěž každý rok stoupá. Největší zájem o zpětnou vazbu na školní webové stránky mají střední školy, které mají nouzi o studenty. Ty jsou také schopny nejvíce investovat čas i peníze do své webové prezentace i uživatelského výzkumu.

Kritéria, podle nichž jsou školní weby hodnocené, sledují pestré spektrum ukazatelů, vítězí školní webové stránky od profesionálů, rodičů i učitelů či ředitelů. Důraz je kladen na přehlednost informací, autentické fotografie, uživatelsky přívětivý a propracovaný obsah i bezpečnost.
EDUin se soutěží snaží eliminovat nejčastější nešvary školních webů. Například, že stále spousta školních webů neběží správně na mobilních zařízeních a na některých nedohledáte ani kontakt na ředitele. Případně je kontakt na důležité osoby směřován na jejich soukromé adresy, což může působit nedůvěryhodně a znamenat bezpečnostní rizika. Co se týká obsahu, nejhorší ze všeho jsou dlouhé nestrukturované texty ve formě různých vyhlášek.

Výsledky sCOOL web 2018

Kategorie A (neúplně organizované ZŠ)
1. místo: Základní škola Na Pohodu
2. místo: Základní škola SMART š.p.o.
3. místo: Základní škola Navis

Kategorie B (plně organizované ZŠ)
1. místo: Základní škola Čelákovice, Kostelní 457, příspěvková organizace
2. místo: Základní škola a mateřská škola Proseč
3. místo: Základní škola a Mateřská škola Emy Destinnové

Kategorie C (střední školy)
1. místo: Střední škola polytechnická Brno, Jílová, příspěvková organizace
2. místo: Masarykova střední škola Letovice, příspěvková organizace, Tyršova 500/6
3. místo: Gymnázium Vincence Makovského se sportovními třídami Nové Město na Moravě

Cena veřejnosti
1. místo: Základní škola Čelákovice, Kostelní 457, příspěvková organizace (1426 hlasů)
2. místo: Základní škola a mateřská škola Proseč (466 hlasů)
3. místo: Základní škola Navis (353 hlasů)

Loni v této soutěži nejvíce zaujaly školy v Praze, Deblíně a Vysokém Mýtě. Ráda bych ještě vyzdvihla ZŠ Deblín, na jejímž webu se silně podíleli rodiče a žáci. Je vidět, že webové stránky při troše dobré vůle mohou fungovat jako společný projekt rodičů, dětí a učitelů. Bohužel takováto spolupráce je zatím stále velmi osamělá vlaštovka.

Kategorie:

V oblasti kybernetické bezpečnosti na středních školách máme co dohánět

Pá, 06/01/2018 - 10:15

Není pochyb o tom, že studenti středních škol využívají informační a komunikační technologie úplně stejně běžně jako zubní kartáček. Bohužel pokud dojde na téma bezpečnosti, je skutečně co zlepšovat. To prověřil již druhý ročník Národního finále Středoškolské soutěže České republiky v kybernetické bezpečnosti.

Národní finále organizovala pracovní skupina kybernetické bezpečnosti AFCEA ve spolupráci s celou řadou státních, akademických a profesních organizací. Do národního finále postoupilo celkem 36 studentů z 26 středních škol z celé České republiky, a to po předchozích dvou kolech, kterých se zúčastnilo více než 3 000 soutěžících. Pro představu, v ČR je zhruba 425 000 studentů středních škol. To znamená, že necelé jedno procento českých studentů se zúčastnilo soutěže, díky které mohou nalézt okamžité uplatnění ve velmi důstojně placených zaměstnáních nebo značnou podporu vlastního podnikání. Důkazem tomu je partnerství mnoha velkých firem.

Naše sdružení využilo bohatého doprovodného programu k prezentaci projektu podpořeného Ministerstvem vnitra, díky kterému mohou instituce veřejné správy do konce června žádat o bezplatnou výpůjčku routeru Turris Omnia.

No a jak to celé probíhalo a jak to vlastně dopadlo? Ve dvoukolovém finálovém klání řešili studenti celkem 23 úloh různého stupně obtížnosti, z nichž prvních dvacet úloh řešili individuálně a následující tři úlohy byly týmové a řešilo je již pouze 24 postupujících studentů.

Nejlépe se dařilo soutěžícímu Ondřeji Blehovi z Gymnázia Boženy Němcové v Hradci Králové, hned za ním se umístil Břetislav Hájek z Gymnázia v Českém Brodě a trojici oficiálně nejlepších českých etických hackerů uzavřel Ondřej Tesař. Národním kolem soutěž ještě nekončí, 15 nejlepších studentů se v průběhu léta bude ucházet o možnost jet na Evropské finále v kybernetické bezpečnosti, které se koná v říjnu v Londýně. Studenti budou vybráni nejen na základě svých technických znalostí, ale i na základě komunikačních, prezentačních a sociálních dovedností.

Do soutěže bylo zapojeno téměř 300 škol, na kterých proběhla řada přednášek a diskusí, jichž se zúčastnilo téměř 10 000 studentů a 500 učitelů. Soutěž má tedy kromě uplatnění a rozvoje talentů i značný osvětový charakter. Do dalších let tedy přejeme organizátorům, aby počet soutěžících pořádně rostl.

Kategorie: