Hosting

Přihlášení

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

Jaký byl #TurrisHack17 ?

Út, 07/18/2017 - 07:50

Od počátku projektu Turris jsme velmi rádi, že můžeme úzce spolupracovat s komunitou. Bez ní bychom s projektem ani zdaleka nebyli tam, kde jsme. Byl to z nemalé části i zájem potenciálních uživatelů, který nás postrčil ke kampani na Indiegogo a byla to opět z velké části komunita, která umožnila kampani stát se úspěšnou. Tento úspěch nám také pomohl komunitu uživatelů výrazně zvětšit a rozšířit z České republiky do světa.

V jednom z rychlých sprintů kampaně jsem přišel do Turris týmu a od té doby se snažím celý produkt a jeho vývoj komunitě přiblížit. Ideální to zatím jistě není, ale dětské krůčky nás pomalu opět sbližují. Čistíme a vylepšujeme fórum, pilujme a doplňujeme dokumentaci, otevíráme nové komunikační kanály; jezdíme po konferencích a open source setkáních, kde potkáváme mnoho nových Turris nadšenců a navazujeme zajímavá a významná partnerství. O tom všem ale až příště. Dneska bych Vám rád pověděl o prvním Turrisím hackathonu, který jsme pořádali. Střípky z něj můžete najít na Twitteru pod #TurrisHack17.

Prvotní myšlenky hackathonu byly dvě. Sblížení se s komunitou a navázání kontaktu s její vývojářskou částí. Open source je přece i o společné práci na kódu. Chtěli jsme dát komukoliv šanci přidat si do routeru to své a sdílet to s dalšími uživateli.

Vzhledem k tomu, že jsme hackathon jako Turris tým nikdy předtím nepořádali, využili jsme zkušeností posbíraných účastmi na podobných akcí a obrovského know-how týmu naší Akademie CZ.NIC z pořádání konferencí, školení i méně formálních akcí. Přesto jsme se rozhodli první setkání koncipovat spíše jako menší, „rodinné“ a na domácí půdě, naopak s veškerým servisem.

Sešli jsme se tedy 16. června v 15:30 a po krátkém úvodním seznámení se členové Turris týmu vývojářům z komunity pokusili přiblížit dvě důležité části vývoje pro routery Turris – jak pro Turris balíčkovat a jak vytvářet pluginy pro jeho webové rozhraní Foris. Obě přednášky kolegů Michala Hrušeckého a Štěpána Henka budete již brzy mít k dispozici na YouTube, v češtině s anglickými titulky.

Následovala pauza na kávu, diskuze o projektech a rozdělení do týmů. To proběhlo následnovně:

Tým Bigclown s jasným záměrem zlepšení podpory HW a integrace dat BigClown do Forisu. K HW vývojářům Karlovi, Pavlovi a Danovi přímo z firmy BigClown se přidal Jirka, který jim výrazně pomohl s front-endem.

UPS tým s cílem vyvinout unikátní záložní zdroj pro Omnii plně komunikující s routerem reprezentovaný odhodlaným bastlířem a učitelem informatiky Jardou a Turris vývojářem Karlem

– Dlouholetý fanoušek Turrisu, zkušený Pythonista a Linuxák Jethro se rozhodl částečně spolupracovat s UPS týmem, ale především zprovoznit na Omnii low-cost bezdráty NRF24L01

– Tým jednoho z dlouhodobě nejaktivnějších členů komunity a Linux admina Ondry s vrchním balíčkářem Turris OS Michalem se odhodlal k portaci Btrfs a nástroje schnapps pro Turris 1.x

– Martin se zkušenostmi s Pythonem, Djangem i Javascriptem připravoval obsluhu připojování disků ve Forisu

 

Stylově v 18:18 jsme odstartovali 24 hodin vývoje, během nichž jsem se snažil hodně reportovat na Twitteru. Nápadů na řešení bylo v každém týmu nemálo, přesto všichni začali s psaním kódu velmi rychle. Jarda překvapil, když se své malé brašny krom součástek a olověných baterií začal tahat také pájku a nemálo dalšího nářadí. Bylo velmi hezké sledovat, jak na Turrisím hackathonu krásně rezonuje jedno z našich hesel: „Miluji hardware“. To ostatně můžete vidět i ve fotogalerii.

Jak postupovaly hodiny, byla chvílemi znát i mírná únava. Někdo si na chvíli schrupnul, jiní se šli proběhnout noční Prahou kolem Olšanských hřbitovů. Dle referencí skutečný zombie run. Hlavní tažnou silou byly nápoje Club Maté a především Carcara Fizz. Netradiční a přírodní „energiťák“ fungoval dle ohlasů mnohem lépe, než RedBully a podobné. Asi nezvyk.

Nad ránem už se nám začaly reálně vykreslovat obrysy vývojářské práce a s postupem dne stále vládla dobrá nálada, atmosféru jsme se snažili doplňovat i vhodnou a tématickou hudbou. Znáte třeba SUSE písně? Samozřejmostí byl neustálý přísun jídla a pití, protože výkonný vývojář toho prostě spořádá hodně.

Pár hodin před koncem jsem očekával mírnou paniku, že se projekty nestihnou dotáhnout, ale nic takového nenastalo. Nakonec všichni dokončili s přehledem půl hodiny před limitem. A to se nekladli zrovna malé cíle!

Klauni udělali obrovský kus práce a propojení jejich HW s Omnií bude brzy o poznání jednodušší. Až téměř nemožný úkol v podobě portace Btrfs a snappsu na zasloužilé Turrisy se velmi povedl, díky přesunu filesystemu na microSD kartu chytli naše původní routery další dech. A rozhodně ne poslední! Za velmi zajímavé částky si budete moci postavit speciální UPS, která umí notifikovat ve Forisu i mailem o změnách napájení či potřebě nabití, a domácí automatizaci na standardu NRF24L01. Jednoduché ovládání připojování úložišť pak bude příjemným usnadněním každodenního použití routerů Turris.

Po prezentaci povedených děl jsme se odebrali na večeři a krátké uvolněné povídání o výsledcích do nedaleké restaurace. Jednoho by až překvapilo, jak krásně kreativní dokáží všichni být po úspěšném dokončení úkolu přesto, že za sebou mají více než 24 hodin práce.

Co jsem si tedy nejen já odnesl z prvního Turris hackathonu?

Že rozhodně nebyl posledním a brzy uděláme další, tentokrát větší a ideálně mezinárodní. S největší pravděpodobností opět nesoutěžní, protože atmosféra se nám povedla vytvořit velmi dobrá a rádi bychom ji zopakovali. Zpřesníme odhady pití i pochutin a nezapomeneme si připravit i na příště něco speciálního a netradičního. Připravíme více místa pro power-napy. Více zapracujeme na propagaci celé akce a lépe se rozhlédneme v kalendáři, abychom našli termín nekolidující s jinou open source akcí. Tentokrát jsme trefili OSS víkend v Bratislavě a už se nedalo nic moc změnit. Především pak urychlíme a zjednodušíme předávání výsledků práce a jejich poskytnutí všem uživatelům. Na většinu ze zmíněných se můžete těšit v následujících týdnech v Turris OS 3.8. Návody budou také postupně vyskakovat ve wiki.

Ještě jednou bych rád poděkoval všem účastníkům, byli jste úžasní! Obrovský dík přidávám znovu i vývojářům z Turris týmu, kteří si významně protáhli pracovní den, aby byli účastníkům nápomocní, a také týmu Akademie CZ.NIC. Bez jejich pomoci bychom to nezvládli.

Routeru zdar a věřím, že se uvidíme na příštím hackathonu!
#WeBelieveInOpenSource

 

Kategorie:

Co má společného Postel, IETF a dnešní Internet

St, 07/12/2017 - 09:55

Ve dnech 16. – 21. července 2017 se v Praze bude konat konference IETF 99. O tom, co IETF je a jak funguje, už dřív česky psal můj kolega Ondřej Surý ve svých článcích Cesta do hlubin IETFOdkud pochází Internetové standardy (aneb bylo jednou jedno RFC) nebo Vrána k vráně sedá aneb koťátka, dogy a nápoje v IETF. Ladislav Lhotka zase trefně popsal její neobvyklou geekovskou atmosféru. Proto stačí uvést, že IETF je organizace vydávající internetové standardy. Jejím cílem je vytvářet kvalitní technickou dokumentaci, která ovlivňuje vývoj Internetu a aplikací přes něj provozovaných.

Mezi výsledky práce IETF patří např. standardizace SMTP protokolu pro přenos e-mailu i protokolu HTTPS, přes který nejspíš čtete tento článek. Myšlenkově ale IETF ovlivnilo svět počítačových sítí mnohem více. Uživatel nevědomky ocení, například když jeho webový prohlížeč správně zobrazí i takové HTML stránky, u nichž autor zapomněl uzavřít párový tag jako je např. „<body>“ pomocí uzavíracího „</body>“. Stejně tak poštovní servery běžně doručují e-maily, přestože DNS informace o doručovacím serveru je v rozporu se standardem. Toto je například možné díky široké aplikaci tzv. Postelova principu, jednoho ze základních principů, pomocí kterého se interpretují internetové standardy.

Princip je pojmenován po Jonu Postelovi (1943–1998) a objevil se v roce 1981 ve standardu pro Internet Protocol (to je „ten“ protokol, co dnes všichni bezmyšlenkovitě zkracujeme jako IP). Postelův princip říká: „Implementace musí být konzervativní při odesílání a liberální při příjmu.“ (v originálu: „an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.“).

V roce 1981, když byl Internet ještě v plenkách, bylo cílem Postelova principu usnadnit propojování systémů různých výrobců stanovením odlišných kritérií pro odesílání a příjem paketů. Při odesílání by měl systém produkovat pakety formátované konzervativně, tj. podle standardu. Naopak při příjmu by implementace měla „přimhouřit oko“ a akceptovat i takové pakety, které sice nejsou technicky na 100 % správně, ale je z nich stále zřejmé, co paket znamená.

Tento princip byl ze standardu IP přejat a široce aplikován i na implementace ostatních protokolů, se kterými se každodenně setkáváme. Příkladem jeho aplikace je už zmíněné zobrazení HTML stránky navzdory chybějícímu tagu „</body>“ (důkaz: zde).

Vypadá to jako jasná výhra pro uživatele i Internet jakožto síť sítí: Vše funguje, všichni jsou spokojení. Nebo snad nejsou?

Postelův princip má i odvrácenou stranu, se kterou se setkávají hlavně vývojáři, kteří se snaží držet přikázání a být liberální při příjmu. Potíže pramení z toho, že princip samotný odkazuje na to, „co paket znamená“, bez ohledu na jeho formální správnost. To staví vývojáře před nelehký úkol najít nějaký význam v paketu, jehož formát není popsaný.

Ilustrujme si to na DNS protokolu: jeho standardizovaná verze umožňuje DNS serveru odeslat v odpovědi více informací najednou:

Dotaz klienta může vypadat třeba takhle:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20394
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 6
;; QUESTION SECTION:
nic.cz.                  MX

Standardní paket s odpovědí serveru vypadá následovně:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 111
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 6
;; QUESTION SECTION:
nic.cz.                  MX

;; ANSWER SECTION:
nic.cz.        1800      MX     10 mail.nic.cz.
nic.cz.        1800      MX     20 mx.nic.cz.
nic.cz.        1800      MX     30 bh.nic.cz.

;; ADDITIONAL SECTION:
bh.nic.cz.     1800      A      217.31.204.252
mail.nic.cz.   1800      A      217.31.204.67
mail.nic.cz.   1800      AAAA   2001:1488:800:400::400
mx.nic.cz.     1800      A      217.31.58.56
mx.nic.cz.     1800      AAAA   2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019

Toť standard: jeden dotaz a jedna odpověď s více položkami.

A teď si představme, že program přijme paket s polem „dotaz“ obsahujícím (v rozporu se standardem) dvě položky:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2222
;; flags: rd ad; QUERY: 2, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
www.nic.cz.               A
www.nic.cz.               AAAA

Co tím odesilatel myslí? Tady začínají problémy, protože dva různí vývojáři si mohou pravidlo „být liberální při příjmu“ snadno vyložit jinak. První vývojář se rozhodne, že program odpoví jen na první ze dvojice dotazů, protože standard neříká, jak se odpovídá na dva dotazy najednou. Druhý si naopak řekne, že standard sice nepředepisuje formát odpovědi na dvě otázky, ale odesilatel dotazu asi chce v poli „odpověď“ mít informace ze všech dotazů, takže naskládá odpovědi za sebe do jednoho paketu. Třetí vývojář problém vyřeší rozdělením odpovědi na každou jednotlivou otázku do samostatného paketu, takže na jeden paket s dotazem pošle dva pakety s odpovědí.

Kdo z nich má pravdu? Vlastně nikdo, protože toto chování standard nedefinuje. Výsledkem je samozřejmě zmatek, protože se různé implementace chovají nekompatibilně.

Problém se vystupňuje, když se příslušná pracovní skupina pokusí rozšířit původní standard o podporu pro „více dotazů najednou“, kterou ale mezitím vývojáři naimplementovali každý jinak. Žádná z implementací se nechce vzdát svého chování, typicky s odkazem na to, že „naši uživatelé jsou závislí na chování naší implementace, a proto ho nemůžeme změnit“. Takže úplně na konec buď vznikne standard, který ale téměř nikdo nedodržuje (protože se všichni drží vlastního vynálezu), nebo nový standard nevznikne vůbec, protože není možné dosáhnout ani hrubého konsenzu o jeho podobě.

Tímto způsobem „liberální” část Postelova principu vede k vytváření vzájemně nekompatibilních rozšíření, která znesnadňují další vývoj protokolu a v důsledku tak způsobují „zkostnatění“ prostředí na Internetu.

Rychlý vývoj Internetu a aplikací přes něj provozovaných zároveň vede k potřebě přizpůsobovat existující standardy a vytvářet nové. Aplikace Postelova principu na konkrétní problém je proto otázkou, které se žádná pracovní skupina v rámci IETF nemůže vyhnout. Vždy je nutné zvážit pro a proti: Má být konkrétní vlastnost protokolu pevně daná a striktně vyžadovaná, což může zpomalit či znemožnit jeho další vývoj? Nebo má určitá část protokolu záměrně zůstat volnější, otevřít dveře aplikaci Postelova principu a umožnit překotný vývoj za cenu rizika nekompatibilních rozšíření?

IETF má v současnosti 126 pracovních skupin a pole jejich působnosti je opravdu široké. Seznam a agendu všech pracovních skupin je možné najít zde, kde je také možné se zaregistrovat do e-mailové konference libovolné pracovní skupiny a přečíst si nejen, co se bude probírat na letošním, pražském IETF, ale také jak bude práce pokračovat dál. Tímto způsobem jsou pracovní skupiny otevřené komukoliv, kdo se v dané problematice vyzná a je ochoten jí věnovat čas.

Kategorie:

Turris spolehlivě a bezpečně připojil finále Národní soutěže kybernetické bezpečnosti

Čt, 07/06/2017 - 09:25

Finále Středoškolské soutěže České republiky v kybernetické bezpečnosti proběhlo 1. června 2017. Z celkového počtu 283 soutěžících z druhého kola soutěže se do finále probojovalo 29 soutěžících.

V prostorách mezinárodního veletrhu obranných a bezpečnostních technologií IDET řešili finalisté celkem pět reálných bezpečnostních scénářů. Jednalo se například o analýzu síťové komunikace, zranitelnost webové aplikace nebo prolomení složité šifry. Studenti byli pro řešení úkolů rozlosováni do šesti týmů, čímž byli nuceni i k blízké týmové spolupráci.

„Průběh soutěže prověřil naši schopnost týmové spolupráce, práci pod tlakem, zpracování nových informací a jejich aplikaci při řešení praktických úloh od kryptografie až po zapojování MESH sítě,“ uvedl Jakub Smejkal, výherce finálového kola soutěže.

Hodnocení soutěžících prováděl soutěžní výbor a po vyhlášení výsledků druhého kola soutěže, měli účastníci dokonce ještě sedm dní na to, aby výsledky připomínkovali. Organizační tým obdržel celkem jedenáct připomínek, sedm z nich bylo relevantních a nejen na tomto aspektu ukázali organizátoři soutěže svou otevřenost a schopnost přiznat a bezproblémově napravovat své chyby.

Vítězem prvního ročníku soutěže v kybernetické bezpečnosti se stal Jakub Smejkal ze Střední školy informatiky, poštovnictví a finančnictví v Brně. Tato škola se také stala celkově nejúspěšnější školou celorepublikového finále, a to nejen proto, že i na třetím místě se umístil její student, ale především díky tomu, že ve finále měla celkem pět zástupců, z nichž se hned čtyři umístili v první patnáctce finalistů. Další informace o umístění studentů naleznete zde. Škola byla vyhodnocena jako bezkonkurenčně nejúspěšnější a díky fantastické práci se studenty získala pro potřeby výuky jako odměnu od CZ.NIC router Turris Omnia.

„Tento vysoce výkonný open source router bude sloužit v praktickém vyučování žáků školy, zejména při výuce nového školního vzdělávacího programu Kybernetická bezpečnost, jehož pilotáž byla na naší škole potvrzena MŠMT (jako jedné ze dvou škol v ČR),“ řekl Roman Koláčný ze Střední školy informatiky, poštovnictví a finančnictví v Brně.

Router Turris Omnia také po celou dobu finále zajišťoval bezproblémové připojení k Internetu v jinak velmi zatížené hale. Hlavní organizátor soutěže Petr Jirásek jej ocenil především díky snadnému nastavení a možnosti přepínání jednotlivých frekvencí. Tato funkcionalita zajistila stabilní připojení pro všechny účastníky. Jedinou nevýhodou tak bylo, že studenti se na frekvenci 5 GHz z některých svých vlastních starších notebooků, které toto pásmo nepodporují, nemohli připojit. Pro účely soutěže byly však od Ministerstva práce a sociálních věcí zajištěny notebooky, které tento náročnější technický požadavek splňovaly.

Úspěšným a přínosným národním finálovým kolem však soutěž zdaleka nekončí. První tři finalisté postoupili automaticky do evropského kola soutěže v kybernetické bezpečnosti, které proběhne 30. října až 3. listopadu 2017 ve španělské Malaze.

Do evropské soutěže bude za Českou republiku nominován desetičlenný tým sestavený ještě navíc ze čtyř dalších finalistů, kteří budou vybráni na základě svého snažení a dosažených výsledků v rámci letní školy. Do desítky budou poté nominováni ještě tři další vysokoškolští studenti; toto umožňují pravidla pro soutěžní týmy z jednotlivých zemí. Sdružení CZ.NIC se díky projektu Safer Internet z velké části podílí na financování nákladů spojených s účastí českého týmu v této mezinárodní soutěži.

Závěrem ještě stojí za zmínku nevšední nakládání s osobními údaji – v rámci celé soutěže organizátoři velice dbají na soukromí soutěžících. Údaje studentů, s nimiž dále nekomunikují, nikde neshromažďují a jejich data dále nevyužívají. Účastníci prvního kola soutěže tak neobdrží ani e-mailovou notifikaci o plánovaném druhém ročníku soutěže a musejí si tak termíny druhého kola v případě zájmu hlídat sami. Souhlasy udělované k fotodokumentaci splňují podmínky velmi diskutovaného nařízení GDPR (ještě před jeho vstupem v platnost). Dá se tedy říci, že Národní soutěž v kybernetické bezpečnosti chápe oblast kybernetické bezpečnosti velice komplexně. Nejen, že je díky ní možné identifikovat mladé talenty, zvyšuje povědomí široké veřejnosti o hrozbách a rizicích kybernetické bezpečnosti, ale ještě navíc sami organizátoři jsou svým jednáním příkladem v oblasti ochrany dat a informací.

Kategorie:

Datovka – rozhraní pro spisové služby

Út, 07/04/2017 - 09:35

Datovka je multiplatformí desktopová aplikace pro přístup k datovým schránkám, která je vyvíjena sdružením CZ.NIC, a která umožňuje pohodlnou práci s datovými zprávami. Celkový počet datových schránek, ke kterým můžete současně z aplikace přistupovat, není omezen. Aplikace zároveň uchovává lokální kopie stažených zpráv i po uplynutí 90 dnů od doručení.

Postupem času se z Datovky stala aplikace, kterou kromě běžných „civilních“ uživatelů začali pro komunikaci s úřady nebo svými klienty používat také v malých kancelářích. Využívají ji kupříkladu OSVČ, účetní nebo také právníci. Všem uživatelům Datovky se postupně snažíme vycházet vstříc a podle jejich námětů nebo požadavků aplikaci upravujeme nebo do ní přidáváme funkce, které pokládáme za přínosné.

Začátkem letošního roku jsme byli kontaktováni společností SingleCase, která řešila problém, jak svým klientům zjednodušit ukládání datových zpráv do jimi provozované spisové služby. Zástupci SingleCase nás požádali, zda bychom Datovku nerozšířili o možnost zasílat datové zprávy do jejich úložiště.

Protože vyvíjíme Datovku jako open source aplikaci, která je všem uživatelům poskytována zdarma, nechtěli jsme vytvářet řešení, které by vyhovovalo pouze jednomu konkrétnímu subjektu. Se SingleCase jsme se proto dohodli, že vytvoříme relativně jednoduché avšak dostatečně obecné rozhraní, které následně implementujeme a dokumentaci k tomuto rozhraní poté zveřejníme.

Komunikace mezi Datovkou a spisovou službou probíhá HTTPS kanálem. Uživatel se přihlašuje pomocí autentizačního tokenu, který si může vygenerovat ve webovém rozhraní spisové služby, nebo jej může obdržet jinak. Přenášená data jsou strukturována do JSON.

Navržené API poskytuje základní funkcionalitu pro získání názvu samotné spisové služby spolu s identifikátorem tokenu, který může sloužit k jeho pohodlnější identifikaci, a logem spisové služby. Logo spisové služby je kupříkladu v současnosti používáno k indikování stavu, že datová zpráva se ve spisové službě nachází.

Dotazem na hierarchii dokumentů je možné získat odpověď se seznamem možných umístění ve spisové službě, kam se můžou datové zprávy nahrávat. Další funkcí je možné do zvoleného místa v obdržené hierarchii nahrát soubor datové zprávy. Poslední funkcí je dotaz na existenci konkrétních datových zpráv ve spisové službě, která se hodí v případě, že chcete synchronizovat lokální informace o umístění datových zpráv ve spisové službě.

Provozovatelé spisových služeb, či jiných úložišť dokumentů, mohou uvedené API implementovat a získat tak možnost používat Datovku k nahrávání datových zpráv. V průběhu vývoje jsme vytvořili malou testovací aplikaci v Qt (bez dalších závislostí), která je součástí stromu zdrojových souborů a která slouží pouze k ověřování komunikace se spisovou službou. Více informací k API nebo k novým funkcím naleznete na domovské stránce a wiki stránkách projektu.

Jako vždy také děkujeme všem uživatelům Datovky za hlášení chyb a nápady, které zasíláte na adresu datove-schranky@labs.nic.cz.

Kategorie:

Cenu veřejnosti za nejlepší školní web vyhrála Základní škola Pardubice-Polabiny

Po, 06/26/2017 - 20:20

Letošní ročník soutěže sCOOL web, organizované společností EDUin, přinesl mnohá překvapení. Některé školy na základě informací získaných v minulých ročnících soutěže radikálně přepracovaly své webové stránky a umístily se na předních příčkách soutěže. Organizátory to utvrdilo v názoru, že tato soutěž má smysl. Nejvíce oceňované webové stránky vznikly za spolupráce rodičů, učitelů a dětí z dané školy. Jen tak dále!

Pozornost porotců byla zaměřena na informační systémy. Mnoho škol již využívá Internet jako jednu z podstatných forem výměny informací s rodiči. Na stránkách pod zabezpečeným přístupem (heslem) si může každý rodič i žák hledat klasifikaci, elektronickou třídní knihu, absenci nebo získávat od školy rychle a operativně důležitá sdělení. Hodnotitelé nakonec zveřejnili statistiky s užíváním školních informačních systémů.  Nejvíce zastoupené byly Bakaláři, Škola OnLine a iŠkola.

Vzhledem k publikaci dokumentů právní povahy na webu (např. Školní řád) je pro školy velmi aktuální nařízení Evropského parlamentu a Rady (EU) č. 910/2014 o elektronické identifikaci a službách vytvářejících důvěru pro elektronické transakce na vnitřním trhu a o zrušení směrnice 1999/93/ES. S přednáškou na toto téma vystoupil na konferenci Jiří Průša z CZ.NIC. Nařízení vedle oblasti elektronického podpisu eIDAS rozšiřuje regulaci i na nové oblasti, zejména přeshraniční uznávání elektronické identifikace či webové certifikáty. V České republice se s eIDASem pojí dva klíčové zákony – č. 297/2016 Sb., o službách vytvářejících důvěru pro elektronické transakce upravující tzv. důvěryhodné služby a připravovaný zákon o elektronické identifikaci. Celou přednášku si můžete přečíst zde.

Soutěž sCOOL web probíhá celkem ve třech kategoriích odborné poroty – bližší popis, jak přesně probíhá, najdete zde.

Organizátoři a hodnotitelé, stojící za soutěží sCOOL web, se snaží být pro všechny tvůrce školních webů důležitým zdrojem informací. Na závěrečné konferenci mohli účastníci slyšet třeba Jana Řezáče, který u každé stránky položil otázku: Kdo jsme, co děláme a proč by mě to mělo zajímat… a hledal na ně odpovědi. Ben Olšanský zopakoval návod, jak napsat efektivní text. Jsou to často drobné změny, co může mít dopad na atraktivitu vašeho školního webu. Doufám, že pomocí těchto drobných krůčků budou školní weby lepší každým rokem. Jsem ráda, že i letos byl partnerem akce CZ.NIC. Myslím, že nejen ohledně eIDASu u nás školy najdou rady, kterých se jim často nedostává. Zajímavé by bylo také udělat analýzu bezpečnosti školních webových stránek, kterou CZ.NIC nabízí bezplatně školám prostřednictvím služby Skener webu.

Výsledné pořadí:

Kategorie A – ZŠ neúplně organizované
1. místo: ZŠ Duhovka
2. místo: ZŠ Smart
3. místo: ZŠ a MŠ Stehelčeves

Kategorie B – ZŠ plně organizované
1. místo: ZŠ a MŠ Deblín
2. místo: ZŠ a MŠ Mirovice
3. místo: ZŠ a MŠ Na Beránku

Kategorie C – střední školy
1. místo: VOŠ a SŠ stavební Vysoké Mýto
2. místo: SŠ a Podorlické vzdělávací centrum, Dobruška
3. místo: Gymnázium Jana Keplera, Praha 6

Kategorie:

Jak by eIDAS mohl pomoci českým firmám na Slovensku?

Pá, 06/23/2017 - 09:36

Již za pár dní budou všem podnikatelům na Slovensku aktivovány elektronické schránky, představující obdobu našich datových schránek. Byť inspirace českým systémem se nezapře, minimálně jeden podstatný rozdíl zde je.

Zatímco k českým „datovkám“ se lze přihlásit jménem a heslem, na Slovensku je povinné přihlášení přes jejich elektronické občanky. V tuto chvíli tak pro přibližně 10 000 (dle některých odhadů až 12 000) českých podnikatelů nastává problém, jak se ke slovenské schránce dostat.

Pokud si odmyslíme získání slovenského občanství, další (a slovenskou vládou silně doporučovaná) možnost je prostřednictvím zmocněnce – slovenského občana, který místní e-občanku má. Poslední (a ne vždy zmiňovanou) možností je získání alternativního autentifikátoru umístěného na čipové kartě s omezenými možnostmi.

V tuto chvíli některé napadne, zda by nemohlo nějak pomoci Nařízení eIDAS. Celkem logicky by se nabízela možnost jednoduše propojit české a slovenské datovky. Oba systémy jsou dost podobné a počet českých firem na Slovensku i opačně celkem vysoký. eIDAS však v tomto případě bohužel mnoho nepomůže.

Ve čl. 43 a 44 sice existuje úprava elektronického doporučeného doručování (tzv. e-Delivery), na rozdíl od elektronického podpisu či elektronické identifikace však eIDAS u e-Delivery nevyžaduje povinné propojování či přeshraniční uznávání zpráv.

Co by však českým podnikatelům bezesporu pomoci mohlo, je vzájemné uznávání eID definované ve čl. 6:

„…Pokud se podle vnitrostátního práva nebo správní praxe pro přístup ke službě poskytované on-line subjektem veřejného sektoru v určitém členském státě vyžaduje elektronická identifikace s použitím prostředku pro elektronickou identifikaci a autentizace, je pro účely přeshraniční autentizace pro danou on-line službu uznán v tomto členském státě prostředek pro elektronickou identifikaci vydaný v jiném členském státě…“

Z dalších ustanovení eIDAS však vyplývá, že povinnost (přeshraničního) uznávání eID nastane nejdříve od 29. září 2018. I toto uznávání má však jeden zásadní háček. Vztahuje se pouze na tzv. ohlášené eID systémy a zatím jediný stát, který toto oznámení učinil, bylo na začátku letošního roku Německo.

V České republice byla sice před pár dny prezidentem podepsána novela zákona o občanských průkazech, který zavádí bezplatné občanské průkazy s čipem, avšak díky odložené účinnosti zákona si na tyto občanky ještě rok počkáme.

Naději na u snadnění přístupu českých podnikatelů ke slovenským elektronickým schránkám by mohl přinést zákon o elektronické identifikaci, který zřizuje tzv. Národní bod pro identifikaci a autentizaci (NIA). Tento systém by měl umožnit přihlašování nejen přes elektronické občanky, ale i přes další nástroje, např. mojeID.

Na použití pro přihlašování ke slovenským datovkám si však čeští podnikatelé přesto ještě počkají. Stejně jako novela zákona o občanských zákonech má i tento předpis odloženou účinnost, tentokrát pevně na 1. července 2018 a pak je zde min. 18 měsíční lhůta, která musí uplynout od prvního ohlášení systému (tzv. pre-notifikace) po zajištění uznávání v jiné zemi.

Pokud by se Ministerstvu vnitra podařilo podat pre-notifikaci do konce letošního roku, od druhé poloviny 2019 by se již čeští statutáři měli mít možnost přihlašovat ke slovenským elektronickým schránkám svých firem českou e-občankou nebo doufejme i přes mojeID. Němečtí podnikatelé však budou mít díky aktivitě své vlády a podané notifikaci tuto možnost již od září příštího roku.

Kategorie:

Učiňme DNS opět velkým!

Út, 06/20/2017 - 10:38

Snad mi bývalý prezident USA Ronald Reagan odpustí, když si půjčím a trochu předělám slogan z jeho prezidentské kampaně. Ostatně tuším, že to tak dnes dělá poměrně mnoho lidí.

Není to tak dávno, co spravovat jednoduchou statickou doménu druhého řádu nebylo nijak náročné. Tehdy jste si na DNS serverech připravili zónový soubor a dopsali jste do něj jednotlivé záznamy. Pak jste pouze před svého registrátora poslali do nadřazené zóny informaci, na kterých DNS serverech že se ten zónový soubor skrývá. A pak už nebylo nutné dělat vůbec nic, tedy alespoň dokud nenastala nějaká změna. To bylo ještě před startem technologie DNSSEC. Tato nová technologie přinesla do ne příliš dobře zabezpečeného protokolu silné bezpečnostní mechanismy. Ale jak už to bývá, bylo to „něco za něco“. Bohužel u DNSSECu už není možné nechat vše jen tak běžet, je nutné občas přepodepsat DNS záznamy, občas změnit podepisovací klíče zóny (ZSK) a občas dokonce i klíče pro podpis klíčů (KSK). Bohužel ta poslední operace běžně vyžaduje ještě komunikaci s nadřazenou entitou (správcem nadřazené zóny, v našem příkladu správce domény nejvyšší úrovně, například CZ.NIC). Nové klíče je nutné předat bezpečnou cestou a to mimo protokol DNS. Každý správce zóny je tedy nucen čas od času něco udělat a to je pochopitelně zdrojem častých problémů. Asi největší komplikací bývá, když komunikace s registrem probíhá přes majitele domény, jenž ještě navíc není zrovna technicky zdatný. V takovém případě je to spíše problém neřešitelný.

Proto hledala DNS komunita cesty, jak tento problém vyřešit. Řešení je popsáno v dokumentech RFC 7344 a RFC 8078, které zavádějí nový mechanismus, jak přenášet informaci o použitých klíčích mezi správcem zóny a nadřazenou entitou bez nutnosti používat jakéhokoliv prostředníka. Velmi laicky řečeno, správce zóny vypublikuje speciální záznamy (CDS a CDNSKEY), které signalizují, jakými klíči je/bude zóna podepsána. Správce nadřazené domény si tyto záznamy stáhne a zajistí, že celý DNS strom bude dále fungovat včetně podepisování pomocí DNSSEC. Použitím tohoto mechanismu se celý problém výrazně zjednodušuje, především v případě, kdy se o doménu stará někdo úplně jiný než příslušný registrátor. Tento mechanismus v doméně .cz startuje právě dnes, více technických informací se brzy dozvíte na tomto blogu nebo ze záznamu vystoupení Jaromíra Talíře na konferenci IT 17. Nicméně pokud již ve své zóně máte CDNSKEY, měla by se Vám bezpečná delegace DNSSEC brzy sama zprovoznit.

Ani s tímto by ale nebylo DNS stejné jako dříve. Stejně by bylo nutné alespoň částečně starat o onu rotaci klíčů, což opravdu není zrovna jednoduchá záležitost a je velice snadné v tom udělat chybu, jak se již mnozí přesvědčili.

A proto jsme přišli i s další novinkou a tou je implementace automatické správy klíčů do našeho autoritativního DNS démona – Knot DNS, konkrétně do verze 2.5.0. Opět se více technických informací dozvíte v některém z dalších článků. Díky této novince už jen označíte u zóny, že se má podepisovat a rotovat klíče a o nic jiného se nestaráte. Složitost správy DNS se tedy vrátila na onu nízkou úroveň, již jsem popisoval na začátku tohoto textu. A tedy z tohoto pohledu se DNS stává opět velkým jako dříve!

Kategorie:

Zveme vás na Turris Hackathon

Čt, 06/01/2017 - 12:37

Výhodou routerů Turris je jejich otevřenost. Můžete si na ně doinstalovat vlastní balíčky, do kontejnerů i jiné systémy, doprogramovat si vlastní software. Nápadů mají naši uživatelé nepřeberně, ale jak začít? Skvělou příležitostí bude červnový hackathon, kdy se sejdou nadšenci do programování i tým Turrisu, aby v koderské čtyřiadvacetihodinovce do routeru doplnili to, na čem jim záleží.

Hackathon proběhne od pátečního odpoledne 16. června 2017 do soboty. Na jeho začátku proběhne zaškolení účastníků, jak sestavovat balíčky, programovat pluginy a vůbec detailně operovat ve vnitřnostech routerů Turris. K dispozici budou nejenom lidé z týmu Turris, ale také nápoje, občerstvení, internet, elektřina, relaxační zóna a další důležité propriety včetně kávovarů i možnosti nočního výběhu do Prahy. Nic tak nebude bránit realizaci některého z nápadů, které budou účastníky trápit a které si přinesou v zásobárně s sebou, nebo se nechají inspirovat na místě.

K účasti na hackathonu je potřeba vlastně málo: dorazit do Prahy na Jiřího z Poděbrad, vyznat se v Linuxu a pokud možno i Pythonu či některém z dalších jazyků používaných v routerech Turris. A mít chuť do trochy té práce.

Detailní informace o Turris Hackathonu včetně možnosti registrace (ta je zdarma) najdete zde.

Těšíme se na vás!

Kategorie:

Test škol: splňujete Standard konektivity?

Po, 05/29/2017 - 14:20

Sdružení CZ.NIC, v rámci mezinárodního projektu MoQoS podpořeného Evropskou komisí prostřednictvím Nástroje pro propojení Evropy (CEF), spustilo ve spolupráci s Ministerstvem pro místní rozvoj ČR (MMR) webový test na adrese www.standardkonektivity.cz. Ten je určený primárně základním, středním a vyšším odborným školám, které žádaly o grantovou podporu prostřednictvím výzev Integrovaného regionálního operačního programu (IROP).

Webová aplikace však neslouží jen institucím žádajícím o podporu, ale lze ji využít i v případě ověření naplnění požadavků např. ze strany poskytovatele webového připojení či pouhé kontroly, jak jsou některé webové stránky, kde nejvíce hrozí kyberútoky a s ním spojené úniky dat, zabezpečené (banky, státní instituce apod.). Výsledky měření rychlosti připojení přes IPv4 a IPv6 protokol jsou zpřístupněny na stránkách www.netmetr.cz ve formě otevřených dat a dány tak bezplatně k dalšímu využití.

A teď ke zmíněnému Standardu konektivity. Ten definuje základní technická kritéria pro projekty předložené ve výzvách č. 32 a 33 (SŠ a VOŠ) a č. 46 a 47 (ZŠ) v rámci specifického cíle 2.4 IROP a má vést ke zvýšení kvality a dostupnosti infrastruktury pro vzdělávání a celoživotní učení, mj. i díky zajištění vnitřní konektivity škol a připojení k Internetu.

Žadatelé o grant, kteří se ve svých projektech zavázali k naplnění požadavků Standardu konektivity, si díky webové aplikaci otestují, jak jsou na tom a zda opravdu dané technické parametry splňují. Toto potvrzení tvoří nedílnou součást žádosti o platbu předkládanou Centru pro regionální rozvoj (CRR).

K 11. květnu je dle informací MMR evidováno 1144 předložených žádostí o podporu ze strany základních, středních a vyšších odborných škol. Rozložení přijatých žádostí středních a vyšších odborných škol je znázorněno v následujícím kartogramu.

MMR ke stejnému datu stihlo doporučit k financování 31 projektů středních nebo vyšších odborných škol. Ostatní projekty jsou stále v procesu hodnocení.

Kategorie:

Centrální registr, registrátor a subregistrátor

Pá, 05/26/2017 - 15:15

Podle logiky jazyka českého chápeme termín registrátor jako označení někoho, kdo registruje. Se subregistrátorem je to trochu složitější, očividně registruje také, ale nějak neúplně, neboť předpona sub naznačuje jeho podřazenost. Centrální registr je poměrně jasný, je to seznam něčeho, třeba vozidel, firem nebo pojištěnců.

Když provozujete své webové stránky .cz, může se Vám jednoho dne stát, že od naší společnosti obdržíte upozornění na expiraci domény s doporučením obrátit se na určeného registrátora. Můžete se cítit zaskočeni, nepamatujete si, že byste uzavírali nějakou smlouvu s námi a s tím, koho v e-mailu uvádíme. Znáte přeci svého vlastního registrátora. Zakopaný pes je v tom, že provedená registrace činí vykonavatele činnosti registrátorem pouze gramaticky, zatímco v terminologii, týkající se domén, je to trochu jinak.

Určený (akreditovaný) registrátor domény je právnická osoba, která uzavřela s CZ NIC smlouvu a zavázala se dodržovat principy vyplývající z obchodních podmínek. Tím získává přístup do registru a s tím související oprávnění doménu s koncovkou .cz registrovat, převádět, prodlužovat a rovněž měnit údaje o držitelích domén, administrativních a technických kontaktech. To vše samozřejmě může učinit pouze na základě Vaší autorizace.

Naopak subregistrátorem se může stát kdokoli, aniž by s námi uzavřel jakoukoli smlouvu. Může to být Váš kamarád, zaměstnanec nebo třeba hostingová společnost. On sám však přístup do registru nemá, registraci domény tak vždy provádí prostřednictvím jednoho z akreditovaných registrátorů. V optimálním případě by měl respektovat stejná pravidla jako registrátor, ale nikde se k tomu nezavázal. Držitel domény by však měl vědět, že registrátora může v případě potřeby kontaktovat osobně. Pokud totiž využíváte služeb subregistrátora, počítejte s tím, že když jej požádáte o aktualizaci údajů nebo o prodloužení domény, musí on následně požádat registrátora. Jedině ten je totiž oprávněný požadavky držitelů domén a kontaktů zpracovávat přímo v Centrálnímu registru.

Může se stát, že zaměstnanec ve Vaší firmě skončí, kamarád je mimo dosah, hostingová společnost ukončila svou činnost. Ztratit z takového důvodu přístup k doméně není žádoucí. Je proto důležité, abyste byli uvedení jako držitel domény. Pokud s Vámi subregistrátor jedná otevřeně a používá reálné kontakty, rád Vám zašle výpis z registru, kde si můžete zkontrolovat, že uváděné údaje o držiteli domény odpovídají skutečnosti.

Na závěr ještě poslední pojem a tím je Centrální registr. Podle Wikipedie znamená registr seznam či katalog. V různých kontextech může nabývat různého významu, používá se v oblasti veřejně dostupných informací, v elektronice a IT nebo v umění. Centrální registr domén je databáze informací o doménách. Najdete v něm veřejně dostupné záznamy o doméně, datum expirace, údaje o držiteli, registrátorovi, administrativní a technický kontakt.

Provoz registru doménových jmen s koncovkou .cz zajišťuje CZ.NIC, z. s. p. o. Ačkoli NIC zní ryze česky, je to zkratka z anglického Network Information Centre (přeloženo do češtiny jako síťové informační centrum). Stejné pojmenování používají i jiné organizace, které se na národní úrovni starají o domény nejvyššího řádu (o domény s jinými koncovkami) – například SK-NIC (Slovensko), nic.at (Rakousko), DENIC eG (Německo), NIC.br (Brazílie) a další. Každá taková společnost však má vlastní pravidla, týkající se například tvorby doménového jména, použití znaků nebo ochranné lhůty po expiraci domény. Databázi všech organizací, které spravují Centrální registry domén nejvyšší úrovně, lze najít v seznamu na stránkách IANA.

Kategorie:

Od honeypotu k analýze routeru

Ne, 05/21/2017 - 19:25

Vše začalo ve chvíli, kdy nám přišla odpověď na jeden z e-mailů, které jsou automaticky generovány našimi honeypoty v případě detekovaného pokusu o útok, či podezřelého chování. Tato upozornění jsou posílána abuse kontaktům sítě, ze které útok přicházel.

Reakce na hlášení z našeho honeypotu.

Takováto reakce na zprávu z našeho honeypotu pochopitelně zaujala moji pozornost. Požádal jsem tedy dotčeného ISP o pomoc a netrvalo dlouho a na stole jsem měl zapůjčené dva vzorky routeru Billion BiPAC 9800VNXL. Jeden přímo odhalený našimi honepoty a druhý čistý pro porovnání v případě, že by se jednalo o trvalou nákazu.

Po prvním „ošahání“ přišlo trochu zklamání. Zařízení nemělo klasický shell, ale jenom jakousi příkazovou řádku na telnetu, která byla pro další analýzu naprosto neužitečná.

Když už jsem pomalu začal vzdávat svoji snahu a smiřoval se s tím, že nebudu schopen porovnat vzorky firmwaru z obou zařízení, zkusil jsem poslední možnost. Připojil jsem zařízení do Internetu na veřejnou IP adresu. A vyplatilo se. Přibližně během do dvou hodin byl router plně kompromitovaný a stal se součásti botnetu. Hned jsem ho tedy odpojil od sítě a jal se analyzovat zachycená data.

Ukázalo se že router trpí zranitelností umožňující vzdálenému neautorizovanému útočníkovi spustit libovolný kód. Útok se skládá ze dvou HTTP/SOAP dotazů přičemž ve druhém byl uschován řetězec:

Došlo tedy ke stažení a spuštění binárky a připojení infikovaného routeru k botnetu. Ze zvědavosti jsem binárku nahrál na Virustotal, ale jak se dalo očekávat, architektury jako například MIPS, nejsou úplně zajímavé pro antivirové společnosti, jako podezřelý označil vzorek pouze jeden antivir z 55. Na základě posbíraných dat, jsem si napsal krátký skript, který mi umožňoval do routeru posílat příkazy. Ty se nakonec zdrcly jen na vypnutí telnetového démona a jeho opětovné spuštění, ale tentokrát s parametrem -l /bin/sh, což mi udělalo velkou radost, protože jsem měl konečně přístup ke klasickému shellu.

Následně jsem již snadno z obou routerů vytáhl firmware a ověřil kryptografické otisky jednotlivých oddílů. Oddíl s kořenovým adresářem a linuxovým jádrem byly na chlup stejné. Lišily se pouze oddíly bootloaderu a oddíl s uloženou konfigurací. Rozdíl v konfiguracích byl nezajímavý a v bootloaderu se dle očekávání lišila akorát uložená MAC adresa. Porovnání oddílů tedy dopadlo dle očekávání, nebývá totiž časté, aby malware přepsal firmware. Částečně také proto, že oddíl s kořenovým adresářem používá jako systém souborů squashfs a při úpravě je zapotřebí, aby byl přepsán celý oddíl.

Porovnání kryptografických otisků jednotlivých oddílů.

Po porovnání firmwarů jsem se vrátil k zpět k prošlému útoku a nalezené zranitelnosti. Samotný malware se choval celkem slušně. Upravil si iptables, tak aby sám sebe ochránil před případnou následnou nákazou zablokováním portů zranitelné služby. A hned na to se jal scanovat náhodné IP adresy za účelem dalšího šíření. Už jen chyběla hláška v telnetu o „zabezpečování zařízení“ a dalo se hádat, že se nejspíš jednalo o botnet Hajime. Ze zvědavosti jsem udělal ještě pár pokusů a nejkratší čas napadení čistého zařízení nepřekročil 10 minut.

Samotná zranitelnost tedy umožňuje vzdálené spuštění libovolného kódu (remote code execution) s maximální délkou řetězce 62 bajtů. Konkrétně se jedná o „vlastnost“ „NewNTPServer“ protokolu TR-064, který je určen pro konfiguraci po lokální síti, ale zřejmě následkem chybné implementace je dostupná i z Internetu v rámci protokolu TR-069. Zranitelnost byla objevena na portu 7547, ale v našem případě se týká i portu 5555, který obsluhuje stejný program (/userfs/bin/tr69). První informace o této zranitelnosti u jiného routeru se objevila 7. listopadu loňského roku a jednalo se o Eir’s D1000. Zneužití této zranitelnosti je velice snadné a odkazovaná stránka obsahuje i modul do Metasploitu.

Na stránkách výrobce routeru nebyla o dostupnosti jiných verzí firmware ani zmínka, proto jsem jej kontaktoval s popisem nalezené zranitelnosti a dotazem, zda bude připravovat nějakou opravu. Při kontaktování výrobce routeru ohledně zranitelnosti však vyšlo najevo, že nová verze firmwaru již existuje a je přímo přeposílána cílovým zákazníkům (zřejmě ISP). Sami uživatelé pak bohužel nemají možnost zjistit ani existenci nové verze firmware či existenci a závažnost zranitelnosti, kterou jimi používaný produkt obsahuje. Proto v tuto chvíli zvažujeme možnost vytvoření webových stránek kde by si lidé mohli nechat automaticky otestovat svoje zařízení na tuto zranitelnost. Jednou z drobných překážek však bude nutnost požadovat od uživatele vypnutí a zapnutí zařízení, protože pokud by již router byl napadený podobným způsobem, zranitelnost by se díky blokovanému portu v iptables neprojevila.

Při hledání souvisejících CVE ID nebylo žádné nalezeno. Po komunikaci s Mitre došlo k přidělení nového CVE-2016-10372 pro zranitelnost dříve objevenou na modemu Eir a po dalším zkoumání pak bude pro BiPAC 9800VNXL přiděleno nové CVE ID a nebo pokud se prokáže, že se jedná o stejný software se stejnou chybou, tak se přidá na seznam zranitelných zařízení pod CVE-2016-10372.

I když se nejedná o zcela novou chybu a ani příliš rozšířená zařízení, jsem rád, že se nám podařilo projít celým řetězcem událostí, od detekování bezpečnostního incidentu vlastními prostředky, přes analýzu celé události až po komunikaci se zainteresovanými stranami.

Závěrem bych chtěl poděkovat za spolupráci Radku Jiroutovi z Dial Telecom, a to za nahlášení vadného zařízení.

Odkazy:
https://devicereversing.wordpress.com/2016/11/07/eirs-d1000-modem-is-wide-open-to-being-hacked/
https://isc.sans.edu/forums/diary/TR069+NewNTPServer+Exploits+What+we+know+so+far/21763/
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10372
https://www.broadband-forum.org/technical/download/TR-064.pdf
https://www.broadband-forum.org/technical/download/TR-069.pdf

Kategorie:

Zážitky z Locked Shields 2017

Pá, 05/19/2017 - 14:15

Locked Shields je největší mezinárodní cvičení věnující se kybernetické bezpečnosti. Je pravidelně organizováno od roku 2010 NATO CCDOE (Cooperative Cyber Defence Centre of Excellence),V rámci tohoto cvičení jde hlavně o souboj mezi dvěma týmy. Červený tým útočí na modrý, který zastává roli obránců. Letos se tohoto cvičení zúčastnilo celkem 19 modrých týmů. Ti dostali na starost rozmanitou počítačovou infrastrukturu vojenské základny fiktivní země sestávající z různých serverů, nemalého počtu pracovních stanic a SCADA systémů apod. Proti obráncům stojí útočníci, kteří mají za cíl co nejvíce škodit, kompromitovat, potažmo zcela odstavit bráněnou síť či její prvky nebo to alespoň obráncům pěkně zkomplikovat. Cvičení je kromě technické části zaměřeno také na strategické rozhodování, (spolu)práci s tiskem a řešení legislativních záležitostí. My jsme byli pozváni kolegy z GovCertu a byli jsme zařazeni do týmu „linuxáků”.

Akce byla rozložena do dvou týdnů, a to po dvou a třech dnech. První týden nám sloužil především pro seznámení se s členy týmu, s infrastrukturou a se systémy. Během těchto prvních dvou dnů bylo důležité najít nejrozmanitější zranitelnosti a identifikovat nastražený škodlivý software či běžící nepotřebné služby. Poté byl přístup k tzv. Gamenetu uzavřen a u všech strojů bylo nastavení uvedeno do původního stavu.

Druhý týden jsme měli na otestování připravených oprav jen první den a poté byly znovu všechny stroje vráceny do počátečního stavu. Druhý den to všechno odstartovalo. Po otevření Gamenetu jsme měli ještě 30 minut „hájení“, než spustil červený tým své útoky. Počáteční půlhodina nám musela stačit na aplikování všeho, co jsme připravovali předešlé dny. Automatizace se zde ukázala v celé kráse. Útoky pak již probíhaly bez omezení po zbytek druhého dne i celý třetí den – dohromady tedy 15 a půl hodiny.

Celkově panovala velice napjatá atmosféra, na chodbách se ozývaly IP adresy, ze kterých červený tým útočil a bylo je potřeba neprodleně zablokovat, a v místnosti, kde jsme seděli (tedy s linuxáky) se kolegové radili a různě si pomáhali. Protože jsme měli každý na starosti jiné systémy, pokusíme se tu popsat alespoň naše dva pohledy:

Radka:
V prvním týdnu, po rozdělení serverů, potažmo služeb, jsem už věděla, že se budu starat o server, na kterém běžel e-shop s armádními doplňky. Zjišťovala jsem tedy, co všechno je špatně v nastavení Tomcatu, ve kterém e-shop běžel. Dále co se děje se zdejší databází, jestli nejsou pozměněné systémové binárky, neběží zde zbytečné služby, popř. nejsou otevřené porty, které být otevřené nemají. Zároveň jsem obdivovala, jak zkušeně si vedou přítomní kolegové se svými službami. Mnozí z nich měli již zkušenost z předchozích let, takže mnohem lépe zvládali průchod materiály a pravidla hry nebo měli prostě více praktických zkušeností z dotčených oblastí. Nejednou mě napadla otázka, jestli jim tam k něčemu vůbec budu :-). I když jsme se večer rozešli, mnozí z nás včetně mě doma dále studovali, co a jak zlepšit.

Druhý den jsme opět zkoušeli na přidělených serverech všelijakou magii. Den na podobné testy jsme měli i druhý týden, ale tentokrát na čistě revertovaných strojích, takže jsem si mohla přesně vyzkoušet, co jsem si zapomněla předešlý týden zapsat.

A další den to začalo. V devět ráno nás pustili do GameNetu a my měli půl hodiny všechno „spravit”. Právě tady se ukázaly přednosti automatizace. Kolegové, kteří měli tuhle část na starosti, vyrobili za předchozí dny mnoho užitečných Ansible playbooků, které aplikovali hned jak mohli a měli jsme krásný základ. Kolem třicátépáté minuty mi moje počáteční nadšení překazil defacement, pro který bylo zneužito fórum neošetřené proti SQL Injection útoku v jedné části e-shopu. Chybu jsem po nějaké době našla, opravila a k incidentu jsem poskytla, co nejpřesnější podrobnosti.

Nic horšího už se mi naštěstí s e-shopem, ani třetí den nestalo (nebo je to jen sladká nevědomost), i když při sledování logů byly nějaké další pokusy ještě vidět. U samotného průzkumu „vlastních” problémů, jsem pozorně sledovala ostatní, pokud to šlo, vypomohla jsem, kde se dalo, a často obdivovala, jak si dokázali pod tlakem hravě poradit s řešením mnohem zapeklitějších případů.

Ke konci posledního dne byla atmosféra už uvolněnější, ale zase stoupalo napětí při pohledu na skóre, protože náš tým se pohyboval na předních příčkách. V 16 hodin byl GameNet uzavřen a my jsme s napětím sledovali dobíhající body za reporty či komunikaci s uživateli. Kolem páté jsme už začali tušit, že je opravdu možné, že jsme první, ale od druhého místa nás dělilo jen velice málo bodů. Další den se konal webinář, ve kterém s námi vedoucí různých týmů (červených a také podpůrných týmů zelených a bílých) v Talinnu sdíleli své dojmy, ale hlavně, kde se vyhlašovaly výsledky, ze kterých jsme se konečně s jistotou dozvěděli, že jsme opravdu PRVNÍ.

Celkově to pro mě byla skvělá zkušenost, zábava, spoustu jsem se toho naučila díky radám zkušenějších kolegů a zároveň jsem měla možnost poznat další odborníky z oboru a vidět naživo, jací jsou to machři.

