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

Yanıt manipülasyonu ve iş e-postası araştırmaları

Yanıtla'yı DMARC kimliğini doğrulayan kimlik olarak değil, ayrı bir yanıt yönlendirme talimatı olarak inceleyin.

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

[ Anahtar noktalar ]

  • Yanıtla'yı DMARC kimliğini doğrulayan kimlik olarak değil, ayrı bir yanıt yönlendirme talimatı olarak inceleyin.
  • Yanıt yönlendirme, imza bütünlüğü ve iş izni farklı kararlardır.
Bu sayfada

Bir mesaj, yanıtları başka bir yere yönlendirirken tanıdık bir Gönderen adresini kullanabilir. Bu fark, biletleme hizmeti gibi meşru olabilir veya hassas bir konuşmayı yeniden yönlendirebilir. Uyuşmazlığı bir saldırı olarak adlandırmadan veya kimlik doğrulamayı yanıt hedefinin onayı olarak değerlendirmeden önce gerçek alanları ve alıcı güven sınırını araştırın.

Alanın rolünü anlayın

RFC 5322 Yanıtla'yı yazarın yanıtların gönderilmesini önerdiği posta kutusu veya posta kutuları olarak tanımlar. Bunun yokluğunda yanıtlar normalde Kimden posta kutusuna gider. Bu, SMTP zarf tesliminden ve insan onayı kararından farklı olan, mesaj formatındaki bir talimattır. İstemciler ve iş akışı araçları kendi yanıt davranışlarını uygulayabilir; dolayısıyla hassas bir yanıt göndermeden önce gerçek alıcıyı inceleyin. RFC 5322 bölüm 3.6.2.

DMARC kimlik ilişkisi için Yanıtla alanını değil, yazar alanını kullanır. Bu nedenle geçiş, farklı bir Yanıtla etki alanının aynı kuruluşa ait olduğunu kanıtlamaz. geçerli DKIM imzası Bu alan imzanın imzalı başlık listesine dahil edildiğinde Yanıtla'yı kapsayabilir, ancak bir değerin bütünlüğü, onu gizli yazışmalar için kullanma izni vermez. DMARC Ve DKIM.

Ekran görüntüsü yerine orijinale açıklama ekleyin

Ham mesaj baytlarını koruyun. Kimden, Yanıtla'yı gösteren ayrı bir ek açıklama oluşturun: Return-Path, DKIM d= and h= values, and the receiving system that produced Authentication-Results. Gönderen tarafından sağlanan alanlar olarak İşaretle ve Yanıtla, doğrulama gerektiren bir talep olarak DKIM imzası ve yalnızca kökenleri belirlendiğinde kimlik doğrulama sonuçları güvenilir olarak kabul edilir. RFC 8601.

Kopyalanan Authentication-Results satırının orijinal olduğunu varsaymayın. Benzer şekilde, rastgele kaydedilen bir metin dosyasındaki Return-Path alanı, SMTP zarfını bağımsız olarak kanıtlamaz. Gerektiğinde yetkili alma günlükleriyle bağlantı kurun.

Üç yazılı başlık senaryosunu karşılaştırın

Her durumda billing@supplier.example.test adresinden görünür olduğunu varsayalım. Zarf kimliği, DKIM d= ve h= değerleri, gerçek imzalar ve güvenilir alıcı sonuçları sağlanmaz. Kopyalanan geçiş onayı bu boşlukları dolduramaz.

  • Beklenmeyen rota: Yanıtla case@support.example.test ; iş akışı onayı sağlanmadı. Farklı etki alanını incelenmek üzere işaretleyin, hassas yanıtları saklayın ve bilinen bir kanal aracılığıyla hizmet sahibine sorun.
  • Aynı etki alanı rotası: Yanıtla help@supplier.example.test . Tam alan adı uyumsuzluğu kuralı bunu işaretlemez ancak bu, posta kutusunun veya istenen bilgilerin yetkili olduğunun kanıtı değildir.
  • Kapsamlı istisna: Yanıtla case@tickets.example.test ; kurgusal bir envanterin bu hizmete yalnızca rutin destek biletleri için izin verdiğini varsayalım. Ödeme değişikliklerine veya gizli belgelere izin vermek yerine, bu amaçla beklendiği gibi davranın.

Bu örnekler yazılı değerler ve kararlardır; dahil edilen bir .eml dosyası, ayrıştırıcı çalıştırması veya gerçek kimlik doğrulama sonucu değildir. Hiçbir DKIM imzası uydurulmamıştır. Önerilen hizmet sahibi, gerçek bir yanıttan önce hem alıcıyı hem de izin verilen bilgileri doğrular; posta araştırmacısı orijinal baytları ve güvenilir kimlik doğrulama kanıtlarını ayrı ayrı elde eder.

