Mail Server’da DMARC Forensic Rapor Analizi

DMARC (Domain-based Message Authentication, Reporting, and Conformance), e-posta sunucularında kimlik doğrulama ve raporlama için kritik bir protokoldür. Mail sunucularında DMARC forensic raporları, aggregate raporlardan farklı olarak bireysel e-posta mesajlarının detaylı incelemesini sağlar. Bu raporlar, SPF, DKIM ve DMARC kontrollerinin sonuçlarını, gönderici IP’lerini ve politika uyumunu XML formatında sunar. Forensic rapor analizi, sahte e-postaları tespit etmek, politika ihlallerini anlamak ve güvenlik açıklarını kapatmak için vazgeçilmezdir. Kurumsal ortamda bu raporları düzenli incelemek, phishing saldırılarını minimize eder ve uyumluluğu artırır. Bu makalede, mail sunucularında DMARC forensic raporlarını adım adım analiz etmenin pratik yöntemlerini ele alacağız.

DMARC Forensic Raporunun Temel Yapısı

DMARC forensic raporları, standart bir XML şemasına göre yapılandırılmıştır. Raporun kök elementi <feedback> olup, içerdiği <report_metadata> bölümü raporun oluşturulma zamanını, gönderici organizasyonu ve rapor ID’sini barındırır. <policy_published> alanı domain sahibinin DMARC politikasını (none, quarantine veya reject) belirtir. <record> elementi ise incelenen tek bir e-posta mesajını temsil eder ve en kritik verileri içerir.

Record bölümünde <identifiers> altında <header_from> orijinal gönderici adresini, <source_ip> gönderici IP adresini gösterir. <auth_results> SPF ve DKIM sonuçlarını detaylandırır; örneğin, SPF “pass” ise IP’nin yetkili aralıkta olduğu anlaşılır. Bu yapı, mail sunucusu yöneticilerinin raporları Postfix, Exim veya Microsoft Exchange gibi sistemlerde entegre araçlarla (örneğin dmarcberater veya rrdmarc) otomatik parse etmesini sağlar. Raporu anlamak için XML’i JSON’a dönüştürmek veya görsel araçlar kullanmak verimliliği artırır.

Forensic Rapor Analiz Adımları

Raporu Toplama ve Ön İşleme

Forensic raporlar, DMARC uyumlu alıcı sunucular tarafından domain’in rua (aggregate) ve ruf (forensic) adreslerine gönderilir. Mail sunucunuzda Postfix kullanıyorsanız, dmarc-milter ile raporları /var/spool/dmarc dizinine yönlendirin. Raporları topladıktan sonra, xmllint veya Python’un xml.etree.ElementTree kütüphanesiyle doğrulayın. Örnek komut: xmllint –schema dmarc.xsd rapor.xml. Bu adım, hatalı raporları filtreler ve analiz için temiz veri sağlar. Günlük olarak cron job ile raporları arşivleyin ki, 48 saatlik forensic TTL’sini kaçırmayın.

Anahtar Alanları İnceleme ve Değerlendirme

<dkim> altında i= imza identity’si ve aspf (alignment strictness) değerlerini kontrol edin; “pass” durumunda domain uyumu sağlanmış demektir. <spf> domain ve scope ile SPF alignment’ı doğrulayın. <policy_evaluated> disposition’ı inceleyin: reject durumunda mesaj bloke edilmiş olmalıdır. IP’yi whois ile sorgulayın, örneğin 192.0.2.1 gibi adresler test IP’leridir. Bu inceleme, mail sunucunuzda fail2ban entegrasyonuyla IP bloklamayı tetikler ve tekrarlanan ihlalleri önler. Her record için pct (prosent) değerini not alın ki aggregate raporlarla çapraz doğrulama yapın.

Otomatik Araçlarla Derin Analiz

Manuel inceleme yerine rrdmarc veya parsedmarc gibi araçlar kullanın. Bu araçlar, raporları veritabanına (PostgreSQL) aktarır ve dashboard üzerinden görselleştirir. Örnek: parsedmarc kurulumu sonrası config.yml’de ruf raporlarını etkinleştirin. Dashboard’da volume grafikleri, fail oranları ve harita tabanlı IP dağılımları görünür hale gelir. Bu sayede, belirli bir subdomain’den gelen yüksek fail trafiğini saniyeler içinde tespit edersiniz. Araçlar ayrıca JSON export ile SIEM sistemlerine (Splunk) entegrasyon sağlar.

Yaygın Sorunlar ve Pratik Çözümler

Forensic raporlarda sık rastlanan sorunlar arasında DKIM alignment failure ve forwarder kaynaklı SPF fail yer alır. Forwarding sırasında envelope sender değişmezken header_from değişirse alignment bozulur; çözümü SRS (Sender Rewriting Scheme) etkinleştirmektir. Mail sunucunuzda OpenDKIM ile selector bazlı signing kurun ve DMARC p=reject’e geçmeden pct=100 test edin. Başka bir yaygın sorun, legacy MUA’ların (mail user agents) rapor göndermemesidir; bu durumda büyük sağlayıcılarla (Google, Microsoft) ruf anlaşması yapın.

Analiz sırasında şüpheli trafiği izole edin: <delivery_result> “reject” ise logları kontrol edin. Pratik takeaway: Haftalık rapor review rutini oluşturun, threshold’lar belirleyin (örneğin %5 fail üstü alarm). Bu yaklaşım, kurumsal mail sunucularında %90+ DMARC uyumuna ulaşmanızı sağlar. Ayrıca, multi-tenant ortamda subdomain bazlı politikalar uygulayın.

DMARC forensic rapor analizi, mail sunucularınızın güvenliğini proaktif yönetmenin anahtarıdır. Düzenli inceleme ve otomasyon ile sahte e-postaları erken tespit edip politika iyileştirmeleri yapabilirsiniz. Bu süreçleri uygulayarak, organizasyonunuzun e-posta altyapısını daha güvenli ve uyumlu hale getirin; uzun vadede operasyonel verimliliği artırın.