Hosting

Přihlášení

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

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:

Registrace domény aneb Na co si dát pozor

Po, 09/24/2018 - 13:17

Výborně! Dostali jste skvělý nápad – vaše nová služba nebo zboží budou prostě jedinečné. Nikdo jiný je zatím nenabízí. Takže teď už je jen správně pojmenovat a vymyslet, jak je dostat k zákazníkům.

S pojmenováním vašeho výrobku, služby nebo společnosti a jejich propagací, která se určitě bude odehrávat i v prostředí Internetu, úzce souvisí i volba vhodného jména domény a jeho registrace a také dodržení pár jednoduchých kroků, aby se vše podařilo tak, jak má. Tak jako byste nechtěli, aby autorství nebo ochranná známka produktu připadly někomu jinému, stejně tak určitě budete chtít být majitelem zaregistrované domény. Pojďme si shrnout na co si dát pozor:

1. je naprosto pochopitelné, že z toho, že jste vymysleli úžasný produkt/službu a jeho trefné pojmenování máte ohromnou radost. Přesto však ovládněte svoji touhu se s ním chlubit a také objednávat tisky a potisky nejrůznějších materiálů a předmětů, natáčení reklamních spotů či výrobu bannerů, a to přinejmenším do té doby, než máte zaregistrovanou doménu, případně tedy založenou společnost (nebo jinou organizaci, pro prospěšné aktivity můžete třeba zakládat spolek).

2. za úvahu může stát také případná ochrana názvu vašeho produktu, služby či společnosti ochrannou známkou či ochrana vašeho nápadu jiným vhodným způsobem v závislosti na jeho povaze (např. patent, užitný vzor…). S žádostí o radu se obracejte na advokáty či patentové zástupce, informace naleznete též na stránkách Úřadu průmyslového vlastnictví. Nenechte se zlákat nabídkami, často doprovázenými rovnou výzvou k úhradě, které vám přijdou e-mailem nebo poštou po vzniku společnosti. Český Úřad průmyslového vlastnictví před nimi na svých stránkách varuje a informace pravidelně aktualizuje, na mezinárodní úrovni činí totéž Světová organizace duševního vlastnictví – WIPO.

Zdroj: www.upv.cz

3. pokud si registrujete doménu, obracejte se na subjekt, kterému důvěřujete, který znáte, případně který si prověříte. Sdružení CZ.NIC, které spravuje rejstřík domén druhé úrovně (to je třeba „dobradomena.cz“), které jsou registrovány pod českou národní doménou .cz, , nabízí na svých stránkách seznam subjektů, registrátorů, kteří s ním mají uzavřenou smlouvu a nabízejí registrace domén. Pochopitelně, a je to samozřejmé, se ale může stát, že se žádostí o registraci domény oslovíte někoho ze svého okolí, protože „počítačům rozumí“.

Ujasněte si proto, co vlastně chcete, ujistěte se, že víte, co bude zahrnovat platba (kromě domény budete totiž potřebovat také prostor, kde bude umístěna vaše prezentace, tedy hosting) a důkladně si přečtěte obchodní podmínky nebo smlouvu (ano, to nebývá zrovna zábavná část, ale nepodceňujte ji). Pokud v nich něčemu nerozumíte, nebojte se svého dodavatele zeptat. Nejspíše totiž nebudete v postavení spotřebitele, hledí se na Vás jako na profesionála a nepožíváte tak automaticky ochrany slabší strany.

Splnění předchozího se vám bude ale obtížněji dařit, pokud za vás doménu registruje např. kamarád či někdo, kdo už pro vás něco dělá, např. grafické studio, ale na vaše jméno, jméno vaší společnosti. Ideální stav samozřejmě je, pokud, než provede registraci, vás seznámí s tím, kde tak hodlá učinit a poskytne vám detailní informace o smluvním vztahu, do kterého vlastně jeho prostřednictvím hodláte vstoupit.

Ještě o něco horší je pro vás varianta, pokud ji registruje za vás, ale ne na vás, ale na sebe, protože „aby to bylo jednodušší…všechno za Tebe vyřídím a vždycky Ti dám vědět, když bude něco potřeba, to se vždycky domluvíme“. Tuhle variantu určitě nelze doporučit. Doména, která nese jméno vaší společnosti, zboží nebo služby nebo dokonce jméno vaše, by měla patřit jen a jen vám. Nepodezírejme hned vašeho kamaráda či dodavatele jiných služeb z nekalých úmyslů, ale stačí nešťastná náhoda a vaše, totiž vlastně ne vaše doména, se stane např. součástí dědického či insolvenčního řízení. Nepříjemné může být i prosté ukončení činnosti takového prostředníka, o kterém se dozvíte až v okamžiku, kdy doména přestane fungovat, odstěhování kamaráda na druhý konec světa nebo jen to, že přestane používat kontaktní údaje, které do vaší, totiž jeho domény uvedl. Věřte, že mnoho toho v takovém případě nezmůžete anebo vás to bude stát poměrně dost námahy, taky finančních prostředků, a s rychlým vyřízením příliš nepočítejte (a aktualizací vašeho webu tím pádem taky ne).

Ohlídejte si proto důkladně, že registrace domény, ať už ji máte pro podnikání nebo pro jiné aktivity, bude provedena na vás a zkontrolujte si, že se to tak opravdu stalo. Spolehlivým zdrojem pro ověření je databáze whois na stránkách CZ.NIC, kde si po zadání názvu domény jednoduše ověříte, kdo je jejím držitelem – a měli byste to být právě vy, případně Vaše společnost (doména pak ostatně vstupuje i do jejího majetku). Pokud vám chce Váš kamarád pomoci, tohle určitě pochopí. K registrované doméně je možné zadat více informací a kontaktů, než jen držitele. Proto není problém, aby na něj byl veden kontakt např. v podobě e-mailu pro notifikaci u kontaktu držitele nebo aby byl uveden jako administrativní kontakt.

Zdroj: www.nic.cz

Kategorie:

Jak přežít plánovanou údržbu DNS

Čt, 09/20/2018 - 09:20

Systém DNS se na Internetu používá již více než 30 let – nyní je naplánována jeho celosvětová údržba, která poprvé za dobu existence DNS potřebuje koordinaci s provozovali DNS serverů a DNSSEC validátorů.

Následující článek shrnuje zásadní kroky, které by provozovatelé DNS serverů měli provést, aby jejich uživatelé neměli potíže po plánované údržbě DNS na konci roku 2018 a začátku roku 2019.

Kroky nutné pro „přežití“ údržby DNS se liší pro provozovatele DNSSEC validujících resolverů a autoritativních serverů:

  • DNSSEC validátory musí být aktualizovány nejpozději 10. října 2018
  • Autoritativní servery musí být aktualizovány nejpozději do 31. ledna 2019

Po uvedených termínech přestane software se zastaralou konfigurací fungovat správně. Dopad jednotlivých změn podrobněji uvádíme v příslušné kapitole níže.

Rekurzivní servery a DNSSEC validátory Nejpozději do: 10. října 2018

Provozovatelé rekurzivních serverů a dalšího softwaru, který provádí DNSSEC validaci, musí nejpozději 10. října 2018 aktualizovat DNSSEC root klíč (anglicky trust anchor), který slouží k validaci podpisů získaných z veřejného DNS. Dne 11. října 2018 v 18:00 CEST bude (historicky poprvé) DNS root zóna podepsána novým klíčem.

Z tohoto důvodu software, jehož konfigurace neobsahuje nový DNSSEC root klíč, nebude od 11. října 2018 schopen resolvovat žádná data pomocí DNS a z hlediska běžného uživatele „Internet nebude fungovat“.

Jak se připravit?

Provozovatelé DNSSEC validátorů by proto měli zkontrolovat, že jejich konfigurace obsahuje oba DNSSEC root klíče, aby přechod ze starého na nový klíč mohl proběhnout bez lidského zásahu. Konfigurační soubor s klíči by měl obsahovat následující dva řádky (nebo jejich ekvivalent, v závislosti na formátu používaném konkrétním softwarem):

. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 . IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D

První řádek obsahuje klíč s ID 19036 používaný do 10. října 2018, zatímco druhý řádek obsahuje nový klíč s ID 20326, který se bude používat od 11. října 2018.

Software BIND na rozdíl od většiny používá jiný formát souboru s klíči, takže správci BINDu by měli zkontrolovat, že jejich soubor s klíči obsahuje následující text:

managed-keys { . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0="; . initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 +/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN R1AkUTV74bU="; };

Pojmenování a umístění souborů i jejich přesný formát záleží na konkrétní verzi softwaru a použitém operačním systému. Z toho důvodu doporučujeme podívat se na návody pro obvyklé případy na stránkách organizace ICANN (anglicky).

Uživatelé Turris Omnia s aktualizovaným operačním systémem se nemusí přechodu obávat, protože nový klíč mají již automaticky nainstalovaný na svých zařízeních.

Autoritativní servery Nejpozději do: 31. ledna 2019

Provozovatelé autoritativních serverů by měli nejpozději do 31. ledna 2019 zajistit, že jejich implementace jmenného serveru správně odpovídá na dotazy s rozšířením EDNS. Přesně podle zveřejněného plánu přestanou významní výrobci DNS software po 1. únoru 2019 (také historicky poprvé) podporovat servery, které porušují DNS standard RFC 6891 i jeho předchůdce RFC 2671.

To prakticky znamená, že servery, které po 1. únoru nebudou odpovídat na dotazy s EDNS rozšířením přestanou z pohledu klientů fungovat a domény hostované na těchto serverech se stanou nedostupné!

Jak se připravit?

Prvním krokem je kontrola, že váš autoritativní DNS server odpovídá správně. K tomu slouží samostatný informační web s testovacím nástrojem dnsflagday.net. Do formuláře na tomto webu zadejte jméno libovolné domény, která je hostována na vašem DNS serveru:

Drtivá většina čtenářů tohoto článku uvidí po kliknutí na tlačítko „Testuj!“ následující hlášení:

V takovém případě nemusíte nic dělat – váš autoritativní server je již připraven.

Pokud testovací nástroj nalezne problém, bude vás informovat např. takto:

Typicky se dají nalezené problémy vyřešit pouhou aktualizací DNS software na jmenných serverech, které hostují testovanou doménu. V ojedinělých případech může být problém způsoben také příliš striktním firewallem, který zahazuje DNS dotazy s některým z rozšíření EDNS.

Další informace spolu s testovacím nástrojem a doporučeními k řešení problémů naleznete na webu dnsflagday.net/cs/.

Závěrem nezbývá než popřát všem provozovatelům DNSSEC validátorů i autoritativních serverů hladkou aktualizaci software a bezproblémový vstup do dalšího třicetiletého období DNS.

Kategorie:

ID4me – jednotná identifikace a domény na německý způsob

Út, 09/11/2018 - 11:02

V sídle německého doménového registru DENIC se 14. srpna sešlo přes 50 zástupců internetových společností, aby se zúčastnili prvního ročníku ID4me summitu. ID4me je aktuální název projektu, který pod názvem DomainID vznikl již loni, a zmínil jsem ho krátce v prezentaci na naší loňské konferenci IT 17.2. Za jeho vznikem stojí právě správce domény .DE spolu s významným německým registrátorem 1&1 a společností Open-Xchange, provozovatelem internetových kolaborativních nástrojů. Společností, které se aktivně hlásí jako podporovatelé, je ale více a nechybí mezi nimi například britský doménový registr Nominet. Cíle, které si projekt stanovil, jsou nám poměrně známé – redukovat množství hesel a registrací při pohybu uživatelů po Internetu. Podobně jako CZ.NIC s projektem mojeID, došli autoři ID4me k závěru, že doménový svět je právě tím místem, kde je možné pokusit se těchto cílů dosáhnout.

Na rozdíl od mojeID, které je samo o sobě službou k okamžitému použití, snaží se ID4me spíše o vytvoření ekosystému spolupracujících organizací, které budou podporovat řešení popsané sadou standardů vznikajících postupně v rámci projektu. Do tohoto ekosystému se již podařilo poměrně rozsáhlou kampaní zapojit řadu zajímavých společností. Relativně nedávno došlo k založení společnosti ID4me AISBL (nadace) se sídlem v Bruselu, která bude členskou organizací a která by měla veškeré aktivity související s projektem zaštiťovat. V tuto chvíli se rozvoj projektu soustředí kolem tří pracovních skupin a jim odpovídajících mailinglistů. V technické pracovní skupině se řeší protokoly a specifikace, na kterých projekt stojí. V organizační pracovní skupině se řeší, jak má ekosystém fungovat na úrovni různých (např. právních) vztahů mezi jeho členy. Poslední adopční pracovní skupina je zaměřená na marketing celého projektu.

Z technického pohledu staví ID4me na používaném standardu OpenID Connect, což mu zajišťuje poměrně dobrou výchozí pozici pro interoperabilitu s existujícími systémy. V mojeID podporujeme tento protokol od roku 2015. ID4me ale přidává tři koncepty, které nejsou příliš obvyklé a reflektují snahu propojit doménový svět se světem identitním.

První z těchto konceptů je rozdělení autentizační služby na dva subjekty. V terminologii ID4me se jedná o Autoritu a Agenta. Agent je subjekt, ke kterému přijde zákazník jako první, předá mu svoje údaje a požaduje zřízení služby. Jak už asi tušíte, v doménovém světě se tomu subjektu říká Registrátor. Autorita je naopak služba, která garantuje vlastnictví identifikátoru a přiděluje ho konkrétnímu uživateli. Opět, analogický subjekt pro doménový svět je Registr. Autorita je tedy zodpovědná za ověření přihlašovacích údajů uživatele a Agent je zodpovědný za uchovávání a předání jeho dalších údajů. Způsob, jakým je tento koncept namapován na OpenID Connect protokol, je poměrně originální. V terminologii OpenID Connect je tento přístup označován jako „Distributed claims“. Uživatel se protokolem OpenID Connect standardně přihlásí u Autority, nicméně místo předání údajů přihlášeného uživatele Autorita poskytne adresu ze systému Agenta, na které je možné se k údajům dostat. Jeden konkrétní subjekt může ale plnit roli jak Autority tak Agenta. Pro standardní službu, která umožňuje přihlášení přes OpenID Connect, by toto rozdělení nicméně neměl být problém.

Druhým konceptem je myšlenka ustanovit doménové jméno jako primární identifikátor. Uživatel si pořídí doménu a bude jí používat pro přihlášení do všech systémů podporujících ID4me. Pouze manipulací s DNS záznamem u této domény si uživatel může určit, kdo je Autorita a Agent pro toto doménové jméno. Toto je určeno speciálním TXT záznamem u poddomény _openid. Samozřejmostí je, že záznamy u této domény musí být zabezpečeny pomocí DNSSEC. Majitel doménového jména by měl tak mít teoreticky možnost jednoduchou změnou TXT záznamu přejít k jinému poskytovateli identitních služeb. Přestože je snaha tento způsob počáteční identifikace uživatele standardizovat, není aktuálně součástí standardu OpenID Connect a vyžaduje tak změny na straně poskytovatelů služeb.

Třetí koncept, který úzce souvisí s předchozím, ale který přesto vidím jako samostatný prvek, je snaha poskytnout službě, která použije ID4me informaci, že přihlášený uživatel je opravdu držitelem zvolené domény. Tuto informaci se služba po přihlášení dozví se speciálního atributu id4me_identifier. Určitou úroveň důvěry tomuto atributu dává proces ověření pomocí DNS varianty ACME protokolu, které by měla provést Autorita předtím, než uživateli vytvoří účet. Jedná se ale o jednorázové ověření při registraci a tudíž nic neříká o aktuálním stavu. Navíc pokud by toto ověření bylo povinné, limituje to zapojení existujících služeb. Dle mých informací se ale zatím neuvažuje, že by tato povinnost byla vynucována.

Autoři ID4me nezůstávají v teoretické rovinně a připravili i sadu knihoven, která zmíněné koncepty implementuje. Existuje projekt na Gitlabu, kde je možné si stáhnout kód, nebo případně diskutovat nad požadovanými změnami. Existují již i některé pilotní projekty, které umožňují přihlášení přes ID4me. Abychom si otestovali kompatibilitu ID4me, zavedli jsme do DNS požadovaný záznam v následujícím formátu:

_openid.mojeid.cz. IN TXT „v=OID1;iau=mojeid.cz/oidc;iag=mojeid.cz/oidc“

Pokud se chcete přihlásit ke kolaborativnímu řešení Open-Xchange s využitím mojeID, stačí když do formuláře napíšete mojeid.cz a kliknete na tlačítko „Sign with ID4me“. Pokud si navíc zaregistrujete doménu a přidáte si k ní tento stejný TXT záznam, budete se nově moci přihlašovat s použitím vaší domény. Obdobným způsobem je možné otestovat si přihlášení u technologického zpravodajského serveru AndroidPIT. Bude určitě zajímavé sledovat, kam se bude celý tento projekt dál rozvíjet.

Kategorie:

Aplikace Open Nettest měřila rychlost Internetu až ve Francouzské Polynésii

St, 09/05/2018 - 11:32

Kdo si chce otestovat rychlost svého připojení k Internetu, nabízí se mu v obchodě s aplikacemi hned několik možností. V rámci mezinárodního projektu “Open crowdsourcing data related to the quality of service of high-speed Internet” (zkráceně MoQoS) vznikla aplikace na měření vysokorychlostního Internetu s názvem Open Nettest. Pomocí této aplikace je možné otestovat např. rychlost připojení v telefonu, které nám poskytuje mobilní operátor, či rychlost připojení prostřednicvím Wi-Fi sítě.

Jaká je kvalita připojení v České republice?

To je možné zjistit pomocí vizualizační mapy, která se nachází přímo v aplikaci. Do této mapy se zároveň propisují měření provedená pomocí českého NetMetru, na jehož vývoji se v CZ.NIC podílíme. Díky barevným bodům je na první pohled patrné, v jakých oblastech je silnější či slabší signál. Zatímco hlavní město se doslova “zelená”, tedy pyšní kvalitním pokrytím, v některých oblastech naší vlasti se stále ještě nacházejí místa s velmi slabým, ba dokonce s nulovým signálem.

Jak jsou na tom ostatní státy světa?

Aplikace Open Nettest měřila rychlost připojení k Internetu i v exotických zemích jako je Francouzská Polynésie, Východní Timor, Fidži či Svazijsko. Nejvíce měření však bylo provedeno ve Slovinsku, dále v Německu a na Slovensku. Rakousko, odkud Open Nettest pochází, se překvapivě nachází až na čtvrté příčce.

Které dny a časy jsou nefrekventovanější?

Zajímavostí je, že testy pomocí aplikace Open Nettest jsou nejčastěji prováděny v úterý odpoledne (mezi 13. a 15. hodinou) a později večer (mezi 21. a 23. hodinou). Aplikace je dále hojně využívána během pátečních, sobotních a nedělních večerů.

Kolik měření již bylo provedeno?

Od počátku projektu (1. leden 2017) bylo pomocí Open Nettestu provedeno cca 400 000 měření. 71 % z nich učinili uživatelé mobilních telefonů s operačním systémem Android, 17 % testů uskutečnili vlastníci iPhone, 11 % měření bylo realizováno prostřednictvím hardwarových sond (routerů Turris) a 1 % spadá na testy z webového prohlížeče. Open Nettest totiž umožňuje, stejně jako NetMetr, provést měření přímo na webu, např. z domácího počítače.

V rámci projektu MoQoS dochází k neustálému vyvíjení jak aplikace Open Nettest, tak aplikace NetMetr. V obou aplikacích je možné spustit tzv. kontinuální (cyklické) měření, které je prováděno v pravidelných intervalech a s menším nárokem na spotřebu dat od mobilního operátora. Dále aplikace umí odhalit a následně zobrazit ve vizualizační mapě takzvaná bílá místa, což jsou body, kde byl zachycen nulový signál.

Abychom dosáhli větší relevance výsledků měření a mohli z nich všichni těžit, je důležité provést co největší množství měření. Poté se lépe podaří zmapovat situaci mobilního datového připojení v České republice i ve světě a v neposlední řadě tak přispět ke zlepšování pokrytí signálem a jeho kvality mobilními operátory. Kromě marketingových kampaní se za účelem zvýšení počtu uživatelů a uskutečněných měření, v rámci aplikace Open Nettest, zavádí takzvaná gamifikace (odměňování) ve formě postupného získávání odznaků, které jsou opatřeny veselými dětskými ilustracemi.

Kategorie:

Fotka

Čt, 08/16/2018 - 14:06

Díky zajímavému projektu s názvem Kdo jiný, který vede nezisková organizace Člověk v tísni, jsem měla to štěstí poznat dvě (na svůj věk) skutečně velké osobnosti. Říkejme jim Kristýna a Sandra. Tyhle dvě holky se na své škole setkaly s poměrně závažnou kyberšikanou, avšak namísto toho, aby se litovaly nebo očekávaly, že se problém vyřeší sám, proměnily tyto nepříjemné životní události ve svou životní zkušenost tím, že se rozhodly problém řešit. Nejen pro sebe, ale i pro ostatní děti, které by mohly podobný osud potkat. Díky aktivnímu přístupu těchto holek a jedné paní učitelky vám mohu přiblížit jejich příběh.

Vše začalo fotkou na Instagramu. Když si na této sociální síti najdete profily slavných modelek a podíváte se na jejich selfie, tak byste bez znalosti nějaké další informace nepoznali, který z profilů patří modelkám a který dívkám. Dívky, jichž příběh vyprávím, si však za svou fotografii nevysloužily obdiv a lajky, ale kyberšikanu. Jejich fotografie se začala naprosto nekontrolovatelně šířit napříč školou. Když dívky zapochybovaly nad rozhodnutím fotografii zveřejnit, bylo již pozdě. Spolužáci si ji mezitím stáhli do svých zařízení a bez jakýchkoli servítek odstartovali aktivity, jež byly pro dívky velmi bolestivé. Toto chování se brzy stalo velkou noční můrou holek a znepříjemňovalo jim téměř každou minutu jejich života, kyberšikana je totiž o to závažnější, že její fyzické projevy nekončí ani zabouchnutými dveřmi od třídy.

Spolužáci, se kterými se dívky nikdy v životě osobně nebavily, je na Internetu napadali způsobem, který skutečně nebylo možné přejít s úsměvem ani bez povšimnutí. Škola se k problému postavila až na jednu pedagožku z mého pohledu velmi zvláštně. Kyberšikana v tuto chvíli pro nikoho nebyla problémem, vedení školy začalo řešit, jak je možné, že dívky vůbec takovou fotografii na Internet daly, a protože se jednalo prokazatelně o fotografii pořízenou v prostorách školy, začal dívkám hrozit školní trest. Naštěstí ve škole působí aktivní pedagožka, která s dětmi pracuje na individuálních projektech. Když se o situaci dozvěděla, navrhla dívkám, zda nechtějí téma zpracovat. Postih dívky sice neminul, ale mohly situaci alespoň trochu uchopit do vlastních rukou. Dívky tedy společně se dvěma spolužáky z ostatních ročníků připravily projekt, jehož výstupem byla osobní konfrontace hlavních iniciátorů kyberšikany s oběťmi.

Dívky si ve spolupráci s pedagožkou a po pečlivé přípravě a spolupráci s odborníky zavolaly útočníky do třídy, kde se jich ptaly, zda by jim věci, které psali na Internetu, byli schopni říci do očí a zda si uvědomují, že svým chováním na sociálních sítích způsobili skutečnou a nemalou bolest. Aktéři zapojení do kyberšikany se až na výjimky v reálné situaci chovali pokorně a byli velice překvapeni ze skutečné konfrontace s reálnými dívkami.

Většina z útočníků uvedla, že z jejich pohledu šlo o legraci, která je v jejich kolektivu naprosto běžná, normální a rozhodně si ji nikdo nebere osobně ani nikomu neubližuje. Já jsem se osobně se dvěma útočníky sešla a mohu potvrdit, že jsem z nich měla pocit, že mluvím s naprosto rozumnými a hodnými lidmi, kteří mají sice drsný smysl pro humor a odlišný přístup k životu, ale rozhodně se nejedná o žádné agresory.

Přesto jejich chování způsobilo nemálo bolesti. Musím říci, že být na místě vedení, zřejmě bych situaci také nevyřešila správně, nevím totiž, má-li vzniklá situace vlastně nějaké správné řešení. Myslím si, ale že podobným situacím lze do jisté míry předcházet patřičnou osvětou. Děti by měly vědět, že pokaždé, když na Internet posílají jakékoli informace, je možné, že se setkají s negativní reakcí nespecifikovatelného okruhu lidí. Obecně je dobrou pomůckou, zeptat se před zveřejněním fotografie sám sebe, zda by se nás dotklo, kdyby fotografie, kterou posíláme na Internet, viděla celá naše třída na velké obrazovce nebo zda by se líbila naší babičce. Zároveň bychom měli naše děti učit respektu. Tím mám na mysli především to, že je naprosto zřejmé, že na světě neexistují dva stejní lidé, vždyť stačí znalost o jedinečnosti otisku prstu. Pokud tedy někdo řekne, že mu nějaké jednání ubližuje, neměla by být reakce „ale vždyť je to sranda“ považována za normální. Naopak, měli bychom naše děti učit omluvit se a přijmout pocit druhého člověka jako fakt, kterému nemusí rozumět, ale stačí jej respektovat.

Kategorie: