Visi ieraksti kategorijā "netsec"

15. augusts, 2020

CERT.LV brīdina par ļaunprogrammatūras Emotet izplatīšanas kampaņām

ā informē CERT.LV, Emotet, nokļūstot upura iekārtā, ievāc sensitīvu informāciju no upura iekārtas; izsūta sevi visam e-pasta kontaktu sarakstam; cenšās izplatīties tīklā, izmantojot paroļu sarakstus vai paroļu pārlasi, lai piekļūtu tīklā pieslēgtām sistēmām/iekārtām; lejuplādē papildus ļaunprogrammatūru, piemēram, TrickBot.

Ar Emotet inficēta sūtījuma pazīmes:

  • visbiežāk e-pasts tiek saņemts no kāda zināma sūtītāja, kurš, iespējams, neuzmanības vai nezināšanas pēc ir atvēris līdzīgu sūtījumu un inficējis savu iekārtu;
  • e-pasts var saturēt atpazīstamus e-pastu fragmentus no pārņemtā konta, lai izskatītos pēc uzsāktas sarakstes turpinājuma;
  • kaitīgais e-pasts pielikumā satur dokumentu (paplašinājums .DOC) ar makro funkcionalitāti.

CERT.LV iesaka sekojošus papildus aizsardzības pasākumus:

  • pārliecināties, ka operētājsistēma, Microsoft Office un e-pasta klients ir atjaunināti;
  • pārliecināties, ka makro funkcionalitāte dokumentos netiek iespējota automātiski
  • saņemtajos e-pastos pārbaudīt sūtītāju, ja sūtītāja adrese nesakrīt ar to, par ko uzdodas, tad tā ir droša kaitīga e-pasta pazīme (bet, ja tomēr sakrīt, vēl nenozīmē, ka e-pasts netiek sūtīts no uzlauzta konta; ja māc šaubas par e-pasta autentiskumu, aicinām sazināties ar sūtītāju citā veidā, piemēram, telefoniski).

Ja šāds e-pasts ir saņemts un dokuments ir ticis atvērts, kiberdrošības eksperti nekavējoties sazināties ar savu sistēmadministratoru.

6. augusts, 2020

CERT.LV brīdina par mēģinājumiem izkrāpt Facebook piekļuves informāciju

CERT.LV brīdina par to, ka tiek veikti mēģinājumi izkrāpt Facebook piekļuves informāciju no Facebook lapu īpašniekiem. Tiek izsūtīti viltoti paziņojumi par kontu bloķēšanu ar saitēm uz viltus lapām, kas tikai vizuāli ir līdzīgas Facebook. Ievadot savus datus šajās vietnēs, dati tiek nodoti krāpniekiem.

22. maijs, 2020

CERT ieteikumi aizsardzībai pret ienākošo e-pastu viltošanu

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

22. maijs, 2020

CERT ieteikumi aizsardzībai 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:[email protected]
    (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

21. maijs, 2020

DNS ugunsmūris piedzīvo virkni uzlabojumu

CERT.LV un NIC (.LV domēna vārdu reģistra uzturētājs) kopprojekts “DNS ugunsmūris” ir piedzīvojis virkni uzlabojumu, kas padara to lietotājiem saprotamāku un draudzīgāku.

Ir papildinātas ugunsmūra uzstādīšanas instrukcijas, kā arī ugunsmūris ir ieguvis jaunu vizuālo identitāti ar savu simbolu un sargu “Ugunīgo kaķi Muri”.

Ugunsmūra sargam Murim par savu tapšanu jāpateicas diakritisko zīmju (mīkstinājumi un garumzīmes) trūkumam domēnvārdos, piemēram, “dnsmuris” un “ugunsmuris“, kā arī kolēģu vēlmei piešķirt šim sargam identitāti un “seju”. (Jāpiezīmē, gan, ka, lai arī neierasti, bet mūsdienās ir iespējams veidot domēnvārdus arī ar mīkstinājumiem un garajiem burtiem!) Muris ar savu uzvedību uz sienas signalizē, vai DNS ugunsmūra pakalpojums ir pieslēgts un aktīvs (kaķis pārliecināti un droši sēž uz mūra un vēro apkārtni) vai nav aktīvs (kaķis satraukti skrāpē sienu).

Atgādinām, ka DNS ugunsmūris ir bezmaksas rīks individuālu lietotāju un organizāciju pasargāšanai no kiberapdraudējumiem, tādiem kā viltus banku lapas, krāpnieciskas tirdzniecības platformas, vīrusus izplatošas vietnes u.c.

Lasīt tālāk