Martin:
Mým úkolem bylo postarat se o chod tří serverů. První dva sloužily jako DNS resolvery včetně autoritativních serverů pro naši doménu a navíc měly na starosti i synchronizaci času přes NTP. Třetí byl VPN server pro vzdálené připojení uživatelů. Zde byl první zádrhel. Těšil jsem se na klasické OpenVPN, ale čekalo mne OpenVPN Access Server, což je komerčnější varianta, která se liší od klasické volně distribuované verze, takže jsem se měl s čím seznamovat.

Kromě výše zmíněného, co je třeba všechno zjistit/ověřit případně i smazat hned na začátku, jenom dodám, že v rámci naší linuxové skupiny slavily úspěch balíky debsums a rkhunter. U DNS serverů byla oprava konfigurace relativně snadná – v konfiguračních souborech byl například povolen zone transfer. U VPN serveru už to bylo malinko složitější, protože veškerá konfigurace, včetně logování, byla v SQLite, takže seznámení se se strukturou nebylo tak přímočaré, ale i přesto se mi povedlo mít na začátek cvičení připraven skript pro smazání nepotřebných účtů a nepovolených způsobů autentizací. Smazaní SUID bitu u /bin/nano už pak byla jen třešnička na dortu.

Během „bitvy” samotné byl na mých serverech relativně klid. Občas se „na chodbách” kromě IP adresy ozvala i nějaká ta doména. Takovou doménu pak bylo nutno zablokovat na DNS serveru.

Nakonec odbyla šestnáctá hodina a naše oči se odvrátily ke skóre, které ještě tou dobou nebylo uzavřené a body se stále přičítaly/odčítaly. Napětí se dalo krájet a v jednu chvíli se skóre zastavilo ve stavu, kdy nás od prvního místa dělil jediný bod (což bylo při skóre přesahující číslo 30 000 opravdu smutné). Pak se ale bodování rozběhlo a nakonec i v neoficiálním vyhlášení zaznělo, že první tři místa se už měnit nebudou. V té době jsme již byli první! Nutno dodat, že druhé místo mělo jen o přibližně 400 bodů méně a to opravdu není mnoho (gratulace Estonsku).

Závěrem už jen dodáme,že celkově pro nás byla účast na Locked Shields opravdu skvělá zkušenost. Chtěli bychom tímto tedy ještě jednou poděkovat všem našim týmovým kolegům a také GovCERTu za pozvání. Jsme rádi, že jsme mohli být součástí takového úspěchu.

Radka Nepejchalová, Martin Kunc

Kategorie:

Mají i dnes smysl otevřené validující resolvery?

Pá, 05/19/2017 - 09:35

Již řadu let naše sdružení provozuje službu skrývající se pod zkratkou ODVR, tedy Otevřené DNSSEC Validující Resolvery. V dobách, kdy byl DNSSEC v plenkách, jsme měli za to, že je třeba přijít s alternativou DNS resolverů poskytovatelů připojení, kteří zaváděli podporu validace pozvolna. Od té doby tedy nabízíme veřejně dostupnou službu, která umožňuje validace domén používajících zabezpečení DNSSEC i v těch sítích, jejichž defaultní DNS resolvery toto nepodporují.

Podpora technologie DNSSEC postupně roste a stává se standardem. V roce 2008 nebyla takto zabezpečena ani jedna .cz doména, na konci roku 2016 pak již každá druhá. Na straně provozovatelů DNS resolverů, tedy převážně poskytovatelů připojení, je situace obdobná, i když vždy byli o něco „pozadu“. Jak lze vyčíst ze statistik Geoffa Hustona (APNIC), přesahuje dnes podpora DNSSEC na DNS resolverech poskytujících služby pro Českou republiku 40 %. Toto číslo platí konkrétně pro šifrovací algoritmus RSA, který je předchůdcem modernějšího algoritmu ECDSA, na který se postupně přechází. Jeho podpora je nižší (viz mapka níže), ale i zde je trend podpory rostoucí. Od listopadu 2016 vzrostla podpora validace pomocí ECDSA v ČR o 6 % na dnešních téměř 36 %.

Přesto, že se dostupnost DNSSECu od poskytovatelů připojení zlepšuje, stále platí, že většina uživatelů Internetu pomocí DNSSECu nevaliduje. ODVR je tu právě pro ně, dokonce jim umožní využívat i již zmíněné ECDSA.

Validace na našem ODVR je zajištěna rekurzivním DNS serverem Unbound. Provozujeme jej již delší dobu bez zásadnějších změn s doporučeným nastavením. Nejzajímavějšími body naší konfigurace jsou:

    • Unbound drží již expirované podpisy po 10 % doby platnosti podpisu každého záznamu (expiration-inception). Jelikož záznamy mohou být podepsány s dobou trvání několika dnů, týdnu nebo i jednoho měsíce, je definována ještě minimální a maximální doba možného držení expirovaného podpisu. V naší konfiguraci je nastaven minimální čas na 1 hodinu, maximální pak na 24 hodin. Nedávno jsem odpovídal dotaz na „nefunkčnost“ validace pro případ expirace podpisu a musel pro toto vysvětlení zajít až do dokumentace projektu Unbound.
    • Unbound zakazuje překlad těch záznamů, u kterých jsou nastavené privátní IPv4 či IPv6 adresy. Tedy IP adresy z rozsahů 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, fd00::/8 a fe80::/10. Je to z důvodu ochrany proti tzv. útoku DNS Rebinding. Současně také z důvodu, že validátor DNSSEC může tyto záznamy považovat za falešné.
    • ODVR resolvery jsou dostupné na IPv4, tak i na IPv6 adresách. Nejedná se však jen o dva servery. ODVR je provozováno, podobně jako naše autoritativní DNS servery, v rámci DNS anycastu. Jen v České republice je těchto serverů šest, jejichž provoz je znázorněn na níže uvedených grafech. Z nich také vyplývá, jak během 1 roku vzrostlo jejich využití.


  • V současné době uvažujeme, že bychom Unbound nahradili naším KNOT Resolverem, který jsme v době spouštění ODVR neměli k dispozici.

ODVR může ale sloužit nejen validaci. Jak jsme dlouhodobě upozorňovali v rámci aktivity Přichází cenzor, DNS resolver si může každý uživatel Internetu svobodně změnit a pokud budou zákony přirozenou funkci DNS pro poskytovatele připojení omezovat, bude přirozeně obliba otevřených resolverů růst. Tak jako roste i obliba a využívání našeho ODVR, které dnes ve špičkách odbavuje přes 6 000 dotazů za sekundu. A jsou okamžiky, kdy je zájem o naše ODVR dokonce výrazně vyšší. Například při loňském výpadku Google, viz následující graf.

Kategorie:

Nové statistiky a růst popularity eliptických křivek v DNSSEC

Čt, 05/18/2017 - 12:15

Už to bude skoro půl roku, co jsme na naší konferenci IT 16.2 prezentovali záměr změnit algoritmus DNSSEC klíče zóny CZ. Kolega Zdeněk Brůna tehdy  ve své prezentaci detailně popsal výhody algoritmů založených na eliptických křivkách a to zejména algoritmu ECDSA. Nicméně vzhledem k situaci, kdy není možné tento krok provést kvůli nepodpoře tohoto algoritmu v kořenové zóně, přesunuli se naše aktivity zejména k osvětě a ke sledování dopadů osvěty na stav podpory této nové technologie. Na semináři s registrátory, který jsme měli na konci února, jsme zaznamenali pozitivní odezvu na některé vlastnosti ECDSA, jako jsou menší velikost zónového souboru nebo menší velikost DNS odpovědi. Někteří registrátoři již na místě deklarovali zájem na ECDSA přejít také. Zároveň registrátoři navrhli, abychom na našem webu zveřejnit statistiky ukazující, jak jsou různé DNSSEC algoritmy v CZ zóně používané. Tento nápad se nám líbil a tak nyní tyto statistiky zveřejňujeme.

Ze statistik vyplývá, že stále nejpoužívanějším algoritmem je RSASHA1. Tento algoritmus má bohužel řadu nevýhod. Tou hlavní je jeho nekompatibilita s NSEC3 technologií a tudíž je primárně určen pro zóny, u kterých nevadí, že jejich obsah je veřejně dostupný. Druhou nevýhodou je jeho orientace na „dosluhující“ hashovací funkci SHA1. Proto je důležité, aby správci domén používající pro DNSSEC tento algoritmus zvážili přechod na jiný typ algoritmu. Co nás těší je, že ECDSA algoritmus již rozhodně není v CZ zóně něco exotického. Aktuálně ho využívá přes 80 000 domén, tedy necelých 13 %, a je to třetí nejpoužívanější DNSSEC algoritmus. Jak jsme se do tohoto stavu dostali ukazuje následující graf.

Vývoj podpory algoritmu označovaného jako ECDSAP256SHA256 je možné sledovat na fialové křivce. Do prosince 2016 se jednalo o pár stovek domén. Sem patří kolem stovky našich vlastních domén, a zbytek jsou domény provozované na infrastruktuře společnosti Cloudflare. Tato společnost je celosvětově hlavním tahounem podpory ECDSA. U nás má několik tisíc domén, nicméně díky neexistující vazbě mezi DNS operátory a registrátory není u všech DNSSEC nastaven. To by se mohlo změnit s projektem automatizované správy keysetů, na kterém aktuálně pracujeme.

V prosinci 2016 je v grafu vidět první velký skok, který je způsobem přechodem na ECDSA u všech domén hostovaných u registrátora Zoner a který se týkal zhruba 30 000 domén. Z grafu je také vidět, že se jednalo o přechod z algoritmu RSASHA1-NSEC3-SHA1. Druhý velký skok se udál před dvěma týdny, kdy obdobným způsobem převedl všechny své domény na ECDSA také registrátor IGNUM. Tentokrát to bylo přes 50 000 domén a bylo to na úkor algoritmu RSASHA1. Oba registrátoři označili tento přechod za bezproblémový. Jsme samozřejmě rádi, že mezi našimi registrátory jsou i takoví, kteří prokazatelně zvládnou ne úplně triviální rotaci DNSSEC klíčů. Změna algoritmu totiž není totéž jako běžná změna klíče, vyžaduje více kroků a větší pozornost. Pokusíme se získat jejich podrobnější zprávu, třeba již na červnové konferenci IT 17.

Kategorie:

Jak se projevilo snížení TTL v zóně .cz

Čt, 05/18/2017 - 08:58

V druhé polovině února jsme informovali o snížení TTL v zóně .cz, a to o jednu hodinu. Poté jsme vždy každou středu, v podobném čase, provedli snížení o další hodinu, až jsme 15. března 2017 dosáhli na požadovanou hodnotu 1 hodiny (tedy TTL=3600).

Snižování TTL jsme provedli konkrétně v těchto časech:

22.02. 2017 ve 14:50,
01.03. 2017 ve 15:25,
08.03. 2017 ve 15:50,
15.03. 2017 ve 15:25.

