Matyáš Kroupa: Segment Routing v Birdu
Směrovací tabulky ve velkých sítích neškálují, což se typicky řeší pomocí MPLS, ale to zase zavádí spoustu nových protokolů. Administrátorům pak došlo, že by chtěli dělat traffic engineering.
Proto vznikl Segment Routing, což je evoluce MPLS a jde tedy o formu source routingu.
Cesta je zvolena při vstupu do sítě a jednotlivé routery se pak jen řídí předem připraveným seznamem hopů. Tomu se říká síťové programování, protože součástí mohou být další instrukce.
Jako control plane se použije OSPF nebo IS-IS, jako data plane pak buď MPLS nebo IPv6 pomocí SRv6.
V případě SRv6 se pak jako segmenty používají IPv6 adresy, které jsou zakódovány do rozšiřující hlavičky. Segmenty jednoho uzlu se sdružují do lokátorů jako IPv6 prefixy.
Při implementaci do Birdu bylo jako control plane použito OSPF, protože Bird nepodporuje IS-IS. Původní OSPF má ale fixní LSA a pokud se mají vytvářet nové položky, musí se vytvořit nové LSA odkazující na původní informace. Ono to ale neškáluje a jsou s tím další problémy.
Proto vzniklo rozšířené LSA používající TLV (Type Length Value), ale není zpětně kompatibilní s původní variantou.
Implementace zahrnuje nové datové struktury pro LSA a TLV, validaci, zpracování přijatých LSA, generování LSA, možnost konfigurace a výpis informací na CLI. Snažil jsem se vše udělat tak, aby to zapadalo do standardní konfigurace.
Testování proběhlo pomocí GNS3, kdy byla postavena virtuální síť konfigurovaná pomocí Ansible a běžící na standardní Fedoře. Mám uzavřenou síť s IPv6, která je natovaná do internetu.
Celá implementace má asi 3200 řádek kódu, asi třetina toho byla napsána na cestách autobusem.
Alexander Zubkov: Diagnostika multipath tras
Směrovač typicky vybírá jednu nejlepší cestu a tu pak pořád používá. Může se ale stát, že považuje za nejlepší několik cest.
V takovém případě pakety pro jeden cíl putují různými cestami, což přináší řadu problémů například s anycastem.
Nejlepším způsobem řešení je výběr cesty podle haše vytvořeného ze zdrojové nebo cílové IP adresy, protokolu, portu, flow id v IPv6 nebo položek v tunelovacích protokolech. K běžným problémům patří, že je některá z cest rozbitá, ztrácejí se pakety nebo máme potíže s balancováním.
Pro diagnostiku je možné použít jednoduché nástroje jako ping, telnet nebo curl, abychom zjistili, jestli komunikace mezi jednotlivými uzly funguje. Pro podrobnější informace je nutné používat nástroje jako mtr nebo trippy, pro složitější situace je pak nutné sáhnout po tcpdumpu nebo Wiresharku. Nástroj mtr je vlastně lepší traceroute, který dělá více pokusů a je možné u něj nastavit mnoho věcí.
Je třeba pamatovat na to, že některý router může mít limit na ICMP, takže pokud ztrácí pakety, neznamená to, že má nějaký problém. Směrování může být asymetrické, takže je potřeba provádět testy z obou stran a zkoušet také různé protokoly. ICMP může jít například mimo problémovou trasu, ale při použití UDP se začne část provozu ztrácet.
Thomas Holterbach: Novinky o bgproutes.io
Routery sdílející veřejně svoje BGP routy jsou jako družice sledující povrch Země. Každý z nich poskytuje informace jen o části povrchu.
Pro diagnostiku ale potřebujeme znát podstatně širší obrázek. Existují proto různé nástroje, které sbírají data o BGP z mnoha zdrojů.
Provozovatelé podobných služeb se musejí rozhodnout, zda sbírat hodně dat, nebo je ukládat po dlouhou dobu. Ukládat mnoho dat je velmi drahé, proto je potřeba si ujasnit priority.
Před rokem byla spuštěna nová služba bgproutes.io, která se zaměřuje na sběr co největšího množství dat v reálném čase. Snažíme se maximálně zjednodušit a automatizovat sběr dat od různých operátorů.
Přihlásit je možné se pomocí účtu v PeeringDB.
Cílem není soupeřit s ostatními platformami, každá z nich má nějaké výhody a nevýhody. Snažíme se posbírat data ze všech existujících platforem a centralizovat je v jednom unifikovaném repozitáři.
V tuto chvíli služba sbírá data z více než 5000 různých míst, v Česku je jich sedm. Více bodů v Česku by nám pomohlo.
Když některý operátor začne do takové služby přispívat, předává jí jen část svých rout, protože BGP jich hodně schovává. Vidíme jen nejlepší a nefiltrované cesty, které jsou do platformy oznamovány.
Všechny ostatní routy pak nejsou viditelné, ale právě v těchto datech mohou být zajímavé informace, jako třeba únosy prefixů.
Jako řešení se nabízí BMP (BGP Monitoring Protocol), který umožňuje sbírat routy ve všech fázích zpracování na routeru. Je tak možné sbírat data už ze vstupních BGP relací. Platforma pak vidí stejná data, jako by měla navázané BGP relace se všemi sousedními routery.
Pro uživatele je pak k dispozici dashboard, s jehož pomocí je možné sledovat celou řadu charakteristik. Snažíme se o co nejbližší přístup ke všem datům.
Celý web je silně konfigurovatelný a dovoluje přistupovat k datům také pomocí vlastních SQL dotazů.
Ondřej Caletka: ASPA: nový způsob zabezpečení protokolu BGP
Protokol BGP je tu s námi už velmi dlouho a je postaven na důvěře. Nemá žádné šifrování ani autentizaci, což funguje jen do chvíle, kdy má někdo zlé úmysly.
Útočník může například ohlašovat lepší cesty a tím ovlivnit provoz.
Už poměrně dlouho existují Internet Routing Registries, kde se může směrovač zeptat, jestli mohou dané prefixy přicházet z konkrétního ASN. Tyto informace se nacházejí například v RIPE Databázi, odkud je možné si informace stahovat a nastavit podle nich filtry. Stejně tak je možné definovat Routing Policy, kdy můžete k autonomnímu systému uložit jeho směrovací politiku.
Tohle už máme, je to užitečné, ale má to své problémy. Takových databázi je mnoho a jsou nekonzistentní, ne všechny mají například kontrolu držitelů adres.
V databázích se často vyskytují zastaralá data a každý operátor si drží vlastní kopii, podle které si nastavuje filtry. Data se stahují z neověřených zdrojů nešifrovaným protokolem a pak podle nich nastavujeme routery.
Lepším řešením je RPKI (Resource Public Key Infrastructure), což je jednotný systém využívající standardní certifikáty, které ale nejsou vázány na web, ale na IP adresy a ASN. Jde o jednu velkou databázi, která je jednotná a strojově zpracovatelná.
Držitel adresních prostředků může získat certifikát, s jehož pomocí pak podepisuje různé informace.
Tato infrastruktura se pak používá pro BGP OV (Origin Validation), BGPsec a nejnověji také pro ASPA (Autonomous System Provider Authorization). Ta říká, který poskytovatel je autorizovaný k tomu, aby byl poskytovatelem pro náš autonomní systém. Když tyto informace někdo vystaví na internetu, někdo jiný si je může stáhnout, ověřit podpisy a následně nastavit filtry.
Proti původnímu řešení máme vše digitálně podepsané a můžeme získaným informacím věřit.
ASPA tedy řeší validaci cesty, jde o objekt obsahující číslo autonomního systému a sadu čísel autonomních systému, o kterých prohlásím, že jsou moji poskytovatelé konektivity. Takový objekt může vytvořit jen držitel čísla zdrojového autonomního systému.
V případě validace se pak zkontroluje každý AS-to-AS hop a zjistíme, zda AS je poskytovatel, není poskytovatel nebo je jeho role neznámá. Pokud se pak mezi námi a naším zákazníkem objeví cesta, která nevede přes potvrzeného poskytovatele, stalo se něco špatného a cesta není platná. Můžeme říct, že danou cestu zahodíme a nebudeme ji používat.
Celá validace pak funguje systémem valley free routing, tedy směrování bez údolí. Předchází se tomu, aby se v hierarchii sítí neměnily směry a aby tak data neputovala neoptimálně nahoru, dolů a nahoru. Router se snaží najít cestu jen po relacích, které nejsou not provider.
Hledá se směr v obou směrech a pokud se vybrané cesty setkají, je všechno v pořádku. Pokud je mezi nimi „údolí“, jde o neoptimální cestu, která se nebude používat.
Stačí, aby ASPA nasadili tranzitní operátoři a už to celé začne fungovat. Pokud to ale bude používat více sítí, bude to samozřejmě lepší.
Do ASPA patří všichni vaši poskytovatelé, včetně záložních. Naopak tam nesmějí být vaši partneři v peeringu.
Tomáš Procházka: Automatizovaný upgrade Network OS v datacentrech
Síť Seznam.cz se postupně rozrostla z několika desítek až na 420 switchů. Aktualizace se prováděly postupně, při různých odstávkách a nejdříve manuálně a později poloautomaticky ve více lidech paralelně. Většina prvků je v přístupové vrstvě, která není redundantní a zařízení byla v různých verzích. Vznikla tak pěkná zoologická zahrada, kterou bylo potřeba nějak srovnat. Tohle už ručně nedokážeme aktualizovat.
Celá aktualizace je rozdělena do několika kroků a automatizačních skriptů. V přípravné fázi se posbírají informace o aktuálním stavu, které se pak předávají do dalšího kroku, ve kterém se nahrávají image, promazávají se zbytečné věci a ověří se kontrolní součty. Na základě verze NXOS se pak provede aktualizace nebo meziaktualizace, pokud je potřeba.
S tím souvisí řada kontrol stavu sítě, ztišení poplachu v monitoringu a řada dalších kroků spojených s aktualizací samotnou.
Vyšší vrstva (leaf) je redundantní a jde celkem o 19 párů prvků. Tady pro nás rychlost není tak důležitá.
Navíc tu ale probíhá kontrola stavu před a po aktualizaci, ověří se dostupnost rozhraní a BGP relací. Mezi aktualizacemi jednotlivých prvků se vždy čeká pět minut, aby správci stihli vše zastavit, kdyby se objevily problémy. Běží nám to celé dopoledne a postupně aktualizujeme, což není problém, protože to celé běží samo.
Celkem se aktualizace prováděla 21 aktualizačních dnů rozdělených do jednoho a půl měsíce, problém nastal jen u dvou prvků z 228. Chceme to celé ještě zrychlit.
Řešení je vhodné u velkých a jednoduchých topologií, které se mohou skládat z prvků různých výrobců. Je to velmi flexibilní a lze vyřešit mnoho problémů, které vás mohou při aktualizacích potkat.
Michal Hrušecký: Kdo útočí na Turrisy?
Na počátku projektu Turris byla otázka, zda někdo útočí na běžné uživatele po internetu. Nechtěli jsme vyrábět router, ale chtěli jsme nějakou síťovou sondu, která by sbírala užitečná data.
Nakonec vzniklo zařízení, které bylo zároveň router a uživatelé jej dostali zdarma pro zapojení do své sítě.
Dnes Turris vyrábí a prodává routery, ale pořád je součástí bezpečnostní projekt, který je ovšem volitelný. Nástroj se dnes jmenuje Turris Sentinel a implementuje minimalistické honeypoty simulující HTTP, telnet, SMTP a FTP. Žádají jen útočníka, aby zadal své přihlašovací údaje.
SSH honeypot běží v datacentru organizace CZ.NIC a routery jen slouží jako proxy.
Přehled dat je k vidění na webu projektu Sentinel. Výstupy se používají také pro zpětné učení firewallu, který pak chrání uživatele před známými útočníky.
Od roku 2024 se sbírají také intenzivněji data o IPv6, kterou ale nemají všichni uživatelé. Asi třetina aktualizací probíhá po IPv6.
Vyvstaly tedy nové otázky, například zda útočníci vůbec používají IPv6. Drtivá většina pokusů o přihlášení přichází po IPv4.
Jen 0,013 % pokusů přijde po IPv6.
Většina provozu po IPv4 jsou přihlášení po SMTP, na IPv6 dominuje naopak HTTP. Pokud se adresy útočníků seskupí podle ASN, sníží se poměr SMTP a naroste telnet. Ukazuje to, že útočníci jsou vytrvalí a zkoušejí se přihlašovat opakovaně.
Na IPv4 jsou útočníci vytrvalejší než na IPv6.
Útočníci využívající IPv6 existují, ale je jich výrazně méně a jsou hodnější. IPv6 internet je lepší místo, kde je dobré být.
(Autorem fotografií je Petr Krčmář.)
ČLÁNKY DO MAILU