Napsali jsme pro Lupa.cz

Hlavním problémem spoofingu je obtížná obrana proti němu. Oběť, jejíž skutečná adresa z její koncové sítě je podvržena, možnost obrany proti něčemu takovému vlastně nemá. Může udělat některá drobná opatření, například neakceptovat ve své síti provoz, přicházející zvenčí, avšak z jejích vlastních adres a samozřejmě může bránit tomu, aby mohl nějaký útočník odesílat provoz s podvrženými adresami z její vlastní sítě. Nic z toho jí však nepomůže vyřešit bezprostředně probíhající spoofing, předstírající, že je odesílán z jejích adres.

Zde by většinu práce měli udělat ISP. Dá se říci, že čím „internetově civilizovanější“ země, tím je větší pravděpodobnost, že operátor od vás jako zákazníka spoofovaný provoz nebude akceptovat. U nás v ČR pro nešíření spoofovaného provozu udělal hodně projekt FENIX sdružení NIX.CZ, z.s.p.o., jehož pravidla odesílání spoofovaného provozu striktně zakazují a sdružení NIX.CZ šíření provozu, který vykazuje znaky spoofingu, aktivně monitoruje a příslušné sítě na něj dokáže upozornit. Zároveň však je nutné říci, že žádné známé dílčí opatření nepokrývá všechny myslitelné případy a že každé opatření, které operátor nebo kdokoli jiný může zatím udělat, má jistá omezení.

Hlavním nástrojem obrany proti spoofingu na úrovni sítí poskytovatelů připojení je tzv. „filtrování podle zpáteční cesty“ (reverse path filtering). V terminologii Linuxu se používá pojem „rp_filter“, v terminologii nástroje pf ve FreeBSD je to „reply-to“ filtrace, na hardwarových páteřních směrovačích je pak obvyklá zkratka uRPF (unicast reverse path filtering). Tento nástroj dokáže ohlídat, že packet se zdrojovou adresou, pro kterou přes rozhraní, kterým přišel, neexistuje ve směrovací tabulce příslušný záznam (routa), se zahodí. To na první pohled vypadá jako řešení všech problémů, ale bohužel jen máloco je dál od pravdy.

Více cest – hlavní omezení současné uRPF 

Ve skutečnosti stávající implementace uRPF narážejí na několik zásadních problémů. Tím asi největším je, že samotný pojem směrovací tabulka je nejednoznačný. Už v jednom z minulých článků jsem zmínil, že jej nebudeme používat. Mozek takového routeru, tedy jeho řídící CPU (control plane) si vytváří z různých zdrojů (zejména statická konfigurace a routy přijaté dynamickými směrovacími protokoly) tabulku, které budeme dále říkat RIB. Ta obsahuje mimo jiné také velké množství informací, které router pro přehazování velkých hromad packetů mezi rozhraními normálně příliš nepotřebuje, například informace o všech dostupných cestách ke konkrétnímu cíli, i včetně těch neoptimálních. Z obsahu RIB se pak vytváří tabulka FIB, velmi zjednodušený kompilát, se kterým pak pracují „svaly“, tedy obvykle specializované (NPU) obvody pro směrování datových toků mezi konkrétními rozhraními.

Jedním z aspektů tohoto zjednodušeného souboru dat je, že ve FIB se nalézá jen velmi omezené množství existujících legitimních cest k danému cíli (zpravidla jen jediná). Výhodou FIB je její rychlost. Používají se zde velmi sofistikované akcelerované paměťové technologie, jako je třeba TCAM, a není nejmenší problém se do ní podívat pokaždé, když přijde na některé rozhraní směrovače nějaký packet (což se děje třeba i ve stovkách milionů případů každou sekundu), a to i několikrát. Naopak podívat se do RIB v reálném čase takto často z řady důvodů možné rozhodně není.

Největším nepřítelem nasazení současného uRPF tedy je možnost, že packet z jednoho zdroje může legitimně přijít více různými cestami. V takovém případě je nezbytné celý problém řešit trochu jinak, nasazují se různé access-listy, komplexita konfigurace celého zařízení roste a s rostoucí komplexitou roste i šance na zavlečení nějaké chyby. Dalším problémem je také to, že počet TCAM buněk v NPU linkových karet je u všech platforem omezený.

Další nedostatky

Než se ale dostaneme k navrženému budoucímu řešení, zmíníme si ještě jedno úskalí (kterým se navržené budoucí řešení ani nezabývá). V některých případech je filtrování pomocí uRPF naopak příliš hrubé a tento nástroj si spoofovaného provozu nemá šanci povšimnout. Tento problém se týká například sdílených ethernetových segmentů v housingových centrech (ale třeba i některých IXP), kde jeden zákazník může podvrhovat zdrojové adresy odchozích packetů tak, že vypadají, jako by odcházely ze serveru jiného zákazníka.

V současných komerčně dostupných hardwarových routerech není k dispozici technologie, která by hlídala, zda zdrojová IP adresa packetu odpovídá zdrojové L2 MAC adrese ethernetového rámce, do níž je tento packet zabalen. Jistě, jde to řešit pomocí L3 ACL na portech agregačních switchů, ale tohle řešení přináší nové problémy, zejména s velmi komplexní konfigurací a na to navazujícími obtížemi se škálováním, nezbytností konfiguračních zásahů do síťových prvků při výměně zákaznického hardware atd.

V Quantcomu nás možnost výskytu těchto problémů vedla k tomu, že jsme myšlenku sdílených L2 segmentů pro více zákazníků už před mnoha lety zcela opustili a každá housingová služba má svoji VLAN a svůj vlastní adresní rozsah, v duchu hesla „dokonalosti není dosaženo tehdy, když už není co přidat, ale naopak když už není co dát pryč“, přesně, jak se to píše v bodě 2/12 RFC1925.

VRF-mode uRPF jako meziřešení?

Někdy od roku 2008 se v odborných kruzích vědělo o možném řešení z kategorie „workaround“, jak se s problematikou více legitimních cest vyrovnat – využít k tomu schopnost routerů provozovat více směrovacích instancí (VRF) a některé specifické routy udržovat ve specifické směrovací instanci.

Obvod odpovědný za provádění uRPF funkcionality pak problematiku řeší na úrovni této směrovací instance (neřeší, zda packet může být legitimně přijat rozhraním, ale zda existuje routovací záznam ve FIB pro celou směrovací instanci). Po této kontrole je pak packet směrován podle globální routovací tabulky. RFC 8704 pro EFP-uRPF, který je hlavním tématem tohoto článku, tuto funkcionalitu zmiňuje:

RFC 8704 2.5. SAV Using VRF Table

The Virtual Routing and Forwarding (VRF) technology [RFC4364] [Juniper] allows a router to maintain multiple routing table instances separate from the global Routing Information Base (RIB). External BGP (eBGP) peering sessions send specific routes to be stored in a dedicated VRF table. The uRPF process queries the VRF table (instead of the FIB) for source address validation. A VRF table can be dedicated per eBGP peer and used for uRPF for only that peer, resulting in strict mode operation. For implementing loose uRPF on an interface, the corresponding VRF table would be global, i.e., contains the same routes as in the FIB.

Asi nejpodstatnější problém s touto funkcionalitou ovšem spočívá v tom, že ji žádný výrobce (vendor) nikdy nezahrnul do ostré produkční verze software pro své směrovače, takže se nikdy nedočkala ostrého nasazení.

IETF přichází s řešením: EFP-uRPF

Z předchozího textu už vlastně řešení vyplývá. Pokud z dat ve FIB nelze dovodit, zda packet přicházející nějakým konkrétním rozhraním je legitimní a do RIB se nedokážeme v reálném čase dostat, nezbývá, než data z RIB, která bychom mohli použít pro takové dovození, nějakým způsobem vytáhnout a uložit někde, kam se ASIC v reálném čase pro každý příchozí packet podívat stihne, tedy nějaká forma agregace RIB, indexovaná podle možného (feasible) příchozího rozhraní. A ano, přesně tak to pro řešení jménem Enhanced Feasible Path (EFP-uRPF) IETF v dokumentu RFC 8704 také specifikuje.

Zbytek už jsou vlastně jenom nudné technické podrobnosti. Podstatné je vědět, že stejně jako u současné technologie uRPF, která zná režim volný (loose mode) a striktní (strict mode), i EFP-uRPF bude mít ekvivalenty těchto dvou režimů, byť terminologie je trochu jiná, méně striktní metoda, podobná využívání loose režimu, je pojmenována jako „algoritmus A“ a striktnější a komplexnější metoda je pak označována jako „algoritmus B“. 

Index routovací tabulky je pak v terminologii RFC 8704 nazýván „zákaznickým kuželem“ (customer's cone), kdy autoři RFC 8704 předpokládají, že i pro největší operátory bude postačující, bude-li limit počtu záznamů v takovém zákaznickém kuželu omezen na vyšší desítky tisíc (srovnejme to s miliony pro počet záznamů v RIB nebo i FIB). 

Zní to docela hezky, že? Je ovšem nutné si uvědomit, že s EFP-uRPF se to nemá jako s nějakou malou změnou ve směrovacím protokolu, která se dá vyřešit updatem software v control-plane hardwarových směrovačů. Tohle vyžaduje změny přímo v hardware, tedy v samotných NPU chipech (ať už proprietárních, nebo v „merchant silicons“), a to rozhodně není otázka dvou nebo tří let.

Pokud je obvyklý životní cyklus linkových karet páteřních hardwarových boxů někde mezi šesti a osmi lety a vývojový cyklus kolem dvou let, dá se očekávat, že v roce 2028 se objeví první zařízení, která tuto technologii budou podporovat a na první ostré nasazení si počkáme tak do let 2030–2031. Do té doby musejí administrátoři pracovat s tím, co je k dispozici teď.