Ochrana sítí, přenos přesného času a DNS pod kontrolou, CSNOG 2026

Většina dnešních IP sítí je závislá na optických vláknech. Mnoho vlastností těch sítí vychází z optiky samotné: kapacitní, vzdálenostní a spolehlivostní limity. Tady leží limity všech dnešních sítí a musíte je jako správci sítě znát. Většina síťových problémů totiž začíná na fyzické vrstvě.

Optické vlákno se skládá z jádra, které vede světlo, pláště, který brání jeho úniku a vrchní ochranné vrstvy. Uvnitř jádra dochází k totálnímu odrazu, takže je světlo uvězněno uvnitř, dokud nedoletí až k přijímači. Jádro se obvykle skládá z křemičitého skla s přesně definovanými parametry.

Nejběžnějšími typy vlákna jsou multi-mode (MMF) a single-mode (SMF). V případě multi-mode je jádro větší, má průměr okolo 50 mikrometrů a vede tedy signál více různými cestami, což značí postupné zhoršování signálu. To limituje použití na kratší vzdálenosti do dvou kilometrů. Výhodou je levnější hardware.

Proti tomu single-mode využívá jádro o průměru devíti mikrometrů, které vede signál jedinou cestou a se zesilovači dokáže přenášet data na stovky kilometrů. Potřebujete ale složitější a dražší optická zařízení.

Nejčastěji se používají tři typy konektorů: LC, SC a MPO/MTP. Nejmenší konektor LC je dnes nejběžnější, obsahuje jen jedno vlákno a dnes jej využívá většina transceiverů. Starší konektor SC je větší a je mechanicky odolnější. MPO znamená Multi-fiber Push On a může obsahovat až 16 vláken. V každém případě platí, že byste měli udržovat čisté konektory, protože i malá nečistota může způsobit problémy.

Je třeba dát pozor také na tvar zakončení vlákna. UPC je Ultra Physical Contact, obvykle se používá v modrých konektorech a má rovné zakončení. APC je Angled Physical Contact, používá zakončení pod úhlem osmi stupňů obvykle v zelených konektorech a má nižší zpětný odraz. Dejte pozor na různé konektory, protože jejich zkřížením způsobíte fyzické poškození zakončení.

Pro převod elektrického signálu na optický je potřeba vysílač (transmitter), pro zpětný převod pak přijímač (receiver). Nejlevnější využívají LED, ale mají horší parametry a hodí se pouze na multi-mode. Modernějším řešením je VCSEL, což už je laser vhodný pro datová centra a kratší vzdálenosti. Nejpokročilejší pak je DBF, který se používá v single-mode a má velký dosah i kapacitu. Je vyžadován pro single-mode a CWDM a DWDM.

Stejně tak existují různě komplexní přijímače. Nejjednodušší využívají PIN Photodiode, lepší pak Avalanche Photodiode (APD) a nejpokročilejší jsou koherentní přijímače využívající více diod a velmi pokročilou detekci signálů.

Pro přenos optického signálu se používají různá pásma, která se hodí pro různé aplikace. Největší ztráty jsou v pásmu 850 nm, takže se hodí pouze pro použití na krátkých vzdálenostech. Pásmo 1310 nm nazýváme O-Band, které se hodí pro středně dlouhé vzdálenosti. Následující 1550 nm je C-Band a má nejnižší ztráty, takže se hodí pro velké vzdálenosti a DWDM. Pásmo 1600 nm nazýváme L-Band, které dovoluje dále zvýšit kapacitu.

Pro zajištění opravdu velké kapacity je nutné využít Wavelength Division Multiplexing (WDM). Pomocí optických filtrů je možné kombinovat různé optické signály do jednoho vlákna. Varianta CWDM dovoluje do jednoho vlákna dostat až 18 vlnových délek rozdělených po 20 nm, přičemž je možné je přenášet na 80 až 120 kilometrů. Je to levnější než pokročilejší DWDM.

DWDM proti tomu používá jen C-Band a L-Band, kanály jsou tu rozděleny po 0,4 nm a řešení vyžaduje výrazně přesnější lasery. V pásmu C-Band je zhruba čtyřicet 100GHz kanálů.

Kvalitu signálů ovlivňuje několik různých problémů spojených s optikou. Jednak jsou to ztráty, které ovlivňují dosah signálu na konkrétní vzdálenost. Ztráty jsou způsobeny jednak vláknem samotným, ale také počtem použitých konektorů na trase.

Další problém přináší takzvaná disperse, tedy rozptyl, který způsobuje roztažení signálu v čase. Je způsobena různým šířením signálů (modální disperse) a také barevným rozpadem signálů (chromatická disperse). Výraznou roli v degradaci signálu může hrát také šum, který je způsobovaný zesilovači, přeslechy a nelineárními efekty při vysokých výkonech.

Abychom zjistili, jestli bude plánovaná linka vůbec fungovat, musíme zvážit výkon vysílače a citlivost přijímače. Zároveň je potřeba počítat se ztrátami na kabelech, konektorech a jednotlivých propojích. Je třeba započítat také vhodnou toleranci vzhledem ke stárnutí všech částí, teplotám a budoucím opravám. V praxi vyžaduje plánování určitou dávku odhadování a uvážlivého rozhodování.

Miroslav Hampl: DNS PATROL – bezpečné DNS pro Kraj Vysočina

Kraj Vysočina vypsal veřejnou zakázku, protože potřeboval nejen DNS resolver, ale chtěl také umožnit pohodlnou správu, řízení, monitoring a analýzu DNS provozu. Služba měla být k dispozici mnoha organizacím a měla být snadno použitelná. DNS PATROL je proto navržen jako ucelený systém, ne jako sbírka nástrojů.

Základem je Knot Resolver, oddělená anycastová infrastruktura, nová webová aplikace pro správu a nové klientské aplikace pro Windows, iOS a Android. Další detaily je možné získat na webu Dnspatrol.cz, kde jsou nástroje ke stažení pod licencí GNU GPL.

U zákazníka v interní síti běží Knot Resolver, který používají uživatelé. Správci se pak připojují do webové aplikace běžící u CZ.NIC, kde běží také anycastový resolver určený pro uživatele pohybující se mimo domovskou síť. Klientské aplikace jsou nastaveny tak, že jakmile se uživatel vrátí do své domovské sítě, aplikace se vypíná a uživatel opět používá místní resolver.

Bylo potřeba napsat zhruba třicet nových modulů, které řeší konkrétní typ hrozeb nebo také různé výjimky. Výstupem pak jsou samostatné RPZ zóny, což umožňuje definovat individuální bezpečnostní politiky pro různé části sítě. White listy mají vyšší prioritu a slouží k řízeným výjimkám a potlačení falešných oznámení. Moduly jsou průběžně aktualizovány a vycházejí z reálného DNS provozu, pasivního DNS, databází hrozeb, strojového učení a detekci anomálií.

CZ.NIC také vytváří vlastní seznamy bezpečných domén, na kterých jsou například státní domény, důvěryhodné evropské a mezinárodní zdroje a ručně prověřené domény. V rámci oddělení ADAM vznikají také seznamy blokovaných domén, například vycházející z legislativních povinností, podezřelých domén, domén pro cílený phishing nebo domén s neetickými e-shopy.

Administrativní portál využívá přihlášení pomocí OIDC na úrovni záruky značná. Správci mohou mít různé role a mohou sledovat stav jednotlivých resolverů, spravovat podsítě a přizpůsobit pravidla pro jednotlivé sítě. Správce jedné organizace vidí jen dění ve své organizaci a podřazených sítích.

V rozhraní jsou vidět statistiky provozu filtrované podle času, konkrétního resolveru nebo typu záznamu. Můžu se dívat na nejčastější zdroje dotazů a sledovat je podle zdrojové země. Vidět je i poměr dotazů, které se propouštějí, auditují či blokují. Ve skutečném provozu je počet blokovaných domén pod jedním procentem.

Vladimír Smotlacha: Přenos přesného času a frekvence systémem White Rabbit

Přesný čas potřebujeme v dopravě, navigaci, přenosové soustavě, telekomunikacích a v dalších oblastech. Pro vědu jsou požadavky na přesný čas ještě výrazně vyšší. Přenos času a frekvence jsou dvě různé úlohy. V případě frekvence přeneseme jednu periodu a na druhé straně máme původní frekvenci. Samozřejmě je tu nějaké zpoždění a zkreslení signálu, takže je potřeba řešit také kvalitu přenosového kanálu. V případě přenosu času je potřeba kompenzovat zpoždění přenosového kanálu.

Pro přenos času se už čtyřicet let používá standardní protokol NTP, který je postavený na struktuře existujících serverů. Uvádí se přesnost na milisekundu, na menší vzdálenosti je možné dosáhnout i na 100 mikrosekund. Vyšší přesnost neumožňují nepřesné oscilátory v počítačích.

Pro lokální přenos v L2 sítích se používá telekomunikační protokol PTP, kde přesnost bývá jedna mikrosekunda, ale předpokládá se hardwarová podpora ve všech zařízeních na trase. White Rabbit je nadstavbou nad PTP a umožňuje dostat přesnost okolo jedné nanosekundy. Je dobré si uvědomit, že za tu dobu urazí světlo ve vakuu vzdálenost 30 centimetrů.

White Rabbit byl vyvinut ve středisku CERN pro synchronizaci senzorů a dalších zařízení v rámci experimentů na urychlovačích. Dokumentace je zveřejněna pod CERN Open Hardware License, takže zařízení může vyrobit kdokoliv. Existuje několik komerčních výrobců, od kterých je možné hotové prvky koupit.

V případě NTP se klient periodicky dotazuje serveru a z výsledku počítá ofset svého času. Zatěžuje to poměrně hodně server a je předpokládaná plná interakce obou stran. Při použití PTP vzniká vztah master-slave, přičemž i master je aktivní a posílá periodicky zprávy. Ve větších intervalech si pak obě strany vyzkoušejí, jestli je zpoždění stejné a případně si jej korigují.

Lepší přesnosti se dosahuje tím, že zdroj změří dobu odesílání paketu a následně pošle nový paket s upravenou informací, jak dlouho se paket v prvku zdržuje. Zůstává jen zpoždění na linkách, které je konstantní a nebude se měnit. Stejný koncept je použit v protokolu White Rabbit.

White Rabbit je nově specifikován v IEEE-1588 jako nový profil HA (High Accurancy). Zařízení jsou postavena na SFP portech, kde se používá gigabitový optický ethernet. Dosažení přesných hodnot nám umožňuje synchronizovaný ethernet SyncE. Tím je zajištěna stejná frekvence v celé síti.

V obou směrech je potřeba mít stabilní zpoždění, takže se obvykle používá pro každý směr samostatné vlákno nebo alespoň vyhrazený kanál. Oba směry musejí mít také stejnou délku, což bychom v jednom vlákně pro oba směry měli, ale protože bychom používali různé frekvence, skutečná délka by se lišila.

Dále je potřeba přesné měření fázového rozdílů, k čemuž se používá DDMTD (Digital Dual Mixer Time Difference) implementovaný v FPGA. Linkový model pak počítá s konstantním zpožděním na lince.

Tomáš Hála, Lukáš Vacek: DNS pod kontrolou

Nefunkční DNS resolver obvykle způsobí velmi rozsáhlý výpadek a vedle sítě by to tedy měl být druhý nejdůležitější prvek ke správě. Požadavky na moderní DNS resolver jsou rychlost, spolehlivost, vysoká dostupnost, filtrování hrozeb, validace DNSSEC a soukromí. Důležitá je volba hardwaru a softwaru.

Výběr hardwaru by neměl být dimenzován na běžný provoz, ale měl by mít několikanásobně vyšší výkon, aby dokázal obsloužit různé špičky. Vysoká dostupnost vyžaduje více nezávislých instancí, jejichž využití závisí na klientovi. Pokud máte nastaveno více resolverů, výpadek prvního bude znamenat timeouty.

