zdroj: Lupa.cz

BGP komunikace tak byla původně chráněna jen mechanismy protokolu TCP, konkrétně sekvenčním číslem. Později RFC 2385 přidalo mechanismus MD5 autentikace, který začal být poměrně široce využíván. Jeden problém vyřešil, konkrétně možnost relativně snadného „propašování“ spoofovaného RST packetu do běžící BGP relace, jiné problémy přinesl, například větší (až stoprocentní) zátěž CPU postiženého směrovače při různých pokusech o zahlcení nebo brute force spoofing, obtížnou správu hashovacích klíčů při větším množství relací atd.

Částečná obrana přišla následně ve formě tzv. „control-plane policing“ (CoPP), tedy de facto ACL a řízeného ořezávání kapacity mezi „svaly“ a „mozkem“ větších směrovačů. Tento způsob ochrany popsal RFC 6195. CoPP umožňuje ochránit procesory směrovačů před utlučením packety, nicméně díky tomu, že pravidla v access-listech fungují jen do čtvrté vrstvy referenčního modelu ISO/OSI (tedy čísla TCP, UDP apod. socketů, lidově „portů“), některým sofistikovanějším útokům na BGP relace zabránit nemohou.

Dalším nástrojem, který je už delší dobu k dispozici, ale příliš se v praxi bohužel nevyužívá, je GTSM, Generalized TTL Security Mechanism. Tento bezpečnostní prvek využívá kontroly TTL (Time To Live) položky v každém packetu – z hodnoty TTL u každého packetu každý TCP/IP směrovač při průchodu odečte jedničku. U přímých (single hop) BGP relací tak postačuje hlídat, zda příchozí BGP packet má TTL rovno 255 (u nepřímých je to trochu jinak, ale řešitelné to je většinou též). Popsáno v RFC 5082. Na některých platformách je tato funkce implementována pohodlněji, jako jedno klíčové slovo při konfiguraci BGP relace, někde to bohužel je nutné propsat do strukturovaných filtračních pravidel na CoPP nebo fyzických rozhraních (například v JunOSu) a tento nedostatek je samozřejmě jednou z příčin malého využívání této funkcionality.

Mezitím bylo stále zjevnější, že algoritmus MD5 je poměrně snadné obejít. Poprvé se to podařilo údajně někdy v roce 1995, v roce 2012 se situace dostala do takového stavu, že už to bylo možné zvládat v reálném čase s výkonem průměrného stolního počítače. Samozřejmě ani IETF nespal a přišel s návrhem TCP Authentication Options, zkráceně TCP-AO, popsané v RFC 5925.

TCP-AO řeší zmíněný problém s nedostatky MD5/RFC2385 technologie a dále zlepšuje i škálovatelnost. Hashovací klíče už nejsou uloženy v konfiguraci BGP relace, ale využívá se obecných nástrojů operačních systémů směrovačů pro správu klíčů. Využívají se, mimo jiné, algoritmy SHA-1 a AES-128, které jsou zatím považovány za bezpečné. I konfigurace jednotlivých peerů je díky tomuto přístupu jednodušší a pro administrátory pohodlnější.

Nástroje tedy existují. V praxi se však používají poměrně málo a když, tak jen některé z nich separátně. Je však zjevné, že žádná zde zmíněná dílčí metodika zabezpečení není dostatečná sama o sobě, ale že jejich skutečná síla spočívá v jejich kombinaci. Bezpečná BGP relace tedy vyžaduje jak správně vykonfigurované CoPP na obou koncích, tak také nasazení nástrojů GTSM a TCP-AO. Pro polovičatost zrovna zde není prostor a může se kdykoli vymstít. Projekt FENIX sdružení NIX.CZ dělá pro zlepšení obecného zabezpečení internetových sítí mnohé a diskuse na jeho platformě už také míří k lepšímu zabezpečení těch nejdůležitějších informací, co tou sítí tečou – protože bez spojených BGP relací by nefungovalo vůbec nic.

Tohle samozřejmě nejsou jediné slabiny BGP, dalším zásadním problémem je jeho přílišná otevřenost, která umožňuje oznamování prefixů nebo cest, které dané cílové síti nepřísluší. Tento problém se řeší jinými nástroji, jako je filtrování podle RIR databází, využití technologie RPKI a v budoucnu možná také BGPSec pro ověřování validních cest mezi různými autonomními systémy, nicméně to už je zase další téma.

V Quantcomu jsme si již zvykli, že býváme těmi, kdo nasazují nové nástroje pro zabezpečení BGP relací mezi prvními, Generalized TTL Security Mechanism na našich relacích vůči tranzitním Tier 1 sítím i vůči významným peeringovým partnerům máme nasazen už bezmála deset let, používáme i další zatím nezmíněné technologie, zlepšující výkon BGP relací, jako je třeba Bidirectional Forwarding Detection, díky níž víme o výpadku zařízení partnerské sítě nikoli v řádu minut, ale v řádu desítek až stovek milisekund. Router pak při výpadku trasy, vyhodnocené původně jako nejlepší pro daný provoz, vybere trasu záložní tak rychle, že uživatel nezaznamená ani výpadek ve streamovaném videu nebo voice over IP.

Proto asi nikoho nepřekvapí, že i s implementací TCP-AO, která postupně v implementacích výrobců hardware uzrála, jsme nejen v podmínkách českých zemí, ale i celoevropsky, mezi prvními, kdo tuto technologii nasazuje na mezioperátorské úrovně do ostrého provozu. První BGP relace přes infrastrukturu NIX.CZ jsme pomocí TCP-AO zabezpečili v průběhu listopadu 2023 a rádi bychom RFC 2385 a MD5 poslali do starého železa co nejdříve.