Hodnotu TTL jsme z opatrnosti snižovali po týdnech, neboť velká změna o 4 hodiny by totiž mohla znamenat znatelnější nárůst dotazů v okamžiku, kdy expirují záznamy z cache rekurzivních DNS resolverů. Postupné snižování nám také umožnilo průběžné monitorovat, jak se změna projeví v provozu a případně přizpůsobit další kroky zjištěným dopadům. Veškerá data o DNS provozu dlouhodobě sbíráme do vlastního systému, ze kterého, kromě sumárních statistik, dokážeme získávat data až na úrovni jednotlivého DNS požadavku.

Zajímavosti z provozu

Všechny anycast DNS servery, jak v České republice, tak v zahraničních lokalitách, odbaví za den průměrně (vztaženo k březnu 2017) okolo jedné miliardy požadavků.

Největším odběratelem DNS provozu .cz zóny je operátor O2 (průměrně 150 000 000 požadavků/den) a společnost Google (130 000 000 požadavků/den). Na dalších místech jsou v tomto pomyslném žebříčku Seznam.cz a její e-mailové služby (53 000 000 požadavků/den) a Microsoft (30 000 000 požadavků/den). Následují větší poskytovatelé připojení, hostingové společnosti a mobilní operátoři.

Nejvíce DNS provozu odbaví lokality v České republice – 36 %, následované lokalitami ve Velké Británii – 19 %, USA – 14 %, Rakousku – 12 %, Německu – 10 % a zbytku světa (Chile, Švédsku, Japonsku) – 9 %.

Pojďme se podívat na DNS provoz trochu blíže. DNS provozem rozumíme přijaté dotazy od DNS serverů na dotazované jméno (tzv. QNAME) společně s typem dotazu (tzv. QTYPE) a na ně navazující odpovědi s návratovým kódem.

Nejčastěji vyskytující se typy dotazů, zjištěné z našich statistik měsíce března 2017, ukazuje následující graf. Pro zopakování:

A – Address Record (obsahuje IPv4 adresu přiřazenou danému jménu),
AAAA – IPv6 Address Record (obsahuje IPv6 adresu přiřazenou danému jménu),
DS – Delegation Signer (obsahuje hash veřejného klíče pro DNSSEC),
MX – Mail Exchange Record (obsahuje adresu a prioritu pro příjem elektronické pošty),
NS – Name Server Record (obsahuje adresu autoritativního DNS serveru pro dané jméno),
TXT – Text Record (obsahuje libovolný textový řetězec),
SRV – Service Record (obsahuje odkaz na jinou adresu a port),
CNAME – Canonical Name Record (obsahuje alias k danému jménu).

Nejčastější návratové kódy v odpovědích jsou:

0 – NOERROR (dotaz úspěšně vyřízen),
1 – FORMERR (chyba ve formátu dotazu),
2 – SERVFAIL (dotaz není možné vyřídit, chyba),
3 – NXDOMAIN (dotazované jméno neexistuje),
4 – NOTIMP (nepodporovaný typ dotazu),
5 – REFUSED (DNS server odmítl odpovědět na dotaz),
9 – NOTZONE (dotazované jméno se nenachází v zóně).

Každý den registrujeme, přibližně v čase 14:50 – 17:00, výrazné zahuštění DNS dotazů vracející odpověď 3 – NXDOMAIN.

O jaká neexistující doménová jména a typy záznamů se jedná? Nejčastěji jde o domény, které již byly vyřazeny z registru a smazány z DNS serverů  a rekurzivní DNS servery se na ně stále dotazují. Některé jsou ovšem s největší pravděpodobností vymyšlené nebo se dotazují přímo na autoritativní DNS servery CZ.NIC namísto delegovaných NS serverů.

Dopad snížení TTL na provoz DNS serverů

Největším dopadem snížení TTL byl skokový nárůst všech DNS dotazů, které expirovaly z cache DNS resolverů.

Při srovnání veškerého DNS provozu byly počty dotazů za sekundu ve špičkách jednotlivých dnů, po snížení TTL, v průměru o 50 % vyšší. Toto navýšení opět po několika minutách pominulo, jak je patrno z níže uvedených grafů.

Dále jsme pozorovali zvýšený počet NXDOMAIN odpovědí, tedy odpovědí DNS dotazů na neexistující nebo již expirované záznamy. Ty mohly být způsobené také dotazujícími DNS resolvery bez použití cache.

Níže uvedený graf ukazuje skokový nárůst NXDOMAIN, trvající vždy 15 minut dle nastaveného NXDOMAIN TTL.

Z dlouhodobého pohledu však změna TTL na DNS provoz neměla žádný významnější vliv. Krátkodobé zvýšení počtu DNS dotazů na serverech proběhlo podle našich očekávání, nebylo nijak zásadní nebo nestandardní.

Snížením TTL jsme docílili rychlejších změn delegací v registru, které se v kratší době projeví na autoritativních DNS serverech, ale i na DNS resolverech. Aktuálně nastavenou hodnotu TTL v zóně .cz je možné ověřit příkazem $ dig +multiline soa cz, případně online např. na http://www.webdnstools.com/dnstools/dns-lookup.

Pro srovnání – TTL národních domén okolních států se pohybují od jedné hodiny až po dva dny. Blíže:
Holandsko (.nl) – 1 hodina,
Maďarsko (.hu) – 1 hodina,
Německo (.de) – 1 den,
Slovensko (.sk) – 1 den,
Polsko (.pl) – 1 den,
Rakousko (.at) – 2 dny,
Francie (.fr) – 2 dny,
Velká Británie (.uk) – 2 dny.

Zajímavostí je, že generické domény .com, .net, .biz a .org mají TTL nastaveno dokonce na 15 minut.

Podobným způsobem je možné zjistit hodnotu TTL často navštěvovaných domén druhých a nižších úrovní.

Kategorie:

Děti online

Čt, 04/13/2017 - 16:37

Festival „Jeden svět“ reflektuje nejen politická ale i sociální témata, a protože dění v kybernetickém světě se stalo každodenní realitou nás všech a počítače a mobilní zařízení už nejsou ve středu zájmu jen několika divných ajťáků, stal se i kybernetický svět důležitým tématem pro tento festival.

Do projekce doprovodného vzdělávacího programu Jeden svět na školách byl zařazen dokumentární film Děti online, který se na základě tří skutečných příběhů zabývá problematikou youtuberů, hraním online her a nástrahami na sociálních sítích. V pražských kinech jej v průběhu měsíce března zhlédlo téměř dva tisíce mladých diváků z řad středních a základních škol.

Ve filmu Děti online se diváci seznamují s reálnými příběhy. Dvanáctiletý Zachy výstižně demonstruje obrovské úsilí, které je nutné věnovat tvorbě kvalitního obsahu a problematiku negativních reakcí na některá svá videa. Oskar vypráví o své vášni k počítačovým hrám a citlivější divák může díky jeho vyprávění zaznamenat hranici mezi zdravým zájmem o hru a závislostí. Poslední příběh vypráví o dvou dívkách, Niky a Anně, které se staly oběťmi psychické manipulace realizované prostřednictvím Internetu, tzv. kybergroomingu, jehož cílem je v dítěti (nebo jiné osobě) vyvolat falešnou důvěru a přimět jej k osobní schůzce, na které je potom například sexuálně obtěžován, fotografován nebo manipulován za účelem radikalizace.

Díky příběhu Nikči a Anny se může divák seznámit s tím, jak obrovský dopad může mít virtuální realita na reálný život. Za spáchání souběhu trestných činů vydírání, sexuálního obtěžování, výroby dětské pornografie a znásilnění, které poškodilo více než padesát dívek, byl pachatel odsouzen k trestu odnětí svobody na šest let a šest měsíců. Tento film bude po skončení festivalu vysílán Českou televizí.

Sdružení CZ.NIC bylo díky projektu Safer Internet osloveno k účasti na odborných besedách, které následovaly vždy po skončení projekce filmu Děti online. Osobně jsme tak měli možnost diskutovat s více než 600 diváky z pražských škol a 300 diváky z Pardubického kraje. Především nás zajímalo, jak na diváky film působil a co je pro ně samotné tím zdánlivě největším problémem na Internetu. Názory na film se lišily dle toho, který příběh byl divákům nejbližší. Kladně byla hodnocena snaha a trpělivost mladého youtubera Zachyho a záporně potom především neopatrnost dívek, při navazování osobního vztahu s cizím člověkem prostřednictvím sociálních sítí.

V návaznosti na oboustranně přínosné diskuse, jsme byli pozváni k dalšímu doprovodnému projektu s názvem Kdo jiný, v rámci kterého jsme se čtyřmi studenty mluvili o jejich projektu, který by měl reflektovat problematiku kyberšikany. Tedy jednání, které opakovaně ubližuje, zesměšňuje, ponižuje nebo týrá druhého prostřednictvím Internetu.

Mám-li shrnout asi ten nejpalčivější problém, který na základě debat se studenty vnímám já sama, musím bohužel konstatovat silný nezájem ze strany rodičů o online život dětí. Na dotaz kolik dětí se pravidelně baví s rodiči o tom, co dělají na Internetu, se v sále obsazeném více než stovkou, většinou aktivních dětí a studentů, nikdy nezvedlo více než pět rukou. Některé děti a někteří studenti mají pocit, že rodiče nezajímá, co na Internetu dělají, jiní si myslí, že „by to stejně nepochopili“.

Dění, které zažívají naše děti online, má dopad na jejich psychické zdraví v reálném světě, rodiče jedné divačky, kterou si dovolím citovat to naštěstí zaznamenali: „No já jsem se směla na Facebook zaregistrovat, až když sem si s rodiči přečetla Podmínky a zásady jeho používání a potom se tam rodiče zaregistrovali taky“. Organizátoři vzdělávacího programu Jeden svět na školách jsou si však velmi dobře vědomi, že tento přístup je s ohledem na dynamiku Internetu dlouhodobě neudržitelný, snaží se proto stejně jako mnoho dalších organizací, vytvářet metodické materiály, propagovat mediální výchovu na školách a prosadit, aby bylo této problematice věnováno více hodin.

Kategorie:

Tři roky s Turrisem

Čt, 04/06/2017 - 10:40

Je tomu pár týdnů zpátky, kdy jsem dostal zprávu, že téměř vypršela tříletá lhůta od mého vstupu do projektu Turris a mohu si tedy router za symbolickou korunu odkoupit. Kromě toho, že jsem to hned udělal, abych kolegům otestoval, že systém dobře funguje, to ve mně vyvolalo nostalgickou vzpomínku. Je to totiž tři roky, co jsem se stejným cílem – otestovat, že nám vše správně funguje – vyplňoval asi první smlouvu o pronájmu routeru. Ty tři roky utekly jako voda a tak je možná vhodná chvíle se ohlédnout zpět.

Když se na tu dobu podívám ve zkratce, ušli jsme opravdu dlouhou cestu. Od první tisícovky modrých Turrisů určených převážně pro výzkumné účely jsme se posunuli do situace, kdy za sebou máme jednu z nejúspěšnějších českých crowdfundingových kampaní (celosvětově 116. největší), routery již komerčně nabízíme a zájem je takový, že již chystáme další várku. Ta cesta ale určitě nebyla snadná ani přímočará.

Příprava každé nové várky routerů nám trvala minimálně rok. Paradoxně nejrychlejší byla příprava první verze, která byla ve výrobě 12 měsíců od spuštění projektu a to i přesto, že jsme první tři měsíce neměli žádného vývojáře hardware a vůbec jsme netušili, jak se takové věci dělají. Byla to doba opravdu velkého zápalu, spousty přesčasů a stresu, ale také velkých pokroků. Druhá verze, kde jsme vylepšili napájení a chlazení a přidali hlavně USB 3.0, trvala o něco déle, i když změny nebyly velké. Bylo to dáno do značné míry tím, že tým už měl i spoustu práce s údržbou stávajících Turrisů a prostor pro inovace se zmenšil. Třetím počinem pak byl Turris Omnia. Tam se nám i přes změnu platformy včetně architektury procesoru podařilo v rychlém čase vyrobit funkční prototypy, se kterými jsme šli do crowdfundingové kampaně. Jak moc se toho pak pokazilo v dalších fázích vývoje, si můžete poslechnout ve výborné prezentaci Ondřeje Filipa. Nakonec jsme ale do roka od startu kampaně rozeslali všechny slíbené routery, a to je na průměr hardwarových crowdfundingových kampaní pořád slušný výkon ;-).

Abych ale nepsal jen o hardware, softwarový vývoj byl samozřejmě také zajímavý. Pro router Turris jsme vyvinuli systém automatických aktualizací, se kterým jsme např. na loňském OpenWrt Summitu sklidili pozitivní ohlas. Je pravda, že ne vždy se všechno podařilo bez chyb, ale i přesto jsem přesvědčen, že jsme to vzali za správný konec. Mimochodem, v Turrisu 1.0 je stále záchranný systém z roku 2014, který nastartuje v případě obnovení továrního nastavení, a který je schopen zařízení aktualizovat až na dnešní podobu systému, včetně výměny knihovny libc, výrazného povýšení kernelu, atp. Je vidět, že jsme to tenkrát nevymysleli vůbec špatně.

Když už jsem zmínil ohlas na OpenWrt Summitu. O tom, že jsme se stali plnohodnotným členem komunity tohoto operačního systému, svědčí i to, že se nám podařilo prosadit Prahu jako město, ve kterém se letošní roční OpenWrt Summitu uskuteční. A protože budeme i jeho hostitelem, věřím, že to bude ten nejlepší, jaký zatím byl.

Když se ale vrátím k software, je toho opravdu hodně, co by se dalo zmínit. Náš webový portál obsahuje celou řadu veřejných statistik i informací pro uživatele jednotlivých routerů. Nedávno jsme pak např. přidali službu amihacked.turris.cz, která vám může pomoci zjistit, jestli nejste nakaženi malwarem. Ta mimochodem využívá mimo jiné data z honeypotů, které jsou na routerech Turris aktivovány, a které nám v loňském roce pomohly jako prvním na světě reportovat aktivitu botnetu Mirai (i když tenkrát se ještě nevědělo, jak se jmenuje) složeného z online kamer a dalších chytrých zařízení.

A tím se dostáváme k další oblasti vývoje a to je síťová bezpečnost. Mnoho z našich výstupů bylo a je vidět, ale ty asi nejcennější veřejné nejsou. Jsou to případy, kdy jsme na základě různých anomálií v chování síťových zařízení odhalili malware přímo v síti některého z turristů. V takovém případě jsme ve spolupráci s týmem CSIRT.CZ diskrétně navázali komunikaci s daným uživatelem a často se nám podařilo nákazu společně najít a zneškodnit. Za ty tři roky bylo takových případů několik desítek a i když to není nijak závratné číslo, osobně si velice cením každého případu, kdy jsme uživateli mohli takto pomoci.

Když se tedy ohlédnu zpátky k plánům, se kterými jsme projekt startovali, a trochu „odzoomuji“ od provozních věcí a detailů, těžko se mi hledá důvod k nespokojenosti. Ve všech klíčových oblastech jsme své představy naplnili a o tom, že budeme i po světě úspěšní v prodeji otevřeného hardwaru „Made in the Czech Republic“, se nám v roce 2013 mohlo jen zdát.

Jak už jsem zmínil, cesta projektu Turris od roku 2013 do dneška nebyla jednoduchá. A určitě by nebyla možná bez těch správných lidí. I proto bych chtěl na závěr tohoto krátkého ohlédnutí poděkovat všem, kteří se okolo projektu Turris točili a točí. Vývojářů, kteří už léta zvládají to nasazení, vedení CZ.NIC, které nám dalo důvěru a neváhalo do projektu investovat nemalé prostředky, a určitě také našim uživatelům a fanouškům – turristům, kteří nám pomáhají svou zpětnou vazbou a mají s námi trpělivost, když se něco nepodaří.

Ať jsou další tři roky projektu Turris alespoň stejně úspěšné.

Kategorie:

Nový hardwarový projekt CZ.NIC

So, 04/01/2017 - 05:25

Jarní období je v posledních letech v CZ.NIC již tradičně doba startu zajímavých hardwarových projektů. V roce 2014 spouštělo sdružení distribuci prvních routerů Turris a v roce 2015 oznámilo spolupráci na projektu Turris Gadgets. I letos tomu není jinak a CZ.NIC se tentokrát rozhodl pro opravdu velký krok vpřed – vlastní procesor.

„Velká část našeho hardwarového vývoje je závislá na procesorech, které jsou na trhu dostupné. Bohužel v poslední době je v této oblasti situace na trhu neuspokojivá. Nabízená řešení nemají dostatečný výkon nebo jsou zase přemrštěně drahá a náročná na spotřebu. Samostatným problémem je pak bezpečnost – vidíme stále větší důraz na transparentnost zařízení i po hardwarové stránce a obavy z produktů čínské provenience a jejich možných špehovacích funkcí. Proto jsme se rozhodli pro vlastní plně otevřený vývoj,“ říká Ondřej Filip, ředitel sdružení.

Procesor, který je zatím vyvíjen pod kódovým označením Říp 1, má již konkrétní obrysy. Bude založen na 64-bitovém jádře ARM Cortex-A53, které nabízí velmi dobrý poměr mezi výkonem a spotřebou, doplněn bude o tři ethernetová rozhraní XFI umožňující přenosovou rychlost 10 Gbps, tři PCIe 3.0 rozhraní s plnou podporou pro NVMe a několik dalších běžných rozhraní. Protože procesor bude zaměřen především na síťové aplikace, byla největší pozornost věnována právě jejich optimalizaci. Největší novinkou tak bude akcelerační jednotka pro síťový provoz. Tu zatím sdružení vyvíjelo na programovatelných hradlových polích FPGA a v tuto chvíli ji převádí do podoby vhodné pro použití v čipu.

„Akceleraci síťového provozu nabízí ve svých čipech i další výrobci, ale náš koncept jde daleko dál. Bude tak výrazně snadnější využít akcelerační možnosti např. v routovacím démonu BIRD nebo je spojit s kryptografickou akcelerací jádra ARMv8 pro bezprecedentní výkon ve VPN aplikacích. Akcelerační jednotka bude navíc také plně open-source,“ dodává Bedřich Košata, vedoucí vývojového oddělení CZ.NIC.

V současné době má sdružení k dispozici finální prototypy celého čipu v FPGA a připravuje výrobu prvních kusů vlastního křemíku. Pokud půjde vše podle plánu, mohly by se procesory do masové produkce dostat na konci roku 2017. Pro budoucí produkty z řady routerů Turris se již počítá výhradně s využitím těchto procesorů.

Do budoucna pak sdružení počítá s dalším výrazným posunem v této oblasti. Pro budoucí verze se počítá i se zařazením  kvantové výpočetní jednotky. „Bude to trochu technologický oříšek, zejména pokud jde o minimalizaci. Zatím nám prototyp kvantové jednotky zabírá dvě sklepní místnosti v naší pražské centrále, dokonce jsme kvůli tomu museli i zrušit vinný sklípek. Věřím ale, že s trochou úsilí budeme mít příští jaro další novinku k představení,“ dodává Košata.

Kategorie:

DNSSEC: splnily orgány státní správy svůj úkol?

Út, 03/28/2017 - 15:25

Již na konci roku 2013 přijala vláda Usnesení, kterým zavedla povinnost zabezpečit všechny domény držené orgány státní správy prostřednictvím technologie DNSSEC, a to do 30. června 2015.

Od tohoto data uplynula již dlouhá doba, proto jsme se opět rozhodli zkontrolovat, zda tyto instituce úkol splnily. Naposledy byla situace na našem blogu zmonitorována v článku s názvem DNSSEC za šest minut dvanáct  několik málo dní před stanovenou lhůtou.

Ministerstva a další ústřední orgány státní správy (centrální úřady) si stojí na výbornou a své povinnosti beze zbytku plní. U krajských úřadů, pro které má usnesení vlády pouze doporučující charakter, je již situace o něco horší a technologií DNSSEC má své domény zabezpečeno pouze sedm ze 14 krajů. Jde tedy o přesnou polovinu. Do té „uvědomělé“ skupiny patří: Karlovarský kraj, Ústecký kraj, Královéhradecký kraj, Pardubický kraj, Kraj Vysočina, Olomoucký kraj a Moravskoslezský kraj. Následující mapa znázorňuje, které kraje na zavedení technologie DNSSEC stále ještě čekají.

Dále tu máme státní instituce jako je Poslanecká sněmovna Parlamentu ČR, Senát Parlamentu ČR, Kancelář prezidenta republiky, Ústavní soud a Česká národní banka, na které se výše uvedené usnesení vlády nevztahuje. Pro zajímavost jsme zrevidovali i tyto webové stránky a pouze Poslanecká sněmovna využívá zabezpečení DNSSEC.

Pokud se zaměříme na webové stránky obcí s rozšířenou působností, dozvíme se, že 51 % z nich také využívá zabezpečení DNSSEC, což je poměrně uspokojivý výsledek.

V České republice se již každoročně koná soutěž o nejlepší webové stránky a elektronické služby měst a obcí – Zlatý erb, jejímž cílem je podpořit modernizaci místní a regionální veřejné správy. Jedním z hodnotících kritérií je právě podpora IPv6 a DNSSEC. Letos se do soutěže přihlásilo 238 kandidátů, z nichž 67 % toto kritérium splňuje. Pokud se tedy městům a obcím dá vhodná motivace, dokáží zavést zabezpečení DNSSEC i bez usnesení vlády.

Podíváme-li se na výsledky využívání technologie DNSSEC globálně, tedy na celou doménu .cz, zjistíme další pozitivní informaci, o které nás již 6. prosince loňského roku informoval Zdeněk Brůna ve svém blogpostu –  Normální je mít DNSSEC. Dle aktuálních statistik sdružení CZ.NIC existuje 51,6 % takto zabezpečených domén. Samozřejmě je stále co zlepšovat, což pochopitelně neplatí jen o zabezpečení DNSSEC. Na základě výše zmíněného si ale můžeme říci, že si Česká republika z pohledu zabezpečení vede poměrně dobře.

Kategorie: