Komunitní setkání Czech and Slovak Network Operation Group (CSNOG) má za cíl spojit odborníky a profesionály z oblasti správy a provozu sítí v České a Slovenské republice. Toto setkání slouží jako platforma pro výměnu znalostí, sdílení osvědčených postupů a diskusi o aktuálních výzvách a trendech v oblasti síťových technologií. Komunitní setkání CSNOG organizují společně sdružení CESNET, CZ.NIC a NIX.CZ.
Kateřina Kubecová: Ochrana BGP pomocí TCP-AO
TCP-AO je způsob ochrany BGP, který nevyžaduje drahé šifrování celého provozu, ale umožňuje nám ověřit autenticitu přijímaných dat. Historicky se používá hašovací algoritmus MD5, který je ale považován za zastaralý a místo něj je k dispozici právě TCP-AO. Přichází s některými vylepšeními, která souvisejí s tím, že pro každé spojení můžeme mít více klíčů.
Klíče je možné měnit, aniž by bylo nutné spojení přerušovat. Vstupem je klíč, který má své ID a rovnou posíláme i ID klíče, který má být použit pro vytvoření odpovědi. Protistrana ověří podpis a pokud nesedí, pak se paket ignoruje.
Informace důležité pro TCP-AO jsou uloženy ve struktuře nazvané MKT (Master Key Tuple), která obsahuje identifikátor TCP spojení, volby pro TCP, SendID a RecvID, klíč pro odvození hesel, funkce pro odvození klíče a algoritmus MAC (Message Authentication Code). Při výměně klíče se původním klíčem zašle klíč s novým ID, a tím se ho protistrana naučí. Abychom se zbavili původního klíče, který je stále platný, musíme ho ručně smazat.
BIRD bude mít možnost nastavit položku authentication na ao a poté je možné v bloku keys nastavit několik různých klíčů a nastavit jim preferenci. V JunOS se konfiguruje ještě navíc položka start-time, která umožňuje přidat nový platný klíč v konkrétním čase.
Jan Kučera: eBPF/XDP pro optimalizaci výkonu síťového subsystému
Našim cílem je chránit koncový server před DDoS útokem, což může být například HTTP(S) služba na portech 80 a 443. Snaha je ustát toho co nejvíce s hardwarovým vybavením, které máme k dispozici.
Způsobu ochrany je celá řada, můžeme serveru předřadit nějaký ochranný prvek, ale můžeme také vhodně nakonfigurovat samotný systém.
Zaměřujeme se na provoz, který není identifikovaný svým zdrojem. Nemůžeme jednoduše rozlišit, zda zdrojová IP adresa odpovídá legitimnímu zdroji.
Na takový provoz nelze použít IP blacklisting, rate limiting a podobná opatření. Typickým útokem je tu TCP SYN Flood, kdy útočník odesílá požadavky na zahájení nových spojení a tím alokuje zdroje na serveru. Standardním řešením jsou SYN cookies, kdy se stavová informace zakóduje do odpovědi.
SYN cookies jsou implementovány v linuxovém jádře, ale tato implementace není příliš efektivní. Existuje ale modul pro iptables nazvaný rawcookie, který zpracování odpovědi přesouvá už do raw table. To obchází nejen conntrack, ale je možné obejít i routovací subsystém a odpověď generovat přímo na MAC adresu nejbližšího směrovače.
Výsledkem je přibližně dvojnásobný výkon než v původní implementaci a na běžném hardwaru je možné dosáhnout vyšších milionů paketů za sekundu.
Je možné jít ale ještě níže a generování odpovědí přesunout blíže k síťové kartě pomocí rozhraní eBPF/XDP. To umožňuje do některých míst v linuxovém jádře vložit vlastní uživatelský kód.
Tento kód pak může paket zachytit a poté předat nějaké uživatelské aplikaci, přesunout do standardního zpracování nebo rovnou vytvořit odpověď. Chceme se vyhnout alokaci socket bufferu, proto je v našem zájmu rovnou vygenerovat odpověď.
Implementace se jmenuje xdpcookie, zkontroluje TCP hlavičku a cílový port a poté vygeneruje SYN cookie a odešle ji. Umožňuje ale i validaci následného ACK, takže je možné se dotázat conntracku a poté paket propustit nebo ověřit správnost cookie.
Navíc je k dispozici podpora VLAN, je možné zapnout a vypnout výpočet kontrolních součtů L3/L4.
Původní rawcookie zvládal na testovací sestavě 15,2 Mp/s (milionů paketů za sekundu), xdpcookie posunul výkon na dvojnásobek na 34,7 Mp/s a s offloadem kontrolních součtů do síťové karty je možné jít přes 40 Mp/s. Situaci je možné ještě zlepšit předřazením dalšího stroje před chráněný server, ale je potřeba řešit překlad sekvenčních čísel. Pro linuxové jádro existuje patch, kterým je možné vnutit vlastní sekvenční číslo.
Lukáš Vacek: Nasazení XDP v Knot DNS
Výkon autoritativních DNS serverů je možné navyšovat přidáváním uzlů v nových lokalitách, navyšováním kapacit linek a přidáváním nových serverů. Tyhle kroky jsou ale finančně velmi náročné. Můžeme ale také využívat výkonnějšího DNS démona.
Je možné použít technologii XDP, která umožňuje obejít celý síťový stack a předat data rovnou démonovi. Je doporučeno používat jádro alespoň verze 5.x a dobrou síťovou kartu umožňující obsluhovat více front. Pakety v nich budou obslouženy paralelně v procesoru.
Vývojáři Knot DNS mají vyzkoušené karty Nvidia ConnectX-6 Dx, Intel series 700 a Intel Series E810.
V linuxovém systému je potřeba upravit konfiguraci služby a přidat capabilities, aby měl Knot dostatečná práva. Dále je vhodné upravit konfiguraci síťové karty, nastavit vhodný počet kanálů, velikost paměti, přerušení a přiřazení konkrétních kanálů ke konkrétním fyzickým jádrům CPU. Je lepší používat jen fyzická jádra a Hyper-Threading vypnout.
To vše je možné provést nástrojem ethtool .
Nastavení Knota už je pak velmi jednoduché, stačí vyjmenovat IP adresy pro poslouchání a ve správné části konfigurace zvolit síťové rozhraní pro nasazení XDP. Je možné také nastavit route-check a rozhodnout, zda se má daný paket odbavit přes XDP nebo projít standardní cestou. Žádný paket pak nepřijde zkrátka a budeme se mu věnovat.
Problém XDP je, že takto zpracovávaný provoz neprochází síťovým stackem, nejsou aplikována pravidla ACL, tcpdump téměř mlčí a není možné sbírat provoz běžným způsobem. Pokud chceme monitorovat provoz, můžeme nechat zrcadlit port na předřazeném switchi.
Tam je pak možné provoz sbírat standardně. Samotný Knot pak nabízí sběr statistik, je tak možné sledovat růst počítadel a tím ověřit funkčnost.
Tomáš Hála: Novinky v DNS anycastu pro .CZ
CZ.NIC provozuje zejména dva kritické systémy: registr domén a autoritativní servery. Nesmí dojít k selhání a musíme si být jisti, že služba bude za všech okolností dostupná.
Pokud by služba vypadla, doména .CZ by zmizela z internetu a spousta věcí by přestala fungovat.
Služba není naškálována jen na běžný provoz, ale na kritické situace, které musí být schopna vždy ustát. V loňském roce přibyla nová anycastová lokalita v Kyjevě, která je připojená rychlostí 10Gbps a dnes odbavuje přibližně 600 dotazů za sekundu. Server jsme koupili u nás a složitě jsme ho dopravovali na místo, byla kolem toho spousta byrokracie.
V lokalitě nekončí zdaleka jen ukrajinský provoz, ale i dotazy z Polska, pobaltských zemích a dalších míst.
Na základě analýzy dat byly vytipovány země, na které dává smysl se zaměřit a snížit pro tazatele dobu potřebnou na získání odpovědi. Zohledňujeme přitom i množství provozu z daných zemí. Například ve Spojených státech sídlí spousta velkých firem, takže je to pro nás zajímavá lokalita.
Byla proto přidána pátá lokalita ve Spojených státech, konkrétně v Los Angeles.
Díky technologii XDP bylo možné zeštíhlit oba vysokokapacitní DNS stacky v Česku, místo původních čtyřiceti serverů dnes stačí pouhých deset. Vznikla také třetí lokalita, která má první produkční 100GE DNS servery v infrastruktuře. Kvůli stabilitě a robustnosti se snažíme držet různý software a hardware. Jenže DNS v režimu XDP je možné provozovat pouze v Knot DNS.
Každá lokalita je postavena na jiném hardware a síťových kartách a je možné ji rychle přepnout na jinou implementaci autoritativního serveru. Snahou je ale přijít s druhou implementací, očekává se, že se to podaří serveru NSD. Až to bude k dispozici a stabilní, máme v plánu to nasadit.
Běžný provoz napříč anycastem je 24 tisíc dotazů za sekundu, ale aktualizovaná lokalita v DC Tower ČRa je schopná odbavit až 240 milionů dotazů za sekundu. Je to schválně hodně předimenzované, abychom odolali velkým útokům.
Petr Špaček: měření výkonu při přenosu DNS zóny
Při měření je možné začít nejmenší zónou se dvěma záznamy, ale takto malý přenos se velmi špatně měří a výsledek je velmi náchylný na různé chyby měření. Proto je možné použít nějakou skutečnou zónu TLD. Česká zóna je tajná, proto můžeme použít třeba švýcarskou.
Během měření se vývojářům v jednom z deseti případů stalo, že server startoval déle.
V systému je možné využít rozhraní IO pressure, které umí říct, na co proces čekal. Ukázalo se, že tento jeden proces čekal na načtení dat z disku. U takto velkých dat narazíte na omezení velikosti diskové keše a je třeba s tím počítat.
Přenos dat přes zabezpečený kanál TLS je stejně rychlý jako přenos nezabezpečeným kanálem, stojí nás to jen o malinko více procesorové zátěže. To mě osobně hodně překvapilo.
Naopak při zabezpečení pomocí TSIG se doba přenosu prodlouží asi o deset procent.
Obvykle nepřenášíme takto velké zóny, ale typicky máme velké množství malých zón. Průměrný čas na přenos zóny by se neměl s počtem zón měnit, v praxi je to ale jiné a časy hodně kolísají. Časy pro 10 a 20 tisíc zón jsou stabilní, ale u 30 tisíc zón vystřelí prudce nahoru. Po startu serveru je vidět postupný pokles zatížení procesoru až k nule.
Zhruba 38 sekund po startu se objeví chyba v TCP socketu, která souvisí se stavem TIME_WAIT. Každé TCP spojení je definováno kombinací: zdrojová IP, zdrojový port, cílová IP a cílový port. Při navazování spojení je potřeba vybrat zdrojové číslo portu, kterých jsme měli nakonfigurováno 28 tisíc.
Po uzavření spojení se ale daný port dostane do stavu TIME_WAIT, po jehož vypršení může být port znovu použit. Doba čekání byla ve výchozím stavu nastavena na 60 sekund, což je celá věčnost. Když se kvůli tomu zónový přenos nepodaří, zkusí se to znovu za 30 sekund.
Je možné omezit počet spojení v čekajícím stavu, aby porty nikdy nedošly. Tohle číslo byste neměli nikdy měnit, žere to koťátka.
Pokud ale víte, co děláte, můžete zmíněný problém vyřešit. Při úpravě na hodnotu tisíc v tomto případě došlo k velmi rychlému přenosu zón, všechno se chová lépe a stabilněji. To dokazuje, že jsme měli pravdu a narážíme na omezený počet TCP portů.
Důležité je při testování ničemu nevěřit a kontrolovat testovací prostředí. Přenos mnoha zón znamená hodně TCP spojení a hodně ladění. Zapomeňte na lineární chování.
Maria Matějka: Čtvrt milionu prefixů
Prefixů pro IPv4 přibývá a blížíme se milionu, což se nám už nevejde do hardware a bude to problém pro řadu zařízení. Můžeme se snažit o bezeztrátovou agregaci tabulky, která nám nezpůsobí žádné provozní omezení. Chceme, aby provoz nakonec dělal totéž, ale aby nám to zabralo méně drahé paměti.
Pokud je paměti ještě pořád málo, můžeme si vybrat jen ty routy, které opravdu potřebujeme v hardware. Zbytek pak můžeme routovat procesorem. Jak je ale vybrat? Můžeme to udělat staticky podle konfigurace nebo dynamicky podle statistik z provozu. Tohle máme ve velmi rané fázi v Birdu.
Myšlenka je taková, že osmdesát procent provozu vyřeší dvacet procent rout.
Pro IPv6 má tabulka přibližně 217 tisíc prefixů a je možné ji sloučit na 70 tisíc prefixů. Asi 50 tisíc prefixů zůstane původních, tak jak jsme je dostali.
Navíc asi 15 % výsledku se mění podle lokality. Routy z Ameriky se vám budou mít větší tendenci agregovat v Evropě a naopak.
Podobně 977 tisíc prefixů pro IPv4 lze sloučit na zhruba 220 tisíc, asi 70 tisíc jich opět zůstane beze změny. Přibližně 30 % prefixů pak bude vypadat úplně jinak podle lokality.
Bird umí agregovat routy podle úplně všeho, dokud se agreguje i podle prefixu. Ve chvíli, kdy chcete agregovat napříč prefixy, není to zatím ještě možné. Musíme to pořádně změřit, analyzovat a publikovat.
Zřejmě budou objeveny nějaké chyby, které bude potřeba opravit. Doufám, že z toho bude alespoň jedna bakalářka.
Ladislav Loub: Dokumentace sítě CESNET3 pomocí Netboxu
Netbox je systém pro dokumentaci a evidenci sítě a datových center. V poslední době se začíná používat jako zdroj pravdy pro uzavřenou automatizaci.
Dříve už byla většina věcí zdokumentována, ale v různých a roztříštěných systémech. Existují totiž různé varianty: RackTables, IP Fabric a konečně Netbox.
Netbox nabízí komplexnější strukturu než RackTables, má propracované API a je možné ho rozšiřovat. Naopak neumí plně nasimulovat direction-less technologii. Smířili jsme se tedy s variantou, že DWDM budeme považovat za blackbox a budeme dokumentovat jednotlivé propoje.
Při nasazování nových prvků technici nainstalovali potřebná zařízení, zprovoznili je a spustili skripty, které připravily základní konfiguraci. Netbox pak přišel s podporou modulů a také vazbou MxN portů. To se nám velice hodí pro zapojení patch panelů.
Existuje také veřejná knihovna typů zařízení, která urychluje zavádění nových zařízení do Netboxu.
Nyní je síť ve stavu, kdy je ji možné plně modelovat v Netboxu. Nemáme ale ještě odvahu plně spustit automatickou konfiguraci.
Existuje ale podpůrný software Rundeck, který provede import ze sítě, vygeneruje unikátní PortID a načte konfiguraci z Netboxu.
Celou agendu není možné pokrýt datovým modelem Netboxu, některé nástroje je potřeba si rozšířit. Potřebovali jsme například přenést starý Inventory monitor, takže jsme vytvořili model podle staré databáze.
Díky tomu je možné sledovat i zpětně, jaké transceivery se v zařízení používaly.
Druhým rozšířením je Netbox Attachments, kterž umožňuje vkládat soubory k jednotlivým objektům v Netboxu. Plugin je zveřejněný na GitHubu a může jej kdokoliv využít.
Důležitá je synchronizace s různými systémy, jako je CRM, VMware, Graylog, Grafana a IPAM. V Netboxu se nám pak spárují například organizace a jejich IP prefixy.
Vznikne tím vazba port – prefix – organizace. Grafana je pak schopná generovat výstupy podle jednotlivých tagů.
Pro snazší přidávání a odebírání síťových správců vznikla potřeba evidence SSH klíčů podle jednotlivých zařízení. Vznikl nový plugin pro správu SSH klíčů. Když některý člověk odejde, jednoduše dohledáme, kde všude má klíče.
Lukáš Macura: Jak na centrální log management
Proč vlastně potřebujeme logovat? Jednak nás k tomu nutí spousta regulací, ale hlavně bychom to měli sami chtít. Bez logování máte zavřené oči a nevidíte, co se děje.
Všichni správci systémů jsou za to zodpovědní, o každém systému se musí vědět. Neexistuje žádná omluva nebo výmluva.
Pokud to správce sám nechce, je to zodpovědnost manažera.
Co bychom měli logovat? Prostě všechno, abychom měli k dispozici všechna data.
Musíme ale pohlídat aplikační data, aby log neobsahoval nic citlivého, například uživatelská hesla. Většina aplikací loguje správně, ale musíme dát pozor na vlastní aplikace a jejich výstupy.
Odkud bychom měli logovat? Zejména z produkčních systémů, zařízení obsahujících produkční data, síťových zařízení a prvků s přístupem na internet. Použít je možné různé nástroje jako Rsyslog, Syslog-ng, Nxlog pro Windows nebo BEATS.
U standardních syslogovacích algoritmů je výhodné, že je možné je jednoduše prohledávat grepem a archivovat. Naopak je velmi náročné je analyzovat, protože to nemá žádnou strukturu – je to jen text.
Pro detailnější analýzu je výhodnější použít BEATS, ale je u něj nutná orchestrace na klientech. Nasadit a nakonfigurovat agenta najednou na stovky zařízení je problém.
Výhodou je, že parsování probíhá na klientovi.
Pro analýzu a korelaci logů je pak možné nasadit Greylog, který ale potřebuje poměrně hodně zdrojů. Dokud nelogujete, nevidíte. Pokud nelogujete centrálně, nemůžete věci korelovat.
Je potřeba pak ale ještě na logy použít automatiku a poté reagovat na zajímavé události.
(Autorem fotografií je Petr Krčmář.)
