Domain bereputasi baik atau layanan pengiriman bersama dapat menjadi bagian dari jalur pesan yang menyesatkan. Pertanyaan yang berguna bukanlah apakah infrastruktur tersebut secara umum dapat dipercaya. Apakah pesan khusus ini diizinkan untuk menggunakan identitas yang diautentikasi. Otentikasi dan otorisasi bisnis menjawab pertanyaan yang berbeda.
Tentukan otoritas yang digunakan kembali
Kotak surat yang disusupi dapat mengirim melalui rute biasa yang diautentikasi. Otorisasi jaringan yang terlalu luas dapat menerima sumber yang tidak diinginkan. Relai dapat menandatangani pesan setelah menerimanya berdasarkan aturan penerimaan yang tidak cukup spesifik. Mekanisme ini mempunyai pemilik dan solusi yang berbeda. Jangan menggabungkannya menjadi satu klaim pembajakan reputasi yang tidak dapat dijelaskan.
Penelitian asli BreakSPF mengkaji permisif SPF konfigurasi dan infrastruktur bersama. Model ancamannya menjadikan akses jaringan sumber sebagai kondisi sentral. Itu adalah batasan penerapan, bukan bukti bahwa penyerang dapat memalsukannya tanda tangan DKIM. Makalah BreakSPF, Bagian III. Perlakukan pengukuran makalah ini sebagai penelitian sejarah, bukan inventarisasi layanan rentan saat ini.
Bangun model ancaman yang tepat
Tulis domain yang dilindungi, pengidentifikasi yang diautentikasi, kumpulan sumber yang diizinkan, kemampuan penyerang, dan keputusan penerima secara terpisah. Dalam skenario terbatas di sini, brand.test memberi otorisasi 192.0.2.0/24 untuk SPF . Permohonan yang disetujui menggunakan 192.0.2.10 , sedangkan penyewa hipotetis yang tidak diinginkan dapat berasal dari 192.0.2.99 . Kedua alamat tersebut berada dalam kisaran yang dipublikasikan. Apakah akses penyewa tersebut ada dalam layanan nyata memerlukan bukti terpisah.
SPF memeriksa otorisasi sumber untuk identitas yang dievaluasi. Itu tidak mengidentifikasi manusia di balik IP bersama. Jika identitas SPF yang diteruskan juga selaras dengan domain penulis, jalur tersebut dapat memuaskan DMARC tanpa DKIM. RFC 7208 Dan RFC 9989. Oleh karena itu, evaluasi yang berhasil dapat mengungkapkan bahwa terlalu banyak wewenang yang diberikan, dan bukannya penerima mengabaikan aturan kelulusan.
Bandingkan tiga kasus otorisasi tertulis
Asumsikan terlihat Dari alerts@brand.test , tidak kosong KIRIM DARI bounce@brand.test , tidak ada tanda tangan DKIM , dan evaluasi DMARC yang memenuhi syarat. Bandingkan hipotetis Catatan SPF v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- Sumber yang disetujui 192.0.2.10 : disertakan oleh kedua awalan jaringan; SPF lolos dan selaras dengan brand.test, sehingga pesan ilustratif lolos DMARC dalam kedua kasus tersebut.
- Sumber yang tidak diinginkan 192.0.2.99 : disertakan oleh /24 tetapi tidak /32; SPF hanya lolos pada catatan luas. Tanpa tanda tangan DKIM , hasil DMARC yang ditetapkan adalah lulus pada /24 dan gagal pada /32.
- Sumber luar 198.51.100.10 : tidak disertakan oleh awalan apa pun; -all hasil SPF gagal dalam kedua kasus. Tanpa tanda tangan DKIM , hasil DMARC yang ditetapkan gagal pada keduanya.
Ini adalah awalan-keanggotaan tertulis dan penyelarasan pengurangan, bukan parser SPF yang sedang berjalan, observasi DNS , atau reproduksi BreakSPF. Kontrol sumber diasumsikan, bukan didemonstrasikan. Tidak ada pesan eksternal atau layanan langsung yang diuji. Teknik lintas protokol makalah ini berada di luar contoh pengajaran ini.
Mekanisme passing selaras tunggal dapat memenuhi kondisi pass DMARC suatu pesan. Hal ini tidak membuat penerapan khusus SPF saja: RFC9989 pasal 7.4 memerlukan DKIM yang valid untuk penerbitan domain p=reject, dan bagian 8 membahas partisipasi penuh. Ini adalah tugas penerapan terpisah, bukan gerbang masuk tambahan per pesan.
Perbaiki batasan yang dapat dipertanggungjawabkan
Sebelum mempersempit data SPF yang sebenarnya, inventarisasi setiap pengirim yang sah dan ikuti konfigurasi yang didukung penyedia. Sumber khusus hanya berguna jika sumber tersebut benar-benar eksklusif dan terpelihara. Konfirmasikan bahwa layanan pengiriman mengikat pelanggan dengan identitas yang diizinkan; verifikasi konfigurasi DKIM dan hapus otoritas usang melalui kontrol perubahan.
Pantau kegagalan spesifik rute setelah perubahan, pertahankan rencana pemulihan, dan dokumentasikan pengirim yang tidak dikenal. Jangan ganti catatan luas dengan daftar IP yang ditebak dari contoh ini. Pelajarannya adalah merekonsiliasi otorisasi dengan kepemilikan layanan sebenarnya, bukan menyalin DNS demonstrasi ke dalam produksi.