Lepším řešením je například VRRP a keepalived, kdy si servery budou přehazovat VIP adresu, která se v případě problému může snadno předat na jiný resolver. Druhý resolver bude pro danou síť tím hlavním a bude odpovídat dál. Problém tohoto řešení je, že je potřeba DNS resolver s novou adresou restartovat. To způsobí krátký výpadek a jistou prodlevu.

Lepším řešením je IP anycast, přičemž všechny resolvery používají jednu společnou adresu a klienti se dotazují svého síťově nejbližšího resolveru. Zlepšit je to možné ještě pomocí VXLAN a anycast VRRP, který umožňuje rozkládat zátěž rovnoměrně a je možné měnit i váhu. Je tak možné šetřit adresami a používat rozsahy /32 a /128. Nebojte se použít anycast i pro resolvery v interní síti.

Filtrování hrozeb na úrovni DNS je kontroverzní záležitost a je otázka, jestli by měl resolver do provozu zasahovat. Realita posledních let je, že na internetu probíhá tolik problematických aktivit, že začíná dávat smysl provoz filtrovat. Filtrování hrozeb je dnes nutné i kvůli plnění zákonných požadavků, ale chrání také uživatele před závadnými doménami.

Proti zneužití služby je nutné nasadit rate-limiting, kdy se vyplatí omezit nejen vstup, ale také výstup. Resolver totiž může být zneužit pro odražené útoky, různé DNS flood, DoS a podobně. Validace DNSSEC je dnes považována za standard a měla by být součástí každého resolveru. Chceme zabránit podvržení informací o doménách. Knot Resolver má validaci zapnutou ve výchozím stavu a není potřeba pro ni nic dalšího dělat.

Téměř veškerá komunikace na internetu se dnes šifruje, ale DNS stále často ne. Knot Resolver umožňuje použít jak DoT, tak i DoH. Je třeba tam ale řešit důvěryhodné certifikáty a monitorovat jejich včasné obnovování.

Ondřej Surý: Evoluce DNS – nová DELEGace

Protokol DNS je velmi starý a používá NS záznamy, které mohou žít v apexu zóny nebo v místě delegace. Často dochází k tomu, že jsou to dvě různé sady nameserverů a způsobuje to různé problémy. Obsahem záznamu je vždy doménové jméno, server musí běžet na portu 53 a nesmí používat žádné šifrování.

Součástí delegace jsou také glue záznamy, které se používají, pokud jsou jmenné servery ve stejné doméně. Vzniká tam smyčka, která se řeší glue záznamy v nadřazené zóně. Opět tím vzniká prostor pro chyby a rozsynchronizování změn.

V rámci IETF vzniká <a>návrh nového standardu, který používá nový typ záznamu DELEG. Ten je rozšiřitelný, zabezpečený a v celé zóně se vyskytují jen jednou. Cílem je, aby se celý řetězec zjednodušil. Pokud by resolver novému záznamu nerozuměl, může stále použít původní NS.

Do DNS se přidávají dva záznamy: samotná delegace v DELEG a také záznam DELEGI obsahující dodatečné informace o delegaci. V registru bude záznam DELEG, u poskytovatele pak bude uveden DELEGI. Když jste hosting a máte tisíce zákazníků, kterým jste předali svou sadu serverů, nemůžete je teď na jednom místě změnit.

Záznam DELEG je textový, takže je možné do něj přidávat další informace, jako například další možné transportní protokoly, TCP porty a podobně. Pokud přijde nový protokol, můžu lepší zabezpečení jednou změnou provést pro všechny zákazníky. U přímé delegace je možné uvést přímo IP adresy a nejsou potřeba žádné glue záznamy.

Zatím standard pro DELEG neexistuje, ale to by se snad mohlo velmi brzy změnit. Pak bude trvat dlouho, než vzniknou implementace a pak bude ještě dlouho trvat, než se to začne používat. Ještě dlouho budeme používat NS záznamy a postupně snad budeme přecházet na modernější variantu. DNS je taková popelka, u které každá změna trvá dlouho. Dokud to funguje, tak se na to nesahá.

Ondřej Surý: Postkvantová kryptografie pro DNSSEC

Současné algoritmy jako RSA, ECDSA nebo Ed25519 spoléhají na matematické problémy, které jsou pro klasické počítače těžké, ale pro kvantové počítače snadné. Současné kvantové počítač mají velmi málo qubitů, ale teoretické riziko existuje. S příchodem dostatečně výkonných kvantových počítačů by selhal DNSSEC. Problém by měly samozřejmě i další protokoly, ale DNSSEC má svá specifika.

Postkvantová kryptografie (PQC) běží na současných běžných počítačích, ale algoritmy jsou navrženy tak, aby odolaly útokům kvantových počítačů. V případě DNSSEC je tu ale s novými algoritmy několik problémů. Nové klíče a podpisy jsou často výrazně větší než ty současné. Protokol DNS přenášený přes UDP má přísné limity na velikost paketu kvůli fragmentaci. Otázkou je, jak nacpat velké PQC podpisy do malých DNS paketů a nezničit přitom výkon internetu?

Pracuje se na několika nových algoritmech, jako například HAWK využívajícího složitosti problému v mřížkách, SQISign využívá zobrazení mezi eliptickými křivkami nad konečnými tělesy, MAYO využívá obtížnosti řešení soustav polynomiálních rovnic o více proměnných. Velikost klíčů se pohybuje od 65 až po 1420 bajtů, podpisy mívají řádově vyšší stovky bajtů.

Stavy implementaci jsou různé, zatímco HAWK má šikovný a úsporný kód, SQISign je nevhodný pro externí použití, použitelné nejsou ani implementace MAYO a ANTRAG. Když jste kryptolog, nepište kód, pokud na vás nedohlíží žádný softwarový inženýr.

Do budoucna je v plánu otestovat různé úrovně hierarchie DNS, další odlišné algoritmy, zaměřit se na vzory pseudo-náhodných subdomén, vynucený re-keying a podobně. Když píšete DNS software, musíte vždy přemýšlet jako útočník.

Marian Rychtecký: Matrix – otevřený standard pro bezpečnou komunikaci

Běžné současné komunikátory mají několik nepříjemných nevýhod: jsou centralizované, nevíme jak pracují s daty a jsou závislé na jedné firmě. Chtěli jsme nějak řešit provozní chat a interní koordinaci. Prozkoumali jsme několik alternativ a Matrix byl jednou z nich. Požadavkem byl otevřený protokol, federace s ostatními organizacemi a šifrování mimo server.

Matrix je název federovaného komunikačního protokolu, který má svůj definovaný standard. V něm se vysvětluje, jak komunikuje klient se servery, jak se dorozumívají a jak vypadají jednotlivé události. Není to tedy název žádné implementace, ale definice protokolu. Všechny standardy jsou na internetu k dispozici a je možné si napsat vlastní server i klienty. Vše je postaveno nad formátem JSON posílaný přes HTTPS.

Architektura Matrixu zahrnuje Homeserver, ke kterému se připojujete a který umí ukládat a případně přeposílat události (events). Poté jsou tu klienti používající uživatelské rozhraní a správné kryptografické funkce. Pro transport se používá HTTPS po TCP/443, aplikační vrstva používá REST a posílá JSON. Jako konkrétní implementaci je možné použít server Synapse a klienty ElementX nebo FluffyChat. Záleží na tom, jaký používáte operační systém a kolik máte klientů.

Jednotlivé události jsou ukládány do grafu, který je kryptograficky propojení a není možné ho změnit. Je to takový blockchain, přičemž stav místnosti je deterministický výpočet z událostí.

Uživatel může používat více zařízení, která sdílejí klíče. Každé zařízení má sice svůj klíč, ale ten je odvozen z jednoho centrálního klíče. Ztráta zařízení neznamená ztrátu identity. Celá kryptografie je přenesena na klienta, server se šifrování vůbec neúčastní.

