Bezpečnost kořenové zóny je v transparentnosti, řekl Ondřej Filip na CSNOG 2023

Tomáš Podermański: kam sahají meze plánovače síťového subsystému linuxového jádra

Paket při přijetí dorazí na síťovou kartu, projde subsystémem linuxového jádra a dorazí do procesu. Proces pak vytvoří další paket, který je vlastně odpovědí. V případě routingu se paket otočí jen v linuxovém jádře a odchází některým z rozhraní.

Síťová karta s příchodem paketů vyvolá přerušení, naplní takzvaný ring buffer a to vyvolá spuštění řady funkcí pro zpracování celého řetězce. Nejprve se zpracuje iptables, poté conntracking, rozhodnutí o směrování a tak dále. Každá ta část by sama o sobě vydala na několikahodinovou přednášku. Pro další podrobnosti je možné prostudovat diplomovou práci 40GbE směrovač pro operační systém GNU/Linux.

Zásadní roli tu hraje plánovač paketů, který zařazuje pakety do fronty a plánuje jejich další zpracování. Plánovač má možnost si nastavit časovač, který po určité době opět vyvolá odložené zpracování některých paketů. V Linuxu je možné plánovač ovládač pomocí příkazu tc, který dokáže vybírat různé frontové disciplíny a jimi plánovač ovlivňovat.

Dalším způsobem, jak plánovač paketů ovlivnit, je sysctl . Tam je možné nastavit vlastnost net.core.dev_weight , kde je možné zvolit, kolik paketů je v jednom kroku odbaveno. Parametrů je mnohem více, můžeme také volit, kolik paketů se nám do bufferu vejde. Tohle je zatím jednoduché, komplikovat se to začne, jakmile začneme provozovat vícejádrový systém.

Moderní síťové karty už jsou natolik inteligentní, že dokáží příchozí pakety rozdělovat mezi různé buffery. My si pak zařídíme, že jeden buffer obsluhuje právě jedno jádro. Tohle funguje dobře a je možné pak zpracování velmi dobře paralelizovat. Výjimkou je právě plánovač paketu, který běží v jednom vlákně. V některých případech je to řešitelné pomocí disciplínu mq, která ale není použitelná vždy, protože jednotlivá vlákna neznají vzájemný vztah. Když budete chtít omezovat nějaký provoz, bude vám to špatně počítat, protože nevíte, která fronta odbavila kolik provozu.

Problém je, že běžné zamykání plánovače nás stojí velkou část výkonu. Propustnost nám klesne o řád a nejsme to schopni při běžném pohledu poznat, protože to vypadá, že se všechna procesorová jádra flákají. Při podrobnějším pohledu na profiler jádra uvidíme, že systém stojí na zámku v jádře. Stav přetížení je velice nepříjemná záležitost a pro klienty pak narostou obrovsky latence. Linky jsou volné, jádra jsou nezatížená a zákazník není schopen dosáhnout nasmlouvané rychlosti.

Platforma MikroTik je na tom stejně, protože je postavená na linuxovém jádře. Pokud použijete něco jiného než sfq, opět přijdete o řád výkonu. Namísto 8,6 milionů paketů za sekundu se propadnete na hodnoty kolem jednoho milionu.

Plánovač paketů se do linuxového jádra dostal v roce 1997, což je doba nového vydání platformy Pentium II. Od té doby se plánovač prakticky nezměnil, což je zajímavé, když si uvědomíme, o jakém zvýšení rychlosti se tu bavíme. Už v roce 2015 proběhla snaha o aktualizaci, ale ukázalo se, že je to tak složitý problém, že všechny úpravy byly dodatečně odstraněny. V současné implementaci je naprosto nereálné, že by někdo dokázal s výkonností něco udělat. Musí proto vzniknout paralelní implementace, která bude fungovat jinak a lépe. Tahle změna je ale v nedohlednu.

Z hlediska serveru to totiž není problém, ale na limity narazíte v případě, že je Linux v pozici routeru. Když se ale podíváte, kam vývoj Linuxu směřuje, je jasné zaměření na serverové systémy. Pokud používáte Linux jako server, nechejte zapnutou disciplínu mq, ušetříte si spoustu starostí. Nedokážete sice pracovat s provozem nijak sofistikovaně, ale nesnažte se to nějak vylepšit.

Pokud chcete používat Linux v pozici routeru, obvykle chcete s provozem pracovat nějakým sofistikovanějším způsobem. Zamyslete si, jaký k tomuto účelu kupujete hardware. Výhodnější je pořídit procesor s menším počtem jader a vyšším taktem. Tak budu mít méně zámků a bude o ně bojovat méně procesorů. Nevhodné je také používat rozhraní pro VLAN, které je také jednovláknové.

Ondřej Blažek: eBPF/XDP a L4 loadbalancer

Původní BPF je s námi od roku 1992, uživatelé jej znají z utilit tcpdump nebo Wireshark. V současné době se to jmenuje eBPF, ale mluví se o něm prostě jako o BPF. Výhodné je, že když tímto způsobem rozšiřujete jádro, nehrozí vám jeho pád. Kód prochází ověřením a nemělo by se stát, že shodí celý systém.

Je to efektivní způsob, protože se výsledek kompiluje do nativních instrukcí s limitem jednoho milionu instrukcí. Zatím to postačuje, ale je možné, že se to rozšíří. Pomocí eBPF je možné sledovat provoz na síti, ale je možné se zaměřit také třeba na syscally nebo další části jádra.

Program v eBPF může využít různých bodů typu net hook, do kterých se může připojit a zpracovávat tam data. Nejníže je XDP, který je nejblíže síťové kartě a je implementován přímo v jeho ovladači. Pracujete přímo s místem v paměti a celé zpracování je na vás. Máte minimum možností komunikace s jádrem.

Další možností je tc hook, kde už je paket částečně zpracován a není to tak efektivní jako XDP. Stejně tak je možné se připojit na sockety, což je výhodné například v prostředí kontejneru.

Výhodou celého tohoto přístupu je, že paket zůstává v jaderném prostoru a nemusí putovat do žádného procesu. Není potřeba vyčleňovat také žádné procesorové jádro a vše je kompatibilní s TCP/IP stackem. Výhodou také je, že většina výrobců desetigigabitových a rychlejších karet tento režim podporuje. Ideální je eBPF využít pro ochranu před DDoS nebo load ballancing. Můžete takto zahazovat obrovské množství provozu a na zatížení procesoru to prakticky nepoznáte.

Pavel Mráček, Tomáš Procházka: distribuovaná NVME storage

Seznam.cz momentálně běží ve třech datacentrech, kde má umístěných 12 tisíc fyzických serverů. Ty mají procesory Intel Xeon Silver nebo AMD EPYC doplněné o 192 či 256 GB paměti a konektivitu pomocí 10 nebo 25 GE. Nad tím běží OpenStack, na kterém je umístěn také CEPH cluster.

Problém tohoto řešení je, že pokud klient intenzivně čte náhodná data, všechen provoz se mu sejde na jednom portu. Ukázalo se, že to dokáže ucpat i 25GE port. Bylo tedy potřeba otestovat celou situaci pomocí reálného testu. Vytvořili jsme tedy ‚hlučného souseda‘, který vytvářel velký provoz. Vedle něj na jiném virtuálním serveru běžel HTTP server, který měl nerušeně odbavovat dotazy klientů.

Bez řízení výrazně rostla latence odpovědí, protože se ucpává port směrem k serveru a zaplňují se buffery. Míchá se tam slabý tok se silným a pakety se zahazují z obou z nich. Jak to vyřešit? Bylo by možné vyhradit porty nebo postavit nezávislou síť, což naráží na finance a prostor v datacentru.

Nakonec byl nasazen QoS a scheduling na portech k serveru. Jako doplněk jsme nasadili ECN, který umí při zahlcení portu notifikovat všechny strany, aby zpomalily. ECN znamená Explicit Congestion Notification. Nedojde pak k zahození paketu, ale do hlavičky IP se přidá informace o zahlcení. Cisco podoporuje také AFD (Approximate Fair Drop) pro vyhrazení určité části bufferu pro konkrétní toky. Stejně tak je možné nasadit DPP (Dynamic Packet Prioritization), který dovoluje prioritizovat menší toky do rychlejší fronty.

Maria Matějka: BIRD 3: Už, nebo ještě ne?

Původní BIRD běží v jednom vlákně a několik let se vyvíjí nová verze 3. Vydáváme alfa verze. Je už na čase přejít? Ano a ne. Když to uděláte, nasadíte si něco, co ještě žádný velký hráč nenasadil. Když zatím nepřejdete, připravíte se o nový výkon. BIRD 3 je samozřejmě rychlejší než BIRD 2. V běžném případě několikanásobně, ale zatím ještě stále hodně věcí stojí na zámcích.

Někdy je BIRD 3 i pomalejší, například při restartu, pokud je v jádře například milion rout. Komunikace s netlinkem se dělá jinak a je potřeba se ještě podívat, proč je to pomalejší. Můžete zkusit BIRD 3 nasadit, konfigurace je stejná, liší se mírně ovládání příkazovou řádkou.

Vícevláknové je BFD, BGP, RPKI a Pipe. Route exporty jsou asynchronní a je možné si nakonfigurovat počet vláken. Pokud používáte MRT, máte smůlu, protože jsme ho ještě nedodělali. Paralelně samozřejmě běží ještě vývoj BIRD verze 2, kam přibyla například podpora pro BGP Roles dle RFC 9234.

V plánu na letošek je pluginu SNMP AgentX, vývojáři chtějí také dodělat podporu AS Cones a ASPA, stejně jako rozšířit funkcionalitu MPLS. Už delší dobu podporujeme route deflektor, ale chtěli bychom také doplnit label distribution. Velkým projektem je také agregaci rout, která zatím umí zpracovat jen stejné prefixy, ale v plánu je možnost projít celý strom a provést nad ním velkou agregaci. Jsou také nějaké úvahy nad podporou EVPN, zatím běží debata o tom, co by bylo dobré implementovat.

Na konci roku 2023 bude ukončena podpora pro BIRD první verze. Teď je správný čas aktualizovat na BIRD 2.13 nebo na rozumně aktuální verzi. Vývojáři už totiž nemají kód první verze v hlavě a pro jakoukoliv změnu musí znovu studovat kód. Kubernetes Calico používá interně také BIRD 1.6.8, což bude muset také někdo vyřešit.

Jan Kolouch: NIS 2 a její transpozice v ČR

Směrnice NIS 2 byla zveřejněna v prosinci 2022 a vstoupila v platnost 16. ledna 2023. Členské státy mají 21 měsíců pro implementaci do vlastního právního řádu. Předpokládá se, že bude hotovo do října 2024. Zruší se všechny prováděcí vyhlášky, stejně jako stávající zákon o kybernetické bezpečnosti.

V nové směrnici bude regulován kdokoliv, kdo je středním či velkým podnikem, případně spadá do vybraných služeb. NÚKIB předpokládá, že bude regulováno několik tisíc nových subjektů, které se nově budou muset zabývat kybernetickou bezpečností.

Regulace bude probíhat ve dvou režimech: vyšších povinností a nižších povinností. Za mě výborné zjednodušení, otázka je, kdo bude ve které skupině. Problém je, že regulace dopadne na organizaci jako celek, ne jen na jeden systém. Podle pravidla „vyšší bere“, všechny systémy budou muset splňovat přísnější podmínky.

NÚKIB umožnil široké veřejnosti připomínkovat celý zákon, přičemž bylo doručeno zhruba tisíc připomínek. I po vypořádání připomínek máme několik problémů, zejména ve vymezení základních pojmů. Primárním aktivem jsou informace a služby, čímž se rozumí také data, včetně provozních. Pokud spadám do přísnějšího režimu, musel bych evidovat provozní údaje pro všechny systémy.

Asi největším problémem je, že zákon pracuje s pojmem významný dopad, ale nikde nedefinuje definice míry určení takového dopadu. Uživatelé budou jistě zmateni.

V současné době je potřeba hlásit podle různých regulací: GDPR, DORA, ENISA a další. Navrhovali jsme zjednodušení, aby bylo možné hlášení poslat do jednoho systému. NÚKIB argumentuje tím, že je potřeba zajistit spolupráci mezi úřady a potrvá to. Stejně tak není řešena situace, kdy dojde k výpadku systémů, kterými bude možné hlášení odeslat.

Stále jsme ještě na začátku a je možné ještě stále připomínkovat a ovlivňovat výsledek. Časem to bude jen horší.

Jonáš Papoušek: koordinované zveřejňování zranitelností v ČR

Koordinované zveřejňování zranitelností (CVD) je formalizovaný proces, který dovoluje případným objevitelům zranitelností s dobrým úmyslem nakládat s informací o zranitelnosti. Jde o to, jak nějaký etický hacker informací oznámí, jak ji zveřejní a jak bude případně odměněn.

Problém neformalizovaného etického hackingu je, že může být kvalifikován jako trestný čin. Kromě toho je možné takto získané informace zneužít, pokud se k nim dostane zlý útočník. Řeší se tedy jednak samotný proces nalézání a zpracování informací, ale také v širším kontextu způsob formalizovaného hledání kybernetických zranitelností.

Etické nalézání zranitelností je možné provádět několika způsoby: prostřednictvím interních kapacit, krátkodobým penetračním testováním, programy typu bug bounty, či neformalizovaným etickým hackingem. Zde už narážíme na právní problémy, protože může jít o trestnou činnost.

Zúčastněnými osobami tu mohou být: odpovědná organizace provozující ICT produkt, objevitel zranitelnosti a koordinátor. To může být organizace typu CSIRT, která může do procesu vstoupit a motivovat k nápravě objevené zranitelnosti.

Celý proces by měl být postaven na zodpovědnosti, takže provozovatel produktu by měla vyhodnotit, zda chce CVD ve své organizaci nasadit. Může také nastavit přesná pravidla, která určí, jaké produkty mohou být takto testovány a jak bude přijímat zjištěné informace.

CVD je založeno na sdílení informací mezi objevitelem a odpovědnou osobou za případné pomoci koordinátora. Po objevení zranitelnosti bude objevitel vázán mlčenlivostí, aby nemohl informovat nikoho dalšího o existenci zranitelnosti. Zveřejnění by pak mělo být primárně v rukou provozovatele.

Výhodou CVD je, že je poměrně levná, je legální a je pod kontrolou provozovatele ICT produktů. Zvyšuje to bezpečnost jednotlivých produktů, protože ty mohou být dlouhodobě a opakovaně testovány na zranitelnosti. Zvýší to také důvěryhodnost organizace, která věří svým produktům natolik, že je dovoluje veřejně testovat.

Implementace CVD je úkolem pro NÚKIB v rámci akčního plánu k Národní strategii kybernetické bezpečností ČR na období let 2021 až 2025. Ostatní státy k tomu přistupují různě: Belgie má čerstvou legislativu, která objeviteli po splnění základních podmínek chrání objevitele. Musí mít dobrý úmysl, způsob nalézání musí být přiměřený, musí své úmysly oznámit úřadům a nesmí zjištěné informace sám zveřejnit. Francie chrání objevitele procesně, takže nemůže být trestně stíhán.

Česká republika se k tomu staví jinak, protože nechce dovolit neřízené testování zranitelností na úkor práva na nerušené užívání majetku. Snažíme se najít efektivní způsob, jak doporučovat implementaci CVD za současných právních norem, aby objevitel byl chráněn. Není tedy vytvářena legislativa, která by znemožňovala trestní stíhání, ale cílem je nalezení efektivní cesty v rámci současných pravidel.

Zbyněk Pospíchal: IoD

Všichni známe Internet of Things (IoT), které je semeništěm mnoha bezpečnostních slabin. Tato oblast má ale jistou podmnožinu – dálkově řízené erotické pomůcky. Ty jsou na tom z hlediska bezpečnosti stejně nebo hůře než IoT jako celek.

První podobná zařízení se objevila v devadesátých letech, kdy se ještě bezpečnost vůbec neřešila. V současné době se taková zařízení obvykle používají přes mobilní telefony a využívá se Bluetooth. Zařízení je pak možné ovládat přes internet. Má vůbec smysl takové hračky hackovat?

Jednak je možné taková zařízení zneužít ke sběru osobních dat, ale je možné je i monetizovat. Jedním z příkladů je vibrátor s webovou kamerou, která měla Wi-Fi a známé výchozí heslo. Podobně jeden z výrobců sbíral data o používání zařízení bez vědomí uživatelů. Proběhly tam žaloby a jedna z uživatelek se dočkala odškodnění ve výši čtyři miliony dolarů.

Nejkřiklavějším příkladem je zařízení Qiui Cellmate, což je jakýsi pánský pás cudnosti, který je možné na dálku odemykat a umí dávat elektrošoky. Co čert nechtěl, objevil se ransomware a útočník požadoval výkupné za odemčení. Pokud tohle srovnáme s tradičním šifrovacím malware, je tohle podstatně horší.

Jde o zanedbávanou oblast kybernetické bezpečnosti. S rostoucími možnostmi takových zařízení rostou i možnosti útočníků. Na zahraničních konferencích se o tom mluví, u nás zatím nic. Je potřeba si zapamatovat, že ztracená firemní data nemusejí být to nehorší, co vás může potkat.

Ondřej Filip: Root Zone KSK Ceremony

DNS nebylo od začátku navrženo jako bezpečný protokol, jako to bylo i u jiných protokolů. Později vznikl protokol DNSSEC, který funguje a máme jej dnes na stole. Pak jsme začali podepisovat jednotlivé zóny, přičemž se začalo národními zónami. Aby DNSSEC fungoval globálně, musíme mít takzvanou bezpečnou kotvu – bod důvěry. Tím je v tomto případě kořenová zóna.

Jejímu podpisu bránily různé diskuse, během kterých probíhal překlenovací stupeň zvaný DNSSEC Lookaside Validation (DLV). Dlouho se diskutovalo o tom, jak by měla kořenová zóna vznikat a kdo by ji měl podepisovat. Nakonec se rozhodlo o řešení, které zachovává status quo a role byly rozděleny tak, že nejvyšší klíče má IANA a zónové klíče má Verisign.

IANA vybrala dvě lokality ve Spojených státech: Culpeper na východním pobřeží a El Segundo na západním pobřeží. Vymysleli to tak, že bezpečnost bude velmi transparentní a budou se o ni starat zástupci z celé technické komunity. Bylo vybráno 27 dobrovolníků (TCR), kteří jsou rozděleny do tří týmů: dvou aktivních týmů a jednoho záložního.

Probíhají čtyři ceremonie ročně, střídají se setkání na západním a východním pobřeží. Ze sedmi lidí se musejí sejít alespoň tři, takže v případě krize není tak náročné dát lidi dohromady. Ve skutečnosti se musí sejít ještě další lidé, což byl během covidu nepříjemný problém.

V chráněné místnosti jsou dva trezory s čipovými kartami, na kterých je kryptografický materiál pro využití v HSM. V celém procesu je zásadní transparentnost, kdy je možné zkontrolovat, že s obsahem trezorů nikdo nepovolaný nemanipuloval. Aby všechno proběhlo v pořádku, je celá ceremonie dlouhá a scénář má desítky stran. Některé kroky se mění, někdy je potřeba měnit zařízení a podobně. Jedna z nejdelších ceremonií trvala šest hodin, přičemž se ničilo jedno HSM a měnily se karty i zástupci komunity.

Celý proces je velmi robustní, protože jde o citlivou operaci nad databází, kde mají data všechny státy světa, od Spojených států až po Severní Koreu. Jsou tam zástupci mnoha zemí, každý krok je potřeba správně vysvětlit a provést. Je možné požádat i o účast na ceremonii, takže se někdy objeví nezávislí pozorovatelé z venčí. Bezpečnost je v transparentnosti, vše je vidět, kromě vytvořených klíčů, které zůstávají v HSM.

Pokud se i vy chcete stát zástupcem komunity, je potřeba mít dobrou reputaci, být známými v komunitě a rozumět technologii DNS a DNSSEC. Zásadní je také kulturní a geografická diverzita, jsou tam zástupci z celého světa. Musíte také umět dobře anglicky a nesmíte mít žádné vazby na organizace ICANN a Verisign.

Blažej Krajňák: mechanismus DDR v praxi

DDR znamená Discovery of Designated Resolvers a umožňuje zjišťovat informace o podpoře šifrování při komunikaci s DNS resolvery. Funguje tak, že jakmile klient získá adresy DNS resolverů třeba z DHCP, zeptá se každého z nich na speciální záznam _dns.resolver.arpa, ve kterém jsou k dispozici potřebné informace o šifrování. Poté se klient pokusí tímto šifrovaným spojením připojit a musí být navázaná komunikace za pomoci validního TLS certifikátu vydaného na skutečnou IP adresu. Z toho plyne, že zařízení musí mít veřejnou IP adresu.

Zatím je tento mechanismus v podobě návrhu na RFC, ale podporu už deklarují Windows 11, iOS 16 a macOS Ventura. Takže je možné to nasadit v praxi. Na skutečné síti se tak bylo možné dostat na 20 % šifrovaných požadavků do DNS.

(Autorem fotografií je Jaromír Novák z NIX.CZ.)