Hosting

Přihlášení

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

Případová studie: CSIRT.CZ a statická analýza malware

Po, 07/09/2018 - 11:13

Na základě upozornění nejmenované hostingové společnosti jsme se dostali k analýze souboru WindowsDefenderService.ini), který aktuálně není rozpoznán žádným z běžných antivirů, a dále souboru (EventManager.dll), jenž rozpoznají pouze tři antivirové systémy. Po prozkoumání obou jsme se rozhodli publikovat tento blogpost, který by měl ostatním pomoci zjistit, zda jejich servery nebyly napadeny; v závěru článku jsou uvedeny IoC, s jejichž využitím by mělo být možné ověřit, zda i vaše servery nebyly kompromitovány.

K samotné analýze jsme dostali čtyři soubory: a.ps1, EventManager.dll, EventManager.logs a WindowsDefenderService.ini. Během počátečního zkoumání vyšlo rychle najevo, že soubor a.ps1 obsahuje skript v powershellu pro tvorbu snímků obrazovky a jejich ukládání do C:\ProgramData\icon.png. Dále se ukázalo, že soubor EventManager.dll není klasická knihovna, ale xml soubor obsahující javascript. Soubor EventManager.logs je ve skutečnosti ini file a WindowsDefenderService.ini změtí textových znaků, které se po chvíli ukázaly jako payload pro zmíněný javascript, který volá powershell s deobfuskovaným obsahem WindowsDefenderService.ini jako command argumentem. Po deobfuskaci pomocí částečného spuštění kódu, dekompresi a přeložení z base64 byl poprvé vidět i samotný zdrojový kód, který byl napsaný pozpátku.

Po přečtení kódu od konce byla jasně vidět struktura jednotlivých funkcí, nicméně kód zůstával i nadále obfuskován. Již byly ale čitelné některé konstanty. Bylo například zjevné, že malware používá api.ipify.org k zjištění veřejné IP adresy. Malware si sebou rovněž nesl 600 delších řetězců (~65 znaků) kódovaných v BASE64, které ovšem po dekódování nedávaly smysl. Rovněž bylo zřejmé, že malware kontroluje existenci antivirových řešení na infikovaném počítači pomocí řetězců „Kasper“, „Panda“, „ESET“, „Symantec“ a „McAfee“.

Po další chvilce zkoumání a několika substitucích se ukázalo, že názvy funkcí a proměnných jsou zakódovány pomocí funkce ROT13. Po jejich dekódování jsme již dostali čitelný zdrojový kód. Ukázalo se, že malware se připojuje na Command & Control server, odkud dostává další příkazy a krom pořizování snímků obrazovky může vykonat prakticky libovolný příkaz.

Při zjišťování k čemu přesně a jak slouží přiložené BASE64 řetězce, byla nalezena funkce, která je kromě dekódování i „dešifruje” pomocí funkce xor a klíče (slova) „secretkey”. Z těchto řetězců se následně vyklubaly URL pro C&C servery, z nichž se náhodně vybíralo pomocí funkce „get-random”. K tomuto výběru docházelo vždy, pokud došlo ke spuštění nebo k problému v komunikaci.

Persistence malware byla zajištěna využitím registrů, konkrétně ve větvi „run” a to jak „HKLM”, tak „HKCU”, a to díky naplánovaným úlohám „schtasks”. Snímky obrazovky malware ukládal do C:\ProgramData\icon.png. Komunikace s Command & Control serverem probíhala každých 135 +/-15 vteřin. V případě pořizování snímku obrazovky se čekalo dalších 15.

Během následujícího víkendu jsme tak dali dohromady potřebné informace, které jsme pak předali dotčené hostingové společnosti. Bohužel nemáme k dispozici informace o vektoru, kterým k napadení serverů došlo. Proto není možné posoudit, zda se jednalo o náhodný útok, nebo zda někdo záměrně útočil na hostingovou společnost. Nicméně právě z těchto důvodů jsme se rozhodli publikovat informace, které mohou pomoci případným dalším obětem zjistit, zda nebyly jejich servery kompromitovány.

Pokud se tedy chcete přesvědčit, zda tento malware nenapadl i vaše servery, můžete využít následující IoC: Seznam C&C serverů a Manipulace s registry.

Martin Kunc, Jan Neduchal

Kategorie:

Tox a jeho použití v CZ.NIC

Čt, 06/28/2018 - 09:36

Před nějakou dobou jsme se v CZ.NIC rozhodli k testování našich projektů v Pythonu použít projekt Tox. Tento projekt umožňuje sjednotit testování projektů v různých prostředích (lokálních vývojových i těch na integračních serverech) a také usnadňuje testování možných kombinací závislostí. Obzvláště druhý bod se nám s přechodem na Python 3 zdál důležitý.

Postupným vývojem a překonáváním drobných (i větších) překážek jsme nakonec dospěli ke stabilní Tox konfiguraci, která splňuje všechny naše požadavky. Níže se pokusím jednotlivé vlastnosti této konfigurace trochu osvětlit a rozebrat.

Konfigurace projektu Tox

Naše finální konfigurace pro projekt „rdap“ vypadá následovně:

[tox] minversion = 3.0.0 envlist = quality,clear-coverage,{py27,py35}-django{10,11},compute-coverage [testenv] setenv = PYTHONPATH = {toxinidir}/test_cfg:{env:IDL_DIR:} DJANGO_SETTINGS_MODULE = settings passenv = IDL_DIR PYTHONWARNINGS debian_deps = py27: python-omniorb py35: python3-omniorb skip_install = coverage: True install_command = pip install --process-dependency-links {opts} {packages} extras = testing deps = coverage !thaw: -cconstraints.txt django10: Django>=1.10,<1.10.99 django10: pytz django11: Django>=1.11,<1.11.99 commands = coverage run --parallel-mode --source=rdap --branch -m django test rdap [testenv:clear-coverage] commands = coverage erase [testenv:compute-coverage] commands = coverage combine coverage report --include=*/tests/* --fail-under=100 coverage report –omit=*/tests/* [testenv:py27-thaw] [testenv:py35-thaw] [testenv:quality] extras = quality # Do not fail on first error, but run all the checks ignore_errors = True deps = commands = isort --recursive --check-only --diff rdap flake8 --format=pylint --show-source rdap pydocstyle rdap

První částí je základní hlavička konfiguračního souboru, která specifikuje minimální požadovanou verzi Tox (kvůli použití negativních faktorů) a také seznam prostředí, která se mají spustit při použití příkazu „tox“. Ta jsou specifikována pomocí tzv. faktorů (výčet uvedený ve složených závorkách, jednotlivé faktory jsou odděleny pomlčkou) a při provádění pak dochází k expanzi do matice. Výsledný seznam prostředí (a jejich pořadí) je tedy následující:

quality clear-coverage py27-django10 py27-django11 py35-django10 py35-django11 compute-coverage

Následuje blok specifikující základní nastavení testovacího prostředí a také definuje, jaké příkazy se budou provádět. Blok „debian_deps“ je konfigurací pro„tox-debian-plugin“, který se stará o instalaci Debianích balíků přímo do daného virtuálního prostředí. Tento blok také využívá faktorů a specifikuje různé závislosti v návaznosti na verzi Pythonu. Pomocí volby „skip_install“ specifikujeme, že pro prostředí, které obsahují faktor „coverage“ není nutné balík instalovat. Dále potřebujeme definovat vlastní instalační příkaz (přidána volba „–process-dependency-links“ – je důležité pro implementaci hooku) a také definujeme, jaké extra komponenty testovaného projektu se mají instalovat a jaké další balíky (kromě tech uvededených v setup.py) je nutné doinstalovat. Zde je opět použito faktorů a to i negativních („!thaw“ značí všechna prostředí, která neobsahují faktor „thaw“). Volbou „commands“ jsou specifikovány příkazy, které se mají provést v rámci běhu daného virtuálního prostředí.

Nastavení uvedená v bloku „[testenv]“ jsou brána jako základní a je možno je přetěžovat či k nim přidávat. Toho se využívá při definici prostředí pro zpracování výsledků coverage, kde se sice používá stejné natavení jako v základním bloku, ale jsou zde změněny příkazy, které se provádějí.

Dále je také možné specifikovat jiná prostředí, která nejsou uvedená v definici „envlist“. Takto definovaná prostředí je možno spustit ručně pomocí přepínače „-e“. Takto máme definována prostředí pro testování aktuálních verzí závislostí. Posledním použitým prostředím je statická kontrola kvality, kde je vynulován seznam závislostí kvůli urychlení vytváření prostředí a také jsou tu ignorovány výsledky jednotlivých příkazů. To donutí Tox dokončit všechny příkazy uvedené v bloku „commands“ a nahlásit až souhrnný výsledek.

Správa závislostí na interních projektech

V našem vývojovém cyklu a prostředí našich aplikací dochází často k tomu, že vývojová větev závisí na ješte nezačleněných větvích v jiných interních projektech. Tento stav pro Tox (i pro nás) představuje problém, protože bychom museli v „setup.py“ vždy uvádět konkrétní vývojovou větev závislých projektů. Tento způsob je ale zcela nevhodný, protože by bylo nutné setup.py při integraci do hlavní větve měnit a mohlo by docházet k chybám.

Rozhodli jsme se tedy využít možností psaní pluginů pro Tox a napsat si plugin, který se o podobnou věc postará za nás.

Nejprve jsme vytvořili repozitář pro správu závislostí mezi projekty. Z formátů nakonec vyhrál JSON díky své jednoduché struktuře a přítomnosti parseru přímo ve standardní knihovně. Náš konfigurační soubor má následující strukturu:

{ „project1“: { „origin“: „project_1_url“, „revision“: „an_awesome_feature“ }, „project2“: { „origin“: „projectu_2_url“, „revision“: „yet_another_feature“ } }

Tento konfigurační soubor se jmenuje „our_feature.conf“ a jednoduše znamená, že aby někomu fungovala naše vývojová větev pojmenovaná „our_feature“, musí si v projektech 1 a 2 přepnout na větve „an_awesome_feature“, resp. „yet_another_feature“.

Toto nastavení jednotlivých větví je tedy třeba provést i při automatickém testování v rámci continuous integration. K nám tomu slouží implementace Tox pluginu. Ten se pomocí „pluggy.hookimpl“ zapojí do procesu instalace závislostí a provede následující kroky:

1) Naklonuje výše uvedený repozitář s konfiguracemi prostředí do dočasného adresáře,

2) zkontroluje, zda se tam nachází konfigurační soubor pro aktuální větev,

3) zmodifikuje soubor instalovaného projektu obsahující URL repozitáře pro závislé projekty a přidá k nim specifikace větve (volba „dependency_links“ v setup.py),

4) spustí znovu instalaci závislostí daného projektu.

Tento postup není ideální, protože se dané prostředí vytváří dvakrát, ale v současné době pro nás asi neexistuje lepší řešení. Naše interní projekty nejsou umístěny v PyPi a jsou tedy instalovány přímo přes URL repozitářes pomocí přepínače „–process-dependency-links“.

Celá implementace hooku pak vypadá následovně:

@hookimpl def tox_testenv_install_deps(venv, action): """Parse dependency links and update dependencies.""" if not os.path.isfile(venv.envconfig.dep_links): return None action.setactivity('PR-VERSION', 'parse version depencencies') tmp_dir = mkdtemp(prefix='pr-version-') try: action.setactivity('PR-VERSION', 'git clone') action.popen(['git', 'clone', 'git@gitlab.office.nic.cz:pr-utils/pr-version.git', '--depth', '1', tmp_dir]) action.setactivity('PR-VERSION', 'parse dependency links {}'.format(venv.envconfig.dep_links)) # Make a copy of dep_links copy(venv.envconfig.dep_links, tmp_dir) update = parse_deps(venv, venv.envconfig.dep_links, action, tmp_dir) if update: action.setactivity('PR-VERSION', 'dependencies changed - running sdist again') # This will recreate the package according to the settings and tox params venv.session.get_installpkg_path() # Replace the modified dep_links from backup copy(os.path.join(tmp_dir, venv.envconfig.dep_links), venv.envconfig.dep_links) finally: rmtree(tmp_dir)

Veškerá práce se zjišťováním aktuální verze a přepisováním konfiguračního souboru je bohužel natolik specifická, že je zbytečné ji zde uvádět. Závisí dost značně nejen na struktuře projektu jako takového, ale i na tagovacích a releasovacích zvyklostech projektů.

Shrnutí

Celkově jsme s použitím projektu Tox pro sjednocení vývojových prostředí velmi spokojeni a postupně na testování pomocí Tox přecházíme se všemi projekty. Za hlavní výhody považujeme jednoduchou rozšiřitelnost na další prostředí, reprodukovatelnost prostředí a komplexní správu sestavovací matice.

Kategorie:

Kolektor DNS provozu

St, 06/27/2018 - 09:45

Vydáváme dns-collector, vstupní část našeho systému pro monitorování a analýzu provozu našich DNS serverů. Spolu s pokročilou analýzou shromážděných dat můžeme nejen sledovat provoz DNS a detekovat naléhavé problémy, ale také zjišťovat a zkoumat dlouhodobé trendy a problémy (například nesprávnou konfiguraci vnějších serverů). Tento systém jsme prezentovali už na konferenci IT 15.2 (video a prezentace v češtině).

Kolektor je první částí analytické pipeline, sleduje provoz DNS a vytváří předzpracovanou formu dotazů vhodných pro efektivní archivaci, transport a další analýzy. Požadavky jsou párovány s odpověďmi podle IETF draftu, kolektor podporuje několik rozšíření EDNS, výstupy jsou buď CSV nebo datové struktury CBOR. Kolektor podporuje BPF filtry, volbu sbíraných atributů, kompresi a rotaci výstupních souborů a samozřejmě podporují offline zpracování PCAPů. Pro efektivitu je kolektor napsán v C nad knihovnou libknot (součást serveru Knot DNS) a spolehlivě zvládne více než 100 000 dotazů za sekundu. Můžete jej spustit buď přímo na serveru DNS nebo na vyhrazeném serveru s port-mirroringem.

Dns-collector vydaný pod GPLv3 najdete na našem githubu a jako hotové balíčky pro Ubuntu, Debian a další v OpenBuildService repozitáři.

Kategorie:

Olomouc hostila 40. ročník soutěže Středoškolská odborná činnost

Út, 06/26/2018 - 09:56

V neděli 17. června jsem měla možnost být v Olomouci na slavnostním vyhlášení vítězů 40. ročníku celostátní přehlídky Středoškolské odborné činnosti. Sdružení CZ.NIC podporuje tuto akci již pátým rokem a i po těch letech se nestačíme divit, co se najde za talenty mezi dnešními středoškoláky. Ale vezměme to od začátku, protože než se studenti probojují na celostátní přehlídky, čeká je dlouhá cesta.

Máte pocit, že jste o Středoškolské odborné činnosti (SOČ) nikdy neslyšeli? Nevadí, pojďme si jí představit. Jedná se o soutěž pro středoškolské studenty, kterou pořádá Národní institut pro další vzdělávání. Její historie sahá až do roku 1978. Účastí v soutěži dostanou studenti možnost si v praxi vyzkoušet, co obnáší vědecká činnost nebo psaní a obhajoba odborné práce, mohou zjistit, jak by je bavil vybraný vysokoškolský obor a pokud se někteří umístí na předních místech, mají šanci tím začít vědeckou kariéru. Vyhlašované obory jsou vždy z přírodovědné, humanitní a technické oblasti, takže si každý najde to svoje. Jak jsem naznačila v úvodu, než jsou vyhlášení ti nejlepší z nejlepších, čeká středoškoláky dlouhá cesta, která trvá od února do června, a to nepočítám samotnou tvorbu práce, která tomu všemu předchází. Nejprve studenti se svou prací účastní tzv. školní přehlídky. Z ní vzejdou jedinci, kteří postoupí do okresní přehlídky a odtud ti nejlepší putují na krajskou přehlídku. Vítězové z krajských kol se pak utkají na celostátní přehlídce, která vrcholí slavnostním vyhlášením.

Celostátní přehlídka je putovní a koná se vždy v jiném městě v rámci České republiky a nad jejím konáním přebírá záštitu jedna z místních škol. Pro 40. ročník byl vybrán Olomouc a hostování se ujalo Slovanské gymnázium v čele s ředitelem Radimem Sloukou. Slavnostní vyhlášení vítězů se pak odehrálo na půdě Moravské vysoké školy Olomouc.

Když jsem vešla do auly, panovala tam atmosféra plná očekávání a lehké nervozity. Kdo se asi stane vítězem jednotlivých oborů? Pro 40. ročník byly vyhlášeny tyto obory: matematika a statistika, fyzika, chemie, biologie, geologie, geografie, zdravotnictví, zemědělství, potravinářství, lesní a vodní hospodářství, ochrana a tvorba životního prostředí, strojírenství, hutnictví, doprava a průmyslový design, elektrotechnika, elektronika a telekomunikace, stavebnictví, architektura a design interiérů, tvorba učebních pomůcek, didaktická technologie, ekonomika a řízení, pedagogika, psychologie, sociologie a problematika volného času, teorie kultury, umění a umělecké tvorby, historie, filozofie, politologie a ostatní humanitní a společenskovědní obory a informatika.

Konečně zazněla slavnostní fanfára a přistoupilo se k vyhlašování a předávání cen. Vše šlo jako po másle, až jsme najednou byli u oboru s číslem 18 – Informatiky. Při této kategorii dávám vždy největší pozor, protože si kladu otázku, jestli někdo z těchto studentů nebude náhodou za pár let pracovat u nás v CZ.NIC. Kdo ví, jestli se v budoucnu na chodbě nepotkám s Antonínem Říhou, Ivem Meixnerem nebo Danielem Krejčím, kteří letos uspěli na předních příčkách.

Antonín Říha se umístil na třetím místě s prací „Implementace a rozbor algoritmu NEAT pro problémy reinforcement learningu“. Cílem práce bylo prozkoumání teoretických východisek pro použití genetických algoritmů na problémy reinforcement learningu a jejich následná implementace. Antonín aplikoval NEAT algoritmus, pro který navrhl vlastní rozšíření a prozkoumal jeho schopnosti pomocí experimentů. V praktické části došlo na samotnou implementaci a na vytvoření prostředí pro další vývoj. Výsledkem bylo, že nové rozšíření algoritmu NEAT je dobrou alternativou pro některé domény.

S prací „Hlasový asistent TERMIX“ uspěl na druhém místě Ivo Meixner. Ve své práci se zabýval hlasovým asistentem a ovládáním počítače pomocí hlasu. Záměrem bylo navrhnout a naprogramovat takový počítačový program, který by běžnému uživateli umožnil ovládat počítač pomocí hlasových příkazů. K dosažení cíle použil Ivo programovací jazyk C#, platformu Microsoft .NET Framework, vývojové prostředí Microsoft Visual Studio a systém pro převod hlasu na text Google Speech API. Výsledkem hlasového asistenta je možnost ovládat hlasem webový prohlížeč, psát text, dále může sloužit k vyhledávání informací na Internetu a přehrávat videa na YouTube.

A konečně celorepublikovým vítězem se stal Daniel Krejčí, který se ve své práci s názvem „Lovci perel“ věnoval vývoji webového informačního systému pro stejnojmennou hru. Tu již provozují knihovny a školy po celé České republice. Podnětem pro vznik systému byla neexistence centrální správy hry bez možnosti prezentace projektu veřejnosti. Nový systém přenáší správu hry do internetové podoby. Přínosem pro knihovny a školy jsou nové možnosti organizace, čtenáře informuje o jejich čtenářské aktivitě a veřejnosti nabízí jednotný a ucelený pohled na projekt, jeho funkcionalitu a přináší jednodušší možnost registrace. Daniel použil k napsání jádra projektu PHP za pomoci MVC frameworku CodeIgniter. Výstup je posílán do prohlížeče uživatele v HTML, CSS a JavaScriptu. Nebyla opomenuta ani bezpečnost, která zajišťuje aktivní obranu před SQL injection, Brute force attack a Cross-site scripting.

Vítězové této kategorie uzavřeli 40. ročník Středoškolské odborné činnosti, vše, co mělo být rozdáno, se rozdalo a byl čas, aby zazněla opět fanfára a my jsme se mohli rozjet do svých měst. Při odchodu jsem nemohla myslet na nic jiného, než že jsem měla opět možnost stát na pódiu ve společnosti skromných, mladých, nadějných lidí, kteří s nesmělostí přebírali své diplomy a ceny. Nemohli uvěřit, že vyhráli a že jejich snažení mělo kýžený výsledek. Nejvíc mě překvapuje, že bych čekala sebevědomé a průbojné jedince, ale opak je pravdou. V mnohých očích byla vidět nevěřícnost, radost, zklamání, ale také odhodlání se účastnit další rok. I já doufám, že budu mít možnost u toho opět být. Takže snad na shledanou příští rok v Opavě.

Kategorie:

Novinky v oblasti školních webů – sCOOLweb 2018

So, 06/16/2018 - 07:10

Ve středu 6. června proběhla na pražském magistrátu konference o školních webech sCOOLweb. Čtvrtý ročník konference, kterou tradičně pořádá informační centrum o vzdělávání  EDUin, o. p. s., se nesl v duchu tématu GDPR. Na konferenci byly vyhlášeny nejlepší školní weby v kategoriích úplně či neúplně organizovaných základních a středních škol.

Sdružení CZ.NIC se soutěže účastní téměř každý rok v roli hodnotitele. Letošní ročník měl za cíl přinést auditoriu z řad ředitelů, učitelů a správců školních webů důležité informace ke správnému nakládání s osobními údaji. K GDPR nicméně padly i lehce úsměvné příběhy z praxe. Vyučující Zdeněk Heteš (ZŠ Mládežnická, Trutnov), Václav Fišer (ZŠ Komenského, Trutnov) ze dvou trutnovských škol vyprávěli o tom, jak se ocitli na tenkém ledě, když se rozhodli založit každému žákovi své školy e-mailové adresy obsahují jméno a adresu v cloudu.

Středoškoláci pomáhají testovat bezpečnost školních webů

Přestože EDUin nechal vypracovat poměrně detailní návod, jak správně vést školní web, stále spousta školních webů nedokáže dodržet bezpečnostní kritéria. Proto mě velmi zaujal aplikovaný projekt, který středoškolské studenty vtahuje do problematiky penetračních testů webových stránek. Jakub Krejcar a Jakub Hudec, studenti SŠIS Dvůr Králové nad Labem a Marek Hencl z firmy AARTKOM na konferenci hovořili o společném aplikovaném projektu odborné firmy a střední školy. Principem nástroje je skenování stránek školy, kde se sleduje komunikace, zabezpečení a ochrana dat. Pro zadavatele je následně zpracována závěrečná zpráva s doporučením, jak lépe zabezpečit web a ochránit soukromí uživatelů. Že by alternativa k našemu projektu Skener webu?

Výsledky

A jak to letos všechno dopadlo? První místo v kategorii škol tvořených pouze třídami prvního stupně získala Škola Na Pohodu Hodonín, z plně organizovaných škol pak ZŠ Čelákovice. V kategorii středních škol zvítězila SŠ polytechnická Brno.
Soutěž, která je pro školy zdarma, probíhala od letošního dubna ve dvou kolech. Nejprve weby posuzovali hodnotitelé nominovaní samotnými školami, ve druhém kole mezi 30 finalisty rozhodovala odborná porota. Souběžně s tím probíhalo i online hlasování veřejnosti.
Počet zájemců o soutěž každý rok stoupá. Největší zájem o zpětnou vazbu na školní webové stránky mají střední školy, které mají nouzi o studenty. Ty jsou také schopny nejvíce investovat čas i peníze do své webové prezentace i uživatelského výzkumu.

Kritéria, podle nichž jsou školní weby hodnocené, sledují pestré spektrum ukazatelů, vítězí školní webové stránky od profesionálů, rodičů i učitelů či ředitelů. Důraz je kladen na přehlednost informací, autentické fotografie, uživatelsky přívětivý a propracovaný obsah i bezpečnost.
EDUin se soutěží snaží eliminovat nejčastější nešvary školních webů. Například, že stále spousta školních webů neběží správně na mobilních zařízeních a na některých nedohledáte ani kontakt na ředitele. Případně je kontakt na důležité osoby směřován na jejich soukromé adresy, což může působit nedůvěryhodně a znamenat bezpečnostní rizika. Co se týká obsahu, nejhorší ze všeho jsou dlouhé nestrukturované texty ve formě různých vyhlášek.

Výsledky sCOOL web 2018

Kategorie A (neúplně organizované ZŠ)
1. místo: Základní škola Na Pohodu
2. místo: Základní škola SMART š.p.o.
3. místo: Základní škola Navis

Kategorie B (plně organizované ZŠ)
1. místo: Základní škola Čelákovice, Kostelní 457, příspěvková organizace
2. místo: Základní škola a mateřská škola Proseč
3. místo: Základní škola a Mateřská škola Emy Destinnové

Kategorie C (střední školy)
1. místo: Střední škola polytechnická Brno, Jílová, příspěvková organizace
2. místo: Masarykova střední škola Letovice, příspěvková organizace, Tyršova 500/6
3. místo: Gymnázium Vincence Makovského se sportovními třídami Nové Město na Moravě

Cena veřejnosti
1. místo: Základní škola Čelákovice, Kostelní 457, příspěvková organizace (1426 hlasů)
2. místo: Základní škola a mateřská škola Proseč (466 hlasů)
3. místo: Základní škola Navis (353 hlasů)

Loni v této soutěži nejvíce zaujaly školy v Praze, Deblíně a Vysokém Mýtě. Ráda bych ještě vyzdvihla ZŠ Deblín, na jejímž webu se silně podíleli rodiče a žáci. Je vidět, že webové stránky při troše dobré vůle mohou fungovat jako společný projekt rodičů, dětí a učitelů. Bohužel takováto spolupráce je zatím stále velmi osamělá vlaštovka.

Kategorie:

V oblasti kybernetické bezpečnosti na středních školách máme co dohánět

Pá, 06/01/2018 - 10:15

Není pochyb o tom, že studenti středních škol využívají informační a komunikační technologie úplně stejně běžně jako zubní kartáček. Bohužel pokud dojde na téma bezpečnosti, je skutečně co zlepšovat. To prověřil již druhý ročník Národního finále Středoškolské soutěže České republiky v kybernetické bezpečnosti.

Národní finále organizovala pracovní skupina kybernetické bezpečnosti AFCEA ve spolupráci s celou řadou státních, akademických a profesních organizací. Do národního finále postoupilo celkem 36 studentů z 26 středních škol z celé České republiky, a to po předchozích dvou kolech, kterých se zúčastnilo více než 3 000 soutěžících. Pro představu, v ČR je zhruba 425 000 studentů středních škol. To znamená, že necelé jedno procento českých studentů se zúčastnilo soutěže, díky které mohou nalézt okamžité uplatnění ve velmi důstojně placených zaměstnáních nebo značnou podporu vlastního podnikání. Důkazem tomu je partnerství mnoha velkých firem.

Naše sdružení využilo bohatého doprovodného programu k prezentaci projektu podpořeného Ministerstvem vnitra, díky kterému mohou instituce veřejné správy do konce června žádat o bezplatnou výpůjčku routeru Turris Omnia.

No a jak to celé probíhalo a jak to vlastně dopadlo? Ve dvoukolovém finálovém klání řešili studenti celkem 23 úloh různého stupně obtížnosti, z nichž prvních dvacet úloh řešili individuálně a následující tři úlohy byly týmové a řešilo je již pouze 24 postupujících studentů.

Nejlépe se dařilo soutěžícímu Ondřeji Blehovi z Gymnázia Boženy Němcové v Hradci Králové, hned za ním se umístil Břetislav Hájek z Gymnázia v Českém Brodě a trojici oficiálně nejlepších českých etických hackerů uzavřel Ondřej Tesař. Národním kolem soutěž ještě nekončí, 15 nejlepších studentů se v průběhu léta bude ucházet o možnost jet na Evropské finále v kybernetické bezpečnosti, které se koná v říjnu v Londýně. Studenti budou vybráni nejen na základě svých technických znalostí, ale i na základě komunikačních, prezentačních a sociálních dovedností.

Do soutěže bylo zapojeno téměř 300 škol, na kterých proběhla řada přednášek a diskusí, jichž se zúčastnilo téměř 10 000 studentů a 500 učitelů. Soutěž má tedy kromě uplatnění a rozvoje talentů i značný osvětový charakter. Do dalších let tedy přejeme organizátorům, aby počet soutěžících pořádně rostl.

Kategorie:

Přechod na eliptické křivky v doméně CZ

St, 05/30/2018 - 08:50

Historie nasazení technologie DNSSEC v doméně CZ je již víc než desetiletá a v jejím průběhu došlo k několika důležitým změnám. Vezměme například rok 2010, který byl z pohledu nasazení DNSSEC přímo nabitý událostmi. V první řadě proběhlo v červenci podepsání kořenové zóny a hned vzápětí také vůbec první rotace KSK klíče se změnou algoritmu mezi doménami nejvyšší úrovně, kterou jsme v doméně CZ provedli v srpnu. Po uplynutí osmi let si tento „double“ letos zopakujeme, jen v opačném pořadí. Na říjen je naplánována odložená první rotace KSK klíče kořenového zóny (bez změny algoritmu). No a v červnu provedeme v CZ doméně již avizovanou rotaci KSK klíče, opět se změnou algoritmu. Tentokrát ale jako první správci domény nejvyšší úrovně použijeme algoritmus ECDSA založený na eliptických křivkách.

Výhody i nevýhody nového algoritmu byly již mnohokrát prodiskutovány. K těm již dříve zmiňovaným výhodám, jako je vyšší bezpečnost (větší síla klíče) a nižší náchylnost ke zneužití pro DDoS (menší DNS odpovědi), bych přidal i obecně lepší dostupnost DNS. Na základě výzkumů laboratoří APNIC týkající se problematiky doručování fragmentovaných datagramů po IPv6 totiž znamená zmenšení velikosti DNS odpovědi i potenciální zrychlení fungování DNS po IPv6 v některých sítích. Nevýhodou ale je, že stále existují staré, neaktualizované DNS servery, které se při neznámém algoritmu budou chovat, jako kdyby dotazovaná doména neměla DNSSEC zapnutý. Je poměrně pravděpodobné, že takovéto neaktualizované DNS servery budou vytrestané již zmiňovanou výměnou KSK kořenové zóny a  DNS jim nepojede vůbec, takže určitě ještě jednou apelujeme na správce DNS serverů – aktualizujte a prověřte konfigurace!

Pro uživatele, kteří se zajímají jak o stav jejich DNS resolveru, spravovaný pravděpodobně jejich poskytovatelem internetu, existuje hned několik nástrojů. Pokud si například zobrazíte naší domovskou stránku, a uvidíte zelené kolečko u nápisu Zabezpečeno technologií DNSSEC, můžete být v klidu. Jiná barva znamená, že byste měli kontaktovat správce vašeho DNS resolveru s žádostí o lepší zabezpečení. Trochu podrobnější přehled podporovaných algoritmů nabízí test, který vytvořili holandští výzkumníci.

Situace v doméně CZ se nicméně za poslední rok vyvinula tak, že algoritmus ECDSA je vůbec nejpoužívanějším DNSSEC algoritmem. Čeští registrátoři Zoner, Ignum a ACTIVE24 vyhodnotili nový algoritmus tak, že jeho přínos je velký a podpora dostatečná a přešli na něj u všech domén, které hostují na své infrastruktuře. Obě varianty tohoto algoritmu, tedy ECDSAP256SHA256 i ECDSAP384SHA384 pokrývají již téměř polovinu všech zabezpečených domén. Bez ohledu na DNSSEC algoritmus použitý přímo pro doménu CZ již tedy algoritmus ECDSA při navštěvování českých domén pravděpodobně využíváte.

Za uplynulých osm let se také výrazně proměnil i způsob, jakým DNSSEC spravujeme. V roce 2013 jsme se rozhodli rozdělit správu ZSK a KSK klíčů do dvou týmů. Zatímco ZSK klíč, který se mění každé dva měsíce, mají ve správě systémoví administrátoři, KSK klíč je uložen offline v trezoru a dohlíží na něj členové bezpečnostního týmu CSIRT. Vždy dvakrát do roka vygeneruje ZSK tým tři nové klíče a připraví soubory obsahující odpovídající kombinace podle časového schématu na další půlrok. KSK tým následovně vyzvedne z trezoru KSK klíč a podepíše připravené soubory. Tyto soubory s podpisy jsou pak uloženy zpět do systému, kde skript podepisující zónu vždy podle aktuálního času vybere příslušnou kombinaci klíčů s podpisy a vloží ji do zónového souboru. V rámci této procedury jsme si již dříve vyzkoušeli standardní rotaci KSK, nikoliv však se změnou algoritmu.

Správně provedená změna algoritmu totiž vyžaduje speciální postup zahrnující podepsání zónového souboru dvěma klíči od stávajícího i nového algoritmu a to ještě před publikací nového klíče v DNS. Některé verze DNS resolveru Unbound jinak považují celou doménu za nevalidní. Verzí Unboundu, které se chovají takto striktně, ale celkem ubývá a tak si například správce domény SE troufl provést změnu algoritmu standardním (liberálním) způsobem. Jak je vidět z prezentace na právě skončené konferenci RIPE76, která se této změně věnovala, nezaznamenali žádný problém. My jsme se rozhodli být v tomto směru konzervativnější a provést změnu tak, jak doporučuje RFC6781. Museli jsme tedy vytvořit nový postup, který zahrnoval spolupráci jak ZSK tak KSK týmu. Mimo jiné musel například KSK tým aktualizovat své prostředí pro KSK ceremonii na nejnovější Ubuntu, které již obsahuje software s podporou ECDSA algoritmu. Celý postup jsme otestovali na speciálně vytvořeném testovacím prostředí a poté ho provedli na doméně 0.2.4.e164.arpa (ENUM doméně), kterou spravujeme stejným způsobem jako doménu CZ.

Jelikož se během testování a ani během změny algoritmu na doméně 0.2.4.e164.arpa neobjevily žádné problémy, plánujeme nyní provést tentýž postup na doméně CZ. Kroky budou následující:

  • 4.6.2018 10h – Vkládáme nové podpisy využívající ECDSA algoritmus
  • 5.6.2018 10h – Publikujeme nové ECDSA klíče
  • 5.6.2018 18h – Generujeme žádost o změnu DS záznamu v kořenové zóně (doba zpracování je max. do sedm dnů)
  • *7.6.2018 10h – Odebíráme staré RSA klíče (může se změnit podle rychlosti změny DS záznamu v kořenové zóně)
  • *8.6.2018 10h – Odebíráme staré podpisy využívající RSA algoritmus (může se změnit podle rychlosti změny DS záznamu v kořenové zóně)

Vzhledem k tomu, že čas podepsání zóny oběma klíči je podle našich testů víc než dvojnásobný oproti stávajícímu, rozhodli jsme se, že po dobu rotace budeme generovat zónový soubor jen jednou za hodinu. O dalším průběhu vás budeme informovat.

Kategorie:

Route Origin Validation v Internetu

St, 05/23/2018 - 10:07

Route Origin Validation (ROV) je komplementárním mechanismem k vydávání Route Origin Authorization (ROA). Dohromady pak tvoří bezpečnostní mechanismus Resource Public Key Infrastructure (RPKI), který má ambice potírat a nebo přinejmenším zmírnit následky chybně oznámených prefixů protokolem BGP. Nasazení mechanismu RPKI je však pomalé a to i navzdory jeho technologické vyspělosti, existenci všech potřebných standardů, software i detailní dokumentaci a propagaci standardu ze strany RIPE NCC. Článek se zabývá kvantifikací nasazení mechanismu ROV v současném Internetu.

Motivace pro zabezpečení směrování v Internetu

V únoru 2008 začal autonomní systém s číslem 17557 (Pakistan Telecommuication company) oznamovat svým sousedům nový prefix 208.65.153.0/24. Tato jinak všední provozní záležitost rozvířila diskuzi o bezpečnosti Internetu jako celku, neboť zmíněný prefix byl součástí méně specifického prefixu, který měl tou dobou přidělený YouTube a který obsahoval servery, tou dobou zcela klíčové pro doručování obsahu všem, kdo si chtěli na YouTube přehrávat video. Jedním z fundamentálních aspektů protokolu TCP/IP je pravidlo, že specifičtější cesta vždy vyhrává. Oznámením specifičtější cesty k subnetu se servery YouTube tedy AS17557 přetáhl veškerý světový provoz na tyto klíčové body YouTube do své sítě a tam tento provoz potichu zahodil. Celá příhoda byla vysvětlena jako konfigurační chyba na straně AS17557, který ve snaze splnit příkaz vlády k omezení přístupu k YouTube ve vlastní síti injektoval slepou cestu do své sítě a nedopatřením došlo k redistribuci do protokolu BGP a k oznámení cesty všem sousedům.

Selhali i sousedé, zejména upstreamy, od kterých se očekává ochrana proti podobným konfiguračním chybám v podobě ručně nastavených filtrů, jejichž změna se musí explicitně domluvit, případně i ověřit správnost v databázích regionálních registrářů (RIR), kteří přidělují IP adresy a vedou databáze alokací. Nutno však podotknout, že provozní postupy a udržování oněch filtrů se v různých částech světa značně liší a že i data v databázích alokací nejsou mnohdy v nejlepší kondici. Nastavování filtrů představuje nepříjemnou administrativu spojenou s odhadováním a prověřováním podezřelých údajů s často těžko kontaktovatelnými protistranami. Zkrátka administrativu, kterou technici nedělají rádi a management je málokdy nadšený z nákladů na práci, která sice potenciálně může zabránit velkému problému, ale k němu skoro vždy vůbec nedojde.

V případě incidentu Pakistan Telecom vs. YouTube došlo k celosvětovému výpadku YouTube na dobu několika desítek minut. Tehdy uplatněné řešení situace ze strany YouTube se stalo prototypem pro mnoho následujících incidentů tohoto druhu: V první řadě YouTube oznámil tentýž prefix shodné, tedy specifičtější délky síťové masky, než původní legitimní prefix. Tím se část bližších sítí přesměrovala zpět na skutečný YouTube a z celosvětového výpadku se stal jen výpadek v blízkosti Pakistan Telecomu. Následovalo kontaktování viníků – správců autonomního systému, který oznamoval konfliktní prefixy a i jejich upstreamů, upozornění na problém a následné odfiltrování úniku. Tato cesta se však ukázala jako pomalá a k vyřešení incidentu stažením chybného oznámení cest došlo až o několik desítek minut po jeho objevení. Celý incident byl zanalyzován a popsán na webu RIPE NCC [1].

Vznik RPKI

Nejen tento incident, ale desítky dalších podobných úniků, útoků a nehod, které se stávaly a stávají relativně často, odhaduje se, že se jedná o jednotky případů za den, akcelerovaly vývoj automatických preventivních opatření. Návrh, který uspěl v diskuzi Internetové komunity a v procesu vývoje standardů byl systém RPKI. K jeho standardizaci došlo v roce 2013 v dokumentu RFC 6480 [2] a v dalších návazných standardech. Jedná se o hierarchický systém, který staví na kryptografickém potvrzování transferu autority nad částmi adresního prostoru a proto byla klíčová podpora RIRů – mezinárodních koordinátorů užití adresního prostoru. Z hlediska Evropy přišla podpora RPKI od RIPE NCC velmi brzy po standardizaci a plnému nasazení RPKI již několik let vlastně nic nebrání.

Celý sytém RPKI není ani příliš složitý, jeho návrh je přiměřeně elegantní a software realizující tento systém je k dispozici v produkční kvalitě i s dokumentací a s možností bezplatných školení ze strany RIPE NCC. Z hlediska jednotlivého provozovatele sítě (autonomního systému) lze RPKI implementovat i s relativně omezenými prostředky a časem. Nicméně již během standardizace se objevily výhrady proti hirearchické podobě RPKI, která efektivně umožní výše postaveným uzlům v RPKI stromu kdykoliv revokovat certifikáty pro nižší uzly a ve výsledku tak odpojit a nebo omezit konektivitu závislým sítím. Sluší se říct, že to není vedlejší účinek, ale prakticky to je prostředek i cíl RPKI.

Přijetí RPKI a nasazení

Bezpodmínečné nasazení RPKI by byla bezpochyby obrovská změna organizace Internetu. V současnosti se Internet skládá z autonomních systémů, které se svobodně dohodly o propojení, navzájem si přiměřeně důvěřují a proto přijímají prefixy oznámené protokolem BGP a předávají je dál. Nad tím, co kdo oznámí protokolem BGP svým sousedům, není tedy žádná centrální kontrola, a veškerá zodpovědnost padá na zdroj oznámení cesty a částečně na jeho bezprostřední sousedy. Těžiště odrážení chybných a nebo zlovolných oznámení a obecně rozhodování o tom, jaké oznámení prefixů se do Internetu vpustí, leží na upstream ISP případného škůdce. V mnoha případech není kvůli počtu oznamovaných prefixů a frekvenci změn reálné všechny příchozí oznámení kontrolovat a proto je na mnoha místech ve filtrech vše povoleno, stejně jako v případě Pakistan Telecomu a jeho upstreamů. RPKI by pravomoc rozhodovat o příchozích oznámeních přeneslo ve prospěch automatického systému. Správci by sice stále mohli ručně zasáhnout. Stejně, jako dnes od určitého množství není ruční kontrola únosná, vše zůstává povoleno a správci ručně zasahují až po důrazném upozornění, tak v případě automatizace kontroly pomocí RPKI by v drtivé většině případů rozhodovaly hierarchicky vydávané certifikáty, a to se všemi důsledky pro omezení decentralizace Internetu.

Odpor proti RPKI z důvodů přenesení rozhodovací pravomoci o přijímaných prefixech na hierarchickou autoritu, které by podle některých hlasů mohlo vést k omezení svobody Internetu, přetrval. Přidaly se i prvotní negativní zkušenosti s konkrétními implementacemi, jistá neprůhlednost a komplikovanost distribuce kryptografických artefaktů ROA a pomalá implementace protokolu RTR ze strany výrobců routerů. Tyto faktory jsou v současnosti vyřešené a nebo přinejmenším vyřešitelné. Přesto prefixů, které jsou pokryté příslušným ROA je zatím jen kolem 10% celkového počtu a růst počtu takto chráněných sítí neslibuje všeobecné přijetí v nejbližší budoucnosti. Mimo to je 0.5 – 1% celkového počtu prefixů pravděpodobně pokryto chybným ROA. Validace a vynucování platných ROA by v současnosti teoreticky ochránilo kolem 10% prefixů a až 1% by bylo neprávem odpojeno.

Otázka počtu sítí, které validují a vynucují ROA byla donedávna předmětem spekulací a převládaly spekulace, že se jedná o marginální počet, omezený zejména na výzkumné sítě a experimentální nasazení.

Měření nasazení ROV

Změřit, kolik autonomních systémů v Internetu vytvořilo a zveřejnilo ROA pro své prefixy a spočítat, kolik prefixů je chráněno, je v principu jednoduchá úloha. Je sice možné vytvořit alternativní neveřejný RPKI strom, mít oddělená úložiště kryptografických artefaktů a klidně i vlastní Trust Anchors, nicméně taková iniciativa nedává v daném okamžiku příliš velký smysl a ani se o ničem podobném neví. Vezmeme-li ROA dostupná na úložištích regionálních registrů (RIR), dospějeme k uvedenému číslu kolem 10% prefixů, pokrytých příslušnými ROA. Z toho je určitá část, až 1% podezřelá, že obsahuje zastaralé a nebo chybné informace. Detailní analýza konfliktů mezi BGP a RPKI je dostupná na webu NIST [3].

Naproti tomu je komplikované najít a kvantifikovat v Internetu sítě, které validují ROA a skutečně aplikují výsledky ROV na routing, tedy zahazují prefixy, pro které existují konfliktní ROA a neexistuje ROA povolující daný pár prefix a origin (t.j. autonomní systém, který prefix oznamuje).

Aktivní experiment

Prezentovaná metoda, která umožňuje otestovat omezený vzorek sítí v Internetu, zjistit, zda validují ROA a tyto výsledky následně zobecnit a usuzovat podle nich o rozšíření ROV v celém Internetu, je závislá na aktivním experimentu. Podstata experimentu je, že se řízeně vyvolá konflikt mezi prefxy oznámenými v BGP a příslušnými ROA a následně se sondují vzdálené sítě, zda je v nich daný prefix dostupný. Tato metoda sama o sobě je velmi nespolehlivá kvůli náhodným fluktuacím v routingu, nedostupným sítím a ztrátám provozu. Spolehlivost i citlivost však lze zvýšit tím, že se připraví diferenciální experiment: Oznámeny jsou dvě sítě, z toho jedna s platným ROA a druhá s v konfliktu s příslušným ROA. Pak lze sledovat rozdíly v šíření těchto dvou prefixů v DFZ. To samo o sobě pořád nestačí, protože výsledkem ROV může být nejen zahození konfliktního prefixu, ale i pouhé snížení jeho priority. Proto je potřeba k nevalidnímu prefixu nabídnout validní alternativu, která by ovšem byla bez ROV méně prioritní. Proto byl připraven oboustranně symetrický experiment, jak ukazuje Obrázek 1.

Obrázek 1: Oboustranně symetrický experiment

 

Aktivního experimentu se účastnily dva autonomní systémy ve dvou různých geograficky vzdálených lokalitách – AS29134 v ČR a AS378 v Izraeli. Z obou zmíněných AS byly oznamovány dva prefixy 188.227.158.0/24 a 188.227.159.0/24, přičemž pro první prefix bylo zveřejněno ROA autorizující jeho oznámení z AS29134 a pro druhý prefix bylo zveřejněno ROA autorizující oznámení z AS378. Oba spolupracující AS zajistily průchod prefixů filtry svých upstreamů a vytvořily příslušné route objekty v RIPE DB (oba AS patří do servisního regiónu RIPE NCC).

Rozpoznání ROV a kvantifikace

Druhá část experimentu je zjistit, ve kterých autonomních systémech byl konfliktní prefix potlačen, zatímco validní prefix procházel. Pro to je potřeba získat informace o routingu. První metoda, naznačená v Obrázku 1 využívá RouteViews [4] a RIPE RIS [5], což jsou služby, které stahují a dlouhodobě uchovávají obsahy BGP tabulek a celou historii změn v BGP z několika stovek autonomních systémů, které poskytují data ze svých routerů těmto projektům. V těchto datech lze snadno dohledat cesty, kde validní prefix prošel, zatímco nevalidní byl cestou ztracen. A s trochou kombinování získaných znalostí, lze s různu mírou pravděpodobnosti dovodit i které autonomní systémy potlačují nevalidní prefixy. Průměrná délka cesty v Internetu, měřeno počtem autonomních systémů, kterými cesta projde, je o něco méně, než 4. Proto je toto dovozování docela jednoduché a algoritmizovatelné. Problémem této metody však je, že umožňuje objevit ROV jen ve velmi omezené množině autonomních systémů, které jsou v cestě mezi oběma injektujícími body aktivního experimentu a některým z kolektorů projektů RouteViews a nebo RIS.

Jinou možností, jak získat obdobná data, avšak z mnohem větší a rozmanitější množiny bodů v síti je použít RIPE Atlas [5]. Tato síť malých a centrálně ovládaných sond umožňuje provádět aktivní měření pro výzkumné i provozní účely a jednou z funkcí, které RIPE Atlas poskytuje je vzdálené spuštění traceroute na vybraný cíl. V našem případě byl ze všech sond RIPE Atlasu spuštěn traceroute na jednu z IP adres uvnitř každého z námi injektovaných experimentálních prefixů, jak ukazuje Obrázek 2. Výsledek traceroute je sice seznam IP adres routerů, přes které přeskakují datagramy ve směru od RIPE Atlas sondy k našim bodům oznamujícím experimentální prefixy, avšak z těchto informací lze s velkou mírou jistoty odvodit cesty v BGP a tím výsledky tohoto měření převést na předchozí případ.

Obrázek 2: Použití RIPE Atlas sond pro získání dat z aktivního experimentu

Přestože se nám povedlo získat díky RIPE Atlasu data z bezmála 9000 sond, pořád tento experiment trpí omezeným rozsahem měření. Poslední krok byl naškálovat experiment do rozměrů, které umožní zobecnění výsledků s velkou mírou jistoty pro celý Internet. Pro toto zobecnění je však zapotřebí slevit z požadavku na objevení kokrétních autonomních systémů, které provádí ROV. Místo toho byla položena otázka: Jaké procento komunikace a nebo přesněji jaké procento cest v Internetu je chráněno ROV? Tato otázka umožňuje použít aktivní experiment k měření na (skoro) všechny aktivní IP adresy v Internetu tím způsobem, že se do sítě injektují dva datagramu pro každou vzdálenou adresu, jejíž zabezpečení je testováno. První bude mít zdrojovou adresou z prvního námi injektovaného prefixu a testovaná adresa bude cílovou adresou. Druhý datagram bude mít odlišnou pouze zdrojovou adresu, která bude tentokrát z druhého prefixu. V obou případech je potřeba vytvořit takový datagram, na který vzdálená adresa odpoví. Následně stačí zachytit odpovědi, které dorazí buď do AS29134 a nebo do AS378. Pokud obě odpovědi dorazí do stejného AS, nedošlo k jejich ovlivnění ROV. Pokud dorazí každá do jiného AS, je možné a nebo dokonce pravděpodobné, že je testovaná adresa chráněná. Pokud dorazí odpověď jen na jednu nebo na žádnou ze sond, je situace složitější, nicméně v některých případech stále řešitelná. Metodu ilustruje Obrázek 3. V našem případě jsme vybrali nakonec jako metodu posílání TCP segmentů navazujících spojení na HTTP servery ze seznamu 1.5 milionu nejnavštěvovanějších webů podle Alexa rankingu [7], který byl zredukován asi na polovinu, kvůli duplicitám a neodpovídajícím serverům.

Obrázek 3: Testování ochrany vzdálených sítí pomocí TCP sond

Všechny tři zhruba popsané metody akvizice dat z jednoho společného aktivního experimentu jsou přirozeně komplikovanější z hlediska postprocessingu získaných dat, protože je nutné odfiltrovat náhodné chyby při doručování datagramů přes Internet, nestandadní směrovací rozhodnutí, zejména náhodné vlivy ECMP, změny routingu v průběhu měření a další nepredikovatelné vlivy. Tyto vlivy lze odstranit statistickými úvahami a několikanásobným opakováním měření. Detaily akvizice a zpracování těchto dat jsou popsány v článku [8].

Výsledky

Hlavním výsledkem je potvrzení dlouho existující domněnky, že ROV je opravdu marginálním jevem. Validaci provádí jen několik málo sítí, zejména, akademických, výzkumných a nebo nějakým způsobem zainteresovaných na propagaci standardu RPKI. Obrázek 4 ukazuje procentuální výsledky všech tří experimentů.

Obrázek 4: Porovnání výsledků tří metod akvizice dat z aktivního experimentu

V prvním případě control plane experimentu s RouteViews a RIPE RIS experimentu byla výsledkem následující sumarizace:

  • Nevalidující autonomní systémy: 250 (84.5%)
  • Možná validace (horní hranice, autonomní systémy bez negativních výsledků): 46 (15.5%)
  • Pravděpodobně validující AS: 4 (1.35%)

V druhém případě měření pomocí RIPE Atlas sond jsme získali následující výsledky:

  • Nevalidující autonomní systémy: 2043 (97.0%)
  • Možná validace (horní hranice, autonomní systémy bez negativních výsledků): 49 (2.3%)
  • Prokázaná validace (spodní hranice): 2 (0.1%)
  • Pravděpodobně validující AS: 12 (0.5%)

V posledním případě experimentu s odraženými odpověďmi od HTTP serverů byly změřeny následující počty chráněných sítí:

  • Nechráněné adresy: 632570 (93.30%)
  • Pravděpodobně chráněné: 201 (0.03%)
  • Ochranu nelze určit: 45163 (6.66%)
Zabezpečení routingu v Internetu

Z uvedených výsledků je zřejmé, že původní domněnka o zanedbatelném nasazení ROV a tedy prakticky neexistujícím dopadu na zabezpečení Internetu je správná a lze jí považovat za prokázanou. Na druhou stranu byly objeveny a dokonce ověřeny u zodpovědných správců dva případy AS, které ROV provádějí jako součást běžného provozu AS což dokazuje, že to v současnosti je technicky i provozně možné.

Zajímavou otázku vzbuzuje pohled na graf srovnání výsledků jednotlivých metod (Obrázek 4). Podezřelá je skutečnost, že nejvíce nadějí pro ROV dává první, co do počtu otestovaných AS, nejomezenější metoda, která závisela na RouteViews a RIPE RISu. Následuje druhá metoda s RIPE Atlasem a nejhůře dopadla metoda s nejširší množinou testovaných sítí pomocí TCP sond. Vysvětlení, byť částečně spekulativní, pro tento výsledek je, že měření přes RouteViews a RIS a i přes RIPE Atlas trpí určitou pozitivní odchylkou: Sítě, které participují v těchto projektech jsou inovátoři, aktivní přispěvatelé v Internetové komunitě a pravděpodobnost, že budou testovat a nebo dokonce nasadí relativní novinku s hlubokým bezpečnostním dosahem, jakou je validace ROV, je u nich vyšší, než u zbytku běžné populace autonomních systémů v Internetu.

Důsledkem tohoto výzkumu bylo rozpracování metodiky měření ROV v Internetu, což mimo jiné doplňuje komplementární článek [9] nezávislé výzkumné skupiny, který došel odlišnými metodami k podobným procentuálním i absolutním výsledkům. Samotný výsledek neznamená pro Internetovou komunitu, proponenty technologie RPKI ani pro provozovatele sítí tragickou zprávu. Cílem experimentu bylo ověřit výchozí bod pro další výzkum, totiž že bezpečnost routingu není, navzdory existenci příslušné technologie, standardů i softwaru, uspokojivě vyřešená. Zároveň však bylo dokázáno, že RPKI je potenciální a schůdné řešení problémů, bude-li masivně nasazeno. Dopady případného nasazení ROV prozkoumal pomocí simulací článek [10] a z jeho závěry jsou pozitivní.

Odkazy

[1] https://www.ripe.net/publications/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study
[2] https://tools.ietf.org/html/rfc6480
[3] https://rpki-monitor.antd.nist.gov/
[4] http://www.routeviews.org/routeviews/
[5] https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris
[6] https://atlas.ripe.net/
[7] https://www.alexa.com/siteinfo
[8] T. Hlavacek, A. Herzberg, H. Shulman, M. Waidner „Practical Experience: Methodologies for Measuring Route Origin Validation„, DSN 2018
[9] A. Reuter, R. Bush, Í. Cunha, E. Katz-Bassett, T. C. Schmidt, M. Wählisch: „Towards a Rigorous Methodology for Measuring Adoption of RPKI Route Validation and Filtering„, ACM SIGCOMM CCR 48(1) pp. 19–27, 2018
[10] Y. Gilad, A. Cohen, A. Herzberg, M. Schapira, H. Shulman: „Are We There Yet? On RPKI’s Deployment and Security„, NDSS 2017

Kategorie:

Omezování IPv6 tunelovacích technologií

Po, 05/21/2018 - 11:37

Před několika lety ještě nebyl protokol IPv6 tak rozšířen jako dnes. Proto jsme se v červnu 2010 rozhodli zprovoznit první veřejný 6to4 relay router v České republice. V dubnu 2011 pak ještě také technologii Teredo v podobě Teredo serveru a Teredo relay routeru. V obou případech měli uživatelé, nemající nativní podporu IPv6 od svého poskytovatele internetu, možnost pomocí tunelovacích technologií získat IPv6 adresu a přístup do sítě. Současně se vzhledem k blízkosti serverů přímo v peeringovém uzlu NIX.CZ zlepšila dostupnost a kvalita spojení. Více informací o obou technologiích si můžete přečíst na našem blogu.

Provoz po IPv6 se výrazně zvyšuje a tím pádem klesá potřeba a využitelnost tunelovacích technologií. Velice výmluvné jsou níže uvedené grafy společnosti Google, které ukazují, kolik uživatelů přistupuje na jejich služby pomocí IPv6 protokolu. První graf znázorňuje postupný nárůst nativní podpory v posledních letech. Druhý pak ukazuje detail do roku 2012, kde je patrný pokles tunelovacích technologií.

Trend nárůstu nativní podpory IPv6 pozorujeme i v naší síti, aktuálně v rámci našeho AS získáváme z tranzitu přes 50000 IPv6 prefixů. Pohledem na níže uvedený graf DNS dotazů je pak IPv6 protokol zastoupen přibližně z jedné pětiny.

Dalším argumentem je také zjištění, které autonomní systémy prefixy obou technologií propagují. Tedy konkrétně prefix 2001::/32 v případě Teredo a prefixy 2002::/16 a 192.88.99.0/24 v případě 6to4. Pohledem do RIPE statistik je patrné, že prefixy těchto technologií dnes propaguje převážně Hurricane Electric (AS6939). Následují pak CZ.NIC (AS25192), TREX (AS29432), SURFNET (AS1103 a AS1101), ITGATE (AS12779) nebo NWN (AS12816).

RIPE statistiky pro Teredo

RIPE statistiky pro 6to4

Je zřejmé, že nativní podpora IPv6 protokolu roste a ve světě postupně dochází k opouštění provozu obou tunelovacích technologií jejich provozovateli. To má však paradoxně za následek, že nám narůstá provoz Teredo a 6to4 tunelů přicházející ze zahraničních konektivit. Rozhodli jsme se, že také začneme s postupným omezováním těchto technologií.

V prvním čtvrtletí 2018 jsme přestali propagovat Teredo prefix 2001::/32 do zahraničí a ponechali propagaci prefixu do peeringových uzlů NIX.CZ a NIX.SK. Pro uživatele v České a Slovenské republice, jejichž poskytovatel Internetu je připojen přímo nebo přes další subjekt do obou peeringových uzlů, to tedy neznamená žádné omezení. Zbytek uživatelů a okolní svět využijí jiné servery, s největší pravděpodobností ze sítě Hurricane Electric. Používání Teredo technologie propagované z naší sítě budeme i nadále sledovat, abychom mohli případně v budoucnu rozhodnout o jejím úplném vypnutí.

Provoz technologie 6to4 zůstává prozatím beze změny, nicméně i v tomto případě lze očekávat podobný scénář.

Kategorie:

Ve spolupráci s Nextcloudem přichází Turris MOX: Cloud, který vám vrátí kontrolu nad vašimi daty

Čt, 05/10/2018 - 11:28

S radostí oznamujeme, že jsme se spojili s Nextcloudem, abychom našim uživatelům mohli nabídnout soukromý cloud hostovaný přímo u nich doma. Turris MOX: Cloud je ready-to-go balíček s naší novou volitelnou rozšiřující deskou USB se 4 USB 3.0 vstupy, díky němuž můžete mít nepřetržitý přístup k vašim datům. Nextcloud poběží na Turrisu MOX a poskytne vám snadný přístup k vašim fotografiím, dokumentům, kalendářům a kontaktům a mnoha dalším věcem díky snadno použitelnému rozhraní pro webová a mobilní zařízení. Jako součást Turris OS 4.0 získá každý systém Turris možnost snadno spravovat externí disky a nainstalovat Nextcloud. Ve světě, kde se čím dál častěji objevují bezpečnostní hrozby a porušování soukromí, je hostování vlastních dat na důvěryhodné platformě zoufale potřeba a soukromý cloud právě to umožňuje.

S Nextcloudem platí: vaše data, vaše pravidla

Nextcloud je navržen tak, abyste mohli sami hostovat svá data, a poskytuje vám snadný přístup k vašim dokumentům prostřednictvím snadno použitelného webového rozhraní i aplikací pro Android a iOS. Soubory mohou být na discích připojených k zařízení MOX přes USB 3.0, a to i v RAID, ale také na NAS úložišti ve vaší síti nebo dostupné přes vzdálené připojení FTP nebo SAMBA.

Nextcloud je nejpopulárnější synchronizační a komunikační platforma, kterou si můžete sami hostovat. Nabízí více než 100 aplikací s dalšími funkcemi, jako je audio/video volání a chatovací server, sdílené upravování dokumentů v prohlížeči, správa hesel nebo kalendáře a úkolů a mnohem více – jediným kliknutím.

Nextcloud je 100% open source platforma podporovaná velkou komunitou nadšenců do open source softwaru, a rovněž také soukromými i veřejnými organizacemi – tito všichni spolupracují na zdokonalování Nextcloudu a každý den přidávají nové funkce.

Soukromý cloud

Společně s platformou Nextcloud vám balíček Turris MOX: Cloud nabízí snadno použitelnou platformu pro hostování vašich souborů, kalendářů a komunikace.

Balíček Turris MOX: Cloud je možné objednat na stránce kampaně na Indiegogo za 115 USD. Za tuto cenu získáte ready-to-go sadu obsahující Turris MOX: Start, rozšíření o 4 porty USB 3.0 a navýšení na 1 GB RAM za speciální sníženou cenu!

Nextcloud se nebude omezovat pouze na Turris MOX: Cloud. Budou ho podporovat všechny MOXy (a Omnie), nicméně pro dobrý výkon je nutný 1GB RAM. Už v prvních dodaných MOXech bude ve webovém rozhraní integrována jednoduchá stránka, která umožňuje uživatelům nakonfigurovat externí úložiště a povolit Nextcloud. Pro zajištění určitého stupně ochrany dat bude rozhraní také podporovat nastavení RAID tak, aby poškození jednoho disku neznamenalo okamžitou ztrátu dat.

Kategorie:

A jdeme do finále!

Čt, 05/10/2018 - 06:15

Za týden by měla skončit naše druhá crownfundingová kampaň na routery projektu Turris. Ta první na Turris Omnia skončila fenomenálním úspěchem. Tehdy jsme si jako cílovou částku zvolili 100 tisíc amerických dolarů. A za 60 dnů jsme vybrali neuvěřitelných 875 tisíc dolarů, což byla a stále je druhá nejvyšší částka vybraná v českých kampaních. Proto jsme si říkali, že v případě MOXu se rozhodně nemůžeme držet příliš při zemi, abychom zůstali důvěryhodní. Nakonec jsme zvolili cíl 250 tisíc dolarů, což sice vypadá v porovnání s Omnií jako nízké číslo, ale ve skutečnosti jde o částku poměrně ambiciozní. Tato kampaň se liší ve dvou hlavních parametrech:

1. Doba kampaně je 45 dnů, u Omnie to bylo 60 dnů
2. Nejlevnější „perk“ u Omnie byl za 99 dolarů, u MOXu to je 29 dolarů

Pokud bychom to tedy počítali čistě jednoduše početně, pak 857 * (45/60) * (29/99) = 188. Ale to je pochopitelně příliš zjednodušující. Záleží přirozeně i na dalších „percích“ a kampaň na MOXe měla i krátkou neveřejnou předkampaň, nicméně to myslím jasně ilustruje, že dosáhnout tohoto cíle není nic jednoduchého.

V tomto okamžiku máme již přes 60 % vybrané částky. To zdánlivě nezní příliš optimisticky, nicméně opět si můžeme udělat srovnání s kampaní Omnie. Jeden týden před koncem kampaně bylo vybráno 56 % částky. Každá kampaň je ale jiná a tak pevně věřím, že tímto příspěvkem neodradím naše potenciální podporovatele. Ceny, za které jsou jednotlivé díly a sestavy nabízené, jsou skutečně nízké a v komerčním prodeji rozhodně půjde o vyšší částky.

Byla by to samozřejmě veliká škoda, pokud by tento unikátní produkt nevznikl a projekt Turris tak přišel o část financování. Tak tedy pojďte prosím s námi do finále, ať první modulární SOHO router vznikne!

Kategorie:

Děti a Internet: bezpečná symbióza či nikoli?

Po, 05/07/2018 - 08:38

Ve dnech 18. a 19. dubna 2018 se sdružení CZ.NIC zúčastnilo akce s názvem EMEA Child Safety Summit pod záštitou společností Facebook a Google.

Na konferenci zaznělo mnoho příznivých zpráv o tom, jak se tyto dvě nadnárodní společnosti snaží co nejvíce informovat děti a jejich rodiče o nástrahách v on-line prostředí pomocí různých programů, mezinárodních spolků a aplikací. Člověk tedy snadno mohl nabýt dojmu, že na Internetu vlastně nehrozí žádné nebezpečí, že Facebook i Google se o bezpečí našich dětí postarají a že spolu s nimi vše zvládneme. To vše sice zní moc hezky, ale je potřeba vrátit se do reality a být stále na pozoru, jelikož nástrah v kyberprostoru stále přibývá a jsou čím dál tím více promyšlené.

I statistické údaje, které zde byly prezentovány, nasvědčují tomu, že novodobý trend je jasný, 90 % dětí ve věku od 6 do 12 let má volný přístup k tabletům a chytrým telefonům. Vychází to z průzkumu provedeného ve Velké Británii. 2 ze 3 dětí v tomto věku mají svůj vlastní aparát a 2 ze 3 dětí jej používají každý den.

Jelikož mám ráda grafy, vyhledala jsem si na Internetu studii vydanou v říjnu minulého roku profesorkou Soniou Livingstone z LSE (London School of Economics and Political Science), kde jsou zmíněna zajímavá fakta a trendy poslední dekády. Níže uvedený graf vydala ve své zprávě telekomunikační společnost Ofcom. Graf znázorňuje odhadovaný počet hodin strávených na Internetu (doma či jinde) dle věku dítěte. Je zajímavé vidět, že děti ve věku od 5 do 15 let čas strávený na mobilních přístrojích v roce 2017 téměř zdvojnásobily oproti údajům z roku 2007.

Dále mě v této zprávě zaujal graf z roku 2017, který znázorňuje, kolik procent dětí ve věku od 3 do 15 let vlastní chytrý telefon či tablet. Zatímco ve věku 10 let převládá vlastnictví tabletu, v 11 letech používají děti spíše chytrý telefon.

Poslední graf, který jsem vybrala, se týká činností, jenž děti ve věku 7 – 16 let nejčastěji na Internetu provozují. Zdrojem je tentokrát výzkumná zpráva agentury CHILDWISE z roku 2017. Pro děti ve věku 7 – 8 let je typické, že používají Internet za účelem hraní her a pouštění videí a děti ve věku 15 – 16 let zde poslouchají hudbu a komunikují prostřednictvím sociálních sítí.

Stále se tedy ještě najde určité procento rodičů, kteří se snaží střet svých dětí s on-line světem co nejvíce oddálit, ale je třeba konstatovat, že takovéto děti jsou z pohledu svých vrstevníků trochu „out“. Mnohem jednodušší asi je se s tímto trendem smířit a jít ruku v ruce s novými technologiemi, které již rodičům umožňují kontrolu nad tím, co jejich děti na mobilu či tabletu dělají. Pokud jim odmalička budeme do hlavy vštěpovat zásady bezpečného chování na Internetu a nenecháme je topit se ve víru virtuální reality, který je dost silný na to, aby jim ublížil, nemusíme mít o své potomky obavy.

Na konferenci mě zaujala prezentace aplikace Family Link, prostřednictvím které může rodič svému dítěti zřídit účet na Googlu (mladšímu 13 let) a nastavit zde parametry dle specifických přání a zvyklostí dané rodiny, např. v jakém časovém rozmezí může dítě mobilní zařízení využívat, jaké dny v týdnu, maximální denní časový limit. Dále je možné zablokovat dítěti některé funkcionality. Při zřizování účtu je rodič vyzván k zaplacení symbolické částky, aby si mohl Google dle majitele bankovního účtu/platební karty ověřit, zda je skutečně rodičem dítěte, jemuž je účet zřizován. Vybrané peníze jsou pak věnovány organizaci na ochranu dětí.

Dále zde zazněla zajímavá rada, což se hodí zmínit právě na závěr tohoto blogu, že bychom se měli naučit naslouchat svým dětem a přijímat od nich informace z on-line světa. Nejen, že tak upevníme vzájemný vztah, ale obě strany si odneseme mnohdy velice cenné poznatky a zkušenosti. Přeci jen dnešní mládež se často orientuje ve virtuálním světe lépe než my a zná od svých vrstevníků jisté triky, které nám zůstávají utajeny.

Kategorie:

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

Po, 04/23/2018 - 10:33

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 prvním a druhém díle seriálu o upgrade DNS infrastruktury jsem představil koncept DNS stacků a první implementaci ISP DNS stacků u poskytovatelů internetového připojení. Dnešní díl se zaměří na jednu z časově nejnáročnějších částí celé realizace – výběrová řízení na 100GE router, switche, servery a jejich následnou logistiku do datacentra.

Výběrová řízení a nákupy hardware

Výběrová řízení jsme rozdělili na dvě skupiny. První na dodávku routerů a management switchů, druhou na dodávku serverů. Poptávali jsme tedy 100GE router pro Velký DNS stack, 2 managementswitche a celkem 31 serverů.

Dodavatelům jsme zaslali seznam požadovaných technických parametrů a pro obě výběrová řízení jsme předem stanovili stejná hodnotící kritéria.

Celkem jsme stanovili 11 hodnotících kritérií, např. cena a cena za support, splnění technických parametrů, rozsah a kvalita supportu, reference, dopad na provozní náklady apod. Ke každému kritériu jsme vyplnili hodnoty 1-5, jako ve škole, kdy 1 je nejlepší. Současně každé kritérium mělo stanovenou váhu v procentech tak, aby celkový součet všech vah byl 100 %.

Nejvyšší váha nebyla stanovena k ceně, ale k technickým parametrům. Pro jejich vyhodnocení jsme měli připravenou ještě další tabulku, která obsahovala jednotlivé parametry a také jejich váhu v rozmezí 1 až 4, která určovala jejich důležitost. Ke každé položce jsme vždy vyplnili buď „1 – splňuje zadání“ nebo „0 – nesplňuje zadání“. Nakonec se na základě váhy vypočítal celkový součet a převedl na známku 1-5, pro doplnění do hlavní hodnotící tabulky. V případě routerů jsme takto hodnotili 21 technických parametrů.

Všechny dodavatele jsme vyzvali do stanoveného data k zaslání nabídek, následně byl prostor k osobním prezentacím navrženého řešení a další konzultace.

Routery

Oslovili jsme 5 dodavatelů, řazeno abecedně:

Alcatel-Lucent Czech s.r.o. (Alcatel-Lucent/Nokia), Alef Nula a.s. (Cisco), Comguard s.r.o. (Brocade), Comsource s.r.o. (Juniper), Huatech a.s. (Huawei).

Hlavními požadovanými technickými parametry routerů byly:

Plná podpora IPv4+IPv6, IRB, OSPFv2/v3, L3 subinterface, ACL aplikované na L3 porty, subinterface a IRB, BGP dle RFC, NetFlow9/IPFIX, PPS – linerate kapacita fyz. rozhraní nezávislá na velikosti ethernetového rámce a linerate kapacita při filtrování. Dále ECMP s podporou minimálně 32 cest, transceivery QSFP28 pro 100GE a SFP+ pro 10GE (případně ekvivalentní), redundantní Control Plane, oddělený Forwarding Plane a podporu ISSU.

Vzhledem k uvažovanému počtu serverů měl 100GE router obsahovat alespoň 2 100Gb porty a alespoň 34 10Gb portů.

Obdrželi jsme nabídky těchto 100GE routerů:

  • Nokia 7750 SR-7,

  • Cisco ASR9904,

    • varianta č.1 s tzv. „rozpletem“ z 100Gb portů na 10Gb porty,

    • varianta č. 2 s požadovaným počtem 10Gb portů,

  • Brocade MLXe-4,

  • Juniper MX240 ve variantě s tzv. „rozpletem“ z 40Gb portů na 10Gb porty,

  • Huawei NE40-X3A.

V užším výběru jsme se rozhodovali mezi routery Cisco ASR9904 ve variantě č. 2 a Juniper MX240. Oba routery nejlépe splňovali naše kritéria, hlavní rozdíl mezi nimi byl v použití tzv. „rozpletu“ 40Gb portů na 4x10Gb v případě Juniperu a ve velikosti U. Router MX240 zabírá 5U, kdežto ASR9904 o jedno U více.

Vítězem se stal router Juniper MX240 díky nižší ceně a také kvůli velikosti. Velikost 5U nebo 6U není na první pohled zásadním kritériem. Potřebovali jsme do 42U racku umístit 31 serverů, dva switche, ODF a mít prostor i na vedení kabeláže. Router o velikosti 5U byla v tomto případě optimální varianta.

Díky výběrovému řízení jsme získali přijatelné podmínky pro obě řešení, které nejlépe splňovala naše kritéria. I v tomto projektu dbáme na dodržení diverzity HW a je tedy možné, že plánovaný druhý Velký DNS stack bude realizován právě s routerem ASR9904 v revidované konfiguraci.

Management switche

Management switche byly poptávány společně s routery. Hlavními požadovanými technickými parametry management switchů byly:

Velikost 1U, přenosová rychlost 10Gb, 48 1Gb portů a 4 10Gb porty, redundantní zdroje a back-to-front air flow.

Tyto technické parametry nejsou v ničem specifické nebo neobvyklé, všichni dodavatelé nabídli velice srovnatelné modely.

Jednalo se o:

  • Nokia 7210 48T,

  • Nexus 3048TP-1GE,

  • Brocade ICX7450-48,

  • Juniper EX3400-48T-AFI,

  • Huawei CloudEngine 5800 TOR.

Vzhledem k výběru routeru od Juniper bylo logickým krokem zvolit switche od stejného dodavatele. Vybrali jsme tedy switche Juniper EX3400-48T-AFI.

Servery

V případě serverů jsme oslovili 4 dodavatele, řazeno abecedně:

Abacus (SuperMicro), Autocont (DELL), Hewlett Packard Enterprise (HPE) a Tecom (Intel).

Hlavními požadovanými technickými parametry serverů byly:

Velikost serveru 1U s 2,5“ disky, redundantní zdroje, HW diskový řadič s cache, Intel platforma, support next business day, remote management s podporou HTML5 nebo Java a 10G SFP+ síťové karty Intel řady X710. Tyto karty jsme vybrali na základě zkušeností kolegů z vývojového týmu Knot DNS a jejich provedených výkonnostních testů (viz https://www.knot-dns.cz/benchmark/).

Všichni dodavatelé serverů nabídli velice srovnatelné parametry a komponenty, rozhodovali jsme se primárně na základě ceny. Vybrali jsme servery DELL, konkrétně v provedení PowerEdge R430.

Dodání a uskladnění HW

Doručit a dočasně uskladnit jeden router a dva switche pro prvotní konfiguraci před umístěním v datacentru není žádný problém. Ale 31 serverů? Jeden zabalený server má přibližné rozměry 85x60x25 cm a váží přibližně 20kg. Pokud bychom si je nechali všechny doručit na naší adresu, zaplnili bychom tak podstatnou část našeho skladu a komplikovaně bychom je poté převáželi do datacentra. Nejvhodnější bylo tedy doručit servery přímo do datacentra, kde jsme domluvili vlastní uzamykatelnou místnost nedaleko nájezdové rampy do sálu a dodavatele požádali o doručení přímo do datacentra.

Neobešlo se to však bez menších komplikací. Dodávka všech serverů byla rozdělena na 3 části a doručována ve třech dnech, z toho jednou chybně na naší adresu. Naštěstí se datacentrum, ve kterém jsme se rozhodli první Velký DNS stack zprovoznit, nachází nedaleko a kurýr ochotně servery převezl.

V dalších dílech se můžete těšit na zkušenosti s přípravou zázemí v datacentru a uvedením do provozu.

4. díl: První Velký stack – příprava zázemí
5. díl: První Velký stack – instalace, testování a nasazení do provozu
6. díl: První Velký stack – závěr a zkušenosti z provozu

Kategorie:

O nenávisti se nám mlčet nechce

St, 04/11/2018 - 12:53

Jistě všichni víte, že už je to nějaký čas, kdy jsme měli tu čest a přivítali jsme v našem sdružení Patricka Zandla. Patrick má na starosti rozvoj Turrisu. To, že se podílí na tak skvělém projektu mu ale možná nestačí; cítí, podobně jako většina zaměstnanců našeho sdružení, že kromě rozvoje technologií je potřeba pracovat i na rozvoji společenské odpovědnosti.

Není tedy příliš velkým překvapením, že se Patrick rozhodl vystoupit z řady přihlížející většiny ve chvíli, kdy se dozvěděl o neuvěřitelně bezohledném a slušně řečeno hrozném chování, mnoha lidí v české společnosti. Nebo už mu spíš nic jiného nezbylo, protože nikdo jiný nic neudělal.

V listopadu na sociální síti Facebook došlo k veřejnému napadání a urážení dětí, které gradovalo do opravdu neuvěřitelných rozměrů. Patrick o tom napsal článek, ve kterém současně vyzval čtenáře k finanční podpoře školy, které se veřejné urážky a napadání týkaly. Článku předcházela sbírka, kterou Patrick uspořádal z toho důvodu, aby škola skutečně viděla, že na tolik nenávisti opravdu nejsou sami. Ve sbírce se Patrickovi podařilo vybrat více než půl milionu korun a to hlavně a především od jeho známých a přátel.

Ve svém článku, který byl zároveň výzvou k veřejné sbírce Patrick napsal: „Je čas si to říct na rovinu. Když vidíme zlo a mlčíme, jsme sami součást zla. Udělat jen to málo jako říct „je hnus navážet se do dětí, natož jim přát plyn“ snad nevyžaduje velkou osobní oběť. Stále snad jsme země, kde se smí ohrožování dětí odsoudit. Proč jsme to teda neudělali? Já původně pod dojmem své nevýznamnosti. Co koho zajímá můj pohled. Ale včera mi došlo, že čekám marně na to, až se dětí zastane někdo významnější. A tak jsem do té školy napsal s pár slovy podpory a otázkou, zda pro ně mohu něco udělat. Na něčem jsme se dohodli nebo dohodneme, to zařídím. Vás potřebuju na to, abych věděl, že nejsem sám. A ty děti a učitelé vás potřebují.“

Jak Patrick řekl, tak učinil. Vybrané děti jsme díky aktivitě a ochotě zaměstnanců školy, pozvali k nám na exkursi, kde se mohly dozvědět o tom, jak si lépe ochránit své zařízení před škodlivými kódy, jak bezpečně a zodpovědně zacházet se svými osobními údaji, jak se vyhnout podvodům na Internetu nebo proč je důležité mít zabezpečený router.

S ohledem na rozšíření naší základny, měly děti možnost navštívit naše nové prostory v Hotelu Olšanka, kde se konala právě zmíněná přednáška. Po obědě jsme se přesunuli do našeho hlavního sídla kousek od náměstí Jiřího z Poděbrad. Tady měly děti možnost vidět práci odborníků v praxi. Díky krásné náhodě, tiskl zrovna Lukáš, jeden z našich kolegů, náhradní díly na 3D tiskárnu, návštěva dětí ho vůbec nepřekvapila a naopak přidal ke své práci poutavé povídání, ze kterého se děti dozvěděly nejen o tom, jak 3D tiskárny fungují, co všechno se s nimi dá dělat, ale i kolik stojí, když si koupí tiskárnu již hotovou a jak moc ušetří, když si jí budou umět poskládat sami :-).

Další oddělení, které děti navštívily, byl vývoj hardware našeho Turrisu. Tady byly seznámeny s tím, jak probíhá proces výroby routeru – Zbyněk s Tomášem jim stručně popsali proces vývoje od samého výběru součástek, návrhu schématu desky plošných spojů, přes výrobu až po osazení a ověření funkčnosti. Krásným zakončením dne byla informace od jednoho z žáků o jeho rozhodnutí jít studovat některý z technických oborů.

Díky Patrickovi a aktivnímu přístupu zaměstnanců školy jsme měli možnost ukázat dětem nejen pražskou základnu našeho sdružení, ale hlavně a především i to, že veřejné napadání, urážení, výsměch a nenávist jsou výsadou pouze omezené skupiny obyvatel, nikoli normou.

Kategorie:

Děti v akci aneb Jak se hraje kybernetické pexeso v DDM Praha 9

Út, 04/10/2018 - 15:25

Již delší dobu mě zajímalo, jak vnímají samy děti hru kybernetické pexeso, které vydalo sdružení CZ.NIC v rámci projektu Safer Internet na podzim loňského roku. Proto jsem se vydala druhý jarní den do Domu dětí a mládeže na Praze 9, na pobočku Černý Most, abych mohla sledovat, jak se děti ke hře kyberpexesa staví a jak je baví.

Pexeso je zaměřeno na hráče přibližně ve věku 9 – 14 let. Navštívila jsem tedy dva kroužky angličtiny (pro 4. – 5. třídu, pro 6. – 7. třídu). Nejprve jsem děti vyzpovídala, co na mobilu, tabletu či počítači nejraději dělají. Nepřekvapilo mě, že nejčastěji hrají hry, sledují sociální sítě nebo „chatují“ s kamarády. Poté se malí studenti angličtiny pustili do hry.

V průběhu hry se děti seznamovaly s novými pojmy z oblasti kybernetické bezpečnosti. Některé z nich je velice zaujaly jako např. anonymní okno, honeypot či zombie. Dále jsme diskutovali nad termíny, které byly některým dětem více známy jako např. virus, spam nebo řetězový dopis. Velmi mě však překvapila poměrně dobrá informovanost mladších žáků o pojmech, jenž jsou i mnoha dospělým dosud neznámé, a to grooming a sexting. Vzhledem k tomu, že děti velmi rády „chatují“, ať už v rámci řešení strategické hry nebo např. v diskuzi ohledně péče o domácí mazlíčky, je zde skutečně velké riziko, že v tomto virtuálním světě potkají „spřízněnou duši“, která pro ně ve finále znamená velké nebezpečí.

Líbilo se mi, že děti tématika kybernetické bezpečnosti zaujala a samy chtěly o jednotlivých rizicích diskutovat. I přestože si některými z nich nebyly jistí, pokusily se alespoň odhadnout jejich význam. Samy dokonce aktivně zmiňovaly konkrétní případy ze svého okolí, kdy někdo z kamarádů či rodičů čelil kybernetickému útoku. Na závěr jsme se dostali k tématu závislosti na mobilu – nomofobii (též jedna z kartiček pexesa). Starší žáci potvrdili, že na svém chytrém telefonu skutečně tráví poměrně hodně času a připustili jistou míru závislosti.

Na závěr bych ráda uvedla, že osvěty v oblasti kyberbezpečnosti není nikdy dost, zvlášť pokud se jedná o malé děti, které jsou ještě dosti zranitelné a s řešením problému si často nevědí rady. Kolegové Pavel Bašta, Věrka Mikušová, Jirka Průša a Katka Vokrouhlíková pořádají na toto téma pravidelná školení a přednášky, kdy žákům formou praktických příkladů představují hrozby na Internetu a radí jim, jak se jich vyvarovat, případně jak je co nejlépe řešit.

S Domem dětí a mládeže na Praze 9 již spolupracujeme druhým rokem, a to primárně na organizaci letního kybertábora.

Kategorie:

Knot Resolver & soukromí

Po, 04/09/2018 - 13:06

Na apríla firma Cloudflare zcela vážně oznámila světu novinku, že vstupuje na trh rekurzivních DNS serverů a začíná tak konkurovat Google Public DNS. Velmi náš těší, že Cloudflare se rozhodl nasadit právě náš Knot Resolver, který v CZ.NIC vyvíjíme od roku 2014. Text veřejného oznámení velmi stručně vyjmenovává funkce Knot Resolveru, které Cloudflare nabízí veřejnosti.

Co jednotlivé funkce prakticky znamenají? A proč je pro uživatele dobře, že Cloudflare vybral právě náš Knot Resolver? Implementuje totiž tři funkce, které zlepšují soukromí uživatelů. Jmenovitě jde o:

  • DNS-over-TLS (Transport Layer Security) RFC 7858,
  • Query Minimization RFC 7816,
  • Aggressive Use of DNSSEC-Validated Cache RFC 8198.

Podívejme se, jak jednotlivé funkce zlepšují soukromí uživatelů, a jak je můžete použít i vy na vašem resolveru.

DNS-over-TLS (RFC 7858)

DNS protokol tak, jak byl před 30 lety navržen, posílá dotazy otevřeně pomocí UDP a TCP protokolů na portu 53, takže kdokoliv, kdo má schopnost sledovat provoz na síti, také vidí všechny DNS dotazy od klienta (tj. vás) k resolveru. Z DNS dotazů se tak např. dozví i jména všech webů, které klient navštěvuje, a to i v případě, že weby samotné jsou zabezpečeny pomocí HTTPS.

Funkce DNS-over-TLS (standard RFC 7858) zabezpečuje DNS provoz pomocí Transport Layer Security protokolu známého zkráceně jako TLS. Díky tomu je provoz mezi klientem a resolverem šifrovaný, díky čemuž „pozorovatel“ na síti nevidí dovnitř DNS dotazů, které klient posílá.

Díky použití DNS-over-TLS je dotaz „viditelný“ na síti jen od resolveru dál. V praxi to znamená, že na dostatečně velkém resolveru se prokládají dotazy od různých klientů, což ztěžuje zpětné přiřazování klient-dotaz.

Pokud chcete, můžete svůj Knot Resolver nakonfigurovat tak, aby posílal všechny DNS dotazy na resolver provozovaný Cloudflarem. Taková konfigurace vás ochrání před útočníky, kteří sledují provoz vycházející z vaší sítě. Samozřejmě to vyžaduje, abyste věřili firmě Cloudflare. Doporučujeme vám přečíst si Cloudflare resolver privacy notice.

Stačí do konfigurace vložit následující řádky:

policy.add(policy.all(policy.TLS_FORWARD({{ '1.1.1.1' hostname='cloudflare-dns.com', ca_file='/etc/pki/tls/certs/ca-bundle.crt' }})))

Nezapomeňte upravit cestu /etc/pki/tls/certs/ca-bundle.crt tak, aby ukazovala na váš systémový soubor s důvěryhodnými certifikáty.

Tímto nastavením jsme skryli provoz mezi klientem (vámi) a resolverem.

Query Minimization (RFC 7816)

Účelem této funkce je omezit „únik“ informací o jménech, na které se resolveru klient ptá, a tím pádem i zvýšit soukromí uživatelů daného resolveru. Jinými slovy omezuje informace, které „unikají z resolveru“ během jeho normální funkce.

Podle prapůvodního standardu DNS RFC 1034 se resolver vždy ptal na celé jméno tak, jak jej dostal v požadavku od klienta, např. www.example.com. To prakticky znamenalo, že informace o tom, které weby uživatel navštěvuje, se v podobě DNS dotazů dostala ke všem serverům, které resolver při řešení požadavku kontaktoval. Můžeme si to představit takto:

  • dotaz www.example.com. → root autoritativní server (zóna.)
  • dotaz www.example.com. → TLD autoritativní server (zóna com.)
  • dotaz www.example.com. → autoritativní server provozovatele (zóna example.com.)

V našem příkladu se tedy informace o tom, že uživatel s konkrétní IP adresou chce navštívit web www.example.com. dostala nejen k root serverům (odpovědným za kořenovou zónu .), ale i TLD serverům (odpovědným např. za zónu cz.). Samozřejmě, že na čím víc míst je dotaz odeslán, tím větší je šance, že bude někde zaznamenán a použit.

Název funkce Query Minimization (experimentální standard RFC 7816) by se do češtiny dal volně přeložit jako „zmenšení dotazů“. Spočítá v tom, že resolver posílá autoritativním serverům nejmenší možné množství informací, např. takto:

  • dotaz com. → root autoritativní server (zóna .)
  • dotaz example.com. → TLD autoritativní server (zóna com.)
  • dotaz www.example.com. → autoritativní server provozovatele (zóna example.com.)

Tím se zmenšuje počet míst, kam je dotaz odeslán, a tím i počet míst, kde může být zaznamenán. Knot Resolver provádí „zmenšení dotazů“ automaticky, takže je i vaše soukromí automaticky chráněno.

Aggressive Use of DNSSEC-Validated Cache (RFC 8198)

Poslední zmíněnou funkci můžeme česky nazvat „agresivní použití DNSSEC keše/mezipaměti“. Detailně se jí budeme zabývat v samostatném článku, takže ji zde popíšeme jen velmi obecně. Musíme však začít základní teorií:

Důkazy v DNSSEC

Základní vlastností technologie zabezpečení DNSSEC je, že klient, který se zeptal na neexistující informaci, dostane zpět tzv. „důkaz neexistence“. Tím se zabezpečuje, že zpráva o neexistenci informace nemůže být podvržena. Takový důkaz vypadá (zjednodušeně!) takto:

ananas.example. NSEC pomelo.example. RRSIG NSEC (kryptografický podpis)

Tím je vyjádřeno, že existují jména ananas.example. a pomelo.example., a že mezi těmito jmény neexistuje žádné jiné.

Například si představme, že klient se ptá na jablko.example. a dostane zpět uvedený důkaz neexistence. Pro ověření, že jméno opravdu neexistuje klient napřed ověří podpis důkazu (RRSIG záznam), a potom se podívá, zda jméno, na které se ptá, leží uvnitř intervalu uvedeném v důkazu. Když seřadíme jména z důkazu a dotazu abecedně, tak dostaneme následující pořadí:

ananas.example. jablko.example. pomelo.example.

Jméno „jablko“ tedy leží mezi jmény ananas a pomelo, takže důkaz opravdu říká, že jablko neexistuje. Tolik k základní teorii důkazů neexistence v DNSSEC. Co tedy znamená „agresivní použití“?

Agresivní použití důkazů

Dříve se resolver pro každý dotaz, pro který neměl ve své cache odpověď, musel znovu zeptat autoritativního serveru. Pokud se tedy klient zeptá na jména jablko.example., banan.example. a mandarinka.example., resolver třikrát pošle dotaz na autoritativní server.

Implementace RFC 8198 nám dovoluje použít DNSSEC důkazy v cache resolveru pro omezení dotazů směrem k autoritativním serverům. V našem ovocném příkladu by se resolver zeptal autoritativního serveru pouze na jablko.example. a následující dotazy banan.example., mandarinka.example. už resolver odpoví přímo ze své cache, tj. informace z dotazu se nedostane k autoritativnímu serveru. To zlepšuje rychlost odezvy a snižuje zátěž jak resolveru, tak autoritativního serveru a zvyšuje odolnost proti některým typům útoků na DNS. Teď se ale zaměřme na vliv na soukromí.

V praxi je velké procento dotazů nesmyslných, způsobených chybnou konfigurací klientů. Například velmi často lokální síť s výchozí konfigurací DHCP konfiguruje klientské systémy tak, že za jméno počítače přidávají neexistující domény jako lan., home. apod. Klienti v důsledku pak generují dotazy jako pepuv-laptop.lan., josef1975.lan nebo ještě hůře unikátní jméno vygenerované při instalaci počítače jako desktop-A8F2C938FA1F.. Unikátní jména pak lze použít ke stopování uživatelů. S pomocí agresivní cache však jednou resolver získá informaci o tom, že neexistuje doména lan. a pak se už znovu neptá, a tím se únik informací zastaven.

Dobrá zpráva je, že Knot Resolver od verze 2.0 automaticky používá agresivní cache a tím zamezuje úniku informací. Doporučujeme tedy aktualizovat na poslední verzi resolveru!

Kategorie: