Perlakukan kontrol DNS sebagai bagian dari kepercayaan email
Pembajakan DNS adalah perubahan tidak sah terhadap informasi atau jalur resolusi yang dipercaya klien. Untuk tim email, pertanyaan penting bukan hanya apakah situs web suatu domain dipindahkan. Tentukan otoritas, akun, atau penyelesai mana yang terpengaruh, nama terkait email mana yang diubah, dan apa yang dapat diamati oleh penerima selama interval yang terpengaruh. Jawaban yang tepat sekarang tidak menetapkan bahwa keputusan pengiriman sebelumnya menggunakan data yang sama.
Pisahkan pengambilalihan otoritatif dari peracunan cache dan pengalihan penyelesai lokal. Mereka dapat menghasilkan gejala yang serupa tetapi memerlukan pemulihan yang berbeda pada pemiliknya. Akun registrar dapat memengaruhi delegasi; akun hosting resmi dapat mengubah konten zona; titik akhir yang dikompromikan dapat menggunakan penyelesai yang tidak terduga. NIST Panduan penerapan DNS membedakan ancaman terhadap layanan otoritatif, rekursif, dan stub. Perbedaan tersebut adalah titik awal untuk peta kejadian yang berguna.
Identifikasi batas kepercayaan yang dipindahkan
Bandingkan dasar pendaftaran dan delegasi yang diketahui dengan layanan resmi saat ini. Catat siapa yang mengelola registrar, hosting DNS , infrastruktur penandatanganan, dan kontak pemulihan. Periksa apakah suatu perubahan telah diotorisasi sebelum menyebutnya berbahaya: migrasi terencana, subdomain yang didelegasikan, dan tampilan terpisah dapat menghasilkan perbedaan yang sah. Pertahankan ketidakpastian ketika catatan atau log akun tidak tersedia.
Hierarki otoritatif penting karena ekspor zona yang tampak dapat dipercaya dari penyedia sebelumnya mungkin tidak lagi menggambarkan delegasi publik. RFC 1034 bagian 4.2 menjelaskan batas-batas zona dan delegasinya. Bukti insiden harus mengidentifikasi server dan jalur yang digunakan untuk setiap observasi, bukan hanya mereproduksi teks jawaban. Tangkapan layar tanpa nama, jenis rekaman, dan stempel waktu yang ditanyakan adalah bukti lemah mengenai apa yang berubah.
Gunakan prosedur insiden yang telah ditetapkan untuk melindungi akun yang terkena dampak, menyimpan log yang relevan, dan mengoordinasikan pemulihan. Tindakan tersebut memerlukan izin organisasi; artikel ini tidak mengarahkan perubahan pada layanan langsung. Hindari menghancurkan bukti yang berguna dengan menghapus akun, mengganti setiap catatan, atau membersihkan setiap cache sebelum pemilik insiden mengetahui status yang terpengaruh.
Telusuri konsekuensi yang berbeda untuk email masuk dan keluar
Perubahan MX yang tidak sah dapat mengalihkan upaya pengiriman email masuk. Apakah pengirim tertentu benar-benar mengirimkannya bergantung pada rute yang dipilih, perlindungan transportasi, dan sambungan yang dihasilkan. Jangan menyimpulkan bahwa isi kotak surat dibaca hanya dari perbedaan MX . Tetapkan interval yang terkena dampak dan periksa bukti pengiriman sebelum membuat klaim paparan.
Pemeriksaan identitas keluar memiliki ketergantungan yang berbeda. SPF mengevaluasi apakah alamat penghubung diotorisasi untuk domain yang dievaluasi, menggunakan kebijakan DNS di bawah RFC 7208. Jika musuh mengendalikan kebijakan tersebut, izin SPF mungkin mencerminkan kebijakan yang tidak sah dan bukan otorisasi bisnis yang sah. Mengganti a DKIM kunci publik dapat mempengaruhi verifikasi, namun penerbitan kunci tidak mengubah tanda tangan pesan lama atau mengungkapkan kunci pribadi sebelumnya. Proses pencarian dan verifikasi kunci dijelaskan di RFC 6376 bagian 3.6 dan 6.1.2.
DMARC bergantung pada pengidentifikasi terotentikasi yang selaras dengan Domain Penulis. Ini bukan daftar independen atas karyawan atau vendor yang disetujui. Materi autentikasi domain yang dibajak dapat melemahkan asumsi di balik hasil penerusan. Kebijakan domain juga menginformasikan penanganan penerima dibandingkan menjamin hasil universal, seperti yang dijelaskan dalam RFC 9989 bagian 4.4 dan 5.4.
Pahami perlindungan mana yang mengatasi risiko tertentu
DNSSEC memberikan autentikasi asal dan integritas untuk data DNS ketika validasi memiliki rantai kepercayaan yang dapat digunakan. Ini tidak menyatakan bahwa perubahan yang dilakukan melalui sistem penandatanganan resmi mencerminkan niat pemilik. Pengeditan berbahaya yang diterima dan ditandatangani oleh jalur administrasi otoritatif yang disusupi mungkin masih dapat divalidasi. RFC 4033 bagian 3 menetapkan layanan yang disediakan DNSSEC ; kontrol perlindungan dan persetujuan akun menangani lapisan yang berbeda.
Kebijakan transportasi juga perlu analisa tersendiri. Yang sudah ada MTA-STS kebijakan dapat membatasi host MX dan validasi TLS yang diizinkan untuk mengimplementasikan pengirim, namun penemuan awal dan cache kebijakan memiliki batasan. DANE SMTP bergantung pada informasi yang diautentikasi DNSSEC dan sesuai TLSA catatan. Kedua mekanisme tersebut tidak dapat digambarkan sebagai obat universal terhadap pengambilalihan domain administratif. Berkonsultasi RFC 8461 bagian 10 Dan RFC 7672 bagian 2 untuk model kepercayaan mereka yang berbeda.
Contoh fiksi dari perubahan MX yang disengketakan
Di organisasi fiksi Contoh Lokakarya, peringatan melaporkan bahwa example.com sekarang memiliki target MX yang berbeda. Panel DNS lama administrator email masih menampilkan nilai yang diharapkan. Investigasi yang diusulkan akan membandingkan delegasi, jawaban resmi saat ini, dan catatan perubahan pendaftar sebelum memutuskan apakah panel tersebut tidak lagi berwenang.
Misalkan rekaman insiden kemudian menghasilkan perubahan delegasi yang tidak sah. Pemilik respons akan mengoordinasikan pemulihan otoritas yang disetujui dan menilai jangka waktu berdasarkan catatan pengirim dan bukti kebijakan transportasi. Otentikasi meneruskan pesan keluar yang tidak terkait tidak akan menutup pertanyaan paparan masuk. Skenario ini diciptakan dan tidak mengandung insiden yang diamati, akses akun penyedia, atau pemulihan yang diuji.
Definisikan pemulihan selain memulihkan satu jawaban
Pertahankan perbedaan rekaman yang disetujui, peta ketergantungan, dan pulihkan materi, lalu verifikasi jalur otoritatif yang dipulihkan dan tampilan rekursif yang dipilih. Tinjau kunci, kredensial, atau titik akhir kebijakan apa pun yang terlibat dalam penyusupan sebenarnya tanpa berasumsi bahwa setiap rahasia telah terungkap. Tetapkan kepemilikan untuk memantau kekambuhan dan pertanyaan paparan yang belum terselesaikan.
Menutup insiden hanya berdasarkan kriteria yang jelas: administrasi dikendalikan, catatan yang diharapkan dilayani, layanan yang bergantung diverifikasi dan interval bukti dipahami. Jawaban yang disimpan dalam cache dan email dalam antrean dapat bertahan lebih lama dari perbaikan yang terlihat. Persetujuan asli dan bukti pencarian pasca-perubahan masih hilang di sini, jadi penjelasan pendidikan ini bukanlah penilaian pembajakan yang telah selesai atau pernyataan bahwa domain mana pun aman.