Defaults.Exposed › Javítások › CDN / WAF és tárhely

Hogyan javítsd ki: CDN / WAF és tárhely

Két leolvasás a weboldaladat mögötti 'vízvezetékről': egy védő pajzs mögött ülsz-e (egy Web Application Firewallal rendelkező CDN, mint a Cloudflare), amely szűri a támadásokat és elnyeli a forgalmi csúcsokat, valamint egy térkép arról, ki futtatja ténylegesen a DNS-edet, a weboldaladat és az e-mailedet. Mindkettő tájékoztató a pontozásunkban – nem mozgatják a besorolásodat –, de leírják, mennyire ki van téve az eredeti szervered a támadásoknak és leállásoknak, és mennyire összegabalyodottak a szolgáltatóid. Egy pajzs elöl és egy ésszerűen elosztott szolgáltatókészlet az, ahogy a rugalmas vállalkozások kinéznek.

Az üzleted szempontjából lényeg: Egy weboldal, amelynek semmi nincs elötte, minden támadást és forgalmi csúcsot közvetlenül az eredeti szerverre vesz – tehát egy bot-özön, egy induló-napi roham vagy egyetlen automatizált támadás hours-ra leveheteti offline, és a helyreállítás rajtad múlik. Egy CDN/WAF elhelyezése elöl (ingyenes szint elérhető) szűri az automatizált támadások nagy többségét, elnyeli a rohamokat, és szerte a világon felgyorsítja az oldalt – tipikusan egy délután munkája az IT-személyednek, licencköltség nélkül. Külön, ha a DNS-ed, a weboldaled és az e-mailje mind egy szolgáltatónál van, egyetlen leállás vagy feltörés ott egyszerre veszi le az egész online jelenlétedet; a szolgáltatói térkép ismerete az első dolog, amelyre szükséged van egy incidensben. Egyik ellenőrzés sem változtatja meg a besorolásodat – de mindkettő leírja a valódi kitettséget a leállásra, elveszített eladásokra és lassú, fájdalmas helyreállításra.

Mibe kerülhet ez neked

Egy bot-forgalmi löket vagy egy kis DDoS egy nagy promóció reggelén eléri a védekezés nélküli szerverdet – az oldal lassul vagy összeomlik, az ügyfelek hibákat kapnak a pénztárnál, és elveszíted a nap eladásait, miközben a hosztod tűzcsatát vív. Egy CDN/WAF elöl felszívta volna.
A DNS-ed, a weboldaled és az e-maile mind egyetlen szolgáltatón futnak; az a szolgáltató leállással rendelkezik, és az oldalad, a foglalási rendszered ÉS az e-maile ugyanazon a pillanatban sötétednek meg – még azt sem küldhetik el, hogy 'tudunk a problémáról', mert a postafiók is nem elérhető.
Egy automatizált támadás egész éjjel kutatja az oldalt – SQL-befecskendezési és bejelentkezés-kitaláló szkriptek közvetlenül az eredeti kódodat célozzák, mert nincs tűzfalréteg a szűrésre –, és csak akkor tudsz meg, amikor valami eltörik. Egy WAF blokkolja az automatizált zaj nagy részét, mielőtt eléri a kódodat.
Incidens jön, és senki nem tudja megválaszolni az alapkérdést: 'kit is hívjunk?' – Az e-mail ugyanazon a hoszton van, mint a webhely? Ki futtatja a DNS-t? Csak a vezetékek térképezésével telik el órákat, miközben az oldal le van.
Egy lehetséges ügyfél IT-csapata átvizsgál aláírás előtt, és pajzs nélküli eredeti szervert lát CDN/WAF nélkül – és egy szerver-fejlécet, amely nyilvánosan hirdeti a futtatott szoftvert (és verziót). Kis jel, de a 'nem keményítette meg az alapokat' rovatba kerülsz éppen a legrosszabb pillanatban.

