[ Raporlar ve soruşturma ]

Kimlik doğrulama raporlarında 1e100.net araştırın

Başlangıç ​​ipucu olarak bir Google altyapı etiketi kullanın, ardından iletinin kimliğini, rotasını ve gerçek hizmet sahibini doğrulayın.

EmailAuth araştırma ekibi tarafından

[ Anahtar noktalar ]

  • Google altyapı etiketi, hesabınızın size ait olduğunu göstermez.
Bu sayfada

Kimlik doğrulama kontrol panelinde bir kaynağın yanında 1e100.net görmek, trafiğin kuruluşunuza ait olup olmadığını size söylemez. Google, ağındaki sunucuları tanımlamak için kullandığı alan adı olarak 1e100.net belgelemektedir. Bu, belirli bir mesajın yetkilendirilmesini veya arkasındaki Google hesabının kimliğini değil, altyapı adının anlamını belirler.

Etiketin kökenini bulun

Ham raporun kaynak IP'siyle başlayın ve kontrol panelinin görüntülenen adı nasıl ürettiğini sorun. Bu, geçerli bir ters DNS araması, önbelleğe alınmış zenginleştirme veya satıcı sınıflandırması olabilir. Arama süresini ve yöntemini raporun orijinal aralığından ayrı olarak koruyun. Mevcut bir etiket, mesajın gözlemlendiği sırada adresin nasıl adlandırıldığına dair tarihsel bir kanıt değildir.

Kanıt kaydındaki kaynak adresi yerine kolay adı kullanmayın. Her ikisini de artı raporlayanı, rapor kimliğini, sayımı ve kapsanan aralığı saklayın. Bu, başka bir analistin kontrol panelinin değişen zenginliğine bağlı olmadan gözlemi yeniden oluşturmasına olanak tanır.

Kimlik doğrulama kimliklerini inceleyin

Bildirilen yazar alanını karşılaştırın SPF kimlik, DKIM etki alanlarını imzalama ve uyumlu politika sonuçları. İlgisiz bir alan adı altında ham SPF veya DKIM başarısı sağlanmaz DMARC yazar alan adınız için başarı. Tersine, tanıdık olmayan bir kaynak etiketi, geçerli bir hizalanmış imzaya eşlik edebilir.

Kimlik doğrulamayı sahiplikten ayrı tutun. Geçerek hizalanmış bir mekanizma, ilgili etki alanı kimlik doğrulama sonucunu destekler, ancak mesajın istendiğini veya hesabın güvenliğinin ihlal edilmediğini kanıtlamaz. Başarısız bir sonuç, daha fazla kanıt olmadan kötü niyetli niyetin varlığını kanıtlamaz.

Olası rotayı test edin

Kuruluşun Google ile ilgili gerçek hizmetlerini ve hesap envanterini kontrol edin. Sorumlu yöneticiye, personel postasının, yapılandırılmış bir aktarmanın veya bir yönlendirme yolunun gözlemi açıklayıp açıklayamayacağını sorun. Rotayı doğrulamak için güvenilir alıcı başlıklarını ve yetkili uygulama günlüklerini kullanın; keyfi olarak güvenmeyin Alınan veya Authentication-Results gönderen tarafından sağlanan metin.

Rota yetkiliyse ancak kimlik tasarımı net değilse, tam olarak bu uygulama aracılığıyla zararsız, kontrollü bir test gönderin. Alıcı posta kutusunu, zaman damgasını ve kimliklerini kaydedin. Farklı bir posta kutusu veya hizmet aracılığıyla yapılan test, orijinal rotayı doğrulamaz.

İki gözlem üzerinden çalışın

Bu sentetik karşılaştırmada, her iki kayıtta da 1e100.net ile biten bir zenginleştirme etiketi bulunur. A Kaydı, kuruluşun yazar alanı için uyumlu bir DKIM geçişine sahip 40 gözleme sahiptir. Kayıt B'de hizalanmış geçiş mekanizması olmayan altı gözlem vardır. Paylaşılan altyapı etiketi, kimlik doğrulama sonuçlarını eşdeğer kılmaz.

Yönetici, A'yı bilinen bir gönderen hesap ve örnek mesajla doğrular. B, hesap ve rota kanıtları beklemede olarak sınıflandırılmamış olarak kalır. Bir sonraki işlem, Google etiketli trafiğin tamamını onaylamak veya gözlemlenen adresi SPF eklemek değil, B'yi araştırmaktır. Bu örnekte hiçbir gerçek hesap veya trafik incelenmedi.

Desteklenen bir sınıflandırmayla kapat

Üç sonuçtan birini kaydedin: Destekleyici kanıtlarla birlikte doğrulanmış yetkili servis, desteklenen izinsiz kullanım veya sahibiyle çözülmemiş gözlem ve bir sonraki adım. Sınıflandırma güvenini ve tarihini koruyun. Kimlik doğrulamanın onarılması gerekiyorsa ters DNS adından DNS değişiklikleri oluşturmak yerine doğrulanan hizmet için geçerli birinci taraf talimatlarını kullanın.

Hesap geçişleri, yönlendirme değişiklikleri veya yeni uygulamalardan sonra sınıflandırmayı inceleyin. Yalnızca tanınabilir altyapı alanına dayalı kalıcı istisnalardan kaçının. Yararlı sonuç, yalnızca sunucuyu işleten şirketi değil, hizmeti ve kimlik doğrulama yolunu tanımlar.