Yanıt hedefini iş akışına göre doğrulayın

Servis sahibine bu mesaj tipi için harici hedefin beklenip beklenmediğini ve önerilen bilgiye uygun olup olmadığını sorun. Destek posta kutusu, faturayı gönderen kişiden yasal olarak farklı olabilir, ancak yine de ödeme talimatları veya hassas ekler için uygun olmayabilir. Onay, yalnızca alanın varlığıyla değil, amaçla da eşleşmelidir.

Beklenmedik istekler için, bilinen bağımsız bir kanal aracılığıyla sözde gönderenle iletişime geçin. Gizli materyali e-postayla göndererek şüpheli bir hedefi test etmeyin. Bir istemci Yanıtla'yı otomatik olarak doldurduysa, hedef doğrulanana kadar taslağı iptal edin.

Alan düzeyindeki soruyu kapat

Uyumsuzluğun beklenip beklenmediğini, izin verilmediğini veya çözülmediğini ve bu bulguyu hangi kanıtların desteklediğini kaydedin. Kimlik doğrulama sonuçlarını ayrı bir gözlem olarak saklayın. Bu, yararlı bir ayrımı korur: Bir mesaj sağlam olabilir ve etki alanı kimlik doğrulaması yapılmış olabilir, ancak önerilen yanıt yolu iş eylemi için uygun olmayabilir.

[ Götürmek ]

Yanıt yönlendirme, imza bütünlüğü ve iş izni farklı kararlardır.

[ 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

Her başlığın kökenine açıklama ekleyin

Başlık adları tek başına güven oluşturmaz.

Sonraki adımlar

  1. Orijinal baytları koruyun.
  2. İmzalı başlık kapsamını inceleyin.
  3. Gerçek yanıt alıcılarını kontrol edin.

CISO / SecOps

Bütünlüğü ve yetkilendirmeyi ayrı ayrı ele alın

İmzalı bir talimat yine de uygunsuz olabilir.

Sonraki adımlar

  1. Veri paylaşımı kapsamını inceleyin.
  2. Araştırma kopyalarını koruyun.
  3. İstisna sahipliğini kaydedin.

Kurucu / Teknik Olmayan

Konuşmanın nereye gittiğini doğrulayın

Tanıdık bir gönderen, başka bir yanıt hedefi önerebilir.

Sonraki adımlar

  1. İş akışına özgü rotaları onaylayın.
  2. Hassas istekleri bağımsız olarak doğrulayın.
  3. Genel güvenden kaçının.

[ SSS ]

Sık sorulan sorular

DMARC Yanıtla kimliğini doğruluyor mu?

Hayır. Yazar-alan adı ilişkisi From'a dayanmaktadır.

Farklı bir Yanıtla otomatik olarak kötü amaçlı mıdır?

Hayır. Biletleme ve diğer onaylı iş akışları ayrı bir adres kullanabilir.

DKIM Yanıtla'yı kapsayabilir mi?

Evet, imzalı başlıklar arasına dahil edildiğinde imza doğrulanır; bu dürüstlüktür, iş onayı değil.

Hassas bir yanıttan önce nelerin incelenmesi gerekir?

Müşteri tarafından seçilen gerçek alıcılar ve bunların iş akışına uygunluğu.

Kopyalanan bir Authentication-Results satırı başarılı olduğunu kanıtlar mı?

Hayır. Güvenilir alma kaynağı oluşturun.

Bu örnekler ayrıştırıldı mı veya doğrulandı mı?

Hayır. Bunlar yazılı başlık senaryolarıdır; hiçbir .eml yapıtı, ayrıştırıcı yürütmesi veya güvenilir alıcı kararı sağlanmıyor.

Onaylı bir dış servis her türlü bilgiyi alabilir mi?

Hayır. Onay, amaç ve izin verilen verilerle eşleşmelidir.

Uyumsuzluk nasıl kapatılmalıdır?

Beklendiği gibi, yetkisiz veya çözülmemiş, kanıtlarla ve ayrı bir kimlik doğrulama bulgusu ile.

[ Kaynaklar ]

Kaynaklar

  1. RFC 5322 İnternet Mesaj Formatı

    Bölümler §2.2 · §3.4 · §3.6.2

  2. RFC 9989 DMARC

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

  3. RFC 6376 DKIM İmzaları

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

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

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

[ Sözlük ]

Sözlük

Yanıtla
Yanıtların nereye yönlendirilmesi gerektiğini gösteren mesaj alanı.
İmzalı başlık listesi
İmzanın kapsadığı başlıkları tanımlayan DKIM h= listesi.
İş akışı istisnası
Tanımlanmış bir iş süreci için belgelenmiş izin verilen sapma.

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ı