Hosting

Přihlášení

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

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:

Turris Omnia na CeBIT 2017

Út, 03/28/2017 - 10:35

Byla to naše první účast na tak velkém veletrhu a rozhodli jsme se pro ni doslova na poslední chvíli. Chtěli jsme najít partnery a také router představit širší veřejnosti. Turris Omnia je ve volném prodeji již mnoho měsíců, jenže odezvu na něj máme především od linuxových nadšenců. Proto nás velmi příjemně překvapilo, jak se na CeBITu router líbil širší veřejnosti.

Už první otázka, kterou vzbuzoval slogan našeho stánku: „Proč je ten router open source? K čemu to je?” Opravdu. Proč by měl být router open source? Tak především proto, aby jste si byli jisti tím, že dělá, co dělat má, především to, že přenáší data tam, kam je přenášet má. Že na něm nejsou žádné backdoory ani špioni. Což je něco, o čem si můžete být u closed-source programů stále méně jisti. Zdrojové kódy Turrisu jsou volně k dispozici a když si je neprojdete vy, prošla je celá řada lidí před vámi. Open source je věc bezpečnosti a pochopitelné to bylo nejenom pro fanoušky open source, ale i pro běžné uživatele.

Otevřenost routeru není ale jen bezpečnost, nýbrž i využitelnost a rozšiřitelnost. Návštěvníky stánku těšilo i to, že do routeru si mohou doinstalovat svůj software a využít tak relativně výkonný a přitom rozměrově i energeticky úsporný hardware namísto běžného serveru. Zcela běžné byly potřeby propojení firemních poboček skrze velmi rychlou VPN, což je právě doména Turrisů, našly se ale i výstřednější aplikace. Ať už šlo o možnost doinstalovat palubní multimediální portál nebo převzetí obsluhy závlahového systému dříve provozovaného na samostatném serveru. Nejde o to co konkrétně, ale o možnost využít Turris pro velmi rozmanité potřeby. To potřebovali častí návštěvníci našeho stánku: Systémoví integrátoři či firmy zajišťující správu sítí a firemních systémů.

Velký zájem vzbuzovala bezpečnost routeru, zejména systém adaptabilního komunitního firewallu, kdy se z jednotlivých Turrisů sbírají data o útocích, vyhodnocují se a následně se všechny Turrisy v reálném čase proti těmto útokům zabezpečují. Uvědomujeme si, že toto je dnes nejsilnější zbraň proti dosud neznámým hrozbám a chceme ji významně posilovat i o detekci hrozeb a problémů ve vnitřní síti (LAN). Už nejenom firmy, ale i informovanější jednotlivci si význam ochrany i pravidelné aktualizace routerů uvědomují. Zejména pro firmy byl „příplatek” za bezpečnost v podobě vyšší ceny routerů Turris zanedbatelným argumentem ve srovnání s přínosy.

Zajímavé bylo i to, jak k jednotlivým výhodám přistupovaly firmy z různých regionů. Například se u našeho stánku sešla celá řada firem z Indie, protože v Indii je nyní open source poptávaný kvůli obavám ze špionáže a backdoorů. Naopak firmy ze severní Afriky potřebovaly menší a kompaktní „server” s dobrou cenou, který obslouží co nejvíce funkcí včetně routování a který budou mít u zákazníka ve svém vlastnictví včetně svých služeb. Skandinávské firmy potřebovaly obsloužit gigabitovou optickou přípojku a Němci trvali na maximální bezpečnosti a sháněli se po DSL, což nás přesvědčuje o tom, že na něm musíme pracovat. Číňané se vyptali na všechno a ještě si detailně nafotili základní desky našeho routeru.

Příjemné bylo setkání s celou řadou linuxových fanoušků i novinářů, kteří si na stánek přišli cíleně popovídat, nebo nás naopak zcela překvapeně objevili při bloudění mezi stánky CeBITu. Zájem byl především o informace o chystané integraci datového sdílení NextCloud a provoz NAS i o nově představený plugin pro zjednodušnou konfiguraci OpenVPN.

Dojmy z CeBITu? Skvělé! Rádi jsme se zúčastnili a akce nám přinesla nejenom množství kontaktů, které se nyní budeme snažit prohloubit, ale také zvýšila naši důvěru v to, že bezpečnost, soukromí a zároveň otevřenost zdaleka nejsou opuštěné a prázdné pojmy. Naopak: zvětšuje se ona menšina uživatelů, která bezpečná řešení vyhledává. Stejně tak se nám potvrzuje, že lidé jsou ochotni pomáhat v boji za vyšší bezpečnost internetu sběrem dat a procesorovým časem svých routerů. Ba dokonce nás uživatelé sami vyzývali k tomu, že by rádi viděli nějakou „gamifikaci” tohoto sběru dat a svého přinosu k hledání bezpečnostních hrozeb, čímž nám nasadili dalšího brouka do hlavy. Alespoň máme s čím přijet na příští CeBIT.

A jen tak mimochodem, poslední březnové dny se účastníme konference MUM 2017 v italském Milanu a následně i dalších akcí. Jejich kalendář budeme publikovat. Pokud se ve vašem okolí nějaká zajímavá IT akce pořádá a rádi byste tam viděli Turris, napište nám!

Kategorie:

Druhý ročník hackathonu AT&T a ČTÚ

Út, 03/21/2017 - 06:10

Je to téměř rok, co jsem na tomto blogu popisoval své dojmy z hackathonu, který v ČR uspořádalo AT&T ve spolupráci s ČTÚ. V roce 2016 se tato akce uskutečnila v Praze a letos bude mít své druhé pokračování, tentokrát v Brně. A stejně jako v loňském roce se jí zúčastní i CZ.NIC jako sponzor speciální ceny pro nejlepší open-source řešení.

Hlavními tématy letošního hackathonu jsou „Internet of Things“ a „Data Analytics“. Obojí jsou to témata, která jsou nám v CZ.NIC nějakým způsobem blízká a již se těším, na zajímavé projekty, které na místě vzniknou. Navíc obzvlášť oblast Internetu věcí by si určitě zasloužila větší podíl otevřených řešení, protože současný stav kdy si každý výrobce vytváří vlastní proprietární řešení vede k situaci, kdy se každou chvíli dočítáme o bezpečnostních dírách v jednotlivých produktech. I proto jsme se rozhodli, že akci podpoříme nejen zmíněnou speciální cenou pro nejlepší otevřené řešení, ale také dáme pořadatelům k dispozici deset kusů routeru Turris Omnia jako otevřené platformy pro případný vývoj IoT řešení.

Pokud tedy budete mít 7. a 8. dubna čas a chuť, přijďte se na hackathon určitě podívat a ideálně aktivně zúčastnit. Pokud mohu soudit podle minulého ročníku, určitě to bude akce, která stojí za to. Tvůrčí atmosféra, kterou na hackathonech zažijete je jedinečná a s trochou štěstí můžete stát u zrodu něčeho nového, velkého a ideálně i otevřeného.

Těším se na shledanou v Brně.

Kategorie: