[ Başlıklar ve teslimat hataları ]

Tekrarlanabilir bir e-posta teslim olayı kanıt paketi oluşturun

Orijinalleri, türevleri, zaman çizelgesini ve gözlemlenenlere ilişkin açık sınırlamaları içeren, başka bir analistin yeniden üretebileceği bir olay paketi oluşturun.

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

[ Anahtar noktalar ]

  • Orijinalleri, türevleri, zaman çizelgesini ve gözlemlenenlere ilişkin açık sınırlamaları içeren, başka bir analistin yeniden üretebileceği bir olay paketi oluşturun.
  • Her bulgu kendi kanıtını, belirsizliğini ve bir sonraki eylemi tanımlamalıdır; eşleşen bir karma, gerçeği değil, bayt tutarlılığını oluşturur.
Bu sayfada

Bir kanıt paketi, ikinci bir analistin, toplama çalışmasını tekrarlamadan veya hangi dosyanın güvenilir olduğunu tahmin etmeden olayı anlamasına olanak sağlamalıdır. Bunu okuyucunun sorusu ve gerçek dağıtım rotası etrafında düzenleyin. Büyük bir ZIP ekran görüntüsü, net kaynağı ve çözülmemiş soruları olan küçük, izlenebilir bir dizi yapıdan daha az kullanışlıdır.

Olayı ve kapsamını belirtin

Kısa bir vaka özetiyle başlayın: beklenen davranış, gözlemlenen belirti, etkilenen zaman aralığı, ilgili gönderen ve alıcı kapsamı, iş etkisi ve hala yanıtlanmamış soru. Bireysel başarısızlıkları daha geniş eğilimlerden ayırın. Kanıtların sağlayıcı kiracıdan mı, yerel bir testten mi, yoksa yapılandırılmış bir öğretim örneğinden mi geldiğini kaydedin.

Mevcut hipotezi yerleşik gerçeklerden ayırın. Örneğin, "bir ağ geçidi gövdeyi değiştirmiş olabilir", önceki ve sonraki baytlar veya eşdeğer güvenilir kanıtlar onu destekleyene kadar bir hipotezdir. A DKIM başarısızlık tek başına değişen sistemi tanımlamaz. RFC 6376 , sorumluluğun otomatik olarak atfedilmesini değil, imza kontrollerini açıklar. RFC 6376 bölüm 6.

Orijinalleri koruyun ve bir bildirim oluşturun

Değiştirilmemiş alınan mesajları, ilgili gönderen günlüklerini, alıcı teşhislerini ve yetkili DNS gözlemlerini kısıtlı bir orijinal alanında saklayın. Her yapı için toplama yöntemini, toplayıcıyı, saati, saat dilimini ve SHA-256 karmasını kaydedin. Sterilize edilmiş türevleri, kendi karmaları ve dönüşüm günlüğüyle birlikte ayrı bir alana koyun. Karma, bildirime göre bayt tutarlılığını doğrular; temel iddiayı doğrulamaz.

DNS kanıtı için tam sorguyu, kayıt türünü, çözümleyiciyi, yanıt süresini ve döndürülen verileri kaydedin. Bugünkü kaydın ekran görüntüsü, dünün konfigürasyonunun tarihsel kanıtı değildir. İletiler için, imza doğrulaması gerektiğinde ham baytları saklayın ve insanlar tarafından okunabilen alıntıları, yedek görünümler yerine kolay görünümler olarak saklayın.

Alıcı başına bir zaman çizelgesi oluşturun

Gönderimi, geçiş kabulünü, alıcıya özel retleri, yeniden denemeleri, son yanıtları ve bildirimleri ayrı olaylar olarak izleyin. Her satıra kaynak dosya adlarını veya karmaları ekleyin. RFC 5321 SMTP kabulü ve yeniden deneme bağlamını açıklar; RFC 3464 teslimat durumu alıcı bloklarını tanımlar. RFC 5321, RFC 3464.

Orijinal zaman damgalarını normalleştirilmiş UTC değerlerinin yanında tutun. Belirsiz saat farklarını ve eksik olayları işaretleyin. Aktarıcının son 250 yanıtından posta kutusu yerleşimi sonucunu çıkarmayın veya toplamdan belirli bir ileti sonucunu çıkarmayın DMARC saymak. Her bir ifadenin gözlemlendiğini, türetildiğini veya hala varsayımsal olup olmadığını açıkça etiketleyin.

Tekrarlanabilir kontrolleri ve sınırlamaları dahil edin

Komutları veya komut dosyasını, araç sürümlerini, seçilen imzayı veya kaydı, giriş karmalarını, beklenen gözlemleri ve gerçek çıktıyı sağlayın. Kimlik bilgilerini veya üretim imzalama sırlarını eklemekten kaçının. Enjekte edilen genel anahtarı kullanan yerel bir test, hiçbir DNS aramasının gerçekleşmediğini söylemelidir; sentetik bir ayrıştırıcı örneği, sağlayıcı değerlendirmesi olarak görünmemelidir.

Tamamlanmış bir kontrol için, gerçek çıktısını koruyun ve eksik veya değiştirilmiş yapıları açıkça işaretleyin. Önerilen bir kontrolü yapılmadı olarak etiketleyin ve gereken erişimi veya girişi belirtin. Boş bir kanıt paketini gözlem olarak sunulan beklenen çıktılarla doldurmayın.

Bir sonraki eylemi netleştirin

Doğrulanan bulgu, kalan boşluklar, önerilen dar düzeltme, sahiplik ve başarı koşulu ile sonlandırın. Yapılandırma değişiklikleri ve harici paylaşım yetkilerini kanıt toplamadan ayrı tutun. Onaylanmış bir onarımdan sonra, arızayı başarılı bir ekran görüntüsüyle değiştirmek yerine yeni tanımlanmış bir test ekleyin ve eski kanıtları koruyun.

Başka bir analistin paketteki üç soruyu yanıtlayabilmesi gerekir: Her bir kaynağa göre ne oldu, ne bağımsız olarak kontrol edilebilir ve ne hâlâ erişim veya muhakeme gerektiriyor. Mevcut kayıtların henüz bir neden ortaya koyamadığı yönünde dürüst bir sonuca varıldığında bile tamamlama standardı budur.

Varsayımsal çözülmemiş bir teslimat senaryosu taslağı çizin

Bir uygulama günlüğünün geçiş kabulünü kaydettiğini, ancak alıcının herhangi bir mesaj bildirmediğini varsayalım. Vaka özeti, kimlik doğrulamanın başarısız olduğunu değil, hedef teslimatın çözülmediğini belirtmelidir. Önerilen minimum paket, yetkili orijinal gönderimi veya tutulan baytları, geçişin kuyruk tanımlayıcısını ve zaman damgasını, alıcı başına izlemeyi, daha sonraki herhangi bir DSN'yi ve mümkün olduğunda alıcı tarafı gözlemini içerir.

Kullanılamayan her öğeyi eksik olarak işaretleyin. Bir sonraki sahip, ilgili geçişe veya alıcı izine erişimi olan kişidir; gerçekten kararlaştırılana kadar kişiyi görevlendirmeden bırakın. Uygun bir başarı koşulu, yalnızca başka bir başarılı gönderim değil, orijinal alıcı için ilişkili bir eğilim ve kalan boşluğun açıklanmasıdır.

Bu, varsayımsal bir paket taslağıdır, teslim edilmemiş dosyalardır, yürütülmüş bir olay araştırmasıdır veya gerçek bir kuruluşun toplama, paylaşma veya saklama yetkisi verdiğine dair bir iddiadır.

Paketi bir sonraki analist için faydalı hale getirin

  • Belirti, kapsam, zaman aralığı ve çözülmemiş soruyla başlayın.
  • Her gözlemi orijinal bir esere ve koleksiyon bağlamına bağlayın.
  • Orijinalleri, türevleri ve varsayımsal açıklamaları ayırın.
  • Tekrarlanabilir kontrol girişlerini ve gerçek çıkışları yalnızca gerçekleştirildiğinde dahil edin.
  • Bir sonraki kanıt talebini ve başarı koşulunu, bir sahibi veya onayı olmadan atayın.

