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
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ý
Zajímavé statistiky a jedno potěšující umístění
Dnes bychom se s vámi rádi podělili o dvě novinky, které se dotýkají tématu, jenž nás velmi zajímá a ve kterém se snažíme co nejvíce angažovat. Jak už možná tušíte, jedná se o bezpečnost uživatelů na Internetu a o hrozby, které na ně číhají. Tentokrát se budeme věnovat novým statistikám týkajícím se bezpečnosti. Začněme nejdříve tou obecnější.
Koncem června spustila společnost Google novou sekci v rámci svého transparency reportu nazvanou Bezpečné prohlížení. Tato stránka umožňuje nahlédnout do statistik získávaných díky jejich službě Google Safe Browsing, která aktivně vyhledává nebezpečné stránky a získaná data nabízí prohlížečům. Ty pak mohou varovat uživatele před návštěvou takovýchto stránek. Možná jste se již také ve vašem prohlížeči setkali s následujícím varováním.
Varování prohlížeče před nebezpečným obsahem
Google Safe Browsing sleduje jak výskyty stránek zneužitých k phishingovým aktivitám, tak stránky sloužící k šíření malware. Statistiky si lze nechat zobrazit podle autonomního systému, nechybí ani rozdělení na stránky záměrně útočné a stránky, které byly pouze zneužity.
K dispozici je také souhrnná mapa, která ukazuje procentuální množství napadených stránek vzhledem k celkovému počtu stránek, které Google v dané zemi kontroloval. Nás může těšit, že z testovaných webů v ČR obsahovala škodlivý malware jen čtyři procenta, což v porovnání s okolními státy není špatné.
Mapa po najetí kurzoru nad konkrétní stát ukazuje
procento nebezpečných stránek nalezených službou Google Safe Browsing.
Je zde také možnost podívat se na autonomní systémy dle regionu. Poskytovatelé služeb v konkrétní zemi se tak mohou podívat, jak si jejich síť stojí v porovnání s ostatními a případně se zaměřit na zlepšení boje s nebezpečným obsahem.
Další příjemnou zprávu nám zanechala společnost Architelos na našem Twitteru. Pogratulovala doméně .cz k dobrému umístění (v sekci Excellent) v jejich reportu týkajícím se bezpečnosti webových stránek provozovaných na jednotlivých doménách prvního řádu. Jejich služba NameSentry, na jejímž základě byl report sestaven, pracuje s daty ze služeb jako jsou Internet Identity, SURBL, Spamhaus, MalwareURL, ZeusTracker, SpyeyeTracker, či Malware Domain List. Toto umístění nás velmi těší, je vidět, že i přes skutečnost, že si .cz doménu mohou registrovat i zájemci ze zahraničí, což vždy zvyšuje riziko nákupu doménových jmen za účelem jejich zneužití, doména .cz počítačové zločince nepřitahuje. Jistě na to mají vliv i pravidla pro nakládání s takovýmito doménami, která jsou jasně zakotvena v pravidlech registrace .cz domény, a také preventivní činnost našeho bezpečnostního týmu, který upozorňuje majitele doménových jmen v případě, kdy dojde ke zneužití jejich doménového jména.
Hledejte nás v tom zeleném sloupečku :-)
Pavel Bašta
Červen v akademii patřil učitelům
Na třetí ročník kurzu Internetové technologie pro pedagogické pracovníky, jak už název napovídá, přijeli učitelé z nejrůznějších míst České republiky, kteří se na svých školách věnují výuce informatických předmětů. Cílem programu bylo představit technologie, pomocí kterých Internet funguje a s nimiž učitelé na většině středních škol studenty detailněji neseznamují – IPv6, DNS a DNSSEC, či to, co najdete na webu http://www.háčkyčárky.cz, tedy používání znaků národních abeced v doménách, tzv. IDN.
Ačkoliv se termíny musely přesouvat kvůli povodňové situaci, která by komplikovala dopravu účastníků na kurz, byly nakonec oba dva obsazeny více než z poloviny. Nebylo snadné vyvážit obsah tak, aby si na své přišli jak učitelé na gymnáziích, tak i učitelé na středních odborných školách, kde se předpokládá hlubší znalost technických témat. Přesto z hodnocení vyplývá, že ač nebyla témata pro všechny stejně zajímavá, splnila akce svůj cíl – představit vybrané internetové technologie těm pedagogům, kteří o nich doposud příliš nevěděli, nebo se chtěli dozvědět více. V závěru dne pak došlo na přiblížení projektů pro školy, jimž se věnují kolegové v našich laboratořích.
Dva kurzy máme již letos za sebou. Ještě jeden plánujeme na 26. září. Pokud víte o někom, komu byste tento kurz doporučili, určitě neváhejte; několik volných míst ještě zbývá. Rezervace je možná na e-mailové adrese akademie@nic.cz. Více informací o projektech pro školy se dozvíte na webu http://www.nic.cz/skoly.
Igor Kytka
Response rate limiting pod drobnohledem
O RRL již krátce psal Ondřej Surý v článku Ochrana obětí před DNS amplification útoky, tak tedy jen v rychlosti oč se jedná. RRL je jedna z metod, jak se poprat s amplifikačními útoky na DNS, která shlukuje podobné odpovědi do tříd a následně omezuje rychlost toku odpovědí v pro danou třídu. Jedná se v podstatě o opak filtrování dotazů na firewallu a výhodou je právě třeba identifikace různých dotazů vedoucí na podobnou odpověď, typicky na neexistující jméno. RRL v současné chvíli implementuje BIND9/10, NSD od verze 3.2.15 a Knot DNS od verze 1.2.0-rc3.
Vzhledem k tomu, že v současné chvíli není tento mechanismus nijak standardizován, každá implementace se chová mírně odlišně. Podívejme se trochu blíže na tři nejzajímavější rozdíly a to, jaký vliv mají na chování serveru pod útokem.
Základní časovou jednotkou pro měření rychlosti toku je vteřina, pro kterou do každé třídy přibyde počet tokenů odpovídající povolené rychlosti. S každou odpovědí se pak token odebírá, a pokud už jsme vše vyčerpali, odpověď zahazujeme. BIND9 k tomu navíc zavádí ještě jedno „makro okno“, které průměruje rychlost toku pro několik následujících vteřin. Zásadním rozdílem je, že v rámci tohoto okna se může počet dostupných tokenů snížit do záporných hodnot, a tím vyčerpat kapacitu pro celý zbytek okna. Jestli je například okno dlouhé 5 vteřin, limit je 10 odpovědí za vteřinu a v první vteřině přijde 50 podobných dotazů, tak následující 4 vteřiny nebude podobné dotazy zodpovídat. Knot DNS ani NSD takový koncept nemají, dá se tedy říct že délka časového okna je 1s. Důvodem je větší férovost odezvy, každá vteřina začíná s čistým štítem, avšak za cenu menší agresivity potlačení nárazových toků.
Co ale dělat v případě, že přijde legitimní dotaz v době, kdy byl vyčerpán počet tokenů? Úplně jej zahodit? Takový dotaz jen velmi těžko rozlišíme od útoku, ale přesto bychom měli dát legitimnímu tazateli možnost získat odpověď a ne jej úplně odstřihnout. Místo toho, aby tedy server dotaz zcela ignoroval, tak odešle prázdnou odpověď s nastaveným TrunCated bitem v hlavičce. Tazatel je pak nucen opakovat dotaz po TCP, na který už dostane odpověď. Takovému mechanismu se říká SLIP (podporují ho všechny implementace). Knot DNS se odlišuje tím, že má počítadlo pro každé vlákno zvlášť, a pro menší rychlost toku není tak přesný. Během testování se ale nepřesnost nijak zvlášť neprojevila a největší vliv má konzervativní výchozí nastavení.
(Zdroj: Comparison of RRL behaviour in BIND9, Knot DNS, and NSD, Dave Knight, DNS-OARC Spring 2013)
Třetí zásadní odlišností je způsob klasifikace odpovědí. Technické memo a BIND9 klasifikují odpověď pomocí:
- Zdrojové adresy (podsítě)
- Dotazovaného jména (nebo zóny v případě chyb, nadřazeného jména pokud je odpověď pokrytá wildcardem)
- Návratové hodnoty (RCODE)
NSD navíc rozlišuje několik podtříd dotazu, např. pokud je dotaz na typ ANY, Knot DNS dotazy navíc ještě klasifikuje podle velikosti. Všechny současné implementace jsou založené na hash tabulkách. Liší se ale výrazně v tom, jakým způsobem řeší kolize. Implementace v BIND9 je založená na přeplňování tabulek, přičemž kolidující klíče se řetězí za sebe (do omezeného počtu). A právě o kolizích probíhala na mailinglistu RRL dost živá diskuze. Abych to vysvětlil, řetězení dobře řeší kolize pokud je zdrojová podsíť různá, ale pořád zůstává možnost kolize hashe dotazovaného jména, které se neukládá celé. Nově ale zavádí potenciální problém, a to že útočníkovi do určité míry možnost kontrolovat množství alokované paměti pro tabulku a ztrácí výkon na procházení zřetězených hodnot.
NSD používá tabulku pevné velikosti, bez řetězení. Netrpí tedy na výše popsané problémy, ale s větší pravděpodobností umožňuje útočníkovi předem spočítat kolidující odpovědi (Birthday attack) v závislosti na velikosti tabulky. Protože není kolize kam řetězit, tak pro danou třídu resetuje počet tokenů, což sice na jednu stranu vylučuje riziko omezení kolidujících odpovědí, ale umožňuje při nalezení dvou kolidujících dotazů rate limiting zcela obejít.
Knot DNS využívá hopscotch hashing, který je velmi dobrým kompromisem s nízkou pravděpodobností kolize (1/32!) při zachování pevné velikosti. Zároveň do klíče přidává náhodně generované tajemství pro znesnadnění predikce kolizí a umožní jen jeden reset počítadla třídy za vteřinu.
Ze zatím dostupných měření na reálných datech vyplývá, že chování všech implementací je i přes popsané rozdíly velmi podobné a liší se především citlivostí u pomalého toku dotazů. Hlavním omezením metody založené na rate limitingu je především nemožnost rozlišit právoplatný dotaz od útoku, což ale při rozumné spolehlivosti není ani prakticky možné. Příliš agresivní omezení by tak mohlo vést k přílišnému zahazování právoplatných dotazů, konzervativní zase k nižší účinnosti. BIND9 doporučuje agresivnější nastavení, Knot DNS je spolu s NSD spíše na konzervativní straně (RRL ve výchozím nastavení vypnuté, v dokumentaci 50 r/s).
Marek Vavruša
Všechno nejlepší!
Už to na tomto blogu několikrát zaznělo, sdružení CZ.NIC sfouklo na dortu patnáctou svíčku, což je u člověka věk, při kterém mu stát dá tolik důvěry, že může požádat o povolení řídit pomalé jednostopé motorové vozidlo. O své vzpomínky na toto období dospívání se již s Vám podělili dva služebně nejstarší zaměstnanci sdružení, Zuzana a Martin. A protože třetí v pořadí jsem již já, dovolte i mně přispět svou vzpomínkou.
Do sdružení jsem vstoupil na konci roku 2003, když jsem se se skupinou podobně smýšlejících lidí snažil otočit kormidlo těžkopádně plující lodě. CZ.NIC v té době rozhodně neměl dobré jméno. Cena domény byla poměrně vysoká, pravidla a nastavení registračního systému příliš nepřipomínala 21. století a mnoho lidí mělo v živé paměti rozporuplně přijímanou migraci na decentralizovaný systém. Sdružení mělo jen minimum zaměstnanců a drtivá většina všech jeho činností, včetně těch klíčových, byla outsourcována. Komentáře tehdejších diskutujících pod články o české doméně by bylo možné v televizi předčítat jedině až po dvaadvacáté hodině. Tedy nic moc okamžik jít s kůží na trh a nabídnout jen další změny a následně ještě jednu migraci. Ani onen pokus o změnu nevypadal ze začátku kdo ví jak. Celkem dlouho trvalo, než došlo k obměně většiny členů představenstva a padlo finální rozhodnutí vyvinout vlastní registrační systém.
Nicméně povedlo se a v roce 2005 již mělo sdružení úplně nové vedení, stanovy, dokonce i v přípravě nové logo, nové podmínky vstupu a začalo nabírat zaměstnance, kteří měli za úkol na zelené louce vyvinout úplně nový a pružnější systém a zcela změnit tvář sdružení. Na svém seznamu neodkladných úkolů jsem měl vyřešit vztah mezi sdružením a státem a po odškrtnutí tohoto políčka byl nejvýše nový registrační systém. Pojmenovali jsme jej FRED a on rostl velmi rychle. Poprvé se v plné kráse a síle mohl ukázat v září 2006, kdy jsme jej nasadili na správu ENUMové domény 0.2.4.e164.arpa. To byl poměrně klíčový milník celého procesu, protože v té chvíli přestal být FRED jen projektem programátorů, ale od této chvíle bylo všechno „doopravdy“. Veškeré změny se musely pečlivě testovat, provádět pouze v odstávkových časech, získávali jsme cenné zkušenosti s provozem.
Ty jsme nejvíce zúročili o rok později, přesně v období 28. až 30. září 2007. V tomto období byl zastaven provoz starého registračního systému a veškerá data byla migrována do FREDa. Bylo to pro mne tehdy úžasné období. Na jednu stranu jsme byli pochopitelně všichni neuvěřitelně nervózní, jestli jsme v našem migračním scénáři, který měl stovky položek někde přeci jenom neudělali chybu, ale na druhou stranu to bylo završení téměř čtyřletého úsilí mnoha lidí. Nervozita byla celkem pochopitelná, neměli jsme v podstatě záložní variantu, sice existovala možnost požádat tehdejšího provozovatele o prodloužení běhu outsourcovaného systému, ale je jasné, že takový krok by měl zcela devastující účinek na pověst sdružení a nás, kteří jsme migraci prováděli. Samotná migrace proběhla až nečekaně hladce s dvaatřiceti hodinovou rezervou a tak jsme těch 32 hodin nervózně čekali na start nového systému, který byl naplánován na 1. říjen, na 10:00. Okamžik nastal, FRED najel a tři vteřiny po startu se začaly registrovat první domény. Skvělá zpráva, ale přesto jsme objevili jednu malou chybičku. Nový systém chránil WHOIS výpisy pomocí Captcha. Takže každý, kdo si chtěl vypsat na webu nějaké informace o doménách, musel přepsat do znaků obrázek. Ačkoliv byl celý systém mnohokrát testován jedné drobné věci jsme si nevšimli. Ano tušíte správně. Zátěžové testy obvykle provádějí automaty. Ty nedokáží přepisovat Captcha obrázky a proto byla tato částečka systému při testech deaktivována. A právě v ní byla chyba, která se za celou dobu neprojevila u ENUMu, protože ten nikdy nebyl vystaven zátěži uživatelů lačných po informacích. Špatné ukládání dočasných dat způsobilo, že při současných přístupech více uživatelů přestal WHOIS fungovat. V ten okamžik nastalo v místnosti, odkud jsme spouštění řídili, hrobové ticho. Nebylo hned zřejmé, že chybička je pouze u WHOIS a že systém jinak bez problémů funguje. Všichni jsme měli velký strach, že jde o něco vážného. Já sám jsem si z toho okamžiku odnesl pár šedivých vlasů, což je při hustotě mé kštice poměrně vidět. Nejvíce duchapřítomnosti ukázal kolega Surý, který hned popadl klávesnici a zhruba do tří minut provedl tu spásnou změnu kódu, která vše vyřešila. Od té doby si dobře pamatuji, že čas je relativní, málo kdy později mi pak přišly tři minuty tak strašně dlouhé. Nicméně to už bylo vše. Systém naběhl, o žádnou doménu jsme nepřišli a tak trochu se začala psát nová epocha sdružení. Cena domény dramaticky poklesla, pravidla registrace a související podmínky se značně zjednodušily, vstoupilo mnoho nových členů, sdružení se přestalo zabývat především samo sebou a nasměrovalo velké množství energie do projektů pro lokální internetovou komunitu. Jen soupis těchto všech projektů by zabral na tomto blogu mnoho místa a pokud se podíváte na některé starší příspěvky, jistě si obrázek uděláte. Velmi dobrým průvodcem může být i strategie sdružení na nejbližší čtyři roky. Změnu vnímaní sdružení nejvíce vystihují již zmíněné příspěvky pod články, které se nás týkají. Netvrdím, že jsou to ze 100 % výkřiky nadšení, ale poměr kritických poznámek se dramaticky zmenšil a pokud už se objeví nějaká kritika, je poměrně vstřícná.
Co dodat na závěr? CZ.NIC pomalu opouští své dětské období, už má poměrně jasno o své budoucnosti a ukázalo, že internetová samospráva může fungovat, a to kvalitně a stabilně. Připojuji se k zástupu gratulantů a přeji vše nejlepší, a hlavně zdraví! Zdraví české doméně! A svobodnému Internetu!
Ondřej Filip