Implementace DNSSEC v doméně CZ zvýšila úroveň zabezpečení

Technologie DNSSEC, vytvořená k zabezpečení protokolu DNS, byla do správy české domény zavedena v roce 2008. V té době byla Česká republika teprve pátou zemí na světě, v níž se k tomuto kroku správci odhodlali. V dnešní době je DNSSEC téměř standardem, a jak ukazuje statistika organizace ICANN, mezi doménami nejvyšší úrovně je poměr zabezpečených již na 84 %.

Celý článek

DNSSEC za šest minut dvanáct

Již pozítří vstoupí v účinnost poslední část Usnesení vlády č. 982 ze 13. prosince 2013, podle kterého mají všechny ústřední orgány státní správy, tj. ministerstva a další orgány jako je např. Český telekomunikační úřad, Státní úřad pro jadernou bezpečnost nebo Úřad pro ochranu hospodářské soutěže zabezpečit všechny jimi držené domény prostřednictvím DNSSEC. V této souvislosti je třeba zdůraznit, že tato povinnost se vztahuje nejen na doménu využívanou pro hlavní prezentaci, ale i např. i domény jednotlivých projektů jako např. CzechPOINT.cz či BusinessInfo.cz.

Celý článek

Jak bude v nejbližších letech podporovat stát oblast kybernetické bezpečnosti?

Vláda České republiky schválila v minulém týdnu hned dva dokumenty týkající se kybernetické bezpečnosti. Oba pocházejí z dílny Národního bezpečnostního úřadu, který v roce 2011 přebral úlohu gestora pro tuto oblast. První z nich, Zpráva o stavu kybernetické bezpečnosti, uvádí jako dvě hlavní události za minulý rok přijetí Zákona o kybernetické bezpečnosti a otevření Národního centra kybernetické bezpečnosti. Oba tyto kroky jsou vyvrcholením delších diskusí, příprav a strategie, kterou se snaží úřad v této oblasti plnit. I když se jedná o poměrně jednorázové záležitosti, jejich praktické plnění je spíše otázkou delšího časového rozvoje. Vládní CERT tým však v minulém roce prošel postupně výraznějšími změnami, které tým posílily a pomohly ho postupně zformovat do dnešní podoby. Mezi splněné úlohy se dostala také spolupráce s týmem CSIRT.CZ, která přešla z konzultační roviny do roviny praktického řešení kybernetických incidentů.

Celý článek

Připravte se na odborné kurzy Akademie CZ.NIC

Některé odborné kurzy v naší nabídce vyžadují aspoň základní znalost protokolů TCP/IP. A dosud bylo na účastnících, jakým způsobem si základy TCP/IP nastudovali. Nyní však mají možnost projít si před samotným workshopem bezplatný e-learningový kurzu v prostředí Moodle, kde si mohou osvěžit, co již možná zapomněli.

Celý článek

Zfušovaný Internet

Všichni se shodneme, že na Internetu najdeme spoustu věcí, které jsou nepříjemné, otravné či dokonce škodlivé. Stojí nás čas, peníze a vnitřní klid. Ale ne všechny tyto věci vznikají se zlým úmyslem. Často je tomu dokonce naopak. Ale jak se říká, cesta do pekel je dlážděna dobrými úmysly.

Ukázalo se, že projekt Turris je takovým magnetem na nepříjemnosti způsobené jinými subjekty.

Celý článek

Validace DNSSEC pomocí Dnsmasq

Dnsmasq je jednoduchá implementace základních síťových služeb — vše v jednom: DNS, DHCP, router advertisement a bootování ze sítě. Pro svou velikost (maličkost) a nenáročnost na systémové prostředky si našel místo na mnoha domácích routerech. Dnsmasq také spravuje virtuální sítě v sadě nástrojů libvirtd. A v neposlední řadě je k nalezení i na některých smartphonech (včetně Androidu), kde se používá pro tethering.

9. dubna 2014 vyšel Dnsmasq verze 2.69, který do vínku dostal podporu validace DNSSEC. To určitě stojí za vyzkoušení.

Celý článek

Pomůže usnesení vlády k většímu rozšíření IPv6 a DNSSEC?

Na konci loňského roku přijala vláda Usnesení č. 982, které zavádí povinnost zabezpečení domén držených státní správou prostřednictvím technologie DNSSEC. Usnesení vlády se zaměřuje rovněž na podporu IPv6, kdy ve srovnání s usnesením z roku 2009 rozšiřuje okruh subjektů, které musí u svých elektronických služeb podporovat IPv6. Ve svém dnešním příspěvku bych se rád na nové usnesení vlády podíval trošku podrobněji a zároveň přidal pár statistických dat jako příspěvek do diskuze na téma, zda má cenu mít usnesení vlády, které nemá žádné sankce a zda takovýto dokument není jen „prázdným plácnutím do vody“.

IPv6: současný stav

Povinnost podporovat na svých serverech IPv6 byla vládou schválena již v červnu 2009 s tím, že jednotlivé orgány státní správy (tj. ministerstva a další centrální úřady jako např. Český statistický úřad či Energetický regulační úřad) měly za povinnost do 31. prosince 2010 zabezpečit přístup ke svým stránkám jak prostřednictvím protokolu IPv4, tak protokolu IPv6. Stejná povinnost pak byla doporučena pro kraje včetně hl. města Prahy.

Pokud se podíváme na aktuální výsledky podpory IPv6 u jednotlivých orgánů veřejné správy (viz graf), zjistíme, že podpora nové verze internetového protokolu je u státní správy mnohem vyšší, než ve zbytku domény .cz, přičemž vidíme znatelný rozdíl mezi státní správou, která je přímo dotčena usnesením vlády č. 727 z roku 2009, a samosprávou. U měst a obcí pak stojí za povšimnutí téměř čtyřnásobný růst podpory IPv6 na straně webových serverů, který je částečně způsoben rovněž zahrnutím podpory této technologie jako jednoho z kritérií soutěže Zlatý erb, kterou jsme se rozhodli jako technologický partner podpořit rovněž v letošním roce.

Graf_IPv6

IPv6: co přináší nové usnesení vlády

V rámci nového usnesení vlády přijatého na sklonku loňského roku považuji osobně za nejdůležitější nový bod 1. d), tj. „zahrnout požadavek na podporu IPv6 do všech relevantních výběrových řízení, a to jak na dodávky služeb, tak zboží (hardware), i jako nedílnou součást požadavků na všechny nově podpořené projekty a jejich součásti financované ze strukturálních fondů v tomto i nadcházejícím finančním období. Oproti původnímu usnesení vlády se povinnost podpory IPv6 rozšiřuje rovněž o příjemce prostředků ze strukturálních fondů. Zde je nutné si uvědomit, že v rámci tzv. publicity patří webové prezentace mezi nejoblíbenější nástroje, přičemž často se nejedná o samostatný web, ale jen o začlenění jedné (či několika málo stránek) do stávajícího firemního webu. V této souvislosti stojí za připomenutí, že z TOP100 firem podporuje na webových serverech IPv6 pouze 5 % největších podniků.

V případě zájmu se mocným nástrojem na prosazení IPv6 může pak stát požadavek jejího povinného zahrnutí do všech relevantních výběrových řízení. Je ale nutné si uvědomit, že pod pojmem „relevantní výběrová řízení“ se již nemusí skrývat jen tendery související se zajištěním webové prezentace, ale rovněž s nákupem datových služeb (včetně mobilních), což podporuje rovněž Český telekomunikační úřad, který 20. prosince 2013 zveřejnil Obecná pravidla řízení datového provozu. Podle těchto pravidel se pak službou přístupu k síti internet rozumí:

veřejně dostupná služba elektronických komunikací, která umožňuje využívání obsahu, aplikací a služeb sítě internet, a tím propojení prakticky všech koncových bodů připojených k síti internet (a to protokolem IPv4 a IPv6), bez ohledu na použitou technologii sítě.

Zde bude zajímavé sledovat, zde se povinnost zajištění konektivity jak přes IPv4 či IPv6 nestane další součástí boje v rámci elektronické aukce komunikační infrastruktury veřejné správy, tzv. KIVS.

DNSSEC

Pokud se podíváme na aktuální statistiky, zjistíme, že průměr počtu zabezpečených domén .cz dosahuje 37,1%, zatímco u státní správy se to o 10 procentních bodů méně – konkrétně jen čtyři ministerstva ze čtrnácti a tři ze třinácti ústředních orgánů státní správy.

Situace je tak zde zcela opačná, než u IPv6 a z tohoto pohledu je usnesení vlády vítaným nástrojem, který – dle zkušeností s IPv6 – sice zřejmě nikdy nezaručí 100% přijetí této technologie, ale může výrazně urychlit její zavedení. V rámci podpory rozšíření obou technologií se pak Akademie CZ.NIC rozhodla všem účastníkům z veřejné správy nabídnout speciální akci: dva kurzy (IPv6 a DNSSEC) za cenu jednoho.

Hřejivé na srdci je pak i to, že u DNSSEC se Česká republika stala první zemí min. v Evropě, která nařídila veřejné správě zabezpečení svých domén, což byl možná i jeden z důvodů, proč nedávné Usnesení vlády označil renomovaný publicista Jiří Peterka jako jednu z 10 nejvýznamnějších událostí českého eGovernmentu za rok 2013.

Jiří Průša

Proč je opravdu zapotřebí DNSSEC?

Amir Herzberg a Haya Shulmanová z izraelské Bar Ilan University na konferenci IETF 87 v Berlíně představili novou variantu otrávení DNS pomocí fragmentace IP paketů. Kompletní prezentaci lze najít v IETF 87 Proceedings.

Doporučuji si pro osvěžení tématu znovu přečíst o útoku na DNS, který před pěti lety objevil Dan Kaminsky. Kromě použití technologie DNSSEC, která je jedinou opravdu funkční ochranou proti podvrhávání DNS odpovědí, se jako jedna z obran začaly používat náhodné zdrojové porty, které přidaly dalších ~16 bitů entropie.

Už v té době jsme ve studii (kratší shrnutí) upozorňovali, že ani větší počet náhodných bitů nezaručuje ochranu před podvržením a otrávením DNS, a s dostatečně velkým datovým tokem (~100Mbps) je možné otrávit DNS za dobu lehce překračující jeden den (~25 hodin).

Izraelští výzkumníci nyní přišli s novými variacemi útoku na DNS, které ukazují, že opravdu potřebujeme kryptograficky silné DNS a potřebujeme jej pokud možno ihned.

Hlavička IPv4 paketu vypadá takto:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          <strong>Total Length</strong>         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         <strong>Identification</strong>        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    <strong>Destination Address</strong>                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Celá hlavička UDP datagramu vypadá takto:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    <strong>Destination Address</strong>                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Důležité je vědět, že v případě, že spojení mezi dvěma směrovači má nižší MTU (Maximum Transmission Unit) dojde k fragmentaci paketu na několik částí, které jsou identifikovány stejným číslem v poli Identification (dále IP-ID). Fragmentovaný provoz může vypadat například takto:

14:56:02.608188 IP (tos 0x0, ttl 64, id 47557, offset 0, flags [+], proto ICMP (1), length 1500)
    217.31.204.249 > 12.22.58.30: ICMP echo request, id 22368, seq 1, length 1480
14:56:02.608193 IP (tos 0x0, ttl 64, id 47557, offset 1480, flags [none], proto ICMP (1), length 48)
    217.31.204.249 > 12.22.58.30: ip-proto-1
14:56:02.797078 IP (tos 0x0, ttl 60, id 61513, offset 0, flags [none], proto ICMP (1), length 1528)
    12.22.58.30 > 217.31.204.249: ICMP echo reply, id 22368, seq 1, length 1508

Jak lze vidět, tak odchozí ICMP zpráva typu echo request (tj. ping) byla rozdělena na dvě části s IP-ID = 47557 a rozdílnými offsety. Fragmentované části paketu pak budou v cíli spojeny do jednoho a aplikace, která přenesenou zprávu zpracovává, ji dostane v jednom bloku. A protože k defragmentaci paketů dochází až v cílové destinaci a směrovače fragmentované pakety nijak speciálně nesledují, tak je možné, že každá část fragmentovaného paketu dorazí k cíli například jinou cestou nebo v jiném pořadí, než byly fragmenty odeslány.

Toto skládání částí paketu mimo pořadí nahrává útočníkovi. Pokud ví, jaké je po cestě MTU, což nemusí být tak složité zjistit, tak může začít podvrhovat následné (tedy druhé a vyšší) části paketů. Takto podvrhnuté fragmenty můžou mít dvojí efekt – jednak je možné do druhé části paketu vložit vlastní obsah a jednak v případě rozdílné udané velikosti celého paketu je možné donutit operační systém, který je zodpovědný za defragmentaci paketu, aby (pro útočníka) nežádoucí pakety zahazoval (tj. taková trochu chytřejší varianta DDoS útoku).

Další (a poslední) část fragmentační skládačky spočívá v tom, že existuje ICMP zpráva typu fragmentation needed, kterou si počítače na cestě domlouvají maximální velikost paketu, kterou dokážou přenést. V případě IPv4 je minimální velikost MTU 68, v případě IPv6 je to 1280. Bohužel tuto zprávu lze celkem dobře podvrhnout a cílový server donutit snížit MTU na hodnotu, která je pro útočníka výhodná. Tato nová hodnota je v operačních systémech držena v dočasné paměti až několik minut.

Jaké to tedy má důsledky pro DNS? Na to se musíme podívat do hlavičky DNS zprávy:

                                1  1  1  1  1  1
  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                      ID                       |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    QDCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ANCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    NSCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    ARCOUNT                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Již jsme si řekli, že ochranu proti spoofingu nám zajišťuje ID v hlavičce zprávy (16 bit) společně se zdrojovým portem v UDP zprávě (16 bit).

Když se ale podíváme zpátky pouze na IP vrstvu, tak zjistíte, že obě informace (DNS-ID i source port) jsou vždy uloženy pouze v prvním IP fragmentu, tudíž útočníkovi stačí podvrhnout druhou část paketu, kterou nahradí vlastním obsahem. Při podvrhávání potřebuje útočník uhádnout jenom správné IP-ID, aby se podvržený fragment spojil se začátkem platné odpovědi. Kromě toho, že hádání 16-bitového IP-ID je velmi jednoduché provést pouhou hrubou silou, tak celou situaci ještě zjednodušuje fakt, že hodnoty IP-ID se většinou negenerují úplně náhodně. Na některých operačních systémech existuje globální counter IP-ID, takže hodnotu aktuálního IP-ID systém vyzrazuje s každým odeslaným paketem (a útočník tedy přibližně ví, do jakého rozsahu se má trefovat). Pokud cíl útoku běží na Linuxu, tak je to pro útočníka naštěstí trochu složitější, protože pro každou cílovou adresu má Linuxové jádro zvláštní IP-ID counter, ale i toho však lze bohužel zneužít.

Poslední komplikace, kterou útočník musí vyřešit, je kontrolní součet v UDP hlavičce. Nicméně ani to není velký problém, protože jednak útočník ví, jak bude odpověď DNS serveru vypadat, protože se sám může zeptat, a v DNS paketu je vetšinou dost místa na to, aby kromě falešné odpovědi do DNS paketu ještě nacpal další data, kterými 16-bitový kontrolní součet nastaví na požadovanou hodnotu.

Poslední zefektivnění útoku probíhá opět již na IP vrstvě a závisí na implementaci IP stacku v jednotlivých operačních systémech, nicméně je možné říci, že ve většině případů je možné tuto optimalizaci dost efektivně využít. Již jsme si výše řekli, že fragmentované pakety mohou přijít mimo pořadí, a protože je UDP nespojovaný protokol a zároveň vrstva, která dělá defragmentaci v IP stacku nemá moc ponětí o vrstvách vyšších, je možné podvržené druhé fragmenty poslat dopředu na náš cíl útoku a ony se uloží do vyrovnávací paměti operačního systému. Teprve po tomto „nahrání“ druhých fragmentů útočník vyvolá Kaminsky-style dotaz, a odpověď, kterou cílová aplikace dostane, bude složena z přednahraného části a prvního fragmentu správné odpovědi.

Celý koncept útoku dále v Laboratořích CZ.NIC zkoumáme, a mimo jiné bychom rádi v rámci ověření efektivity takového útoku vyrobili funkční PoC (Proof of Concept) implementaci celého útoku. O tom, zda-li jsme uspěli, Vás budeme dále informovat.

Na závěr bych rád řekl jednu špatnou a jednu dobrou zprávu. Ta špatná zpráva je, že v současné době není proti tomuto útoku známa žádná jiná efektivní obrana než nasazení DNSSECu. Ta dobrá zpráva je, že pokud máte doménu .CZ, tak máte skoro 40% šanci, že Vás DNSSEC chrání. Jestli chcete vědět, jak s DNSSEC pracovat, přijďte do naší akademie. Kurz se jmenuje více než prozaicky – DNSSEC – zabezpečení DNS.

Ondřej Surý

Distribuovaná kybernetická bezpečnost

Na konferenci IT 13 jsme mimo jiné představili nový projekt zaměřený na vývoj bezpečného domácího routeru. Ten je součástí většího projektu zaměřeného na zlepšení bezpečnosti v českém síťovém prostředí a to pomocí aktivního monitoringu a analýzy síťového provozu. Zmíněný domácí router bude v rámci tohoto projektu plnit roli síťové sondy a zároveň aktivního prvku v ochraně koncových uživatelů.

V tomto krátkém článku si představíme především hlavní důvody vzniku tohoto projektu a jeho cíle.

Motivace

Každý, kdo provozuje nějaký veřejně dostupný server a podívá se občas do jeho logů, ví, že internet není klidné a bezpečné místo. I bez jakéhokoli zásahu uživatele se s počítačem připojeným k internetu neustále pokouší spojit různé cizí stroje a to málo kdy s dobrými úmysly (vizte např. výsledky z našeho honeypotu).

Vzhledem k tomu, že většina domácích sítí je připojená k síti svého poskytovatele přes jeden přístupový bod, kterým je domácí router, a často používá NAT, který schovává celou domácí síť za jedinou IP adresu, vedou první útoky v podstatě vždy právě na domácí router. Ten je tedy ideálním místem jak pro detekci pokusů o neoprávněný přístup do sítě, tak pro aktivní ochranu před nimi. Pokud by si navíc routery byly schopny mezi sebou informace o detekovaných útocích vyměňovat, mohlo by to vést ke zvýšení účinnosti ochrany jednotlivých strojů a zároveň detekci velkých útočníků.

Protože se v našem sdružení dlouhodobě věnujeme problematice internetové bezpečnosti, rozhodli jsme se vytvořit systém, který by s pomocí sítě domácích routerů dokázal monitorovat podezřelý síťový provoz a reagovat na zjištěné bezpečnostní hrozby úpravou pravidel pro přístup do sítě. Takto získané výsledky by pak byly k dispozici i pro ochranu dalších uživatelů Internetu.

Distribuovaný adaptivní firewall

Systém, který jsem nastínil v minulém odstavci, interně nazýváme „distribuovaný adaptivní firewall“ a je v této chvíli ve fázi aktivního vývoje. Součástí systému je klientská část, která po aktivaci na domácím routeru monitoruje nevyžádané pokusy o přístup do sítě zastavené firewallem a také provádí analýzu protékajících dat. V těch se pokouší odhalit anomálie, které by mohly být příznakem úspěšného útoku nebo již existující nákazy. Výsledky obou zmíněných částí klientského systému jsou nahrávány na druhou část systému, kterou je centrální server, kde jsou data dále zpracovávána a porovnávána s výsledky z ostatních sond.

Pokud je systémem některá část provozu vyhodnocena jako anomální a odborná obsluha systému vyhodnotí danou anomálii jako potenciální útok, připraví pro ni nové pravidlo pro firewall. To je potom formou aktualizace nahráno zpět na všechna zařízení zapojená do sběru dat.

Pro případy, kdy je třeba o dané anomálii získat doplňující informace, je součástí systému také nástroj na spouštění specializovaných „mikrosond“, které je možné formou modulů nahrávat na sledovaná zařízení. Ty pak umožní zaměřit analýzu na konkrétní typ provozu a získat detailnější data o daném jevu.

Výsledkem výše popsaných opatření je systém, v rámci kterého budou moci uživatelé chránit své sítě i sítě ostatních účastníků před vnějšími útoky a který se bude postupně „učit“ reagovat na nové hrozby. Navíc bude možné takto získaná data použít i pro ochranu další uživatelů Internetu, kteří nejsou do projektu přímo zapojeni, a také pro další analýzy získaných informací.

Závěr

V tomto článku jsme si představili nový projekt sdružení CZ.NIC zaměřený na distribuovanou kybernetickou bezpečnost. V blízké budoucnosti si v samostatném příspěvku ukážeme hlavního aktéra tohoto projektu, kterým je otevřený domácí router vyvíjený pod interním označením „CZ.NIC router“.

Bedřich Košata