Hosting

Přihlášení

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

Rok 2018 STOPonline.cz v číslech

Pá, 01/18/2019 - 09:51

Loňský rok přinesl STOPonline.cz rekordní množství incidentů. Zatímco v roce 2017 linka obdržela 1 397 hlášení, v roce 2018 jich bylo již 2 445, tj. o 75 % více.

Hlavní příčinou nárůstu počtu hlášení bylo především květnové ukončení provozu policejní hot-line, ze kterého jsou nyní návštěvníci přesměrováváni právě na STOPonline.cz.

Z celkového počtu hlášení se sice dětské pornografie týká v relativním vyjádření jen necelá osmina případů, v absolutních číslech však počet těchto hlášení i jejich závažnost významně roste, což nejlépe ilustruje počet případů (často hostovaných v zahraniční) nahlášených do mezinárodní databáze ICCAM provozované INHOPE ve spolupráci s INTERPOLem. Zatímco v roce 2017 jsme do databáze nahráli 49 stránek, v loňském roce se jednalo již o 371 případů. Podobný podíl jako dětská pornografie mají hlášení s tzv. dětskou nahotou, které kolegyně Kateřina Vokrouhlíková trefně popisuje jako „Fotografie vystavované na Internet s myšlenkou, že všem ukážu, jakou krásnou mám rodinu a jak roztomilé jsou mé děti. Bohužel pod těmito fotografiemi vidí někteří lidé i něco jiného než roztomilost a díky tomu se ze zdánlivě nevinné fotografie stane během chvilky dětská pornografie.“

Nejvíce hlášení STOPonline.cz skrývají statistiky vytvářené dle mezinárodní metodiky pod položkou „Jiný obsah“ zahrnující např. nevhodné komentáře na sociálních sítích nebo upozornění na podvodné e-shopy, kterých přibývá zejména v předvánočním období.

Čísla spojená s nelegálním obsahem si pak dovolím uzavřít poslední (z roku 2017) statistikou znázorňující podíl jednotlivých zemí na hostingu dětské pornografie (CSAM), kde se Česká republika řadí s méně než 1 % mezi ty nejúspěšnější země. Na druhé, odvrácené straně žebříčku, pak stojí v Evropě Nizozemí (51 %), Francie (18 %) a Švédsko (10 %). K pozitivnímu obrazu České republiky v tomto ohledu jistě přispívá i skvělá spolupráce s jednotlivými ISP, díky čemuž se některé případy hostování dětské pornografie daří odstranit již do několika málo hodin od nahlášení.

 

Kategorie:

Česká republika učinila první krok k použití elektronických občanek v zahraničí

St, 01/02/2019 - 10:40

Necelý půlrok od zahájení vydání nových elektronických občanských průkazů poskytlo Ministerstvo vnitra jejich podrobný popis ostatním členským státům a zahájilo tak proces vedoucí k jejich vzájemnému uznávání v zahraničí dle nařízení eIDAS.

Česká republika poskytla popis tzv. eID schématu jako 11. země v Evropě. Jako první tak učinilo Německo, jehož elektronické občanské průkazy by mělo jít od 29. září 2018 použít k přihlašování k vybraným službám e-Governmentu v jiných evropských zemích. Možnost reálného použití v mnoha zemích stále provázejí praktické problémy. Anders Gjøen z DG CONNECT ve své prezentaci na Trust Services Forum v této souvislosti uvedl, že Evropská komise již řeší první stížnosti nespokojených občanů, jejichž počet bude zřejmě narůstat.

Používat české elektronické průkazy pro přihlašování k zahraničním službám e-Governmentu by mělo být možné po uplynutí všech lhůt nejdříve od poloviny roku 2019, závazná povinnost pak nastane ostatním státům až na konci roku 2020. V návaznosti na zákon č. 250/2017 Sb., o elektronické identifikaci by v budoucnu mělo být možné v případě jejich zájmu podobné využití umožnit rovněž soukromoprávním poskytovatelům identit, jako jsou např. banky, mobilní operátoři nebo naše služba mojeID.

Technická stránka vzájemného uznávání eID a možnosti přihlásit se prostřednictvím českých el. občanek ke službám e-Governmentu v jiné členské zemi bude realizována prostřednictvím tzv. eIDAS uzlu, který od září v rámci Národní identitní autority provozuje pro Správu základních registrů naše sdružení.

Kategorie:

Aplikace Open Nettest nabízí v nové verzi další odznaky za věrnost

St, 12/26/2018 - 22:00

Děti zaměstnanců sdružení CZ.NIC se podílely na tvorbě odznaků, které nabízí aplikace Open Nettest, jejíž pomocí lze otestovat rychlost připojení k Internetu. Odznaky mají za úkol motivovat uživatele k provádění vyššího počtu měření.

Dětský obrázek lze získat za určité množství uskutečněných měření (1, 3, 6, 12,…) nebo v některý z významných dnů v roce jako je např. Den bezpečnějšího Internetu, Den čokolády či Den emoji. Pro získání odznaků je třeba mít nainstalovánu nejnovější verzi 2.7.8, která byla nasazena dne 19. prosince 2018 a je volně ke stažení jak na Google Play či na App Store.

Děti se úkolu zhostily na výbornou. Mnohé z nich motivovala vidina, že se stanou důležitou součástí aplikace Open Nettest. Kdo uskuteční první měření v aplikaci, získá hned první odznak od jedné z nejmladších výtvarnic. V následující tabulce je přehled významných dnů, jež ztvárnily ostatní děti zaměstnanců CZ.NIC.

Tvůrci aplikace mají v plánu i v příštím roce přidat do nabídky odznaků nové významné dny. V případě zájmu o účast v další malířské akci, prosíme o zaslání zprávy na e-mailovou adresu: kontakt@nic.cz. Dveře jsou otevřené i dětem, které nejsou nijak spjaty se sdružením CZ.NIC.

Aplikace Open Nettest byla vyvinuta v rámci mezinárodního projektu “Open crowdsourcing data related to the quality of service of high-speed Internet” (zkráceně MoQoS). Pomocí aplikace lze zjistit, jak si na tom stojí náš poskytovatel Internetu či mobilní operátor co do rychlosti a kvality připojení.

Během dvouletého projektu, který se již chýlí ke konci stejně jako rok 2018, využívaly aplikaci Open Nettest, resp. její národní modifikace, regulační úřady v České republice (ČTÚ), na Slovensku (), ve Slovinsku (AKOS) a v Srbsku (RATEL).

Aplikaci Open Nettest přejeme mnoho úspěchů a odměněných uživatelů i v nadcházejícím roce 2019!

Kategorie:

Hezké a klidné svátky a vše dobré v novém roce

Čt, 12/20/2018 - 10:00

Děkujeme vám za pozornost, kterou věnujete našim projektům a aktivitám, a přejeme vám spokojené a šťastné Vánoce a úspěšný nový rok. Na viděnou ve 2019!

Kategorie:

Redesign webu mojeID

St, 12/19/2018 - 16:43

K redesignu jakéhokoliv webu se musí přistupovat vždy velmi opatrně a obezřetně. Lidé jsou už zvyklí na to, že se ten „jejich“ web nějak chová a nějak vypadá, a pochopitelně tak z jakýchkoliv změn mívají obavy. Je to jako v supermarketu, kde provozovatel jednou za čas (v dobré víře) přestěhuje zboží do jiného regálu a vy najednou prostě nejste schopni nalézt svou oblíbenou hořčici. I proto jsme si nechali vypracovat nezávislou UX analýzu webu mojeID a teprve na základě výstupu této analýzy jsme přistoupili k redesignu.

Informační architekura

Pamatujete na weby z 90. let minulého století a na tlačítko „mapa stránek“? Informační architektura je něco podobného. Definujete, jaké informace a komu chcete sdělit, dáte tomu strukturu, prioritní položky zařadíte do hlavní navigace a máte téměř hotovo. V případě webu mojeID bylo nejdůležitější strukturovat jej do dvou sekcí: pro uživatele a pro poskytovatele.

Responzivní design

Dnes už nelze spoléhat na to, že něco se prohlíží na desktopu a něco jiného na mobilu. Uživatel vyžaduje stejně kvalitní zážitek a funkčnost na všech zařízeních. Původní web responzivní nebyl vůbec, takže toto pro něj byla úplná novinka. Na rozdíl od některých mobilních verzí webů se v případě webu mojeID nejedná o žádnou ochuzenou verzi, ale o verzi naprosto „plnotučnou“ – na mobilu se dostanete ke všem informacím, stejně jako na desktopu.

Fulltext vyhledávání

Přes veškerou snahu postavit web tak, aby každý snadno našel, co potřebuje, se může stát, že něco uživatel prostě nenajde (vzpomeňte na příklad s hořčicí). Proto jsme přidali možnost na webu vyhledávat (v hlavní navigaci nahoře kliknutím na ikonu lupy). Tu jsme přidali také do katalogu poskytovatelů, abyste věděli, zda váš oblíbený web službu mojeID podporuje.

Chat s podporou

Nově jsme přidali také užitečnou funkci online komunikace s naší zákaznickou podporou, a to formou chatu. Kromě telefonu a e-mailu se tak teď můžete na cokoli ohledně mojeID dotázat i v chatovacím okénku (tuto funkci, myslím, ocení hlavně nesmělí).

Grafika a copywriting

Grafika se někomu může líbit, někomu nemusí, ale hlavně musí být funkční. My jsme se soustředili na to, aby především dokreslovala textové informace a pomáhala se na webu zorientovat. Veškerá grafika je vektorová, takže se vám bude krásně vykreslovat v jakémkoliv rozlišení. Nově jsme také přepsali všechny texty, tak aby byly co nejsrozumitelnější.

Kategorie:

Konec roku je pro děti na Internetu nejrizikovější

St, 12/19/2018 - 12:49

Ještě donedávna platilo, že nejrizikovějším obdobím na Internetu jsou pro děti letní prázdniny. Během nich tráví čas na sociálních sítích, experimentují s různými seznamkami a volnočasovými službami. Děti se tak často setkaly s kyberšikanou, obtěžováním přes sociální sítě, sextingem, vydíráním či zneužitím osobních údajů.

Poslední dobou se ale nejrizikovějším obdobím na Internetu stává konec roku. Děti, stejně jako dospělí řeší nákupy dárků a i to, kde na ně vzít. Podle posledních průzkumů si na Vánoce půjčuje finanční prostředky téměř pětina (17 %) dospělých Čechů. Téma, kde vzít na Vánoce, řeší i mladí lidé. Ti nejčastěji spoléhají na kapesné od svých blízkých nebo příležitostné brigády.

Až 21 % dětí v několika průzkumech uvedlo, že jsou ochotny za nabízenou odměnu poskytnout svoje intimní materiály nebo sexuální služby. Na vzorku 1 800 dětí se zjišťovala i cena, za kterou jsou schopny na tyto nabídky přistoupit.

Oproti všem předpokladům a zažitým klišé, jsou nejčastějšími obětmi v tomto ohledu na Internetu chlapci. Ti dostávají nabídky častěji od falešných profilů než dívky. Chlapci nemají problém pořizovat intimní materiály – fotografie nebo videa vytvářejí běžně a to mnohdy i zdarma. Pokud ale dostanou nabídku na odměnu, jsou to nejčastěji klíče ke hrám, Premium SMS do her a dobití kreditu. Částky za zaslaný intimní materiál se pohybují v řádech několika set korun. Pokud by byl chlapec vylákán na intimní schůzku, pohybuje se průměrná cena sexu s ním okolo 2 700 Kč. O něco vyšší částka je i imaginární hranicí, kterou je heterosexuální chlapec ochoten přijmout za sex se stejným pohlavím.

Děvčata mají sice více nabídek na vytváření fotografií, videí a setkání se sexuálním podtextem, ale se zasíláním citlivého obsahu jsou opatrnější než chlapci. Pokud jde o možnost si vydělat nějaké peníze, dávají přednost osobním schůzkám. Největší zájem je o dívky ve věku 14 až 21 let a průměrná cena za pohlavní styk se pohybuje v průměru 750 Kč. Až 76 % dívek, které měly s touto aktivitou zkušenost, pak uvedlo, že šlo pouze o jednorázový přivýdělek.

Nabídky se sexuálním podtextem řeší české sociální sítě a seznamky různě. Některé těmto aktivitám vycházejí nepřímo vstříc, neboť je možné si na profilu vyplnit údaje typu: velikost pohlaví, jaké nosím spodní prádlo nebo kdy jsem měl naposledy sex. Tyto údaje mohou vyplnit i děti a často to také dělají. Z mnoha průzkumů také víme, že lidé, kteří vyplní více položek s fotografiemi (včetně citlivých), mají až trojnásobně větší šanci, že budou osloveni.

V rámci připravovaného internetového seriálu o dětské prostituci, jsme se chtěli přesvědčit, jak moc bude atraktivní pro útočníky oslovit nový dětský profil na seznamce. Vytvořili jsme falešnou identitu chlapce i dívky, na kterém jsme uvedli věk 15 let a údaj, že jsme doma nemocní. Přes noc, tzn. za necelých 12 hodin, jsme na profilu chlapce evidovali 1 200 zpráv. Z toho téměř 750 zpráv obsahovalo finanční nabídku. U dívky byl počet oslovení desetinásobně menší. Během několika hodin jsme na místo setkání vylákali deset zájemců, mezi nimi i v minulosti odsouzeného za pohlavní styk s dětmi a ohrožování mravní výchovy.

Možností, jak se bránit fenoménu sexuálních nabídek na Internetu je mnoho. Dobrou zprávou je, že se těmto tématům dostává velké pozornosti a existuje celá řada projektů, které se této problematice věnují. Pro rodiče, kteří jsou bohužel nejslabším článkem v tomto procesu, je důležité se o dítě zajímat. Jejich úlohou je vytvoření takového klima, ve kterém dítě nebude mít potřebu soupeřit s ostatními dětmi o to, kdo má kvalitnější oblečení nebo elektroniku. Pokud se někdy děti s podobnými nabídkám setkají, je potřeba je naučit, jak je správně řešit.

Kategorie:

Jak vysvětlit malým dětem, co je „grooming“?

St, 12/05/2018 - 10:30

Setkat se dnes s dvouletými či tříletými dětmi, které na tabletu sledují pohádky, umí si pustit další díl oblíbeného seriálu nebo kreslí obrázky již (bohužel) není občasná výjimka. Díky intuitivnímu ovládání se nejmladší generace v on-line prostředí často orientuje lépe než my, dospělí.

Zatímco v mnohých činnostech, jako je hraní her, je pro nás obtížné s dětmi držet krok, existuje minimálně jedna oblast, kde dětem můžeme a měli bychom předat více. Jedná se o záležitosti spojené s počítačovou bezpečností.

Stejně jako své potomky od raného věku seznamujeme se základy bezpečnosti na přechodu pro chodce, či že nemají nasedat k cizím lidem do auta, měli bychom jim vštěpovat i základy bezpečného pohybu po Internetu. Zde však často narazíme na problém, jak jednotlivá rizika malým dětem objasnit.

Jedním z takovýchto příkladů může být grooming. Vysvětlení, že pán, který před školou nabízí bonbóny, nemusí mít vždy dobré úmysly, zvládneme většinou na jedničku. U obdobného jevu na Internetu je to však již horší.

Vstříc těm, kteří chtějí děti s těmito základy nenásilnou formou seznamovat co nejdříve, nyní přicházíme s knihou „ON-LINE ZOO“, která představuje nejnovější přírůstek Edice CZ.NIC.

Jednotlivá rizika Internetu kniha vysvětluje na příkladu zvířátek v zoologické zahradě. Se zmíněným groomingem se tak malí čtenáři setkají prostřednictvím lva Ludvíka, který si nasadí na ruku maňáska antilopy. Malé antilopy Agáta a Adam pak mají pocit, že si povídají s jinou antilopou a ne lvem, který v sobě právě probudil staré lovecké pudy. Podobně kniha seznamuje i s dalšími negativními aspekty on-line světa – zveřejňováním nevhodných fotek (selfie), závislost na mobilu nebo kyberšikanou.

S původně rakouskou knihou, která vyšla v rámci projektu Safer Internet, jež je spolufinancován Nástrojem Evropské unie pro propojení Evropy, připravujeme i veřejná čtení s následnou besedou. Knihu je možné si objednat přímo u nás v CZ.NIC. Prvním deseti zástupcům mateřských a základních škol, kteří mi napíší, jak by knihu u sebe využili, ji pak rádi zašleme zdarma.

Kategorie:

Co nám ukázal sken 10 000 domén?

St, 11/28/2018 - 14:50

V rámci našeho působení provozujeme aplikaci Malicious Domain Manager. S její pomocí se snažíme informovat držitele domén v zóně .CZ o úspěšné kompromitaci jimi provozované webové prezentace. Nejčastějším scénářem, který se v rámci napadení webových aplikací pravidelně opakuje, je situace, kdy si útočníci pronajmou web či IP adresu a provozují na ní nějaký exploit kit, který útočí na známé zranitelnosti komponent, jež uživatelé obvykle využívají při procházení webových stránek (tedy prohlížečů, Javy, Flash playeru apod.). Tuto adresu, kde je exploit kit provozován, pak například pomocí tagu iframe vkládají do napadených webových stránek jako jejich součást. Již delší dobu si klademe otázku, zda nemůže ve skutečnosti v zóně .CZ být více napadených domén, než o kterých jsme schopni se dozvědět s pomocí naší aplikace. Zkusili jsme proto reverzní postup: Vzali jsme množinu náhodných domén a sledovali, z jakých dalších domén si tyto stránky stahují své komponenty. Potom jsme v kupce agregovaných výsledků pátrali po jehlách a červech… Co myslíte, povedlo se nám v malém českém rybníce identifikovat nakažené stránky, na které ještě nepřišel Google Safebrowsing? A případně kolik?

Nebudu chodit kolem horké kaše – nenašli jsme nic. Žádné dosud neobjevené pirátské weby, masivně odkazované z webů českých obětí, na nás v hromadě dat nečekaly. Nicméně i tak máme zajímavé výsledky, o které se chceme podělit.

Pár slov ke skeneru – vyvinuli jsme ho před čtyřmi lety, abychom ověřili, zda české stránky identifikované jako škodlivé službou Google Safebrowsing (kterou používá např. i Firefox a Chrome k ochraně uživatelů) nejsou false positives, předtím, než jejich vlastníka upozorníme. Skener MDMaug jsme nyní rozšířili, aby bral vícero URL adres a generoval co nejvíce uchopitelný přehled externích domén třetích stran, na které se české domény připojují.

Při testování jsem nechtěně provedl i zátěžový test Firefoxu. Zapomněl jsem implementovat řízení vláken a když jsem zadal, aby se domény oskenovaly, frontend je mínil oskenovat všechny najednou. Vyslal 10 000 AJAX spojení a definitivně zamrznul. Nicméně počítač statečně hučel. Další ráno jsem sebral výsledky – necelé tři hodiny skeny probíhaly normálně, protože server se nenechal zahltit, nicméně když Firefox zobrazil pár tisíc výsledků analýz, přetekl SWAP a počítač se již nevzpamatoval. Kolegové mi celé ráno psali na Jabber v domnění, že jsem online, ale online byla jen má černá díra.

Nyní frontend skeneru obsahuje statistiky průběhu testů a panel rychlosti, kde uživatel řídí počet vláken, ve kterém skeny probíhají. To lze měnit za běhu podle vytíženosti serveru – na svém 4jádru 8 GB RAM jsem nakonec test nechal běžet na dvou až třech vláknech, pokud jsem na počítači normálně pracoval, případně v 11 až 14 vláknech přes noc. Sken probíhal rychlostí přibližně 12 až 15 URL za minutu. Z toho vyplývá, že 10 000 domén lze oskenovat v ideálním případě za 12 hodin.

Je třeba říci, že výsledky nezohledňují URL z whitelistu – MDMaug provoz z některých URL rovnou zahazuje (http://clients1.google.com/ocsp, http://www.google.com/adsense/, …). Další domény druhého řádu má možnost whitelistovat uživatel. Já jsem například whitelistoval ocsp.pki.goog, google.com, gstatic.com, cloudfront.net, doubleclick.net a w3.org, digicert.com. A nakonec doména detectportal.firefox.com je blokována přímo v nastavení interního testovacího Firefoxu, neboť při každém spuštění prohlížeče Firefox je tato adresa pingnuta.

Celkem jsme skenovali homepage 10 997 domén, v grafech je budeme nazývat origins. Celkem 7 522 origins se připojilo k 8 206 externích adres třetích stran. Když vezmeme v úvahu všechny možné IP adresy, skrze něž se lze k externí adrese připojit, vytvořili mezi sebou 43 996 spojení. Pětina domén (2 577) se připojuje na svoji vlastní „www” doménu, 95 na jinou svoji vlastní doménu třetího řádu. Buď variantu „www” (www3, w1, w17), označení, že doména třetího řádu obsahuje statický obsah (img, static, cdn, media), nápovědu, že tam běží administrace (admin), variantu jmeno.prijmeni.cz (nebo například public.relations.cz), variantu s doménou čtvrtého řádu (www.fotbal) nebo cokoli dalšího (api, files, geo, legacy). Přes 1 400 domén v okamžiku testu i týden potom timeoutovalo, šest set domén přesměrovávalo jen a pouze na svoje subdomény, dva tisíce funkčních domén nepřesměrovávalo vůbec nikam.

Nejvíce součástí stránek bylo stahováno z TLD .cz, .com, .org a .net. Na následujícím grafu vidíme, že 5 443 českých origin (oranžovaná) odkazuje na 5 270 externích adres (žlutá) na TLD .cz (popis osy). K tomu provedli 11 945 spojení (modrá). Jinými slovy, nejčastěji odkazovanou TLD je na českých doménách TLD .cz. Domény se připojují na o něco menší množinu domén, přičemž průměrně na každou externí adresu vedou dvě IP adresy.
O něco méně origins (4 731) se připojují na třetinovou množinu adres v TLD .com, ale protože proběhlo přes 22 tisíc relací, usuzujeme, že průměrně se na jednu .com doménu připojujeme deseti IP adresami.
Dále origins odkazují na .org a .net, ale tam je množina externích adres mnohem menší (70 a 274 domén).

Pokud se si protáhneme tento graf dál, vidíme, že další nečasteji používané TLD jsou: polská, evropská, cool input/output doména, slovenská a německá.

Na ta samá data se podívejme ještě jiným způsobem. Přepočítejme si vždy na 100% součet relací (modrá), origins (oranžová) a exteních adres (žlutá). Vidíme opět, že TLD .org má maloučko externích domén, na které se odkazuje mnoho českých origins. Oproti tomu několik málo origins odkazují na mnoho TLD .tv. Dva origins odkazují na jedinou doménu na TLD .stream, ale připojují se k ní na 11 různých IP adresách. TLD .to se objevuje jenom díky webovému komunikátoru tawk.to, který má 22 subdomén, na jejichž 16 IP adres se origins připojily v celkem 285 relacích, zřejmě kvůli dostupnosti služby.

Když místo TLD uděláme agregaci podle počtu nejvíce přistupovaných domén druhého řádu, dostaneme následující tabulku. Ukazuje, že 1 423 origins z množiny testovaných přistupuje na 13 subdomén na facebook.com, v těsném závěsu jsou přístupy 1 397 origins na jedinou doménu scanandcleanlocal.com . Shodou okolností ji znám, je to fb.scanandcleanlocal.com, je nasměrovaná na localhost a po minutě googlování jsem nepochopil, k čemu ji Facebook používá. Následují certifikáty na letsencrypt.org a aplety na jednopísmenném podkladu WordPressu w.org. V závěsu se pohybuje ještě googletagmanager.com a DNS služba cloudflare.com.

 

Pokud domény druhého řádu seřadíme podle počtu domén třetího řádu, vede český webnode.cz se 77 subdoménami, ke kterým přistupuje sedmdesátka origins. Dva origins přistoupí k úctyhodným 64 subdoménám xvideos.com. Na šestém místě je další doména Facebooku fbcdn.net, u které jsme objevili 18 subdomén a na kterou přistupuje 464 origins. Sloupec se nám dokonce nevešel do grafu, podobně jako u 13 subdomén facebook.com, kterou známe z předchozího grafu.

Zajímá-li nás, proč je tak málo používaných domén na TLD .org a .net a které to jsou? Vedou čtyři již zobrazené letencrypt.org, w.org, facebook.net a fbcdn.net. Za nimi jsme zaznamenali 170 zásahů na tři subdomény typekit.net, dále šest subdomén adform.net a několik hostů přistupuje k 15 subdoménám akamaihd.net.

Drtivá většina origins přistupuje pouze na jedinou TLD. O tisícovku méně je origins, které přistupují na dvě, o další tisícovku méně je těch, které přistupují na tři. Graf postupuje dál a šampionem se stává stránka, která natáhne adresy z 19 různých TLD. Skutečně, jedna mezinárodní spediční společnost při přístupu na stránku zobrazí zdroje z .com, .net, .be, .dk, .uk, .pl, .cz, .it, .au, .sk, .de, .ca, .fr, .in, .hk, .sg, .nl, .ie a .my. Na deseti různých IP kontaktuje adresu hello.staticstuff.net, potom různá CDNka (static-cdn.responsetap.com, cdn.siteimprove.net), pluginy (m.addthis.com, u.heatmap.it), certifikace (s.trustpilot.com, static-ssl.responsetap.com), sociální konektory, analytiky, in-page komunikátory, třináct různých homepage vyhledávače Google, co si vzpomenete.

Potom jsem si seřadil origins podle počtu libovolných externích stránek, na které se připojují. Vyšlo mi, že dva tisíce origins se připojují právě k jedné externí stránce, o něco méně origins ke dvěma a ke třem už jenom osm set origins. Šampionem v této disciplíně se stává jeden projekt Českého rozhlasu, kde jsme naměřili 87 různých externích stránek. Byly tam vedlejší stránky víceméně pochopitelné a všechno šlo svižně. Několik dalších finalistů, které se připojují k osmdesátce stránek, vedou na tutéž stránku, zřejmě je vlastní nějaký spekulant. Některé e-shopy ale obsahují tolik různých pluginů (nahrávání uživatele, livechat…), že stránka začne hučet a člověka to pokouší zablokovat JavaScript. Mezi stránkami se vyskytla i smrt.cz . Byl jsem zvědav, proč smrt.cz načítá osmdesátku externích stránek a zadal ji do prohlížeče. Skončil jsem na stránce Blesku pro ženy. Pátral jsem a zjistil, že smrt.cz vede na brana.cz/číslo. Pokud jsem číslo změnil, skončil jsem na hlavní stránce Blesku, kde bylo přes celou stránku napsáno „SMRT – českého doktora v Číně”. Úsudek ať si každý vytvoří sám, já si nevytvořil žádný.

Srovnání prvních 250 origins, které iniciovaly nejvíce spojení, ukazuje poměr IPv4 / IPv6, v jakém jsou relace navazovány. Existuje jenom málo origin, které naváží menšinu spojení s IPv4, četnost IPv6 se drží přinejlepším na 15 %.

Pokud byste si chtěli náš nástroj vyzkoušet, mám pro vás dobrou zprávu. Skener si můžete nainstalovat i v lokálních podmínkách, není třeba žádná kompilace, instalace však není pro začátečníky. V README souboru projektu se snažíme dobře popsat příkazy, se kterými si vygenerujete vlastní certifikát a ohlídáte si instalaci pod nově vytvořeným omezeným uživatelem. Dále zde jsou rady, jak debuggovat, pokud něco nefunguje tak, jak má. Po nainstalování serveru se zpřístupní i testovací podezřelá stránka, která obsahuje rámce, podezřelé obrázky i skripty s voláním nebezpečných funkcí.

Při troše štěstí analyzér zaznamená veškerou komunikaci a podá přehledný výpis externích adres, na které se snaží testovací stránka připojit. Můžete pak skenovat, co je vám libo a bez obav o svůj normální prohlížeč zjišťovat, kam která adresa uživatele unáší.

Jsem rád, že náš test neodhalil žádné neznámé zdroje infekce mezi doménami v zóně .CZ. Znamená to, že náš nástroj Malicious Domain Manager odvádí dobrou práci a že nám doufejme ani v budoucnu neuteče žádná zásadní kampaň, zneužívající k šíření malware domény .CZ. Vznik tohoto textu i samotného skeneru byl podpořen Nástrojem Evropské unie pro propojení Evropy.

Kategorie:

Další podvodná kampaň se snaží vystrašit uživatele

Po, 11/19/2018 - 05:50

Koncem uplynulého týdne opět probíhala kampaň, která má jediný cíl – vystrašit uživatele a získat od nich peníze. Ačkoliv jsme nejen my již v minulosti na tyto podvody upozorňovali, jak prostřednictvím naší linky STOPonline, tak na webových stránkách CSIRT.CZ, jsou tyto kampaně stále částečně úspěšné. Ač se jednotlivé verze mohou lehce lišit, vždy obsahují pohrůžku uživateli, ve které údajný hacker tvrdí, že se dostal do jeho počítače a natočil jej při sledování pornografie.

Přestože se komunikace v této kampani vyznačuje krkolomnou až legrační češtinou, vypadá to, že se útočníkovi vydávajícímu se za hackera podařilo během prvních dvou dnů vybrat již 0.31417946 BTC (necelých 40 000 korun). A to v podstatě bez práce, jen rozesláním e-mailů.

Bohužel, napálených uživatelů může i nadále přibývat. Pokud už takovýto e-mail dostanete, měli byste jej vždy ignorovat. V některých verzích mohli uživatelé narazit i na reálné kombinace jména a hesla, kteří dotyční používali. V žádném případě však v těchto případech nedošlo ke kompromitaci uživatelských PC; jednalo se o data uniklá z některé z on-line služeb, které uživatel využíval. Útočník data jen zneužil k vystrašení.

Pokud už uživatel zaplatil, měl by se obrátit na policii a oznámit, že se stal obětí podvodu. V okamžiku, kdy začne policie danou peněženku sledovat, bude pro útočníka obtížnější se k penězům dostat. A pokud chcete pomoci i ostatním, můžete bitcoinovou peněženku uvedenou ve vyděračské zprávě nahlásit do databáze zneužívaných bitcoinových peněženek, jako se to stalo i v aktuální kampani zde.

Kategorie:

Náš první FIRST onsite visit

St, 11/14/2018 - 12:00

Jako Národní bezpečnostní tým CSIRT.CZ jsme byli požádáni společností Accenture o podporu jejího členství v mezinárodní organizaci FIRST. Podpora bezpečnostních týmů v České republice je důležitou součástí naší činnosti, kterou navíc v rámci programu Connecting Europe Facility podporuje také Evropská unie. Proto jsme souhlasili, že kromě vyjádření naší podpory písemnou formou, tak jak je požadována organizací FIRST, provedeme ve společnost Accenture i takzvaný onsite visit.

Jeho smyslem je seznámit se také s jinými členy bezpečnostního týmu, než jen pouze representative týmu, který tým zastupuje navenek, poznat management a ověřit nastavené procedury. V neposlední řadě je součástí onsite visit rovněž ověření jak fyzické bezpečnosti, tak i existence příslušných politik a pravidel pro řešení incidentů a práci bezpečnostního týmu.

S různými audity již máme zkušenosti, ostatně naše sdružení je držitelem certifikace ISMS, jsme členy organizace FIRST a aktuálně procházíme procesem certifikace u úřadu Trusted-Introducer. V rámci ISMS máme rovněž zkušenosti s interními audity. Tentokrát jsme však měli možnost vyzkoušet si roli „auditorů“ v jiné společnosti. Naštěstí FIRST poskytuje formulář, díky němuž je jasné, jaké oblasti je potřeba ověřit. Ovšem hloubka auditu závisí také na zkušenostech a znalostech auditorů.

V rámci onsite visit je kontrolováno správné zakotvení constituency, tedy rozsahu působnosti daného CSIRT týmu, dále se řeší existence dokumentů popisujících účel a fungování CSIRT, dokumenty deklarující jeho vznik a oznamující tuto skutečnost směrem k jeho constituency. Důležité jsou i otázky týkající se financování, ukotvení CSIRT v rámci dané společnosti, nebo organizace týmu. Současně musí tým doložit existenci politik týkajících se klasifikace informací, ochrany informací, expirace a archivace informací, správné likvidace dat, řízení přístupu k informacím a šíření informací.

Další politiky se týkají akceptovatelného používání a ochrany vybavení CSIRT týmu, spolupráce s dalšími týmy, nebo pravidel a postupů pro samotné řešení bezpečnostních incidentů.

V rámci on site visit je kontrolována i úroveň fyzického zabezpečení, dostupnost vybavení a možnost bezpečného uložení fyzických předmětů, například do trezoru. Sleduje se také síťová infrastruktura, či zda tým používá nějaký nástroj pro řízení práce s bezpečnostními incidenty. Důležité je, aby tým využíval PGP nebo GPG pro šifrování a podepisování své komunikace, včetně toho, aby měl správně nastavené postupy pro práci s těmito klíči. V rámci přijímání za členy mezinárodní CSIRT komunity je kontrolováno rovněž další vzdělávání a rozvoj zaměstnanců. I na toto musí mít budoucí člen naší komunity daná pravidla, která v rámci jeho kontroly již platným členem organizace FIRST budou zkontrolována.

Kolegové ze společnosti Accenture byli na naši návštěvu dobře připraveni a díky tomu celá onsite visit proběhla svižně a bez vážnějších zádrhelů. Velmi pravděpodobně tak bude mít brzy Česká republika třetího zástupce mezi členy organizace FIRST.

Kategorie:

Reinstalace Openldap v CZ.NIC

St, 11/14/2018 - 11:35

Jelikož se na začátku roku objevila „výzva“ reinstalovat LDAP, který nám v CZ.NIC běžel na starším OS, řekl jsem si, že takto zajímavou „challange“ nechci minout. A takto natěšený jsem byl zhruba do doby, než mi došlo, že na stejném serveru běží zřejmě „jako bonus“ Freeradius a Radsecproxy s připojením k Eduroamu. Ten se měl samozřejmě přepisovat také, jelikož se syntaxe mezi verzemi Freeradius v2 a v3 v lecčems změnila. Až teprve nyní jsem pochopil a obdivoval trpělivost lidí, kteří tyto věci v CZ.NIC nastavovali přede mnou a je mi jasné, že si s nimi celkem „užili své“. Ale to je jiná kapitola, tento blogpost má být výhradně o instalaci LDAP. Zdůrazňuji, že tento článek pojednává pouze o základním nastavení LDAP.

LDAP neboli „Lightweight Directory Access Protocol“ je adresářový protokol optimalizovaný pro rychlý přístup k datům. Díky jednoduchosti protokolu, použití adresářové (stromové) struktury a databáze, je možné velmi rychle vyhledávat informace o uživatelích a službách. Data do databáze lze také samozřejmě vkládat, modifikovat je a mazat. LDAP umožňuje centralizovaně udržovat data o uživatelích. Díky tomu lze přistupovat ve všech aplikacích, které LDAP podporují, ke stejným údajům. V Linuxu takto například můžeme úspěšně synchronizovat účty uživatelů napříč systémy.

Každý záznam obsahuje jméno „distinguished name“ neboli DN, kterým je konkretní záznam jedinečný. Pomocí DN je zároveň popsána stromová cesta k záznamu. Pod DN jsou pak sdruženy objekty a hlavně attributy, které tvoří jednotlivé záznamy. Příkladem objektu je objectClass, která definuje typ objektu. Objekty jsou již předefinované pomocí schémat, přičemž je také možně zadefinovat si vlastní. Příkladem attributu může být atribut „DC“, kterým lze popsat např. doména „dc=nic,dc=cz“ nebo attribut „O“ popisující organizační jednotku.

# Entry 1: dc=nic,dc=cz dn: dc=nic,dc=cz dc: nic o: CZ.NIC, z.s.p.o objectclass: top objectclass: dcObject objectclass: organization

Data je možné distribuovat textově ve formě .ldif, binární data v .ldif (například různá jazyková nastavení nebo jiný třeba binární, abych tak řekl, „blob“) se ukládá za pomoci kódování, nejčastěji pomocí base64.

Instalujeme

Instalací balíčku pro Openldap (v Debianu balíček slapd) se LDAP již po instalaci automaticky nastaví. Aby to s konfigurací bylo o maličko složitější, od verze Openldap 2.4.23-3 se LDAP nenastavuje pomocí textového souboru (dříve existoval jeden konfigurační soubor „slapd.conf“), ale pomocí příkazů ldapadd, ldapmodify a .ldif vkládaných přímo do databáze.

S příkazy ldapadd, ldapmodify, můžeme pracovat buď s parametrem EXTERNAL. Takto s ním nakládáme tehdy, když si „hrajeme“ s konfigem, tedy vlastním nastavením DB LDAP. Nebo s právy administrátora (nebo jinými právy v závislosti na ACL). Těch používáme zejména při modifikaci uživatelských dat. Pokud byste chtěli pomocí účtu administrátora měnit hodnoty v samotném konfigu LDAP, lze to také nastavit.

Než se pustíme do konfigurace, měli bychom si vysvětlit, jakým způsobem s LDAP pracovat. Po instalaci LDAP bude člověka určitě zajímat, jaké je jeho aktuální nastavení. Pro „omrknutí“ konfigurace používám nástroj ldapsearch z balíčku „ldap-utils“. S jeho pomocí lze snadno odkrýt nejsvrchnější stromovou strukturu nastavení, abychom se podívali, co vše se v databázi nachází. Příkaz pro ldapsearch, jímž si DN konfigu vypíšeme:

# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn dn: cn=config dn: cn=module{0},cn=config dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: olcBackend={0}mdb,cn=config dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}mdb,cn=config

Jak je vidno, tak v konfiguraci LDAP jsou po instalaci použita čtyři schémata. Pokud by vás zajímalo, jaké moduly LDAP aktuálně používá, není nic jednoduššího, než se „ponořit do hloubek“ konfigů, opět s pomocí ldapsearch. Podobným způsobem můžeme „rozvádět“ a zkoumat i další DN z předcházející stromové struktury do nejmenších detailů. Tak například zjistíme, že v defaultní instalaci LDAP nebyly použity žádné rozšiřující moduly kromě vlastního backendu DB (který, jak je vidno, je také zřejmě modulem, i když ne modulem rozšiřujícím, ale databázovým).

# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=module{0},cn=config dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_mdb

Pomocí ldapsearch nemusíme vypisovat pouze části konfigurací, ale můžete ji samozřejmě vypsat celou. Ale to se vystavujete problému, že zde narazíte na schémata, která působí poněkud nepřehledně. Myslím, že zkoumat schémata LDAP, která definoval někdo jiný, není to, co chcete a ostatně to ani dělat nemusíte.

Podobného účinku o výpis konfigurace lze rovněž docílit nástrojem ‚slapcat‘, jen s tím rozdílem, že ‚slapcat‘ vypisuje opravdu vše, včetně údajů o modifikaci a vytváření záznamů. Příkazu ‚slapcat‘ proto spíše než pro výpis konfigurace využijeme pro zálohování (viz. dále).

ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config slapcat -n 0 Zálohujeme

Předtím než začneme s LDAP pracovat, je výhodné si zálohovat počáteční konfiguraci. Záloha se samozřejmě bude hodit tehdy, pokud si v konfiguraci něco rozvrtáte sami svým zkoušením (třeba nefunkčním .ldif souborem se špatnými hodnotami, například při nastavování replikace – tehdy je potřeba opravdu dávat pozor). Nebo tehdy, když se vám v konfiguraci vrtal někdo jiný s povolenými acl právy. Tehdy se vám určitě budou hodit auditlogy, viz. moduly LDAP, a vše nejlépe replikované někam mimo, kde si všechno dohledáte.

S původní funkční zálohou konfigurace lze „rozložený“ LDAP poměrně rychle opravit. Co se týče záloh, určitě bychom měli zálohovat denně. K různým zálohám nastavení LDAP se samozřejmě potom můžete vracet, nebo si na to postavit rychlý skript.

Záloha konfigurace

Doporučuji si nastavit zálohování konfigurace cronem. Zálohovat bychom určitě měli nastavení samotné databáze i samotná data uživatelů. Slapcat s přepínačem „-n 0“ se vztahuje pro výpis konfigurace, „-n 1 .. n“ pro výpisy uživatelských dat v DB. Ale předpokládám, že používání LDAP pro více domén nebude zase tak častý jev. Záloha je ne-invazivní věc, které se nemusíme vůbec bát, jelikož spočívá v prostém vypsaní databáze a uložení do souboru.

0 7 * * * root slapcat -n 0 -l /path/config_ldap_back_$(date -I)_.ldif 0 7 * * * root slapcat -n 1 -l /path/db_ldap_back_$(date -I)_.ldif Obnovení ze zálohy

Máme tedy zazálohováno, ještě potřebujeme vědět, jak zálohu obnovit. Dejme tomu, že tedy máme dva soubory. Soubor s konfigem Databáze a soubor s uživatelskými daty. Úplně na začátku obnovíme samotný konfig Databáze, k tomu slouží v LDAP příkaz slapadd, který dělá to samé, jako když jsme zálohu ukládali, jen opačným způsobem. Postupujete takto:

service slapd stop mv /etc/ldap/slapd.d /etc/ldap/slapd.d-`date -I` mkdir -p /etc/ldap/slapd.d; chown -R openldap:openldap /etc/ldap/slapd.d/ slapadd -n 0 -F /etc/ldap/slapd.d -l /path/config_ldap_back_$(date -I)_.ldif chown -R openldap:openldap /etc/ldap/ service slapd start

Uživatelská data v Databazi vratíte takto:

mv /var/lib/ldap /var/lib/ldap-`date -I` mkdir -p /var/lib/ldap; chown -R openldap:openldap /var/lib/ldap/ # pokud mame povolenou replikaci, pridame jeste "-w" slapadd -n 1 -F /etc/ldap/slapd.d -l /path/db_ldap_back_$(date -I)_.ldif -w chown -R openldap:openldap /var/lib/ldap/ Přidáváme ldify Heslo Administrátora

Někdy se může stát, že přijdeme již k hotovému serveru s Openldap, který nakonfiguroval někdo jiný. Tehdy se hodí vědět, jak změnit heslo administrátora. V prvním kroku si vygenerujeme hash hesla, například pomocí slappasswd (z balíčku ldap-utils). Ideální bude použít trochu silnější heslo, než jsem použil v příkladu.

# slappasswd -h "{SSHA}" New password: Re-enter new password: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng

Hash hesla, vložíme do LDAP pomocí tohoto ldif:

# ldapmodify -H ldapi:// -Y EXTERNAL -f passwd.ldif dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcRootPW olcRootPW: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng

Zda-li je heslo vloženo v pořádku, můžeme ověřit operací ldapsearch (hash hesla by se měl shodovat):

# ldapsearch -H ldapi:// -LLL -Q -Y EXTERNAL -b "cn=config" "(olcRootPW=*)" ... olcRootDN: cn=admin,dc=nic,dc=cz olcRootPW: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng ...

Takto jsme změnili LDAP heslo v sekci „cn=config“. Teď potřebujeme udělat to samé pro účet admina v DB uživatelských dat. Kdybychom to neudělali, mohlo by platit ještě i staré heslo, použijeme .ldif:

# ldapadd -c -h localhost -Z -f passwd.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_admin_heslo" dn: cn=admin,dc=nic,dc=cz changetype: modify replace: userPassword userPassword: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng Certifikáty

Pokud máte LDAP „rozjetý“, asi se budete zajímat, jak vaši komunikaci zabezpečit. Určitě nechcete, aby se vám data „toulala“ po síti jen tak v „plain“ textu, ale šifrovaně. Certifikáty navíc zaručují identifikaci, takže u serveru i klienta byste měli mít jistotu, že nekomunikujete s někým, kdo se za jednu ze stran vydává.

Doporučuji zvolit silnější šifrování, ale ne zase takové, aby to „zabilo“ celé vaše CPU, protože dotazů na LDAP muže přijít spousta v relativně krátkém čase. Do konfigu LDAP jsem přidával certifikáty tímto .ldif, ale můžete použít i jiné nastavení:

# ldapadd -c -Y EXTERNAL -H ldapi:// -f cznic_config_certificate.ldif dn: cn=config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ldap/ssl/CZ.NIC2-cacert_sha2.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/ssl/ldap.nic.cz-cert_sha2.pem - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.nic.cz-key_sha2.pem - add: olcTLSDHParamFile olcTLSDHParamFile: /etc/ldap/ssl/dhparam dn: cn=config changetype: modify replace: olcLocalSSF olcLocalSSF: 128 - replace: olcSecurity olcSecurity: update_ssf=128 simple_bind=128

V Debianu si ještě nezapomeňte povolit v /etc/default/slapd naslouchání na portu 636 pro ldaps:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///" ACL

Přesné nastavení ACL, jak ho máme v CZ.NIC, sem bohužel dát nemohu. Nicméně kombinací nastavení ACL lze vytvořit dost a dost. Pokud budete potřebovat podrobnosti, doporučuji dokumentaci. Direktiva práv typicky začíná attributem olcAccess, po němž následuje pořadí ACL pravidla, řetězec k čemu se přistupuje, a nakonec kdo přistupuje (přistupujících může být více a jsou odděleni mezerami). Nebojte se být restriktivní, zrovna u ACL je to potřeba, vyhnete se tak v budoucnu nepříjemnostem. Co se týče uživatelů, lze si vystačit s těmito:

  • Uživatel External – pokud si nějakým nedopatřením smažete práva
  • Uživatel Admin – uživatel, pod kterým budete vkládat data
  • Uživatel Reader – tohoto uživatele budete nastavovat v aplikacích, ze kterých budete potřebovat pouze číst (takže typicky skoro všechny)
  • Ostatní (self, auth, *) – můžete například dovolit uživatelům měnit si heslo

Dovolil jsem si vymyslet alespoň příklad nastavení práv, abych vás o toto téma neochudil, viz. .ldif:

# ldapmodify -c -h localhost -Z -f acl.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_admin_heslo" dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=admin,dc=nic,dc=cz" manage by dn="cn=reader,dc=nic,dc=cz" read by self write by anonymous auth by * none olcAccess: {1}to dn.subtree="dc=nic,dc=cz" by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=admin,dc=nic,dc=cz" manage by dn="cn=reader,dc=nic,dc=cz" read by * none olcAccess: {2}to * by * none

S těmito ACL, by se vám mělo podařit vypsat si uživatele ze skupiny People (lze se ptát také pomocí privilegovaného učtu EXTERNAL):

ldapsearch -Z -h localhost -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo_admina" -b ou=People,dc=nic,dc=cz 'uid=zsobotka' # ldapsearch -H ldapi:// -LLL -Q -Y EXTERNAL -b "dc=nic,dc=cz" 'uid=zsobotka'

Doptat se ldapu na skupiny:

ldapsearch -Z -h localhost -x -D "cn=reader,dc=nic,dc=cz" -w "silne_heslo_uzivatele" -b "dc=nic,dc=cz" '(objectClass=posixGroup)' # ldapsearch -H ldapi:// -LLL -Q -Y EXTERNAL -b "dc=nic,dc=cz" '(objectClass=posixGroup)'

Nebo být sám sobě schopen změnit heslo:

ldappasswd -Z -h -x -D "uid=zsobotka,ou=People,dc=nic,dc=cz" -w "puvodni_heslo_uzivatele" -a "puvodni_heslo_uzivatele" -s "nove_heslo_uzivatele" Logování

Neměli bychom zapomenout na nastavení logování. Číslo u olcLogLevel je součtem příslušných „kódů“, které lze debugovat. Rozumný kompromis „ukecanosti“ logů bych zastavil na čísle 256. Pokud budete chtít debugovat, můžete si troufnout i víc. Zde je .ldif:

# ldapmodify -h localhost -Z -f ./logmodify.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo" dn: cn=config changetype: modify delete: olcLogLevel dn: cn=config changetype: modify add: olcLogLevel olcLogLevel: 256 Rychlost

Při přechodu na MDB byste neměli mít problém s rychlostí. Oproti HDB backendu se rychlost mnohonásobně zvýšila a mimo jiné konzumuje dvakrát méně systémových prostředků. Pokud by ale vašemu LDAP přece jen „docházel dech“, můžete ho zkusit „vytunnit“ těmito DB parametry.

Writemap – použije se zapisovatelná paměť místo paměti pro čtení, čímž zvyšuje rychlost zápisu. Databázi to ale učiní potenciálně zranitelnou na „korupci dat“, v případě nepředvídaného pádu serveru.

Nometasync – přeskakuje se synchronizace metadat. Tento režim je rychlejší než při plné synchronizaci, ale v případě selhání operačního systému může dojít ke ztrátě poslední transakce.

# ldapmodify -c -Y EXTERNAL -H ldapi:// -f speed.ldf dn: olcDatabase={1}mdb,cn=config changetype: modify add: olcDbEnvFlags olcDbEnvFlags: writemap - add: olcDbEnvFlags olcDbEnvFlags: nometasync Moduly Auditlog

Výhody audit logu jsem již zmiňoval, určitě ho všem doporučuji zapnout. Audit.log automaticky sleduje změny, které se v LDAP provádí, a ukládá je v .ldif formě do zadefinovaného souboru. V logu je vidět timestamp změny události, jméno uživatele a ip adresu, ze které změna přišla. Pokud nastane problém, máte možnost si na něj díky auditlogu „posvítit“; nemusíte se bát, že by Vám něco uniklo. Log soubor můžete navíc replikovat rsyslogem na servery, kde jste zvyklí logy koncentrovat.

# ldapadd -c -Y EXTERNAL -H ldapi:// -f auditlog.ldif dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: auditlog.la dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAuditlogConfig olcOverlay: auditlog # chmod 755 /var/log/slapd/; chown openldap:openldap /var/log/slapd/ olcAuditlogFile: /var/log/slapd/auditlog.log Replikace

Replikace umožňuje synchronizovat databázi s uživatelskými daty pro „speciální okolnosti“. Při pádu jednoho ze serverů se rychle „switchne“ provoz na další server. Na každém ze strojů se nastaví stejné rid, různý provider (ip protilehlého serveru) a rozdílné olcServerID. Pokud jste u LDAP nastavili šifrování, měli byste ho zapnout i u replikace, v .ldif například přes starttls. Další podrobnosti ohledně replikace se dají vysledovat z logů a v dokumentaci.

# ldapmodify -c -Y EXTERNAL -H ldapi:// -f cznic_config_replication.ldif dn: olcDatabase={1}mdb,cn=config changetype: modify #add: olcSyncrepl replace: olcSyncrepl olcSyncrepl: rid=001 provider=ldap://xxx.xxx.xxx.xxx bindmethod=simple binddn="cn=admin,dc=nic,dc=cz" credentials="silne_heslo_admina" starttls=yes searchbase="dc=nic,dc=cz" schemachecking=on type=refreshAndPersist retry="30 +" network-timeout=5 timeout=30 - #add: olcMirrorMode replace: olcMirrorMode olcMirrorMode: TRUE - #add: olcDbIndex replace: olcDbIndex olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq dn: cn=config changeType: modify add: olcServerID #Make sure you use different olcServerID's for different servers, in example 0, 1 olcServerID: 0 dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: syncprov

Na obou serverech by měl být správně nastaven uživatel, pod kterým bude replikace probíhat. V příkladu je použit účet admin, ale může být i jiný.

Password policy

Password policy (ppolicy) je modul kontrolující „sílu“ uživatelských hesel. Modul zavadí politiku hesel tak, že nepovolí hesla kratší než předem stanovený počet znaků, písmen a čísel. Pomocí modulu můžeme zajistit, aby uživatel neprotáčel stále stejná hesla. Změněné otisky hesel si modul ukládá do vlastní historie v uživatelské DB.

Těchto modulů lze dohledat vice, v LDAP jsem použil modul PqChecker. Domovská stránka projektu je zde. Pokud jste odvážní, můžete ho zkusit zkompilovat. Ale lepší bude stáhnout si rovnou instalační balíček. Ten rozbalí modul „ppolicy.so“ přímo do příslušné cesty. Hodnoty chování ppolicy se nastavují v uživatelské DB, třeba tímto .ldif..

Nastavení zavedení modulu:

# ldapmodify -c -Y EXTERNAL -H ldapi:// -f "pwd_policy01.ldif" dn: cn=module{0},cn=config add: olcModuleLoad olcModuleLoad: ppolicy.so

Nastavení configu pro modul (předtím je ještě potřeba nahrát príslušné schéma z /etc/ldap/schema/ppolicy.ldif):

# ldapadd -c -Y EXTERNAL -H ldapi:// -f "pwd_policy02.ldif" # ppolicy jeste nastavit v mdb, req. - melo by byt zavedeno schema -> /etc/ldap/schema/ppolicy.ldif dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcPPolicyConfig olcPPolicyDefault: cn=default,ou=policies,dc=nic,dc=cz

Nastavení parametrů pro tento modul (je už přímo v databázi). Pokud máte například nainstalovaného PhpLdapAdmina, můžete parametry ppolicy měnit přímo tam.

# ldapadd -Z -h localhost -f pwd_policy03.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo" dn: ou=policies,dc=nic,dc=cz objectClass: organizationalUnit objectClass: top ou: policies dn: cn=default,ou=policies,dc=nic,dc=cz cn: default objectClass: top objectClass: device objectClass: pwdPolicy objectClass: pwdPolicyChecker pwdAllowUserChange: TRUE pwdAttribute: userPassword pwdCheckQuality: 2 pwdCheckModule: pqchecker.so pwdFailureCountInterval: 300 pwdGraceAuthNLimit: 5 pwdInHistory: 10 pwdLockout: TRUE pwdLockoutDuration: 180 pwdMaxFailure: 10 pwdMinAge: 0 pwdMinLength: 8 Uživatelská data

Zmiňoval jsem, že databáze uživatelů našeho LDAP čítá přes 12 let historie. Proto když jsem pro potřeby CZ.NIC LDAP instaloval, nepotřeboval jsem vytvářet DB novou, ale použil jsem to, co zde již dávno bylo. Protože však nechci tento blogpost ochudit o to nejzajímavější, přidávám příklad initu s uživatelskými daty.

# ldapadd -Z -h localhost -f user.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo" dn: dc=nic,dc=cz dc: nic o: CZ.NIC, z.s.p.o objectClass: top objectclass: dcObject objectclass: organization ## FIRST Level hierarchy - People dn: ou=People,dc=nic,dc=cz ou: People description: All people in nic.cz objectClass: top objectClass: organizationalUnit # Test user dn: cn=nstanciu,ou=People,dc=nic,dc=cz objectClass: person objectClass: inetOrgPerson cn: nstanciu gn: Nicolae sn: Stanciu uid: nstanciu # heslo userPassword: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng mail: nicolae.stanciu@nic.cz description: The Example ## FIRST Level hierarchy - Group dn: ou=Group,dc=nic,dc=cz ou: Group description: All groups in nic.cz objectClass: top objectClass: organizationalUnit ## FIRST Level hierarchy - Hosts dn: ou=Hosts,dc=nic,dc=cz ou: Hosts description: All hosts in nic.cz objectClass: top objectClass: organizationalUnit O ldapu CZ.NIC

LDAP provozujeme v CZ.NIC spoustu let, za tu dobu byl samozřejmě v rámci obměny software několikrát reinstalován. S reinstalací našeho LDAP se váže jeho přenesení do Ansiblu, respektive napsání role pro něj. Tím snad jeho reinstalaci usnadníme pro další cyklus obměny. V našem tiketovacím systému se nejstarší zmínka o LDAP datuje zhruba 12 let zpět. Je ale možné, že zde je ještě déle. I po tak dlouhé době se ale nedá říci, že je náš LDAP v CZ.NIC co do objemu nějak rozsáhlý. Uživatelských účtů máme zhruba do 200, velikost nacachované databáze je cca 1Gb a počet akceptovaných připojení se denně pohybuje kolem 50 000 dotazů.

Pokud Vás zajímá, co lze v LDAP mít, můžu obecně shrnout, co používáme my. Máme zde samozřejmě definované uživatele včetně jejich skupin. Ve skupinách jsou lidé samotní, sdružené skupiny lidí jsou definované ve vlastních skupinách prostřednictvím memberUid. Kerberos nepoužíváme, takže hesla jsou zahashovaná přímo v DB. Kromě uživatelů, zde máme také hesla schránek našeho mail serveru. Protože naši uživatelé používají Eduroam wifi, máme zde definované servisní skupiny pro Radius, které uživatele třídí do VLAN odpovídajících oddělení, ve kterých pracují a které Freeradius vůči LDAP ověřuje. Pak jsou zde data týkající se Samby, ppolicy modulu, kalendářové účty zasedacích místností SOGo kalendáře a nakonec testovací účty.

Pro replikaci LDAP používáme typ mirror (v našem případě nejsou více než dva LDAP servery potřeba). V případě pádu jednoho ze serverů se ip adresy přepínají na záložní server pomocí Ucarp. Co se týče schémat navíc, máme zde schémata Samby, Radius, SOGa (SOGo Resource Configuration) a PPolicy.

Jako GUI pro rychlé procházení, mazaní a přidávání triviálních věcí, se nám osvědčil dnes už zřejmě nevyvíjený (ale stále funkční) PhpLdapAdmin. Zbylé věci řešíme v rámci našich skriptů, tj. přidávání uživatelů, skupin, změny hesel a dalších věcí, které se vkládají do uživatelské DB pomocí .ldif.

Z ostatních služeb je na LDAP navázané téměř vše, od loginů do systémů a systémových group, přes interní systém pro zaměstnance, až po zaintegrované externí aplikace jako třeba Jabber, kalendářové řešení a mnoho dalších.

Kategorie:

Pozor na nabádání žáků k používání sociálních sítí a messengerů

Čt, 10/25/2018 - 08:50

Spolu se zahájením školního roku nejeden učitel řeší, jaký nástroj pro komunikaci se žáky zvolit. Spolu se stále se snižujícím věkem, kdy již dlouho není výjimkou ani více než polovina prvňáčků, kteří mají mobilní telefon, padá logicky volba na sociální sítě a především nejrůznější messengery. Ať již jde o Facebook, WhatsApp či Viber.

Při doporučování takovéto komunikace či zakládání společných skupin pro celou třídu je však na místě obezřetnost. I na používání těchto aplikací se od letošního května vztahuje legislativa, konkrétně pak GDPR, podle kterého je pro používání podobných nástrojů ze strany osob mladších 16, resp. 13 let (v návaznosti na národní legislativu) nutný souhlas rodičů. Podobný problém pak může nastat i při video-konzultacích přes Skype.

Většina aplikací promítla GDPR i do svých uživatelských podmínek, které obsahují ustanovení o minimálním věku a poměrně neurčitě odkazují na národní legislativu. Např. WhatApp ve svých anglických podmínkách ochrany soukromí (pozn. oficiální český překlad není nabízen) uvádí: „If you live in a country in the European Region, you must be at least 16 years old to use our Services or such greater age required in your country to register for or use our Services“ (Pokud žijete v některé ze zemí Evropy, musíte být pro používání našich služeb starší 16 let nebo vyšší věk, než je pro používání našich služeb požadován ve Vaší zemi). Vzhledem k tomu, že v České republice zatím nebyl k GDPR schválen příslušný národní zákon, platí hranice pro používání sociálních sítí od 16 let.

Pravidla pro ověření věku je sice možné sice poměrně snadno obejít (např. zadáním záměrně chybného data narození nebo prostým odškrtnutím políčka „Starší 16 let“), čímž však dochází jak k porušení smluvních podmínek, tak i platné legislativy. V budoucnu pak nejde vyloučit, že by právě takového porušení mohlo pomoci provozovatelům sociálních sítí se, byť částečně, vyvinit ze své odpovědnosti např. v případě kyber. šikany.

Minimálně z pohledu GDPR jedno z možných řešení nabízí získání písemného souhlasu rodiče, které ve svých podmínkách nastiňuje rovněž Viber: „In the EEA, certain default privacy settings will be applied to users under the age of 16 and can only be changed if the legal guardian instructs so in writing.“ (V zemích EHP se na uživatele mladší 16 let mohou vztahovat určitá výchozí nastavení ochrany osobních údajů, která mohou být změněna pouze tehdy, pokud zákonný zástupce dítěte o to písemně požádá). Takovýto souhlas může škola získat např. od rodičů na začátku školního roku. Vhodné je zároveň schválení ve Školním řádu. Pro komunikaci se žákem je zároveň možné v některých případech využít možností e-learningových systémů, např. Moodle.

Podmínky pro používání sociálních sítí ve školách bohužel GDPR ještě více zkomplikovalo. To by však nemělo být důvodem k rezignaci na jejich využití ve výuce a především osvětové činnosti, kdy učitel či školní metodik provádí žáka např. bezpečnostním nastavením a upozorňuje na možná rizika jednotlivých aplikací.

Kategorie:

Ze života online stopaře

Po, 10/22/2018 - 10:51

Ráda bych dnes navázala na jeden můj starší blogpost na podobné téma. V době jeho vzniku jsem byla strašně naštvaná na provozovatele serverů určených ke sdílení fotografií. Rozčilovalo mě, jak je možné, že nenastavují lepší mechanizmy ke kontrole vkládaných fotek. Proč nemají někoho, kdo je prochází? Proč nenastaví alba rovnou jako neveřejná? Mohla bych pokračovat dál, ale po téměř dvou letech, kdy mám pocit, že je vše jen boj s větrnými mlýny, jsem už něco pochopila. Není to přeci chyba provozovatelů, či poskytovatelů, každý sám je zodpovědný za své činy.

Zkouším se tedy posunout v oblasti osvětové činnosti a vyprávět rodičům, prarodičům, dospívajícím a všem, kdo má zájem, o zneužitelnosti osobních údajů, v tomto případě především fotografií.

Jak jsem psala i v předešlém blogpostu, dnes a denně se setkávám s fotografiemi, které jsou vystavovány na Internet s myšlenkou, že všem ukáží, jakou krásnou mám rodinu a jak roztomilé jsou mé děti. Bohužel pod těmito fotografiemi vidí někteří lidé i něco jiného než roztomilost a díky tomu se ze zdánlivě nevinné fotografie stane během chvilky dětská pornografie.

Všechny tyto fotografie byly pořízeny s dobrým úmyslem a všechny byly během několika málo minut zneužity. Některé jsou focené na dovolené, jiné na návštěvě, na chalupě, u babičky, u bazénu a nebo taky ve školce. Bohužel jsem se setkala i s fotografiemi nejen od rodinných příslušníku, ale například i náhodných účastníků výletů základních škol nebo koupání mateřské školky.

Všechny tyto snímky jsem získala z jednoho českého serveru, všechny jsou veřejně dostupné, všechny mají několik tisíc shlédnutí a některé z nich obsahují mnohdy nechutné komentáře. Těmi to ovšem nekončí. Stává se, že tyto fotografie jsou staženy a znovu použity. Později je tak naleznu i v různých sbírkách dětské pornografie, které nám někdo nahlásil, protože byly veřejně dostupné na Internetu.

Smutné je i to, že je díky těmto fotkám možné odhalit i identitu dětí, případně jejich bydliště, školu, školku atd. Sama jsem si vyzkoušela u jedné z fotografií, jaké všechny možné informace dokážu najít. A hádejte? Jméno a příjmení mi bylo jasné velmi rychlé, našla jsem dokonce i porodnici s přesnými mírami a časem narození. A pátrání pokračovalo. Podle fotky a data na ní jsem zjistila momentální věk dítěte. Dále jsem našla adresu a pomocí sociálních sítí i další informace: koníčky, název základní školy, kroužky a hodně jmen kamarádů a spolužáků. Celá anabáze trvala cca dvě hodiny, a to nejsem žádný velký sociální inženýr. Jak dlouho to může trvat někomu, kdo v tom dokáže chodit?

Přemýšlejme nad tím, co o sobě a své rodině zveřejňujeme! Zajímavé rady a informace můžete najít i na našich facebookových stránkách STOPonline.cz.

Kategorie:

DNS64 v české zóně

Čt, 10/18/2018 - 10:18

Systém doménových jmen (DNS) se pomalu vzpamatovává z výměny root klíče pro DNSSEC. V době psaní tohoto článku, nejsou známy žádné významné problémy, které by tato změna způsobila. To je i pro naši českou národní doménu velmi dobře, protože každou druhou doménu máme DNSSECem zabezpečenou. Situace je horší se zaváděním IPv6 (jedná se o celosvětový problém, viz přednáška Geoffa Hustona Is IPv6 only for the Rich? na letošním RIPE 76).

DNS64

Nicméně, zkusme si na chvíli představit, že chceme mít určité služby a nebo dokonce celou kancelář IPv6-only. Motivací může být několik, i když v současné době pravděpodobně nejsou příliš silné:

  • nechceme si připlácet za IPv4 adresy,
  • nechceme konfigurovat jak IPv4 tak IPv6, protože tím roste složitost a náchylnost k chybám,
  • budujeme interní infrastrukturu, kde může být výhodné mít spíše filtrovanou IPv6 než IPv4 NATované rozsahy,
  • chceme otestovat, kde všude nám chybí IPv6 a nebo kde je špatně nakonfigurovaná.

V průběhu budování takové IPv6-only sítě pravděpodobně zjistíme, že existuje určité (dle konkrétních požadavků různě velké) množství služeb, které protokol IPv6 neimplementují. Možných řešení je několik:

  • DNS64+NAT64
  • 464XLAT
  • HTTP a HTTPS proxy

Nás z hlediska DNSSECu bude zajímat právě první možnost a to konkrétně její část DNS64. Ta má na starosti DNS překlad pro záznamy, které mají pouze IPv4 adresu. V tomto případě DNS64 vytváří neexistující IPv6 záznam využívající NAT64, který se již postará o zbytek překladu pro konkrétní IPv4-only službu. DNS64 samozřejmě nemá možnost doplnit chybějící DNSSEC podpisy a proto tyto záznamy budou nevalidní.

DNS64-nekompatibilní domény

Přechodový mechanismus DNS64+NAT64 tedy není možné použít pro domény, které jsou zabezpečeny DNSSECem. Před dvěma lety napsala Jen Linkova článek Let’s talk about IPv6 DNS64 & DNSSEC, kde analyzovala, kolik takovýchto nekompatibilních domén je v prvním milionu světově nejčastěji navštěvovaných doménách (podle serveru Alexa).

Za dva roky se ovšem mohlo hodně změnit a proto jsem analýzu v srpnu 2018 opakoval a zároveň připojil analýzu pro naší TLD .CZ.

Alexa 1M 2016 * Alexa 1M 2018 .CZ 2018 Počet domén 1 000 000 1 000 000 1 294 217 IPv6 5.7 % 18.0 % 30.2 % DNSSEC 1.7 % 6.1 % 52.6 % IPv4-only 94.3 % 79.5 % 63.1 % DNS64-nekompatibilní 1.3 % 1.5 % 34.0 %

* Pro rok 2016 vycházím ze statistiky Jen Linkové.

Závěr

Z dat a grafu je patrné, že počet domén zabezpečených DNSSECem a domén, které podporují protokol IPv6 roste podobně, i když DNSSEC se zavádí malinko rychleji a proto mírně roste i počet DNS64-nekompatibilních domén. Pro naši národní doménu, ale platí, že zavádění DNSSECu výrazně předbíhá zavádění IPv6 a tedy každá třetí doména s koncovkou .CZ není kompatibilní s přechodovým mechanismem DNS64.

To neznamená, že bychom měli na DNSSEC zanevřít, ale spíše nás to může motivovat k větší snaze o implementaci protokolu IPv6 a nebo k výběru jiného přechodového mechanismu než je NAT64+DNS64.

Kategorie:

CSIRT.CZ se zapojil do kampaně Evropský měsíc kybernetické bezpečnosti

St, 10/17/2018 - 13:43

Měsíc říjen je již tradičně Evropským měsícem kybernetické bezpečnosti. Smyslem této akce je rozšiřovat mezi širokou veřejností povědomí o kybernetické bezpečnosti. Jako každý rok i letos se do této kampaně zapojil Národní bezpečnostní tým CSIRT.CZ. Co již proběhlo a kde nás naopak ještě můžete vidět?

Hned na začátku měsíce jsme přednášeli na odborné konferenci věnované problematice kyberkriminality a její prevence – Praha bezpečně online 2018. V jejím rámci představila kolegyně Kateřina Vokrouhlíková fungování linky STOPonline, kterou provozuje sdružení CZ.NIC v rámci fungování CSIRT.CZ.

Dalším cílem našeho týmu pak byla konference v Telči pořádaná Národním úřadem pro kybernetickou a informační bezpečnost nazvaná Kyberbezpečnost ve školním prostředí. Této akce se zúčastnili pedagogové ze základních škol.

A co nás ještě čeká? 18. a 19. října proběhne v Jihlavě mezinárodní konference Řešení elektronického násilí a kyberkriminality, kterou pořádá Kraj Vysočina ve spolupráci s Krajským ředitelstvím policie Kraje Vysočina a Policejní akademií. Zde se můžete těšit na vystoupení zástupce CSIRT.CZ v panelu věnovaném problematice policejního pohledu na dětskou kybernetickou kriminalitu.

19. října se s naší osvětovou činností zaměříme na naše nejmenší. V národní Národní technické knihovně budeme přednášet dětem o rizicích, která na ně číhají. V rámci akce Ochutnávka programování pro školáky (pořádá EURid, správce národní domény nejvyšší úrovně .eu) opět zúročíme zkušenosti, které náš tým získal při dlouhodobém provozování Internet Hotline.

Série našich říjnových vystoupení vyvrcholí 25. října na karlovarské konferenci Internetem bezpečně 2018. Ta je rozdělena do několika samostatných částí, které jsou určené pro preventisty Policie České republiky, Městských policií, zaměstnanců městských a obecních úřadů, Odborů sociálněprávní ochrany dětí, neziskových společností, učitelům, výchovným poradcům, zaměstnanců dětských domovů a SOS vesniček nebo ředitele škol a pro policisty ze základních útvarů. Odpolední program konference je pak určen rodičům dětí a dalším zájemcům. Program této akce se tedy bude týkat opravdu širokého spektra posluchačů a nás velmi těší, že v každé z částí, určených jinému typu posluchačů, bude mít CSIRT.CZ svého zástupce.

Rádi vás na některé z plánovaných akcí uvidíme!

Kategorie:

Zprovoznili jsme druhý 100GE DNS stack v ČR

Čt, 10/11/2018 - 02:13

Po necelém roce od spuštění historicky prvního 100GE DNS stacku v České republice (tisková zpráva) jsme spustili do provozu v pořadí již druhý 100GE DNS stack. Několikanásobně jsme tím zvýšili odolnost infrastruktury autoritativních DNS serverů proti případným DoS útokům. Zprovozněním druhého stacku současně také snižujeme závislost na konkrétním datacentru, výrobci hardware a DNS démonovi.

Průběhu prací na prvním 100GE DNS stacku, od návrhu, přes výběrové řízení až po umístění v datacentru a zprovoznění, se věnoval několikadílný seriál. Díky získanému know-how jsme tak realizovali druhý stack v kratším čase.

V čem se tedy druhý stack liší? Především ve výběru výrobců veškerého hardware, softwarového vybavení, ale také racku a fyzického umístění.

Lokalita a rack

Druhý 100GE DNS stack je umístěn v další pražské lokalitě, konkrétně v datacentru CeColo na Bohdalci.

Rack v zásadě odpovídá parametrům předcházejícího, včetně typů dveří perforace, uzavírání. Je však o 5U vyšší. Konkrétně se jedná o Conteg RSF-48-80/120. Požadavek na rack vyšší než 42U byl dán převážně vyšším routerem. Současně nám to napomůže i k pohodlnějšímu vedení kabeláže. Stejné jsou také vertikální vyvazovací panely a dvojice měřitelných PDU, v tomto případě APC 8886. Protože jsme věděli, že tento nový rack bude mít příkon více jak 5 kW, zdokonalili jsme spolu s instalací racku systém chlazení v datovém centru pomocí principu teplé a studené uličky.

Hardware a software

V rámci požadovaného dodržení diverzity pro klíčové parametry DNS infrastruktury byly ve výběrovém řízení router a switche tentokrát vybrány od společnosti CISCO. Jednalo se konkrétně o

    • 2 x 1U 100GE switch Cisco Nexus 3232C

    • 2 x 1U 1GE switch Cisco Nexus 3048

    • 1 x 6U router Cisco ASR-9904

Router Cisco ASR-9904 je na rozdíl od použitého routeru Juniper MX240 v první lokalitě o 1U vyšší, narostl tedy na celkových 6U. Je osazen 2x Route Switch Processorem 880 a 2x 400G modular line kartami, do kterých jsou vloženy 2+2 MPA moduly 1x 100GE s adaptéry CFP2 to CPAK.

Pohled na router Cisco ASR-9904

Pro vedení optických vláken jsme opět využili řešení rozvadeče IANOS EDR od společnosti Huber+Shuner v provedení 1U a za použití několika patching modulů single size, Base-2, 6x LCD violet, OM4. ODF jsme tentokrát využili pouze k propojení se zbylou infrastrukturou a síťovými prvky, nikoliv k propojení všech DNS serverů jako v předchozím případě.

Uplink ke všem DNS serverům byl realizován jiným způsobem. A to přímo do switchů Nexus 3232C, pomocí tzv. rozpletů 40Gb MPO na 4x 10Gb LC. Tyto switche byly následně připojeny pomocí 4x MPO/MPO MM OM4 optických kabelů do 100GE adaptérů v routeru.

Switche Nexus 3048 poslouží výhradně pro připojení managementu všech serverů a také pro správu celého stacku.

Pohled na switche Cisco Nexus 3232C, Nexus 3048 a IANOS EDR ODF

Konfigurace a celkový počet serverů zůstává stejný, tzn. 30 DNS serverů a jeden server pro management celého stacku. Servery však byly dodány od jiného výrobce, od společnosti HPE v provedení 1U DL360 Gen9. Po softwarové stránce je rozdíl v použitém DNS démonovi. V případě prvního DNS stacku je použit námi vyvíjený Knot DNS server, v druhém DNS stacku je pak implementace od ISC BIND. Díky pravidelnému testování výkonnosti různých DNS démonů víme, že se BIND dlouhodobě neumisťuje na předních místech. Proto plánujeme, že jej v blízké době nahradíme jinou implementací, např. NSD démonem, který slibuje rychlejší odezvy a tím i lepší využití dostupného výkonu.

Hardwarové konfigurace serverů, routeru a jednotlivých switchů jsme stejně jako v případě prvního Velkého stacku optimalizovali primárně pro 100GE uplink do peeringového uzlu NIX.CZ a také do tranzitu. V současné době máme v lokalitě CeColo uplink do tranzitu zatím o rychlosti 10GE. Jednáme však o navýšení na 100GE, kterého bychom se měli dočkat v horizontu jednoho až dvou měsíců.

Pohled na servery z přední strany

Pohled na servery ze zadní strany

Závěrem ještě jedna designová perlička.. Na připojení metalických patchcordů jsme použili barvu trikolóry, jako vzpomínku na sté výročí založení naší republiky a dvacáté výročí založení sdružení CZ.NIC. Červená je využita pro vzdálený management iLO, modrá s bílou pro management serverů a správu stacku :-).

Kategorie: