Další zpráva sdružení APWG zabývající se phishingovými útoky přináší výsledky měření za druhé pololetí roku 2012. Vytrvalé monitorování a rychlá reakce na zjištěné phishingové útoky, jimž se věnují oba naše CSIRT týmy (národní CSIRT.CZ, interní CZ.NIC-CSIRT), zdá se odrazují útočníky od zneužívání domény .CZ čím dál více. Zatímco v předchozích dvou pololetích bylo v doméně .CZ 171 (2/2011) a 170 (1/2012) phishingových útoků, v druhém pololetí roku 2012 bylo takových útoků již pouze 135.
Nejvíce zneužívané domény prvního řádu
Došlo také k dalšímu snížení ukazatele počtu phishingových útoků na deset tisíc registrovaných doménových jmen v zóně .CZ. V současné chvíli je tento ukazatel rovný číslu jedna, což oproti minulému pololetí představuje zlepšení o jednu desetinu procenta. Opět také poklesl průměrný uptime phishingových stránek v doméně .cz, a to z předchozích 39 hodin a 41 minut na 24 hodin a 56 minut. Podle výzkumů organizací, které se boji s phishingem věnují, mají phishingové stránky největší výtěžnost během prvních 24 hodin. Tedy již se blížíme hranici, při které se útočníkům přestane phishing v naší národní doméně vyplácet. Jediný ukazatel, který se od minule zvýšil, je medián uptimu. Ten stoupl z 13 hodin a 54 minut na 15 hodin a dvě minuty. I tak si ale myslím, že jsme si celkově velice polepšili.
Na závěr bych chtěl proto touto cestou poděkovat všem administrátorům, se kterými naše týmy při řešení útoků spolupracují, za jejich příkladnou spolupráci při odstraňování phishingových stránek na jimi provozovaných serverech.
Pavel Bašta
S ohýbáním rohů v knihách je konec
Náš svět je plný zkratek. A o světě IT to platí dvojnásob. Abyste se v tom „doménovo-technologicko-internetovém“ prostředí vyznali, připravili jsme pro vás knižní záložky, na nichž najdete ty nejčastější zkratky s vysvětlením.
Jen pro ilustraci vybírám například DNS, PKI, VoIP nebo IPv6 (celkem je jich 32). Po pravdě, nevybral jsem tyto zkratky náhodou. Všechny mají něco společného s Akademií CZ.NIC a s nabízenými kurzy. Právě při návštěvě některého z nich můžete tuto záložku získat a s ní i některou knihu Edice CZ.NIC.
P.S.: Čtenáři elektronických knih mají bohužel smůlu. Elektronické záložky se zatím nekonají.
Igor Kytka
Honeynet: problematické autonomní systémy se příliš nemění
Po půlroční pauze se pojďme opět podívat na statistiky z našeho honeynetu. A začněme rovnou přehledem největších „hříšníků“ – autonomních systémů, z kterých se k nám útočníci od května do konce července připojovali.
Nejčastější útočníci (květen 2013 – červenec 2013)
Tentokrát vede brazilská síť AS28573, která od poloviny července intenzivně šířila tento typ viru Conficker a s více než 30 tisíci uploady mu zajistila první místo v další tabulce zachyceného malware. Tato síť už se v minulosti v našich statistikách objevila a není to vůbec překvapivé, protože podle statistik Shadowserver jí aktuálně patří 12. místo (řazeno podle absolutního počtu IP adres šířících vir Conficker). Infikované je celé 1 % jejího adresního prostoru.
Podobně smutná situace je u tchajwanské sítě AS3462, která se v našich statistikách objevuje taky pravidelně a tentokrát skončila na 6. místě (celosvětově jí patří místo sedmé). Za sledované období se snažila rozšířit 93 různých virů.
Ani třetí v pořadí v naší tabulce není výjimkou. Venezuelská síť AS8048 se snažila šířit 42 virů, z toho čtyři se dostaly i do tabulky deseti nejčetnějších. Tato síť je celosvětově na 29. místě.
Naopak jako výjimky se dají označit polská síť AS196927 a bulharská síť AS42431, které si své umístění zasloužily díky jednotlivcům. V případě polské IP trval útok dva týdny, v případě bulharské osm dní. Osobně mě překvapilo umístění chorvatské akademické sítě AS2108, kde útok trvá s menšími přestávkami stále. Podle zkušeností s naším CESNETem bych očekával rychlejší řešení incidentu.
Pro zajímavost ještě znázornění na mapě, kde je výrazně vidět Brazílie s Polskem. Očekávatelné Rusko zdaleka není tak zajímavé.
Zdroje útoků (květen 2013 – červenec 2013)
V přehledu portů, na které se útočníci připojovali, vede 445 (SMB protokol), výrazně méně připojení pak směřovalo na porty 5060 (SIP), 3306 (databáze MySQL), 1433 (Microsoft SQL Server) a 80 (HTTP).
Cílové porty (květen 2013 – červenec 2013), horizontální osa má logaritmickou škálu
V přehledu zachyceného malwaru vedou různé varianty viru Conficker. Platí, že většinou jednu variantu šíří jeden autonomní systém.
Zachycený malware (květen 2013 – červenec 2013)
Na našem webovém honeypotu mě vedle běžných hledání skriptu setup.php pro phpMyAdmin (viz CVE-2010-3055) zaujal dotaz na soubor /phppath/php metodou POST s tělem <?php echo "Content-Type:text/html\r\n\r\n";echo "___2pac\n"; ?>. Jedná se o pokus zneužít zranitelnost CVE-2013-4878 v Parallels Plesk Panel, která byla zveřejněna 5. června. První útok tohoto typu jsme zachytili v sobotu 8. června, tedy jen o 3 dny později. Ukazuje to, že je důležité neodkládat bezpečnostní aktualizace až po víkendu :-).
Jiří Machálek
K čemu slouží facebookový „like“ scam?
Určitě jste již někdy slyšeli o facebookové hře Farmville. Ale říká vám něco pojem Like-farming? Jedná se o sbírání „lajků“, tedy v podstatě fanoušků, pro konkrétní facebookovou stránku. Vlastně mě k sepsání tohoto blogpostu inspirovala pozvánka, kterou jsem nedávno dostal a která vedla na stránku „Tvůj Rodokmen aneb: Poznej své předky!
Snad ani netřeba zdůrazňovat, že žádný rodokmen nezískáte.
Podobných podvodných stránek vzniká na Facebooku celá řada. Jejich primárním cílem je nějakým způsobem nalákat uživatele, aby se stali fanouškem stránky a zároveň do ní pozvali své další přátele. Za tímto účelem se používají obvykle dvě taktiky: první něco slibuje (lechtivé video s celebritou, výhru iPhonu, iPadu, změnu vzhledu facebookové stránky, či třeba možnost sledovat, kdo si prohlížel váš facebookový profil), druhá je zastrašující (pokud nesouhlasíte se zpoplatněním využívání Facebooku, pak dejte like). Podobným skupinám je tedy vhodné se vyhnout. Pokud si nejste jisti, můžete využít například stránku facecrooks.com.
Cui bono? To je ta otázka, o kterou zde kráčí. Možná si říkáte, k čemu taková stránka může někomu být? Tak například často bývá podmínkou získání slíbené odměny požadavek na vyplnění nějaké ankety. Za to, že věnujete svůj čas jejímu vyplnění, však dostává zaplaceno majitel stránky, Vy se samozřejmě slíbené odměny, například ve formě růžového facebookového profilu, nedočkáte. Jiný způsob výdělku spočívá ve zobrazování reklamy fanouškům stránek nebo v přímém prodeji takto vybudované stránky dalšímu zájemci.
Poptávka po stránce s více než 50 tisíci fanoušky.
A nabídka (stránky již byly prodány).
Nejhorší možnou variantou je zneužití takovéto skupiny k šíření malware, například formou odkazu na video, které prostě musíte vidět. Samozřejmě místo videa budete vyzváni ke stažení přehrávače videa. Tento soubor však ve skutečnosti obsahuje malware, který ukradne vaše citlivá data a použije váš účet k dalšímu šíření odkazů na tento malware.
Doufám, že po přečtení tohoto krátkého článku budete při používání Facebooku zase o trochu obezřetnější a že nedáte zbytečně šanci vykukům, kteří vydělávají na lidské naivitě. Tak schválně, každý kdo dá like na tento článek, tomu se na facebookové stránce zpřístupní možnost sledovat soukromou korespondenci ostatních uživatelů.
Pavel Bašta
Zajímavý případ od kolegů z polského CERTu
Polský bezpečnostní tým CERT Polska uveřejnil 31. července na svých stránkách http://www.cert.pl zprávu, ve které jeho členové popisují, proč NASK (správce registru národní domény .pl) ukončil spolupráci s jedním z registrátorů domén .pl, společností Domain Silver, Inc.
Tento registrátor, jehož oficiálním sídlem byly Seychelské ostrovy, zahájil svou činnost v květnu roku 2012. Od té doby začal CERT Polska pozorovat velký nárůst škodlivých domén .pl. Většina těchto domén byla zaregistrována právě u tohoto registrátora.
Ze všech registrovaných domén (641, stav k 9. červenci tohoto roku) byla pouze jedna doména neškodná. Tou byla přímo doména tohoto registrátora – domainsilver.pl.
Z celkového počtu 404 domén, které obsahovaly škodlivý kód, bylo 179 domén pod správou C&C serverů. Domény, které byly pod správou některého z botnetů, také tyto botnety nebo škodlivý kód distribuovaly. Jednalo se například o malware nebo botnet Citadel, Dorkbot, ZeuS Ice IX, Andromeda, RunForestRun nebo ransomware. Bližší informace jsou k dispozici na stránkách polského CERT týmu.
V doméně .CZ jsme sice zatím nenarazili na případ, kdy by se na podobné záležitosti přímo specializoval registrátor (a doufejme, že i díky podmínkám pro přijímání registrátorů ani nenarazíme), ale i u nás se sem tam objeví podobné případy nakažených domén, resp. stránek. Není jich ale zdaleka tolik jako jinde. Možná je za tím náš nástroj MDM (Malicious Domain Manager), který používáme pro čištění zóny .CZ. Od spuštění pilotní verze této aplikace uběhly více než dva roky a počet opravených nebo chcete-li vyčištěných domén za tu dobu překročil počet 5000.
Michal Prokop
Weby sdružení v novém kabátě
Dosud nejdéle používaný layout webu sdružení CZ.NIC se téměř po šesti letech dočkal faceliftu. Ten dosavadní byl nasazen u příležitosti migrace na nový systém správy domény .CZ v říjnu roku 2007 a s drobnými úpravami plnil svou funkci až do července 2013.
Spuštění redesignovaného webu je zároveň posledním krokem v procesu změny vizuálního stylu sdružení, která byla zahájena loni na podzim spolu s televizní premiérou první série osvětového seriálu „Jak na Internet“.
Kromě hlavního webu www.nic.cz se změna projeví také na všech ostatních webech používajících jednotný vizuální styl sdružení, jako např. labs.nic.cz, edice.nic.cz, www.dnssec.cz, nebo háčkyčárky.cz. Do konce roku 2013 se nového designu dočká také Blog a stránky Akademie CZ.NIC.
Malá exkurze do minulosti
O prvním webdesignu lze v souvislosti s webem www.nic.cz hovořit od poloviny roku 2001.
Roky 2001 – 2004
Tehdy spuštěný web nahradil webové prezentace do té doby kladoucí důraz především na obsahovou stránku (1998, 1999, 2000).
Faceliftu se dočkal o tři roky později v roce 2004.
Roky 2004 – 2006
K významnému redesignu došlo v polovině roku 2006, kdy stěhování sídla sdružení z Prahy 6 na Vinohrady doprovázela také změna vizuálního stylu a s ní i spuštění zbrusu nového webu.
Roky 2006 – 2007
Zatím předposlední a dosud nejdéle používaný layout byl za téměř šest let svého „života“ svědkem celé řady významných momentů v životě sdružení, počínaje úspěšnou migrací na vlastní systém pro správu domén, přes podepsání zóny .cz DNSSEC, spuštění autentizační služby mojeID, až po registraci milionté domény .cz a dvě letošní významná výročí.
Roky 2007 – 2013
Ondřej Písek
CZ.NIC router
V nedávném článku jsme na tomto blogu představili projekt distribuované kybernetické bezpečnosti, na kterém od začátku tohoto roku pracujeme. Hlavní komponentou v navrhovaném systému distribuovaného adaptivního firewallu je speciální domácí router, který monitoruje síťový provoz a je schopen reagovat na potenciální bezpečnostní hrozby, a který vyvíjíme pod kódovým označením „CZ.NIC router“.
V tomto příspěvku si blíže představíme hardware a software navrhovaného zařízení, které by mělo plnit nejen úlohu bezpečnostní, ale mělo by být také plnohodnotným routerem s pokročilými funkcemi.
Operační systém
Pro vývoj operačního systému pro embedded zařízení je dnes možností první volby Linux. Má velmi dobrou podporu existujícího hardware, výbornou síťovou vrstvu, je v této oblasti široce rozšířený a v neposlední řadě je svobodný. Často navíc není třeba implementovat ani zbytek systému na zelené louce, ale je možné najít existující svobodný projekt, který je blízký zamýšlenému využití. To je výhoda svobodného softwaru.
V našem případě bylo hned několik projektů, které byly svým zaměřením blízké našemu záměru. Z nich jsme nakonec vybrali jako základ pro další práci systém OpenWrt. Pro ty z vás, kteří se s ním dosud nesetkali, stručně zmíním, že se jedná o specializovanou Linuxovou distribuci určenou právě pro domácí routery a vyladěnou pro jejich specifické potřeby. Systém tedy obsahuje výbornou podporu pro síťové technologie a je optimalizovaný pro malé paměťové kapacity běžných domácích routerů.
Jako základ vývoje operačního systému pro „CZ.NIC router“ jsme tedy použili OpenWrt, které upravujeme a rozšiřujeme o potřebnou funkcionalitu. V případech, kdy to bude dávat smysl, počítáme s poskytnutím úprav zpět do OpenWrt, aby z nich mohla profitovat jeho poměrně rozsáhlá uživatelská komunita.
Software
Jednou z výhod Linuxu jako jádra pro embedded operační systém je dostupnost velkého množství kompatibilního softwaru. OpenWrt navíc obsahuje balíčkovací systém, který umožňuje velice pohodlně do systému doinstalovat aplikace podle vlastní potřeby. Zároveň je možné si pomocí tohoto systému sestavit základ operačního systému na míru.
V našem případě se jedná např. o použití validujícího DNS resoveru Unbound namísto výchozího DNSMasq nebo výměna minimalistického SSH serveru Dropbear za OpenSSH.
Uživatel si pak může sám doinstalovat např. server pro sdílení souborů v domácí síti nebo třeba bittorrent klienta.
Hardware
Jednou ze zajímavých částí projektu „CZ.NIC router“ je vývoj vlastního hardwaru. K tomuto kroku jsme se odhodlali poté, co jsme prozkoumali na trhu dostupná zařízení a zjistili, že žádné plně nevyhovuje našemu záměru. Pro analýzu síťového provozu v reálném čase je přece jen třeba výkonnější hardware a větší množství paměti, než jen pro běžné routování. Do budoucna navíc počítáme s dalším vývojem softwaru pro bezpečnostní sondu a potřebujeme tedy dostatečnou výkonnostní rezervu.
Zde je krátký výčet důležitých komponent a vlastností navrhovaného systému:
* procesor Freescale P2020 se dvěma jádry architektury PPC taktovaný až na 1.2 GHz
* dedikovaný WAN port (s nezávislým připojením do procesoru)
* 4 LAN porty připojené přes výkonný switch chip
* SO-DIMM slot pro DDR3 paměť (osazený pravděpodobně 2 GB paměti)
* 2 miniPCIe sloty, z nichž jeden bude obsazen výkonnou Wifi kartou kompatibilní s 802.11a/b/g/n
* externí Wifi antény
* flash paměť minimálně 128 MB
* slot na micro SD kartu
* 2x USB 2.0 port
Při návrhu hardwaru jsme se snažili myslet také na jeho možnou rozšiřitelnost. Samozřejmostí tak budou dva USB 2.0 porty pro připojení disků nebo tiskárny. K dispozici bude ale také např. sériový UART výstup přístupný jednoduše přes USB rozhraní a na desce zařízení budou vyvedeny také další sběrnice (GPIO, I2C a SPI) do tzv. pinheaderu, který umožní případné připojení dalších zařízení, podobně jako třeba u platformy Arduino.
Celkově se tedy bude jednat o poměrně slušně vybavené zařízení, které by mělo svým výkonem výrazně předčit cokoli, co je dnes na trhu domácích routerů k dispozici a poskytnout tak dostatek výkonu ke všem potřebným bezpečnostním analýzám.
Co je na něm ale asi nejzajímavější z mého pohledu – bude to plně otevřené řešení, jehož návrh bude zveřejněn pod open source licencí, a které bude moci nést nálepku „Made in Czech Republic“. A takového hardwaru dnes moc nenajdete…
Bedřich Košata
Smějeme se s DNS
Možná by se mohlo zdát, že svět kolem DNS je suchý a plný pouze jedniček a nul. Naštěstí i DNS komunita má svůj specifický humor a cílem tohoto krátkého příspěvku je upozornit na dva zdroje vtipů spojených s DNS.
První studnice humoru je účet @DNS_BORAT na Twitteru; za velký úspěch považujeme to, že se Knot DNS dostal i do hledáčku DNS_Borata:
Was been wonderful day compare djbdns source code with Knot core dumps; very little differences
— DNS Borat (@DNS_BORAT) July 10, 2013
Mimochodem *_Borat účtů je více: @DEVOPS_BORAT, @Sysadm_Borat nebo @X509_Borat.
Další výborný (obrázkový) blog je DNS Reactions, kde (také neznámý) autor z DNS komunity komentuje DNS pomocí animovaných gifů.
I zde jsme se zjevně stali již součástí popkultury – resp. ten fakt, že ve sdružení pracuje příliš mnoho Ondřejů a velmi často se stává, že si nás cizinci pletou (někdy dostávám pozvánky na schůzky za pět minut, které jsou na druhé straně zeměkoule).
Autor blogu to okomentoval v příspěvku Asking for „Ondrej“ in CZ.NIC, který doplnil tímto obrázkem:
Nakonec bych opět upozornil na sesterský blog DevOps reactions ze života adminů a programátorů.
Ondřej Surý
OpenID Connect na cestě
Je to více než rok, co jsem poprvé psal o nové verzi OpenID protokolu nazvané OpenID Connect. Jeho vývoj se od té doby samozřejmě o dost posunul. Před necelým měsícem byl dokončen další významný milník v návrhu této sady specifikací a to je určitě příležitost zmínit se o aktuálním stavu. Pro připomenutí, OpenID je otevřený protokol pro jednotné přihlašování a jeho nová verze Connect je postavena nad moderním autorizačním protokolem OAuth 2.0. Oproti předchozí verzi OpenID 2.0 jsou jeho předností například mnohem jednoduší implementace, připravenost pro mobilní platformy anebo možnost použít email jako přihlašovací jméno.
Práce na novém protokolu začala v březnu 2010 a nyní byl publikován druhý tzv. Implementers Draft – tzn. verze specifikací, která prošla připomínkováním několika implementátorů. Kromě toho, že se průběžně vyvíjené implementace testují v rámci rozsáhlých testů interoperability, existuje již několik produkčních nasazení, kde je možné Connect použít a to např. Google, PayPal nebo Ping Identity. V tuto chvíli asi nejvíc postup blokuje finalizace některých specifikací, na kterých Connect závisí a které jsou vytvářeny podobně jako OAuth 2.0 na půdě IETF. V této organizaci je bohužel odhadováni termínů velká loterie. Přesto existuje orientační plán, při jehož splnění by finální verze specifikací měla být vydána v prosinci letošního roku.
Za vývojem všech OpenID specifikací stoji OpenID Foundation, která sdružuje společnosti jako Microsoft, Google nebo Facebook; vydávání nových specifikací se zde řídí přesnými pravidly. Finální verzi musí členové nakonec odhlasovat. Nová verze OpenID není jedna ucelená specifikace. Naopak, součástí balíku je 8 dokumentů pro jednotlivé oblasti a tyto ještě navíc navazují na řadu dalších specifikací, které nejsou specifické pro OpenID a jejichž vývoj probíhá v rámci IETF. Pojďme si tedy projít jaké jsou základní stavební bloky OpenID Connect.
Spodní vrstvu tvoří víceúčelový autorizační protokol OAuth. Ten má v zásadě za úkol předat mezi třemi entitami (uživatelem, autorizačním serverem a službou) souhlas s nějakou akcí. Specifikace tohoto protokolu ve verzi 2.0 vznikala v rámci pracovní skupiny OAUTH při IETF a po dvou letech práce nakonec vyšla loni na podzim v podobě dvou standardů RFC6749 a RFC6750. Bylo kolem toho hodně dusno, protože jeden z autorů původní verze protokolu, který tento protokol do IETF přinesl, dost ostře s finální verzí nesouhlasil. Nakonec hlasitě zkritizoval všechno, co bylo dosaženo, včetně fungováni IETF a od druhé verze protokolu se distancoval.
Pracovní skupina vydáním dvou RFC neskončila a pracuje na dalších rozšířeních protokolu. Pro Connect jsou nejdůležitější dvě. První z nich přidává automatickou registraci služeb. V základní verzi protokolu se totiž předpokládá, že každá služba bude svým autorem manuálně registrována k autorizačnímu serveru. Jedna z vlastností OpenID je, že služby mohou využívat předem neznámý OpenID server, což je možné právě pouze s využitím automatické registrace.
Druhé rozšíření přidává k základní verzi protokolu přenos tzv. prohlášení o identitě (assertion). Autorizační server v něm kromě své identifikace uvede i jednoznačnou identifikaci přihlášeného uživatele. Právě díky této identifikaci pak může služba ve své vlastní evidenci uživatele najít a umožnit mu přihlášení. Podobně jako velké množství dalších specifikací vznikajících v IETF i zde se začal prosazovat jazyk JSON na úkor XML. Connect bude také využívat prohlášení v jazyku JSON a označované jako JWT (JSON Web Token).
Aby bylo ono prohlášení zmíněné v předchozím odstavci důvěryhodné, musí být podepsané. Jazyk JSON je ovšem poměrně mladý a tak neobsahuje některé vlastnosti, které jsou například v XML již dlouhá léta běžné. Jednou z těchto vlastností jsou právě digitální podpisy, které v XML řeší prověřené rozšíření xmldsig . Tento nedostatek se v IETF snaží napravit pracovní skupina JOSE. Skupina pracuje na čtyřech dokumentech a to JSON Web Algorithms (JWA), JSON Web Encryption (JWE), JSON Web Key (JWK) a JSON Web Signature (JWS). Bohužel ale neschopnost konsenzu finální vydání RFC oddaluje a skupina autorů OpenID Connect je z toho poměrně rozladěna.
Poslední klíčovou závislostí, která vzniká v IETF, tentokrát v pracovní skupině APPSAWG, je protokol webfinger. Tento protokol hraje roli ve fázi OpenID komunikace označované jako „discovery“. Služba se při ní snaží z poskytnutého identifikátoru zjistit, jaká je adresa OpenID serveru se kterým má pro přihlášení komunikovat. Rozhodnutí používat webfinger místo vlastního řešení SWD (Simple Web Discovery) bylo poměrně významnou změnou ve specifikacích OpenID Connect a došlo k ní letos v lednu. Protokol webfinger bude univerzální protokol pro zjišťování dodatečných informací o nějakém zdroji na internetu. Např. pro přihlášení uživatele provede služba po zadání uživatelského jména user@example.com standardní http dotaz na example.com/.well-known/webfinger?resource=acc://user@example.com. Výsledek ve formě JRD (JSON Resource Descriptor) bude obsahovat mimo jiné i adresu OpenID serveru, se kterým se spojit.
Pro zájemce o podrobnější informace o OpenID Connect doporučuji souhrnnou prezentaci jednoho z autorů. Jak je vidět, autoři OpenID Connect si dali nelehký úkol vytvořit standard, který bude skládat obecné technologie do použitelného celku. Historický vývoj specifikací pěkně ilustruje následující obrázek:
OpenID Connect je technologie, od které si svět správců identit hodně slibuje a jejíž vývoj byl také oceněn významnou cenou na loňské konferenci European Identity & Cloud Conference. Jeho vývoj se posouvá, byť možná pomalým tempem, ke svému cíli. Nezbývá než doufat, že tato technologie své příznivce nezklame a podaří se jí po jejím dokončení rychle rozšířit mezi služby na internetu.
Jaromír Talíř
Vše, co jste kdy chtěli vědět o zabezpečení podpisu zóny .cz (ale báli jste se zeptat)
Možná jste někdy přemýšleli, jakým způsobem je zajištěna bezpečnost při podepisování naší národní domény .cz a zda podepsání vaší vlastní domény nemůže ohrozit špatné zabezpečení domény nadřazené, tedy té .cz. O ceremonii kolem generování klíče KSK pro kořenovou zónu a o jeho zabezpečení jste se mohli dočíst například v tomto článku. Náš kolega Ondřej Surý je totiž jedním ze sedmi lidí na světě, kteří vlastní SMK kartu nezbytnou pro obnovení KSK klíče kořenové zóny. Jeho rady a zkušenosti nám také pomohly při vytváření našich vlastních procesů a pravidel nutných pro co nejbezpečnější provozování DNSSECu v zóně .cz.
Aby byla zvýšena bezpečnost při nakládání s KSK klíčem, je jeho správa oddělena od správy ZSK klíčů. Ty jsou používány při podepisování zóny pomocí DNSSEC a slouží k podpisu všech záznamů v zóně, zatímco KSK klíč slouží pouze k podepisování všech DNSKEY záznamů.
Členové KSK týmu při KSK ceremonii
Samotné vybavení nezbytné pro realizaci KSK ceremonie, včetně notebooku, zařízení s uloženým KSK klíčem i bootovacího CD s Linuxem je uloženo v trezoru v sídle našeho sdružení. Vlastně to není tak docela přesné, protože v trezoru je ještě jedna schránka s vlastním zámkem, ve které jsou tyto nezbytnosti uloženy. Každý z členů KSK týmu má klíč pouze od trezoru, nebo od vnitřní schránky. Není tedy možné, aby někdo z KSK týmu sám vyjmul z trezoru jakoukoliv součást vybavení pro KSK ceremonii. Další kopie KSK klíčů a bootovacího CD jsou pro případ katastrofy uloženy také v trezoru banky.
Notebook má fyzicky odpojené bezdrátové sítě a je z něj vyjmutý harddisk, aby nebylo možné se na něj jakýmkoliv způsobem bezdrátově připojit a abychom se vyhnuli riziku nějakých zbytkových dat v cache, uložených mimo naši kontrolu. K bootování se používá CD s Ubuntu 12.0.4 LTS, upraveným pro potřeby ceremonie.
Pokud jde o generování nového KSK klíče, je při generování klíčů vždy přítomen jeden zástupce managementu. Po vygenerování nového klíče je získán hash tohoto klíče, který je zaprotokolován. Podepsané kopie dokumentu jsou následně rozdány všem držitelům klíčů od trezoru (členům KSK týmu), aby si kdykoliv v průběhu ceremonie mohli zkontrolovat, že se používá správný KSK klíč.
V případě potřeby podepsat novou sadu ZSK klíčů je tato nová sada podepsána GPG klíčem ZSK týmu a předána zástupcům KSK týmu. Ti musí být vždy minimálně dva a po celou dobu ceremonie se pohybují společně. Skript, který se stará o samotné podepsání, je zkontrolován ještě před podepsáním nové sady a to proto, aby byla žádost podepsána správným GPG klíčem ZSK týmu. Po podepsání je výsledná podepsaná sada ZSK klíčů opět podepsána pomocí GPG klíče KSK týmu tak, aby si následně členové ZSK týmu mohli být jisti, že manipulují se správnou sadou klíčů.
Celá ceremonie pro podepisování zóny .cz může působit jako poměrně složitá. Naším cílem však bylo poskytnout držitelům domén v zóně .cz jistotu, že ke kompromitaci KSK klíče a tím ohrožení bezpečnosti jejich domény nemůže dojít.
Pavel Bašta