Hosting

Přihlášení

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

Nový seriál #martyisdead ukazuje drsnou tvář Internetu

Út, 10/22/2019 - 09:10

Co vedlo dosud bezproblémového patnáctiletého Martina přezdívaného Marty k tomu, aby vzal do ruky mobil a natáčel se v situacích, ze kterých mrazí? A musel zemřít, aby jeho rodiče zjistili, jak úzkostné pocity a hrůzné chvíle před svou smrtí zažíval? Byl skutečně patologickou zrůdou nebo obětí systematického vydírání?

I na tyto otázky najdete odpovědi v novém seriálu #martyisdead, jehož první díl odvysílala internetová televize MALL.TV v neděli 20. října. Právě ve spolupráci s touto stanicí, sdružením CZ.NIC (projekt Bezpečně na netu) a společností Bionaut tento projekt vznikl.

Pro hraný seriál jsme se rozhodli proto, že po audiovizuálním formátu je ze škol největší poptávka a pro mladé uživatele je tato forma srozumitelnější. Novinka #martyisdead (trailer) se začala připravovat před více než rokem a předlohou jí byly skutečné případy. Seriál je unikátní i tím, že se tým scénáristů spojil s odborníky na rizikové chování na Internetu, psychology nebo policií, se kterými konzultoval jednotlivé scény. Thriller tak věrně zobrazuje postupy útočníků, které z dětí lákají intimní materiály nebo je vydírají. V návaznosti na seriál pak budou vznikat další doprovodná videa nebo metodiky, z nichž se rodiče, děti nebo učitelé dozvědí více informací k dané problematice. Například to, jak postupovat, pokud se s něčím podobným na Internetu setkáme.

Čísla, která nás motivovala přenést toto téma na obrazovky, jsou děsivá. Až osm procent dětí má zkušenost s vydíráním. Odhadem přes deset dětí ročně spáchá v České republice kvůli problémům na Internetu sebevraždu. I když o možných rizicích a predátorech děti vědí, jen dvě procenta z nich by se svěřilo svým rodičům. Tuto situaci se v rámci projektu Bezpečně na netu chystáme změnit a se seriálem se od ledna příštího roku chceme vypravit do několika desítek škol, kterým nabídneme projekci seriálu s následnou diskuzí s odborníky.

I když seriál odstartoval „až“ minulou neděli, podařilo se nám s ním na festivalu Serial Killer vyhrát cenu za nejlepší webseriál střední a východní Evropy. Věřím, že filmové zpracování tohoto těžkého tématu diváky zaujme a pomůže nám udělat Internet zase o něco bezpečnější.

O #martyisdead

Osmidílný thriller
Režie: Pavel Soukup
Scénář: Jaroslav T. Miška, Jan Stehlík
Kamera: Miloslav Holman
Hrají: Jakub Nemčok (Marty), Petra Bučková (Alena Biedermanová), Jan Grundman (Petr Biederman), Sára Korbelová (Kristýna), Matěj Havelka (Kryštof)

Kategorie:

Testování páteřních switchů pro privátní sál

Po, 10/14/2019 - 13:30

Po delší odmlce opět přicházím s pokračováním povídání o budování privátního sálu. Příprava na ostrý provoz nás docela zaměstnala, sál jsme úspěšně „rozsvítili“ a stěhování serverů začalo. Ale hezky popořadě.

Páteřní switche

Všechny páteřní metalické a optické kabely máme zavedené ve žlabech nad racky a tak přišly na řadu nové páteřní switche, jejich testování a oživování vůči jednotlivým access switchům.

Jako páteřní switche zde používáme dva Juniper QFX5200 obsahující 32x 10/25/40/50/100GbE QSFP+ portů, které jsou zapojené ve virtual chassis pomocí 100G DAC kabelů (dále VC porty). Jednotlivé access switche (v každém racku jsou samozřejmě dva) jsou s páteřními switchi propojeny dvěma MTP-MTP, MM, OM4 optickými patchordy, pomocí 100G QSFP28 SR transceiverů. Do páteřních switchů bude současně přímo připojeno produkční prostředí registru FRED, služby mojeID a DNS infrastruktury. To zajistíme pomocí tzv. break-out kabelů a ODF, kdy z každého portu na switchi osazeného 40G QSFP+ transceiverem „rozpleteme“ 4x 10Gbit uplinky k jednotlivým serverů.

Jak probíhalo testování páteřních switchů?

Obě QFXka jsme propojili port-channelem s LACP (dále ae interface), 2x10G s využitím 2x40G QSFP+ PLR, 2x LR rozplet 40G na 4x10G a 2x SFP+ LR se switchem Juniper EX3300. Na switchi jsme nastavili dvě testovací VLANy a dva access porty, jeden do každé z VLAN pro testování dostupnosti zařízení v případě upgrade SW, přepínání master/backup a změn v STP.

Pomocí dvou notebooků, dvou VLAN se dvěma různými subnety, zmíněného switche EX3300 s 2x 10G interfacy do QFX switchů a IRB interface na QFX jsme provedli níže uvedené testy a upgrade na poslední doporučenou verzi JUNOS. Na switchích bylo nastavené MSTP a porty k notebookům byly nastaveny jako EDGE. Při testech jsme posílali ping mezi oběma notebooky a zároveň na bránu (IRB interface v dané VLAN na QFX).

Ukázka z testování páteřních switchů

Upgrade SW jsme provedli nejdříve na backup instanci QFX, poté na master a to bez NSSU. Switch se během upgrade dvakrát restartoval, následně nastartoval do master stavu ve virtual chassis. V tu chvíli byly aktivní dva master switche a nefungoval mezi nimi VC porty. Switch EX3300 měl interface ae ve stavu UP, ale backup QFX switch viděl na své straně porty ve stavu DOWN, dokud nebyl proveden restart master instance. Reálně byl tedy dopad minimální, neboť měl switch EX3300 stále funkční uplink. Při restartu původního QFX master převzal ae interface původní QFX backup a vygenerovala se spanningtree TC. Edge porty to neovlivnilo, takže se vždy ztratily asi tři pingy v intervalu jedna sekunda.

Přepnutí master QFX instance tedy neznamenalo žádný ztracený ping, vypnutí celého master i backup switche také ne. Dále jsme zkoušeli postupné fyzické vytažení kabelů k virtual chassis portům, vždy bez výpadku. Samozřejmě jsme otestovali i kompletní rozpojení všech VC portů, což byl z pohledu dopadu na připojená zařízení nejhorší scénář. V tomto případě switch EX3300 udržel ae interface proti oběma switchům, reálně však ale fungoval jen ping v rámci daného subnetu. Oba QFX switche se tvářily jako master instance. A po opětovném zapojení jednoho z virtual chassis portů dokonce došlo k výpadku jednoho z ae portu na původním QFX backupu.

Vypnutí a současné zapnutí obou QFX switchů (odpojením napájení) znamenalo vyčkat, než nastartují do stavu, kdy si mezi sebou vybrali virtual chassis mastera. Ping následně fungoval v rámci VLAN i mezi nimi, ale QFX backup měl ještě po chvíli vypnuté porty. Dle očekávání odpojení jednoho z portů vedoucím do EX3300 neznamenalo žádný výpadek.

Dále jsme ještě testovali konfiguraci QFX a switchů Nexus řady 9300 s 48x 1/10/25G SFP+ a 6x 40/100G QSFP28 uplink porty. Jednolivé testování již jen v bodech:

  • interface s trunkem a nativní VLAN

  • interface s trunkem a MSTP

  • interface s Q-in-Q

  • L3 interface

  • mirroring port

  • dva různé STP regiony a Q-in-Q

Oživení privátního sálu

Páteřní switche a hlavní switch pro management (zatím jeden) jsme oproti původnímu umístění v racku posunuli těsně nad sebe a 2U vyvazovací panely umístili nad a pod switche. A to z prostého důvodu, že se lépe manipuluje s transceivery a patchordy. Z kabelovny máme do páteřní ODF přivedené čtyři 12vláknové kabely, ze kterých jsme zatím použili 2x dvě vlákna pro propoj mezi současnou lokalitou. Ty jsme propatchovali do obou páteřních switchů na 10Gbitu a po rozsvícení LINKu na obou portech jsme mohli začít stěhovat servery. Ale o tom až zase příště.

Ukázka vybavení páteřního racku

Kategorie:

Představujeme vám naši aplikaci První Psychická Pomoc

Po, 10/14/2019 - 11:33

V rámci Laboratoří CZ.NIC jsme byli osloveni pracovníky skupiny Sekce psychologie krizí, katastrof a traumatu při ČMPS (Českomoravská psychologická společnost) s žádostí o vytvoření mobilní aplikace První psychická pomoc (ve zkratce PPP), která by byla pomůckou nejen pro příslušníky bezpečnostních sborů, ale i pro lidi v neziskových organizacích. V aplikaci, která je již k dispozici na Google Play a App storu, najdou zájemci strukturovaný přístup pomoci ke stabilizaci člověka, který se dostal do náročné životní situace. První psychickou pomoc můžeme přirovnat k té zdravotní, jež slouží k zajištění základních životních funkcí člověka, než je předán do další odborné péče. V první psychické pomoci se snažíme člověka, který v danou chvíli není schopen uplatnit své mechanismy zvládání stresu, podpořit a redukovat jeho distres tak, aby situaci zvládl sám, případně věděl, na koho se může obrátit pro pomoc. Obsahem aplikace je kromě rad a postupů i seznam vhodných odkazů a kontaktů.

Psychologie krizí je obor, který se celosvětově rozvíjí, a to především v posledních dekádách. Tento obor vychází zejména z poznatků sociální, forenzní a klinické psychologie, psychologie zdraví, psychologie práce a organizace, interkulturní a vývojové psychologie apod. Jako i v celé řadě dalších případů i zde je podstatná mezioborová spolupráce s odborníky z mnoha dalších oblastí (urgentní medicína, bezpečnost, ICT technologie atd). Mezi zakládající členy Sekce psychologie krizí, katastrof a traumatu při ČMPS, která vznikla v roce 2010 v reakci na podnět stálého výboru pro psychologii krizí a katastrof EFPA, patří psychologové z oblastí bezpečnostních sborů, jednotek IZS, klinické praxe a akademické sféry. Cíle a poslání této sekce jsou především rozvoj oboru, spolupráce a propojení českých a zahraničních trendů, přenos informací odborníkům a osvěta laické veřejnosti (více informací zde).

Zástupci této Sekce psychologie krizí, katastrof a traumatu při ČMPS nám dodali veškeré odborné podklady potřebné pro vytvoření aplikace PPP. Naším úkolem potom bylo jejich zapracování a vytvoření grafické podoby aplikace. Návrh a výsledek můžete porovnat sami na obrázcích. Samotnou aplikaci potom najdete na Google Play nebo App storu.

Jsme moc rádi, že jsme se mohli podílet na tomto projektu a pomoci tak dobré věci. Ať je aplikace prospěšná a dobře slouží!

Kategorie:

Když méně (technologií) znamená více

Čt, 10/10/2019 - 14:20

Minulý měsíc jsem se na pozvání kolegů z polského Safer Internet Centra zúčastnila konference „Keeping Children and Young People Safe Online“. Jedno z hlavních témat této akce bylo, jak digitální svět spolu s IoT (Internet of Things) zasahuje do našeho života. Vyslechla jsem mnoho zajímavých příspěvků a diskuzí, což mě přimělo se nad tématem znovu zamyslet, shrnout získané poznatky a doplnit své osobní postřehy a doporučení.

Většina domácností se již běžně skládá z chytrých telefonů a televizí. Někteří lidé držící krok s vývojem moderních technologií používají i chytrou ledničku, topení či osvětlení. Mnozí rodiče malých dětí jdou však ještě dále a zřejmě díky fascinaci technologiemi pořizují on-line „chůvičky“, monitory dechu či dokonce chytré plínky.

Vedle četných bezpečnostních aspektů je však namístě se zamyslet i nad tím, kde se nachází ta správná hranice pro množství „smart“ přístrojů v naší domácnosti a do jaké míry nám ještě pomáhají a kdy už nám začínají spíše škodit. Ať už se jedná o zdravotní rizika, nebo stoupající míru závislosti na moderních technologiích někdy přecházející až v absenci používání „zdravého selského rozumu“.

Podle Elizabeth Milovidov, právničky a koučky v oblasti digitálního rodičovství, působí on-line hry na děti stejně návykově jako alkohol na dospělé. Dětem se hraním her mění chování a u některých se dokonce zvyšuje míra agrese a snižuje pozornost. Měli bychom si tedy každý zvážit, zda prostředí, ve kterém žijeme, není už náhodou přespříliš digitalizované a zda bychom si svůj vnitřní svět neměli chránit tím, že se budeme více věnovat off-line aktivitám.

Mnohem lépe než příkazy a zákazy můžeme své děti ovlivnit tím, že jim půjdeme příkladem a budeme si počínat tak, jak si přejeme, aby se chovaly ony.

K tomu nám pomůže nastavení rodinných pravidel, která mohou znít například takto:

  • nepoužíváme mobilní telefon u jídelního stolu,
  • v průběhu rozhovoru nenahlížíme do displeje mobilního telefonu,
  • v autě nepoužíváme mobilní telefon, pouze v případě nutnosti,
  • telefon nabíjíme pouze v předsíni, kam jej pokládáme i před spaním (případně určíme jinou místnost),
  • v noci mobilní telefon nepoužíváme, i když nemůžeme spát,
  • v sobotu či v neděli odpoledne máme digitální detox (samozřejmě dle aktuálních možností).

Na závěr bych chtěla zmínit už jen osobní postřeh. Po návratu z konference jsem ve svém pokoji zahlédla zárámovaný nápis „Home is where the wifi is“. Musím říci, že mi z toho bylo úzko, jak moc jsme nechali on-line svět vstoupit do toho reálného. Je však na každém z nás, jak se k tomu postavíme. Pokud zavedeme nové domácí zvyklosti, čímž omezíme používání digitálních technologií, prospějeme tak nejen svému zdraví, ale i duševní pohodě, která je v naší uspěchané společnosti obzvláště důležitá. Brzy jistě přijdeme na to, že nám mobilní telefon tolik nechybí a je nám někdy bez něj lépe.

Kategorie:

Další 10GE posílení .CZ anycastu

St, 10/09/2019 - 14:00

Dovolte mi další krátký díl našeho „nekonečného“ seriálu o zvyšování bezpečnosti provozu DNS pro .CZ doménu. Zřejmě proto, že jeho poslední zveřejněný díl znamenal upgrade v řádu 100 GE, a také proto, že naši administrátoři mají plné ruce práce se stěhováním do privátního sálu, tento vychází poněkud zpožděný a navíc z mé klávesnice.

Faktem ale je, že na naší mapě nodů DNS anycastu pro .CZ doménu přibyl 4. července další, tentokrát italský – umístěný konkrétně v milánském peeringovém centru – MIX. MIX patří mezi dvacítku nejvýznamnějších peeringových uzlů Evropy, navíc se nám zde podařilo domluvit dobré ekonomické podmínky hostování a připojení našich technologií. Po zkušenostech z předchozích vzdálenějších (hůře dostupných automobilem) instalací jsme volili postup, kdy jsme předkonfigurované servery poslali v předstihu přepravní službou a na jejich zapojení a zprovoznění jsme poté vyslali administrátora letecky. Předchozí varianta, kdy jsme tu druhou část domlouvali s pracovníky v peeringovém centru, se vší úctou ke snaze na obou stranách, selhávala a nevedla k rychlému dosažení cíle. Umístění serverů do připraveného racku a zapojení všech portů podle naší dokumentace je práce pro našeho technika na jedno odpoledne a výsledek si pak můžeme i zadokumentovat.

V MIXu jsme zprovoznili malý DNS stack sestávající z pětice serverů: jeden v roli management serveru, jeden v roli síťové brány a zbývající tři slouží k odbavování DNS provozu, přesně, jak je zobrazeno na tomto schématu.

Management server v pravidelných intervalech stahuje z master DNS serverů .CZ zónu a pak ji dále servíruje na jednotlivé DNS servery. Dále tu běží monitoring serverů a jejich služeb. Do tohoto serveru jsou zapojené out of band management porty zbývajících částí stacku. Na DNS servery jsme v rámci snahy o co největší diverzitu DNS anycastu zvolili NSD do role DNS daemona. Síťovou branou je samostatný server, který má oproti zbytku stacku síťová rozhraní navíc a běží na něm BGP daemon, který do zbytku světa oznamuje naše anycastové adresy. Jako routovacího daemona jsme použili FRRouring, což je živější fork známějšího projektu Quagga. Osvědčený BIRD tentokrát ustoupil požadavku na různorodost prostředí. Z pohledu operačního systému jsme zvolili osvědčenou klasiku – distribuci Debian Stretch s backportovaným jádrem a se zkompilovanými nejnovějšími ovladači pro síťové karty. Nejnovější ovladače používáme proto, že občas bývají problémy s kompatibilitou mezi verzemi firmware síťových karet a jejich podporou v distribučních ovladačích.

Po navázání peeringu s route servery v MIXu se nám s nimi zpočátku v pravidelných intervalech spojení rozpadala a přestávala fungovat IPv6 konektivita, což se nám poměrně rychle podařilo vyřešit pomocí zvětšení route cache. Samotné zprovoznění peeringu vyžaduje často změny v konfiguraci na některé z peeringových stran nebo nutnost kontaktování peeringových partnerů z důvodu jejich absence na peeringových uzlech, případně proto, že tam neoznamují všechny prefixy. Nebylo tomu jinak ani tentokrát a tato část tedy zabrala nějaký ten den navíc.

Po několika nezbytných testech jsme mohli začít oznamovat naše anycastové adresy do MIXu, přepnout celý stack do ostrého provozu a přidat tak další opěrný bod pro DNS provoz .CZ domény ve světě.

Kategorie:

MojeID a Účtenkovka

Út, 10/08/2019 - 14:20

V říjnu tomu budou dva roky, co ministerstvo financí spustilo hru Účtenkovka, v níž se každý měsíc losuje ze zaregistrovaných účtenek o více než 20 tisíc cen v hodnotě od 100 do 1 milionu korun. Nedílnou součástí této loterie je i naše služba mojeID, která přichází na řadu v momentě, kdy je soutěžící vylosován jako výherce peněžní odměny v hodnotě 100 tisíc, 200 tisíc, 300 tisíc a 1 milion korun.

Takto vysoké částky mohou být vyplaceny jen bezhotovostně. Proto je pro jejich předání nutné ověřit totožnosti výherce a to jednoduše prostřednictvím naší služby mojeID.

Abyste měli plně ověřený účet mojeID, musíte projít takzvanou validací. Tu provedete díky žádosti, kterou si generujete v sekci Nastavení ve správě účtu mojeID.

Validaci účtu je možné provést několika způsoby:

Přes datovou schránku. Žádost o validaci zašlete do datové schránky sdružení CZ.NIC, kterou naleznete pod ID h4axdn8.

Druhou možností je CzechPoint. V tomto případě je nutné žádost vytisknout a zajít s ní na nejbližší pobočku. Není třeba se obávat vyplňování, na každé žádosti je podrobný popis toho, co po každém pracovníkovi pobočky chtít. Validaci přes CzechPoint také podrobně popsal kolega Petr Peterka ve svém blogu; do něj přidal i názorné ukázky s podrobným návodem.

Díky spolupráci se sítí městských knihoven lze podat žádost o validaci i na některé z poboček. V tomto případě je třeba mít vytisknutý formulář a občanský průkaz. Žádost s údaji je pak zaslána na naše pracoviště.

Validovat účet mojeID lze i na pobočkách České pošty. Vytištěnou žádost si necháte úředně ověřit a originál žádosti zašlete na naši adresu CZ.NIC z.s.p.o., Milešovská 5, Praha 3, 130 00.

Poslední možností je přímo naše sdružení. Pokud máte cestu kolem, stavte se a my vám zde vytiskneme žádost a rovnou vás také ověříme (zvalidujeme). Potřebujete jen občanský průkaz.

Validaci účtu, tedy ověření vaší osoby jakožto „hráče“, je nutné provést a výhru si vyzvednout ve lhůtě 60 dnů od okamžiku, kdy se dozvíte, že jste něco vyhráli.

Veškeré informace o mojeID jsou k nalezení také na webu služby. Zde je uveden podrobný návod a zároveň odpovědi na nejčastější dotazy.

Pro úplnost uvedu, že pokud je výhra nižší než 20 tisíc korun (100 korun nebo 1 000 korun), je zasílána na účet, nebo si ji můžete vyzvednout osobně v sídle společnosti SAZKA (K Žižkovu 851, Praha 9). V tomto případě tedy není třeba provádět validaci účtu mojeID.

Věřím, že vám tento stručný návod pomohl zorientovat se v tom, v jakém vztahu je mojeID a portál uctenkovka.cz a také, jak se zachovat v případně výhry. Nyní už jen zbývá popřát hodně štěstí!

Kategorie:

Nové ODVR již odbavuje více než 20 procent provozu

Čt, 10/03/2019 - 11:37

Dnešní krátký článek bych rád pojal jako velké poděkování! Komu? Všem těm, kteří nejen že pomohli s otestováním nových Otevřených DNSSEC Validujících Resolverů po jejich spuštění v květnu tohoto roku, ale dále zkouší nově zavedenou podporu DNS-over-TLS a DNS-over-HTTPS a v neposlední řadě systematicky přecházejí na systémech ve své správě právě na nové ODVR.

Nové ODVR nabízí, kromě podpory výše zmíněných nejmodernějších protokolů, výkonově silnější infrastrukturu, zcela oddělenou od infrastruktury anycastu pro .CZ doménu. K oddělení jsme přistoupili zejména ve vazbě na pokračující zvyšování robustnosti DNS infrastruktury pro .CZ doménu. Nyní postupně směřujeme k vypnutí původního ODVR, zejména anycast části, která sdílí prostředky (hardware, IP adresy) s částí anycastu pro .CZ doménu. Proto jsme minulý týden zveřejnili výzvu k přechodu na nové ODVR a rozeslali ji i správcům TOP 30 sítí, ze kterých přichází největší provoz na původní ODVR. Jsme velice rádi, že ji celá řada vyslyšela (například Vodafone & UPC, Master Internet nebo VSHosting) a jak ukazuje graf rozložení požadavků mezi jednotlivé části ODVR infrastruktury, zvýšení provozu na novém ODVR anycastu za poslední týden výrazně vzrostlo, přesahuje již 20 procent.

Opravdu nás těší, že měníte nastavení svých zařízeních a pomáháte tak přibližovat moment, kdy původní ODVR platformu, zejména původní anycast část, vypneme. Právě u té původní anycast části předpokládáme, že by její podíl na celkovém odbavování provozu mohl poklesnout do řádu jednotek procent ještě do konce tohoto roku a to by tedy byl pro nás jednoznačný impuls pro její vypnutí.

Proto prosím znovu, zapomeňte na původní IP adresy ODVR, přejděte na nové! Zapomeňte prosím na: 217.31.204.130, 2001:1488:800:400::130 a 193.29.206.206, 2001:678:1::206, přejděte včas na: 193.17.47.1, 2001:148f:ffff::1 a 185.43.135.1, 2001:148f:fffe::1.

Kategorie:

Můj Den offline

Čt, 09/26/2019 - 09:00

Během seminářů, které pořádáme v projektu „Bezpečně na netu“ radíme, aby si děti i rodiče vyzkoušeli, jaké je to být třeba jen jeden jediný den bez mobilu. Přiznávám se, že sám jsem se k tomu zatím nikdy nedostal. Až do minulé soboty 21. září, na kterou připadl český Den offline.

Zprvu jsem si říkal, že pro odpojení od všudypřítomné „sítě sítí“ jsem si nevybral zrovna nejlepší den. Čekala mě totiž cesta z ICT Proposers Days v Helsinkách. A cestování člověka k používání mobilu svádí mnohem více, než kdyby byl např. jen doma na zahrádce. Nicméně jsem to vzal jako výzvu a nyní se rád podělím o své postřehy potvrzující, že na mnoho činností mobil skutečně nepotřebujeme. Byť to tak na první pohled nevypadá.

Vstávání

Ráno mi letí letadlo v půl desáté, což znamená vyrazit před půl osmou z hotelu. Budíček tedy nejpozději na sedmou. Mobil mám již od večera preventivně vypnutý, takže zvažuji, zda požádat recepci o buzení klasickým telefonem (ano, z domácností vymizely, ale na většině hotelových pokojů ještě jsou) nebo se spolehnout na svůj vnitřní budík. Nakonec vítězí druhá možnost, neboť moje svědomí bojuje s tím, že i starý dobrý telefon je vlastně telefon. Můj budík mě naštěstí nezklame a probouzím se před půl sedmou. První meta dosažena.

Cesta na letiště

Bez mučení přiznávám, že při používání MHD jsem si již zvykl na Google navigaci. Moji výhodou v Helsinkách je, že bydlím asi jen 5 minut chůze od stanice vlaku, který jede přímo na letiště. Večer si tak zjišťuji intervaly, abych si mohl cestu lépe naplánovat. Ve skutečnosti vlak jede jinak, než podle jízdního řádu, který mi den předtím našel Google, ale nevadí. Čas odjezdu svítí na tabuli a finským dráhám věřím. První okamžik, kdy zalituji toho, že nemohu použít mobil, přichází, když v protisměru přijíždí vlak, na kterém je obrázek krtečka s deštníkem. Myslím, že v Čechách by fotka sklidila úspěch.

Check-in

Na letiště přijíždím s plánovaným předstihem. Finské letiště Vantaa je již do vysoké míry digitalizované, takže celý check-in probíhá za využití samoobslužných automatů téměř bez lidské přítomnosti. Nejdříve si vytisknout palubenku (naštěstí funguje načtení občanky a systém nevyžaduje rezervační kód, který jsem si zapomněl přepsat z mobilu) i štítek na kufr. Pak si štítek sám nalepím, na dalším automatu zvážím a pošlu do útrob letiště. Při pohledu na mizející kufr přemýšlím o tom, co asi budou za pár let dělat slečny a mladí pánové, kteří sedí za check-inem v Praze i dalších městech. A neubráním se vzpomínkám na mizející pokladní, které jsou již v mnohých supermarketech nahrazovány samoobslužnými pokladnami. Zatímco tato povolání mizí, z nás se pomalu nevědomky stávají pokladní a pracovníci letištního odbavení.

Čekání a let

Absenci mobilu začínám trochu výrazněji pociťovat při téměř hodinovém čekání na letadlo. Chvíli mi zabere obcházení duty-free obchodů, pak čas místo surfování zaháním pozorováním lidí a přemýšlení nad tím, co je k dnešní cestě vedlo, případně, zda se jedná o pár či kolegy. V letadle mobil většinou nepoužívám a tak mi ani nechybí. Zato vedle mě sedící mladík stále dost znuděně kouká do svého přístroje a na mě až příliš často přepíná mezi čtením a hrami. Já se jen usmívám :-).

Zatím asi nejvíce absenci mobilu pociťuji po přistání, kdy je má rodina zvyklá obdržet zprávu, že jsem v pořádku přistál. Na to, že budu offline jsem je připravil a jak se nakonec ukázalo, SMSka typu „Právě jsem přistál v Praze“ jim nakonec ani moc nechyběla. Ruku na srdce – kdyby náhodou naše letadlo spadlo, tak už stejně žádnou SMSku nepošlu a ve zprávách to bude pravděpodobně dříve, než bychom měli přistát.

Cesta z letiště

Cesta z pražského letiště je pro mě bez mobilu přirozeně snazší, než na letiště v Helsinkách. Jediný moment, kdy trochu lituji absence mobilu a IDOSu je ve chvíli, kdy by se mi hodilo ověřit, zda je z Dejvické výhodnější jet tramvají či autobusem. Nakonec intuitivně volím autobus. I přes delší čekání nakonec jede dříve, než tramvaj, byť další přestup stíhám s vyplazeným jazykem. Ale ani zde by mi ale mobil nepomohl.

Odpoledne doma

Udělat si oběd z polotovaru naštěstí zvládám i bez internetové kuchařky. Odpoledne plánuji cestu za rodiči a tak řeším co s volnou hodinou a půl. Nebýt Dne offline, asi bych se vrhnul na promazávání e-mailů, zpracování fotek či bezcílné procházení Internetu. Místo toho si chvilku čtu časopisy a pak jdu na zahrádku udělat věci, které mi již delší dobu žena připomíná. Byť si nemyslím, že bych patřil mezi náruživé uživatele telefonu nebo sociálních sítí, v tento okamžik si uvědomuji, kolik času mi, byť často po malých kouskách, mobil bere a že i za půl hodiny se dá udělat spoustu práce. Ostatně, věděli jste, že průměrný Čech stráví na sociálních sítích 143 minut? Tj. téměř dvě a půl hodiny denně!

U rodičů

Na cestu k rodičům většinou mobil nepoužívám ani v jiné dny a tak mi to nedělá problém ani na Den offline. U našich pak přichází obdobný efekt, jako po obědě se zahrádkou. Místo chvilek na mobilu si více povídáme či si čtu.

Druhý den

Nevím, zda za to může absence modrého světla, změna prostředí či únava z cesty, ale ráno spím téměř do osmi, což se mi již delší dobu nepodařilo. Když pak dopoledne po více než 24 hodinách offline zapínám mobil, zjišťuji, že mi nikdo nevolal, neposlal žádnou SMSku ani vzkaz přes WhatsApp či Facebook a v pracovním e-mailu mám jen jednu zprávu. Zároveň si uvědomuji, že jsem předchozí den měl mnohem více příležitostí na přemýšlení a věnování se vlastním myšlenkám. Připomínám si rozhovor se socioložkou Karolínou Presovou na iHned, který jsme nedávno odemkli všem našim příznivcům. Při tom si uvědomuji, kolik dobrých nápadů jsem dříve dostal např. ve vlaku.

Den offline tak mohu všem jen doporučit. Věřte, že vám nic neuteče a naopak možná dostanete pár dobrých nápadů. Pokud příští rok do dne offline zapojíte nejen sebe, ale i svoji rodinu, možná vám ani nepřijde, že jste offline. Jak jsem si sám vyzkoušel, odpojit se jde i při cestování, kde jsme se postupně naučili na mobil v nejedné situaci spoléhat.

Kategorie:

Agentura ENISA školila v Akademii CZ.NIC bezpečáky

St, 09/18/2019 - 08:55

Jednou z hlavních úloh CSIRT.CZ je pomoc s řešením incidentů, a aby taková činnost mohla být maximálně funkční a profesionální, zasednou občas i členové CSIRTu „do lavic“. Letos Národní bezpečnostní tým CSIRT.CZ poprvé uspořádal ve spolupráci s evropskou agenturou ENISA dvě technická školení. Co se školilo? Kdo se školení účastnil?

Ve dnech 5. a 6. září proběhlo v prostorách Akademie CZ.NIC celodenní školení v anglickém jazyce pod vedením zahraničních lektorů, které bylo zaměřené na Mobile Threats & Incident Handling a Malware Analysis and Memory Forensics.

Jsme velmi rádi, že se v České republice dlouhodobě daří budovat kvalitní infrastrukturu bezpečnostních týmu CSIRT a proto, když jsme dostali nabídku agentury ENISA na bezplatné proškolení členů našeho týmu, rozhodli jsme se, že se o tuto příležitost podělíme a nabídneme kurz také všem bezpečnostním týmům, které jsou v ČR oficiálně konstituovány.

Mimo samotné vzdělávání členů CSIRT.CZ bylo cílem aplikovat myšlenku rozšíření bližší spolupráce CSIRTů v ČR (ale také i na Slovensku), která dosud probíhá především v technické rovině řešení incidentů apod. a formálního setkávání se na konferencích, dále do roviny edukační. Každé takovéto školení je totiž zároveň příležitostí vyměnit si vlastní zkušenosti s danou problematikou.

Co se týká samotného školení, zúčastnili se ho technicky zaměření členové z CSIRTů z celé republiky a také zástupce jednoho CSIRT týmu ze Slovenska.

Kurz Mobilní systémy a Incident handling byl zaměřen na:

  • práci s mobilními platformami,
  • seznámení se s nástroji používanými pro Mobile Incident Handling,
  • seznámení se s mobilními aplikacemi,
  • statickou analýzu malware na mobilních systémech.

V rámci druhého kurzu na téma Forenzní analýza operační paměti se účastníci obeznámili s:

  • aplikací klasifikačního schématu pro incidenty,
  • konceptem triage a základy incident handlingu,
  • způsoby získání obsahu operační paměti,
  • práci s nástrojem Volatility.

Školení ve spolupráci s ENISou se stalo prvním a rozhodně ne posledním v řadě kroků, kterými bychom rádi přispěli k výměně zkušeností a šíření znalostí mezi bezpečnostními týmy. Závěrem mi dovolte poděkovat kolegům z Akademie CZ.NIC za skvělou přípravu kurzu a agentuře ENISA za její ochotu bezplatně sdílet vlastní know-how.

Kategorie:

Mozilla řeší problémy IoT pomocí routeru Turris Omnia

Čt, 09/05/2019 - 13:20
IoT

Internet věcí nebo-li IoT je dnes hojně diskutované téma a nejen to, jako by se s těmito důmyslnými přístroji roztrhl pytel. Hlavně společnosti vyrábějící různá elektronická zařízení, jako jsou žárovky, elektrické vypínače, teploměry, váhy, kamerové systémy a tak podobně, se je snaží udělat chytřejší. Vždyť cokoli může být chytré – dokonce i záchod. Jediné, co je potřeba udělat, je něco změřit, nebo nahradit manuální vypínač za elektronický, a potom ho připojit k Bluetooth, ZigBee, ZWave nebo dokonce Wi-Fi a máte chytré zařízení, za které lidi zaplatí nemalý peníz. Má to ale pár háčků (kromě toho, že ne všechna tato zařízení dávají smysl).

Společnosti, které dnes vyrábějí inteligentní zařízení, obvykle vědí, jak udělat skvělý hardware. Mají s tím dlouhodobé zkušenosti a jsou oprávněně hrdé na to, co dělají. Ale co software? To je pro ně typicky velká neznámá. Ale přece to nemůže být tak těžké, ne? U někoho se najde čip, na kterém je Wi-Fi a nějak se připojí ke kusu hardwaru. Někdo jiný má zase na Internetu hezkou webovou službu, která dělá zhruba to, co je potřeba. Spojí se to tedy dohromady a je tu chytré zařízení – problém se softwarem je vyřešen, vrátíme se k té důležité části – hardwaru.

Problém tohoto přístupu je ale v tom, že softwarový průmysl je tady už také dlouho. Naučili jsme se, že nesmíme podceňovat bezpečnost. To, co bylo považováno za bezpečné před deseti lety, je dnes vysoce zranitelné. Udržování aktualizovaného softwaru je pro zabezpečení velmi důležité. Soukromí je také něco, co dnes vyžadují i běžní uživatelé, takže nad odesíláním osobních údajů službám třetích stran se leckdo pozastaví.

Mozilla mění svět IoT

Jaký je tedy pohled na současný stav světa IoT? Dost často nezabezpečený chaos, ve kterém zařízení nemohou navzájem komunikovat jinak než přes několik cloudů. Společnost Mozilla se rozhodla tomu pomoci a napravit tuhle zmatenou situaci. Problémy s IoT, které jsem uvedl v předchozí části, jsou dány nekompatibilitou – absencí standardizovaných API a nedostatečnou důvěryhodností, kdy jsou osobní údaje nebezpečným způsobem odesílány bůhví kam.

Ve snaze o řešení těchto problémů přišla Mozilla s Web Thing API. Abstrakční vrstvou pokrývající různá zařízení IoT. Pokud by se spojily jednotlivé brány/zařízení/cloudy různých majitelů, mohla by být interakce mezi zařízeními napříč dodavateli mnohem jednodušší. Zároveň by to otevřelo prostor pro to, aby vznikly další služby využívající toto API – třeba aplikace pro správu chytré domácnosti a podobně. Pomohlo by to také dalšímu problému – bezpečnosti. Mohly by vzniknout bezpečné služby a možná dokonce i takové, které poběží u vás doma a budou bezpečně uchovávat data lokálně. Máte-li software, který ovládá všechna data z vašeho chytrého domova umístěný fyzicky doma v nějakém zabezpečeném zařízení, příležitostí na vás útočit je mnohem méně. Bez automatických aktualizací jsou ale jednotlivá zařízení stále lokálně zranitelná, nicméně útočník by vás musel fyzicky navštívit u vás doma, aby mohl útok vůbec vyzkoušet.

Mozilla šla ve své snaze ještě dále. Vytvořila také aplikaci, která přijímá data z vašich IoT zařízení, následně je shromáždí a zobrazí. Plus vám umožní kontrolu samotných zařízení. Lze si je hezky zobrazit na půdorysu a můžete si vytvořit bezpečný tunel pro přístup k vlastní bráně z celého světa. Je to uživatelsky přívětivé, a to přímo u vás doma.

Na scénu vstupuje Turris

Jakou roli tedy v tomto úsilí hraje Turris? Mozilla udělala spoustu zajímavých a užitečných věcí. Ale koneckonců software musí někde běžet. Turris Omnia je router, který má automatické aktualizace a i jiná bezpečnostní opatření, jako je distribuovaný adaptivní firewall a honeypoty. Je také zcela otevřený. O výkonu ani nemluvě. Hezky se k Mozille hodí nejen svojí filozofií, ale také z praktického hlediska. Pro Turris je velice snadné vytvořit vlastní software a i obecně si router přizpůsobit.

A přesně to udělala Mozilla. Vzali náš operační systém, začlenili do něj svůj software a vytvořili vlastní obraz se všemi již integrovanými funkcemi. To je jedna z velkých výhod open source – umožňuje lidem řešit problémy, které jsou důležité pro ně.

Samozřejmě preferujeme spolupráci, při které balík může být hezky integrován do distribuce a UI a v míru koexistovat s ostatními věcmi, které dodáváme. To je něco, na čem pracujeme s Mozillou, ale nástroje, které poskytujeme, jim umožňují velmi snadno vytvořit vlastní vydání s využitím toho nejnovějšího a nejlepšího z obou projektů.

Jedno varování na závěr. I když to je snadné, oficiálně na našem zařízení nepodporujeme jiné OS, jelikož u softwaru jiných výrobců nemůžeme zaručit shodu se všemi předpisy a také se může stát, že si nainstalujete něco, co bude silně opotřebovávat vnitřní flash paměť (jako databáze a jiné aplikace náročné na diskové operace). Takže se dobře zamyslete nad možnými důsledky než si nainstalujete jiný software.

Kategorie:

Příprava síťové infrastruktury a základní osazení racku

St, 08/28/2019 - 06:50

Po všech přípravách „na sucho“ začínáme skutečně pracovat na síťové infrastruktuře privátního sálu aneb dokud se netahají kabely není to žádná práce! Minulý týden jsme se tedy pořádně protáhli a vyzkoušeli si práci na štaflích, když jsme do předem připravených žlabů pečlivě zaváděli metalické a optické kabely a také jsme do racků namontovali předem připravené switche a vyvazovací panely.

Pro jednotlivé typy kabeláže máme vyčleněny dva kovové žlaby nad racky výhradně pro IT technologie. Horní žlab je určený pro metaliku, spodní pak pro optiku, kde předpokládáme větší množství kabelů. Sem také ústí vlákna z centrálního propojovacího místa budovy datacentra. Abychom zabránili nežádoucímu ostrému zalomení optických kabelů, máme nad každým rackem umístěné tzv. kabelové svody, viz obrázek níže.

Kabelový svod z drátěného žlabu nad racky

Metalická kabeláž

Metalické kabely Cat6 používáme převážně pro oddělenou managementovou síť, tj. pro IPMI/iDrac/iLo rozhraní serverů, dále k připojení konzolových serverů, managementů switchů a pro uplinky serverů, které nejsou osazeny 10Gbit síťovou kartou a čekají na svojí pravidelnou obměnu. Jednotlivé patchcordy rozlišujeme barevně dle použití:

  • šedá: páteřní propojení managementové sítě a nebo první uplink k serverům,
  • modrá: druhý uplink k serverům,
  • červená: připojení IPMI/iDrac/iLo rozhraní serverů,
  • zelená: připojení konzolových serverů, patchordy jsou zapojené jako rollover,
  • bílá: připojení managementů switchů.

K dnešku máme zavedeno 18 páteřních metalických kabelů, v délkách 5 až 16 metrů, do sedmi racků a ke čtyřem konzolovým serverům. Ke každému management switchi v racku vedou dva patchordy. Jeden je zapojený, druhý připraven pro případné pozdější použití. Tyto kabely končí v páteřním racku, kde je umístěn (zatím) jeden hlavní MGMT switch. Jakmile provedeme všechny plánované migrace a obměny zařízení, doplníme jej o druhý kus kvůli redundanci.

Optická kabeláž

V optické infrastruktuře, kterou budeme používat výhradně pro připojení switchů a serverů, jsme zatím položili 6 páteřních optických kabelů MTP-MTP, MM, OM4 v délkách 12 až 14 metrů do třech racků, kterými začínáme 1. fázi migrace. Do každému racku vedou dva tyto kabely, abychom zajistili redundanci access switchů a jsou stejně jako metalické kabeláže ukončeny v páteřním racku.

Dále jsme propojili tzv. breakout kabely MTP-4xLC(D), v délkách 3 až 7 metrů, páteřní rack s 1. velkým DNS stackem (10 kabelů) a s produkcí FRED/mojeID (8 kabelů).

Vedení optické infrastruktury v drátěném žlabu nad racky

Zakončení optické a metalické infrastruktury v páteřním racku

Optické breakout kabely MTP-4xLC(D)

Základní osazení racku

Ve většině racků jsou umístěny dva access switche, jeden management switch a horizontální vývazovací panely. Vybrané racky mají navíc zepředu umístěn také konzolový server.

Konkrétní základní osazení racku v jednotlivých U vypadá následovně:

Pozice U Zařízení 52-49 volno 48 back: management switch 46-47 back: 2U vyvazovací panel (47) (front: konzolový server) 45 back: access switch 44-43 back: 2U vyvazovací panel 42 back: access switch 41-40 back: 2U vyvazovací panel

Základní osazení síťových prvků v racku

První výjimkou jiného rozložení je páteřní rack, ve kde se nacházejí páteřní management a access switche, ODF (mimo jiné s vlákny vedoucí do centrálního propojovacího místa budovy datacentra) a router.

Pozice U Zařízení 52-51 volno 50 back: ODF … … 32-28 front: 5U router 27 back: páteřní switch 26-25 back: 2U vyvazovací panel 24 back: páteřní switch 23-22 back: 2U vyvazovací panel 21 back: páteřní management switch 20 front: konzolový server 20-19 back: 2U vyvazovací panel 18-1 volno

Další výjimkou je rack s prvním velkým DNS stackem a rack s produkcí FRED/mojeID. Oba mají na pozici 50U ODF a na pozici 48U MGMT switch/e spolu s horizontálními vyvazovacími panely. Oba racky však neobsahují access switche. Uplinky k serverům budou realizovány LC-LC patchordy mezi jednotlivými servery a ODF. ODF je pak připojeno výše uvedenými breakout kabely k páteřním switchům.

Servery začínáme umisťovat odspodu nahoru, přibližně do pozice 32U. Je to z důvodu, že osazené dvojice PDU v každém racku začínají přibližně na pozici 40 a končí u země.

Kategorie:

Omalovánky ke knize ON-LINE ZOO

Út, 08/20/2019 - 10:16

Nový školní rok se již nezadržitelně blíží a spolu s ním další besedy s dětmi nad knihou ON-LINE ZOO, které pořádáme na základních školách a v knihovnách. Jelikož děti mladšího školního věku ještě velmi rády kreslí a vymalovávají obrázky, připravili jsme pro ně omalovánky ve stylu této knihy.

Jak jsem již psala ve svém lednovém blogpostu, na besedách si s dětmi povídáme o tom, k čemu nám slouží Internet, ale i jaká nebezpečí přináší. Děti si příběhy z knihy oblíbily a rády o nich diskutují. Mnozí z nich již mají bohaté zkušenosti s on-line prostředím a často nám vyprávějí, co samy zažily a z čeho mají obavy.

Abychom jim po besedě připomněli stěžejní příběhy z knihy, budeme jim rozdávat omalovánky, kde si postupně vybarví všechna zvířátka, o kterých kniha pojednává. Budou si moci vybarvit opičáka, který se stává závislým na mobilu. Dále smutného medvídka pandu, jemuž se hyeny na Internetu smějí, že je moc tlustý. U obrázku s antilopami se rozpomenou, že by neměly důvěřovat všem, kdo je na Internetu osloví a chce se stát jejich virtuálním kamarádem. Zbrklá žirafa jim připomene, jak je důležité číst veškeré informace, které se jim objeví na displeji. A úsměvný obrázek tučňáka v plavkách je poučí, že není dobré pořizovat fotky ve spodním prádle.

Věříme, že se dětem budou off-line omalovánky líbit a budou jim připomínat, že Internet je dobrý pomocník, ale zlý pán.

Kategorie:

Zabydlujeme se v privátním sále

Čt, 08/15/2019 - 09:37

V předcházejících dílech seriálu o budování privátního datového sálu popisoval kolega Zdeněk Brůna stavební práce na sále a oživování technologií pro jeho provoz. V tomto a dalších dílech budu informovat o jednotlivých krocích pro přípravu síťové infrastruktury a migraci technologií.

Klíčový systém

Pro přístup do racků používáme klíčový systém (tzv. keybox), umístěný hned za dveřmi v privátním sále. Konkrétně se jedná o model FAB TRAKA 21, kde číslovka udává maximální kapacitu klíčů. Tento klíčový kabinet umožňuje, mimo jiné, zadat až tisíc uživatelů, přiřadit jim oprávnění k vybraným klíčům a samozřejmě logovat veškeré události. To nám pomůže ještě lépe řídit přístupy do jednotlivých částí infrastruktury. Uživatel s oprávněním administrátora si pak může zpětně dohledat, kdo si v jakém čase vypůjčil jaký klíč a má možnost všechny logy exportovat na flash disk (proto ten USB konektor umístěný pod displejem). Každý uživatel má samozřejmě přidělen vlastní PIN kód, po jehož zadání se keybox otevře a klíče, které má přidělené, se vybarví zeleně. Zvolením čísla na displeji si může klíč odebrat. Keybox zná správnou pozici klíčů, takže nemůže dojít k záměně pozic v případě, že si uživatel odebere klíčů více.

Příprava síťové infrastruktury

Abychom mohli oživit síť v privátním sále, nechali jsme si při realizaci natáhnout 4x dvanáctitivláknový kabel MTP-MTP / 12F 9/125 G.657.A2 3,0mm z kabelovny do naší páteřní ODF, která je opět v provedení IANOS 1U EDR. Všechna vlákna jsou zakončena ve dvou přechodových modulech IANOS Base12 MTP-LC, double size, SM. Oba moduly jsou osazeny dvěma MTP konektory na vstupu a dvanácti LC duplex konektory na výstupu. Do těchto vláken budeme následně přepojovat všechny naše propoje.

Současně jsme požadovali propojení privátního sálu s naší stávající infrastrukturou (také přes kabelovnu) a to 2x dvěma vlákny. Tento propoj budeme používat pro migraci technologií.

Při budování síťové infrastruktury zavedeme dvě novinky. Tou první je, že budeme co nejvíce serverů připojovat výhradně 10Gbit uplinkem, samozřejmě zapojeným jako port-channel. Při nákupech nových serverů s tímto již dlouhodobě počítáme a máme k tomu do nového sálu připravené nové switche s rozhraním SFP/SFP+/QSFP28. Samozřejmě některé servery budou i nadále připojeny pouze 1Gbit uplinkem a to do chvíle, než projdou pravidelnou obměnou.

Druhou novinkou je, že zcela oddělíme managementovou síť, tj. síť pro IPMI/iDrac/iLO rozhraní serverů, VME rozhraní switchů a současně také pro konzolové servery. Nebudeme tedy využívat „drahé“ 10Gbit porty access switchů a celá tato síť bude zapojena výhradně do „obyčejných“ 1Gbit switchů s rozhraním RJ45, které právě v rámci obnov nahrazujeme. Oddělujeme tím vlastně tyto dvě sítě nejen na úrovni VLAN, ale skutečně i fyzicky.

Co nás čeká a další plány?

Co by to bylo za plánování bez Ganttova diagramu, že? Souvislostí a vazeb mezi jednotlivými úkoly je tolik, že by to při tak rozsáhlém projektu nebylo možné uřídit. Jednotlivé úkoly máme rozdělené podle racků, které budeme stěhovat. V každém z nich se začíná se síťovou infrastrukturou, tj. propojení metalikou a optikou s páteřním rackem, dále s konfigurací a aktualizací access a management switchů. Poté přichází na řadu příprava stěhování serverů, tj. dohodnutí odstávky nebo switchover do jiné lokality, aktualizace firmware všech HW komponent serverů a nakonec fyzické přemístění. Tomu samozřejmě předchází realizace páteřního racku (páteřní a mgmt switche, v průběhu také router a ODF), do kterého jsou připojena všechna vlákna z kabelovny.

V současné době máme naplánovanou přibližně polovinu celého rozsahu, což znamená splnit přibližně 313 úkolů (většina z nich se samozřejmě týká serverů). Zatím jsme jich uzavřeli přibližně 50, protože úkoly týkající se realizace síťové infrastruktury patří mezi ty časově nejnáročnější. Ale jakmile začneme ve velkém stěhovat servery, číslo splněných úkolů bude rychle stoupat.

Na závěr malá ukázka Ganttova diagramu

Kategorie:

Projekt STOPonline.cz: analýza druhého čtvrtletí 2019

Čt, 08/08/2019 - 11:29

Ve druhém čtvrtletí letošního roku jsme na lince STOPonline.cz přijali 874 hlášení nebo lépe řečeno incidentů. U každého incidentu nejprve posuzujeme jeho závažnost a podle toho s ním pak nadále pracujeme. Incidenty se dají rozdělit na několik různých typů.

Typy incidentů

Nejčastěji nám uživatelé Internetu nahlašují webové stránky, ze kterých byl jejich obsah již odstraněn, případně se na nich žádný nelegální obsah nenachází. Takový incident označujeme jako Jiný obsah (Other content). Ve druhém čtvrtletí 2019 jich na linku STOPonline.cz přišlo 494.

Další tentokrát méně početnou skupinou, která nespadá mezi kompetence horké linky, jsou incidenty, jež nazýváme Mimo oblast hotline  (Outside hotline remit). Jedná se převážně o hlášení týkající se falešných e-shopů a od dubna do června 2019 jsme jich zaznamenali 63.

K nejzávažnějším materiálům, které k nám přicházejí, patří hlášení související s dětskou pornografií (Child porn). Jedná se o druh pornografie (znázornění lidského těla a jeho sexuálního chování, jehož účelem je vzbudit sexuální pud), v níž jsou zobrazeny osoby mladší 18ti let jako sexuální aktéři nebo objekty. Za dětskou pornografii tedy považujeme fotografický, filmový, počítačový či elektronický (čitelný jen strojově) materiál, který zobrazuje odhalenou osobu mladší 18ti let, jíž jsou vidět genitálie a je součástí sexuálních praktik (vaginální či anální soulož, masturbace, uspokojování nad přítomnou nezletilou osobou apod.). Většina ze 168 případů dětské pornografie nahlášených ve druhém čtvrtletí se nacházela mimo území České republiky – tato hlášení putují do mezinárodního systému ICCAM, který je veden ve spolupráci s INTERPOLem. Případy z České republiky pak díky uzavřenému memorandu s Národní centrálou proti organizovanému zločinu postupujeme přímo Policii České republiky.

Podobně jako s dětskou pornografií nakládáme i s incidenty týkající se dětské erotiky (Child erotica). Tímto termínem pojmenováváme materiál, jenž zobrazuje nezletilé osoby v sexuálně vyzývavých polohách, které jsou pořízené za účelem podnícení sexuální touhy, avšak oproti dětské pornografii jsou zachycené osoby částečně zahalené – v plavkách nebo spodním prádle. Materiál přitom může simulovat sexuální akt či různé sexuální hrátky a praktiky. Jako Child erotica bylo označeno 31 hlášení.

Na linku STOPonline.cz bylo nahlášeno také 36 případů dětského nudismu (Child nudism). Dětským nudismem označujeme takové fotografie či videa, které zachycují odhalené nezletilé osoby v polohách, které nejsou primárně sexuálně vyzývavé. Nejčastěji je pořizují samotní rodinní příslušníci na dovolených či na výletech, přičemž následně mohou být určitou skupinou osob zneužity za účelem uspokojování. Na takový nevhodný obsah pak upozorňujeme poskytovatele webových stránek.

Se sexuálním zneužíváním dětí a mladistvých souvisí rovněž tzv. Child grooming. Jedná se o psychickou manipulaci nezletilého prostřednictvím internetových komunikačních prostředků (Facebook, Instagram, Snapchat, Skype, chatové místnosti, e-mail, atd.). Agresor, který se mnohdy vydává za někoho jiného, se přitom snaží s obětí navázat důvěrný vztah, aby ji posléze vylákal k osobnímu setkání, jehož cílem je sexuální zneužití. Ve druhém čtvrtletí byly na linku STOPonline.cz nahlášeny tři případy child groomingu, které byly předány policii.

Poslední typ incidentu, který se k nám v uplynulém čtvrtletí dostal, se týká rasizmu (Racism); jednalo se o jeden případ. S ním se můžeme setkat například na sociálních sítích, v chatovacích místnostech, na různých fórech či v komentářích pod články. Vyznačuje se slovním napadáním, vulgarismy, zesměšňováním, zastrašováním a vyhrožováním jednotlivci, či skupině osob s biologicky odlišnou „rasou“. Toto hlášení jsme opět postoupili příslušníkům policie.

V případě podezření na některý z výše uvedených typů nezákonného obsahu na Internetu, tedy například šíření dětské pornografie, zneužívání dětí, nepatřičnou dětskou nahotu nebo kybergrooming, nám zasílejte upozornění na https://www.stoponline.cz.

Kategorie:

Jak odolat internetovým výzvám?

St, 07/31/2019 - 13:15

Vylít na sebe kýbl ledové vody, sníst co nejvíce skořice, tančit v otevřených dveřích jedoucího auta nebo spolknout tabletu do myčky na nádobí. To jsou jen příklady některých výzev (tzv. challanges), které se pravidelně objevují na sociálních sítích. Některé z nich jsou pozitivní, jiné mohou být vtipné, mnoho z nich je však nebezpečných a to až smrtelně.

Své by o tom mohli vyprávět Geert a Anita Reyndersovi z Nizozemí. Ve výzvě „Chocking game“, při které se děti záměrně dusí, aby přerušily přívod krve do mozku, přišli o svého 16letého syna Tima. Nyní se snaží proti nebezpečným výzvám bojovat.

Tim, Anita, Anna a Geert Reynders

Děti a mladí lidé dělali bláznivé kousky a vzájemně se hecovali od nepaměti. Internet a sociální sítě však spolu s mobilními telefony umožňují zdokumentování těchto často bláznivých nápadů, jejich šíření a oslovení širokého publika. Často i těch, kteří by, nebýt Internetu, podobný nápad nikdy nedostali. Teď se však snaží sami sobě i svým kamarádům dokázat, že oni danou výzvu přeci zvládnou. A přitom nasbírat pěknou řádku lajků.

Podle výzkumu komunikační agentury Jong & Je Wil Wat se mladí lidé do on-line výzev nejčastěji zapojují kvůli napětí, zvědavosti, získání a udržení kamarádů či zvyšování popularity. Byť to tak na první pohled nemusí vypadat, zvládnutí mnoha výzev je jednoduché – nevyžaduje žádné zvláštní dovednosti ani speciální vybavení. Tyto faktory pak často podle výzkumu Jong & Je Wil Wat vedou k tomu, že nebezpečí je ve výzvách podceňováno, což bývá umocněno i shlédnutými videi, jejichž aktérům se nic nestalo. Velkou roli hraje rovněž vzájemný tlak a snaha napodobit své vzory, ať již se jedná o influencery nebo starší kamarády.

Podle Geerta a Anity Reyndersových může být pro mnoho dospívajících opravdu těžké říci ne svým přátelům, zejména, když se všichni výzvy zúčastní. Některé děti si myslí, že daný úkol musí udělat, aby se začlenili do skupiny přátel. Další se pak mohou cítit vyděšeně a osamoceně. Je však důležité, aby si uvědomily, že není v pořádku, aby je někdo do něčeho nutil. Na základě zkušeností, které nizozemští manželé shromáždili ve své nadaci, dnes mladým lidem radí:

  • Řekněte sebejistě NE. Říci ne svým přátelům však často vyžaduje silnou vůli. Pokud si budete trénovat říkat ne, bude pro vás snazší (kamarády/návrh kamarádů) odmítnout. Zároveň se díky tomu vyhnete situacím, ve kterých se necítíte dobře, bezpečně nebo pohodlně. Zkuste se podívat i na své kamarády, kteří jsou zvyklí říkat ne a umí se vypořádat s tlakem vrstevníků.
  • Nesuďte své kamarády jen podle toho, že se do některé výzvy nezapojí a nenaplní tak vaše očekávání. Naopak. Snažte se respektovat jejich rozhodnutí.
  • Pokud se vám aktivity, které podnikají vaši kamarádi, nebudou líbit nebo byste se při nich necítili dobře, zkuste navrhnout něco jiného.

Na on-line výzvy a s nimi spojená rizika se zaměřujeme v projektu „Bezpečně na netu“. Jako první vlaštovku vypouštíme tento týden na náš Instagram, Facebook a Youtube krátké spoty, které se v sobě snaží kombinovat humor s vážným poselstvím.

To ostatně v rámci svého průzkumu mj. doporučuje i agentura Jong & Je Wil Wat, podle které mezi mladými lidmi nefungují zákazy. Naopak funguje varování o nebezpečích a diskuze o tom, jak některé výzvy fungují. Našimi spoty se zároveň snažíme zvýšit povědomí o on-line výzvách a motivovat rodiče a učitele, aby si k tomuto tématu zjistili více informací. V rámci projektu „Bezpečně na netu“ se on-line výzvám chceme i nadále věnovat.

Kategorie:

Kdo je za dveřmi? Jen my…

Po, 07/29/2019 - 13:00

Jak jsem psal ve svém prvním příspěvku o budování privátního sálu, realizací tohoto projektu získáme zejména vyšší kapacitu v datovém centru a také vyšší fyzickou bezpečnost. Jak je to tedy s tou bezpečností?

Na bezpečnost je ve všech objektech provozovatele datového centra kladen velký důraz, však je to také budova zajišťující vysílání televize a rozhlasu. Společnými bezpečnostními rysy pro všechny sály v datovém centru jsou:

• napojení na centrální bezpečnostní systém,
• nepřetržité monitorování všech prostor i okolí objektu,
• dohled bezpečnostní agentury v režimu 24/7,
• přístup je pouze přes systém čipových karet v kombinaci se čtečkami biometrických údajů,
• záznamy o přístupech jsou archivovány.

Dosud jsme svoje technologie měli umístěny v racích na tzv. sdíleném sále, kam má přístup pro nás neznámé, ale každopádně větší množství cizích subjektů. Proto jsme alespoň umístili racky do klece, která sice snižuje využití prostoru a tedy pro zákazníka zdražuje službu, ale do značné míry omezuje fyzický přístup k našim technologiím. Pro potenciálního útočníka ale není příliš obtížné tuto fyzickou bariéru překonat a pokud vezmeme v potaz, že nejmenší pronajímatelnou jednotkou v datacentru je „čtvrtrack za pár korun měsíčně“, není riziko ohrožení naší infrastruktury úplně zanedbatelné. Proto, když jsme začali narážet na kapacitní limity současného řešení, jsme přistoupili kromě upgradu kapacit také ke zvýšení fyzické bezpečnosti.

Tím hlavním prvkem je fakt, že jsou naše technologie doslova „schovány“ za dveřmi s požárnostní a bezpečnostní odolností třídy BT3 a nikdo, kromě našich autorizovaných osob, k nim nemá přístup. Samozřejmě také pracovníci datacentra, ale pouze po předchozím ohlášení. Přístup na sál je chráněn dvoufaktorovou autentizací (RFID + otisk prstu). Vchod i vnitřní prostory jsou sledovány kamerami (se záznamem na 30 dní) a detektory pohybu. Každý rack má svůj unikátní klíč a klíče jsou na sále umístěny ve speciálním klíčovém trezoru se záznamem a uchováváním veškerých aktivit. Zvolený klíčový trezor umožňuje definovat oprávnění k použití jednotlivých klíčů pro různé role našich pracovníků.

Provoz .CZ domény a dalších námi provozovaných služeb je tak zase nějaký kousek bezpečnější.

Kategorie:

Bez šťávy by to nejelo

Čt, 07/18/2019 - 09:23

V předcházejícím dílu seriálu o budování našeho privátního datového sálu jsem psal o chlazení. Dnes bych se zaměřil na další klíčový prvek datových center a tím je napájení. Je to část, která je (společně s budovou) nejvíce technologicky sdílená s provozovatelem datového centra. Ne, opravdu nebudeme mít pro svůj privátní sál svoje tři VN přívody od distributorů elektrické energie nebo svoje trafostanice. Dokonce ani nebudeme mít svoje dieselové agregáty nebo UPS pro zajištění nepřetržitých dodávek elektrické energie při výpadku dodávek od distributora. Ekonomicky to prostě pro naše potřeby nedává smysl a tyto části sdílíme s provozovatelem datového centra. Ano, stávající UPS jednotky jsou již doplněny o dva 50 kW moduly (jeden pro napájecí větev A, druhý pro „Béčko“) a do nádrží dieselů provozovatel DC dolil „pár“ litrů nafty navíc, aby i při rostoucí zátěži dokázal garantovat 30 hodin kontinuálního provozu bez dodávek externích paliva (v případě výpadku napájení DC), ale to je vše, co bylo třeba udělat ve stávající energetické soustavě provozovatele datového centra. Ne, ani svoji jadernou elektrárnu si opravdu nestavíme :).

UPS jednotka

Baterie

Co máme logicky svoje, jsou dva nezávislé přívody napájení sálu, dva elektrické rozvaděče v sále pro napájení IT, tj. našich technologií v racích, a dva elektrické rozvaděče pro napájení non-IT (klimatizace, zvlhčovače, monitoring, atp.) Čistě pro nás je určeno i devět párů třífázových PDU (power distribution unit) pro zajištění dodávek elektrické energie k našim technologiím v racích. Aby dával koncept dvou nezávislých napájecích větví smysl, v racích budeme používat výhradně dvouzdrojové technologie. Maximální příkon, který každé PDU k racku dokáže dovést je 11kW (tři fáze po 16 A), což je výrazně nad plánovanými potřebami sálu. Každé PDU obsahuje 36 zásuvek typu C13 (pro běžné rackové technologie – zejména servery a switche), šest zásuvek C19 (pro výkonově náročnější rackové technologie – například routery) a tři zásuvky UTE (to jsou ty kulaté, které používáte u běžných spotřebičů v domácnosti). PDU je rozděleno do tří sekcí dle jednotlivých napájecích fází, tzn. že každá sekce obsahuje 12x C13, 2x C19 a 1x UTE. Pokud bychom v budoucnu potřebovali nějaké zásuvky ještě přidat, k PDU je možné sériově připojit další PDU s potřebným počtem a typem zásuvek nebo do racku přivést další dva napájecí kabely.

Důležitou součástí systému napájení je jeho monitoring včetně měření spotřeby. To je na našem sále řešeno měřícími transformátory, které jsou umístěny v sálových rozvaděčích. Přes rozhraní jsou pak informace předávány on-line do dohledových systémů provozovatele DC a uvidíme je spolu s dalšími parametry i na zákaznickém portálu. Máme tak pod neustálou kontrolou stavy napájení každého racku.

Elektrický rozvaděč

Elektrický rozvaděč uvnitř

Přívody napájení k rackům

Detail zásuvek PDU

Privátní sál jsme zatím do běžného používání nepřevzali. S dodavatelem řešíme několik nedokončených nebo nedokonalých věcí. Některé potřebujeme doladit před instalací našich technologií, jiné (méně podstatné) může dodavatel dokončit za běhu. U tak rozsáhlé a komplexní akce není nic neobvyklého, že se instalace některých částí zpozdí. My v každém případě pokračujeme v rozsáhlých přípravách instalace našich technologií. Nové (v provozu nezapojené) síťové prvky již konfigurujeme, pro stávající prvky naší infrastruktury dokončujeme plán přesunu do privátního sálu. Téměř každý prvek infrastruktury tak má v našem privátním sále, byť virtuálně, svoje místo. Ale o tom zase někdy příště.

Kategorie:

Chyba v implementaci DNSSEC v BIG-IP load-balancerech od F5

St, 07/10/2019 - 06:00

Při vývoji DNS resolveru Knot Resolver se Laboratořím CZ.NIC podařilo odhalit bezpečnostní chybu, která umožňuje obejít zabezpečení DNSSEC na load-balancerech výrobce F5 a způsobit tak nedostupnost služby. Tyto výrobky jsou nasazeny například na některých internetových bankovních aplikacích i českých bank a úřadů. Z pohledu uživatele se úspěšný útok pomocí této chyby projeví např. tak, že prohlížeč při práci s internetovým bankovnictvím náhle zahlásí chybu „adresu nelze nalézt“ a služba přestane být dostupná.

Výrobce byl o chybě informován již v srpnu 2018 a nyní vydal doporučenou konfiguraci k obejití problému. Protože operátoři DNS resolverů na chybu již naráží i v běžném provozu, publikujeme podrobný popis chyby, abychom informovali odbornou veřejnost a zvýšili povědomí o tomto problému.

Podstatou chyby, kterou jsme objevili při testování nové verze Knot Resolveru, byl technický detail skrytý v softwaru dodavatelské společnosti F5, který obsahuje chybnou implementaci technologie DNSSEC.

V první části tohoto článku je popsána samotná chyba a její důsledky, v druhé potom způsob jejího zneužití a poučení na závěr.

To hlavní zní: Pokud používáte load-balancer F5, požadujte od výrobce co nejdříve opravu pro chybu označenou jako Bugzilla ID 744937. Než bude oprava dostupná, použijte postup popsaný v článku výrobce.

Kde je chyba?

Celý příběh by se dal zkrátit do věty „příčinou chyby je nedodržení technického standardu RFC5155 sekce 3.1.8„, nejspíš jako důsledek snahy o zjednodušení si práce při implementaci.

Aby čtenáři mohli docenit celý princip chyby a její důsledky, ilustrujeme si chybu na příkladu, kde se uživatel snaží připojit na webový server se jménem „www.example.com.“, na němž je nasazen load-balancer. Jako první krok pro připojení musí webový prohlížeč přeložit doménové jméno „www.example.com.“ na IPv4 nebo IPv6 adresu. Překlad prohlížeč provede tak, že najednou odešle dva dotazy na DNS resolver:

  • www.example.com. AAAA (záznam pro IPv6 adresu; dejme tomu, že tato adresa neexistuje)
  • www.example.com. A (záznam pro IPv4 adresu; tato adresa v našem příkladu existuje)

Pořadí, v jakém budou dotazy obslouženy DNS resolverem, je v podstatě náhodné. V následujícím příkladu popisujeme situaci, kdy resolver zpracovává jako první dotaz na IPv6 adresu (typ DNS záznamu AAAA). Levý sloupec popisuje chování korektní implementace, pravý sloupec ukazuje chybu ještě nedávno přítomnou v load-balancerech F5:

Správná implementace Chyba v implementaci F5 1. Webový prohlížeč odešle DNS resolver dotaz na www.example.com. AAAA (typ záznamu AAAA je IPv6 adresa). – stejné – 2. DNS resolver v cache nemá odpověď, protože uživatel danou stránku otevírá poprvé, takže se DNS resolver zeptá autoritativního serveru skrytého za load-balancerem. – stejné – 3. Protože v našem hypotetickém příkladu existuje pouze IPv4 adresa (typ A) a neexistuje IPv6 adresa (typ AAAA), load-balancer musí zpět poslat „DNSSEC důkaz neexistence“. – stejné – 4. Load-balancer pošle zpět odpověď obsahující správný důkaz neexistence pro záznam www.example.com. AAAA: Load-balancer pošle zpět odpověď obsahující nesprávný důkaz neexistence pro záznam www.example.com. AAAA: MIFDNDT3NFF3OD.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OE A

Na konci důkazu je seznam typů záznamů, které na jméně www.example.com existují: V našem případě jsou to pouze záznamy typu A (IPv4 adresa). Důkaz je tedy správný a DNS resolver dostává signál: AAAA tu není, máme jenom A. MIFDNDT3NFF3OD.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OD TXT

Úplně na konci důkazu je nekorektní část, která říká, že jméno www.example.com obsahuje pouze záznamy typu TXT. To zároveň znamená, že dotaz na typ A nemá smysl – z uvedeného důkazu by totiž DNS resolver získal chybnou informaci, že neexistuje. 5. Resolver si uloží důkaz neexistence do vyrovnávací paměti (cache). – stejné – 6. Nyní resolver stejným způsobem zpracovává dotaz www.example.com. A (IPv4 adresa). – stejné – 7. DNS resolver z předchozí odpovědi už ví, že A existuje, ale zatím neznal jeho hodnotu. Jinými slovy, v cache má důkaz, že existuje záznam www.example.com. A, který dosud není v cache, takže se zeptá autoritativního serveru. DNS resolver v cache má chybný důkaz, že neexistuje záznam www.example.com. A. 8. Resolver přijme A záznam od autoritativního serveru, zvaliduje DNSSEC podpis a odešle záznam webovému prohlížeči. Na základě chybné informace získané v kroku 4 resolver ihned odpoví webovému prohlížeči, že záznam s IPv4 adresou neexistuje. 9. Webový prohlížeč má IPv4 adresu a může se připojit na web. Webový prohlížeč nemá žádnou IP adresu a nemůže se připojit na web. Útok odepření služby

Chybu ilustrovanou výše může útočník zneužít k útoku typu odepření služby (DoS), a to dokonce dvěma způsoby:

  • Prostým posláním dotazu na DNS resolver s podporou agresivní cache. Útočníkovi se stačí zeptat na cílové jméno a libovolný neexistující typ. Jediným dotazem tak způsobí nedostupnost konkrétní domény a s ní spojené služby pro všechny uživatele daného DNS resolveru, typicky např. všechny zákazníky daného poskytovatele připojení k Internetu.
  • V případech, kdy útočník nemůže poslat dotaz na resolver, nebo daný resolver nepodporuje agresivní cache, lze použít dlouho známou techniku podvržení DNS odpovědi. V tomto případě je útok proveden ve dvou fázích, přípravné a útočné, které popisujeme níže:
Příprava na podvržení odpovědi
  1. Útočník pošle zranitelnému load-balanceru dotaz na cílovou doménu a neexistující typ, např.
    www.example.com. AAAA (nebo kterýkoliv jiný neexistující typ, např. HINFO)
  2. Zranitelný load-balancer odpoví důkazem neexistence, který stejně jako v předchozím příkladě obsahuje nekorektní informaci, ale je validně podepsán podepisovacím klíčem domény:
    MIFDNDT3NFF3OD53O7TLA1HRFF95JKUK.example.com. NSEC3 1 0 0 – MIFDNDT3NFF3OD53O7TLA1HRFF95JKUL TXT
  3. Útočník si uloží nekorektní důkaz neexistence pro pozdější použití.
Útok podvržením odpovědi
  1. Oběť se zeptá na cílovou doménu a existující typ, např.
    www.example.com. A
  2. Útočník podvrhne dříve získanou odpověď místo „pravé“ odpovědi od load-balanceru.
  3. Podvržený důkaz neexistence zdánlivě splňuje všechny požadavky DNSSEC standardu a dokazuje, že typ A neexistuje, a je proto uložen do cache resolveru.
  4. Resolver na základě podvrženého důkazu neexistence odpoví oběti, že požadovaný záznam neexistuje.
  5. Oběť se nemůže na cílový web připojit.
Jak jsme chybu odhalili?

V Laboratořích CZ.NIC se zabýváme vývojem vlastního DNS resolveru a chceme, aby patřil mezi nejefektivnější na trhu. Proto jsme vloni náš software rozšířili o podporu tzv. „agresivní cache s podporou NSEC3“, kterou doposud nemá žádný „konkurenční“ software. Jedná se o novou techniku popsanou ve standardu RFC 8198, která umožňuje DNS resolveru používat všechny informace zabezpečené DNSSEC a odpovídat na některé dotazy přímo z cache resolveru (viz kroky 7 a 8 výše, v odstavci „Kde je chyba“). Když jsme toto rozšíření nasazovali, setkali jsme se s tím, že uživatelé sice získali zefektivnění odpovídání na DNS dotazy, ale zároveň si někteří z nich stěžovali na nevysvětlitelné potíže s připojením na weby některých bank a státních úřadů, a co je nejhorší, „problém sám po chvíli zmizel“, což velmi ztěžovalo analýzu.

Podrobně jsme analyzovali problematické dotazy a odhalili, že problém není v naší implementaci standardu, ale je na straně autoritativního serveru (přesněji load-balanceru) a že se projeví, jen když se dotazy sejdou „v nešťastném pořadí“. Problém pak trvá do vypršení platnosti záznamů v cache DNS resolveru. Chybu jsme nahlásili výrobci a čekali na opravu. Výrobce F5 původně žádný termín opravy nesliboval, ale když jsme podrobně popsali potenciál ke zneužití, tak během několika měsíců publikoval návod, jak chybu obejít změnou konfigurace.

Závěrem

Snad se nám podařilo ilustrovat, jak nebezpečné je používat při implementaci „zkratky“, které jsou v rozporu se standardem. Každá taková nestandardní zkratka sebou nese riziko zavlečení bezpečnostních chyb.

V tomto případě paradoxně byly postiženy systémy institucí, které uživatelé považují za nejbezpečnější a které aktivně investují do „obrany“ pomocí řešení od externího dodavatele. Inu, i subdodavatelé se musí držet technických standardů.

Pokud se chcete o technologii DNSSEC dozvědět víc, zveme vás na kurz v Akademii CZ.NIC.

Kategorie:

Teplo je třeba uchladit

St, 07/03/2019 - 10:13

Venkovní teploty oproti včerejšku sice poněkud opadly, ale i tak bude myslím ideální, když dnešní díl seriálu o budování privátního sálu pojedná o jeho chlazení. Technologie v datovém centru totiž generují obrovské množství tepla (my kalkulujeme s řádově desítkami kW) a bez chlazení, nebo při jeho výpadku, se za pár minut „upečou“. Myšleno v nadsázce. Dnes to již neplatí. Všechny technologie, které budeme v privátním sále provozovat, se při případném přehřátí automaticky vypnou, což dává vlastně stejný výsledek, protože služby na nich přestanou běžet. A výpadky chlazení se opravdu stávají. Ve své praxi jsem je zažil několikrát a často přispěly i ke změně provozovatele datového centra.

V předcházejícím dílu seriálu jsem psal, že máme v privátním sále opravdu hodně vysoko do stropu a že budeme používat racky o výšce 52U, mimo jiné i kvůli získání dalšího prostoru pro naše technologie. Dnes dodávám, že v privátním sále nebudeme mít, oproti tomu stávajícímu zdvojenou podlahu. Nebude ani zapotřebí, protože pro chlazení budeme používat jiný způsob distribuce chlazeného vzduchu. Oproti často používané distribuci pod zmíněnou zdvojenou podlahou je v našem případě použito chlazení tzv. „záplavou“. V obou případech je chladný vzduch nasáván ze studené uličky přes perforované dveře a vyfukován, potom co projde chlazenými technologiemi, do uličky teplé. Dodávky studeného vzduchu na našem privátním sále zajistíme pomocí dvou nadrackových (máme opravdu vysoko do stropu, kolikrát jsem to již psal? :)) klimatizačních jednotek Conteg CoolTop (každá se třemi EC ventilátory), čtyř vnějších jednotek a dvou zvlhčovačů. Obě vnitřní jednotky budou v provozu maximálně na 50 % výkonu v redundanci 1+1. Při výpadku jedné jednotky najede druhá jednotka do plného výkonu. Distribuce chladného vzduchu z CoolTop jednotky je velice plynulá, protože máme přístup vzduchu rovnoměrný před všechny racky ve studené uličce. CoolTop má jednu obrovskou výhodu, tj. velký průtok vzduchu. Jen pro zajímavost, pokud bude v chodu jeden CoolTop na 100 %, tak se vzduch ve studené uličce vymění za šest sekund, což je výkonově více než dostatečné. Ohledně sání teplého vzduchu do jednotky je z pohledu projektu uděláno maximum, tj. nad i kolem jednotek je dostatek volného prostoru pro sání vzduchu z druhé poloviny sálu. Z fyzikálního principu, kdy teplo stoupá vzhůru ke stropu, si jednotky Cool Top tento teplý vzduch dokáží nasát i z protilehlé teplé uličky. Níže je několik fotek z minulého čtvrtka, kdy byla instalace chlazení ještě v běhu a například ještě nebyla zakrytována studená ulička. Na poslední z fotek jsou výše zmíněné zvlhčovače, které doplňují vlhkost v sále, aby neklesla pod 20 %. Pak se totiž zvyšuje riziko statického výboje.

Nadrackovým jednotkám jsme zpočátku poněkud nedůvěřovali. Provozovateli DC Tower nám ale byla názorně předvedena již delší dobu provozovaná podobná instalace, přičemž po exkurzi přímo u výrobce jsme přišli i o poslední pochybnosti. Měli jsme obavy zejména z možného průsaku kondenzátu, který se při chlazení vytváří, ale tomuto je zabráněno instalací kovové vany s aktivním odčerpáním a záložním pasivním odtokem.

Jinak stav instalace privátního sálu má menší zpoždění. Ke dnešku máme osazeny vstupní dveře, plní se klimatizace, dnes se instaluje slaboproud (kamery, zabezpečovačka, čidla, atp.), PDU v racích jsou již pod napětím, probíhá instalace potřebných propojů, finalizuje se instalace vzduchotechniky a zvlhčovačů. Dnes dojde k zakrytování studené uličky, kontrole funkčnosti čidel a k drobným stavebním dodělávkám. Čekáme dále na dokončení systému hašení, kde schází instalace přetlakových klapek a trysek s tlumiči. Do konce týdne by ale mělo dojít i k úklidu a připraví se provozní testy. Během příštího týdne by mělo dojít k zaškolení našich lidí, možná i k předání sálu k našemu využívání. Pak začneme s instalací našich technologií.

Kategorie: