[ Raporlar ve soruşturma ]

Temsili arıza ve uç durumları kullanarak bir DMARC ayrıştırıcısını doğrulama

Rapordan türetilen ölçümlere güvenmeden önce anlamsal doğruluğu, kaynak sınırlarını, yinelenen işlemleri ve güvenli kurtarmayı doğrulamak için sürümlendirilmiş bir fikstür matrisi kullanın.

EmailAuth araştırma ekibi tarafından

[ Anahtar noktalar ]

  • Ham kimlik doğrulama sonuçlarını DMARC uyumlu sonuçlardan ayırın.
  • Desteklenen şemaları, uzantıları ve çakışma davranışını açıkça tanımlayın.
  • Önceden belirlenmiş beklenen değerleri, tekrar oynatma güvenliğini ve ölçülen kaynak sonuçlarını karşılaştırın.
Bu sayfada

İyi bir XML raporunu kabul eden bir ayrıştırıcı yalnızca dar bir testi geçmiştir. Yararlı bir doğrulama paketi, neyi çıkardığını, neyi reddettiğini, desteklenen varyasyonları nasıl ele aldığını ve yeniden denemelerin toplamları değiştirip değiştirmediğini kontrol eder. Beklenen normalleştirilmiş değerleri, testin icat etmesine izin verilen bir çıktı olarak değil, fikstürün parçası olarak ele alın.

Desteklenen sözleşmeyi bildirin

Referanslar: RFC 9990 §3.1.1, RFC 9990 §3.2.

Ayrıştırıcıyı, çalışma zamanını, sıkıştırıcıyı ve şema sürümlerini kaydedin. Hangi rapor formatlarının ve uzantılarının desteklendiğini ve eski girdilerin nasıl işlendiğini belirtin. RFC 9990 geçerli toplu formatı ve genişletme modelini tanımlar; eski formatların desteklenmesi ayrı bir uyumluluk kararıdır.

Önce minimum düzeyde geçerli bir fikstür oluşturun. Baytlarını, karmasını, beklenen meta verilerini, aralığını, kaynak IP'sini, sayısını, kimliklerini ve hizalanmış sonuçlarını kaydedin. Başarılı XML ayrıştırmayı yeterli görmeyin: alan türlerini ve anlamlarını doğrulayın. Eksik isteğe bağlı değerleri, geçersiz gerekli verilerden farklı tutun.

Yaygın anlamsal hataları test edin

Referanslar: RFC 9990 §3.1.1.9, RFC 9990 §3.1.1.11, RFC 9989 §5.3.5.

Ham dahil DKIM hizalanmış bir DKIM hatasıyla ilgisiz bir alan adı altından geçiyor ve ham SPF olmadan geçmek hizalama. Hizalanmış bir mekanizmanın geçerken diğerinin başarısız olduğu bir durumu ekleyin. Normalleştirilmiş sonucun her iki mekanizmanın da geçmesini veya ham başarıyı uyumla eşitlemesini gerektirmediğini kontrol edin.

Yayınlanan politikadan basit bir çıkarımdan farklı olan rapor edilen düzenlemeyi ekleyin. Mevcut geçersiz kılma nedenlerini koruyun. Geçerli şema için, bilinmeyen eski bir değer olarak reddetmek yerine ActionDispositionType değer geçişini ekleyin; RFC 9990 Ek A geçmek için tanımlar DMARC zorlayıcı bir politikayla. Eski format beklentilerini açıkça ayrı tutun. İlk imza dışında tüm imzaları bırakmadan birden fazla DKIM sonucunu test edin. Amaç, eksik verilerden yeni bir alıcı değerlendirmesi uydurmak değil, raporun söylediklerini korumaktır.

Yapısal ve güvenlik vakalarını tatbik edin

Referanslar: RFC 9990 §3.2, RFC 9990 §8.1.

Referans: OWASP XML harici varlık önleme, Genel Kılavuz.

