Je to přibližně rok, co jsme spustili službu mojeID. Nebojte se, neplánuji zde na blogu udělat nějaký sáhodlouhý rozbor toho, co se nám za tu dobu povedlo či nepovedlo. Konečně to jsem v podstatě provedl nad otázkami pana Vyleťala nedávno na Lupě.
Pro úspěch této služby je pochopitelně klíčový přístup poskytovatelů služeb, například e-shopů či internetových vydavatelství. No a právě v případě druhé jmenované skupiny se nám podařilo za ten rok „získat“ dva významné zástupce. Prvním je Internet Info, které adaptovalo většinu svých webů. Druhým je mediální skupina Economia, jež zahájila spolupráci se svým portálem Volny.cz.
Po našem upozornění na první narozeniny nám napsalo pár gratulantů, za což jsme pochopitelně vděční. Asi nejlepším způsobem nám ale poblahopřál právě další mediální dům a to opět zvučného jména. Mladá Fronta a.s. se rozhodla využít výhody této služby a implementovala podporu mojeID na osmnácti svých webech jako jsou například Živě.cz, Mobilmania či E15.cz.
Děkujeme tedy tomuto milému gratulantovi! Ať vám mojeID slouží!
Ondřej Filip
Proaktivita nebolí
I když v procesu incident handlingu vystupují obvykle národní CSIRT týmy spíše jako jakýsi „institut poslední záchrany“, rozhodně by měly dle svých možností a v rámci svého pole působnosti také aktivně upozorňovat na existující i potencionální bezpečnostní incidenty. I my se v rámci našeho týmu CSIRT.CZ snažíme nejen co nejefektivněji řešit reportované incidenty, ale pokud máme příležitost, chceme být proaktivní také v přístupu k bezpečnosti českého internetového prostředí. Jak může tato proaktivita vypadat v reálu si ukážeme na vybraných příkladech z poslední doby.
Před několika dny jsme kontrolovali jednu internetovou stránku kvůli podezření na šíření virové nákazy; jednalo se o web, který se přímo zabývá hackingem. Na něm jsme narazili na článek informující o možných zranitelnostech některých internetových stránek státní správy. Šlo o chyby v rozsahu od XSS, přes SQL injection, až po možnost procházet obsah adresářů.
Uvedené zranitelnosti mohou vést k různým způsobům zneužití – získání neoprávněného přístupu k informacím, změny obsahu stránek, či útoku na uživatele takovéhoto webu. Z těchto důvodů jsme riziko vyhodnotili jako vysoké a rozhodli jsme se informaci o zveřejnění těchto bezpečnostních problémů zaslat správcům jednotlivých stránek.
Dle dlouhodobé zkušenosti našeho týmu velká část správců na incidenty reaguje opravením reportovaného problému, avšak na naši původní zprávu již většinou neodpoví. Stejně tomu bylo i v tomto případě. V současné chvíli většina z problematických nastavení na stránkách již není, reakci ale máme pouze od jednoho ze správců. Pro nás je však nejdůležitější, že se nám i tímto krokem podařilo přispět k větší bezpečnosti uživatelů internetu a také ukázat, že národní bezpečnostní tým nespoléhá pouze na nahlášené incidenty.
Příkladem jiného druhu proaktivity může být i nedávná akce CSIRT.CZ – rozeslání informačních dopisů správcům DNS serverů, u kterých existuje vysoké riziko možného útoku pomocí DNS cache poisoningu. S pomocí Laboratoří CZ.NIC jsme při této akci oslovili více jak 1400 firem a institucí v rámci celé republiky. Zatím nemáme přesná data o úspěšnosti celé akce, avšak při první vlně, kdy jsme zkušebně odeslali prvních 100 dopisů, byla úspěšnost, tedy změna konfigurace DNS serveru směrem k lepšímu zabezpečení, okolo 13 procent.
Dalším aktuálně provozovaným proaktivním prvkem v rámci CSIRT.CZ je například detekce útoků pocházejících z počítačových sítí v České republice za pomoci intrusion detection system (IDS), který je provozován ve spolupráci se sdružením CESNET. Tento systém po zachycení pokusu o útok automaticky informuje správce příslušné sítě, který tak má možnost ihned reagovat na vzniklý incident a zamezit případnému průniku do dalších systému nebo šíření virové nákazy.
Osobně doufám, že počet proaktivních prvků v rámci provozu národního CSIRT týmu bude narůstat a že vás tak v budoucnosti budeme moci informovat o dalších úspěšně zrealizovaných akcích CSIRT.CZ směřujících k větší bezpečnosti „sítě sítí“.
Pavel Bašta, CSIRT.CZ a CZ.NIC-CSIRT
Biorytmy v DNS provozu
Ať chceme nebo nechceme, celý náš život je řízen rytmy okolního prostředí. Některé vycházejí z fyzikální podstaty našeho světa, jako střídání noci a dne při otáčení naší planety kolem její osy, či cyklus ročních období při její rotaci kolem slunce. Jiné, jako měsíce či týdny, jsme si vytvořili uměle (možnost souvislosti délky týdne s dobou potřebnou ke stvořením světa nechám na kritickém posouzení laskavého čtenáře), ale jejich vliv na nás není o mnoho menší. Koneckonců kdo z nás nikdy netrpělivě nečekal, až se mu účtu konečně opět po měsíci objeví výplata…
I přesto, že počítače jsou věci (zatím) neživé, biorytmy, které řídí život člověka se přenášejí i na ně. V případě CZ.NIC můžeme tyto sledovat na provozu našich DNS serverů a právě tomuto tématu bych rád věnoval dnešní krátký příspěvek.
Na následujícím obrázku se můžete podívat na ukázku toho, jak vypadá například běžný měsíční provoz na našich DNS serverech.
Na první pohled je tu patrné střídání dne a noci a hned na ten druhý také týdenní cyklus s výrazně nižším provozem o víkendu.
Denní cyklus si můžeme blíže prohlédnout na následujícím obrázku.
Na něm je zobrazena průměrná středa v našem DNS provozu za posledních cca 20 měsíců. Protože jsou data zprůměrována přes relativně dlouhou dobu, vyhladily se případné výkyvy v provozu. Z grafu můžeme vyčíst například fakt, že minimální provoz je cca kolem 4. hodiny ráno a přibližně mezi 5. a 10. hodinou se provoz zdvojnásobí s tím, jak lidé přijíždějí do práce, zapínají počítače a začínají brouzdat. Kolem 12. hodiny je malý ale patrný útlum, kdy lidé postupně odcházejí na oběd, aby se posíleni opět vrhli do práce a způsobili tak maximum aktivity mezi 14. a 15. hodinou. Poté aktivita mírně klesá a po posledním záchvěvu, který najdeme kolem 20:00, rychle upadá k nočním hodnotám.
Na dalším grafu najdeme podobně vytvořený průběh průměrného týdne.
Ten nám kromě zhuštěného náhledu na typický pracovní den s jeho přestávkou na oběd a večerním krátkým vzrůstem aktivity ukazuje, jak se vyvíjí provoz od pondělí do neděle. Zatímco první čtyři pracovní dny jsou téměř totožné, v pátečním průběhu je již zřetelně vidět pracovní únava a v odpoledních hodinách naplnění touhy po brzkém odchodu domů, které se projeví výrazně rychlejším a větším poklesem aktivity.
Víkendový provoz je pak o poznání slabší, se zvýšenou aktivitou v neděli večer, která je srovnatelná s páteční.
Pokud si po přečtení předchozích řádků říkáte s Cimrmanem, „To ani nemusel psát. To každý ví.“, mám pro vás ještě jeden graf. Ten sice také nepřekvapí, ale alespoň je v něm nějaká věda.
Jedná se o výsledek analýzy periodicity DNS provozu získaný Fourierovou transformací vstupních dat (pro přehlednost je uveden jen výřez grafu). Kromě silné denní periodicity je zde vidět i závislost týdenní. Za zmínku pak stojí také slabší zastoupení period kolem 0,5 a 3,5 dne. První z nich je způsobená výše zmíněným poklesem provozu kolem poledne, zastoupení druhé pak souvisí s náhlými změnami mezi pracovními a víkendovými dny.
Doufám, že pro vás byla pozorování z tohoto článku zajímavá a že vás třeba, podobně jako mě při psaní, přivedou k zamyšlení nad tím, jak moc jsme rytmy okolního prostředí ovlivňováni a kam vlastně až tento vliv sahá.
Bedřich Košata, Laboratoře CZ.NIC
Ospalé evropské září
I když v srpnu zmizelo 8,5 miliónu IPv4 adres, přesto se datum vyčerpání adres v dalším RIRu oddálilo. Jak je to možné? Je to způsobeno tím, že Evropané, kteří jsou konci IPv4 aktuálně nejblíže, si tak trochu prodloužili prázdniny a alokovali v podobném tempu jako v srpnu. Skončili tak na třetím místě. Nejméně si vyžádali Afričané, kteří při pouhých jedenácti schválených žádostech alokovali dokonce ještě méně než „vyprázdněný“ region Asie-Pacifik. První skončili překvapivě obyvatelé Latinské Ameriky, kteří spotřebovali téměř polovinu všech adres. Situaci ilustruje následující graf.
Dlužno podotknout, že na prvenství Latinské Ameriky se podepsaly především dvě velké alokace. Global Village Telecom alokoval v Brazílii 2 milióny adres a polovinu této sumy si vyžádal Telecom Argentina. Každopádně běžné tempo v tomto regionu bývá nízké, a tak se konec IPv4 zde příliš nepřiblížil.
Z pohledu jednotlivých zemí lze konstatovat, že i přes tyto velké alokace nebyla Brazílie ani Argentina největším konzumentem IPv4 adres. Nejvíce jich tentokrát alokovaly Spojené státy, na které obvykle připadne většina spotřeby severoamerického regionu. Rozdělení alokací podle států ukazuje následující graf.
Ani situace kolem IPv6 alokací nebyla nijak zásadně významná, bylo alokováno 146 IPv6 prefixů, z toho jeden směřoval i do České Republiky. Tímto se počet tuzemských IPv6 zvedl na ve dvojkové soustavě číslo 128.
Druhý slabší měsíc již pohnul se předpovědmi konce IPv4 v Evropě, což je jistě příjemná zpráva. Aktuálně to vypadá, že bychom mohli mít IPv4 adresy ještě na začátku léta. Je dost dobře možné, že jde již o přímý důsledek restriktivní politiky RIPE. Uvidíme, jestli to potvrdí i příští měsíc. Vzhledem k tomu, že tento příspěvek je psán poněkud později a máme téměř jednu třetinu října za sebou, mohu prozradit, že alokační tempo se zatím nezrychlilo.
Ondřej Filip
Kouzlo standardizovaného řešení
Je tomu přibližně čtvrt roku, co do datových schránek přibyla možnost rozšířit autentizaci přihlašovacím jménem a heslem o hesla jednorázová (OTP – One Time Password). Toto rozšíření umožňuje výrazně zvýšit zabezpečení datové schránky před prolomením či odcizením hesla.
Jednorázová hesla v datových schránkách si může uživatel buď generovat na mobilním zařízení a nebo nechat zasílat pomocí SMS. Vzhledem k tomu, že druhá možnost je placená, upne se asi většina zájemců o tuto funkci k variantě první. Díky tomu, že se programátoři datových schránek rozhodli v tomto případě použít standardní algoritmus pro jednorázová hesla (RFC 4226), je možné pro jejich generování využít aplikace třetích stran.
Datové schránky oficiálně podporují tři různé aplikace pro platformy iOS, Android a Java ME. Použití standardizovaného OTP algoritmu by však mělo umožnit využít i další podobné programy a dát tak uživatelům větší možnost volby. Jednou z aplikací tohoto druhu je Google Authenticator.
Google zavedl jednorázová hesla jako volitelnou možnost při přihlašování k účtu v únoru toho roku. Způsob jakým se jednorázová hesla u Google aktivují a používají je z pohledu uživatele trochu odlišný, ale základní myšlenka doplnit standardní hesla o další autentizační prvek je stejná. Google by však jako jedna z největších IT firem současnosti asi jen těžko přenesl přes srdce použití aplikace třetích stran pro potřeby vlastních uživatelů a vznikl tak již zmiňovaný Google Authenticator. Ten implementuje stejný standardní algoritmus generování OTP a podporuje platformy iOS, Android a Blackberry (a pro potřeby serveru obsahuje také PAM modul).
Protože OTP používám jak pro datové schránky, tak pro svůj Google účet a protože jako zaměstnanec CZ.NIC LABs musím být od přírody zvědavý, zajímalo mě, jestli půjde Google Authenticator použít i pro datové schránky.
Ukázalo se, že to opravdu jde a jediná komplikace je ve formátu v jakém se předává vstupní tajný klíč mezi serverem datových schránek a mobilní aplikací při prvotní aktivaci OTP. Zatímco datové schránky a jimi doporučované aplikace používají hexadecimální (tedy Base16) formát, Google Authenticator používá Base32. Celý problém použití Google Authenticatoru pro datové schránky se tedy redukuje na triviální úkol převodu mezi těmito dvěma kódováními.
Aby to však nebylo příliš jednoduché, trochu jsem si úlohu zkomplikoval. Google Authenticator totiž oproti ostatním aplikacím nabízí jednu vlastnost, kterou každý, kdo musel přepisovat 40 znaků v hexadecimálním zápisu z mobilu do počítače, určitě ocení – synchronizaci tajného hesla mezi serverem a mobilním zařízením pomocí QR kódu.
Abych již dále neprotahoval již tak dlouhý příspěvek, výsledkem je mini „aplikace“ v čistém JavaScriptu, kterou najdete na konci příspěvku. Ta umožňuje vygenerovat si na straně uživatele v prohlížeči tajný klíč, který poté pouze zkopíruje do systému datových schránek a zároveň jej přes QR kód nahraje do Google Authenticatoru na svém mobilu. Není tedy potřeba nic přepisovat a kontrolovat a pokud už Google Authenticator používáte, ani instalovat kvůli datovým schránkám další aplikaci.
Na závěr tedy nezbývá než pochválit tvůrce datových schránek za to, že si na rozdíl od některých dřívějších rozhodnutí tentokrát vybrali standardizované řešení. Usnadnilo to práci jim i uživatelům a dalo nám to možnost větší volby.
Poznámka: Protože celý proces generování tajného kódu i odpovídajícího QR kódu probíhá ve vašem prohlížeči, nemusíte se bát uniku informací a jejich potenciálního zneužití.
Bedřich Košata, Laboratoře CZ.NIC
P.S.- pokud nad tímto textem nevidíte QR kód, váš prohlížeč pravděpodobně neumí HTML canvas (např. IE), který je nutný pro generování QR kódu na straně klienta.