Miért fontos. Mindkét ellenőrzés tájékoztató a módszertanunkban – nulla ponttal vannak nyilvántartva és soha nem változtatják meg a besorolásodat –, mert az infrastruktúrádat írják le, ahelyett, hogy egy sikeres/sikertelen biztonsági vezérlőt tesztelnének. Azért vetjük őket felszínre, mert valódi üzleti kitettséget térképeznek. Egy CDN/WAF nélküli oldal minden támadást és forgalmi csúcsot közvetlenül az originen vesz, szűrés és csúcs-elnyelés nélkül; egy hozzáadása (a Cloudflare ingyenes szintje a közös út) az egyik legjobb hatású, legalacsonyabb árú rugalmasság-fejlesztés, amelyet egy kis vállalkozás tehet. Egy egyértelmű szolgáltatói térkép – tudni, hogy a DNS-ed, a webe és az e-maile szét van-e osztva vagy egy szolgáltatóra halmozva – az első dolog, amelyre szükséged van, amikor valami rosszul megy, és a különbség a tartalmazott incidens és a teljes sötétedés között.

Mi ez egyszerű szavakkal

Minden webhely valahol egy szerveren fut. A kérdés, amelyre ez az oldal válaszol: mi áll a nyílt internet és az a szerver között – és ki futtatja ténylegesen az online jelenleted részeit?

Két rész van:

CDN / WAF – az elöl lévő pajzs. Egy CDN (Content Delivery Network) egy globális hálózat, amely az oldal elé ül, a tartalmaidat gyorsan kiszolgálja a látogatóknak bárhol, és elnyeli a forgalmi csúcsokat. Egy WAF (Web Application Firewall) egy szűrő, amely megvizsgálja a bejövő kéréseket, és blokkolja a rosszindulatúakat, mielőtt elérnék a szerveredet. A népszerű szolgáltatások (Cloudflare, AWS CloudFront, Fastly, Akamai, Sucuri, és mások) ezeket egybecsomagolják. Megvizsgáljuk az oldal válaszait, és jelezzük, látunk-e pajzsot elöl – és megjegyezzük, milyen webszervert futtatsz.
Tárhely / szolgáltatói térkép – ki futtatja a vízvezetéket. Olvassuk a nyilvános rekordokat, amelyek megmondják, ki kezeli a DNS-edet (a könyvtárat, amely a domainedet cím-mé változtatja), és ki kezeli az e-mailedet. Ebből megállapíthatjuk, hogy a DNS-ed, a weboldaladat és az e-maile szét van-e osztva (rugalmas) vagy egy szolgáltatóra halmozva (kényelmes, de egyetlen meghibásodási pont).

A legfontosabb tudnivaló előre: a pontozásunkban mindkettő tájékoztató. Nem befolyásolják a besorolásodat. Azért vetjük őket felszínre, mert leírják, mennyire van kitéve a vállalkozásod a leállásnak és a támadásnak – ami egy különböző, és nagyon praktikus kérdés a besorolástól.

Mibe kerülhet ez neked

Ezek nem elvont kockázatok – ezek azok a mindennapi módok, ahogyan egy pajzs nélküli, összegabalyodott beállítás kis problémából rossz napot csinál.

Leesve offline akkor, amikor a leginkább számít. Az oldalad az eredeti szerveren ül, semmi sincs elötte. Egy indulás vagy promóció reggelén a forgalom csúcsra emelkedik – vagy egy szerény bot-özön éri –, és a szerver nem bírja. Az oldalak le időzítik, a pénztár hibásodik, és elveszíted a nap bevételét, miközben a hosztod tűzcsatát vív. Egy CDN elnyeli a csúcsokat, és egy WAF szűri a szemét forgalmat; együtt a különbség a “forgalmas nap” és a “egész reggel le” között.
Minden egyszerre elsötétedik. A DNS-ed, a weboldaled és az e-maile mind egyetlen szolgáltatón futnak. Az a szolgáltató leállással rendelkezik (ez mindannyiukkal előfordul végül), és az oldalad, a foglalási rendszered és az e-maile egyszerre eltűnnek. Nem tudsz rendeléseket feldolgozni, és még azt sem tudod e-mailben küldeni az ügyfeleknek, hogy tudatában vagy a problémának – mert a postafiók is le van. A szolgáltatók szétválasztása azt jelenti, hogy egyetlen hiba tartalmazott, nem totális.
A kódod minden támadást közvetlenül vesz. WAF nélkül minden automatizált próba – befecskendezési kísérletek, bejelentkezés-kitalálás, ismert exploit szkennerek – szűrés nélkül az alkalmazáskódodat éri. Arra fogadsz, hogy a szoftver tökéletes és teljesen frissített, örökre. Egy WAF az automatizált zaj elsöprő többségét blokkolja, mielőtt hozzád érne, “állandó háttér-támadást” “nagyrészt szűrt”-re változtatva.
Lassú, pánikszerű incidens, mert senkinek nincs térképe. Valami eltörik, és az első óra el van vesztegelve azzal, hogy ‘várj, ki futtatja a DNS-ünket? Az e-mail ugyanazon a hoszton van mint a web? Kit hívunk?’ Amikor a szolgáltatói térkép nem egyértelmű, minden incidens nulláról indul. A térkép előzetes ismerete lázas rohanást telefon-hívássá változtat.
Rossz első benyomás egy gondos vevőnél. Egy lehetséges ügyfél IT-csapata átvizsgál aláírás előtt, és pajzs nélküli origint lát CDN/WAF nélkül – és egy szerver fejlécet, amely nyilvánosan hirdeti a pontos szoftvert és verziót. Kis jel, de a “nem keményítette meg az alapokat” rovatba kerülsz pontosan a legrosszabb pillanatban.

Mi ez pontosan

CDN / WAF – a védelmi réteg

Amikor egy látogató (vagy egy támadó) kéri az oldaladat, a kérés vagy egyenesen az eredeti szerverhez megy, vagy először egy CDN/WAF-on keresztül. Ha van pajzs elöl, az a pajzs tud:

Rosszindulatú kéréseket szűrni (a WAF rész): befecskendezési kísérleteket, bot-támadásokat és ismert exploit mintákat blokkolni, mielőtt valaha elérнék a kódodat.
Forgalmat elnyelni (a CDN rész): gyorsítótárban tárolt tartalmat kiszolgálni minden látogató közelében lévő szerverekről, és csúcsokat elnyelni, hogy egy csúcs – legitim vagy ellenséges – ne zúzza össze az origint.
Az oldalt felgyorsítani: a közeli él-szervererről kézbesített tartalom gyorsabban tölt be a látogatóknak szerte a világon.

Pajzsot azáltal érzékelünk, hogy az oldal válaszfejléceiben ezek a szolgáltatások által hagyott ujjlenyomatokat nézzük – például egy cf-ray fejléc (Cloudflare), x-amz-cf-id (Amazon CloudFront), x-served-by (Fastly), x-akamai-transformed (Akamai), vagy x-sucuri-id (Sucuri). Olvassuk a Server fejlécet is, hogy azonosítsuk az alap webszerveredet (nginx, Apache, IIS, LiteSpeed, Caddy, stb.), és jelzünk minden X-Powered-By fejlécet, amely túl sokat oszt meg.

Mit jelent a „jó” beállítás: az originod elöl érzékelt CDN/WAF, és egy Server fejléc, amely nem hirdet meg egy specifikus verziószámot.

Tárhely / szolgáltatói térkép – az infrastruktúra-függőségek

A domained csendesen számos különböző szolgáltatásra mutat:

DNS – a könyvtár, amely a sajatceg.com-ot tényleges szerver-cím-mé változtatja. Olvassuk a névszerver (NS) rekordokat, és felismerjük a közös szolgáltatókat (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, DigitalOcean, Hetzner, Linode, és regionális registrar-ok köztük).
E-mail – ahol a leveled kezelve van. Olvassuk az MX rekordokat, és felismerjük a közös szolgáltatókat (Google Workspace, Microsoft 365, Proofpoint, Mimecast, Barracuda, Zoho, és mások).

Ebből megállapíthatjuk, hogy ezek a felelősségek szét vannak-e osztva szolgáltatók közt (az egyikben való hiba nem veszi le a többit), vagy halmozva egyetlen szolgáltatóra (kényelmes, de egyetlen leállás vagy feltörés mindent levet).

Mit jelent a „jó” beállítás: legalább a DNS egy dedikált, megbízható szolgáltatónál tartva, nem ugyanabba a fiókba csomagolva mindennel – hogy a domain könyvtára ne ossza a weboldal és a postafiók sorsát.

Hogyan javítsd ki (ingyenes, ~1 délután)

Add ezt az IT-személyednek vagy webfejlesztőnek – a javítás ingyenes. Egy CDN/WAF az oldal elé helyezése semmibe sem kerül a közös ingyenes szinteken, és a szerver-verzió elnyomása egy egysoros beállítás. Nincs licenc-vásárlás. (A fizetős lehetőségek itt csak a figyelés, portfólió-nyomon követés és auditok – soha nem maga a javítás.) A tulajdonos egyetlen döntése: igen, tegyél pajzsot az oldal elé.

Mivel mindkét ellenőrzés tájékoztató, ezek egyike sem pontozásos – de egy CDN/WAF az egyik legjobb értékű rugalmasság-fejlesztés, amelyet egy kis vállalkozás tehet, tehát megér elvégezni.

1. Tegyél egy CDN/WAF-ot az oldal elé

A legközösebb, ingyenes út a Cloudflare:

Hozz létre egy ingyenes Cloudflare fiókot, és add hozzá a domainedet.
A Cloudflare olvassa a meglévő DNS rekordokat; ellenőrizd, hogy helyesen importáltak-e.
Változtasd meg a domain névszervereit (a registrar-odnál) a Cloudflare által adott kettőre. Ez az a váltás, amely a forgalmat a Cloudflare-en keresztül irányítja.
Állítsd az SSL/TLS módot Full (strict)-re, hogy a titkosítás végponttól végpontig maradjon a látogató → Cloudflare → az originalod között. (Kerüld a “Flexible”-t, amely az utolsó részt titkosítatlanul hagyja.)
A CDN és egy alap WAF most aktív. A WAF szabályokat később hangolhatod, de az alapbeállítások már sokat szűrnek.

Más utak, a stackedtől függően:

AWS CloudFront – hozz létre egy disztribúciót az originalodra mutatva; párosítsd AWS WAF-fal a szűréshez. Legjobb, ha már AWS-en vagy.
Sucuri WAF – DNS-alapú, nem igényel változtatásokat a szerveren; jó, ha nem tudsz hozzányúlni az originhoz.
Fastly / Akamai – vállalati szintű CDN-ek/WAF-ok, tipikusan nagyobb vagy magasabb forgalmú oldalakhoz.

Az átváltás után teszteld az oldalt, erősítsd meg, hogy a HTTPS mindenhol működik, és figyeld meg egy napig. Ne gyorsítótárazz agresszívan olyan oldalakat, amelyeknek személyesnek vagy élőnek kell maradniuk (bejelentkezett területek, kosarak, pénztárak).

2. Állítsd le a szerver-verzió hirdetését

Akár hozzáadsz CDN-t, akár nem, nyomd el a verzió hirdetését – ez ingyenes információ, amelyet a támadóknak adsz.

Nginx:

server_tokens off;

Apache (a fő konfigurációban):

ServerTokens Prod
ServerSignature Off

Távolíts el egy túl sokat megosztó X-Powered-By fejlécet (pl. PHP-ból vagy alkalmazás keretrendszerből) szerver vagy CDN szinten – a Cloudflare-nél egy válasz-fejléc átalakítási szabállyal el tudod távolítani.

3. Ellenőrizd a szolgáltatói térképet (opcionális, ~10 perc)

Nézd meg, hol él ténylegesen a DNS-ed, a weboldaladat és az e-maile:

Ha mindhárom egy szolgáltatói fiókban van, fontold meg legalább a DNS mozgatását egy dedikált szolgáltatóhoz (a Cloudflare DNS ingyenes és gyors). Ez az egyetlen szétválasztás azt jelenti, hogy a domain könyvtára túléli a tárhelyi leállást.
Írd le a térképet – DNS-szolgáltató, webhoszt, e-mail-szolgáltató, registrar, és a bejelentkezési/ügyfélszolgálati elérhetőség mindegyikhez. Ez az egy oldal a leghasznosabb dolog, amelyet incidens során maga előtt tarthat az ember.

Platform megjegyzések

Google Workspace / Microsoft 365: ezek az e-mail szolgáltatóid, nem a weboldaladat. Egy CDN/WAF az oldal elé helyezése nem érinti az e-mailt, és fordítva – különálló döntések. (E-mail a Google/Microsoft-nál és a webhely a Cloudflare mögött teljesen jó, szándékosan szétválasztott beállítás.)
Managed site builder-ek (Wix, Squarespace, Shopify): ezek saját CDN-t és egy WAF-védelmi szintet tartalmaznak a platform részeként, tehát már védve lehetrsz akkor is, ha a fejléc-ellenőrzésünk nem nevez meg egy szolgáltatót. Általában nem tudsz saját Cloudflare-t hozzáadni elé; ez rendben van – a platform kezeli.
WordPress a saját tárhelyeden: ideális jelölt egy ingyenes Cloudflare rétegnek elöl. Kombináld egy biztonsági bővítmény tűzfalával az alkalmazás-szintű szabályokhoz.

Általános hibák

Sima origint futtatni, ‘mert az oldal kis’. A kis oldalak ugyanazokat az automatizált támadásokat és bot-özönöket kapják, mint a nagyok – a botok nem ellenőrzik először a bevételedet. Az ingyenes CDN/WAF szint pontosan kis oldalakhoz létezik; nem használni azt egy könnyű nyereményt hagy az asztalon.
Cloudflare ‘Flexible’ SSL használata. Lakatot mutat, de a Cloudflare és az originalod közötti kapcsolatot titkosítatlanul hagyja. Mindig használj Full (strict)-et, hogy végponttól végpontig titkosított legyen.
A rossz dolgok gyorsítótárazása. Bejelentkezett oldalak, kosarak vagy pénztárak agresszív gyorsítótárazása az egyik ügyfélnek a másik tartalmát vagy elavult árakat mutathatja. Gyorsítótárazz statikus tartalmat; hagyd a személyes és tranzakciós oldalakat gyorsítótárazatlanul.
Mindent egy szolgáltatóra halmozni anélkül, hogy észrevennéd. A kényelem rendben van, ha tudatos döntés – de sok vállalkozás csak a leállás során fedezi fel, hogy a DNS, a web és az e-mail egy fiókban van, amely mindhármat leszedi. Tedd döntéssé, ne felfedezéssé.
Kint hagyni a szerver-verziót kijelzőn. Ez egy ingyenes, egysoros keményítési lépés, amelyet könnyű elfelejteni. Kapcsold ki.

Megjegyzés a besorolásról

Teljesen egyértelműen: ezen ellenőrzések egyike sem befolyásolja a besorolásodat. A módszertanunkban tájékoztatóként vannak nyilvántartva, nulla ponttal, és soha nem büntetünk pajzs nélküli originért vagy egyetlen-szolgáltatós beállításért. Azért számolunk be róluk, mert valódi kitettséget írnak le a leállásra, a támadásra és a lassú incidenshelyreállításra – és mert egy ingyenes CDN/WAF hozzáadása az egyik legjobb értékű fejlesztés, amelyet egy kis vállalkozás tehet. Ha itt semmit nem teszel, a besorolásod változatlan. Ha pajzsot teszel az oldal elé, és szétválasztod a DNS-t, a vállalkozást érdemben rugalmasabbá tetted ingyen. Ez a helyes módja ennek az oldalnak az olvasásának: nem egy szám, amelyet meg kell védeni, hanem egy rugalmasság-fejlesztés, amelyet érdemes elvégezni.

GYIK

Ezek nem befolyásolják a besorolásomat – miért törődjek velük?

Mert a besorolás mér specifikus biztonsági vezérlőket (titkosítás, e-mail-hamisítás elleni védelem, biztonsági fejlécek), miközben ez a két ellenőrzés a rugalmasságodat írja le – mennyire vagy kitéve a leállásnak és a támadásnak. Egy pajzs nélküli szerver még mindig jól pontozhat a pontozott ellenőrzéseknél, és még mindig leeshet offline egy bot-özöntől az indulás napján. A besorolás és a rugalmasság különböző kérdések; ez az oldal a másodikról szól. Egy CDN/WAF hozzáadása az egyik legjobb értékű fejlesztés, amelyet tehetsz, besorolástól függetlenül.

