E-pastu drošība - aizsardzība pret izejošo e-pastu viltošanu

Lai pasargātu citus saņēmējus un sava uzņēmuma vai organizācijas reputāciju, būtiski ir nodrošināt iespēju citiem pārliecināties par saņemtā e-pasta autentiskumu, ja tas izsūtīts jūsu uzņēmuma vai organizācijas vārdā, kā arī liegt iespēju trešajām pusēm izsūtīt šādus e-pastus. Arī šeit izmantojamas DMARK, SPF un DKIM tehnoloģijas.

DMARC

Katrā domēnā jābūt izveidotam DMARC ierakstam, jo šī tehnoloģija veic būtiskus uzlabojumus e-pastu standartos, kurus savādāk nav iespējams panākt dēļ atpakaļsaderības.

DMARC ierakstam jābūt sintaktiski korektam. T.sk. jāņem vērā, ka pirmais tegs vienmēr norāda DMARC versiju (dmarc-version), bet izvēlētai politikai (dmarc-request) vienmēr jābūt otrajā vietā (RFC 7489, 6.4. punkts).

Ieviešana

Ieviešana jāsāk ar SPF vai DKIM tehnoloģijām, jo DMARC pieprasa, ka katrs leģitīmi izsūtītais epasts ir aizsargāts vismaz ar vienu no tām.

Ir ieteicams izmantot DKIM + DMARC vai SPF + DKIM + DMARC kombināciju, jo SPF + DMARC (bez DKIM) var sagādāt piegādes traucējumus vairākos scenārijos (visbiežākie - epastu pārsūtīšana un meilinglistes).

Lai gan DKIM + DMARC konfigurācija no drošības perspektīvas ir tikpat droša kā SPF + DKIM + DMARC (un dažreiz pat drošāka dēļ tā, ka SPF ierakstos nākas iekļaut mazāk uzticamus serverus), praksē bieži vien nav iespējams izvairīties no SPF. Tā kā SPF ir vecāka tehnoloģija, kas arī ir daudz vienkāršāk ieviešama salīdzinājumā ar DKIM (sūtītāja pusē pietiek ar DNS ieraksta izveidošanu), tad tā šobrīd ir arī daudz biežāk izplatīta nekā DKIM vai DMARC. Līdz ar to, aizsargājot savus izejošos e-pastus tikai ar DKIM un DMARC, pastāv risks, ka daļa saņēmēju nespēs tos korekti validēt un tādēļ faktiski viņiem sūtītie e-pasti vispār netiks pasargāti no viltošanas.

Ja ir tehniskās iespējas apstrādāt DMARC atskaites (aggregate and forensic reports), vēlams sākt DMARC ieviešanu ar politiku 'p=none', lai iespējamās neapzinātās kļūdas neietekmē e-pastu piegādi. Pieprasītas piegādes atskaites  tiek apkopotas ar mērķi identificēt trūkumus tekošajā SPF, DKIM vai DMARC konfigurācijā. Tās ieviešot, jāņem vērā:

• Pēc noklusējuma “aggregate” (“rua”) atskaites tiek izsūtītas tikai par e-pastiem, kas vienlaicīgi neizturēja abas pārbaudes – SPF un DKIM.
• Ja tiek ieviestas abas šīs tehnoloģijas, tad noderīgāk ir saņemt informāciju par e-pastiem, kas nav izgājuši jebkuru no šīm pārbaudēm, to var panākt ar ‘fo=1’ tegu.
• E-pasta adreses jānorāda ar ‘mailto:’ prefiksu.
• Pēc noklusējuma atskaites atļauts sūtīt tikai uz šī paša domēna adresēm, ja ir nepieciešams tās izsūtīt uz cita domēna e-pastu, tam domēnam ir jāapstiprina šī darbība, ieviešot “External Domain Verification” DNS ierakstus. Piemēram TXT ieraksts “viens.lv._report._dmarc.divi.lv” ar saturu “v=DMARC1;” norāda, ka ‘divi.lv’ ir ar mieru saņemt ‘viens.lv’ domēna DMARC atskaites

p=none

'p=none' DMARC ierakstos norāda, ka e-pastam jātiek piegādātam neatkarīgi no SPF un DKIM pārbaužu rezultātiem.

'p=none' konfigurācija bez 'rua' tega, visticamāk, ir kļūda, jo domēns, kuram izveidots šāds ieraksts, nav pasargāts no e-pastu viltošanas, kā arī e-pasta administratori nesaņem informāciju par tekošās konfigurācijas trūkumiem.

Turklāt, ja domēnam ir izveidots SPF ar striktu politiku ('-ALL'), bet DMARC ierakstā ir norādīts 'p=none', e-pasti tiks apstrādāti dažādi, atkarībā no saņēmēja:

• ja saņēmēja serveris spēj pārbaudīt SPF, bet ne DMARC vai arī izmanto SPF pārbaužu rezultātus e-pastu filtrēšanai arī pie DMARC politikas ‘p=none’: SPF tiks pārbaudīts un kļūdu gadījumā e-pasts netiks piegādāts (kas var notikt arī ar leģitīmiem e-pastiem dēļ pāradresācijas vai meilinglistēm)
• ja saņēmēja serveris spēj pārbaudīt DMARC un pieņem lēmumus tikai balstoties uz to: e-pasts tiks piegādāts neatkarīgi no SPF validācijas rezultātiem (bet SPF kļūdu gadījumā par tām tiks ziņots, ja DMARC politikā ir ieslēgta atskaišu funkcionalitāte)

Šādi var veidoties grūti diagnosticējamas problēmas, kā arī tas var radīt viltus drošības sajūtu.

Jāņem vērā

Izmantojot SPF + DKIM + DMARC konfigurāciju, tik un tā jārēķinās ar to, ka daļa sūtītāju būs spējīgi validēt tikai SPF. Tas rada divas problēmas, kas jāņem vērā:

1. Saņēmēji, kas neatbalsta DMARC, validēs SPF pēc tā oriģinālās specifikācijas, neizmantojot DMARC ieviesto papildus prasību par Envelope Sender' un Originator (parasti 'From' header'is) alignment. Tas nozīmē, ka šādi saņēmēji de-facto nav pasargāti no e-pastu viltošanas (bet sūtītājs šajā gadījumā arī nevar neko iesākt lietas labā).
2. Ja visi uzņēmuma e-pasti tiek korekti pasargāti ar DKIM, tad daļa no tiem varētu arī noteiktos apstākļos nākt no serveriem, kas nav iekļauti SPF ierakstā. Tas var notikt kļūdas pēc vai arī uzsākot e-pastu izsūtīšanu no jaunas vietas (kas ir pasargāta ar DKIM, bet serveri netika ievietoti SPF ierakstā). Šajā gadījumā saņēmēji, kas spēj validēt DMARC, turpinās saņemt visus e-pastus, bet tie saņēmēji, kas spēj validēt tikai pliku SPF, daļu e-pastu var nesaņemt. Šādi piegādes traucējumi var nebūt pamanīti uzreiz un tad, kad tas ir pamanīts, to cēloni var būt visai grūti izskaidrot.

(Vēlams) DKIM

DKIM noteikti jālieto kopā ar DMARC. Bez tā sūtītājam nav iespējams signalizēt saņēmējam, ka visiem tā e-pastiem jābūt korekti parakstītiem ar DKIM. Līdz ar to krāpnieki var vienkārši viltot e-pastus, nepievienojot DKIM pavisam, - saņēmējam šajā gadījumās nāksies pieņemt e-pastus, jo DKIM trūkums (bez DMARC) netiks uzskatīts par problēmu.

Būtiska DKIM priekšrocība, salīdzinājumā ar SPF: DKIM parakstīti e-pasti paliek valīdi arī tad, ja tie tiek pārsūtīti, pie nosacījuma, ka to saturs netiek mainīts. Tas ir svarīgi, lai e-pasti tiktu piegādāti arī tad, ja saņēmējiem ir izveidotas dažāda veida pāradresācijas, vai arī, ja epasti tiek sūtīti uz meilinglistēm (par tām vairāk sk. zemāk).

Gadījumā, ja e-pasti tiek sūtīti no vairākiem avotiem (caur e-pastu serveri, web-serveri(em), mārketinga servisiem, sadarbības partneriem, automatizētām sistēmām), tiem visiem jābūt pasargātiem ar DKIM. To var panākt, vai nu pārkonfigurējot visus izejošo e-pastu punktus tādā veidā, lai e-pasti tiktu nosūtīti caur vienotu releju (kas pievienot epastiem DKIM parakstus), vai arī pievienojot DKIM parakstus katrā no vietām, caur kurām epasti tiek izsūtīti. Otrajā gadījumā vēlams katrā no vietām izmantot atsevišķu DKIM atslēgu, ar atsevišķu DKIM selektoru, lai nepieciešamības gadījumā katru no tiem varēu atsaukt individuāli.

Tā kā DKIM neierobežo atslēgu skaitu, kas tiek lietotas vienā domēnā, tad tehniski ir iespējams lietot individuālu atslēgu katram servisam, vai katram lietotājam. Taču praksē liels atslēgu skaits būtiski sarežģī atslēgu pārvaldi, ja vien tā nav automatizēta, kas palielina risku izveidot kļūdainu konfigurāciju, iespaidojot epastu piegādi.

Oversigning

DKIM ļauj norādīt, kuri e-pasta header'i tiek iekļauti, veidojot parakstu. Turklāt individuālu header'i var norādīt vairākas reizes. Tad, ja header'is patiesībā e-pastā sastopams tikai vienu reizi, izskaitļojot DKIM parakstu, otro reizi tas tiks aizstāts ar tukšumu.

Šis ir būtiski, jo DKIM skaita header'us virzienā no apakšas uz augšu. Savukārt daudzos citos kontekstos e-pastu serveri un e-pastu klienti apskata header'us virzienā no augšas uz apakšu. Turklāt, lai gan dažiem no header'iem pēc standartiem ir jābūt sastopamiem tikai vienu reizi, praksē vairums e-pastu serveru pieņem arī nekorektus e-pastus, kuros šie header'i ir sastopami vairākas reizes, pie tam bieži vien uzskatot par korektu to, kas sastopams pirmais.

Šie fakti kopumā ļauj uzbrucējiem veikt ierobežotu e-pastu viltošanu sekojošā veidā. Par pamatu tiek paņemts kāds reāli izsūtīts e-pasts ar valīdu DKIM header'i. Taču tas tiek modificēts, pievienojot papildus header'us, kas vai nu oriģinālajā e-pastā vispār nebija sastopami, vai arī bija sastopami un bija iekļauti DKIM parakstā tik pat reizes, cik reizes tie bija sastopami (vai mazāk).

Lai izvairītos no šīs situācijas, ieteicams iekļaut DKIM parakstāmo header'u sarakstā visus svarīgos header'us, pie tam minot tos par vienu reizi vairāk, nekā tie patiesībā sastopami izsūtāmajā e-pastā. Šajā gadījumā, pievienojot e-pastam papildus header'i, DKIM paraksts nesakritīs un e-pasts tiks atpazīts kā viltojums.

Meilinglistes un garuma tegs ('l=')

DKIM piedāvā iespēju ierobežot teksta garumu, kas tiek izmantots, skaitļojot DKIM kriptogrāfisko parakstu. Visbiežāk tas ir noderīgi meilinglistēm, kas pārsūta e-pastus, pievienojot tiem papildus parakstu ar administratīvu informāciju. Tā kā ar DKIM bija parakstīts viss e-pasts, bet šajā gadījumā tika modificēts e-pasta teksts, šis paraksts pēc meilinglistes ieviestās modifikācijas kļūs nederīgs.

