Hogyan akadályozza meg, hogy bárki a cége nevében küldjön levelet. A három rekord szerepe, a bevezetés sorrendje és a leggyakoribb hibák.
A levelezés alapprotokollja nem tartalmaz hitelesítést: bárki beírhat a feladó mezőbe bármit. A három DNS-rekord (SPF, DKIM, DMARC) ezt a hiányt pótolja, és együtt megakadályozzák, hogy idegen a cég nevében küldjön levelet.
A gond, hogy sok szervezetnél be vannak állítva, csak nem működnek.
SPF felsorolja, mely szerverek küldhetnek levelet a domain nevében. A fogadó ellenőrzi, hogy a küldő IP szerepel-e a listán.
DKIM kriptográfiai aláírást tesz a levélre. A fogadó a DNS-ből lekért nyilvános kulccsal ellenőrzi, hogy a levél nem változott útközben, és tényleg a domainről indult.
DMARC összeköti a kettőt: megmondja, mi történjen, ha az ellenőrzés megbukik, és hova jelentsenek erről. Ez a legfontosabb, mert az SPF és a DKIM önmagában csak jelez, nem tilt.
A p=none beállítás semmit nem blokkol, csak jelentést kér. Ez a bevezetés első lépésének való, de sok szervezetnél évekig ott marad, mert senki nem meri továbblépni.
Az érvényesítés két szintje:
p=quarantine: a megbukott levél a levélszemét mappába kerülp=reject: a megbukott levelet a fogadó elutasítjaAmíg nincs p=reject, addig bárki küldhet levelet a cég nevében, és az célba is ér.
1. Küldő-leltár. Melyik rendszer küld levelet a domain nevében? A saját levelezőn kívül jellemzően van hírlevélküldő, számlázó, CRM, HR-rendszer, monitorozó eszköz. Ezek mindegyikét fel kell venni az SPF-be, különben a saját leveleit fogja blokkolni.
2. SPF beállítása. Figyelem a tíz DNS-lekérdezés korlátjára: ha túl sok include van benne, az SPF érvénytelenné válik. Ez gyakori probléma sok szolgáltatásnál.
3. DKIM minden küldőn. Nem elég a fő levelezőn: minden rendszernek, ami a domain nevében küld, saját aláíró kulcsot kell kapnia.
4. DMARC p=none, jelentésekkel. Néhány hét alatt kiderül, mely küldők buknak meg, és melyik jogos.
5. Fokozatos szigorítás. p=quarantine részleges százalékkal, aztán teljes, végül p=reject.
BIMI. A logó megjelenítése a levél mellett a fogadó levelezőjében. Feltétele az érvényesített DMARC, tehát csak akkor jön szóba, ha a fenti kész. Márkaérték és bizalmi jelzés.
MTA-STS. Kikényszeríti, hogy a levelezés titkosított kapcsolaton menjen. Nélküle a titkosítás opcionális, és lefokozható.
Külső feladó jelölése. Nem DNS-rekord, hanem a saját levelezőben beállítható szabály: a kívülről érkező levelekhez látható jelzés kerül. A vezetői utasítás típusú adathalászat ellen ez az egyik leghatékonyabb kontroll.
Az e-mail hitelesítés azt akadályozza meg, hogy a te domained nevében küldjenek levelet. Nem akadályozza meg:
arl1tech.hu),Ezekre az oktatás, a folyamat és a technikai szűrés együtt a válasz. Erről az adathalászatról szóló cikkünkben írtunk részletesen.
A beállítás néhány perc alatt ellenőrizhető: küldjön levelet egy külső postafiókba, és nézze meg a fejlécben az Authentication-Results sort. Ott látszik, hogy az SPF, a DKIM és a DMARC átment-e.
Ha bármelyik fail vagy none, ott van tennivaló. A teljes levelezési architektúra átvizsgálása az IT biztonsági szolgáltatásaink része.
Átfogó IT biztonsági szolgáltatások, tűzfalak, WAF, IPS, SIEM, DLP és végpontvédelem az ARLITECH-től.
A mai phishing már nem a rossz helyesírásról ismerszik meg. Milyen technikák működnek, mit tanítson a…
Kiberbiztonsági képzési és tudatosítási programok szervezetek számára, technikai mélybúvárlattól vezetői…
Szakértőink szívesen átbeszélik, mit jelent mindez az Ön szervezetének környezetében.