A Cloudflare a biztonságosabb routingot ígérő RPKI-ra szavaz
A szolgáltató összes ügyfelének ingyen kínálja a nagyobb biztonsággal kecsegtető technológiát.
A nagyobb nevek közül elsőként implementálja az RPKI-t, vagyis a Resource Public Key Infrastructure technológiát a Cloudflare. Az aláírásos tanúsítványokra épülő, biztonságosabb internetes routinggal kecsegtető fejlesztést ingyen kínálja majd ügyfeleinek a szolgáltató, amely kisebb lendületet adhat az RPKI-nak. Mindez azonban vélhetően nem lesz majd elég a futótűzszerű terjedéshez, a technológia implementáláshoz ugyanis mind a hálózatot felépítő különféle hardvereknek, mind pedig a szoftvereknek meg kell felelniük.
Az RPKI az úgynevezett "route hijack", azaz forgalomeltérítéses támadások ellen nyújthat védelmet. Ennél az egyre korosodó BGP (Border Gateway Protocol) gyengeségét használja ki a rosszindulatú fél. A BGP lényege nagy vonalakban: a szolgáltatók meghirdetik, hogy mely IP-tartományok tartoznak hozzájuk, így az ezekre irányuló forgalmat a többi szolgáltató eszközei feléjük csatornázzák. A rendszer jellemezően bizalom alapon működik, egyik BGP router (illetve szolgáltató) alapértelmezetten elfogadja a másik által hirdetett online útvonalakat. Így tehát, ha a hálózat egy pontján valakinek sikerül a saját szájíze szerint módosítani a kritikus paramétereket, azt a következő pont már kérdés nélkül legitimként értékelheti.
A forgalomeltereléshez ugyanakkor nem mindig kell rosszindulatú fél, egyszerű adminisztrátori hibából is történt már jó néhány kellemetlen eltérítés. Mindez rávilágít a BGP komoly gyengeségeire, amelyek orvoslása bár a protokoll kiterjedtsége miatt komoly műszaki kihívást jelent, egyre kritikusabbá válik. A probléma jellemzően inkább a nagyobb, akár több ezer IP tartománnyal rendelkező nagy szolgáltatókat érinti. A szerényebb, néhány 10 tartománnyal rendelkező kisebb szereplők (ilyen a hazai szolgáltatók nagy része is) esetében ugyanis még működhet a kézi, AS (Autonomous System Number) alapján végzett kötelező ellenőrzés, ezres nagyságrendben viszont ez már kvázi kivitelezhetetlen.
Ez utóbbit rendszeresen kihasználják a támadók, precedensekért nem kell messzire menni. Tavasszal például az Amazon is áldozatul esett a BGP gyengeségeinek, a támadók 1300 darab felhős szolgáltatásokhoz tartozó IP-t tereltek el, 150 ezer dollárnak megfelelő kriptopénzt zsákmányoltak - szakértők szerint az akció csak bemelegítő kör volt. A támadás relatíve egyszerűségét jól mutatja, hogy mindehhez csupán nagyjából 2 órára van szükség. Az esetet követően az Amazon elmondta, hogy nem közvetlenül a AWS-t, vagy a Route 53 DNS szolgáltatását törték fel a támadók, ehelyett egy internetszolgáltatót vettek célba, amelyen keresztül a Route 53 érintett címeit a szolgáltatóval kapcsolatban álló hálózatok felé kommunikálták.
Machine recruiting: nem biztos, hogy szeretni fogod Az AI visszafordíthatatlanul beépült a toborzás folyamatába.
Ennek megakadályozásához nyújthat segítséget a BGP kiegészítő mechanizmusának tekinthető RPKI. A NIST és az NCCoe által összerakott biztonsági szabvány segít megakadályozni, hogy BGP ne akarja a bármilyen okból hibásan bejelentett prefixeket alapértelmezett útvonalként használni. Ehhez titkosított tanúsítvány formájában validációt alkalmaz az RPKI, amely magában foglalja az IP prefixet és a forrás AS-t is. Bár az RPKI sokat javít a biztonságon, tökéletes választ nem jelent a bizalom alapú BGP gyengeségeire, amelyet például update üzenetekben érkező aspath hibákkal továbbra is meg lehet zavarni.
A Cloudflare szerint ennek ellenére mérföldkövet jelent az RPKI, amelynek köszönhetően a hálózat egy nagyobb lépéssel közelebb kerülhet a biztonságosabb, azonosítás alapú routinghoz. Ehhez azonban még évek kellhetnek, az adaptáció ugyanis lassan halad. Jelen állás szerint mindössze az egyedi Prefix/Origin párok bő 9 százaléka alkalmazza az RPKI-t, amely a teljes internet csupán 1 százalékát fedi le. A gyorsabb terjedés egyik akadálya lehet, hogy titkosítás az eddigieknél nagyobb erőforrásigényt támaszt, amit több, használatban lévő eszköz nem képes kiszolgálni, így az implementációhoz több esetében meg kell várni a következő hálózatfejlesztési ciklust.