Zakaj ponarejanje e-pošte še vedno deluje
Protokol, ki prenaša e-pošto (SMTP), je bil zasnovan brez preverjanja, kdo je pošiljatelj v resnici. Sporočilo z vašim naslovom v polju Od lahko pošlje kdorkoli in s katerega koli strežnika na svetu. Zato so goljufije z lažnimi računi, spremenjenimi podatki za plačilo in sporočili v imenu direktorja ali dobavitelja še vedno tako uspešne.
To vrzel zapirajo trije zapisi DNS. SPF določa, kateri strežniki smejo pošiljati pošto za vašo domeno, DKIM vsakemu sporočilu doda kriptografski podpis, DMARC pa prejemnikom pove, kaj naj storijo s sporočilom, ki ne prestane preverjanja, in vam o tem pošilja poročila. Noben od njih sam ne zadošča: prava zaščita nastane šele, ko delujejo skupaj in ima DMARC uveljavljeno politiko.
Orodje zgoraj te zapise prebere iz javnega DNS in za vsakega pokaže, ali je v redu in kateri zapis objaviti v naslednjem koraku.
SPF zapis: kdo sme pošiljati v vašem imenu
SPF (RFC 7208) je zapis TXT na korenu domene, na primer v=spf1 include:spf.protection.outlook.com -all. Prejemni strežnik preveri, ali je naslov IP pošiljatelja na seznamu. Največ težav povzročajo tri pravila:
- Natanko en zapis. Dva zapisa, ki se začneta z
v=spf1, se ne seštejeta, temveč povzročita trajno napako (permerror), zato SPF ne uspe za vso pošto. Ko dodate novo storitev, razširite obstoječi zapis in ne ustvarite drugega. - Največ 10 poizvedb DNS. Vsak
include,a,mx,existsinredirect, tudi tisti v vključenih zapisih, šteje v omejitev 10 poizvedb. Nekaj storitev za e-novice in CRM jo hitro preseže. Orodje število oceni tako, da sledi vključitvam. - Smiseln zaključek.
-all(zavrni neznane pošiljatelje) in~all(označi jih kot sumljive) sta ob vzpostavljenem DMARC oba ustrezna.?allne ščiti,+allpa pošiljanje v vašem imenu dovoli vsemu internetu.
SPF ima eno slabost: preverja tehničnega pošiljatelja ovojnice, ne naslova Od, ki ga vidi prejemnik, in se pokvari pri posredovanju sporočila. Zato potrebuje DKIM in DMARC.
DKIM: podpis, ki preživi posredovanje
Pri DKIM (RFC 6376) strežnik pošiljatelja vsako sporočilo podpiše z zasebnim ključem, prejemnik pa podpis preveri z javnim ključem, objavljenim v DNS na <selektor>._domainkey.vasadomena.si. Podpis praviloma preživi tudi posredovanje, zato je DKIM navadno zanesljivejša podlaga za DMARC.
Selektor je poljubno ime, ki ga izbere ponudnik. Microsoft 365 uporablja selector1 in selector2, objavljena kot zapisa CNAME, ki kažeta k Microsoftu. Google Workspace privzeto uporablja google. Platforme za e-novice in CRM imajo vsaka svojega. Ker selektorjev iz DNS ni mogoče izpisati, lahko orodje preveri le pogosta imena. Če ne najde ničesar, poglejte glavo DKIM-Signature poslanega sporočila: oznaka s= je vaš selektor in ga lahko vpišete v orodje.
Kjer ponudnik to omogoča, uporabite ključe RSA z 2048 biti. Google jih priporoča v smernicah za pošiljatelje, v Microsoft 365 pa lahko z 1024 na 2048 bitov preidete ob naslednji menjavi ključev.
DMARC: politika, ki vse poveže
DMARC je zapis TXT na _dmarc.vasadomena.si. Sporočilo prestane DMARC, ko uspe SPF ali DKIM in se domena, ki jo preverjata, ujema (je poravnana) z domeno v vidnem naslovu Od. Zapis določa tudi politiko za sporočila, ki ne uspejo:
| Politika | Kaj naredijo prejemniki | Kdaj jo uporabiti |
|---|---|---|
p=none | Dostavijo normalno, pošiljajo poročila | Prve dva do štiri tedne, da najdete vse legitimne pošiljatelje |
p=quarantine | Neuspešno pošto premaknejo med neželeno | Ko poročila pokažejo, da vaša pošta uspe |
p=reject | Neuspešno pošto zavrnejo | Ciljno stanje za vsako domeno |
Oznaka rua določa naslov za zbirna poročila, datoteke XML, v katerih prejemniki navedejo, kateri strežniki so pošiljali pošto v vašem imenu in ali je uspela. Brez njih delate na slepo, zato vedno začnite s p=none in naslovom rua, na primer v=DMARC1; p=none; rua=mailto:dmarc-reports@vasadomena.si. Storitev za poročila DMARC naredi XML berljiv.
Maja 2026 je IETF objavil RFC 9989, ki nadomešča prvotno specifikacijo DMARC, RFC 7489. Obstoječi zapisi v=DMARC1 delujejo naprej. Najbolj vidni spremembi sta, da je oznaka pct odpravljena in nadomeščena s testno oznako t=y ter da nova oznaka np določa politiko za neobstoječe poddomene.
Kaj zahtevata Gmail in Yahoo
Gmail od februarja 2024 od vseh pošiljateljev zahteva SPF ali DKIM. Kdor na račune Gmail pošlje več kot 5.000 sporočil na dan, mora imeti SPF in DKIM, zapis DMARC (politika je lahko none), domeno v naslovu Od, poravnano s SPF ali DKIM, odjavo z enim klikom za trženjsko pošto in delež neželene pošte pod 0,3 %. Yahoo za množične pošiljatelje določa praktično enaka pravila. Tudi če pošiljate manj, ta pravila kažejo smer: nepreverjena pošta vse pogosteje konča med neželeno ali je zavrnjena.
Najpogostejše napake
- Pozabljeni pošiljatelji. ERP pošilja račune, spletna trgovina potrditve naročil, sistem za podporo obvestila o zahtevkih, nobeden pa ni v SPF in ne podpisuje z DKIM. V poročilih DMARC se pokažejo takoj, ko jih začnete brati.
- Leta na p=none. Spremljanje je faza, ne zaščita. Prehod na quarantine in reject načrtujte z datumi.
- Šibka politika za poddomene.
sp=noneobp=rejectnapadalcem omogoča pošiljanje z izmišljenih poddomen. - Nezaščitene parkirane domene. Domene, ki ne pošiljajo pošte, potrebujejo
v=spf1 -allinv=DMARC1; p=reject, sicer so idealne za ponarejanje. To velja tudi za stare domene, na primer po preimenovanju podjetja. - Dva zapisa SPF po menjavi ponudnika in zapisi SPF nad omejitvijo poizvedb.
Varna pot do p=reject
- Popišite vse storitve, ki pošiljajo pošto v vašem imenu.
- Objavite en zapis SPF in vklopite DKIM za glavni poštni sistem in vsako storitev.
- Objavite DMARC s
p=noneinruater dva do štiri tedne berite poročila. - Uredite pošiljatelje, ki niso poravnani, in preidite na
p=quarantine. - Ko so poročila čista, preidite na
p=rejectin jih še naprej spremljajte.
Zaščita domene pred ponarejanjem je smiseln del ukrepov za obvladovanje kibernetskih tveganj, ki jih zahteva ZInfV-1 (NIS2). Ali ste zavezanec, preverite v vodiču ZInfV-1 in NIS2, širše oceno obrambe pa v oceni pripravljenosti na kibernetski napad. Poskuse lažnega predstavljanja lahko prijavite tudi nacionalnemu odzivnemu centru SI-CERT.
Humanfrog vzpostavlja in upravlja Microsoft 365 in varnost e-pošte, vključno s SPF, DKIM, poročili DMARC ter postopnim prehodom na p=reject brez izgubljene pošte. Če želite rezultat pregledati s strokovnjakom, nam pišite.
