Saygın bir alan adı veya paylaşılan gönderme hizmeti, kötüye kullanım amaçlı mesaj yolunun parçası olabilir. Yararlı soru, altyapının genel olarak güvenilir olup olmadığı değildir. Bu özel mesajın kimliği doğrulanmış kimliği kullanma yetkisine sahip olup olmadığıdır. Kimlik doğrulama ve işletme yetkilendirmesi farklı sorulara yanıt verir.
Yeniden kullanılan yetkiyi tanımlayın
Güvenliği ihlal edilmiş bir posta kutusu, kimliği doğrulanmış normal rota üzerinden gönderim yapabilir. Aşırı geniş bir ağ yetkilendirmesi, istenmeyen bir kaynağı kabul edebilir. Aktarıcı, yeterince spesifik olmayan bir kabul kuralı kapsamında bir mesajı kabul ettikten sonra imzalayabilir. Bu mekanizmaların farklı sahipleri ve çareleri vardır. Bunları, itibar gaspına ilişkin açıklanamayan tek bir iddiaya indirgemeyin.
Orijinal BreakSPF araştırması müsamahakârlığı inceliyor SPF yapılandırmalar ve paylaşılan altyapı. Tehdit modeli, kaynak ağ erişimini merkezi bir koşul haline getiriyor. Bu bir dağıtım sınırıdır, bir saldırganın herhangi bir sahtecilik yapabileceğinin kanıtı değildir. DKIM imzası. BreakSPF belgesi, Bölüm III. Makalenin ölçümlerini, savunmasız hizmetlerin mevcut bir envanteri olarak değil, tarihsel bir araştırma olarak ele alın.
Kesin bir tehdit modeli oluşturun
Korunan etki alanını, kimliği doğrulanmış tanımlayıcıyı, izin verilen kaynak kümesini, saldırgan yeteneğini ve alıcı kararını ayrı ayrı yazın. Buradaki sınırlı senaryoda brand.test, SPF için 192.0.2.0/24 yetkilendirir. Onaylanan başvuru 192.0.2.10 kullanırken, varsayımsal istenmeyen kiracı 192.0.2.99 kaynaklanabilir. Her iki adres de yayınlanan aralıkta yer almaktadır. Bu tür kiracı erişiminin gerçek bir hizmette mevcut olup olmadığı ayrı bir kanıt gerektirir.
SPF değerlendirilen kimliği için kaynak yetkilendirmesini kontrol eder. Paylaşılan bir IP'nin arkasındaki insanı tanımlamaz. Geçen SPF kimliği aynı zamanda yazarın etki alanıyla da uyumluysa, bu yol aşağıdaki gereksinimleri karşılayabilir: DMARC olmadan DKIM. RFC 7208 Ve RFC 9989. Bu nedenle başarılı bir değerlendirme, alıcının geçiş kuralını göz ardı etmesi yerine çok fazla yetki verildiğini ortaya çıkarabilir.
Üç yazılı yetkilendirme durumunu karşılaştırın
Görünür olduğunu varsayalım From alerts@brand.test , nonempty POSTA bounce@brand.test , DKIM imzası yok ve başka şekilde uygun bir DMARC değerlendirmesi. Varsayımsal karşılaştır SPF kayıtları 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.
- Onaylanan kaynak 192.0.2.10 : her iki ağ önekinde de bulunur; SPF brand.test'i geçip onunla uyumlu olduğundan, açıklayıcı mesaj her iki durumda da DMARC geçer.
- İstenmeyen kaynak 192.0.2.99 : /24'e dahil edilmiş ancak /32'ye dahil edilmemiştir; SPF yalnızca geniş kayıt altından geçer. DKIM imzası olmadığında, öngörülen DMARC sonucu /24'ün altında geçer ve /32'nin altında başarısız olur.
- Dış kaynak 198.51.100.10 : her iki önek de dahil; -all sonuçlar SPF her iki durumda da başarısız olur. DKIM imzası olmadığında öngörülen DMARC sonucu her ikisinde de başarısız olur.
Bunlar; yazılı önek-üyelik ve hizalama kesintiler, çalışan bir SPF ayrıştırıcısı, DNS gözlemi veya BreakSPF'nin çoğaltılması değil. Kaynak kontrolü varsayılır, gösterilmemiştir. Hiçbir harici mesaj veya canlı hizmet test edilmedi. Makalenin çapraz protokol tekniği bu öğretim örneğinin dışındadır.
Tek geçişli hizalanmış mekanizma, bir mesajın DMARC geçiş koşulunu karşılayabilir. Bu, yalnızca SPF dağıtımını yeterli kılmaz: RFC9989 bölüm 7.4, alan yayınlama için geçerli DKIM gerektirir p=rejectve 8. bölüm tam katılımı ele almaktadır. Bunlar ayrı konuşlandırma görevleridir, mesaj başına ekstra bir geçiş kapısı değildir.
Sorumlu sınırı düzeltin
Gerçek bir SPF kaydını daraltmadan önce, her yasal gönderenin envanterini çıkarın ve sağlayıcı tarafından desteklenen yapılandırmayı izleyin. Özel bir kaynak yalnızca gerçekten özel olması ve bakımının yapılması durumunda faydalıdır. Gönderme hizmetinin müşterileri izin verilen kimliklerine bağladığını doğrulayın; DKIM yapılandırmasını doğrulayın ve değişiklik kontrolü yoluyla eski yetkiyi kaldırın.
Değişiklikten sonra rotaya özgü arızaları izleyin, bir kurtarma planını koruyun ve bilinmeyen gönderenleri belgeleyin. Geniş bir kaydı, bu örnekteki tahmin edilen bir IP listesiyle değiştirmeyin. Ders, gösteri DNS üretime kopyalamak değil, yetkilendirmeyi gerçek hizmet sahipliğiyle uzlaştırmaktır.