Yetkisiz kullanım sınıflandırması için, güvenilir mesaj ve hesap günlükleriyle desteklenen, sorumlu hesap sahibinin izlenen gönderme eyleminin yetkisiz olduğunu doğrulayan olumlu kanıtları saklayın. Bilinmeyen bir sahip veya başarısız hizalama sonuç tek başına çözümsüz kalır; Eksik kanıtları ve bunları kimin elde edeceğini kaydedin.

Kompakt bir araştırma kaydı tutun

  • Kaynak kanıtı: ham IP, rapor kimliği, raporlayan, sayım ve dönem.
  • Zenginleştirme kanıtı: görüntülenen ad, arama yöntemi ve arama süresi.
  • Kimlik doğrulama kanıtı: yazar alanı, ham SPF / DKIM kimlikleri ve uyumlu sonuçlar.
  • İş kanıtı: hizmet sahibi, yetkili hesap veya rota ve bunu doğrulayan kontrollü bir mesaj.
  • Karar: yetkili, desteklenen yetkisiz kullanım veya sahibiyle çözülmemiş ve sonraki adım. Tanıdık bir sunucu etiketi karar değildir.

[ Götürmek ]

Başlangıç ​​ipucu olarak bir Google altyapı etiketi kullanın, ardından iletinin kimliğini, rotasını ve gerçek hizmet sahibini 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

Fikri mülkiyeti ve zenginleştirme kaynağını koruyun.

Daha sonraki zenginleştirme değişikliklerinin araştırmayı yeniden yazamaması için orijinal gözlemi koruyun.

Sonraki adımlar

  1. Fikri mülkiyeti ve zenginleştirme kaynağını koruyun.
  2. Ham kimlikleri hizalamayla karşılaştırın.
  3. Şüphelenilen uygulamayı tam olarak test edin.

CISO / SecOps

Sağlayıcı kimliğini yetkilendirmeden ayırın.

Tanınmış bir sağlayıcı bir güvenlik istisnası değildir. Şüphelenilen kötüye kullanımı doğrulayın ve kanıt eksik olduğunda belirsizliği koruyun.

Sonraki adımlar

  1. Sağlayıcı kimliğini yetkilendirmeden ayırın.
  2. İlgili olduğu durumlarda güvenliği ihlal edilmiş hesap olasılıklarını inceleyin.
  3. Desteklenmeyen altyapı istisnalarının süresinin dolmasını sağlayın.

Kurucu / Teknik Olmayan

Rotanın hangi işletme hesabına ait olduğunu sorun.

İşletme sahipliği ve posta kimlik doğrulaması farklı sorulara yanıt verir. Bir istisnayı onaylamadan önce her ikisini de zorunlu kılın.

Sonraki adımlar

  1. Rotanın hangi işletme hesabına ait olduğunu sorun.
  2. Sınıflandırılmamış trafiği onaylı envanterin dışında tutun.
  3. İstisnadan önce kanıt isteyin.

[ SSS ]

Sık sorulan sorular

1e100.net nedir?

Google bunu, ağındaki sunucuları adlandırmak için kullanılan bir alan adı olarak tanımlar.

Etiket, postanın Google hesabımızdan geldiği anlamına mı geliyor?

Hayır. Hesabınızı veya hizmet sahipliğinizi belirlemez.

Gözlemlenen IP'yi SPF eklemeli miyim?

Yalnızca bu ipucundan değil. Hizmeti doğrulayın ve desteklenen kimlik doğrulama yapılandırmasını kullanın.

Kontrol paneli adını nereden aldı?

Ters DNS , önbelleğe alınmış zenginleştirme mi yoksa sağlayıcı sınıflandırması mı kullandığını kontrol edin.

Google etiketli bir kaynak DMARC başarısız olabilir mi?

Evet. İlgili sonuç, görüntülenen sağlayıcı adına değil, kimlik doğrulamanın ve hizalamanın geçmesine bağlıdır.

Uyumlu DKIM güvenli içeriği kanıtlıyor mu?

Hayır. Bu, içeriğin istendiğini veya hesabın güvenliğinin ihlal edilmediğini göstermez.

Yararlı bir doğrulama testi nedir?

Gerçek şüpheli yoldan geçen, güvenilir bir alıcıda incelenen zararsız bir mesaj.

Çözümlenmemiş trafik nasıl kaydedilmelidir?

Yetki vermeden kanıtlarını, belirsizliğini, soruşturma sahibini ve belirli bir sonraki eylemini saklayın.

[ Kaynaklar ]

Kaynaklar

  1. RFC 9989 : DMARC çekirdek protokolü

    Bölümler §4.4 · §4.5 · §11

  2. RFC 9990 : DMARC toplu raporlama

    Bölümler §3.1.1

  3. Google Yardımı: 1e100.net nedir?

    Bölümler 1e100.net nedir?

  4. RFC 8601 : Authentication-Results güven sınırı

[ Sözlük ]

Sözlük

DMARC hizalaması
Görünür Kimden alan adı ile geçen SPF veya DKIM kimliği arasındaki gerekli ilişki. Sıkı uyum, tam bir alan adı eşleşmesi gerektirir; Rahat hizalama, uygulanabilir organizasyonel alan ilişkisini kullanır.
Yazar Alanı
DMARC değerlendirdiği, mesajın görünür Gönderen adresindeki alan adı.
DMARC
Etki Alanı Tabanlı Mesaj Kimlik Doğrulaması, Raporlama ve Uyumluluk, uyumlu kimlik doğrulamayı etki alanı sahibi politikası ve geri bildirimiyle birleştirir. Mesaj içeriğini onaylamaz veya teslimatı garanti etmez.
Toplu rapor
Bir alıcının bir raporlama aralığı için gruplandırılmış DMARC gözlemleri. Bir kuruluşun gönderdiği her mesajı temsil etmeyebilir.

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ı