Cloudflare, tűzfal és e-mail védelem: a beállítás, amin a legtöbben elcsúsznak
Miért csúszik el a legtöbb Cloudflare-beállítás?
A Cloudflare bekapcsolása öt perc, a jó beállítása nem. A RootCR tapasztalata szerint a hibák nagy része nem hibaüzenettel jelentkezik: az oldal a böngészőben rendben van, közben a védelem megkerülhető, a Google nem éri el a lapot, vagy a fizetési visszaigazolás nem jut át. A leggyakoribb esetek:
| Tünet | Az ok | Amit beállítunk |
|---|---|---|
| A „narancs felhő” be van kapcsolva, a támadás mégis a szervert éri | a szerver a saját IP-címén is válaszol, a CDN megkerülhető | a szerver csak a CDN-től fogad forgalmat, minden mástól eldobja |
| Az IP-cím „el van rejtve”, mégis megtalálható | régi DNS-rekord, szürke felhős aldomain, vagy a levelezés ugyanarra a gépre mutat | DNS-takarítás, a levelezés és a web szétválasztása |
| A Google és az AI-keresők ritkán vagy soha nem járnak az oldalon | minden látogatóra kiterjesztett bot-kihívás, amit a robotok nem tudnak megoldani | ellenőrzött kereső- és AI-botok célzott engedélyezése |
| A webshopban „elvesznek” a kártyás fizetések | a bank visszahívását (webhook) a tűzfal robotnak nézi | kivétel a fizetési szolgáltató visszahívására |
| Csere után a látogatók a régi fájlt látják | a CDN-gyorsítótár a lecserélt fájl régi tartalmát adja | verziózott fájlnevek, gyorsítótár-szabályok |
| Átirányítási hurok vagy „nem biztonságos” figyelmeztetés | rossz SSL-mód a CDN és a szerver között | végig titkosított, tanúsítvánnyal ellenőrzött kapcsolat |
| Eltűnt e-mail cím a gépi olvasatból | a CDN e-mail-cím elrejtése átírja a hivatkozást | a funkció célzott kikapcsolása |
Egy valós eset: 13 óra régi fájl, hibátlan 200-as válaszokkal
A gyorsítótáras eset nem elmélet: a RootCR egyik oldalán 2026. augusztus 27-én a CDN nagyjából 13 órán át egy lecserélt betűfájl régi változatát szolgálta ki, miközben minden kérés hibátlan 200-as választ adott. Azóta minden cserélhető fájl tartalom-lenyomatos nevet kap, és a frissességet böngészőből mérjük.
Hogyan lesz a szerver valódi IP-címe elrejtve?
A RootCR a szerver IP-címét négy rétegben rejti el, mert egy réteg önmagában kevés:
- DNS. Minden webes rekord a CDN-en keresztül megy, a régi és elfelejtett rekordok törölve, a levelezés külön kezelve, hogy az MX- és az SPF-rekord ne árulja el a webszervert.
- A szerver tűzfala. A webes port kizárólag a CDN nyilvánosan közölt címtartományaiból fogad kapcsolatot; minden más csomagot eldob, válasz nélkül. A tartományokat követjük, változáskor frissítjük.
- A webszerver saját ellenőrzése. Ha a tűzfal mögé mégis bejutna egy kérés, a webszerver megnézi, honnan jött, és 403-mal elutasítja, ami nem a CDN-ből érkezett.
- Az adminisztráció láthatatlansága. Távoli belépés csak titkosított magánhálózaton, kulccsal; kívülről nincs nyitott adminisztrációs port.
Mérve kívülről, egy független hálózatból (2026-09-24): a szerver címére közvetlenül küldött webes kérés választ sem kapott, a kapcsolat hat másodperc után időtúllépéssel ért véget; az adminisztrációs port zárva; ugyanaz az oldal a CDN-en át 200-as választ adott.
Egy gyakran kihagyott részlet: a CDN mögött a szerver minden látogatót a CDN címéről lát. Ha ezt nem állítjuk át a valódi látogatói címre, a kéréskorlát minden látogatót egy kalap alá vesz, és egy kitiltás a CDN-t tiltaná ki, nem a támadót.
Mit állítunk be a Cloudflare-en?
A RootCR a Cloudflare-t tételesen, a te fiókodban állítja be, és mindenről leírást kapsz. A legtöbb kis- és középvállalkozásnak az ingyenes csomag is elég, ha jól van beállítva; fizetős csomagot csak akkor javaslunk, ha mérés indokolja.
| Terület | Mit állítunk be |
|---|---|
| Titkosítás | végig titkosított, tanúsítvánnyal ellenőrzött kapcsolat, HSTS, régi protokollok tiltása |
| DNS | DNSSEC, a felesleges és kiszivárgó rekordok takarítása, CAA-rekord |
| Webes tűzfal (WAF) | a kezelt szabálykészlet, saját szabályok az oldal tényleges útvonalaira, admin-felület lezárása |
| Bot- és DDoS-védelem | kihívás ott, ahol kell; az ellenőrzött kereső- és AI-botok, a fizetési és futárszolgálati visszahívások átengedve |
| Kéréskorlát | belépés, űrlap, kereső és API végpontonként |
| Gyorsítótár | szabályok laptípusonként, a pénztár és a fiók soha nem gyorsítótárazva |
| Űrlapvédelem | ember-ellenőrzés a látogató zavarása nélkül |
| Átirányítások | domain-egységesítés, régi címek egy ugrásos 301-gyel |
Minden változtatás előtt a teljes DNS-zóna exportja elkészül, tehát bármelyik lépés visszaállítható.
Mi véd a Cloudflare mögött?
A RootCR a CDN mögé egy második réteget is tesz, mert a CDN szabályai egy ponton átjárhatók, és mert a CDN-t is lehet rosszul beállítani. A szerveren saját webes tűzfal fut egy nyílt, iparági szabálykészlettel.
Az új szabályokat először figyelő módban élesítjük: naplóznak, de nem blokkolnak. Egy túl szigorú szabály ugyanis a rendelést, a fizetést vagy az ajánlatkérést állíthatja meg, hibaüzenet nélkül. A napló alapján finomítunk, és csak utána kapcsolunk éles blokkolásra. A RootCR saját rendszerein ma 6 oldalon éles, 24 oldalon figyelő módban fut a szerveroldali WAF (2026-09-24).
Támadásnál a kitiltás a CDN szélén történik, nagyjából egy másodpercen belül, és a teljes webhelyre érvényes: a támadó következő kérése már a szerverig sem jut el. Ugyanez a rendszer védi az AI chatbotot is.
Miért kerül a céges levél a spam mappába?
A leggyakoribb ok, hogy a domain nem igazolja, ki küldhet a nevében. Három DNS-rekord végzi ezt, a RootCR mindhármat beállítja, és 2024 óta a nagy postafiók-szolgáltatók meg is követelik:
| Rekord | Mit mond | Mi történik nélküle |
|---|---|---|
| SPF | mely szerverek küldhetnek a domain nevében | a levél gyanús, gyakran spam |
| DKIM | digitális aláírás a levélen, hogy útközben nem módosult | a hitelesség nem igazolható |
| DMARC | mit tegyen a fogadó, ha az előző kettő elbukik, és kinek jelentsen | bárki küldhet a céged nevében, és erről nem is tudsz |
A Google és a Yahoo 2024 februárja óta, a Microsoft (Outlook.com, Hotmail) 2025. május 5. óta követeli meg az SPF-et, a DKIM-et és a DMARC-ot a napi 5 000-nél több levelet küldőktől; a Microsoft a megfelelés nélküli levelet azóta 550-es hibakóddal visszautasítja, nem a spam mappába teszi (a szolgáltatók közleményei, 2023–2025). Kisebb küldőnél is ez a mérce: a hitelesítés nélküli levél a spam mappa felé indul.
Mit hibáznak el a levelezés beállításánál?
A RootCR a levelezésnél a küldő rendszerek teljes listájából indul, mert a hiba szinte mindig egy elfelejtett küldő. A tipikus esetek:
- A webshop visszaigazolója spambe megy. A rendelési levelet a webshop szervere küldi, de az nincs benne az SPF-ben. A számlázó, a hírlevélküldő és a CRM ugyanígy.
- Két SPF-rekord van. A szabvány egyet enged; kettőnél a hitelesítés hibára fut, mintha egy sem lenne.
- Túl sok beágyazás az SPF-ben. A szabvány (RFC 7208) legfeljebb 10 DNS-lekérdezést enged; minden szolgáltató-hivatkozás ebbe számít bele, és a 11. már hibát okoz.
- DMARC „p=none” örökre. Ez csak figyel, nem véd; a domain ugyanúgy hamisítható.
- A nem levelező domain nyitva hagyva. Ha egy domainről soha nem megy levél, ki kell mondani (SPF
-all, DMARCreject), különben a csalók erről küldenek. A RootCR által kezelt egyik ügyféldomain pontosan így van lezárva.
A bevezetés sorrendje: DMARC figyelő módban, jelentésekkel; a jelentésekből a küldők teljes listája; minden jogos küldő hitelesítve; utána karantén, végül reject. A RootCR saját domainje reject szabállyal fut. Ha kell, beállítjuk a BIMI-t is, amitől a cég logója megjelenhet a postafiókban; ennek feltétele a szigorú DMARC és egy külön tanúsítvány.
Mely rendszerekkel dolgozunk?
A RootCR a nagy szolgáltatók rendszereit a te fiókodban állítja be, a szolgáltató saját felületén és API-ján. A védelem elve mindenhol ugyanaz, a beállítás szolgáltatónként más:
- Cloudflare
- Akamai
- Fastly
- Amazon CloudFront · AWS WAF
- Azure Front Door
- Google Cloud Armor
- Imperva
- Sucuri
- FortiGate
- pfSense · OPNsense
- MikroTik
- Linux nftables · iptables
- Microsoft 365 · Exchange Online
- Google Workspace
- Amazon SES
- SendGrid · Mailgun · Brevo
- Route 53 · Azure DNS
- Gmail · Outlook.com · Yahoo
A nevek a tulajdonosaik védjegyei. A RootCR egyiknek sem partnere vagy viszonteladója: a beállítást a megrendelő saját fiókjában végzi.
Szövegesen, kategóriánként: tartalomszolgáltató hálózat és webes tűzfal (Cloudflare, Akamai, Fastly, Amazon CloudFront és AWS WAF, Azure Front Door, Google Cloud Armor, Imperva, Sucuri); hálózati tűzfal (FortiGate, pfSense, OPNsense, MikroTik, Linux nftables és iptables); céges levelezés és levélküldés (Microsoft 365 és Exchange Online, Google Workspace, Amazon SES, SendGrid, Mailgun, Brevo); DNS (Cloudflare, Route 53, Azure DNS). A levelezés hitelesítését a Gmail, az Outlook.com és a Yahoo szabályaihoz igazítjuk.
Hogyan zajlik a munka?
A RootCR jelszót nem kér. Hozzáférést korlátozott jogú tagként vagy szűk jogkörű API-kulccsal kapunk a fiókodban, amit bármikor visszavonhatsz. A lépések:
- Felmérés, csak olvasási joggal. DNS, CDN, tűzfal, levelezés, küldő rendszerek; kívülről is mérve, ahogy egy támadó látná.
- Írásos terv. Mi változik, milyen sorrendben, mi a kockázat, és hogyan állítjuk vissza, ha kell.
- Mentés. A DNS-zóna és a meglévő szabályok exportja minden változtatás előtt.
- Bevezetés lépésenként, ahol lehet, figyelő módból indulva, a forgalmas órákon kívül.
- Mérés és átadás. Jegyzőkönyv arról, mi van beállítva és mi lett mérve, dátummal.
- Igény szerint felügyelet. Heti gépi ellenőrzés, hogy senki ne kapcsolja át véletlenül a beállításokat, és riasztás, ha a levelezés hitelesítése elbukik.
Mennyibe kerül?
A RootCR ezt a munkát egyedi megállapodás alapján végzi, mert a terjedelem cégenként nagyon más: egy domain egy postafiókkal vagy tíz domain, három levélküldő rendszerrel, webshoppal és irodai tűzfallal. A felmérés után írásos ajánlatot kapsz, fix áron és fix határidővel. Folyamatos felügyelet külön kérhető.
Ha az oldalad most áll, vagy a leveleid épp nem érnek célba, az sürgős hiba: írj azonnal, a javítás és mentés menetrendje szerint kezeljük.
Amit nem ígérek
Feltörhetetlen rendszer nincs, és egy CDN sem helyettesíti a jól megírt, frissen tartott alkalmazást. Amit a RootCR vállal:
- Nincs rés a CDN mellett. A szerver kívülről csak a védelmen keresztül érhető el.
- Nincs csendes kár. Ami a keresőket, a fizetést vagy a levelezést érinti, azt beállítás után mérjük, nem feltételezzük.
- Minden visszaállítható. Mentés minden lépés előtt, írásos leírás minden beállításról.
Gyakori kérdések
Kell fizetős Cloudflare-csomag?
A legtöbb kis- és középvállalkozásnak nem. A RootCR saját rendszerein mind a 26 zóna az ingyenes csomagon fut (2026-09-24). Fizetős csomagot akkor javaslunk, ha a forgalom, egy speciális szabály vagy a kötelező rendelkezésre állás ezt méréssel indokolja.
Elérhetetlen lesz az oldal a beállítás alatt?
Nem kell, hogy az legyen. A lépések sorrendje úgy van megtervezve, hogy a látogató ne vegyen észre semmit; ahol elkerülhetetlen egy rövid átállás (például névszerver-csere), azt előre egyeztetjük, forgalmas órákon kívülre.
Meglévő WordPress vagy webshop mögé is beállítható?
Igen, a CDN, a tűzfal és a levelezés független attól, milyen rendszeren fut az oldal. Bérelt webshop-platformoknál (például Shopify) a CDN-proxy nem mindig engedélyezett; ott a DNS rendbetétele és a levelezés hitelesítése a feladat.
A leveleink már most is spambe mennek. Mit tudunk gyorsan tenni?
Az első lépés a küldő rendszerek listája és a meglévő rekordok ellenőrzése; a leggyakoribb hiba (elfelejtett küldő, dupla SPF) általában még aznap javítható. A szigorú DMARC-ra állás viszont néhány hét jelentésgyűjtést igényel, hogy egyetlen jogos levél se akadjon el.
Más állította be a Cloudflare-t. Át tudod nézni?
Igen. A felmérés csak olvasási joggal indul, tehát semmi nem változik, amíg a tervet el nem fogadod. Írásban kapod meg, mi kockázatos, mi felesleges, és mi hiányzik.
Irodai hálózatra, tűzfalra is vállaljátok?
Igen, a hálózati tűzfalak (FortiGate, pfSense, OPNsense, MikroTik) beállítását és a telephelyek közötti titkosított összeköttetést is, egyedi megállapodás alapján. A szerver- és kiszolgálóoldali részt a biztonság és felügyelet és a tárhely és VPS oldal írja le.