[ SPF ]

SPF uyumluluğundaki ani düşüşü araştırın

Düşen SPF yüzdesine yanıt vermeden önce gerçek kimlik doğrulama hatalarını değişen trafikten, hizalamadan ve raporlama kapsamından ayırın.

EmailAuth araştırma ekibi tarafından · 3 dakikalık okuma

[ Anahtar noktalar ]

  • Pay, payda, raportör seti ve zaman penceresini tanımlayın.
  • Trafik karışımı değişikliklerini meşru kimlik doğrulama hatalarından ayırın.
  • Bir onarım seçmeden önce temsili işlemleri doğrulayın.
Bu sayfada

Bir düşme SPF uyumluluk yüzdesi bir DNS tanısı değil, araştırılması gereken bir sinyaldir. Sayı, ham SPF geçişini, hizalanmış SPF geçişini, satıcıya özel bir sınıflandırmayı veya yalnızca belirli raporlama alıcıları tarafından görülebilen mesajları temsil edebilir. İlk önce payını, paydasını ve zaman penceresini yeniden oluşturun. Aksi takdirde başarılı bir altyapı değişikliği, bir saldırıyla veya raporlamayla karıştırılabilir.

Ölçümü tanımlayın

Kesin ölçümü bir yere yazın: örneğin, "hizalanmış SPF geçişine sahip iletilerin, bu UTC aralığı boyunca bu alınan raporlardaki tüm iletilere bölünmesi." Dahil edilen muhabirleri, hacmi, eksik dönemleri ve varsa tekilleştirme kurallarını kaydedin. Ham SPF sonuçlarını ayrı tutun DMARC hizalama. SPF Yazar Alanıyla ilgisi olmayan bir alan adı için geçerli olabilir; dolayısıyla geçiş sayısı ve hizalanmış geçiş sayısı farklı soruları yanıtlar. RFC 9989 §3.2.4, RFC 9989 §4.4.

Oranların yanı sıra mutlak sayıları da karşılaştırın. Açıklayıcı örnek: Dün gözlemlenen 10.000 mesajın 9.900'ü SPF ile uyumluydu. Bugün aynı 9.900 meşru mesaj geçiyor, ancak 10.000 ek yetkisiz mesaj görünüyor. Orijinal 100 hizalanmamış gözlemin de kaldığını ve bugün 20.000 gözlem verdiğini varsayalım. Bilinen meşru akışta yeni bir arıza olmadan oran %99'dan (9.900/10.000) %49,5'e (9.900/20.000) düşer. Bunlar sentetik aritmetik girdilerdir, rapor ölçümleri değil. Bu güvenlikle ilgili bir değişiklik olmaya devam ediyor, ancak bu kaynakları SPF eklemek yanlış yanıt olacaktır.

Düzenlemeden önce bölümleme

Değişikliği kaynak IP'sine, zarf etki alanına, Etki alanından, sağlayıcıya veya uygulamaya, alıcı raporlayıcısına, adres ailesine ve ham sonuca göre ayırın. En erken değişen segmenti bulun ve bunu DNS değişiklikleri, yeni kampanyalar, yönlendirme değişiklikleri, yük devretme olayları ve hizmet geçişleriyle karşılaştırın. Bildirilen kaynak adresleri tek başına işletme sahipliği oluşturmaz.

Başarısız, softfail , nötr, hiçbiri olarak sınıflandırın, temperror Ve permerror ayrı ayrı. Sonuç ayrımları önemlidir: DNS kesintisi, yeni yetkisiz bir adres veya hatalı biçimlendirilmiş bir kayıtla aynı düzeltici eyleme sahip değildir. Bir hata yolu için tam politikayı ve iç içe geçmiş bağımlılıkları yakalayın; SPF değerlendirme sınırları, görünür içerme dizelerinin basit bir sayısı değildir. RFC 7208 §4.6.4, RFC 7208 §8.

İşlem kanıtlarıyla onaylayın

Etkilenen her meşru akıştan temsili bir başarısız mesaj alın. Güvenilir bir sınırdan SMTP günlüklerini veya kimlik doğrulama sonuçlarıyla birlikte alınan orijinali alın. Bağlantı IP'sini ve gerçek değeri kontrol edin POSTA kimlik, ardından politika değerlendirmesini tarihli DNS kanıtlarıyla yeniden oluşturun. Bir kontrol paneli etiketi, bunların yerine geçmek yerine bu gözlemlere işaret etmelidir. RFC 8601 §1.2, RFC 8601 §7.1.

Ham geçiş hızı sabitse ancak hizalama düşüyorsa yeni bir zarf alanı arayın. Yalnızca bir alıcı popülasyonu değişirse yönlendirme ve bağlantı yollarını karşılaştırın. Bilinmeyen hacim artarken meşru hacim düşerse, tanımadığınız kaynakları izin vermeden araştırın. Raporlama kapsamı değiştiğinde, karşılaştırılabilirliği icat etmek yerine seriye açıklama ekleyin.

İstenilen durumu geri yükleyin

Sebebe uygun bir çözüm seçin: bir politika kusurunu düzeltin, DNS hizmetini onarın, desteklenen bir zarf yapılandırmasını geri yükleyin veya istenmeyen bir yönlendirmeyi durdurun. Kaydedilmiş bir önceki durumu, sorumlu sahibi ve açık geri alma koşulunu saklayın. Etkilenen akışları yeniden test edin ve bir sonraki karşılaştırılabilir raporlama penceresini inceleyin. Çözülmemiş raporlama boşlukları da dahil olmak üzere, olayı hem teknik sonuçla hem de ölçüm tanımıyla kapatın.

Kararı yazılı hale getirin

Aralık, raportör popülasyonu, toplam gözlemler, hizalanmış SPF sayısı, bilinen yasal hacim, bilinmeyen hacim ve eksik veri notlarını içeren bir karşılaştırma çalışma sayfası kullanın. Hizalanmış SPF düşerken ham SPF geçmeye devam ederse adres izinlerini düzenlemeden önce gerçek zarf etki alanlarını karşılaştırın. Yeni bir raporlayıcı veya değiştirilmiş bir veri tekilleştirme kuralı, iki oranı karşılaştırılamaz hale getirebilir. Bunlar inceleme kriterleridir; gerçek bir kesinti veya saldırının kanıtı değildir.

[ Götürmek ]

Pay, payda, raportör seti ve zaman penceresini tanımlayın. Trafik karışımı değişikliklerini meşru kimlik doğrulama hatalarından ayırın. Bir onarım seçmeden önce temsili işlemleri doğrulayın.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Pay ve paydayı açıkça tanımlayın.

Metrik tanımlarını, bölümlere ayrılmış sayıları, konfigürasyon değişikliklerini ve temsili işlem kanıtlarını birleştiren kısa bir olay çalışma sayfası tutun. SPF yalnızca kontrol paneli rengini iyileştirmek için düzenlemeyin.

Sonraki adımlar

  1. Pay ve paydayı açıkça tanımlayın.
  2. Hataları kimliğe ve rotaya göre segmentlere ayırın.
  3. Düzenlemeden önce temsili bir işlemi onaylayın.

CISO / SecOps

Saldırgan hacmini yasal hatalardan ayırın.

Saldırgan hacmini yasal bir gönderenin eksik yetkilendirmesinden ayırt edin. Bir olay sırasında yeni bir izin eklenmeden önce kaynak sahipliğini gerekli kılın.

Sonraki adımlar

  1. Saldırgan hacmini yasal hatalardan ayırın.
  2. Yeni izinden önce kaynak sahipliğini zorunlu kılın.
  3. Raporlama kapsamındaki belirsizliği belgeleyin.

Kurucu / Teknik Olmayan

Hangi meşru iş akışlarının değiştiğini sorun.

Yasal iş mesajlarının kimlik doğrulamasını gerçekten kaybedip kaybetmediğini, trafik karışımının değişip değişmediğini ve müşteri üzerindeki etkisinin bilinip bilinmediğini sorun. Paydası olmayan bir yüzde, kurtarma çalışmasını yanlış yönlendirebilir.

Sonraki adımlar

  1. Hangi meşru iş akışlarının değiştiğini sorun.
  2. Yüzdelerin yanı sıra mutlak hacimleri de inceleyin.
  3. Doğrulanmış müşteri etkisine öncelik verin.

[ SSS ]

Sık sorulan sorular

Daha düşük bir yüzde SPF bozulduğunu mu gösterir?

Hayır. Trafik karışımı, muhabirin kapsamı, hizalama veya ölçüm tanımı değişmiş olabilir.

İlk önce neyi incelemeliyim?

Kesin pay, payda, zaman penceresi, raporlayıcı seti ve mutlak mesaj sayıları.

Uyumluluk düşerken ham SPF geçişi yükselebilir mi?

Evet, daha fazla iletilen ileti hizalanmayan bir zarf etki alanı kullanıyorsa veya kontrol paneli farklı bir uyumluluk tanımı uyguluyorsa.

RFC 9989 §4.4 RFC 9989 §4.4.2

Tanınmayan kaynak IP'leri eklenmeli mi?

Yalnızca sahiplik ve meşru gönderme ihtiyaçları doğrulandıktan sonra. Oranın düşmesinin nedeni izinsiz trafik olabilir.

Geçici hatalar nasıl ele alınmalıdır?

Açık hatadan ayrı olarak DNS kullanılabilirliğini ve değerlendirme zamanlamasını araştırın. Zaman damgalarını ve eşzamanlı kanıtları koruyun.

RFC 7208 §2.6.6

Toplu gözlemler her göndereni tanımlayabilir mi?

Bunlar yararlı kanıtlardır ancak tam bir envanter değildir. Kapsam ve raporlama kullanılabilirliği farklılık gösterebilir; bu nedenle uygulama ve SMTP kayıtlarıyla mutabakat sağlayın.

IPv4 ile IPv6 neden karşılaştırmalısınız?

Değişen bir adres ailesi, uygulama ve zarf etki alanı değişmeden kalsa bile bir politika boşluğunu ortaya çıkarabilir.

RFC 7208 §5.6

Olayı ne zaman kapatabilirim?

Amaçlanan meşru yollar doğrulandığında metrik doğru şekilde yorumlanır ve kalan veri boşluklarının veya risklerin sahipleri olur.

[ Kaynaklar ]

Kaynaklar

  1. RFC 7208

    Bölümler §2.4 · §2.6 · §2.6.6 · §4.6.4 · §5.6 · §8

  2. RFC 9989

    Bölümler §3.2.4 · §4.4 · §4.4.2

  3. RFC 8601

    Bölümler §1.2 · §7.1

[ Sözlük ]

Sözlük

SPF
Bağlanan bir IP ve ilgili SMTP kimliği için yetkilendirme değerlendirmesi.

RFC 7208 §2.4

DMARC hizalaması
Kimliği doğrulanmış bir tanımlayıcı ile Yazar Etki Alanı arasında gerekli ilişki.

RFC 9989 §4.4

Uyumluluk oranı
Değerleri karşılaştırmadan önce payı, paydası, kaynak popülasyonu ve aralığının tanımlanması gereken bir ölçüm etiketi.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası