Defaults.Exposed › Javítások › DMARC (E-mail-hamisítás elleni védelem)

Hogyan javítsd ki: DMARC (E-mail-hamisítás elleni védelem)

A DMARC az egyetlen beállítás, amely ténylegesen megmondja a világ levelezési szolgáltatóinak, hogy BLOKKOLJÁK a te vállalkozásod nevét hamisító e-maileket. Az SPF és a DKIM ellenőrzi a zárait; a DMARC dönt arról, mi történik, ha egy hamisítvány megbukik az ellenőrzésen – kukába, spambe vagy átengedi. Helytelenül beállítva a domainedet teljesen hamisíthatják; helyesen beállítva a megszemélyesítés megáll a postafiókban.

Az üzleted szempontjából lényeg: DMARC-kényszer nélkül egy bűnöző pontosan úgy küldhet e-mailt, mintha a te vállalkozásodtól jönne – az ügyfeleidnek, a személyzetednek és a szállítóidnak –, és bekerül a postafiókjukba, nem a spambe. Embereket ejtik át a nevedben, és téged hibáztatnak.

Mibe kerülhet ez neked

Egy csaló e-mailt küld az ügyfélnek egy valódinak tűnő számlán 'a könyvelési csapatoddal', saját bankszámlaszámukkal. Az ügyfél kifizeti. Hetekkel később tudod meg, amikor az árut kérik, amelyért már fizettek – és felelőssé tesznek téged.
Egy hamis 'sürgős kifizetés' e-mail a saját pénzügyes emberednek megy, neked, a tulajdonosnak tűnve. Átutalják a pénzt, mielőtt bárki gondol az ellenőrzésre – és ha egy bűnöző fiókjára kerül, szinte soha nem szerzik vissza.
Egy nagyobb lehetséges ügyfél IT-csapata biztonsági ellenőrzést futtat a domaineden az aláírás előtt. A visszajövő eredmény: 'az e-mail nincs védve – hamisítható.' A szerződést egy olyan versenytársnak adják, akinek domainja átment.
A domainedet egy adathalász hullámban használják. Az átvert ügyfelek dühös értékeléseket hagynak és figyelmeztetnek másokat. A hírnévkárosodás hónapokkal túléli a támadást.
Még a saját valódi e-maileid is spambe kerülnek, mert a Google és a Yahoo egyre inkább megbízhatatlannak tartja – és mostanra néha visszautasítja – a kényszerített DMARC nélküli domaineket.

Miért fontos. Az e-mailt soha nem úgy tervezték, hogy bizonyítsa, valójában ki küldte, tehát a 'feladó' cím hamisítása triviális. A DMARC az egyetlen vezérlő, amely 'tudjuk érzékelni a hamisítványokat'-ból 'a hamisítványok blokkolva vannak'-ot csinál – és megadja a napi jelentéseket, amelyek feltárják, ki küld levelet a te márkáddal. A nagy levelezési szolgáltatók ma már egy hiányzó vagy érvénytelen DMARC-politikát bizalmatlan jelként kezelnek, tehát ez befolyásolja azt is, hogy a saját e-maileid kézbesülnek-e.

Mi a DMARC egyszerű szavakkal

Az e-mailnek van egy kellemetlen titka: a ‘feladó’ sor csak beírt szöveg. Bárki, bárhonnan, beírhatja a te vállalkozásod nevét és cím-ét egy e-mail ‘feladó’ mezőjébe, és elküldheti. Az internet soha nem volt úgy tervezve, hogy ezt megakadályozza.

Három beállítás van, amelyek együttesen megoldják ezt. Gondolj rájuk, mint egy épület biztonsági rendszerére:

Az SPF azon lista, akinek engedélyezett belépni a bejárati ajtón (melyik levelezési szolgáltatás küldhet neked nevében).
A DKIM hamisításbiztos pecsét, amely bizonyítja, hogy az üzenetet nem változtatták meg az átvitel során.
A DMARC az a biztonsági őr, aki ellenőrzi a listát és a pecsétet – és döntően dönt, mit tegyen, ha nem egyeznek: engedje át, spambe küldje, vagy visszautasítsa az ajtónál.

