DMARC öğrenimi ve testi
(learndmarc.com)- LearnDMARC, e-posta kimlik doğrulamasının temeli olan SPF, DKIM, DMARC konularını tek ekranda öğrenip test etmeyi sağlar; genel görsel açıklama masaüstünde görüntülenebilir
- Sonuç ekranı önce Source IP address, Hostname, Sender gibi bağlantı bilgilerini göstererek kimlik doğrulama değerlendirmesinin başlangıç noktasını görmeyi sağlar
- SPF ve DKIM, ayrı ayrı kimlik doğrulama hedef alan adını ve sonucu gösterir; ayrıca DMARC değerlendirmesi için gerekli Alignment durumunu da ortaya koyar
- DMARC bölümü, RFC5322.From domain ile Policy(p=), SPF, DKIM sonuçlarını bir araya getirerek nihai DMARC Result'a bağlar
- Son olarak Final verdict ile genel değerlendirme görülebilir; ayrıca sonuç anonimleştirme ve DMARC öğrenme bağlantısı da sunulur
LearnDMARC'nin amacı
- SPF, DKIM, DMARC öğrenmek ve test etmek için hazırlanmış bir sayfadır
- DMARC'ın nasıl çalıştığına dair genel görsel açıklamayı görmek için siteyi masaüstünde açmak gerekir
Sonuç ekranında kontrol edilen öğeler
-
Connection parameters
- Source IP address
- Hostname
- Sender
-
SPF
- Domain
- Identity
- Auth Result
- DMARC Alignment
-
DKIM
- Domain
- Selector
- Algorithm
- Auth Result
- DMARC Alignment
-
DMARC
- RFC5322.From domain
- Policy(p=)
- SPF
- DKIM
- DMARC Result
Nihai değerlendirme ve yardımcı işlevler
- Sonuç ekranı, genel kararı Final verdict ile gösterir
- Anonymize results ile sonuçlar anonimleştirilebilir
- DMARC hakkında daha fazla bilgi edinin bağlantısı sunulur
1 yorum
Hacker News yorumları
Spam’i azaltmak için gereken temel e-posta hizmetlerini zorlamanın iyi bir yolu. Birlikte çalıştığım şirketlerde SPF, DKIM ve DMARC’ın tek başına yeterli motivasyon olmasını hep umdum, ama itibar tek başına yatırımı önceliklendirmek için çoğu zaman yetersiz kalıyor.
Neyse ki müşterileriyle güvenilir biçimde iletişim kurmak isteyen şirketler için pazarlamacıların hoşuna gidecek bir standart var: Brand Indicators for Message Identification(BIMI). Artık yalnızca güvenlik kazanmıyorsunuz, güzel bir logo da kazanıyorsunuz: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
Birkaç şirkette “müşteri deneyimi” gerekçesiyle BIMI’den yararlanarak DMARC’ın doğru şekilde, yani
P=Rejectile uygulanmasını sağladım.SPF de DKIM de e-posta spoofing’ini önlemeyi tamamen çözmüyor. SPF, HELO/MAIL FROM tanımlayıcılarını doğrular; DKIM ise DKIM-Signature başlığındaki
d=alanını doğrular, ancak ikisi de son kullanıcıya gösterilenFrombaşlığını doğrulamaz. Bu yüzden SPF ve DKIM doğrulamasından geçilse bileFromadresi hâlâ sahte olabilir.Bir e-posta alan adında DMARC+ olmaması açıkça bir sorun, ancak DMARC+ tek başına “gerçek gönderen bu mu” sorununu çözmüyor.
İlgili kaynak: DMARC, SPF ve DKIM’in nasıl çalıştığını etkileşimli olarak görmek - https://news.ycombinator.com/item?id=29869266 - Ocak 2022, 108 yorum
DMARC raporlarını işlemek için açık kaynak ya da en azından ücretsiz bir yöntem bilen var mı merak ediyorum.
SPF, DKIM ve DMARC’ı etkinleştirdiğim birkaç e-posta alan adım var ve çalışıyorlar, ancak DMARC’ta iki can sıkıcı sorun var.
(1) Bazı siteler “3 mesaj gönderdiniz, hepsi normal ve tüm kontrollerden geçti” gibi DMARC raporları gönderiyor.
(2) Bazen başka sunucular üzerinden benim alan adımla spam gönderme girişimleri oluyor ve “birileri HELO/FROM’a sizin alan adınızı koyarak spam denedi, ama kontroller başarısız olduğu için engellendi” şeklinde rapor alıyorum.
İkisi de benim için işe yaramıyor. Kullanıcımın @gmail.com veya @mail.ru adresine e-posta gönderdiğini bilmek istemiyorum; ikinci durumda da benim sunucumun IP’si olmadığı için yapabileceğim bir şey yok.
XML’i elle açıp kontrol etmek fazla zahmetli, bu yüzden filtreler ya da bir pano çok faydalı olurdu.
Rapor özetini ve hata ayrıntılarını gösteriyor. Çok gelişmiş değil, ama genişletmek için yeterince basit olmalı. SMTP-TLS raporlarını da ayrıştırıyor.
“DMARC’ın geçmesi için DKIM ve/veya SPF kontrollerinin geçmesi ve alan adının hizalanması gerekir” açıklaması bildiğim kadarıyla yanlış.
“and/or” değil, or. DKIM veya SPF’den yalnızca birinin geçmesi yeterli; ikisini birden zorunlu kılmanın bir yolu yok.
Temel sorun, MailChannels’ın kimlik doğrulama istememesiydi. Cloudflare Workers, e-posta göndermek için MailChannels’ın API endpoint’ini çağırabiliyordu ve MailChannels, SPF politikasına bir
include:kaydı eklenmesini istiyordu. Sonuç olarak MailChannels tüm alan adları için geçerli bir gönderici haline geldi ve herkes herkesin kimliğine bürünebilir oldu.Barındırılan 2 milyon alan adından yalnızca yaklaşık 400’ünde DKIM ayarlanmıştı; ama DKIM olsa bile yalnızca SPF’nin geçmesi DMARC’ın geçmesi için yeterliydi.
[1] https://blog.cloudflare.com/sending-email-from-workers-with-...
From:/Reply-To:alanlarında IP adresi literal’i içeren bir e-posta adresi olması “SPF” elde etmenizi sağlar ve ilk işlemde greylisting’e takılmamak için çok daha iyi bir puan alırsınız. Gövdede URL yoksa daha da iyi.Ama bu zaten bilinen bir şey.
Süreci tekrarlı şekilde izleten yaklaşım gerçekten hoşuma gitti. Birkaç yıl önce önceki şirketimde doğru güvenlik önlemleriyle birlikte kendi barındırdığımız e-posta gönderimine geçmeye çalışırken böyle bir şey olsaydı çok yardımcı olurdu.
Apple’ın “Hide My Email” servisine e-posta gönderince hata verdi: https://support.apple.com/en-us/HT210425
Unhandled Promise Rejection:TypeError: a.from.replace(/[<]/gi," is not a function. (In 'a.from.replace(/[<]/gi,"(")', 'a.from.replace(/[<]/gi,"' is undefined)dist.min.js:3:32767Arayüz “Here are the message headers and message body:” ile
DKIM-Signature: d=icloud.com s=1a1haigöstermeye başladıktan sonra olduBu web sitesi Hacker News’te tanıtılalı bir yıldan fazla olduğuna göre, JavaScript kodu eskimiş ve artık çalışmaz hâle gelmiş gibi. Başından beri Safari’yi desteklemiyor da olabilir, ikisi birden de olabilir. Yine de DMARC testinin birinci ve ikinci bölümlerinden çok şey öğrendim; sonraki adımlarda ne olacağına dair fikir edinebildim
[2]
dig +noall +answer -t TXT | grep -i SPF[3]
dig +noall +answer -t Atelnet learndmarc.com 25Trying 87.239.13.42...Connected to learndmarc.com.Escape character is '^]'.220 allspark.uriports.com ESMTP URIports Mail Portal 1.03.2 Sun, 01 Oct 2023 21:55:40 +0000HELO there250 allspark.uriports.com Hello []MAIL From: me@example.com250 OKRCPT To: ld-49101f55f6@learndmarc.com250 AcceptedDATA354 Enter message, ending with "." on a line by itself.250 OK id=1qn4QF-00CUhd-5jYazarken “aşk mektubu yazmana gerek yok” tarzında olması komikti. Yanılıyor olabilirim ama veri bölümünde
From:veTo:başlıklarını tekrar etmek gerekiyor gibiYıllar boyunca ana makine adı yerine HELO there ile kaç e-posta gönderdiğimi düşününce hâlâ gülüyorum. Ayrıca internet trafiğinin ne kadarının
Enter message, ending with . on a line by itselfifadesinden oluştuğunu da merak ediyorumfromalanı olmadan e-posta gönderdiği için bozulmuş. Programcı sadece kötü bir kullanıcının kötü şeyler yaptığı durumu test etmeyi düşünmemiş; özel bir komplo yokYaklaşık 30 yıl önce iyi niyetlere ve ideallere uygun olan bir teknolojiyi 21. yüzyılda çalıştırmak için katman katman uyumluluk katmanı ve hack üzerine yaslanmamız gerçekten şaşırtıcı
VOIP/telekom tarafı da aynı
Microsoft da yakın zamanda e-posta teslim edilebilirliği sorunları yaşadı ve O365 tenant’larımızın çoğunda SPF, DKIM, DMARC’ı kontrol etmemizi söyleyen bildirimler çıktı. Bizde zaten doğru yapılandırılmıştı, ama bazı tenant’larda küçük e-posta sağlayıcılarına (ISS düzeyi) e-posta gönderirken sorun vardı. Çünkü aynı IP adresinden veya posta sunucusundan spam çıktığı için küçük sağlayıcılar IP’yi ve IP aralıklarını komple engelliyordu
Eğlenceli bilgi: sns.amazonaws.com için hâlâ DMARC kaydı yok. Özel alan adı kullanmazsanız AWS SNS mesajları buradan gelir ve tüm CloudWatch uyarıları da
no-reply@sns.amazonaws.comadresinden gelirE-posta aslında böyle çalışmalı, ama gerçekte izin listeleri var
DNS failover durumunda da bu kontrolleri düzgün ayarlamayı unutmamak gerekir
Exchange Online’ın varsayılan ayarlarını kullandığı için dolandırılan bir şirket gördüm
Saldırgan DNS’i kısa süreliğine “kullanılamaz” hâle getirince tüm phishing e-postaları geçti. Çünkü MS sunucusu DNS
temp errorile yanıt verdi ve tüm e-postaları spam değilmiş gibi içeri aldıAyrıntı olarak
received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout)idi; DKIM ise gönderenin SMTP sunucusu alan adında kontrol ediliyor, bu örnekte de phishing için kullanılan saldırganın sunucusuyduSonrasında MS IT/güvenlik desteğiyle harika vakit geçirdik; oradakiler e-postanın nasıl çalıştığını bile anlamıyordu. Çok komik ama bir o kadar da üzücü bir deneyimdi; dış kaynak kullanımının onlar için iyi sonuç vermesini umarım