Geçersiz zorunlu değerler, hatalı biçimlendirilmiş XML, desteklenen ad alanı uzantıları, desteklenmeyen sürümler, eksik isteğe bağlı öğeler ve aşırı sınırlı iç içe yerleştirme kullanın. Sıkıştırılmış ve genişletilmiş boyut sınırlarını, kesintiye uğramış girişi ve zararsız harici referans koruyucularını ayrı ayrı test edin. Her girişin kabul edildiğini, karantinaya alındığını veya reddedildiğini ve nedenini tanımlayın.

Desteklenen bir uzantı, aşağı akış analizinin onu koruduğunu iddia etmesi durumunda sessizce kaybolmamalıdır. Desteklenmeyen bir yapı, başarısız kimlik doğrulama olarak yeniden sınıflandırılmak yerine açık bir uyumluluk sonucu üretmelidir. Güvenlik testlerini küçük ve kaynaklara bağlı tutun; Yalnızca bir sınırı göstermek için yıkıcı iş yükleri oluşturmayın.

Yineleme ve işlem davranışını doğrulayın

Referanslar: RFC 9990 §3.5.4.

Bir fikstürü içe aktarın, yeniden oynatın ve tekrar oynatmadan önce çalışanı yeniden başlatın. Sayılan rapor, belgelenmiş kopya kuralına göre tek kalmalıdır. Aynı rapor kimliğini iddia eden ve açık bir çelişki kararı gerektiren farklı bir ek ekleyin. Tek başına aynı kimlikler, farklı delillerin incelenmeden atılmasına izin vermez.

İşlemden önce kontrollü bir kesinti enjekte edin. Hiçbir kısmi kaydın üretim ölçümlerini etkilemediğini ve izin verilen yeniden denemenin beklenen sonucu bir kez verdiğini doğrulayın. Sıfır gözlem çıktılarını sıfıra bölmek veya mükemmel bir geçiş hızı üretmek yerine, kullanılamaz olarak test edin.

Bir kabul satırı üzerinde çalışın

Sentetik fikstür F1, hizalanmış DKIM geçişli 90 gözlem ve hizalanmış geçiş mekanizması olmayan on gözlem içerir. Beklenen dahil edilen sayı 100 ve beklenen gözlemlenen geçiş sayısı 90'dır. F1'in tekrar oynatılması her iki değeri de değiştirmeden bırakmalıdır. Kasıtlı olarak kısaltılmış bir kopya, toplamı artırmadan reddedilmelidir.

Yürütmeden önce beklenen değerleri kaydedin. Gerçek çıktıyı, kaynak ölçümlerini ve teşhislerini bu temel çizgiyle karşılaştırın. Bu bir ayrıştırıcı kabul spesifikasyonudur; herhangi bir ticari veya kiracı ayrıştırıcının bunu geçtiğine dair bir iddia değildir. Ayrı bir yeni çevrimdışı aritmetik/tekrar oynatma modeli, 100/90 değerlerini ve tekrarlanan kimlikteki değişmeyen sayımları kontrol eder; RFC 9990 XML raporunu ayrıştırmaz veya doğrulamaz. Bir durum başarısız olursa, daha sonraki bir revizyonun yeniden oluşturulabilmesi için kusuru ve tam tespitini saklayın.

Kaydedilen sonuçlarda kapı değişiklikleri

Fikstür kimliğini, karma değerini, amacı, beklenen sonucu, gerçek sonucu, ayrıştırıcı yapılandırmasını ve inceleme kararını içeren bir matris tutun. Desteklenmeyen özellikler için belgelenen istisnalar dışında, tüm zorunlu durumların dağıtılan revizyonda geçmesini zorunlu kılın. Bağımlılık veya normalizasyon değişikliklerinden sonra yeniden çalıştırın ve saklanan raporları yeniden işlemeden önce geçmiş metrik etkilerini karşılaştırın. Ayrıştırıcı doğrulaması hem sistemin kullanılabilirliğini hem de insanların politika kararları için kullandığı sayıların anlamını korumalıdır.

[ Götürmek ]

Önceden belirlenmiş beklenen değerleri, tekrar oynatma güvenliğini ve ölçülen kaynak sonuçlarını karşılaştırı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

Sürüm fikstürleri ve beklenen normalleştirilmiş değerler.

Hizalama semantiğini test edin ve tekrar oynatın. İşlem kurtarmayı ve kaynak sınırlarını doğrulayın.

Sonraki adımlar

  1. Sürüm fikstürleri ve beklenen normalleştirilmiş değerler.
  2. Hizalama semantiğini test edin ve tekrar oynatın.
  3. İşlem kurtarmayı ve kaynak sınırlarını doğrulayın.

CISO / SecOps

Güvenlik ve bütünlük olaylarını birlikte inceleyin.

Tam sürüm kabul kanıtı gerektirir. Geçmiş yeniden işlemeden önce metrik etkiyi değerlendirin.

Sonraki adımlar

  1. Güvenlik ve bütünlük olaylarını birlikte inceleyin.
  2. Tam sürüm kabul kanıtı gerektirir.
  3. Geçmiş yeniden işlemeden önce metrik etkiyi değerlendirin.

Kurucu / Teknik Olmayan

Kontrol paneli değişikliklerine güvenmeden önce kanıt isteyin.

Başarısız kabul vakalarına sahipler atayın. Desteklenmeyen formattaki boşlukları görünür tutun.

Sonraki adımlar

  1. Kontrol paneli değişikliklerine güvenmeden önce kanıt isteyin.
  2. Başarısız kabul vakalarına sahipler atayın.
  3. Desteklenmeyen formattaki boşlukları görünür tutun.

[ SSS ]

Sık sorulan sorular

Geçerli XML bir raporu kabul etmek için yeterli mi?

Hayır. Desteklenen rapor yapısını ve alan anlambilimini de doğrulayın.

RFC 9990 §3.1.1

Ham DKIM geçişi, hizalanmış DKIM geçişi anlamına mı gelmeli?

Hayır. İmzalama alanı, yazar alanıyla aynı hizada olmayabilir.

RFC 9990 §3.1.1.11 RFC 9989 §4.4

Hem hizalanmış SPF hem de DKIM geçmesi gerekir mi?

Hayır. Her iki mekanizmadan geçen hizalanmış bir yol DMARC karşılayabilir.

RFC 9989 §5.3.5

Tekrar testi neyi kanıtlamalı?

Yeniden denemeler ve yeniden başlatmalar, dahil edilen aynı gözlemleri tekrar eklemez.

Talep edilen aynı rapor kimliğine sahip farklı dosyalar nasıl ele alınmalıdır?

Çatışmayı sürdürün ve açık, kanıta dayalı bir karar uygulayın.

RFC 9990 §3.5.4

Desteklenmeyen formatlarda kimlik doğrulama hataları mı oluyor?

Hayır. Bunlar uyumluluk veya alım sonuçlarıdır.

Hatalı biçimlendirilmiş bir fikstürün üretim metriklerinde neleri değiştirmesi gerekir?

Atomik taahhütten önce doğrulama başarısız olursa hiçbir şey olmaz.

Doğrulama kaydında neler yer alır?

Fikstür karması, beklenen ve gerçek sonuçlar, konfigürasyon, ölçülen limitler ve inceleme kararı.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9989

    Bölümler §4.4 · §5.3.5

  2. RFC 9990

    Bölümler §3.1.1 · § 3.1.1.11 · § 3.1.1.9 · §3.2 · §3.5.4 · §8.1 · Ek A

  3. OWASP XML Harici Varlık Engelleme

    Bölümler Genel Rehberlik

[ Sözlük ]

Sözlük

Ham kimlik doğrulama sonuçları
SPF ve DKIM sonuçları, DMARC hizalaması ile ilişkileri yorumlanmadan rapor edildi.

RFC 9990 §3.1.1.11

Hizalanmış sonuçlar
Policy_evaluated SPF / DKIM sonuçları, DMARC ile ilişkili olarak.

RFC 9990 §3.1.1.9

Tekrar oynat
İstenmeyen ekstra metrik sayımları olmadan, belgelenmiş bir yinelenen kural kapsamında bir girdinin yeniden işlenmesi.

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ı