[ Götürmek ]

Orijinalleri, türevleri, zaman çizelgesini ve gözlemlenenlere ilişkin açık sınırlamaları içeren, başka bir analistin yeniden üretebileceği bir olay paketi oluşturun.

[ 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 sonucu izlenebilir hale getirin

Her olay ve testin tanımlanabilir bir kaynağa ihtiyacı vardır.

Sonraki adımlar

  1. Hash ve envanter eserleri.
  2. Araç sürümlerini ve komutlarını koruyun.
  3. Alıcı zaman çizelgelerini farklı tutun.

CISO / SecOps

Kontrollü kanıt yönetimini koruyun

Tekrarlanabilirlik, sırları açığa çıkarmamalı veya erişimi genişletmemelidir.

Sonraki adımlar

  1. Orijinalleri kısıtlayın.
  2. Harici paylaşımı ayrı olarak inceleyin.
  3. Hipotezleri ve onayları açık tutun.

Kurucu / Teknik Olmayan

Soruşturmayı uygulanabilir hale getirin

Bir paket etkiyi ve bir sonraki kararı açıklamalıdır.

Sonraki adımlar

  1. İş semptomunu belirtin.
  2. Çözülmemiş soruyu atayın.
  3. Başarı durumunu takip edin.

[ SSS ]

Sık sorulan sorular

Bir olay paketinin başlangıcında ne yer alır?

Beklenen davranış, gerçek belirti, kapsam, zaman penceresi ve çözülmemiş soru.

Hipotezler gerçekler gibi mi görünmeli?

Hayır. Bunları etiketleyin ve test etmek için gereken kanıtları belirleyin.

Orijinalleri ve türevleri neden ayrı ayrı tutmalısınız?

Düzenlemeler teknik anlamı ve imza geçerliliğini değiştirebilir, dolayısıyla köken net kalmalıdır.

Eşleşen bir karma mesajın gerçek olduğunu kanıtlar mı?

Hayır. Yazarlık veya doğruluk değil, kaydedilen baytlarla tutarlılığı kanıtlar.

Bugünün DNS yanıtı dünün ayarını kanıtlayabilir mi?

Hayır. Tarihsel konfigürasyonun o zamana bağlı kanıtlara ihtiyacı vardır.

Bir çeki tekrarlanabilir kılan nedir?

Tanımlanan girdiler, araç versiyonları, komutlar, ayarlar, beklenen sonuçlar ve tutulan gerçek çıktı.

Taslak canlı bir olayı belgeliyor mu?

Hayır. Bu varsayımsal, çözülmemiş bir teslimat durumudur. Talep edilen toplanmış dosyalar, yürütülen kontroller veya atanmış gerçek sahibi içermez.

Soruşturma ne zaman kapanabilir?

Bulgular, kanıt sınırları, mülkiyet ve doğrulanmış onarım sonuçları açıkça kaydedildiğinde.

[ Kaynaklar ]

Kaynaklar

  1. RFC 6376 : DKIM İmzaları

    Bölümler §3.4 · §3.6 · §5 · §6

  2. RFC 5321: SMTP

    Bölümler §3.3 · §4.5.4 · §6.1

  3. RFC 3464 : Teslimat Durumu Bildirimleri

    Bölümler §2.2 · §2.3

  4. RFC 8601: Authentication-Results

    Bölümler §1.2 · §7

  5. RFC 9990 : DMARC Toplu Raporlama

    Bölümler §3.1

[ Sözlük ]

Sözlük

Olay kanıt paketi
Teslimat araştırması için kapsamlı bir dizi eser, kaynak, test ve bulgu.
Bütünlük denetimi
Kaydedilen yapay baytların kayıtlı parmak izleriyle karşılaştırılması.
Gözlemlenene karşı çıkarım yapılan
Doğrudan kanıt ile bundan çıkarılan sonuçlar arasındaki ayrım.

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ı