Felfutás a körmös szalon fölötti irodától a világhálóig
A Cloudflare 2010-ben indult Palo Altóban, egy körmös szalon feletti apró irodából, egyetlen tranzitszolgáltatóval és pár névszerveres beállítással működő fordított proxyval. Az első partnerük az nLayer Communications (ma GTT) volt, amely lehetőséget adott a peeringkapcsolatok világába lépni, és rámutatott a költségek és a teljesítmény bonyolult egyensúlyára. Innen lépésről lépésre haladtak városról városra: Chicago, Ashburn, San Jose, Amszterdam, Tokió – mindenhol új adatközpont, bonyolult egyeztetések, szerverrögzítések, optikai kábelezések, Internet Exchange-peeringek sorozata. Az „internet” nem valami ködös felhő: drótokkal, gépekkel teli szobák hálózata, ezek egyedi kihívásokkal teli helyszínek. Időnként a felszerelések eltűntek a vámon, vagy éppen fogselyemre volt szükség az improvizációhoz. 2018-ban egyetlen hónap alatt 31 városban sikerült beüzemelni rendszert, például Katmanduban, Bagdadban, Reykjavíkban vagy Kisinyovban. Akkoriban már 7 millió internetes oldalt védtek – ma, több mint 330 városban működő adatközponttal ez a lefedettség a teljes web több mint 20%-ára nőtt.
Az internet pajzsa: felhőből védelmi réteg
A Cloudflare mára nemcsak a gyorsítótárazott weboldalakat szolgálja ki: a cégek munkatársait, teljes intranetes hálózatokat, régi MPLS-vonalakat is védeni kellett. A hagyományos védelmi eszközök helyett saját fejlesztésű rendszerek garantálják a titkosított alagútban történő biztonságos elérést, vagy akár az ügyfelek IP-címeinek, útvonalainak hirdetését is, közvetlenül a globális hálózatból, BGP-vel. Mindeközben a támadások mérete is brutálisan nőtt. 2025-ben például 31,4 Tbps sávszélességű DDoS-támadást kellett kivédeniük: mindez alig 35 másodpercig tartott, az Aisuru–Kimwolf botnet (főleg megfertőzött Android TV-kből állva) indította, és aznap még több mint 5000 támadást blokkoltak. Egyetlen mérnöknek sem kellett beavatkoznia a védekezés folyamatába.
Mindazonáltal tíz évvel korábban egy ekkora támadást csak országos erőforrásokkal lehetett volna kivédeni. Most a hálózat ezt automatikusan intézi, hiszen minden szerver intelligensen, önállóan dönt, a teljes rendszer méretéből adódóan.
Önvédelmi rendszer: így állják útját a támadásoknak
Támadás esetén minden bejövő csomag a hálózati kártyára érkezik, majd azonnal XDP (eXpress Data Path) programláncba kerül, amelyet az xdpd futtat illesztőprogram-szinten. Az első szűrő az l4drop program, amely az eBPF-szabályok alapján mérlegel: ezeket a dosd nevű szolgáltatás generálja minden egyes szerveren, valós időben mintázva a forgalmat, súlyozott listát készítve, majd szétküldi az egész, adott telephelyen működő szerverflottának. Az egész rendszer így egységes döntést hoz: minden szerver ugyanazokra a támadási mintákra ugyanúgy reagál.
Ha a dosd támadást detektál, a szűrési szabályokat nemcsak lokálisan, de a Quicksilver nevű, saját fejlesztésű, elosztott kulcs–érték táron keresztül globálisan is továbbítják, másodpercek alatt elérve világszerte minden szervert. Az Unimog nevű L4-terheléselosztó továbbjuttatja az átment forgalmat az egészséges szerverekhez, míg a Magic Transit ügyfeleknél a flowtrackd alkalmazás további, akár TCP-szintű vizsgálatokat is végez, minden nem valós forgalmú kapcsolatot azonnal blokkolva.
A legutóbbi, 31,4 Tbps-os támadás is pontosan ezen a folyamaton futott végig: központi forgalomátirányításra nem volt szükség, minden támadott adatközpont önállóan, valós időben szedte le a nemkívánatos csomagokat, mielőtt azok egyáltalán a CPU-hoz érhettek volna.
Helyben futó alkalmazások és fejlesztői platform
A teljes hálózaton futó védelmi szoftverek mellett adott volt a lehetőség: ha minden szerveren elbírnak bonyolult programokat is, akkor ügyfélkód is futtatható rajtuk. Így született meg a Workers fejlesztői platform, majd később a KV és a Durable Objects. Ezek nem csak szórványos felhőközpontokban, hanem a világ minden pontján, közel a felhasználókhoz futnak – 2025-től már konténereket is képes kezelni a platform, így nagyobb, összetettebb alkalmazások is közvetlenül a hálózat peremén futnak.
A felhasználói kód mindig ugyanazokon a szervereken fut, ahol a legagresszívebb DDoS-forgalmat is gond nélkül „kipucolja” az l4drop, így sem a támadás, sem az alkalmazáskörnyezet nem lassul le.
Előrelátó protokollok: IPv6, RPKI és ASPA
Az IPv6 és RPKI terén úttörőként lépett a Cloudflare: BGP-eltérítések (routing hijack) súlyos működési zavarokat, visszaéléseket okozhatnak, ezért az RPKI segítségével minden rossz útvonalat automatikusan kidobnak, a prefixum tulajdonjogát érvényesítve. Mindig aláírják a Route Origin Authorizationokat (ROA), szigorúan betartják a Route Origin Validationt, és nem fogadnak el hibás RPKI-bejegyzést, még akkor sem, ha emiatt néha átmeneti elérhetetlenség alakul ki.
Most az Autonomous System Provider Authorization (ASPA) a következő lépés: míg az RPKI igazolja a cím tulajdonosát, az ASPA a forgalmi útvonal helyességét ellenőrzi, véd a route leak szituációk ellen is. Később várható, hogy az egész iparág igazán rááll ezek használatára – tíz éve például egyetlen prefixum sem volt tanúsított, ma már 867 ezer érvényes RPKI-s prefixum található a globális routingtáblákban. A Cloudflare mérete miatt minden ilyen döntés kihat az egész internetre: érdemes korán lépni, mert a késlekedés csak további támadási felületet jelent.
Az MI-ügynökök és az evolúcióban lévő internet
Az MI forradalma átrajzolja a webes jelenlét fogalmát: már nemcsak emberek, hanem MI-ügynökök, crawler programok, modellek tanulófolyamatai is folyamatosan „járják” az oldalakat. Ma a teljes HTML-lekérések több mint 4%-át ilyen MI-alapú forgalom adja, ez megfelel a Googlebot aktivitásának. Közben a „user action” típusú keresések (amikor egy MI-robot emberi kérdésre keres válaszoldalt) egyetlen év alatt tizenötszörösére nőttek.
Az MI-crawlerek másképp viselkednek, mint a böngészők: nem kérdeznek, hanem minden kapcsolódó hivatkozást letöltenek, maximális sávszélességgel. Ebben a méretben már komoly technikai kihívást jelent megkülönböztetni a rosszindulatú, támadó MI-forgalmat a hasznostól. Erre a célra a Cloudflare IP-címtartomány-ellenőrzést, TLS-ujjlenyomat-vizsgálatot, viselkedéselemzést és robots.txt alapú szignálokat is használ. Például a böngészők egyedi, kiszámítható TLS-kapcsolatkezdeményezésekkel jelentkeznek; ha egy MI-crawler csak az User-Agent mezőt klónozza, de más TLS-ujjlenyomattal kapcsolódik, azt a rendszer már a kezdetekkor kiszűri.
Újabb 500 Tbps felé: közösség és partnerség
A világ legpajzsosabb hálózata mára 330 város, 125 ország, 13 ezer peeringpartner és saját fejlesztői platform együttműködésével működik – és a növekedés nem áll meg. A jövő újabb 500 Tbps kapacitást, még több védelmet, még kevesebb támadási lehetőséget és még nagyobb fejlesztői szabadságot tartogat.