Meglehet a lista (SPF) és a pecsét (DKIM), és még mindig nincs őr. Ez a leggyakoribb és legveszélyesebb helyzet: a zárak megvannak, de semmi sem kényszeríti ki azokat. A DMARC a kényszer. Ez a különbség aközött, hogy ‘el tudjuk mondani, hogy ez az e-mail hamis’ és ‘ez a hamis e-mail soha nem ér el az ügyfélhez.‘

Mibe kerülhet ez neked

Ez nem elméleti. Íme a konkrét módok, ahogyan egy nem védett domain valódi pénzzé és valódi kárba válik:

A hamis-számla átverés. Egy bűnöző e-mailt küld az ügyfélnek, amelynek pontosan úgy néz ki, mint egy valódi számla a könyvelési csapatoddal – ugyanaz a név, ugyanaz a domain, professzionális elrendezés –, de a saját bankadataikkal. Mert a domainedet nem kényszerítik, bekerül a postafiókba, nem a spambe. Az ügyfél kifizeti. Hetekkel később fedezed fel, amikor megkérdezik, hol van a rendelésük. A pénz általában elment, és az ügyfél sokszor téged tart felelősnek a feltörésért.
A vezérigazgató-csalás banki átutalás. Egy e-mail úgy tűnik, hogy tőled, a tulajdonostól, a pénzügyes emberednek jön: “Át tudod tolni ezt a fizetést sürgősen, egy megbeszélésen vagyok.” Teljesen valódinak látszik, mert az a te cím-ed – csak hamisított. A kifizetés megy ki. Ez a minta – Üzleti E-mail Kompromisszum – az egyik legköltségesebb átverés, amellyel a kis vállalkozásokat érik, pontosan azért, mert az e-mail genuinly a te saját domainedhöz tűnik jönni, tehát egyenesen átmegy a gyanakvásán.
Az elveszített szerződés. Egy komoly lehetséges ügyfél biztonsági vagy ajánlati ellenőrzést futtat az aláírás előtt. Az eszközeik azt jelentik, hogy a domainedet “hamisítható – nincs e-mail-hitelesítési kényszer”. Ez az egyetlen piros jelzés elegendő lehet a szerződés egy olyan versenytárshoz való adáshoz, akinek domainja átment. Soha nem tudod meg az igazi okot.
A hírnévcsapás, amelyet nem tudsz visszacsinálni. A domainedet egy adathalász kampányba söprik. Tucatnyi ember, akit a nevedben ejtetek át, figyelmeztetéseket és értékeléseket tesz közzé. A támadás egy hétig tart; az “egyáltalán biztonságos ez a cég?” kérdés hónapokig megmarad.
A saját e-maileid spambe kerülnek. A Google és a Yahoo ma már aktívan megbízhatatlannak tartja a kényszer nélküli DMARC-kal rendelkező domaineket. Az általad genuinly küldött ajánlatok, számlák és válaszok csendesen spam-mappákba kerülnek. Üzletek megállnak, és soha nem tudod meg, miért.

Mi ez pontosan (és mit jelent a „jó” beállítás)

A DMARC egy egysoros szöveg a domain beállításaiban – egy DNS “TXT” rekord, amelyet a speciális _dmarc.sajatdomain.hu névnél tesznek közzé. Benne van néhány rövid utasítás. Kettő számít legtöbbet, és ezek pontosan az értékelés által ellenőrzött két dolog.

1. A politika (p=) – az őr parancsai. Ez az ellenőrzés erősen súlyozott része. Három dolog egyike lehet:

p=none – csak figyelés. Az őr megjegyzi, ki ment be, de senkit nem állít meg. Ez ellen nem véd semmit; ez egy figyelési szakasz, nem egy kész beállítás. (Az ellenőrző motorunk ezt sikertelenként pontozza – jobb, mint DMARC nélkül, de nem védelem.)
p=quarantine – hamisítványokat spambe küldeni. Valódi védelem, de egy eltökélt támadó arra számít, hogy az emberek ellenőrzik a spam-mappájukat. Szilárd lépközi állomás – nagyjából a féle pontszámot kapja.
p=reject – hamisítványokat visszautasítani az ajtónál. A hamisított e-mail soha nem kézbesül. Ez az egyetlen beállítás, amely teljesen megvéd és teljes pontszámot ér.

