Aktivita CSNOG vznikla v komunitě, která se potkává na setkáních RIPE. Všude kolem nás mají vlastní NOG, jen u nás nic takového nebylo,
řekl v úvodní řeči Ondřej Filip, ředitel sdružení CZ.NIC. Společná česko-slovenská akce je podle něj logická, protože obě země jsou stále propojené, nejen na úrovni jazykové a síťové, ale i lidské.
Cílem není jen pořádat konference, ale podpořit komunitní život, aby spolu operátoři začali komunikovat a vyměňovat si zkušenosti. Chceme, aby se lidé potkávali, psali si přes mailing list a podobně. Jsme na začátku, ale máme velké ambice.
Vznikla skupina na Telegramu a také místnost ve Slacku, kde je už možné komunikovat.
Zakládajícími členy jsou CZ.NIC a NIX.CZ, ale postupně by měly přibývat další subjekty. Byli bychom rádi, kdyby otěže postupně převzala komunita, aby se i financování rozprostřelo mezi více zdrojů.
Program konference ovšem sestavovala nezávislá programová komise, která rozhoduje bez ohledu na sponzory.
Artyom Gavrichenkov: DDoS útoky a jak jim čelit
První DDoS útoky byly zaznamenány na přelomu tisíciletí. V roce 2005 vytvořil Microsoft model STRIDE, který pokrývá hlavní typy nebezpečí pro koncové systémy. Jde vlastně o přehled toho, jak je možné na nás zaútočit.
DoS a DDoS se vždy rozlišovaly tím, že druhý jmenovaný přichází z několika různých zdrojů. Otázkou ale je, co definujeme jako zdroj. Obvykle se tím myslí napadený koncový počítač.
Dnes ovšem může jít i o virtuální stroje. Počítají se i virtuální počítače pod jedním hypervizorem? Co linuxové kontejnery?
Stejně tak můžeme počítat IP adresy, ale ty se běžně při útoku falšují.
Dnes se spíše oba druhy útoku rozlišují tak, že DoS spoléhá na bezpečnostní slabinu v software, kdežto DDoS vyčerpá výpočetní zdroje. V zásadě je každý zdroj vyčerpatelný: paměť, procesorový čas, síťové rozhraní.
STRIDE se pak zabývá hodnocením rizik, modelováním a managementem v této oblasti.
Základním hlediskem je pravděpodobnost útoku vztažená k možným dopadům. Většina útoků je triviálních a ne příliš nebezpečných, proto se jimi nemusíme zabývat. Na druhé straně spektra jsou ale nebezpečné útoky s vážnými dopady. Důvody můžou být různé, od zábavy přes vydírání, konkurenční boj nebo politické cíle.
Nejvíce jsou rozšířené útoky na webové služby různých firem, které si objednávají konkurenti.
Dnešní klasický DDoS útok se snaží vyčerpat kapacitu sítě. Ta je rozdělena na různé vrstvy a různé útoky se zaměřují na různé vrstvy. Může jít o klasické vyčerpání kapacity na L2 nebo L3, útoky na vrstvy L4–6 se mohou zaměřovat na TCP/TLS a na L7 se útočník zaměřuje na samotnou aplikaci. Nedostupnost kterékoliv této vrstvy vede k nedostupnosti celé služby.
Často využívanou metodou používanou k DDoS útokům je zesilující efekt některých služeb. Počítá se s tím, že řada serverů posílá uživateli více dat, než od něj dostává.
Při použití UDP protokolů se obvykle neověřuje zdrojová IP adresa, kterou je možné podvrhnout a tím nechat server poslat odpověď směrem k oběti.
Existuje celá řada protokolů, které jsou k tomuto postupu zneužitelné: NTP, DNS, SNMP, SSDP, Portmap a další. Naštěstí počet zranitelných serverů postupně klesá, ale čas od času je objeven nový útok a počet použitelných serverů tak zase skokem naroste.
Zesilující faktor se u různých protokolů výrazně liší, od několikanásobku až po tisícinásobky.
Boj s tímto typem útoku je poměrně snadný, pomocí BGP FlowSpec je možné oslovit poskytovatele připojení a informovat ho o tom, že určitý provoz nechcete dostávat. Stále však existují protokoly, které takto nemůžete jednoduše odříznout: ICMP a případně BitTorrent, který není vázaný na konkrétní port.
V minulém roce začaly být k zesilujícím útokům zesilovány memcached servery. Jejich tvůrci udělali chybu ve výchozím nastavení, které otevírá neautentizovaný UDP port na všech rozhraních, včetně těch směrem do internetu.
Po světě existuje spousta otevřených memcached serverů, které je možné naplnit daty a pak je nechat obsah vyslat směrem k oběti. Zatímco NTP zesiluje útok zhruba pětsetkrát, u memcached jde teoreticky až o miliony.
Velmi rozšířený je útok pomocí napadených IoT zařízení, který je známý mnoho let, ale teprve v posledních letech se stal masově rozšířeným. V roce 2015 začaly být napadány malé routery, do kterých je možné trvale umístit malware. O rok později přišel známý malware Mirai napadající IP kamery. Přestože jsou dohromady kamery schopné generovat toky v řádu terabitů, je jejich síla rozdělena mezi stovky různých botnetů, takže výsledek není tak nebezpečný.
Klasickým útokem je SYN flood, který dokáže na oběť zaútočit na různých vrstvách. Buď je možné vyčerpat kapacitu sítě nebo zdroje na cílovém serveru, který není schopen držet informace o velkém množství otevřených TCP spojení. Řešením je použití SYN cookies nebo SYN proxy, které umožňují oběti ověřit zdrojovou adresu protistrany.
IPv6 také přináší své problémy, protože má obrovský adresní prostor. To je v mnoha ohledech výhoda, kvůli které byl nový protokol navržen. Zároveň ale komplikuje například blokování jednotlivých adres, protože nejsme schopni je dostat do paměti. V případě IPv4 bylo blokování celých sítí považováno za velmi špatnou praktiku. U IPv6 se k ní ale musíme vrátit.
Na aplikační vrstvě se velmi často zneužívají různé CMS, jako třeba WordPress. Obvykle jsou mimo zodpovědnost síťových operátorů a řešit je musí provozovatelé serverů. Jedním z řešení je například captcha, což je snadno implementovaný nástroj, který je ovšem možné obejít buď pomocí OCR, strojového učení nebo levné pracovní síly najaté po internetu. Existují služby, kam pošlete dolar a lidé v rozvojových zemích pro vás vyřeší tisíc captcha.
Citlivým místem většiny služeb je DNS, které je díky UDP možné zahltit velkým množstvím požadavkům a tím službu efektivně znepřístupnit. Naštěstí DNS umí přejít na TCP, který umožňuje ověřit zdrojovou IP adresu. Bohužel řada protokolů postavených na UDP je vytvořena bez ohledu na DDoS. Proto je těžké některé služby chránit, například tím trpí řada herních serverů.
Použití internetu se komplikuje, přibývají další protokoly a s nimi další rizika. Dříve jsme použili DNS, otevřeli socket, použili HTTP a zpracovali odpověď. Dnes se k tomu přidala volba mezi IPv4 a IPv6, TLS handshake, CRL/OCSP, load balancing a například také CDN. Bezpečnost není produkt, je to proces. Schopnost odolat DDoS útokům musí být vestavěna do designu všech protokolů.
Firmy se ale musí zabývat také pravidly pro aktualizace, risk management a řešení incidentů.
Zrychluje se také zneužívání nových hrozeb. V případě memcached byl problém odhalen v listopadu 2017 a začal být zneužíván o tři měsíce později. Příště to bude pravděpodobně mnohem rychlejší. Meltdown a Spectre ukázal, že embargo u velké komunity nefunguje a informace jsou vyzrazeny dříve.
Do budoucna se budeme muset zaměřit na spolupráci celé komunity, vyvinout nová pravidla definující správnou a dobře načasovanou reakci. Měla by tedy vzniknout obdoba RFC 2350 pro síťové operátory.
Paul Rendek: RIPE NCC a NOG v našem regionu
RIPE NCC je sekretariát pro RIPE komunitu, který je dnes zodpovědný za přidělování IP adres a ASN, spravuje RIPE databázi a provozuje služby jako RIPEstat, RIPE Atlas a další. Jsme zcela nezávislí, nejsme financováni sponzory nebo vládami, platí nás sami členové. Jsme otevření, průhlední, neutrální a nestranní. Jsou to velká slova a není lehké to splnit.
RIPE podporuje také NOG, které ale musí ctít stejný otevřený přístup.
V našem regionu je přibližně 25 aktivních NOG, nově přibyl ten česko-slovenský. Snažíme se hodně NOG podporovat, děláme přednášky, propagujeme je a dodáváme nástroje. Zajímavé je, že většina NOG od nás nechce peníze, chtějí po nás spíše podpořit komunitu.
Hlavním cílem těchto skupin je sdílení zkušeností, které vede k celkovému zvýšení odbornosti v jednotlivých zemích. Odborníky pak nemusíte hledat daleko v zahraničích, ale můžete se rozhlížet kolem sebe.
Důležitý je samozřejmě také byznys, na který firmy dobře slyší. Když mají lidé plné peněženky, dobře se jim buduje komunita. Byznys je tu neodmyslitelný.
NOG pak často hraje důležitou roli ve vývoji internetu a mívá nemalou roli na vládní politiku a regulace, protože působí jako odborný garant.
NOG v různých zemích jsou si velmi podobné, obvykle čerpají zkušenosti od ostatních. Všichni mají problém sehnat dobrovolníky, přednášející a sponzory.
Kromě samotného přednášení na konferencích jsou velmi důležité také přestávky na kávu, kde se členové komunity potkávají. Tam lidé kolují, tam se mluví a setkává. Je to snad ještě důležitější než přednášky, proto tomu dáváme hodně prostoru.
Mezi různými skupinami jsou ale také rozdíly: setkání jsou půldenní až dvoudenní, některé akce navštíví desítky lidí a jiné stovky, komunita bývá občas formalizovaná, ale často jde o otevřenou skupinu lidí. Liší se také komunikační kanály, některé komunity používají e-mail, jiné využívají něco úplně jiného.
Příkladem úspěšné komunity je irský iNOG, který vznikl v roce 2015 s 15 lidmi. Za tři roky měli už 15 setkání a oslovují stovky lidí. Zaměřují se na zajímavé přednášky, někdy se sejdou jen na pizzu, točí videa, jsou hodně aktivní na sociálních médiích.
Jejich doporučení je zůstat co nejvíce otevřený a co nejvíce snížit práh pro přístup nových členů.
CSNOG je první skupina vytvořena napříč dvěma státy. Ale tím je to zajímavé, Češi a Slováci jsou velcí kamarádi, takže je logické, že se i komunity dávají takto dohromady.
RIPE NCC je za další komunitu velmi rád a chce ho dál podporovat.
Andrej Hošna: detekce a izolace chyb v sítích
Andrej Hošna pracuje ve Facebooku a se svými kolegy se zabývá monitoringem sítě. Pokud monitoring nemáte, dozvíte se o nefunkčnosti sítě jen od uživatelů. Pak přichází manuální práce, abyste zjistili, kde se co rozbilo.
Takový postup neškáluje a je nepoužitelný ve velkých sítích, jaké provozuje právě Facebook.
Některé chyby jsou dobře vidět, protože způsobují problémy v komunikaci. Například v případě problémů s kapacitami linek se ale konkrétní chyby v prvcích neobjevují a služba je přesto nedostupná. Navíc nesmíte věřit zařízením, protože ta vám předem neřeknou, že selhávají. Pasivní monitoring tu nestačí, potřebujete silnější řešení.
V datacentrech služby komunikují mezi sebou a síť je pro ně jen jakýsi éter, který musí jednoduše fungovat. Dokud jsou odezvy v milisekundách, je síť neviditelná. Jakmile stoupne latence na 200 milisekund, služby selhávají. Potřebujeme tedy monitorovat celou infrastrukturu.
Facebook si napsal vlastní nástroj NetNORAD, který sám ověřuje průchodnost sítě.
Prvním způsobem je klasický ping, automaticky se testují odezvy jednotlivých uzlů v síti. Každá sonda má nadefinovanou zhruba stovku cílů, do kterých se trefuje a zkouší se průchodnost.
Zkouší se komunikace uvnitř datacentra, mezi jednotlivými částmi podsítě i mezi různými datacentry v odlišných lokalitách. Později byl nástroj vylepšován, aby byl schopen pomocí traceroute a frameworku Apache Thrift projít všechny cesty v sítích a statisticky odhalit vadnou linku nebo prvek.
Kromě automatizovaného monitoringu je potřeba také většinu událostí vyřešit automatizovaně. Pokud máte deset prvků, dokážete je opravovat ručně. Se stovkou se to taky ještě dá. Ale jakmile jich máte sto tisíc, nemůžete mít dostatečně velký tým odborníků, který je bude spravovat. Většinu zásahů pak musí udělat automat.
Ľubor Jurena: open-source směrovač na běžně dostupném hardware
Základním parametrem každého zařízení je jeho výkon, v případě routeru je to počet paketů, který dokáže zpracovat za sekundu. Zajímají nás také protokoly a podporovaná funkcionalita a také škálovatelnost. Protože takové zařízení kupujeme na dlouhou dobu, zajímá nás také možnost dalšího rozšíření pomocí karet.
Důležitým parametrem je také cena a náklady na provoz.
Na začátku byly požadavky 1U routeru se dvěma zdroji, který bude schopen přenést 20Gbps. Rozhodli jsme se postavit vlastní řešení, proto jsme pořídili server od SuperMicro.
Uvnitř jsou dva čtrnáctijádrové procesory Intel Xeon E5–2680, 32 GB RAM, dva integrované SFP porty a prostor na tři PCIe karty. Zapojili jsme do něj tři karty Intel XL710, čímž jsme získali dvanáct dalších portů.
Poté bylo zařízení zapojeno do testovacího prostředí, ve kterém byl packet generátor a receiver, mezi nimi bylo samotné testovací zařízení. V síti byl i switch, který sloužil čistě ke sběru statistických dat.
Rozhodovalo se mezi nasazením FreeBSD, Linuxu, Bird či Quagga. Snažili jsme se saturovat 10Gbps linku různě velkými pakety.
Kromě toho byla také routovací tabulka naplněna náhodně vygenerovanými cestami s prefixem /8 až /24 a byl použit nejnovější ovladač i40e.
Z testu vyšla propustnost 1,4 milionu paketů za sekundu na Debianu s jádrem 4.14. Ve FreeBSD byla propustnost výrazně nižší, tam jsme se dostali jen asi na jeden milion paketů.
Po vyladění nastavení síťových karet se podařilo v Debianu zvýšit propustnost na 1,7 milionu paketů. Ve FreeBSD nebyl nárůst příliš velký, takže jsme se rozhodli už s tímto systémem nepokračovat.
Dále bylo potřeba zvolit mezi routovacími démony Bird nebo Quagga. Nakonec bylo rozhodování velmi snadné, protože Bird potřebuje o třetinu méně paměti a je také výrazně rychlejší.
Výsledkem je řešení, které dokáže přenášet dvakrát 10 Gbps při 28 milionech paketů a 55% zátěži procesorů. Jakmile se začnou aplikovat například firewallová pravidla, jde výkon velmi rychle dolů. Stačilo přidat jediné pravidlo pro BCP38 a výkon se nám snížil o 400 tisíc paketů za sekundu.
Výhodou vlastního řešení je cena, modulárnost, jednodušší upgrade a otevřenost řešení. Můžeme kdykoliv měnit karty za jiné nebo přenést konfiguraci na jiný hardware.
Naopak nevýhodou je nižší výkon při složitější konfiguraci, vyšší náročnost na správu, obtížnější testování a chybějící komerční podpora. Nemáme k tomu žádnou podporu, takže když hledáte správce, nestačí vám jen správce sítě, ale potřebujete i linuxového administrátora.
Ondřej Filip: Bird 2.0.x
Projekt Bird začal na Karlově univerzitě v roce 1998 jako seminární práce. Na začátku vývoje nebylo příliš mnoho konkurentů, ale vývojáři se hned rozhodli být velmi progresivní a vytvořit nejlepšího routovacího démona. Poté projekt spal a jeho reinkarnace přišla mezi lety 2003 a 2006. Plně se začal vyvíjet až v roce 2008, kdy se Bird stal projektem Laboratoří CZ.NIC.
Zajímavé je, že původně se vývojáři domnívali, že IPv4 je na konci svého života. Proto se rozhodli podporu pro čtyřku a šestku rozdělit pomocí kompilačních parametrů, kdy se kompilací vytvoří dvě různé binárky. Dnes je Bird multiplatformní, podporuje IPv4 i IPv6 a podporuje celou řadu routovacích protokolů. Srdcem Birdu je protokol PIPE, který umožňuje démona využít mnoha různými způsoby.
PIPE dovoluje propojovat různé protokoly, na které Bird pohlíží jako na samostatné routery.
Konfigurace probíhá pomocí vlastního jazyka, který je od začátku koncipován velmi flexibilně. Je to vlastně malý programovací jazyk, takže je velmi mocný a můžete v něm ovlivnit mnoho věcí.
Bird má také klasické ovládací rozhraní, ve kterém je možné prohlížet routovací tabulky, restartovat jednotlivé protokoly a podobně. Také tady je možné používat filtrovací jazyk, který se kompiluje do bytekódu.
Bird je nasazen na route serverech v NIX.CZ. K tomu se všichni účastníci připojí pomocí BGP a cokoliv mu pošlou, on zase přepošle všem ostatním. Velmi to zjednodušuje přístup novým členům, kteří se připojí k jednomu serveru a mohou začít peerovat s ostatními.
Pomocí signalizace přes BGP community je možné řídit, kterým sítím se propagují které routy. Tohle některé sítě vyžadují, jinak by se vůbec nepřipojily.
Bird je dnes ve více než dvou třetinách peeringových uzlů na světě. Už se naopak diskutuje o tom, jak to udělat, aby Bird neměl takový monopol. Pokud by se objevila nějaká chyba, mohli bychom přijít o velkou část provozu.
Uvažuje se nad tím, že by komunita podpořila vývoj OpenBGPD.
Současnou stabilní verzí je 1.6.4, která má dlouhodobou podporu a už do ní nebudou přibývat velké novinky. Hlavní vývoj nyní probíhá ve verzi 2.0.x, která zásadně mění interní struktury. To nám umožnilo propojit dohromady IPv4 a IPv6 svět do jednoho démona.
Zároveň proběhlo několik změn v konfiguraci.
Michal Krsek: budoucí nároky videa na sítě
Video se na internetu sleduje stále ve větší míře. V největších špičkách máme zhruba 160 000 souběžně sledujících diváků, což generuje více než 500 Gbps provozu.
Diváci disponují zařízeními a konektivitou, která dovoluje přehrávání HD obsahu: počítače, televize, tablety a mobily. Postupně se také do IP připojují i televizní přijímače.
Přestože dříve všichni přísahali na uživatelský obsah, třeba na YouTube, nejde o nijak významný zdroj toků. Podle Krska jde totiž o tak krátká videa, že se vytvoří toky v jednotkách gigabitů za sekundu. Zajímavější už jsou filmy a seriály, které mají stopáž v desítkách minut.
Nárůst toku je ale lineární, protože se sledující uživatelé rozloží v čase. Opět jde spíše o gigabitové toky.
Vyšší čísla se objevují v případě aktuálního zpravodajství, kdy se někdy objeví až exponenciální nárůst. Typicky když někdo zemře, koná se královská svatba nebo jsou povodně.
Tam už jde o desítky gigabitů za sekundu.
Nejnáročnější jsou pak exponované živé přenosy, které mají hodinové stopáže – typicky sportovní přenosy. Pokud se hokejisté dostanou do finále, je to špatné. Vždycky to jsou stovky gigabitů a vždycky se objeví problémy.
Video se tradičně distribuovalo pomocí IPTV, které je pod kontrolou ISP a je možné jej šířit multicastem. Pak se ale objevila OTT distribuce, která běží unicastem a není možné ji řídit ze strany ISP.
Všechno dnes běží po HTTP, ať už po HLS nebo MPEG-DASH. V nejhorším případě to běží v TLS a vám se najednou nahrne z některého směru spousta dat a vy nemůžete dělat vůbec nic.
Největším zpomalovačem růstu v této oblasti je prozatím malá penetrace HbbTV aplikací, chybějící obchodní model, omezování kvality pro koncové uživatele v exponovaných časech a snaha o zpoplatnění IP vysílání. Velkou roli hraje také omezování dostupnosti obsahu po IP, ať už časové nebo geolokační.
Na druhé straně pomyslné vysílací cesty jsou poskytovatelé obsahu, kam patří provozovatelé webů a broadcasteři. Webaři se snaží monetizovat video jako web, ale zatím pro něj mají málo obsahu.
Naopak broadcasteři vyrábějí hodně atraktivního obsahu, mají atraktivní práva a vnímají distribuční model stejně jako u broadcastu. IP je pro ně zatím jen doplněk, ale chtějí růst.
Mezi klasickým bradcastem a IP jsou ale velké rozdíly. Zatímco o u klasického šíření je kvalita nezávislá na počtu diváků, u IP je potřeba síť vhodně dimenzovat. Stejně tak už neplatí, že jeden operátor kontroluje celou přenosovou cestu. Najednou je tu řada sítí po cestě k divákovi.
Dostáváte se také do heterogenního ekosystému s propojovací infrastrukturou. Operátoři po cestě mohou mít i jiné zájmy.
Co nás tedy v budoucnu čeká? Určitě to bude rozvoj HbbTV, vstup dalších vysílatelů a netradičních obchodních modelů, migrace vysílatelů na IP a přechod na HD od 1080p až po 4K s HDR. Objeví se i nové síťové technologie jako QUIC-FEC či multipath, které řeší například zpoždění, ale problém s kapacitou zůstává. Příští olympiáda by mohla dosáhnout terabitu. Položte si otázku, zda to vaše síť zvládne.
Petr Špaček: bude vaše doména fungovat i v roce 2019?
Výrobci DNS serverů se rozhodli, že je na čase přestat podporovat některé zastaralé vlastnosti rozbitých serverů. Ke změně dojde 1. února 2019, kdy například budou vynucovány správné odpovědi na EDNS dotazy. Pokud server EDNS neumí, musí odpovědět chybou FORMERR.
Podpora EDNS stále není vynucována, ale server nesmí potichu dotaz zahodit, protože takové chování pak znamená složitou logiku na resolveru, který se musí začít ptát znovu. Nerozliší, jestli server zahodil EDNS dotaz sám nebo došlo k nějaké chybě. Tohle chování způsobuje řadu problémů a tvůrci resolverů se ho rozhodli nadále neřešit na své straně.
Už teď je možné si otestovat vlastní autoritativní servery pomocí nástroje dnsflagday.net, kam se do formuláře vloží doména a výsledkem je ověření funkčnosti. Podle současných zjištění je problém jen u 0,4 % domén v .CZ a 60 % rozbitých domén běží u dvou poskytovatelů. Pokud to tihle opraví, budeme skoro z obliga.
Oleksii Samorukov: internetová cenzura v ČR
Internetová cenzura se v Česku objevila 1. ledna 2017, kdy začal platit zákon o hazardních hrách. Byl kritizován řadou společností včetně CZ.NIC, Seznamu, NIX.CZ a dalšími.
Ústavní soud ale rozhodl, že nejde o cenzuru a zákon je platný. Nikdo se ale nezabýval tím, jak se má blokování obsahu provádět.
Seznam je zveřejňován v PDF, které není dobře strojově zpracovatelné. Ministerstvo financí seznam zveřejňuje na svém webu a je potřeba jej pravidelně stahovat a kontrolovat. Adam Schubert ale s použitím nástroje Tabula vytvořil web, na kterém zveřejňuje strojově čitelnou podobu.
Samorukov provedl vlastní měření blokování pomocí 258 českých sond z projektu RIPE Atlas a dostal 403 odpovědí, protože některé sondy mají více DNS resolverů. Z dat plyne, že v 61 % sítí nejsou domény na seznamu blokovány. Ovšem ne všechny sondy jsou v uživatelských sítích a nejsou rovnoměrně distribuovány.
Andrzej Wolski: Routing Security Toolset
V počátcích velkých sítí neexistovaly žádné routovací protokoly, používaly se staticky konfigurované sítě partnerů, kteří spolu potřebovali a chtěli komunikovat. V roce 1989 byl standardizován protokol BGP, na kterém dnes stojí celý internet. Od té doby vzniklo několik verzí a několik různých rozšíření.
BGP funguje tak, že si jednotliví partneři předávají informace o svých sítích. Jsou označení pomocí ASN a vzájemně si předávají informace důležité pro routing. Řeší se i to, kam poslat data, pokud existuje více cest. Pak se volí podle délky cesty. To je v zásadě všechno, co v praxi potřebujete o BGP vědět.
Bohužel, součástí standardu nejsou žádná bezpečnostní opatření. V té době platilo, že když jste operátor, jste důvěryhodný.
Znáte číslo AS daného operátora, ale osobně ho neznáte a nevíte nic o jeho záměrech. Kdokoliv může do BGP sítě ohlašovat jakékoliv IP adresy. Nehody se prostě stávají, stačí překlep na klávesnici.
Poměrně častá jsou různá porušení pravidel, kdy se do veřejného internetu ohlašuje něco, co do něj nepatří. Neslavný je incident pákistánského Telekomu, který chtěl v zemi vypnout YouTube a místo toho ho vypnul pro celý svět.
Ještě horší jsou úmyslné útoky. V dubnu 2018 byly například pomocí BGP uneseny DNS servery Amazonu, jejichž komunikace byla dvě hodiny směrována do jiné sítě. Cílem byla kryptopeněženka MyEtherWallet, ze které útočníci kradli peníze.
Neexistuje žádná BGP policie, zbývá vám jen čekat na nápravu. U velkých firem to zpravidla trvá hodiny, u těch malých mnohem déle.
Incidenty jsou v této oblasti běžné, jen v loňském roce jich bylo přes 14 tisíc a postihly 10 % světových AS. Můžeme dělat něco víc než jen hasit problémy? Existují registry, ve kterých jsou zaznamenány vazby mezi IP adresami a ASN. Existuje jich mnoho, například RIPE Database nebo RADB. Uživatel je známý, je našim členem. Na základě tohoto prověření pak může přidávat vlastní záznamy.
Ostatní pak mají možnost ověřovat údaje získané z BGP právě v těchto databázích a přijímat jen prověřené údaje.
Kdo to ve skutečnosti dělá? Obvykle různé peeringové uzly, jako NIX.CZ. Tranzitní operátoři ale podle těchto databází nefiltrují, protože mají na obou stranách velké množství zákazníků. Mají tam často stovky nebo tisíce sítí, které z různých směrů ohlašují různé prefixy.
Dalším problémem je, že data v těchto databázích nejsou vždy naprosto přesná.
Dalším řešením je zavedení elektronického podpisu s veřejnými klíči (PKI) do routování (RPI). Propojuje IP adresy a ASN s veřejnými klíči.
Výsledkem jsou digitálně podepsaná oznámení, která jsou pak zveřejňována v databázi. Výhodou je, takto posbíraná data jsou velmi přesná. V Česku je takto pokryto zhruba 23 % záznamů.
Ignas Bagdonas: BGP transport security
BGP je z transportního hlediska nezabezpečené a rozbité. MD5 je považováno za nebezpečné už mnoho let, přesto jej stále pro routovací protokoly používáme.
BGP bylo navrženo tak, aby mohlo běžet nad jakoukoliv transportní technologií, dnes se nejčastěji používá ve spojení s TCP. BGP samo o sobě nemá žádný mechanismus pro validaci důvěrnosti nebo integrity.
Útoky na TCP jsou triviální, stačí odhadnout okno nebo se podívat do provozu. Pokud se takto podaří resetovat TCP sezení, můžeme způsobit vyšší zátěž na routerech. Je tu snaha vytvořit nadstavbové bezpečnostní mechanismy, ale rozbitá je bezpečnost samotného protokolu. Nač mít dobře zamčené dveře, když vám v domě chybí zadní zeď?
Co s tím? Existuje několik řešení: funkční TCP-MD5, které je ale považováno za rozbité; enhanced TCP-MD5, které je ale podporováno jen úzkou skupinou dodavatelů; TCP-AO řeší všechny problémy, ale v praxi ho nikdo neimplementoval. Existuje několik proprietárních mechanismů, které ale nejsou veřejně dostupné.
Dodavatelé se vymlouvají na to, že žádné pořádné řešení zákazníci nechtějí. Jednoduše jim to funguje, takže nemají potřebu potenciální problém řešit.
Přesto je možné se chovat tak, abychom minimalizovali rizika, především je důležité mít dobře navrženou síť. Bezpečnost protokolu není náhradou za bezpečný návrh sítě.
Existuje několik návrhů budoucího řešení: je možné použít TLS, komplexní IPsec nebo definovat nový transportní protokol pro BGP. QUIC je nový transportní protokol, který je velmi slibný. Kombinuje UDP a TLS a možná by vyřešil všechny problémy najednou.
Thomas Weible: transceivery pro 400G
Technologie 100GE je tu už nějakou dobu, je vyzrálá a jednoduše funguje. Další generace bude pracovat na rychlosti 400 Gbps. Optický transceiver se vždy skládá ze dvou částí: elektrické a optické.
Elektrická část převezme signály a přemění je v optický signál. 400GE používá modulaci PAM4, která umožňuje v jednu chvíli přenést dva bity místo jednoho. Tím se v každém kanále přenáší 56 gigabitů, přičemž se použije celkem osm laserů k odeslání osmi signálů.
Vylepšením optických komponent je možné zvýšit rychlost na 112G, čímž pak stačí přenášet jen čtyři signály. Vyžaduje to ale také zrychlení na straně elektroniky, což je opravdu složité, protože pracujeme se signály na vysokých frekvencích.
Použít je možné transceivery typu QSPF-DD nebo delší OSFP, jejichž příkon je 12 a 15 wattů. Většina výrobců preferuje QSPF-DD, nejen kvůli zpětné kompatibilitě.
Jednotlivé signály je možné také rozdělit a připojit do 100GE přepínače pomocí starších transceiverů. První nasazení by se měla objevit ještě letos. Uvidíme, jestli to bude v létě nebo až na podzim.
Zdeněk Brůna: zvyšujeme bezpečnost provozu .CZ DNS
Autoritativní servery domény .CZ používají anycast, což umožňuje používat více serverů s jednou IP adresou. Dotazy se pak pomocí BGP dostanou do nejbližší lokality, což rozkládá zátěž, snižuje latenci a umožňuje v případě problému odklonit provoz jinam.
CZ.NIC má tři lokality v Česku a osm dalších po celém světě. V Česku bude na konci roku 67 serverů, v zahraničí jich je plánováno 28.
Síť CZ.NICu je od začátku předimenzovaná, ale nároky na DNS rostou každý rok o 5 až 10 %. Původně bylo vše nastaveno na limit 20 milionů dorazů za sekundu, nyní je snaha dostat se na 100 milionů. Zároveň roste kapacita linek, původně to bylo okolo 60 Gpbs, nyní jsou servery připojeny pomocí 200 Gbps. Hlavní motivací je zvyšující se počet DDoS útoků a dopady nefunkční domény by dnes byly fatální.
Cílem je posilovat diverzitu hardware, aby chyba v jednom serveru nebyla fatální pro celý cluster. Patří do toho i geografická a síťová diverzita.
Stejně tak se liší operační systém, routovací démon a DNS server.
Autoritativní servery je možné umisťovat také přímo do sítí poskytovatelů připojení, přičemž se do sítě oznamuje anycastový prefix. Tento prefix se neohlašuje do internetu, ale zůstává jen v síti poskytovatele. Platí tu Paretovo pravidlo, takže když pokryjeme ty největší poskytovatele, odbavíme tak 80 % provozu.
Hlavním cílem je zajistit funkčnost domény i v případě, že primární cluster přestane fungovat, třeba vlivem útoku. Že to zároveň snižuje latenci, je spíš vedlejší efekt.
Servery jsou v současné době už připojené v sítích Vodafone a Seznamu, přičemž odbavují stovky dotazů za sekundu. Jsou tu i další zájemci: Cesnet, Cetin, Casablanca, O2, T-Mobile a Master Internet. Není to úplně snadná a rychlá záležitost, většinou to narazí na management firmy, která v tom na rozdíl od techniků nevidí přínos a nechce to platit.
Karel Holek: vizualizace výsledků měření pokrytí
ČTÚ má víc možností, jak získávat data o pokrytí mobilními sítěmi. Jednou z nich je crowdsourcing pomocí aplikace NetMetr, další možností jsou profesionální měření s přesně stanovenou metodikou. Je také možné simulovat pokrytí podle rádiových parametrů. Nemůžete ale simulovat QoS parametry sítě.
Úřad měl doposud velmi malé oddělení, které se měřením zabýval, to se nyní mění. Byli to jen dva lidé na celou republiku.
Měření je součástí nového projektu VIS – MSEK a finální produkt bude rozšířen o srovnávání dat z různých zdrojů. Data budou poté veřejně dostupná na webu.
Surová data z měřicích terminálů se ukládají do databáze a analytici je mohou využít pro specifické analýzy. Navíc můžete databázi napojit na další aplikace, třeba pro tvorbu datových sad a webových map pro veřejnost.
Po uložení dat do databáze také probíhají různé korekce a redukce naměřených bodů. Naměří se několik hodnot každou sekundu a ty nemusíte všechny ukládat. Proto provádíme automatizovaný výběr a také redukujeme počet bodů v určité oblasti.
Pokrytí je pak možné vztáhnout nejen k oblasti, ale také například k počtu obyvatel.
Naměřená data budou časem dostupná na novém responzivním webu, kde bude k vidění kompletní mapa pokrytí, možnost filtrace podle operátorů a ke stažení bude i část dat pro další zpracování. Uživatel si bude moci vybrat, která data chce a dostane připravený balík omezený na vybranou oblast a čas.
Nejdůležitější ale je, že se naměřená data využívají k vyhodnocování pokrytí podle parametrů daných licencí. Doposud jsme to řešili jen simulací, ale z těch nevyčtete vše.
Miroslav Slugeň: hromadný sběr anonymizovaných dat pomocí Kolektoru
V posledním roce velmi rychle přibývá uživatelů, kteří sledují televizi pomocí OTT. V předchozích letech to byly maximálně desítky tisíc uživatelů, dnes už to jsou stovky tisíc.
Služba Sledování.TV se tedy začala zabývat tím, jak sbírat informace o provozu celé sítě a jejím vývoji. Podporujeme celou řadu různých zařízení, takže potřebujeme sbírat data ze set-top-boxů, mobilů, webových prohlížečů a podobně.
Dat se sbírá velké množství, u každého zařízení jsou to desítky kilobytů za hodinu. Hlavním cílem je sjednocení hlášení chyb a debuging na různých aplikacích.
Sbírají se statistická data, verze klientů, co daný klient sleduje a podobně. Data jsou zašifrována a putují do collectoru, který je dimenzován tak, aby zvládal velké množství spojení.
Z dat je pak možné zjistit, kolik lidí se dívá na konkrétní kanál, kdy se objevila chyba, zda uživatel zadal chybný PIN a podobně. Často se nás partneři ptají, zda bychom jim nemohli říct, jestli není zrovna problém s videem u nich. Chceme tedy nabídnout automatizované hlášení, které bude vygenerováno bez zásahu naší podpory.
Autorem fotografií je Roman Prachař.
