# Cloudflare, tűzfal és e-mail védelem — a beállítás, amin a legtöbben elcsúsznak URL: https://rootcr.hu/cloudflare-tuzfal-email-vedelem/ Frissítve: 2026-09-24 # Cloudflare, tűzfal és e-mail védelem: a beállítás, amin a legtöbben elcsúsznak > **Röviden:** A RootCR beállítja a Cloudflare és a többi nagy szolgáltató védelmi rétegét: webes tűzfal (WAF), bot- és DDoS-védelem, a szerver valódi IP-címének elrejtése, és a céges levelezés hitelesítése (SPF, DKIM, DMARC), hogy a levél ne a spam mappában kössön ki. A munka a meglévő fiókjaidban történik, minden lépés mérve. Saját rendszereinken 26 Cloudflare-zóna fut így (2026-09-24). Egyedi megállapodás alapján. ## 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: 1. **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. 2. **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. 3. **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. 4. **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](/ai-chatbot-fejlesztes/) 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`, DMARC `reject`), 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:

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: 1. **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á. 2. **Írásos terv.** Mi változik, milyen sorrendben, mi a kockázat, és hogyan állítjuk vissza, ha kell. 3. **Mentés.** A DNS-zóna és a meglévő szabályok exportja minden változtatás előtt. 4. **Bevezetés lépésenként,** ahol lehet, figyelő módból indulva, a forgalmas órákon kívül. 5. **Mérés és átadás.** Jegyzőkönyv arról, mi van beállítva és mi lett mérve, dátummal. 6. **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](/weboldal-javitas/) 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: 1. **Nincs rés a CDN mellett.** A szerver kívülről csak a védelmen keresztül érhető el. 2. **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. 3. **Minden visszaállítható.** Mentés minden lépés előtt, írásos leírás minden beállításról.
Nem tudod, most hol állsz? Írd meg a domaineidet, és azt, hogy milyen rendszerekből megy ki levél a nevedben. Megmondom, mi látszik kívülről: elérhető-e a szervered a CDN megkerülésével, és átmegy-e a leveled a nagy szolgáltatók hitelesítésén.
## 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](/biztonsag-felugyelet/) és a [tárhely és VPS](/tarhely-es-vps/) oldal írja le.