[ Kimlik sahteciliği ve kimliğin kötüye kullanılması ]

Güvenli e-posta ağ geçitleri ve DMARC : birinin diğerinin yerini aldığını varsaymaktan kaçının

Ağ geçidinin neleri değiştirdiğini, imzalamanın nerede gerçekleştiğini ve son alıcının hangi sonucu doğrulayabileceğini test edin.

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

[ Anahtar noktalar ]

  • Ağ geçidinin neleri değiştirdiğini, imzalamanın nerede gerçekleştiğini ve son alıcının hangi sonucu doğrulayabileceğini test edin.
  • Dönüşümlerden sonra son baytları yeniden test edin ve imzalayanın yetkilendirmesini imza geçerliliğinden ayrı tutun.
Bu sayfada

Güvenli bir e-posta ağ geçidi ve DMARC örtüşen operasyonel sorunları çözerler ancak birbirlerinin yerine kullanılamazlar. Bir ağ geçidi mesajları inceleyebilir, yönlendirebilir, karantinaya alabilir veya değiştirebilir. DMARC hizalanmış kimlik doğrulamayı değerlendirir ve alıcılara alan adı politikası bilgilerini sağlar. Önemli soru, imza oluşturulduktan sonraki dönüşümler de dahil olmak üzere rotanızın tamamının nasıl davrandığıdır.

Gerçek mesaj yolunu çizin

Sırayla kayıt gönderimi, imzalama, ağ geçidi işleme ve son alındı. Hangi bileşenleri kontrol ettiğinizi ve her birinin hangi kimlikleri imzalamaya yetkili olduğunu belirleyin. Yalnızca ağ geçidinin etkin olduğunu söyleyen bir diyagram, aşağı akışlı bir alıcının bozulmamış, hizalanmış bir imza alıp almadığını belirleyemez. Orijinal ve son ham mesajları, mesaj tanımlayıcılarını ve zamanlarını koruyarak yetkili bir test rotasından alın.

DKIM seçilen başlıkları ve standartlaştırılmış bir gövdeyi kapsar. Gövdenin yeniden yazılması, değiştirilen bağlantı meşru bir güvenlik özelliğinin parçası olsa bile mevcut imzayı geçersiz kılabilir. RFC 6376 imza ve doğrulama davranışını tanımlar. DKIM spesifikasyonu. İmzalı başlık listesini koruyun, kanonikleştirme Belirli bir arızayı açıklarken seçimler ve herhangi bir vücut uzunluğu parametresi.

Doğrulamayı ve imzalamayı kasıtlı olarak yerleştirin

Gelen ağ geçidi, bir mesajı değiştirilmeden önce doğrulayabilir, ancak bu dahili sonuç, her alt alıcı için otomatik olarak güvenilir değildir. Bir sonraki sistemin güvenilir sonuçları nasıl tanıyacağını ve güvenilmeyen başlık iddialarıyla ne yapacağını tanımlayın. RFC 8601. Daha sonra değiştirilen baytları kontrol eden bir doğrulayıcı, meşru bir nedenden dolayı farklı bir sonuca ulaşabilir.

Yönettiğiniz bir giden rota için, onaylanmış dönüşümlerden sonra imza atmak, son imzanın bozulmasını önleyebilir. İmzalayanın kendi alanı için yetkili olması gerekir ve hizalama hala değerlendirmeye ihtiyacı var. İlgisiz bir ağ geçidi etki alanından geçerli bir imza eklemek, mutlaka uyumlu bir DMARC sonucu oluşturmaz. Daha geniş kontrol tasarımını gözden geçirmeden, yalnızca bir imzayı korumak için güvenlik denetimini kaldırmayın.

Varsayımsal bir yeniden yazmanın izini sürün

Yetkili bir brand.test imzalayıcısının, URL içeren bir mesaj gövdesini imzaladığını varsayalım. Daha sonra bir ağ geçidi, daha sonra yetkili bir hizalanmış imza eklemeden, kapsanan URL'yi değiştirir. Kurallı hale getirilmiş imzalı baytlar değişirse önceki imza, değiştirilen gövdeye göre geçerli olmayacaktır. İlgili kanonikleştirilmiş imzalı baytları değiştirmeden bırakan bir dönüşümün imzayı bozması gerekmez. Her yeniden yazmanın aynı etkiye sahip olduğunu varsaymak yerine kanonikleştirmeyi, seçilen başlıkları ve herhangi bir l= limitini inceleyin.

Dönüştürülen son mesajı ayrı bir yetkili imzalayan imzalarsa, eski imza başarısız olsa bile bu yeni imza doğrulanabilir. Eski imzayı onarmaz veya yeni imzalayanın ticari yetkisi olduğunu kanıtlamaz. Yeni d= alanının hizalamasını ve güvenilir nihai alıcı sonucunu değerlendirin. Bunlar protokole dayalı varsayımsal sonuçlardır; ham mesaj örnekleri, oluşturulan anahtarlar, dkimpy çıktısı veya yürütülen bir ağ geçidi denemesi değildir.

Sonucu rota testine çevirin

Üretimde, kontrollü alıcıları ve satıcının desteklenen yapılandırmasını kullanarak ilgili yetkili dönüşümü yeniden oluşturun. Ağ geçidi konsolundan başarıyı çıkarmak yerine son alıcının güvenilir sonuçlarını yakalayın. Aynı içerik revizyonunu rota boyunca karşılaştırın ve konu önekleri veya sorumluluk reddi beyanları gibi diğer değişiklikleri not edin. Yeni bir imzanın geçmesi, daha önceki kimlik doğrulamanın devam ettiğini kanıtlamaz.

Başarısızlık yönetimini de test edin. İmzalama adımı kullanılamıyorsa, postaların sıraya girip girmediğini, başarısız olup olmadığını veya beklenen imza olmadan ayrılıp ayrılmadığını belirleyin. Kurtarma talimatlarını gerçek hizmete bağlı tutun. Kapsamlı bir kimlik doğrulama sorununu sınırsız geçişe veya denetlenmemiş dağıtıma dönüştüren acil durum atlamasından kaçının.

Kabul kaydında test edilen rota, dönüşüm, imzalayanın yerleşimi, nihai kimlikler ve alıcı sonucu belirtilmelidir. Kötü amaçlı yazılım filtreleme için ayrı kontroller yapın, kimlik avı algılama ve etki alanı kimlik doğrulaması. Bir testi geçmek, mesajın veya ağ geçidinin tamamının güvenli olduğunu gösteren bir sertifika değil, bu yeteneğe ilişkin yararlı bir kanıttır.

Kaynak ve yürütme sınırı

RFC 9989 Bölüm 4.4, 5.3.5 ve 5.4 kimlik doğrulama, hizalama ve işlemeyi ayırt edin; geçiş, mesaj içeriğini onaylamaz. Buradaki operasyonel kararlar, kapsamlı tavsiyeler ve açıkça varsayımsal örneklerdir; bir müşterinin, sağlayıcının veya tarihi demirbaşın yeni testleri değildir. Herhangi bir gerçek değişiklik, kendi yetkili kapsamını, saklanan kanıtları ve sorumlu kararı gerektirir.

[ Götürmek ]

Dönüşümlerden sonra son baytları yeniden test edin ve imzalayanın yetkilendirmesini imza geçerliliğinden ayrı tutun.

[ 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

Son mesaj baytlarını doğrulayın

Dönüşüm sırası önemlidir.

Sonraki adımlar

  1. Her iki ham mesajı da yakalayın.
  2. İmzalayanın yerleşimini kontrol edin.
  3. İmzalama hatası işlemeyi test edin.

CISO / SecOps

Kontrol sınırlarını koruyun

Kimlik doğrulama kanıtları güvenilir kalmalıdır.

Sonraki adımlar

  1. Güvenilir değerlendiricileri tanımlayın.
  2. Baypas risklerini gözden geçirin.
  3. İmzalayanın yetkilendirmesini denetleyin.

Kurucu / Teknik Olmayan

Test edilmiş yetenekleri satın alın

Özellik adları rota sonuçlarını oluşturmaz.

Sonraki adımlar

  1. Uçtan uca kanıt gerektirir.
  2. Fon sürekliliği testi.
  3. Ayrı inceleme ve kimlik doğrulama hedefleri.

[ SSS ]

Sık sorulan sorular

Ağ geçidi DMARC yerini alır mı?

Hayır. Denetim ve yönlendirme kontrolleri, hizalanmış alan kimlik doğrulamasından farklıdır.

URL'nin yeniden yazılması DKIM bozabilir mi?

Evet. Kapsam dahilindeki bir gövde değişikliği, daha önceki imzayı geçersiz kılabilir.

Bu öğretim örneği için kriptografi uygulandı mı?

Hayır. Yeni bir imzalama veya doğrulama çalıştırması talep etmeden DKIM kurallarından varsayımsal kapsanan bayt dönüşümlerini açıklar.

Gerçek bir ağ geçidi test edildi mi?

Hayır. Bu öğretim revizyonu için hiçbir ağ geçidi hesabı, yerel yeniden yazma deneyi veya harici dağıtım uygulanmadı.

Yeni imza eskisini onarır mı?

Hayır. Orijinal imza geçersiz kalırken yeni imza doğrulanabilir.

Herhangi bir ağ geçidi alanı DMARC hizalamasını geri yükleyebilir mi?

Hayır. Geçen bir imza aynı zamanda geçerli hizalama ilişkisini de karşılamalıdır.

Giden imzalama nerede yapılmalı?

Genellikle yetkili kimlik ve son doğrulama ile kontrollü rotada onaylanmış değişikliklerden sonra.

Kabul testi neyi muhafaza etmelidir?

Orijinal ve nihai mesajlar, dönüşüm ayrıntıları, imzalayanların yerleşimi ve güvenilir alıcı sonuçları.

[ Kaynaklar ]

Kaynaklar

  1. RFC 6376 DKIM

    Bölümler §3.4 · §3.5 · §3.7 · §6.1 · §6.3

  2. RFC 8601 Kimlik Doğrulama Sonuçları

    Bölümler §1.2 · §1.6 · §7

  3. RFC 9989 DMARC

    Bölümler §4.4 · §5.3.5 · §5.4 · §7.4 · §8

[ Sözlük ]

Sözlük

İmzalayan yerleşimi
Mesaj dönüşümlerine göre imzanın eklendiği konum.
Kanonikleştirme
Hashing işleminden önce belirtilen mesaj baytlarının normalleştirilmesine yönelik DKIM kuralları.

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ı