Mengungkapkan Catatan DMARC

Diterbitkan: 2021-08-18

Standar DMARC (Domain-based Message Authentication, Reporting & Conformance) adalah alat terbaik yang dimiliki merek untuk memerangi serangan phishing yang menargetkan pelanggan dengan memalsukan domain milik mereka. Tetapi menerapkan DMARC bisa membingungkan dengan sangat cepat.

Dalam posting ini, kami akan mengungkap data DMARC dengan mendefinisikan tag DMARC yang menyusunnya. Kami akan membahas tag wajib dan opsional, serta membahas beberapa strategi dan kasus penggunaan di mana tag DMARC yang kurang dikenal dapat memberikan tingkat keamanan email yang lebih tinggi bagi organisasi Anda.

Apa itu tag DMARC?
Tag DMARC adalah bahasa standar DMARC. Mereka memberi tahu penerima email untuk (1) memeriksa DMARC dan (2) apa yang harus dilakukan dengan pesan yang gagal autentikasi DMARC.

Tag DMARC yang diperlukan
Hanya ada dua tag DMARC yang diperlukan: “v:” dan “p:”

v: Versi . Tag ini digunakan untuk mengidentifikasi data TXT sebagai data DMARC, sehingga penerima email dapat membedakannya dari data TXT lainnya. Tag v: harus memiliki nilai “DMARC1” dan harus dicantumkan sebagai tag pertama dalam seluruh data DMARC. Jika nilainya tidak sama persis dengan “DMARC1” atau tag v: tidak dicantumkan terlebih dahulu, seluruh data DMARC akan diabaikan oleh penerima.

Contoh: v=DMARC1

p: Kebijakan Penerima Surat yang Diminta. Tag ini menunjukkan kebijakan yang akan diberlakukan oleh penerima untuk pesan yang gagal dalam pemeriksaan autentikasi dan penyelarasan DMARC, seperti yang ditentukan oleh pemilik domain. Kebijakan ini akan berlaku untuk domain yang dikueri dan semua subdomain kecuali jika kebijakan subdomain terpisah dijelaskan secara eksplisit (kami akan membahasnya nanti di postingan). Ada tiga kemungkinan nilai untuk p: tag

  1. p=none: Pemilik domain tidak meminta tindakan khusus untuk dilakukan pada email yang gagal dalam autentikasi dan penyelarasan DMARC.
  2. p=karantina: Pemilik domain berharap agar email yang gagal dalam pemeriksaan autentikasi dan penyelarasan DMARC dianggap mencurigakan oleh penerima email. Ini bisa berarti penerima menempatkan email di folder spam/sampah, menandainya sebagai mencurigakan atau meneliti email ini dengan intensitas ekstra.
  3. p=reject: Pemilik domain meminta agar penerima email menolak email yang gagal dalam pemeriksaan autentikasi dan penyelarasan DMARC. Penolakan harus terjadi selama transaksi SMTP. Ini adalah kebijakan yang paling ketat dan menawarkan tingkat perlindungan tertinggi.

Berdasarkan informasi di atas, contoh data DMARC yang paling dasar dapat berupa: v=DMARC1; p=tidak ada.

Tag DMARC opsional
 Tag DMARC opsional di bawah ini memungkinkan pengirim email memberikan instruksi yang lebih spesifik tentang apa yang harus dilakukan dengan email yang tidak diautentikasi, menghilangkan dugaan penerima.

  • rua: Menunjukkan ke mana laporan DMARC agregat harus dikirim. Pengirim menunjuk alamat tujuan dalam format berikut: rua=mailto:[email protected]
  • ruf: Menunjukkan ke mana laporan DMARC forensik harus dikirim. Pengirim menetapkan alamat tujuan dalam format berikut: ruf=mailto:[email protected]