Norādot DKIM parakstā teksta garumu, kurš tika parakstīts, meilinglistes var pievienot tam galā papildus tekstu, nebojājot DKIM parakstu.

Diemžēl, šo funkciju ir iespējams izmantot arī ļaundabīgai e-pastu viltošanai. Pirmāmkārtām, ļaundari var vienkārši pievienot tekstu kāda e-pasta galā. Otrāmkārtām, savienojot šo ievainojamību ar iepriekš aprakstīto header'u viltošanu (ja netiek pielietos Oversigning), ir iespējams pilnībā pārrakstīt saņēmējam attēloto tekstu (pievienojot jaunu MIME daļu), vai pievienot e-pastam jaunu pielikumu.

Lai pasargātos no šādas e-pastu viltošanas, vēlams izvairīties no 'l=' tega izmantošanas, lai tiktu parakstīts viss e-pasta saturs, un, krāpniekiem pievienojot jebkuru tekstu e-pasta galā, lai tiktu invalidēts DKIM paraksts, kas liecinātu par e-pasta viltošanu. Taču, ja ir zināms, ka domēna lietotāji izmanto meilinglistes, kuras modificē sūtītos e-pastus, var gadīties, ka no ‘l=’ tega nav iespējams izvairīties. Šajos gadījumos risku var daļēji mazināt, izmantojot iepriekš minēto ‘oversigning’ stratēģiju.

(Vēlams) SPF

SPF ieviešana jāsāk ar visu izejošo e-pastu avotu apzināšanu.

Var sākt ar ~ALL, bet pilnam efektam jāpāriet uz -ALL.

SPF ierakstiem jābūt sintaktiski korektiem. Biežāk pieļaujamās kļūdas, no kurām jāuzmanās:

• Vairāki SPF ieraksti vienam domēnam (drīkst būt tikai viens).
• Pārbaudot SPF ierakstu, tiek pārsniegts DNS pieprasījumu limits (10 pieprasījumi). Jāņem vērā, ka DNS limits attiecas uz pilnu SPF pārbaudi, ieskaitot apakšierakstus, kas tiek iekļauti, izmantojot 'include' tegus. Turklāt 'mx' tega izmantošana izraisa vismaz divus DNS pieprasījumus (viens atgriež MX servera DNS ierakstu, otrs noskaidro šī DNS ierakstam atbilstošo IP adresi), bet gadījumā, ja 'mx' DNS pieprasījumā tiek atgriezti vairāki MX serveri, DNS pieprasījumu skaits var būt daudz lielāks.
• SPF ieraksts ir pārāk garš. Tipiski, SPF ierakstam jābūt zem 255 rakstu zīmēm. Ja ir nepieciešams garāks SPF ieraksts, to var panākt ar vairākiem TXT tipa ierakstiem, taču jāuzmanās, jo SPF validācijas laikā tie tiks apvienoti vienā ierakstā un šādā formā tiem ir jāveido korekts SPF ieraksts (teiksim, tikai pirmajam TXT ierakstam jāsākas ar 'v=spf1 '). Parasti drošāks risinājums ir izmantot apakšierakstus, lietojot 'include' mehānismu.
• SPF ierakstā minēti neeksistējoši DNS ieraksti. Šīs var būt novecojušas un vairs neizmantotas sistēmas, vai arī tā var būt parasta neuzmanības kļūda. SPF validācijas laikā, sastopot šādu DNS ierakstu, kas nevar tikt pārveidots par IP adresi, rodas kļūda.
• SPF ierakstā ir izmantots 'mx' tegs, kaut gan patiesībā ar epastu izsūtīšanu nodarbojas serveri, kas ir atšķirīgi no ienākošajiem. SPF ierakstā jānorāda tikai serverus, caur kuriem epasti tiek piegādāti uz internetu, bieži vien ienākošie serveri (uz kuriem norāda 'mx' DNS ieraksts) nesakrīt ar izejošajiem, tādēļ 'mx' tega izmantošana šajos gadījumos ir kļūdaina.
• SPF ierakstā ir pieminētas daudzas sistēmas, kas patiesībā netiek izmantotas e-pastu izsūtīšanai. Bieži sastopami SPF ieraksti, kuros izmantoti 'a' un 'mx' mehānismi, minētas daudzas IP adreses un subneti, kaut gan patiesībā visi izejošie e-pasti no organizācijas tiek sūtīti caur vienu vai diviem e-pastu serveriem. SPF ierakstā nav jānorāda visas sistēmas, kas potenciāli var sūtīt e-pastus, bet gan tikai patiesie izejošie e-pasta serveri, caur kuriem organizācijas e-pasti tiek piegādāti uz internetu. E-pastu administratora uzdevums, veidojot SPF ierakstu, ir noskaidrot visus avotus, kas patiesībā nodarbojas ar e-pastu piegādi uz internetu, taču jāizvairās no lieku sistēmu pieminēšanas, jo tas palielina uzbrukuma virsmu.

Domēni, kuri netiek izmantoti e-pastu izsūtīšanai

Jāaizsargā arī organizācijas pārvaldībā esošie domēni, kas netiek izmantoti e-pastu sūtīšanai. Ja tas netiek darīts, e-pastu viltošana ir iespējama un jebkurš no šiem domēniem var tikt izmantots ticamu pikšķerēšanas uzbrukumu veikšanai.

Šajā gadījumā pietiek ar minimālu konfigurāciju, kas liedz sūtīt epastus no jebkuras IP adreses.

Ieteicamā konfigurācija ir sekojoša:

• DMARC: 'v=DMARC1; p=reject'
• SPF: 'v=spf1 -all'

Jāņem vērā, ka ar vienu DMARC ierakstu nepietiek, jo ir risks, ka daži no e-pastu saņēmējiem nespēj to korekti verificēt. Tā kā SPF atbalsts šobrīd ir sastopams biežāk, tad vēlams veidot abus ierakstus.

Ieviešanas soļi izejošo e-pastu aizsardzībai

1. DMARC politika “v=DMARC1;  p=none; rua=mailto:ADRESE@ATSKAITEM.LV”
   (neietekmē e-pastu piegādi, bet ļauj novērtēt aizsardzības mehānismu efektivitāti vai arī pamanīt kļūdas to konfigurācijā; ierakstu var papildināt ar ‘fo=1’, lai saņemtu arī informāciju par e-pastiem, kas izkrituši tikai vienu no SPF vai DKIM pārbaudēm, nevis tikai abas kopā).
2. Saņemto DMARC piegādes atskaišu analīze
   (to IP adrešu uzskaite, no kurām patiesībā tiek izsūtīti e-pasti; automatizēto sistēmu inventarizācija).
3. Testēšanas režīmi DKIM (‘t=y’) un SPF (‘~ALL’) mehānismiem
   (iespēja pamanīt un novērst kļūdas, pirms tās izraisa piegādes traucējumus).
4. Pārliecināties, ka DMARC alignment prasības tiek izpildītas
   (SPF gadījumā Envelope Sender jāsakrīt ar From lauku, DMARC gadījumā ‘d=’ tegā norādītais domēns sakrīt ar From lauka domēnu).
5. Saņemto DMARC atskaišu analīze (t.sk. ‘ruf=’, ja tas ir iespējams) & cita veida piegādes kļūdu monitorings
   (jārēķinās, ka daži saņēmēji var sākt filtrēt e-pastus jau šajā solī, pie tam neveicot DMARC atskaišu izsūtīšanu).
6. Stingru režīmu ieviešana SPF (‘-ALL’) un DKIM (‘p=quarantine’ vai ‘p=reject’)
   (ja iepriekšējos soļos tas vēl nebija izdarīts, šeit noteikti ieteicams ieslēgt arī DMARC atskaišu funkcionalitāti, kā arī ieviest saņemtās informācijas apstrādi).

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 ienākoš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

Attēls: pixabay.com