DDoS-védelem
A forgalmi áradatokat a hálózat peremén nyeljük el, a hálózati rétegbeli támadásokat a felsőbb szinteken szűrjük, és bármi, ami eléri a szervert, a céloldal saját, kernelszintű elszigetelésében marad. Több réteg, mindegyik más feladatot lát el, így az egy webhelyet célzó támadás nem okoz leállást a mellette lévők számára. Ezt a védelmi modellt egy világszerte több mint 700 000 webhelyet kiszolgáló platformhoz építettük fel, és az alapcsomag minden előfizetésen működik. Elérhetőség: a webhelyenkénti adatbázis-szabályozás aktív fejlesztés alatt áll, és még nem érhető el. Minden egyéb itt leírt funkció már ma működik.
A volumetrikus áradás, az L7 alkalmazási rétegű elárasztás és a lassú kapcsolatkimerítéses támadás három különböző probléma. Mindegyiket ott kezeljük, ahol a legolcsóbb és leggyorsabb a kezelése — a szerverpark előtt, a hálózat peremén és a ketrecen belül.
A szolgáltatói szintű DDoS-védelem már a worker-flottánk előtt megszűri a hálózati rétegbeli áradásokat, mielőtt ez a forgalom valaha is lefoglalna egy portot, hálózati kártyát (NIC) vagy processzorciklust azon a gépen, amelyen az Ön webhelye fut. Haladó és vállalati kockázati profilok esetén a Cloudflare Magic Transit és a Spectrum ugyanezt a szűrést a nem HTTP-forgalomra is kiterjeszti.
Minden webhely előtt egy felügyelt peremhálózat működik. Elnyeli a volumetrikus HTTP-elárasztásokat, L7 WAF-ot futtat, webhelyenkénti sebességkorlátozást alkalmaz, és robotkezelést, valamint felügyelt ellenőrzéseket használ a valódi látogatók és az automatizált forgalom szétválasztására — mindezt még azelőtt, hogy a kérés elérné a forráskiszolgálót.
A LiteSpeed Enterprise IP-cím alapú kapcsolati korlátokkal alkalmazza a kapcsolatok és kérések szabályozását, az Imunify360 hálózati tűzfalat működtet brute-force védelemmel és IP-hírnév szűréssel, a CloudLinux LVE belépési folyamatokra vonatkozó korlátai pedig megszabják, hogy egyetlen webhely legfeljebb hány egyidejű kérést tarthat nyitva.
Az LVE webhelyenként egyedileg korlátozza a CPU-t, a RAM-ot, az IO-t, az IOPS-t, a folyamatokat és a belépési folyamatokat. A felső rétegeken átjutó forgalmi áradatot a céloldal saját izolált környezetében korlátozza a rendszer, így a keletkező terhelés az adott webhelynél marad ahelyett, hogy szétterjedne a teljes szerveren.
A támadások során bekövetkező tárhelykimaradások többségét nem az okozza, hogy a támadás eléri a célját. Sokkal inkább az, hogy a célpont erőforrás-fogyasztása miatt minden más erőforrás nélkül marad a szerveren. Ez az a hibalehetőség, amelynek kiküszöbölésére ezt az architektúrát tervezték.
A legköltséghatékonyabban kiszolgálható kérés az, amely soha nem éri el a PHP-t vagy a MySQL-t. Kétrétegű gyorsítótárunk révén az alkalmazásrétegű túlterhelések jelentős részét statikus bájtok szolgálják ki, anélkül hogy a kiindulási szerverének dolgoznia kellene.
A kockázatenyhítés nem egy támogatási jegy. A jelzések egy szabályzatmotort táplálnak, amely mindegyiket egy érvényesítési művelethez, egy ügyfélértesítéshez és – ahol lehetséges – egy automatikus elhárításhoz rendeli hozzá, minden átmenetet naplózva.
Amikor DDoS-jelzés aktiválódik, a szabályzatmotor Cloudflare-mérséklést és webhelyenkénti sebességkorlátozást alkalmaz, valamint dinamikusan szigoríthatja az adott webhely LVE-korlátait. Amikor a jelzés megszűnik, a korlátok ismét enyhülnek. Fokozatos, visszafordítható és minden lépésnél naplózott.
Ha egy támadás veszélyezteti a forrásszervert, a webhely „korlátozott” (throttled) állapotba lép – szigorúbb LVE-korlátok és sávszélesség-/sebességkorlátozás lép életbe, miközben a webhely továbbra is elérhető és kiszolgálja a kéréseket. A korlátozás automatikusan feloldódik, amint a terhelés megszűnik; ez nem felfüggesztés.
Az irányelvmotor alatt az LVE natív módon és automatikusan korlátozza a webhelyenkénti CPU-, IO- és folyamathasználatot. Ez a folyamatosan működő első védelmi vonal, amely attól függetlenül fut, hogy a forgalmat már támadásnak minősítették-e vagy sem.
Minden érvényesítési átmenet rögzíti az okát, azt, hogy automatikus vagy a személyzet által kezdeményezett volt-e, valamint a mögötte álló bizonyítékokat. Értesítést kap arról, hogy mi változott és hogyan oldható meg, és minden intézkedés ellen fellebbezni lehet.
Az alapszintű védelem nem választható, mivel egy megtámadott vagy feltört webhely veszélyezteti a szomszédait, a szervereink hírnevét és az IP-tartományainkat. Erősebb védelem áll rendelkezésre azon webhelyek számára, amelyek kockázati profilja ezt megköveteli.
A forgalmi csúcs gyakran csak tünet. Ugyanaz a jelvezeték, amely a túláradásokat kezeli, az azokat előidéző biztonsági incidenseket is észleli, így az incidens pontos besorolást kap ahelyett, hogy egyszerűen csak elnyelné a rendszer.
A tervezési cél az elszigetelés. Minden webhely a saját CloudLinux LVE környezetében fut korlátozott CPU-, RAM-, IO-, IOPS-, folyamat- és belépési folyamatszámmal, saját CageFS fájlrendszer-nézettel, valamint a MySQL Governor általi webhelyenkénti adatbázis-szabályozással. A megtámadott webhely a saját felső korlátjánál kerül szabályozásra ahelyett, hogy a teljes gépet leterhelné, a LiteSpeed IP-címenkénti kapcsolatkorlátai pedig megszabják, hogy a webszerver mekkora részét kötheti le. Az elszigetelés a kernel szintjén van kialakítva, nem pedig ügyfelenként konfigurálva.
Az alapszint minden csomag részét képezi: LVE és CageFS elkülönítés, LiteSpeed kapcsolat- és kérelemkorlátozás, hálózati tűzfal, proaktív WAF és kártevő-ellenőrzés, valamint a flotta előtt működő Cloudflare peremhálózati elnyelés és szolgáltatói szintű hálózati szűrés. Azért biztosítjuk ezt alapszolgáltatásként, mert a saját flottánk védelmét nem tehetjük opcionálissá. A fejlett botkezelés, a magasabb DDoS-szintek, a kiterjesztett WAF-szabályok és a dedikált tűzfalszabályok kiegészítőként érhetők el az ezt igénylő webhelyek számára.
Ha a webhely DDoS-támadás célpontjává válik, az Cloudflare-alapú forgalomcsökkentést és webhelyenkénti sebességkorlátozást von maga után, valamint — kizárólag akkor, ha a támadás az eredeti kiszolgálót veszélyezteti — a „throttled” (visszafogott) állapotot: szigorúbb LVE-korlátok lépnek érvénybe, miközben az oldal továbbra is üzemel és kiszolgálja a kéréseket. A visszafogott állapot a terhelés megszűnésével automatikusan helyreáll. A felfüggesztés kizárólag nemfizetés vagy igazolt visszaélés esetén alkalmazandó, és a webhely még ekkor is egy márkajelzéssel ellátott, a konkrét okot feltüntető várakozóoldalt jelenít meg a hibás oldal helyett.
Nem vonatkozik semmire, amit a gyorsítótárból szolgálnak ki. A LSCache a PHP vagy a MySQL meghívása nélkül válaszol a gyorsítótárazott oldalakra vonatkozó kérésekre, és a webhelyenkénti Redis objektum-gyorsítótár tehermentesíti az olvasási műveleteket a valóban dinamikus oldalak esetében. A fennmaradó részt a webhelye LVE-folyamatainak és belépési folyamatainak korlátai, valamint a MySQL Governor webhelyenkénti adatbázis-szabályozása korlátozza, így az egy webhelyről érkező adatbázis-terhelés nem terjedhet át a szerverre. A kosár, a pénztár, a fiókom és a munkamenet-oldalak alapértelmezés szerint gyorsítótárazatlanok maradnak, így a biztonsági szigorítás soha nem szakít meg tranzakciót.
Igen, a hálózati rétegben. A szolgáltatói szintű DDoS-védelem protokolltól függetlenül kiszűri az L3/4 elárasztásokat a flottánk előtt, haladó vagy vállalati igények esetén pedig a Cloudflare Magic Transit és a Spectrum kiterjeszti az edge-szintű védelmet a nem HTTP-forgalomra is.
Minden kényszerítési állapotváltozás rögzítésre kerül az indoklással, azzal együtt, hogy automatikus volt-e vagy a személyzet kezdeményezte, valamint a mögötte álló bizonyítékokkal. Ön értesítést kap a változásokról és azok megoldásáról, minden intézkedés fellebbezhető, és a kiemelt jogosultságú műveletek naplózásra kerülnek a saját megfelelőségi nyilvántartása érdekében. A jelzések nem különféle eszközökben szóródnak szét, hanem egyetlen Abuse Desk felületen összegződnek.
Igen. A Footprint-Free tárhely egy kártya nélkül igénybe vehető, 14 napos próbaidőszakkal kezdődik akár 5 webhelyre — fizetési adatok és elköteleződés nélkül. A csomagokat 30 napos kérdések nélküli pénzvisszafizetési garancia, ingyenes migrálás és szolgáltatói kötöttségek hiánya támogatja.
A hálózati szűrés, a hálózatperemi elnyelés, a szerverterhelés-szabályozás és a webhelyenkénti elszigetelés az üzembe helyezés pillanatától kezdve működik — nincs mit konfigurálni, nincs mit bekapcsolni az incidens közben. Kezdje a 14 napos, bankkártya nélküli próbaverzióval, amelyet 30 napos pénzvisszafizetési garancia és díjmentes átköltöztetés támogat.
Kezdés ingyen