Hosting

Přihlášení

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

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:

Druhý ročník kybertábora je úspěšně za námi

St, 08/15/2018 - 10:36

V Akademii CZ.NIC jsme minulý měsíc spolupořádali druhý kybertábor pro dvacet dětí z Domova dětí a mládeže Prahy 9.

Seznamovací hry jsme po zkušenosti z loňského roku rovnou vynechali a s dětmi jsme se hned pustili do věcí, které pro ně měli přichystané Nora s Lukášem, naši kolegové od 3D tisku. Kromě této zábavy měly děti za úkol ještě „offline“ výrobu herních desek, na kterých si potom mezi sebou zahrály turnaj. Milým zjištěním pro nás bylo, když jsme se dozvěděli, že některé děti hrály hru i večer s rodiči. Turnaj se dohrával ještě v průběhu týdne a jeho vítěz si odnesl malý přenosný repráček. Odpolední program potom čekal děti až v Bohnicích, ale za to cestování stál, hrály se totiž laser games.

Úterý zahájil velkolepě kolega Edvard Rejthar, který má dlouholeté zkušenosti s organizací dětských programů a her. K tomu má navíc zkušenosti z divadelního kroužku, takže děti dokázal svým projevem neuvěřitelně nadchnout. Děti si musely na celé dopoledne vypojit myš a plnit jednotlivé úkoly, které nedoprovázela zábavná grafika. Člověk by si řekl, že to ty děti v životě nemůže bavit. Jenže to, jak to měl Edvard promyšlené a připravené, bylo až neuvěřitelné. Děti žádnou grafiku nepotřebovaly, bavilo je posouvat se o úroveň dál, zjišťovat, že „to nejde“ jsou jen slova, která když přestanou říkat, půjde jim to rychleji. Pod Edvardovým vedením se nejeden účastník kybertábora dozvěděl, jak moc přínosné je umět pracovat s počítačem pomocí klávesových zkratek. Děti, kterým bylo mezi 10 a 15 lety, se tak naučily bez pomoci myši klasické vychytávky jako je přepínání, otevírání a zavírání oken, instalaci programů přes terminál, tvorbu a organizaci nových složek a mnoho dalšího.

Středa i čtvrtek byly pod taktovkou úspěšného absolventa Cyber Security Competition Jirky. Jirka měl pro děti na středu připravený program, který se týkal kybernetické bezpečnosti. Děti se během něj zábavnou formou dozvěděly, jak se mohou starat o svá tajemství a jak je důležitá jejich identita na Internetu. Odpoledne potom děti dostaly malé robůtky, které si sami poskládaly.

Ve čtvrtek jsme důkladně prověřili Jirkovy lektorské dovednosti, když jsme po objevení chyby zjistili, že původní program nelze realizovat. Jirka nám hned oznámil, že to vůbec nevadí, protože má plán B i C. Troufám si tvrdit, že plán B byl asi nejúspěšnějším dopoledním programem celého týdne. Děti se velice snadnou a zábavnou formou učily programovat vlastní hru. Jirkovi to ale nestačilo, chtěl pro děti udělat ještě víc, a tak jim od anglicky hovořícího vývojáře této hry sehnal klíče k jinak placené hře a tuto hru jim na páteční odpoledne nejen že stáhl, ale ještě ke všemu ji přeložil, aby ji děti měly česky. Odpolední program se díky dobrým vztahům našeho kolegy s pány z Českých radiokomunikací a jejich velké laskavosti přesunul na Žižkovskou věž, kde jsme se kromě vyhlídek podívali i na to, jak funguje velké datacentrum.

V pátek k nám zavítaly slečny z Národního úřadu pro kybernetickou bezpečnost, aby děti provedly příběhem Báry Bezhlavé, která si myslela, že Internet je anonymním místem. Jednalo se o workshop, v rámci kterého měly děti prostřednictvím klasického internetového vyhledávače zjistit co nejvíce informací o Báře Bezhlavé. Koneckonců, tento úkol si můžete vyzkoušet také.

Kybertábor se i tentokrát povedl a tak jsem přesvědčená, že bude pokračovat i nadále.

Kategorie:

Upgrade .cz DNS aneb Zákulisí příprav a realizace – část čtvrtá

Út, 08/14/2018 - 09:24

Na začátku roku 2017 jsme začali pracovat na projektu celkového posílení infrastruktury autoritativních DNS serverů zabezpečujících provoz .CZ domény. Hlavní motivací bylo zvýšit odolnost DNS infrastruktury proti DoS útokům, jejichž riziko se zvyšuje stále více. Základní stavební jednotkou nové DNS infrastruktury je tzv. „DNS Stack“.

V předchozím díle seriálu o upgrade DNS infrastruktury jsem popsal proces výběrového řízení na 100GE router, switche a servery. Dnešní díl bude věnován přípravě zázemí v datacentru, konkrétně výběru racku a jeho součástí.

Nový rack

Nejdůležitější diskuze nás čekala hned na začátku. Jaký rack potřebujeme, jaké součásti má obsahovat, jak řešit různé proudění vzduchu zařízení, chlazení, napájení apod. Hlavním požadavkem jsme si byli jisti. Potřebujeme do racku umístit 31 serverů, každý o velikosti 1U, dále dva switche (2U), console server (1U), ODF pro vedení optické kabeláže (1U), horizontální vyvazovací panely (2U) a router o velikosti 5U. Vyšlo z toho tedy, že potřebujeme 42U. Připravili jsme návrh zapojení tak, jak bychom si jej představovali a začali řešit veškeré možnosti od návrh až po finální zapojení se zástupci datacentra.

Proběhlo několik setkání, prohlídka konkrétních racků v sálech, úpravy návrhu zapojení podle technologických možností a další a další změny našeho původního návrhu.

Jak nakonec vypadá rack pro Velký DNS Stack?

Jedná se o Conteg RSF-42-80/120. Jeho výška je 42U, šířka 800mm a hloubka 1200mm. Přední i zadní dveře (dělené) jsou perforované z 86 %, obsahují výklopnou pákovou kliku, uzavírání je vícebodové. Rovnoměrné zatížení více než 1000 Kg. Rack je osazen vertikálními lištami (stojnami) 12x1U, na nichž je uchyceno tzv. STS (side-to-side) řešení. Na tyto lišty se také umísťují vertikální HDWM (vyvazovací panely).

Řešení STS umožňuje dokonale oddělit zónu horkého a studeného vzduchu a je tak možné bezpečně osadit síťové prvky s bočním prouděním vzduchu přímo do blízkosti jednotlivých serverů, které mají proudění vzduchu předozadní. V praxi to vypadá tak, jak ukazuje níže uvedený obrázek:

Zdroj: https://www.conteg.cz

Pravá část (vyznačena žlutě) je zaslepena v celé své výšce od vertikální lišty (stojny) k boku racku. Jedná se o podobné zaslepovací panely, které se umisťují do volných U prostorů, kde nejsou umístěné servery, aby nedocházelo k nechtěnému mísení teplého a studeného vzduchu. Do požadované výšky se pak umisťuje adaptér (vyznačen modře) pro konkrétní síťová zařízení, v našem případě pro router Juniper MX240. Tento adaptér zajistí, že se vzduch dostane pouze k routeru. Prostorem mezi STS a bokem racku je možné umístit např. kabelové tunely pro vedení kabeláže zepředu dozadu.

Výhodou STS řešení je možnost mít všechny technologie umístěné v jednom racku. To je v našem případě zásadní, protože vybraný router má proudění vzduchu právě side-to-side, zatímco ostatní zařízení front-to-back. V opačném případě by musely být servery, router a síťové prvky rozděleny do dvou racků. Nevýhodou je, že STS nastaví pevnou rozteč mezi vertikálními lištami (stojny) na 80 cm. Tato skutečnost nás limitovala ve výběru vertikálního HDWM (vyvazovacího panelu), protože jsme původně požadovali variantu s 19 cm žebry. Použili jsme tedy variantu s 12 cm žebry, konkrétně HDWM-VMR-42-12/10F. Jedno HDWM je umístěno vlevo při pohledu zepředu a druhé vlevo při pohledu zezadu.

Pro napájení všech zařízení jsme použili 2x PDU APC 7857. Každé obsahuje 36 zásuvek IEC320 C13 a 6 zásuvek IEC320C19. PDU jsou umístěné vpravo při pohledu zezadu za sebou a jsou samozřejmě připojeny do třech fází.

ODF a optické moduly

Pro vedení optických vláken k jednotlivým serverům a novému racku jsme na základě doporučení vsadili na řešení rozvaděče ODF od společnosti Huber+Suhner. Jedná se o 19“ 1U nebo 4U šasí, do kterého se vkládají moduly v různých provedeních dle zvoleného typu konektorů, celkového počtu, použití pro single-mode či multi-mode apod.

Zdroj: https://www.hubersuhner.com

Pro naše potřeby jsme vybrali variantu IANOS EDR 1U, která umožňuje osadit až 12 modulů (tj. až 72 konektorů LC/MTP), včetně zadního kabelového managementu. Šasí jsme osadili těmito moduly:

  • 7x patching module, single size, Base-2, 6x LCD violet, OM4 PC

    Zdroj: https://www.hubersuhner.com

    Jedná se o základní propojovací modul, v tomto případě s růžovými konektory. Tato barva na první pohled udává, že jde o multi mode variantu. Do tohoto typu modulů je potřeba zapojit vhodná optická vlákna. My jsme použili kabely multipatchcord 1x MTP(F) – 8xLC/PC OM4. Do těchto modulů jsme klasickými LC/PC-LC/PC MM 50/125 OM4 optickými patchcordy připojovali jednotlivé servery. Tyto kabely jsme si nechali vyrobit na míru v různých délkách od 0,8 do 2 metrů tak, abychom zajistili optimální uložení ve vertikálních vyvazovacích panelech.

  • 1x patching module, single size, Base-2, 6x LCD blue, SM PC

    Zdroj: https://www.hubersuhner.com

    Modrý patching modul je oproti předchozího modulu určen pro single mode a použili jsme ho k připojení tranzitní konektivity.

  • 1x transition module, double size, Base-12, front 12xLC/PC, rear 2xMTP, OS2

    Zdroj: https://www.hubersuhner.com

    Tento modul je uvnitř plně osazen a realizuje přechod mezi MTP na vstupu a LC na výstupech. Použili jsme jej pro propojení mezi nových rackem a stávající infrastrukturou za použití 2x MTP-MTP / 12F SM kabelů. Těmito vlákny jsme přivedli všechny důležité propoje k novému routeru.

 

Další díl bude věnován instalaci, testování a přípravě pro nasazení do provozu.

Kategorie:

Dílna technických pisálků po třetí

Po, 08/13/2018 - 10:58

Dne 14. června proběhl v Akademii CZ.NIC 3. ročník, pomalu již tradičního, workshopu výměny zkušeností mezi technickými dokumentaristy, nebo-li TW workshop. Mluvčí opět přednesli velmi zajímavá témata, jejichž přehled můžete najít na stránce workshopu. Na tomto ročníku se sešlo zatím nejvíce účastníků (17) a jejich hodnocení pro nás byla velkým povzbuzením pro další opakování této akce. Pojďme se podívat podrobněji na jejich i moje dojmy.

Kupříkladu Marie z RedHatu o workshopu napsala:

„TW workshop je vcelku komorní akcí s omezeným množstvím účastníků, což je skvělé z několika různých důvodů. Setkávají se tu totiž techwriteři působící v České republice, kteří přicházejí z firem rozdílných velikostí. Někteří účastníci workshopu mají dlouholeté zkušenosti, jiní teprve začínají. … Když jsem se skrze své kolegy dověděla o existenci TW workshopu, věděla jsem, že tohle je pro mě skvělá příležitost jak ‚vplout‘ do světa konferencí v oblasti techwritingu. Vzhledem k limitovanému počtu 20 účastníků jsem věděla, že v pozici nováčka nebudu stresována velkým publikem a navíc propozice deklarovaly důležitost prostoru pro diskuzi, na kterou byl vymezen opravdu dostatek času. Tedy skvělá příležitost pro výměnu zkušeností, učení se od zkušenějších, diskuzi aktuálních problémů … Tehdy mi to velmi pomohlo!“

Prezentace tvoří hlavní program workshopu a dávají především prostor pro sdílení zkušeností v techwritingu (technické dokumentaristice). Nabízejí současně také příležitost začínajícím mluvčím, aby si mohli vyzkoušet prezentovat a rozvíjet své prezentační dovednosti před malým publikem. To ale není jediný pilíř workshopu.

Stejně důležitá, možná i nejdůležitější, je možnost si volně a neformálně popovídat s techwritery z jiných společností. Jak říká naše pravidelná účastnice Vendula z Dativery, jejíž slova volně parafrázuji: „Tu nejdůležitější věc dne se obvykle dozvím při přestávce na kávu.“. Já jsem se tak například doslechla o první vlaštovce v akademickém vzdělávání techwritingu, která přiletí na Technickou univerzitu v Liberci. Proč je to tak důležité?

Dlouhodobě se totiž zabývám tím, jak dostat profese technické komunikace jednak do povědomí na trhu práce i obecně a jednak na akademickou půdu. Jak jsme se shodli v jedné z diskuzí, to, čím se zabýváme, je svébytná oblast odborných znalostí, která navíc těží z překvapivě bohaté kombinace vědních oborů, a jako taková si zaslouží respekt a odborné vzdělávání.

Ale ještě zpět k prezentacím a jejich tématům. Vendula se také rozepsala o obsahu prezentací workshopu a její reportáž si můžete přečíst na blogu Dativery.

Zatímco první ročník měl pevně stanoven společný námět, vloni a letos jsme zvolili jiný přístup, který dovolil účastníkům přijít s vlastními tématy. Díky tomu se jich sešla pestrá škála, která dovolila jejich rozvinutí do větší šíře. Jeden z účastníků, Milan z NetSuite/Oracle, komentoval témata následovně (volný překlad z komentáře v angličtině):

„Navštívil jsem workshop již v minulých letech a témata mi připadala lépe uplatnitelná v mojí práci (tehdy jsem pracoval pro RedHat). Letos jsem shledal témata super-zajímavými, ale méně relevantními pro mou současnou práci. Ale nemyslím si, že by to bylo nutně na škodu, protože profesnímu rozvoji prospívá i rozšiřování obzorů.“

Díky, Milane! Možná znovu zvážíme, zda na příštím ročníku opět nezkusit stanovit společný praktičtější námět, ale nevytratila by se tím kýžená pestrost?

A víte co? Teď se díky našemu nově založenému mailinglistu s námi můžete spojit i během roku. Pozdravte nás, požádejte o radu nebo nám něco poraďte vy sami, a případně nám pomozte začít plánovat další ročník!

Kategorie:

Pohled do zákulisí výroby prototypů Turris MOX

Út, 07/31/2018 - 10:10

Nový produkt řady routerů Turris se jmenuje MOX a je koncipován jako modulární systém. K základnímu CPU modulu MOX A bude možné připojit řadu dalších modulů, které uživateli umožní využívat pouze funkce, které potřebuje a nebude muset platit za periferie, které zatím nevyužije. A samozřejmě celý router v budoucnu rozšířit, když bude potřebovat. Moduly označené písmeny A až E se nyní nachází ve fázi prototypů, tedy oživování, testování jednotlivých funkcí, ale také ladění výroby a přípravě na tisícové výrobní série. A jak taková výroba prototypů vypadá, to se dozvíte v tomto článku.

Stejně jako druhá výrobní série routeru Turris Omnia, bude se i Turris MOX vyrábět v Lanškrouně, ve společnosti Morelli Electronics, s. r. o. Výroba elektrotechniky má na Lanškrounsku dlouholetou tradici, protože zde fungovala Tesla Lanškroun a nyní je zde několik jejích nástupců.
Do výroby jsme mohli nahlédnout ve chvíli, kdy se na lince vyráběly prototypy modulu MOX C – modul se čtyřmi metalickými gigabitovými konektory RJ 45 a gigabitovým switchem Marvell Topaz. Ještě před samotnou výrobou je nutné, na základě dat od hardwarových vývojářů, nechat vyrobit PCB – Printed Circuit Board, česky DPS – desky plošných spojů (dále desky) a nakoupit komponenty pro jejich osazení. Desky necháváme vyrábět v Číně, zejména kvůli rychlosti a ceně. Výroba a doručení do ČR trvá přibližně dva až tři týdny.

Komponenty, veškeré součástky, na prototypy pak nakupujeme na některém z on-line shopů, kde jsou okamžitě skladem. Pokud jde vše bez problémů a zásilka nezůstane na celnici, tak máme komponenty k dispozici za cca tři dny od objednání.

U sériové výroby je to však zcela něco jiného. Je rozdíl, když potřebujete stovky kondenzátorů nebo dva miliony. Ceny a především dodací lhůty jsou výrazně odlišné a v dnešní době bohužel značně nevyzpytatelné. Celý popis nákupu komponent by vydal na další článek, který zveřejníme třeba někdy příště.

Máme tedy vše potřebné k výrobě přichystané, naše prototypy jsou zařazeny do plánu výroby a můžeme vyrábět. Jako první se osazují SMD součástky, tedy součástky pro povrchovou montáž. Laicky řečeno jsou to ty malé součástky bez viditelných vývodů. Na MOXu C tedy téměř vše, kromě ethernetových konektorů.

Prvním krokem je nanesení pájecí pasty na desku. Desky se nedodávají samostatně, ale v tzv. panelech, ze kterých se až po osazení vylomí. Díky panelům lze PCB umístit na dopravníky jednotlivých strojů, přičemž každý krok je realizován na větším množství desek současně. V našem případě jsou v jednom panelu čtyři desky MOX C. Nanesení pájecí pasty se pak realizuje pomocí sítotisku. Sítotiskový stroj má navíc svoji vlastní inspekci, kterou kontroluje tloušťku, rovnoměrnost, množství a tvar nanesení pasty na jednotlivých bodech desky.

Sítotisk s připojeným vstupním podavačem

Detail vnitřku sítotisku

Desky umístěné ve vstupním podavači

Po vyjetí ze sítotisku je na všech ploškách pro SMD součástky nanesena bezolovnatá pájitelná pasta šedé barvy.

Pohled na přepravník na výstupu sítotisku

Do takto nanesené pájecí pasty se v dalším kroku umístí komponenty. Tento krok se provádí v osazovacím automatu. Komponenty jsou dodávány v několika typech balení, většinou však v tzv. reelech – kotoučích.

Komponenty na osazení prototypu MOX C

Tyto kotouče se umístí do podavače, tzv. feederu, který se nacvakne do osazovacího automatu. Ten pak na základě programu umístí jednotlivé komponenty na správné místo. Podklady pro tvorbu tohoto programu dodávají naši hardwaroví vývojáři.

Feeder s namotaným kotoučem kondenzátorů

Pohled do vnitřku osazovacího automatu, v pravém dolním rohu několik feederů

Osazovací automat má také možnost kontrolovat jednotlivé komponenty, zda jsou vhodné k osazení – spočítá počet vývodů na součástce a porovná ji s uloženým vzorem v programu. Lze tak odhalit případnou chybu v nabití feederu, nebo chybu součástky.

Kontrola součástky – zapnuté kamery

Kontrola součástky – vypnuté kamery, je možné vidět pipetu pro uchopení součástky

Obsluha osazovacího automatu není nic jednoduchého. Trvá zhruba dva měsíce, než se operátor naučí základní obsluhu, jeden rok pak než zvládne všechny procedury a programování stroje. A dále se učí celý život.
Daní za modulárnost MOXe je použití tzv. Straddle mount konektorů, kterými se jednotlivé moduly spojují. Jejich osazování a pájení není jednoduchou záležitostí a nelze je v našich podmínkách provádět automatizovaně. V našem případě jsou nasazovány ručně pomocí speciálního přípravku, který si v Morelli vyrobili.

Balení straddle mount konektorů

Ve výrobní lince, na které se osazovaly prototypy MOX C, jsou umístěny dva osazovací automaty za sebou. V jednom se osadí část součástek, ve druhém zbytek. Díky tomu lze zároveň osazovat dva panely, místo jednoho.

Osazená deska po výjezdu z prvního osazovacího automatu

Deska po kompletním osazení SMD součástkami

Pohled na linku, zleva sítotisk a dva osazovací automaty

Osazené desky se pak posílají skrz reflow pec, kde dojde k přetavení pájecí pasty a vodivému spojení jednotlivých vývodů součástek s deskou. V Morelli mají dvě reflow pece, bohužel ta větší, do které vede přepravník v námi používané lince, byla v době naší návštěvy mimo provoz. Mohli jsme si alespoň vyfotit její vnitřní část. Tato větší pec má příkon 45 kW při zahřívání, které trvá 20 minut.

Reflow pec, použitá při výrobě prototypů MOX C, v popředí stojan na feedery pro osazovací automaty

Otevřená reflow pec, na které poběží výroba Turris MOX

Výjezd desek z reflow pece

Po osazení a zapájení všech komponent na SMT linkách přichází na řadu kontrola na AOI – Automated Optic Inspection. Zde je u všech součástek prověřeno, zda jsou správně zapájeny a zda jsou na správných pozicích. Jak AOI funguje je nejlépe vidět z následujícího videa.

Posledním krokem u našich prototypů je osazení ethernetového konektoru. V sériové výrobě půjde o tzv. pájení vlnou, u malého počtu prototypů je výhodnější konektory osadit a zapájet ručně.

Osazené moduly jsou zabaleny do ESD bublinkové folie a odeslány do CZ.NIC do rukou našich vývojářů, kteří je oživí a začnou testovat jejich funkcionalitu. To už je zcela jiný příběh.

Kategorie: