Síťové sekci konference Intel European Research and Innovation Conference 2013 (program) jednoznačně vévodily dvě zkratky: SDN (Software Defined Networking) a NFV (Network Functions Virtualization). O SDN jsem už na tomto místě psal a na další příspěvek se chystám v souvislosti s účastí CZ.NIC v FP7 projektu NetIDE.
O virtualizaci síťových funkcí přednášeli především zástupci velkých telekomunikačních operátorů (Telefónica, Verizon) a firem, které jim navrhují infrastrukturu a dodávají služby. Mně osobně daly jejich příspěvky možnost nahlédnout pod pokličku sítí 4G LTE, o nichž, přiznám se, jsem toho dosud mnoho nevěděl. Ne že bych byl teď o mnoho moudřejší, ale jeden základní dojem jsem si přece jenom odnesl – tyhle sítě jsou v porovnání se standardním Internetem pekelně složité. Už jen ta záplava zkratek, namátkou: OSS, BSS, HSS, MME, PCRF, OTT, BRAS, SGSN, GGSN, VAS … Virtualizace je pak celkem pochopitelně jednou z cest, jak tento moloch zvládnout.
Přemýšlel jsem o tom, kde se ta složitost vlastně bere. Zčásti jde jistě na vrub známých nedostatků v reálném Internetu, jakými jsou třeba nefungující multicast či chabá podpora mobility. Hlubším důvodem je ale podle mého známý end-to-end princip, na němž jsou protokoly TCP/IP postaveny, tedy v podstatě hloupá a ne zcela spolehlivá síť, jež funguje díky tomu, že pokročilejší funkce jsou soustředěny v koncových stanicích. Je jasné, že v takové best-effort síti je obtížné nabízet zákazníkům diferencované služby a podle toho je pak také kasírovat.
Když tedy technologičtí experti předestírají vize budoucího Internetu jakožto sítě chytrých telefonů a jiných mobilních zařízení, musíme si uvědomit, že se nejedná jen o osvobození od kabelů, ale dost možná taky o podstatné změny v architektuře globální sítě – bude to vlastně ještě Internet, jak jej dnes známe?
Ladislav Lhotka
Nový projekt: DNS Collector sbírá a analyzuje provoz v DNS
Primární účel DNS (Domain Name System) je zprostředkovat překlad doménových jmen na adresy v síti. Ve zjednodušené formě – klient generuje dotazy a server poskytuje odpovědi. Jako takový tvoří DNS jednu z důležitých služeb v IP sítích. Ve většině případů začíná komunikace na internetu právě DNS dotazem. Stopy této komunikace lze nalézt na různých úrovních DNS hierarchie. Analýzou těchto stop (DNS dotazů) lze získat užitečné informace o stavu sítě a chování jejích uživatelů.
Sběr DNS dat
DNS provoz je potřeba extrahovat z celkového síťového provozu. Převážná část DNS provozu je přenášena nefragmentovanými UDP pakety. Abychom získali pokud možno celistvý pohled na přenášená data, je nutné u zbylého provozu provést defragmentaci paketů a provést rekonstrukci TCP spojení. Je také nutné se vypořádat s poškozenými pakety nebo nedokončenými datovými přenosy.
V DNS provozu na serverech obsluhujících .cz TLD převládá síťový protokol IPv4. V závislosti na objemu provozu a umístění serveru se jeho zastoupení pohybuje kolem 90 %. Výjimku tvoří server akuma, umístěný v Japonsku, u kterého je poměr IPv4/IPv6 převrácený. Na transportní vrstvě dominuje UDP.
Aplikace DNS Collector zjednodušuje zpracování DNS provozu tím, že je schopna poslouchat provoz na několika síťových rozhraních současně. V současné době k tomu využívá knihovnu libpcap. Zachycený síťový provoz je defragmentován. V případě TCP provozu je sledováno správné ustanovení a ukončení TCP relace. Přerušená TCP spojení nebo neúplné pakety jsou po čase zahozeny. Zrekonstruované surové (tak jak jsou přenášené po síti) DNS pakety jsou v závislosti na použité síťové a transportní vrstvě opatřeny daty z IPv4/IPv6 a UDP/TCP hlaviček. Takto připravená data jsou předána ke zpracování do modulů.
DNS Collector umožňuje zpracovávat také archivovaný provoz uložený v souborech na disku (ve formátu podporovaném knihovnou libpcap). V tom případě pak ale není možné současně zpracovávat archivovaný provoz s živým provozem ze síťových rozhraní. V současné době také není také možné zpracovávat více archivů (souborů) současně, protože doposud nebyl implementován mechanismus řazení paketů podle časových značek uložených v souborech. V případě, že je potřeba zpracovat více archivů současně, je nutné použít externí aplikaci jako je například mergecap nebo PCAPMerger.
Zpracování provozu v modulech
Modul je funkční jednotka, která se zabývá zpracováním surových DNS dat. Tyto data mu připravuje DNS Collector způsobem zmíněným v předcházející části. Moduly představují funkční abstrakci, umožňující izolovat jednotlivé činnosti nad DNS daty. Moduly si udržují vlastní kontexty, mohou tedy pracovat nezávisle na ostatních modulech.
Moduly lze nahrávat nebo uvolňovat za běhu celé aplikace. V porovnání se samostatnými aplikacemi provádějícími ekvivalentní činnost mají moduly výhodu menší režie. Všechny moduly totiž společně sdílí společnou vrstvu, která se stará o přípravu vstupních dat. Tato vrstva by v případě samostatných procesů musela existovat ve všech procesech.
DNS Collector neposkytuje žádné rozhraní pro parsování surových DNS dat. V závislosti na povaze zpracovávaných dat je možné implementovat vlastní jednoduchý parser DNS paketu, nebo v případě složitějších operací použít některou z existujících knihoven, jako je například ldns.
Detektor anomálií
Tento modul vychází ze samostatného projektu detektoru DNS anomálií. Původní samostatná aplikace prováděla statistickou analýzu části DNS provozu, která byla dostupná v úplných UDP paketech. Na základě vzájemné podobnosti zjištěných vzorů pak posuzovala, zda je provoz „normální“. Je nutné upozornit, že se jedná o hodnocení ve smyslu: normální je převažující chování. V tomto smyslu anomálie nemusí být nutně škodlivé, pouze se něčím vymykají charakteristice většiny. Díky použití v DNS Collectoru je možné zpracovávat data pocházející z fragmentovaných paketů a dat přenášených přes TCP.
Výstupem tohoto modulu je textové hlášení o detekovaných anomálních identifikátorech. Volitelným výstupem jsou soubory vykreslující výskyt detekovaných anomálií ve formátu vhodném pro zpracování gnuplotem.
Na následujících obrázcích je ukázka několika typů detekovaných anomálií. Data byla zachytávána a analyzována v desetiminutových intervalech 1. října na serveru dns-b-01. Grafy zobrazují zastoupení anomálního provozu v poměru k celkovém provozu. IP adresy jsou záměrně nahrazeny.
Na grafech je zobrazeno zastoupení provozu označeného jako anomální:
IP A – hromadné rozesílání emailů, provoz obsahuje dotazy na MX a adresy mailserverů
IP B – opakovaný dotaz se stejným ID v krátkém intervalu (300x během 2ms)
IP C, D, F, G – rekurzivní resolvery
IP E – DKIM spam-filter
IP H – opakované dotazy na adresy tří nameserverů, postupně se zvyšující ID dotazů
Spouštění skriptů v Pythonu
Ne každá analýza si zaslouží samostatný modul psaný v C. V případech, kdy není jisté, zda bude výsledek použitelný, je výhodnější použít jazyk s méně pracnou správou paměti a přívětivější správou datových struktur, který je vhodnější pro prototypování. Teprve v případě, kdy je ověřeno, že testovaný postup bude fungovat, bude nutné algoritmus přepsat do C nebo C++.
Pro účely rychlého návrhu slouží modul pro spouštění pythoních skriptů. Modul implementuje wrapper pro rozhraní DNS Collectoru. Toto rozhraní je pak možné využívat ve spouštěném skriptu. Samotný modul volá interpret jazyka Python (libpython). Kód wrapperu obaluje předávané C-čkové struktury a vytváří z nich PyObjecty. Za cenu snížení výkonu aplikace, v důsledku obalování datových struktur, je možné využívat všechny výhody dynamicky typovaného interpretovaného jazyka s automatickou správou paměti. Surová DNS data je možné v Pythonu zpracovávat pomocí pyLDNS (wrapper okolo LDNS).
Použití tohoto modulu není pro jiné účely, než je testování, doporučeno. Důvodem je samotná knihovna libpython. Tato knihovna nepodporuje více samostatných interpretů v rámci jednoho procesu. Libpython nepoužívá kontext pro předávání konfigurace interpretru; kontext interpretu existuje jako globální struktura(y) v prostoru procesu. Libpython sice implementuje něco, čemu říká sub-interpreter, ale jak sami tvůrci v dokumentaci uvádí, izolace těchto „pod-interpretrů“ není úplná. Při použití funkcí z nízkoúrovňových operací připouštějí jejich vzájemné ovlivňování.
Konfigurace
DNS Collector je možné spouštět na popředí z příkazové řádky. V tom případě je možné konfigurovat a používat pouze jedno síťové rozhraní či archiv a jeden modul. Tento režim slouží zejména k testování modulů nebo ke spouštění v dávkovém režimu pro postupné zpracování více archivů. Primární určení DNS Collectoru je být spuštěn jako daemon pro monitorování DNS provozu. V tomto případě je vhodnější používat konfigurační soubor, ve kterém je možné současně specifikovat nastavení několika síťových rozhraní společně s několika moduly.
Experimentální konfigurace NETCONFem
Pro použití ve vzdálených zařízeních je experimentálně implementována možnost konfigurace pomocí protokolu NETCONF. NETCONF je protokol založený na XML, umožňující konfiguraci síťových zařízení. Funkce NETCONF serveru je naprogramována s využitím knihovny libnetconf. Tato knihovna implementuje NETCONF server a klient a bezpečný komunikační SSH kanál.
DNS Collector na listopadové konferenci CZ.NIC
Pokud vás tento projekt zaujal a máte k němu otázky, můžete samozřejmě využít komentářového formuláře. Jestli se ale chcete dozvědět více a zeptat se přímo, doporučil bych vám, abyste si udělali čas na naši konferenci Internet a Technologie 13.2 (30. 11., MFF UK, Praha), v jejímž již brzy zveřejněném programu prezentace na toto téma bude.
Karel Slaný
Projekt Turris – pomozte nám vybrat antény
Velké úsilí věnujeme v rámci projektu Turris tomu, aby byl náš hardware co nejkvalitnější a co nejlépe sloužil jeho budoucím uživatelům. Pro domácí síť je jistě jednou z nejdůležitějších součástí Wifi, které šetří náklady na síťovou infrastrukturu, ale zejména umožňuje připojování mobilních zařízení jako jsou chytré telefony a tablety.
Abychom v této oblasti poskytli co nejlepší funkci, rozhodli jsme se pro řešení založené na velice kvalitním chipsetu od firmy Qualcomm Atheros, které nabízí 3×3 MIMO (multiple in, multiple out), laicky tři antény, a to jak v běžném pásmu 2,4 GHz (802.11b/g/n), tak v pásmu 5 GHz (802.11a/n), které není zdaleka tak zarušené. Uživatel si tak může podle vlastní potřeby vybrat, které pásmo mu z hlediska jeho vlastností a lokální situace lépe vyhovuje.
U Wifi ale kvalita spojení závisí nejen na použité elektronice, ale výrazně také na kvalitě použitých antén. Pokud uvažujeme běžné domácí použití, tak jsou nejpraktičtějším řešením všesměrové antény. Ty mají při běžných velikostech (do 20 cm) zisk mezi 2 a 5 dBi a pro běžný provoz v domácnosti jsou většinou naprosto dostačující.
Z výše zmíněných důvodů jsme plánovali dodávat s routerem Turris tři všesměrové antény, ideálně dvoupásmové, tedy schopné pracovat v pásmech 2,4 i 5 GHz. Tady jsme ale bohužel narazili na problém – nabídka dvoupásmových všesměrových antén je velice omezená a ceny dost vysoké. Je to pravděpodobně dané tím, že Wifi v pásmu 5 GHz zatím není příliš rozšířené a pro domácí použití, kde jsou vhodné všesměrové antény, není tak univerzálně použitelné (signál se hůře ohýbá a prostupuje stěnami, pro vnitřní použití je vhodnější ve velkých otevřených prostorách).
Z tohoto důvodu jsme se rozhodli obrátit na naše čtenáře s prosbou o pomoc. První prosba míří na případné výrobce nebo dodavatele antén, kteří by nám byli schopni nabídnout kvalitní antény odpovídající výše zmíněným parametrům. Budu rád, pokud se mi ozvete na adresu bedrich.kosata@nic.cz. Druhá prosba je určená širší veřejnosti, zejména již předregistrovaným zájemcům o router Turris. Pomocí Google Drive jsme připravili krátkou anktetu ohledně plánovaného použití Wifi a budeme rádi, pokud nám jejím vyplněním pomůžete vybrat nejlepší řešení.
Bedřich Košata
Perlička na závěr
Jako jeden z možných způsobů, jak obstarat vhodné antény za rozumnou cenu, jsme se obrátili přímo na několik čínských výrobců antén. Zatím se nám podařilo otestovat vzorky od jednoho z nich a výsledky byly tristní – v pásmu 5 GHz fungovala jejich „dvoupásmová“ anténa hůře, než anténa určená jen pro 2,4 GHz. Když jsme anténu rozebrali, zjistili jsme proč – v cca 15 cm těle je ukrytá maličká anténa konstrukcí podobná tomu, co se běžně používá jako interní anténa v levnějších Wifi routerech.
Na následujícím obrázku vidíte pro srovnání (zleva do prava) rozebranou standardní 2.4 GHz anténu, 5 GHz anténu, kvalitní dvoupásmouvou anténu (zde je bohužel vidět jen malá část, většina antény je součástí plastového krytu) a výše zmíněnou testovanou anténu. Je asi zřejmé, proč poslední uvedená v testech příliš neuspěla. (Obávám se, že pokud bychom si objednali místo 5 dBi verze 8 dBi, dostali bychom stejný produkt jen v delším plastovém obalu za vyšší cenu).
Obamacare má technické problémy kvůli chybě v jednotném přihlašování
Možná jste již v médiích zaznamenali, že Barack Obama připustil rozsáhlé technické problémy své zdravotnické reformy. Jeden z architektů protokolu OpenID Connect John Bradley k tomu na svém blogu napsal krátké shrnutí, ve kterém tvrdí, že jednou z příčin těchto problémů je zvolený způsob implementace jednotného přihlašování na hlavním webu healthcare.gov.
Velké instituce, zejména ve státní správě (samozřejmě myšleno mimo ČR), nejdou úplně rychle z dobou a pro jednotné přihlašování (anglicky „single sign-on“) v rámci svých digitálních agend používají léta prověřený protokol SAML. Platí to jak pro připravovaný systém propojení evropských digitálních identit STORK, kterého se účastníme, tak i pro systémy federální vlády Spojených států. SAML je předchůdce OpenID a psal jsem o něm i na našem blogu.
Příčinou problémů je nestandardní použití jednoho atributu protokolu SAML. To způsobuje, že poskytovatelé služeb zdravotního pojištění, kteří se chtějí napojit na centrální systém, musí aktualizovat svoje systémy, aby se nestandardnímu chování přizpůsobili.
U nás v České republice, kde v digitalizaci státní správy teprve dobíháme vyspělejší státy, a kde jsem si také užili své při startu různých centrálních registrů, může tato situace vyvolat lehký posměch. Ani ve Spojených státech se spouštění velkých projektů neobejde bez komplikací. Na druhou stranu je třeba ocenit, že tyto vyspělejší státy sáhnou radši po prověřeném standardu, než aby vymýšlely vlastní proprietární řešení. V České republice vedle mojeID, které je již používáno i městy a obcemi, nabízí jednotné přihlašování i systém datových schránek. Ten se však vydal cestou vlastního technického řešení a zatím jej využívá jen jeden subjekt.
Jaromír Talíř
První čtyři nové generické domény dostaly zelenou!
Trvalo to dlouho, proces byl hodně bolestný, ale už máme první výsledky. Proces, který byl mnohými nazýván největší inovací Internetu poslední doby, se dostal do závěrečné fáze. V pondělí 21. 10. ICANN oznámil, že čtyři nové generické domény dostaly zelenou a velmi krátce poté, ve středu zhruba ve 21:00 našeho času, byly tyto domény delegovány. Vzhledem k tomu, že nelatinkové domény nakonec dostaly v tomto procesu přednost, nelze předpokládat, že zrovna tyto domény budou v našich končinách nějak mimořádně populární. Jde konkrétně o:
- شبكة (xn--ngbc5azd) – arabské slovo pro „síť“
- онлайн (xn--80asehdb) – rusky „on-line“
- сайт (xn--80aswg) – rusky „webová stránka“
- 游戏 (xn--unup4y) – čínsky „hra“
Kdy přesně bude možné v těchto doménách provádět další registrace zatím není jasné. Určitou technickou zajímavostí je, že všechny čtyři domény byly delegovány včetně DS záznamů, tedy včetně DNSSEC, protože to je už u těchto nových domén povinnost.
Osobně jsem nikdy nebyl velkým příznivcem tohoto procesu a pořád nejsem příliš přesvědčen, že splní to, co se od něj očekávalo, tedy konkurenci zavedené superdoméně .com. Spíše se bojím, že nové domény přinesou chaos běžným uživatelům. Nicméně, pokud mi už nějaké z těchto domén dávaly smysl, tak to byly právě tyto nelatinkové varianty. Přeji tedy našim arabsky, rusky a čínsky mluvícím síťoobčanům, ať jim nové domény slouží.
Ondřej Filip
Za rok přibylo v ČR více než 100 tisíc uživatelů IPv6
V nedávném příspěvku na téma DNSSEC jsem se odkazoval na prezentaci Geoffa Hustona na RIPE 67. Dovolím si tento úspěšný koncept využít ještě jednou a krátce okomentovat jeho další prezentaci, tentokrát o IPv6. Geoff se pokusil ověřit závěr Google, že podíl IPv6 se za poslední rok zdvojnásobil. Ačkoliv se v absolutních číslech liší, což je poněkud paradoxní, protože opět využívá reklamní síť právě od Googlu, v hrubých rysech se jeho závěry shodují. Dle jeho měření stoupl podíl IPv6 z 0,45 % na 1,29 %, což je již výrazný nárůst.
Poměrně překvapivé je, že hlavním motorem tohoto růstu je Evropa a to konkrétně Evropa severní a Evropa východní (do které jsme řazeni i my). Osobně bych spíše očekával, že nejvyšší nárůst bude v regionu Asie-Pacifik, protože ten byl nedostatkem IPv4 adres zasažen jako první. Leč neděje se tak.
Podle metodiky Geoffa přibylo v České republice za rok více než 100 tisíc uživatelů IPv6, což je vzhledem k naší velikosti poměrně slušné číslo. Celosvětově jsme v penetraci IPv6 na desátém místě a podle všeho se o to nejvíce zasloužili tito tři poskytovatelé Internetu: CESNET, který zvýšil podíl IPv6 uživatelů z 20 % na 27 %, Telefónica CR (0 % -> 3 %) a Internethome (0 % -> 2 %). Veliká gratulace a doufejme, že obdobná statistika příští rok dopadne ještě lépe.
Ondřej Filip
Akademie CZ.NIC v novém
Minimálně od konce prázdnin se můžete setkávat s větším počtem novinek spojených s naší akademií. Nejdříve přišel na řadu EDUROAM, přes který se můžete ve vzdělávacím centru Akademie CZ.NIC přihlašovat k Internetu. Potom jsme představili kurz Datové schránky vedený respektovaným odborníkem Jiřím Peterkou. Na to jsme přidali vyčerpávající nabídku kurzů s termíny až do konce letošního roku a to jak v pražské, tak v brněnské pobočce Akademie CZ.NIC. A jako zatím poslední přišly na řadu nové kurzy pro vývojáře open-source softwaru – Svobodná aplikační bezpečnost, Open Source SW Quality Assurance. Teď tu pro vás máme další novinku – Akademie CZ.NIC má nové internetové stránky.
Stránky akademie už delší dobu neodpovídaly našim představám a požadavkům. Proto jsme se rozhodli do toho opřít a výsledkem je úplně nový web, na němž najdete nejen stávající informace, ale především řadu nových. Ty jsou vidět hned od první stránky. Na ní si vyberete to svoje podle toho, jestli jste IT profesionálové, běžní uživatelé, učitelé nebo studenti či zaměstnanci veřejné správy.
Co dlouho chybělo byla sekce novinky. Nyní ji už tedy máme a těšíme se na to, že ji budeme moci začít plnit. Když jsme u komunikace, na nových stránkách samozřejmě najdete také odkazy na sociální sítě. Upravené a rozšířené jsou také části věnované kurzům pořádaným v Praze a Brně a jednotlivým přednášejícím. Je toho samozřejmě více, ale nechtěli bychom vás připravit o jeden z řady důvodů, proč kliknout a prozkoumat akademie.nic.cz.
Na tradiční adrese tedy nyní najdete netradiční (čti nové) stránky. Doufáme, že se vám budou líbit a že se na nich budete lépe orientovat v tom, co a kdy naše vzdělávací centrum nabízí. Pokud byste při jejich procházení narazili na místo, které stojí za upozornění, e-mailová adresa akademie@nic.cz je vám samozřejmě k dispozici. Předem děkujeme za vaše připomínky a návrhy na zlepšení.
Vilém Sládek
Třetina uživatelů validuje DNSSEC, jsme šestí na světě
Geoff Huston z APNICu nedávno prezentoval v rámci konference RIPE 67 poměrně zajímavá čísla z jeho výzkumu validace DNSSEC. Geoff si nakoupil od Google reklamní prostor a do flash kódu implementoval dotazy na tři různá URL. DNS prvního bylo jako referenční bez DNSSEC podpisu, druhé bylo s korektním DNSSEC podpisem a třetí bylo se schválně špatným DNSSEC podpisem. Toto měření mělo mnoho různých cílů, ale z počtu úspěšných transakcí na URL se špatným DNSSEC podpisem lze ukázat, kolik procent DNS resolverů validuje. Samozřejmě jde trochu diskutovat o reprezentativnosti vzorku sbíraného pomoci reklam Google, ale rozhodně následující čísla o něčem hovoří. (Zdroj čísel je ve zmíněné prezentaci na slide 11.)
- Švédsko: 78 %
- Slovinsko: 59 %
- Lucembursko: 44 %
- Vietnam: 38 %
- Finsko: 37 %
- Česká republika: 31 %
Mezi TOP 25 (slide 18) sítí, které validaci podporují, se dostali dva čeští ISP a to Telefónica Czech Republic a GTS Czech. Děkujeme.
Z určitého pohledu to není špatný výsledek. Na prvních šesti místech jsou země, u kterých se to více méně očekávalo. Snad jen trochu překvapivý je Vietnam, ale zde je vysvětlením velká popularita resolverů Googlu, které DNSSEC validují. Na druhou stranu jsem přeci jenom trochu doufal, že země s nejvyšším podílem podepsaných domén v národní doméně bude alespoň na bedně. Inu ještě máme co zlepšovat. Musíme si uvědomit, že dvě třetiny uživatelů mohou být vystaveny třeba velmi zákeřnému útoku na DNS pomocí IP fragmentace, který také v rámci RIPE 67 prezentoval kolega Tomáš Hlaváček!
Ondřej Filip
Ústavní soud k otázce spáchání trestného činu přes Internet
Není třeba dlouze diskutovat o tom, že masivní nástup informačních technologií na přelomu tisíciletí se pochopitelně netýkal jen pozitivních oblastí lidské činnosti, ale velmi výrazně ovlivnil i, slovy klasika, činnost „kriminální a kriminalistickou“ (1). V trestněprávní oblasti tak došlo jednak ke vzniku nových protiprávních jednání (těžko dříve někdo mohl spáchat phishing), a dále se rozšířily možnosti, jak páchat tradiční protiprávní skutky (např. krádež, podvod).
Nový trestní zákoník (TZ), tzn. zákon č. 40/2009 Sb., účinný od 1. 1. 2010, který nahradil předchozí normu z počátku 60. let minulého století, už s Internetem, pro který mj. užívá pojem „veřejně přístupná počítačová síť“, počítá. V tomto příspěvku se nebudu věnovat zcela konkrétním novým skutkovým podstatám, které souvisejí s významem sítě Internet a počítačových systémů a byla jim tak přiznána trestněprávní ochrana (např. §§ 230 – 232), ale ani skutkovým podstatám v tomto smyslu upraveným (např. § 182 a 183), ale otázce veřejnosti spáchání trestného činu a spáchání veřejně přístupnou počítačovou sítí.
TZ uvádí v § 117, že trestný čin je spáchán veřejně, pokud je spáchán obsahem tiskoviny, filmem, rozhlasem, televizí, veřejně přístupnou počítačovou sítí nebo jiným obdobným způsobem a nebo před nejméně třemi současně přítomnými osobami. V zákoně je navíc u jednotlivých trestných činů uvedena tzv. kvalifikovaná skutková podstata, kdy základní skutek je za stanovených podmínek přísněji trestný, a to s ohledem na vyšší nebezpečnost jednání. Jednou z takových okolností je právě spáchání činu prostřednictvím veřejně přístupné počítačové sítě, tedy Internetu.
Ve svém rozhodnutí sp. zn. I. ÚS 1428/13 se Ústavní soud věnoval otázce naplnění skutkové podstaty zločinu výroby a jiného nakládání s dětskou pornografií dle ustanovení § 192 odst. 2 (trestné mj. Pokud je pornografické dílo pachatelem učiněno veřejně přístupným) a § 192 odst. 3 (vyšší trest pak dostane pachatel v případě, pokud skutek spáchá…. veřejně přístupnou počítačovou sítí nebo jiným obdobně účinným způsobem).
K tomu, aby bylo pornografické dílo učiněno veřejně přístupným, je dle dřívější judikatury Nejvyššího soudu (2) vyžadováno, aby byla blíže neurčenému okruhu jiných osob poskytnuta možnost seznámit se s takovým dílem. Pachatel v tomto případě zaslal videozáznam z jejich setkání na profilu poškozené na sociální síti. Již dříve (3) NS judikoval, že nepostačuje zasílání pornografických děl prostřednictvím elektronické pošty do soukromých e-mailových schránek jiných osob a pokud tedy veřejně přístupná počítačová síť slouží pouze jako prostředek pro přenos zprávy (podobně jako dopis), pak znak spáchání veřejně přístupnou počítačovou sítí splněn nebyl. Jiná situace by ovšem nastala, pokud by uživatel k takové e-mailové schránce, kde je předmětné dílo uloženo, zveřejnil přístupové údaje a nebo jej přímo rozesílal více uživatelům.
V případě zasílání zpráv prostřednictvím sociální sítě je třeba rozlišovat, zda se jednalo o zprávu, která byla poslána výhradně uživateli (tzv. soukromá zpráva) nebo zda jde o příspěvek, který se „vyvěšuje“ na profil uživatele. Ve druhém případě je nutné zkoumat ve světle možností ostatních uživatelů si daný obsah zobrazit pokud jde o přístupová práva a také z hlediska toho, že se o něm vůbec dozví. Pouhé užití sociální sítě ke komunikaci nic neznamená právě z toho důvodu, že umožňují zasílání individuálních soukromých zpráv mezi svými členy. Musí být zkoumáno, jaké funkcionality má ta konkrétní platforma sociální sítě, jaké jsou možnosti zobrazování dat od jiných uživatelů a další postupy, v závislosti na nastavení ze strany provozovatele služby a jednotlivých uživatelů. A pochopitelně jaké konkrétní nastavení v daný okamžik na příslušném účtu bylo.
Aby totiž došlo k naplnění znaku „činění veřejně přístupným“ v případě umístění na Internet, pak musí jít o obdobu umístění ve výkladní skříni či ve veřejných místnostech. Tedy musí jít o široký okruh osob bez úzkého individuálního vymezení. Činnost navíc musí být tak škodlivá, jako kdyby byl užit tisk, film, rozhlas nebo televize.
Lze se tedy domnívat, že pouhým odesláním jako soukromé zprávy takové dílo veřejně přístupné není. Pokud by ale bylo takové dílo umístěno na uživatelský profil, pak by vyhodnocení dle mého názoru vypadalo jinak. Na uživatelský profil má přístup obvykle více než 3 osoby, přičemž řada uživatelů nijak neomezuje možnost zobrazení svého profilu uživateli „zvenčí“, tj. osobami, které nejsou registrovanými uživateli dané sociální sítě.
Závěrem ještě zdůrazňuji, že pochopitelně od začátku se (v případě dětské pornografie) jedná o činnost trestnou, to, že dojde ke zpřístupnění veřejně přístupnou počítačovou sítí je jen důvodem pro přísnější trest.
Zuzana Průchová
Poznámky:
1 – Cimrman, Jára: Vražda v salonním coupé.
2 – Nejvyšší soud, sp. zn. 5 Tdo 641/2012 a také 8 Tdo 1467/2010, dostupné na www.nsoud.cz.
3 – Nejvyšší soud, sp. zn. 6 Tdo 1561/2011 (zde je zajímavé, že soud vzal v potaz i to, že přístup k obsahu komunikace mohl mít poskytovatel (freemailové služby) a že k šíření obsahu zasílané zprávy může dojít i bez vědomí uživatele, a to tehdy, pokud má např. zavirovaný počítač. Poskytovatelé jsou však vázáni k zajištění důvěrnosti obsahu zákonem 127/2005 Sb., o elektronických komunikacích.
OpenSource@RIPE
Představovat organizaci RIPE NCC je pro čtenáře tohoto blogu asi trochu zbytečné. Je to registr IP adres pro Evropu a Blízký východ. Nicméně tím výčet aktivit nekončí. RIPE NCC také dvakrát ročně organizuje RIPE meeting, což je setkání především síťových operátorů z evropské oblasti. V rámci RIPE meetingu bylo v minulosti ustaveno několik pracovních skupin (working groups), které se pravidelně scházejí a diskutují na daná témata. V současnosti jsou aktivní Anti-Abuse, Cooperation, Database, DNS, EIX (Internet Exchange Points), ENUM, IPv6, MAT (Measurement Analysis and Tools), RIPE NCC services, Routing. Nicméně počet pracovních skupin není úplně konstantní a občas nějaká vznikne nebo naopak zanikne.
Jako člověk, který se v podstatě celý svůj profesní život věnuje open source softwaru a především směrovacímu démonu BIRD, jsem měl občas trochu problém, v jaké pracovní skupině prezentovat. BIRD je velmi výrazně zastoupen u peeringových center, takže občas jsem prezentoval v rámci EIX. Jde o implementaci routingu, tak jsem čas od času přednášel v rámci Routing. A někdy byla má prezentace vybrána pro plenární zasedání. Nicméně problém byl v tom, že třeba Routing je spíše o směrovacích protokolech a ne o implementacích. V rámci EIX není prostor na prezentaci novinek v OSPF a v plenary je bohužel poměrně málo místa a těžko by ho dostala prezentace o posledních novinkách v nějakém software.
Tehdy mě kontaktoval Martin Winter, který tou dobou pracoval pro ISC a který měl podobný problém s jeho aktivitou opensourcerouting.org, zabývající se projektem Quagga. Dohodli jsme se, že zkusíme udělat tzv. BoF, neboli takové neformální setkání, které je organizováno obvykle večer. Vzhledem k tomu, že přišlo poměrně hodně lidí a z diskuse vyplynulo, že by bylo fajn, tato setkání opakovat a přizvat i další projekty, požádali jsme po pár BoFech RIPE NCC o založení nové pracovní skupiny. Byli jsme požádání o zorganizování jakéhosi pilotního běhu a po něm bylo oficiálně rozhodnuto, že byla nastartována Open Source Working Group a Martin Winter a já jsme byli zvoleni za předsedy této pracovní skupiny.
No a zítra (16.10.) v 8:00 našeho času bude v rámci RIPE meetingu 67 v Athénách první plný běh této pracovní skupiny. Pokud Vás tedy open source týkající se síťových záležitostí zajímá, můžete se podívat i vzdáleně, celý RIPE meeting lze sledovat na tomto URL.
Ondřej Filip