E-pasta autentiskuma pārbaude pirms piegādes lietotājam ir būtiska drošības sastāvdaļa. Tas pasargā saņēmējus no SPAM un sūtījumiem ar kaitīgu saturu. Zemāk tiek aplūkotas trīs metodes – DMARC, SPF un DKIM – efektīvai e-pasta sūtītāja pārbaudei.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Jāspēj korekti pārbaudīt ienākošā e-pasta autentiskumu, saskaņā ar tā domēna administratora norādīto DMARC politiku.
Kļūdu apstrāde
Ja pārbaužu laikā rodas kļūdas, kas norāda uz e-pasta viltošanu:
- Pie DMARC politikas ‘none’ – e-pastu var piegādāt gala lietotājam bez papildus marķējumiem.
- Pie DMARC politikas ‘quarantine’ – e-pastu var piegādāt ar lietotājam skaidru marķējumu, kas liecina par to, ka e-pasta autentiskumu nevar apstiprināt. Atkarībā no citu pārbaužu rezultātiem (piemēram, DNSBL, satura analīze) un organizācijas/uzņēmuma izvēlētās drošības politikas, šādus e-pastus var arī pavisam nepiegādāt gala lietotājam, vai arī piegādāt tos IT darbiniekiem, kas spēj veikt manuālu pārbaudi.
- Pie DMARC politikas ‘reject’ – e-pastu ir vēlams nepiegādāt gala lietotājam pavisam. Taču, ņemot vērā piegādes traucējumus, kurus var radīt nekorekta konfigurācija sūtītāju pusē, atkarībā no organizācijas/uzņēmuma prasībām, pragmatiskāks risinājums var būt e-pastu pieņemšana, bet ar skaidru, lietotājiem redzamu marķējumu, kas liecinātu par to, ka e-pasts tiek uzskatīts par neuzticamu. Pie šādas stratēģijas ir lietderīgi pieturēties tad, kad DMARC vēl atrodas ieviešanas stadijā, vai ir zināms, ka daļa partneru (ar kuriem notiek bieža e-pastu komunikācija) vēl tikai plāno DMARC ieviešanu, vai arī tad, kad ir noskaidrots eksperimentālā veidā, ka ievērojama ienākošo e-pastu daļa rada DMARC kļūdas dēļ nekorektas konfigurācijas sūtītāja pusē.
Atskaites par e-pastu piegādi un sastaptām kļūdām
Ja pārbaudes laikā rodas kļūdas un sūtītāja DMARC ieraksts norāda e-pasta adresi agregāt-atskaitēm (‘rua’) vai padziļinātas detalizācijas atskaitēm (‘ruf’), uz šīm adresēm ir jāsūta pieprasītā informācija par saņemto vēstuļu statistiku, vai arī par kļūdām, kas radušās piegādājot šī domēna vēstules.
SPF (Sender Policy Framework)
Visiem ienākošiem e-pastiem tiek pārbaudīti SPF ieraksti, ja tādi ir izveidoti. Jāņem vērā, ka SPF apstrāde atšķiras atkarībā no tā, vai domēnam ir definēts DMARC, vai nē. Līdz ar to, nav iespējams korekti pieņemt lēmumu par e-pasta autentiskumu, ja ienākošo e-pastu apstrādes sistēma spēj pārbaudīt tikai vienu SPF (vai pat abus SPF un DKIM, bet bez DMARC), – ir jāspēj validēt visi trīs mehānismi – SPF, DKIM un DMARC (kas iekļauj modificētas SPF un DKIM pārbaudes).
Ja SPF tiek izmantots, bet DMARC ieraksts domēnam nav izveidots, SPF pārbaužu laikā tiks izmantota sūtītāja adrese, kas ņemta no e-pasta aploksnes – ‘envelope sender’. Tehniski šai adresei nav jāsakrīt ar to, kuru tipiski redz gala saņēmējs – ‘originator’ (parasti ņemta no ‘From’ header’a). Taču labā prakse ir pārliecināties par to, ka šīs adreses sakrīt. Ja adreses nesakrīt:
- Ja e-pasts iziet DKIM pārbaudi – uzskatīt to par autentificētu (uzticamu).
- Ja ir kontrole pār mehānismu, kādā gala lietotāji pārskata e-pastus (pašu uzturētais webmail, Outlook ar Active Directory), attēlot tajā abas adreses – ‘originator’ (parasti ņemta no ‘From’ header’a) kā parasti, kā arī ‘envelope sender’, kas izmantota SPF pārbaudēs un kuras patiesums ir pārbaudīts caur SPF.
- Ja nav iespējams autentificēt e-pastu, izmantojot to adresi, kura tiks attēlota gala lietotājam (vai nav zināms, kādā veidā gala lietotājs pārbauda e-pastus, un jāpieņem, ka viņam tiek attēlota adrese tikai no ‘From’ header’a), – e-pasts jāuzskata par neuzticamu un jāmarķē lietotājam skaidrā un redzamā veidā.
DKIM (DomainKeys Identified Mail)
Ienākošiem e-pastiem jāvalidē DKIM header’u informācija, ja tāda ir pievienota.
Gadījumā, ja domēnam ir definēts DMARC ieraksts, DKIM ieraksts var tikt uzskatīts par valīdu tikai tad, ja ir izmantots domēna identifikators, kas sakrīt ar sūtītāja e-pasta domēnu. Gadījumā, ja DKIM tiek izmantots bez DMARC, standarti nenosaka šādu prasību, taču labā prakse ir tomēr ņemt vērā tikai tādus DKIM parakstus, kuros šis ‘alignment’ tiek ievērots.
Vēl par e-pastu drošību:
E-pastu drošība – šifrēšana
E-pastu drošība – lietotāju autentifikācija
E-pastu drošība – aizsardzība pret izejošo e-pastu viltošanu
Noderīgas saites:
“Dmarc – Defeating E-Mail Abuse”, CERT-EU
https://cert.europa.eu/static/WhitePapers/Updated-CERT-EU_Security_Whitepaper_DMARC_17-001_v1_2.pdf
“Using DMARC”, D. Crocker
https://tools.ietf.org/html/draft-crocker-dmarc-bcp-03
“Interoperability Issues Between DMARC and Indirect Email Flows”
https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-18.xml
“Breakng DKIM – on Purpose and by Chance”, Steffen Ullrich
https://noxxi.de/research/breaking-dkim-on-purpose-and-by-chance.html
“DomainKeys Identified Mail (DKIM) Verifiers may inappropriately convey message trust, cert.org
https://www.kb.cert.org/vuls/id/268267/
“Email authentication: SPF, DKIM and DMARC out in the wild”, JonLuca DeCaro
https://blog.jonlu.ca/posts/spf-dkim
“Guidelines on Electronic Mail Security”, NIST
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-45ver2.pdf
“Trustworthy Email”, NIST
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-177r1.pdf
“Email Authentication Best Practices”, CISCO
https://www.cisco.com/c/dam/en/us/products/collateral/security/esa-spf-dkim-dmarc.pdf
“M3AAWG Best Practices for Managing SPF Records”, Messaging, Malware and Mobile Anti-Abuse Working Group https://www.m3aawg.org/sites/default/files/m3aawg_managing-spf_records-2017-08.pdf
“M3AAWG Trust in Email Begins with Authentication”, Message, Mobile and Malware Anti-Abuse Working Group https://www.m3aawg.org/sites/default/files/document/M3AAWG_Email_Authentication_Update-2015.pdf
“Internet.nl Toolbox – hw-to’s mail security standards”, internet.nl
https://github.com/internetstandards/toolbox-wiki
“How to Combat Fake Emails”, Australian Cyber Security Centre
https://www.cyber.gov.au/publications/how-to-combat-fake-emails