2 puan yazan GN⁺ 2023-10-02 | 1 yorum | WhatsApp'ta paylaş
  • 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

1 yorum

 
GN⁺ 2023-10-02
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=Reject ile uygulanmasını sağladım.

    • DMARC’ın da hâlâ sorunları var. Birkaç yıl öncesinden bir kaynak: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      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österilen From başlığını doğrulamaz. Bu yüzden SPF ve DKIM doğrulamasından geçilse bile From adresi 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.
    • Saldırgan açısından, aynı logoyu kullanan bir phishing alan adı oluşturup BIMI’yi ayarlamayı neyin engellediğini merak ediyorum.
    • BIMI yılda yaklaşık 1000 dolar tutmuyor mu?
  • İ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.

  • “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.

    • Bununla ilgili olarak Cloudflare ile MailChannels ortaklığında yakın zamanda bir sorun yaşandı ve e-posta spoofing’i mümkün oldu.
      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-...
    • Sanırım sözdizimini yanlış yorumlamışsınız. Buradaki and/or’un kapsayıcı OR anlamına geldiğini düşünüyorum. “and”in mutlaka mümkün bir seçenek olduğu anlamına gelmiyor.
    • Neden downvote aldığımı bilmiyorum ama yalnızca or doğrudur demek doğru.
    • Alan adı ücreti ödemeden IP adresi literal’i kullanırsanız SPF’yi ücretsiz elde edebilirsiniz.
      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:32767
    Arayüz “Here are the message headers and message body:” ile DKIM-Signature: d=icloud.com s=1a1hai göstermeye başladıktan sonra oldu
    Bu 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 A

    • Sahte e-postayı test ederken Chrome’da da aynı hata çıkıyor
      telnet learndmarc.com 25
      Trying 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 +0000
      HELO there
      250 allspark.uriports.com Hello []
      MAIL From: me@example.com
      250 OK
      RCPT To: ld-49101f55f6@learndmarc.com
      250 Accepted
      DATA
      354 Enter message, ending with "." on a line by itself
      .
      250 OK id=1qn4QF-00CUhd-5j
      Yazarken “aşk mektubu yazmana gerek yok” tarzında olması komikti. Yanılıyor olabilirim ama veri bölümünde From: ve To: başlıklarını tekrar etmek gerekiyor gibi
      Yı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 itself ifadesinden oluştuğunu da merak ediyorum
    • from alanı 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 yok
    • DMARC, RFC5322.From adresine dayanır; bu adres eksikse hata verir. Bu tür hatalardan kaçınmak için şu anda bu adresi olmayan e-postaları yok sayıyoruz
  • Yaklaşı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.com adresinden gelir

  • E-posta aslında böyle çalışmalı, ama gerçekte izin listeleri var

    • Bir de engelleme listeleri var. Yırtıcı engelleme listeleri de var, örgütlü haraçtan farksız olan engelleme listeleri de var
    • Neyin izin listesi olduğunu bilmiyorum. Benim alan adıma gönderebilecek alan adlarını önceden izin listesine almak yaygın değil. Böyle yaparsan e-postanın amacı çöker
  • 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 error ile 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 sunucusuydu
    Sonrası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