Mit jelent a „jó” beállítás: p=reject. Bármi kevesebb rést hagy.

Két technikai részlet, amelyeket az ellenőrzésünk is néz, érdemes tudni, hogy ne kapj meglepetést:

Az aldomain-politika (sp=). Erős politikát állíthatsz be a fő domainedhöz, de véletlenül nyitva hagyhatod az aldomainokat (mint mail.sajatdomain.hu vagy hirek.sajatdomain.hu). A motorunk ezt erősen büntet – egy p=reject-tel de sp=none-val rendelkező domain közel annál is alacsonyabbra pontoz, mint ha egyáltalán nincs kényszer, mert a támadók egyszerűen aldomaint hamisítanak helyette. Jó gyakorlat, ha az sp örökli az erős fő politikát, vagy explicit módon reject-re van állítva.
A százalék (pct=). Gondos bevezetés során a kényszert csak a levél töredékére alkalmazhatod (pl. pct=25). Ez legitim átmeneti eszköz, de egy részleges bevezetés csak részleges védelmet ad, és a pontszámunk ezt tükrözi – fokozatosan emelkedik, ahogy a 25%-tól a 100% felé haladsz, de a teljes pontszám teljes lefedettséget igényel.

2. A jelentési cím (rua=) – a láthatóságod. Ez az oldal második ellenőrzése. Az rua= tag arra kéri a világ minden levelezési szolgáltatóját, hogy napi összefoglalót küldjenek neked arról, ki próbált e-mailt küldeni a domainedhez – a saját rendszereid és bármely megszemélyesítő. Nélküle vakon repülsz: fogalmad sincs, ki él vissza a neveddel. Vele a vállalkozások rutinszerűen fedeznek fel az első napon 5–50 jogosulatlan feladót.

Mit jelent a „jó” beállítás a jelentésnél: egy érvényes rua=mailto: cím (vagy egy jelentési-szolgáltatás https: URL), amely ténylegesen fogadja a jelentéseket. Az ellenőrzésünk érvényesíti a formátumot – egy hibásan beírt vagy rosszul formázott cím azt jelenti, hogy a jelentések csendesen sehova nem mennek, ami részleges vagy sikertelen eredményként pontoz, még ha egy tag technikailag “jelen” is van.

Hogyan javítsd ki (ingyenes, ~30 perc két hétre elosztva)

Add ezt a részt annak, aki a domainedet, weboldaladat vagy IT-jét kezeli – a javítás teljesen ingyenes. Mi csak azért számítunk fel díjat, ha idővel figyeljük, hogy helyesen marad-e, domainportfóliót kezelünk, vagy auditot biztosítunk. Maga a módosítás semmibe sem kerül.

Az arany szabály: soha ne ugord egyenesen a reject-re. Először kapcsold be a figyelést, nézd meg a jelentéseket, erősítsd meg, hogy a valódi leveled felismerve van, majd szorítsd meg. Ebben a sorrendben elvégezve biztonságos; siettetetten elvégezve a saját e-mailedet spambe küldheti.

1. lépés – Győződj meg először, hogy az SPF és a DKIM a helyén van. A DMARC ezekre támaszkodik. Ha valamelyik hiányzik, rendezd azokat a DMARC kényszerítése előtt (lásd az SPF és DKIM oldalakat).

2. lépés – Tegyél közzé egy figyelési rekordot bekapcsolt jelentéskészítéssel. Adj hozzá egy DNS TXT rekordot:

Hoszt / név: _dmarc.sajatdomain.hu (a DNS-szolgáltatód ezt csak _dmarc-ként mutathatja)
Típus: TXT
Érték: v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s

Ez figyel és jelent semmit sem blokkolva még. Az adkim=s; aspf=s részek szigorú igazodást kérnek – hagyd ki ezeket először, ha nem vagy biztos, és add hozzá, amint a leveled megerősítetten tiszta.

3. lépés – Olvasd a jelentéseket ~2 hétig. A nyers DMARC-jelentések sűrű XML. Használj ingyenes jelentési szolgáltatást (pl. dmarcian vagy a Postmark ingyenes DMARC eszköze) a olvasható irányítópulttá alakításhoz. Erősítsd meg, hogy minden legitim feladó – a levelezési szolgáltatód, hírlevél-eszközöd, CRM, helpdesk, számlázó alkalmazás – átmegy. Javíts bármelyik valódi feladót, amelyik nem.

4. lépés – Menj quarantine-ra. Amint a valódi leveled tiszta, változtasd meg a p=none-t p=quarantine-ra. Figyelj még néhány napig.

5. lépés – Menj reject-re. Végül változtasd meg a p=quarantine-t p=reject-re. Most teljes mértékben védve vagy. A végső rekord így néz ki:

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s

6. lépés – Ne felejtkezz el az aldomainekről. Győződj meg, hogy nem hagytad az sp=none-t a helyén. Ha egyáltalán nem teszöl közzé sp-t, az aldomainek öröklik a fő p= politikádat, ami az, amit akarsz.

Megjegyzések platformonként:

Google Workspace / Microsoft 365: Mindkettő teljes mértékben támogatja a DMARC-ot. Maga a DMARC rekord a DNS-szolgáltatódba megy, nem a Google vagy a Microsoft adminisztrációs konzoljába – először győződj meg, hogy az SPF és a DKIM engedélyezve van az adminkonzolban, majd tedd közzé a DMARC TXT rekordot a registrar-nál/DNS-hosztodnál.
Cloudflare: DNS > Records > Add record > TXT, név _dmarc, illeszt be az értéket. A Cloudflare beépített DMARC-kezelést is kínál, amely beállíthatja ezt és összegyűjtheti a jelentéseket neked.
Általános hosztok / registrar-ok (Blacknight, GoDaddy, stb.): Keresd a “DNS”, “DNS Zone” vagy “Advanced DNS” részt, adj hozzá egy TXT rekordot _dmarc névvel és a fenti értékkel. A terjedés általában néhány perctől egy óráig tart.

Általános hibák

Megállni a p=none-nál. Messze a leggyakoribb hiba. A figyelés a kezdet, nem a befejezés – egy none-nál ragadt domain még mindig teljesen hamisítható. A motorunk pontosan ezért pontozza sikertelenként.
Egyenesen reject-re ugrani figyelés nélkül. Az ellentétes hiba. A jelentési szakasz nélkül lehet, hogy nem veszed észre, hogy egy legitim feladó (sokszor egy hírlevél- vagy számlázó eszköz) nincs igazítva – és elkezded blokkolni a saját leveleidet.
Az aldomain-politika elfelejtése. Egy erős p=reject sp=none-val nyitva hagy egy hátsó ajtót; a támadók egyszerűen aldomaint hamisítanak helyette.
Törött jelentési cím. Egy hibásan beírt rua= (vagy a mailto: előtag nélkül) azt jelenti, hogy a jelentések sehova nem mennek, és te vakon maradsz anélkül, hogy rájönnél. A formátumnak érvényes mailto: vagy https: URI-nak kell lennie, különben a jelentések soha nem kerülnek kézbesítésre.
“Nem küldünk e-mailt, tehát kihagyjuk.” Egy nem-küldő domain első osztályú célpont pontosan azért, mert senki nem figyeli. Tegyél közzé egy szigorú reject politikát, hogy teljesen bezárd.

Megjegyzés a pontozásról

A politika ellenőrzés (p=) az egész értékelés egyik legsúlyosabb tétele – mert ez az egyetlen legnagyobb tényező abban, hogy a vállalkozásodat meg lehet-e személyesíteni. A reject teljes pontszámot ér; a quarantine nagyjából a felét; a none és a hiányzó rekord sikertelenként pontozódnak. Egy gyengébb aldomain-politika vagy részleges pct= bevezetés a pontszámot leviszi a ténylegesen meglevő védelmi szint megfelelőjéhez.

A jelentési ellenőrzés (rua=) is valódi súlyt hord, de gondolj rá inkább mint a reject-hez biztonságosan eljuttató eszközre, mintsem kipipálandó jelölőnégyzetre. Állítsd be a figyelési rekorddal egyidejűleg, és az első napon láthatóságban megtéríti önmagát.

Állítsd be a tárhelyszolgáltatódnál

Lépésről lépésre a népszerű szolgáltatóknál:

GYIK

Egyáltalán nem vagyok technikai beállítottságú – tényleg meg tudom ezt oldani?

Igen, de nem kell személyesen elvégezned. A javítás néhány sor hozzáadása a domain beállításaihoz, és ingyenes. A legegyszerűbb út az, hogy az alábbi 'Hogyan javítsd ki' részt továbbítod annak, aki a weboldaladat vagy az IT-ügyfélszolgáltatodat futtatja. Tipikusan jól egy óra alatt elvégzik, néhány hetes biztonságos figyeléssel elosztva.

Tönkreteheti-e a DMARC bekapcsolása a saját e-mailem kézbesítését?

Igen – de csak ha kihagyod a biztonságos bevezetést. Az egész lényege a 'csak figyelés' (p=none) bekapcsolásával és a jelentéskészítés beindításával való kezdésnek az, hogy két hétig figyeld, és erősítsd meg, hogy minden legitim feladó (a postafiókod, a hírlevél-eszközöd, a számlázó alkalmazásod) helyesen van felismerve, MIELŐTT átvált blokkolásra. Ebben a sorrendben elvégezve a valódi e-mailedre nincs hatása. Azonnal 'reject'-re ugrás a jelentések ellenőrzése nélkül az egyetlen közös hiba, amely eltöri a kézbesítést.

Már be van állítva SPF és DKIM. Nem elég ez?

Nem – és ez a legfontosabb megértendő pont. Az SPF és a DKIM a zárak; a DMARC az az utasítás, amely azt mondja: 'ha a zárak nem egyeznek, utasítsd el az e-mailt.' DMARC 'reject' nélkül egy fogadó szerver észreveheti, hogy egy e-mail hamis, és még mindig kézbesítheti. Az SPF és a DKIM előfeltételei a DMARC működéséhez, de önmagukban nem akadályozzák meg, hogy egy hamisított e-mail elérje a postafiókot.

Mi a különbség a 'none', 'quarantine' és 'reject' között? Melyikre van szükségem?

A 'none' csak figyel és jelent – semmit sem állít meg, tehát nem véd. A 'quarantine' a hamisítványokat a spambe küldi. A 'reject' egyenesen visszautasítja, tehát soha nem érkeznek meg. A 'reject' a cél és az egyetlen beállítás, amely teljes pontszámot kap. A 'quarantine' ésszerű lépközi állomás; a 'none' az első pár hét kiindulópontja, nem a cél.

Mi az az 'rua' jelentési dolog, és szükségem van-e rá?

Az rua tag arra kéri a levelezési szolgáltatókat, hogy napi összefoglalót küldjenek neked minden rendszerről, amely e-mailt próbált küldeni a domainedhöz – beleértve a bűnözőket is. Így fedezik fel a vállalkozások az első napon az 5–50 jogosulatlan feladót, amely tipikusan visszaél egy domainnel. Önmagában kevesebb súlyt hord, mint a politika, de így juthatod el biztonságosan a 'reject'-hez anélkül, hogy eltörnéd a valódi e-mailedet, tehát ugyanakkor állítsd be.

Alig küldünk e-mailt, vagy egyáltalán nem küldünk e-mailt erről a domainről. Még mindig szükségünk van DMARC-ra?

Különösen akkor. Egy olyan domain, amely kevés vagy semmilyen valódi e-mailt nem küld, tökéletes, alacsony-zajú célpont a bűnözők számára a megszemélyesítésre, mert senki nem figyeli. Az a domain, amelyről soha nem küldünk levelet, szigorú elutasítási politikát kell közzétennie – ez tiszta, alacsony kockázatú nyeremény, amely teljesen becsukja az ajtót.