Nem vagyok technikai beállítottságú – mit kell ténylegesen tennem?

Egy döntés és egy átadás. A döntés: akarsz-e egy védő pajzsot (CDN/WAF) az oldal elé? Szinte minden vállalkozás számára a válasz igen, és a közös út – a Cloudflare ingyenes szintje – semmibe sem kerül. Az átadás: add a 'Hogyan javítsd ki' részt annak, aki a weboldaladat vagy domainedet kezeli. Egy ingyenes CDN/WAF beállítása tipikusan egy délután munkája, licencköltség nélkül. A javítás ingyenes; csak az opcionális figyelés és portfólió eszközök fizetnek.

Mi a különbség a CDN és a WAF között – mindkettőre szükségem van?

Egy CDN (Content Delivery Network) egy globális szerverhálózat, amely az oldal elé ül, a tartalmaidat közel a látogatókhoz gyorsítótárazza, hogy az oldalak gyorsan töltsenek be bárhol, és elnyeli a forgalmi csúcsokat, hogy egy roham ne zúzza össze az origint. Egy WAF (Web Application Firewall) egy szűrőréteg, amely megvizsgálja a bejövő kéréseket, és blokkolja a rosszindulatúakat – befecskendezési kísérleteket, bot-támadásokat, ismert exploit mintákat – mielőtt elérik a szerveredet. A jó hír az, hogy a népszerű szolgáltatások mindkettőt egybecsomagolják: kapcsold be a Cloudflare-t (vagy hasonlót), és egyszerre kapod a CDN-t és egy alap WAF-ot. Tehát a gyakorlatban ez egy beállítás, két előnnyel.

Rossz-e, hogy az összes szolgáltatásom egy szolgáltatónál van?

Koncentrációs kockázat, nem vétek. A kényelem valódi – egy számla, egy bejelentkezés, egy ügyfélszolgálati vonal. De a kompromisszum az, hogy egyetlen leállás vagy fiók-feltörés egyszerre veheti le a DNS-edet, a weboldaladat és az e-mailedet, és alkalmatlanná tehet arra, hogy akár kommunikálni sem tudsz erről. Sok kis vállalkozás ezt tudatosan elfogadja. Az ellenőrzés célja egyszerűen az, hogy a függőséget láthatóvá tegye, hogy döntés legyen, ne meglepetés. Egy közös, alacsony erőfeszítésű fejlesztés a DNS dedikált szolgáltatóhoz való mozgatása (a Cloudflare DNS ingyenes), hogy legalább a domain könyvtára ne osztozzon az elhelyezés sorsán.

Felismertük a szerver szoftverot és verzióját – miért számít ez?

Amikor a szervered pontosan hirdeti a futtatott szoftvert és melyik verziót (a 'Server' vagy 'X-Powered-By' fejlécben), parancsikont ad a támadóknak: meg tudják keresni az ismert sebezhetőségeket az adott verzióhoz, és egyenesen rá céloznak. Önmagában nem tesz téged bizonytalanná, de felesleges információfelfedés – mint amilyen, ha a záraid gyártóját és típusát hagyod a bejárati ajtón. A verzió elnyomása (egyetlen szerverbeállítás sor, ingyenes) egy kis, ésszerű keményítési lépés. Lefedi az alábbi javítási lépések.

Tönkretesz-e bármit egy CDN az oldal elé helyezése, vagy lelassítja-e azt?

Helyesen elvégezve felgyorsítja az oldalt – ez az egész CDN lényege. A fő dolgok, amelyeket helyesen kell csinálni a beállítás során: biztosítsd, hogy a HTTPS végponttól végpontig maradjon (használj 'Full (strict)' módot a Cloudflare-nél, nem a 'Flexible'-t, ami a legutolsó részt titkosítatlanul hagyja), és ne gyorsítótárazz agresszívan olyan oldalakat, amelyeknek személyesnek vagy élőnek kell maradniuk (bejelentkezett irányítópultok, pénztárak). A jó hírű szolgáltatók ésszerű alapbeállításokra állítanak be. A névszerverek átváltása után teszteld az oldalt, figyeld meg egy napig, és egy gyorsabb, védett oldala lesz, hátrány nélkül.