Pro skupinové šifrování v místnostech se používá algoritmus Megolm, který umožní vytvořit jeden klíč pro celou skupinu zařízení. Důvodem je optimalizace pro velké místnosti a nízká režie. Je to takový šifrovací multicast.

Server Synapse je naspaný v Pythonu a konfiguraci má v YAML. Včetně čtení dokumentace vám instalace zabere asi hodinu. Pro registraci uživatelů můžete použít LDAP nebo OAuth2, pro federaci je potřeba povolit TCP port 8448.

Vývoj Matrixu jde rychle dopředu, ale slabším místem jsou zatím klienti – nejdále je klient ElementX. Uživatelé jsou zvyklí na komfort jiných aplikací, ale mohou si sami zvolit vhodného klienta. Decentralizace má své nevýhody, například ve velkých místnostech musíte sestavit tisíce HTTPS spojení. Vstup do místnosti trvá výrazně déle a může to hodně zatížit váš server.

Ladislav Loub: Jak kreslit mapy sítě pomocí NetBoxu

NetBox slouží jako databáze různých objektů v síti, jejich souřadnic a propojů. Pro zobrazení map a zapojení monitoringu je možné použít nástroj Grafana a pro samotné kreslení se pak využije klasické HTML s JavaScriptem. NetBox poslouží jako datová struktura, ve které je v rozumném formátu uložena celá síť.

Pro načtení do Grafany je možné použít rozšíření Infinity plugin, který dovoluje propojení s NetBoxem pomocí GraphQL API. Ten slouží pouze pro čtení a my chceme data jen číst. Po naformátování dat je možné nasadit další rozšíření Business Text, které umožňuje vykreslit výstup pomocí HTML.

V takto vykreslené mapě chybějí data z monitoringu, pro která si ale můžeme jít do InfluxDB. Výsledkem je vykreslení stejné topologie, ale navíc je možné vizualizovat stav linek. Po kliknutí na linku je možné dodat statistiky, kolik dat linkou proteklo, nebo nějaké další údaje. V plánu je do mapy přidat různé vrstvy podle použitých síťových protokolů.

Zbyněk Pospíchal: Bráníme (se) IP spoofingu

IP spoofing způsobuje, že se v síti objevují pakety, o kterých nevíme, kdo je odeslal. Dobře se používají k odrazům nebo zesilujícím útokům. Správce zdrojové sítě ale obvykle není motivován takový problém řešit, protože ho přímo netrápí. Spoofing znamená, že někdo je schopen odesílat komunikaci z IP adres, které mu nebyly přiděleny.

Na rozdíl od BGP hijackingu útočník neočekává, že mu přijdou odpovědi. Naopak očekává, že odpovědi přijdou cíli jeho útoku. Bránit se tomu dá jen velice těžko. Za posledních dvacet let se v této oblasti téměř nic nestalo. Je to jako za covidu: tvoje rouška chrání mě, moje rouška chrání tebe.

Můžete chránit zbytek světa tím, že zabráníte odchozímu provozu ze své sítě používajících cizí IP adresy. Dobré je také zabránit tomu, aby vám přicházel provoz z vašich vlastních IP adres. Pokud za sebou máte další zákazníky, je dobré chránit je i před útoky mezi sebou.

Hardwarové routery podporují funkci uRPF (unicast Reverse Path Filtering), kdy je možné hlídat, zda v tabulce FIB je cesta, která vede zpět ke zdroji komunikaci stejným rozhraním. Tahle filtrace byla implementována i do linuxového jádra, ale většina malých poskytovatelů o tom neví. Je to zapnuté ve výchozím stavu a většinou to funguje. Pokud si ale pak operátor pořídí druhý tranzit, často se pak diví, proč se mu to celé rozbije.

Velký poskytovatel může používat ACL, ale musí se starat o jejich přegenerování v případě změn. Jak často se mají přegenerovávat? Mají reagovat na nějakou událost, nebo se mají generovat pravidelně? Problémy jsou i s peeringovými centry, protože tam může někdo posílat provoz z adres někoho jiného. NIX.CZ s tím problém nemá, protože to hlídá pomocí sFlow, ale je v tom spíše výjimkou.

Router má dvě směrovací tabulky: RIB v control plane a FIB v data plane. Abychom ale mohli provádět filtraci, potřebovali bychom koukat do do RIB, ale s tou pracujeme jen velmi pomalu. Proto vzniklo RFC 8704, ve kterém autoři vytvářejí tabulku EFP-uRPF, která má obvykle jen několik tisíc záznamů.

V této oblasti je ale veliká setrvačnost a budeme čekat mnoho let na nová zařízení, aktualizace softwaru a reálné nasazení. Nikdo z nás nedokáže spoofing vyřešit, ale společně mu lze čelit. Velký pokrok v této oblasti umožnil projekt Fénix, který provoz monitoruje a příslušného operátora o problémech informuje.

Tomáš Košňar, Petr Adamec: Evoluce síťové obrany na CESNETu

Sdružení CESNET vzniklo v roce 1996 a propojuje vysoké školy a Akademii věd. Vytváří velkou infrastrukturu pro velmi různorodé sítě, které se liší velikostí provozu, charakteristikou toků a například i rozsahy IP adres. Na začátku jsme začínali s ACL a uRPF jako všichni.

Někdy v roce 2004 byl nasazen QoS, ale cílem bylo vždy neomezovat provoz. Byly tam jen pro jistotu, ale raději jsme vždy navyšovali kapacity linek. Okolo roku 2016 začaly experimenty s FlowSpec, v roce 2019 bylo nasazeno RPKI a v roce 2020 po výhrůžce a ukázce DDoS přišel externí scrubbing. Mezi lety 2024 a 2026 byl nasazen DDoS protector vyvinutý ve sdružení CESNET.

Informace o omezeních byla k dispozici na různých místech a bylo těžké zjistit aktuální stav. Proto byl interně vytvořen systém ExaFS, do kterého byly původně ručně vkládány informace. Jako zdroj dat pak byl použit systém FTAS, který umožnil sbírat informace z mnoha zdrojů. Bylo to klidně až sto záznamů za hodinu, proto jsme nasadili API a začali jsme to tam vkládat automaticky.

V současné době se do systému automaticky dostávají BGP Community, BGP Address Family a v plánu je přidat podporu ACL. Zdroje mitigačních pravidel mohou být různé, kromě FTAS to může být třeba také fail2ban, FastNetMon nebo ruční zadání. Výsledek je pak z exaBGP distribuován do routerů.

Jako provozovatel sítě chcete udržet funkčnost sítě a zabránit saturaci. CESNET se snaží odlehčit uživatelům, ale nezasahuje do běžného provozu, jen reaguje v případě anomálií. Leda že se dohodnete s uživatelem a on vás o to požádá.

Pro výchozí řízení obrany se používá flow-based monitoring, kde se sbírají data ze síťových prvků i vlastních sond. Původně se NetFlow sbíhal z hraničních prvků do systému FTAS a ten řídil exaFS. Dává to odpověď na otázku, odkud a kudy to bylo přeneseno a také přibližně co bylo přeneseno. Chybí ale informace o tom, jak to bylo zpracování a kudy to bylo odesláno.

Podstatné pro automatiku je, aby vše bylo vyřešeno rychle. Přijatelnější je, že máte horší sampling, ale hlavně o tom musíte vědět rychle. Vždycky je to nějaký kompromis a timeouty je potřeba držet hodně nízko, jak to která platforma umožňuje.

Současný model je vytvořen na bázi segmentace, kdy jsou ve VRF uzavřeny skupiny uživatelů, které mají podobný charakter provozu. Vycházíme z toho, že co je špatné pro jednoho, je špatné pro všechny. Takový systém je velmi flexibilní, protože libovolný detekční nástroj umí ovládat libovolné exaFS, pokud k tomu má práva.

(Autorem fotografií je Petr Krčmář.)