Tag opsional berikut memiliki nilai default yang akan diasumsikan jika tag dikecualikan. Daftar tag dengan nilai default yang diasumsikan adalah:

  • adkim: Menunjukkan penyelarasan pengenal DKIM yang ketat atau santai. Defaultnya santai.
  • aspf: Menunjukkan penyelarasan pengenal SPF yang ketat atau santai. Defaultnya santai.
  • rf: Format untuk laporan kegagalan pesan. Standarnya adalah Format Pelaporan Kegagalan Otentikasi, atau “AFRF.”
  • ri: Jumlah detik yang berlalu antara pengiriman laporan agregat ke pengirim. Nilai defaultnya adalah 86.400 detik atau sehari.
  • persen: Persentase pesan yang akan diterapkan kebijakan DMARC. Parameter ini menyediakan cara untuk menerapkan dan menguji dampak kebijakan secara bertahap.
  • fo : Menentukan jenis otentikasi dan/atau kerentanan penyelarasan apa yang dilaporkan kembali ke Pemilik Domain.
  • Ada empat nilai untuk yang terakhir untuk: tag:
  • 0: Buat laporan kegagalan DMARC jika semua mekanisme autentikasi yang mendasari gagal menghasilkan hasil "lulus" yang selaras. (Bawaan)
  • 1: Buat laporan kegagalan DMARC jika ada mekanisme autentikasi yang mendasari menghasilkan sesuatu selain hasil "lulus" yang selaras.
  • d: Buat laporan kegagalan DKIM jika pesan memiliki tanda tangan yang gagal dievaluasi, terlepas dari keselarasannya.
  • s: Buat laporan kegagalan SPF jika pesan gagal evaluasi SPF, terlepas dari keselarasannya.

Sementara defaultnya adalah “fo=0,” Return Path menyarankan klien untuk menggunakan fo:1 untuk menghasilkan laporan kegagalan paling komprehensif, memberikan visibilitas yang jauh lebih terperinci ke saluran email.

Di bawah ini adalah contoh data DMARC. Berdasarkan apa yang telah Anda pelajari sejauh ini, coba uraikan setiap tag:

v=DMARC1; p=tolak; untuk=1; rua=mailto:[email dilindungi]; ruf=mailto:[email dilindungi]; rf=afr; persen = 100

Bagaimana dengan sub-domain?
Tag DMARC terakhir yang akan kita bahas hari ini adalah tag sp:, yang digunakan untuk menunjukkan kebijakan yang diminta untuk semua subdomain yang emailnya gagal dalam pemeriksaan autentikasi dan penyelarasan DMARC. Tag ini hanya berlaku untuk domain level teratas (domain level organisasi). Ini paling efektif ketika Pemilik Domain ingin menentukan kebijakan yang berbeda untuk domain tingkat atas dan semua subdomain.

Untuk skenario berikut, kami akan menggunakan domain tingkat atas "domain.com" dan sub-domain "mail.domain.com" untuk menggambarkan kasus penggunaan.

  1. Pemilik Domain ingin menerapkan kebijakan penolakan untuk "domain.com", tetapi kebijakan karantina untuk "mail.domain.com" (dan semua subdomain lainnya). Data DMARC untuk “domain.com” kemudian akan menyertakan “v=DMARC1; p=tolak; sp = karantina.” Ini adalah strategi yang efektif jika organisasi perlu mempertahankan kebijakan DMARC terpisah untuk domain tingkat atas dan semua subdomain.
  2. Pemilik Domain ingin menerapkan kebijakan penolakan untuk "mail.domain.com" (dan semua subdomain lainnya) tetapi tidak menerapkan kebijakan penolakan untuk "domain.com." Data DMARC untuk “domain.com” kemudian akan menyertakan “v=DMARC1; p=tidak ada; sp = tolak.” Ini akan menjadi strategi yang efektif untuk memerangi serangan kamus jika domain tingkat atas tidak siap untuk menerapkan kebijakan, tetapi penipu memalsukan subdomain seperti mail.domain.com, abc.domain.com, 123.domain. com, xyz.domain.com, dll. Menyetel tag sp: untuk menolak akan melindungi organisasi dari serangan kamus yang menargetkan subdomain tanpa memengaruhi email apa pun yang dikirim dari domain tingkat atas, “domain.com”

Sekarang setelah Anda memahami DNA dari data DMARC, pelajari lebih lanjut tentang jenis serangan yang diblokirnya dan jenis serangan yang tidak di The Email Threat Intelligence Report .