Lefteris Manassakis: BGP monitoring
Monitorovací platforma pro BGP by neměla záviset pouze na veřejných zdrojích. Je to především kvůli dostupnosti, protože tyto zdroje mohou mít výpadky a být pro vás nedostupné.
Pokud máte data pod vlastní kontrolou, můžete zlepšit jejich kvalitu a můžete zabránit například skrytí některých pokusů o únos. Útočníci se snaží únosy dělat tak, aby se vyhnuli detekci ve veřejných databázích.
Vlastní sběr dat je možné provádět na mnoha různých místech, ze stovek různých ASN zapojených do peeringu. Můžeme tak zjistit spoustu podrobností a o každé aktualizaci v BGP pak víme, z jakého ASN pochází a z jaké IP k nám přišla.
Data v místní databázi jsou navíc dostupná vždy a okamžitě.
Poskytovatelé informací o BGP by měli splňovat několik kritérií: musejí poskytovat konektivitu po IPv4 i IPv6, mají globální působnost a nabízejí automatizovaný přístup. Potřebujeme také informace téměř v reálném čase. Jakmile je oznámen nový prefix, chceme jej vidět v řádu sekund.
Odstranění prefixu trvá výrazně déle, obvykle v řádech několika minut.
Pro zpracování dat z BGP je možno využít v Česku vyvíjený nástroj BIRD, který má minimální požadavky na paměť a má velmi vyspělou a zralou implementaci BGP. Jsme v něm schopni párovat IP adresy na jednotlivá ASN.
Bijal Sanghani: budoucnost propojování
Euro-IX je sdružení evropských propojovacích uzlů, které má v současné době přes 70 členů. Našimi patrony jsou technologické společnosti a poskytovatelé připojení.
Každý rok organizace pořádá dvě mezinárodní setkání doplněné o workshopy a hackatony.
Organizace nabízí řadu nástrojů a komunitních projektů, poskytuje informační servis pro své členy a udržuje vlastní databázi IXPDB (Internet eXchange Point Database). Peering Toolbox je zaměřen na získávání nových informací, které umožňují lepší rozhodování při budování vlastní sítě. Už peerujícím organizacím umožňuje učit se novým postupům a řešit problémy s konektivitou a dostupností.
Euro-IX má také pracovní skupinu k RFC8950, které se zabývá IPv4 BGP routami, které mají IPv6 next-hop. Vytvořili jsme vlastní testovací prostředí, ve kterém můžeme testovat kompatibilitu jednotlivých dodavatelů.
Cílem je odpovědět na různé související otázky, například zda konkrétní implementace vyžaduje nějakou speciální konfiguraci.
Julie Liu: heterogenní data k řešení problémů a zlepšení výkonu
Při správě BGP se musíme zabývat monitoringem a optimalizací datových toků, ale také koordinací peeringu podle politiky jednotlivých sítí. Ty mohou mít politiku uzavřenou, výběrovou či otevřenou. Peering nikdy není zadarmo, vždycky jsou tu poplatky za linky, porty a další služby.
Je třeba tedy správně vybírat, s kým se budeme propojovat.
Prvním kritériem je množství dat, která si s některou sítí vyměňujeme. Musíme také ale sledovat poměr odesílaných a přijímaných dat.
Poté si můžeme položit otázku, zda nám dává ekonomicky smysl síť rozšířit. Musíte zhodnotit, jestli pro vás bude výsledek levnější než současný tranzit.
Pro optimalizaci je třeba také podrobně monitorovat datové toky, abychom věděli, odkud a kam přenášíme jaké množství dat. Sběr dat a čísel nám pak umožňuje datový provoz efektivně ovládat.
Můžeme pak také ověřit, že naše úpravy mají očekávaný dopad a jsou dostatečně efektivní.
Jad el Cham: peering na Blízkém východě
Původně se Blízký východ připojoval k peeringu především do Evropy. Šlo o mezinárodní i vnitřní propoje, bylo to jednodušší a levnější.
Také obsah byl obvykle šířen především z Evropy, takže i z tohoto pohledu to dávalo smysl.
Velkým problémem Blízkého východu je nedostatečná kapacita podmořských kabelů v Rudém moři, což vytváří úzké místo. Navíc je celá tato oblast válečnou zónou, což komplikuje možnost posílení či opravy poškozených vedení.
Proto se hledají alternativní cesty po pevné zemi přes Turecko, Saúdskou Arábii a dále na západ.
Postupně se tedy mění způsob propojení jednotlivých sítí, ale také se posouvá byznys. Velké firmy jako AWS nebo Google nyní v oblasti investují a další se na to chystají.
Řeší se také otázka místní výměny dat, aby nebylo třeba posílat provoz složitě přes Evropu a zpět.
RIPE NCC v současné době zaznamenává v této oblasti přes 22 tisíc sítí (LIR). V současné době je největší brzdou nedostatek IPv4 adres, proto roste využití IPv6.
Například Saúdská Arábie nebo Spojené arabské emiráty mají dnes více než polovinu uživatelů připojených po IPv6.
V posledních letech roste také výrazně počet peeringových uzlů. Zatímco v roce 2007 existoval jediný, dnes je jich více než deset. Musejí se potýkat s řadou problémů jako jsou regulace a problémy s připojením přes hranice.
V některých zemích musejí peeringové uzly získat plnohodnotnou licenci pro poskytovatele připojení, což je velmi náročné. Výrazně by pomohly samostatné licence jen pro peeringové uzly.
Úspěšný propojovací uzel by měl držet data lokálně, měl by zajímat velké globální hráče, snižovat latence a zlepšovat stabilitu. Ne všechny uzly tyto požadavky splňují, ale situace se postupně zlepšuje.
Ben Ryall: novinky v PeeringDB
PeeringDB je nezisková komunitní databáze peeringových uzlů a datacenter, kde je možné zjistit, kde a za jakých podmínek se lze s někým propojit. V poslední době bylo vylepšeno uživatelské rozhraní a přibyla možnost exportu dat ve formátu KMZ. Ta je možné poté použít například v Google Mapách.
Vylepšeno bylo také vyhledávání, které nyní umí lépe pracovat s umístěním objektů. Stále nás zajímá zpětná vazba od uživatelů, podívejte se na beta verzi a dejte nám vědět.
Organizace hledá také dobrovolníky, kteří budou odpovídat na uživatelské dotazy a budou přicházet s nápady na další vylepšení.
Matěj Pavelka: výhody Flow hned vedle SNMP
V konkrétní velké firmě zaznamenali podivné problémy s latencemi, které trvaly vždy přibližně 10 minut a opakovaly se každou hodinu a půl. Kontaktovali proto svého poskytovatele, který se snažil zjistit, co je špatně. Používal k tomu Zabbix, MikroTik Winbox a Smokeping. Na konci dne stejně nebyli schopni problém objevit, ani zjistit jeho příčinu.
Problém se ale opakoval, až nakonec zákazník změnil poskytovatele.
Druhý zmíněný problém se objevil u velkého poskytovatele, který dostal informace o narůstající latenci na jednom z centrálních routerů. Anomálie se objevovala a mizela v periodách, tok nepřekračoval schopnosti routeru.
Pomocí běžných zdrojů dat se nepodařilo zjistit příčinu.
Podstatně více informací než ze SNMP je možné zjistit z Flow, kde bylo možné vyfiltrovat konkrétní místa v síti a ujistit se, že jde skutečně o anomálii s vlivem na datový tok. Je možné vše rozdělit podle zemí, sítí či protokolů – všechno bylo v pořádku.
Při podrobnějším pohledu na vytížení portů se ukázalo, že ze zdrojového portu 53 pochází více provozu než ze 443, což nemusí být nutně špatně, ale je to podezřelé a stojí to za další průzkum.
Je proto potřeba se podívat na běžný provoz a porovnat ho s dobou, kdy se objevují problémy. Ukázalo se, že v dané části sítě se běžně vyskytuje zhruba tisícovka komunikujících stran, přičemž během problematické doby tento počet vyrostl na 22 tisíc. Rychle tak byl odhalen DDoS útok pomocí odražených DNS dotazů.
Ten už bylo možné zarazit pomocí RTBH nebo BGP Flowspec a informovat klienta o špatně nastaveném serveru náchylném k odrazům.
Pro řešení těchto situací je lepší používat jeden nástroj, ve kterém se scházejí data z mnoha zdrojů. Je jedno, jaký nástroj použijete, ale cílem je používat jednotný systém, který má k dispozici všechny informace.
Důležitá je flexibilita použitého řešení, které dovoluje vytvářet potřebné pohledy napříč různými zdroji dat.
Zach Flom, Jon Morgan: trendy v odražených útocích
Odražené DNS útoky jsou naprosto běžné a jsou umožněny použitím transportního protokolu UDP, u kterého je velmi snadné podvrhnout adresu odesílatele. Je to velmi efektivní, protože stačí poslat velmi malý dotaz a poslat tím směrem k oběti velké množství dat.
V jednom útoku bylo zaznamenáno až 130 tisíc zapojených IP adres.
Většina útoků se zaměřuje na Severní a Jižní Ameriku, přibližně čtvrtina útoků pak směřuje do Evropy. Zesilující faktor se obvykle pohybuje mezi 60 a 100násobkem. To je pro útočníka velmi dobré.
Byly zaznamenány i útoky na síťové prvky, které pak útočník záplatoval, aby zabránil někomu dalšímu v napadení, a poté spustil vlastní veřejný DNS resolver pro další zneužití.
Všechny podobné útoky zneužívají toho, že útočník dokáže zfalšovat zdrojovou IP adresu oběti. Řešením je nasazení doporučovaných postupů ze známého dokumentu BCP38, který doporučuje blokovat falešný odchozí provoz. Z takového odchozího provozu totiž nemá užitek nikdo jiný kromě útočníka.
(Autorem fotografií je Marko Iglić.)
ČLÁNKY DO MAILU