เรียนรู้และทดสอบ DMARC

 (learndmarc.com)
2 คะแนน โดย GN⁺ 2023-10-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • LearnDMARC เป็นเครื่องมือที่ช่วยให้เรียนรู้และทดสอบ SPF, DKIM, DMARC ซึ่งเป็นแกนหลักของการยืนยันตัวตนอีเมลได้ในหน้าจอเดียว และสามารถดูคำอธิบายภาพรวมแบบภาพได้บนเดสก์ท็อป
  • หน้าจอผลลัพธ์จะแสดงข้อมูลการเชื่อมต่อก่อน เช่น Source IP address, Hostname, Sender เพื่อให้ตรวจสอบจุดตั้งต้นของการตัดสินผลการยืนยันตัวตน
  • SPF และ DKIM จะแสดงโดเมนเป้าหมายของการยืนยันตัวตนและผลลัพธ์ของแต่ละรายการ พร้อมแสดงสถานะ Alignment ที่จำเป็นต่อการตัดสิน DMARC
  • ส่วน DMARC จะรวม RFC5322.From domain, Policy(p=), ผลลัพธ์ SPF, DKIM แล้วเชื่อมโยงไปยัง DMARC Result สุดท้าย
  • ท้ายสุดสามารถตรวจสอบการตัดสินโดยรวมผ่าน Final verdict และยังมีฟังก์ชันทำให้ผลลัพธ์ไม่ระบุตัวตน รวมถึงลิงก์สำหรับเรียนรู้ DMARC เพิ่มเติม

จุดประสงค์ของ LearnDMARC

  • เป็นหน้าสำหรับเรียนรู้และทดสอบ SPF, DKIM, DMARC
  • หากต้องการดูคำอธิบายภาพรวมแบบภาพของวิธีการทำงานของ DMARC ต้องเปิดไซต์บน เดสก์ท็อป

รายการที่ตรวจสอบได้ในหน้าจอผลลัพธ์

  • Connection parameters

    • Source IP address
    • Hostname
    • Sender

  • SPF

    • Domain
    • Identity
    • Auth Result
    • DMARC Alignment

  • DKIM

    • Domain
    • Selector
    • Algorithm
    • Auth Result
    • DMARC Alignment

  • DKIM

    • Domain
    • Selector
    • Algorithm
    • Auth Result
    • DMARC Alignment

  • DMARC

    • RFC5322.From domain
    • Policy(p=)
    • SPF
    • DKIM
    • DMARC Result

การตัดสินสุดท้ายและฟังก์ชันเสริม

  • หน้าจอผลลัพธ์จะแสดงการตัดสินโดยรวมด้วย Final verdict
  • สามารถทำให้ผลลัพธ์ไม่ระบุตัวตนได้ด้วย Anonymize results
  • มีลิงก์ Learn more about DMARC ให้ใช้งาน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-10-02
ความคิดเห็นจาก Hacker News

  • เป็นแนวทางที่ดีในการผลักดันบริการอีเมลหลักที่จำเป็นต่อการลดสแปม ผม/ฉันเคยหวังมาตลอดว่าแค่ SPF, DKIM, DMARC ก็น่าจะเป็นแรงจูงใจเพียงพอสำหรับบริษัทต่าง ๆ ที่เคยร่วมงานด้วย แต่บ่อยครั้งแค่ ชื่อเสียง ยังไม่พอที่จะทำให้การลงทุนนี้ถูกจัดลำดับความสำคัญ
    โชคดีที่สำหรับบริษัทที่ต้องการสื่อสารกับลูกค้าอย่างน่าเชื่อถือ มีมาตรฐานที่นักการตลาดน่าจะชอบคือ Brand Indicators for Message Identification(BIMI) ตอนนี้ไม่ได้ได้แค่ความปลอดภัย แต่ยังได้โลโก้สวย ๆ ด้วย: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
    เคยใช้ BIMI เป็นข้ออ้างเรื่อง “ประสบการณ์ลูกค้า” เพื่อผลักดันให้หลายบริษัทนำ DMARC ไปใช้ให้ถูกต้อง นั่นคือ P=Reject

    • DMARC เองก็ยังมีปัญหาอยู่ เอกสารเมื่อไม่กี่ปีก่อน: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      ทั้ง SPF และ DKIM ไม่ได้แก้ปัญหาการป้องกันอีเมลสปูฟได้อย่างสมบูรณ์ SPF ยืนยันตัวระบุ HELO/MAIL FROM และ DKIM ยืนยันฟิลด์ d= ในเฮดเดอร์ DKIM-Signature แต่ทั้งสองอย่างไม่ได้ยืนยันเฮดเดอร์ From ที่แสดงต่อผู้ใช้ปลายทาง ดังนั้นแม้จะผ่านการตรวจสอบ SPF และ DKIM แล้ว ที่อยู่ From ก็ยังถูกปลอมแปลงได้อยู่
      การที่โดเมนอีเมลไม่มี DMARC+ นั้นเป็นปัญหาแน่นอน แต่ DMARC+ เพียงอย่างเดียวก็ยังไม่แก้ปัญหา “เป็นผู้ส่งตัวจริงหรือไม่”
    • ในมุมของผู้โจมตี อยากรู้ว่าอะไรจะขวางไม่ให้สร้าง โดเมนฟิชชิง ที่ใช้โลโก้เดียวกันแล้วตั้งค่า BIMI ได้
    • BIMI ไม่ใช่ว่าต้องเสียราว ๆ 1000 ดอลลาร์ ต่อปีหรือ?

  • แหล่งข้อมูลที่เกี่ยวข้อง: ดูแบบอินเทอร์แอคทีฟว่า DMARC, SPF, DKIM ทำงานอย่างไร - https://news.ycombinator.com/item?id=29869266 - มกราคม 2022, ความคิดเห็น 108 รายการ

  • อยากรู้ว่ามีวิธี โอเพนซอร์ส หรืออย่างน้อยก็ฟรีสำหรับประมวลผลรายงาน DMARC หรือไม่
    มีโดเมนอีเมลอยู่หลายโดเมนที่เปิด SPF, DKIM, DMARC แล้ว และก็ทำงานได้ แต่ DMARC มีเรื่องน่ารำคาญอยู่สองอย่าง
    (1) บางไซต์ส่งรายงาน DMARC ประมาณว่า “คุณส่งข้อความ 3 ฉบับ ทั้งหมดปกติ และผ่านการตรวจสอบทั้งหมด”
    (2) บางครั้งมีความพยายามส่งสแปมด้วยโดเมนของผม/ฉันผ่านเซิร์ฟเวอร์อื่น แล้วได้รับรายงานว่า “มีคนใส่โดเมนของคุณใน HELO/FROM เพื่อพยายามส่งสแปม แต่การตรวจสอบล้มเหลวจึงถูกบล็อก”
    ทั้งสองอย่างไม่มีประโยชน์สำหรับผม/ฉัน ไม่ได้อยากรู้ว่าผู้ใช้ของผม/ฉันส่งเมลไปยัง @gmail.com หรือ @mail.ru และกรณีที่สองก็ไม่ใช่ IP ของเซิร์ฟเวอร์ผม/ฉัน จึงทำอะไรไม่ได้
    การแกะ XML เองแล้วตรวจดูนั้นยุ่งยากเกินไป ดังนั้นถ้ามี ฟิลเตอร์หรือแดชบอร์ด ก็น่าจะมีประโยชน์มาก

    • มีสคริปต์ที่ทำไว้ใช้เอง: https://github.com/hannob/rpter
      แสดงสรุปรายงานและรายละเอียดความล้มเหลว ไม่ได้ซับซ้อนมาก แต่ก็น่าจะเรียบง่ายพอให้ขยายต่อได้ และยังพาร์สรายงาน SMTP-TLS ด้วย
    • เคยกดดาว parsedmarc(https://github.com/domainaware/parsedmarc) ไว้เผื่อดูทีหลัง แต่ยังไม่ได้ลองใช้เอง
    • dmarcian มีแพ็กเกจ personal ฟรี: https://dmarcian.com/pricing/

  • คำอธิบายที่ว่า “เพื่อให้ DMARC ผ่าน การตรวจสอบ DKIM และ/หรือ SPF ต้องผ่าน และโดเมนต้องสอดคล้องกัน” ตามที่ผม/ฉันรู้มานั้นไม่ถูกต้อง
    ไม่ใช่ “and/or” แต่เป็น or ผ่านแค่อย่างใดอย่างหนึ่งระหว่าง DKIM หรือ SPF ก็พอ และไม่มีวิธีบังคับให้ต้องผ่านทั้งคู่

    • เกี่ยวกับเรื่องนี้ เมื่อไม่นานมานี้เกิดปัญหาในความร่วมมือระหว่าง Cloudflare กับ MailChannels และทำให้สปูฟอีเมลได้
      ปัญหาพื้นฐานคือ MailChannels ไม่ได้กำหนดให้ต้องยืนยันตัวตน Cloudflare Workers สามารถเรียก API endpoint ของ MailChannels เพื่อส่งอีเมลได้ และ MailChannels กำหนดให้เพิ่มระเบียน include: ใน SPF policy ผลคือ MailChannels กลายเป็นผู้ส่งที่ถูกต้องสำหรับทุกโดเมน ทำให้ใครก็ปลอมเป็นใครก็ได้
      ในบรรดาโดเมนที่โฮสต์อยู่ 2 ล้านโดเมน มีเพียงประมาณ 400 โดเมนที่ตั้งค่า DKIM แต่ถึงจะมี DKIM ก็ตาม แค่ SPF ผ่านก็ทำให้ DMARC ผ่าน แล้ว
      [1] https://blog.cloudflare.com/sending-email-from-workers-with-...
    • ดูเหมือนจะตีความไวยากรณ์ผิด ตรงนี้ and/or น่าจะหมายถึง OR แบบครอบคลุม ไม่ได้แปลว่า “and” เป็นตัวเลือกที่เป็นไปได้เสมอไป
    • ไม่รู้ว่าทำไมถึงโดน downvote แต่คำพูดที่ว่า มีแต่ or เท่านั้นที่ถูก นั้นถูกต้องแล้ว
    • ถ้าไม่จ่ายค่าโดเมนแล้วใช้ IP address literal ก็จะได้ SPF ฟรี
      แค่มีที่อยู่อีเมลที่มี IP address literal อยู่ในฟิลด์ From:/Reply-To: ก็จะได้ “SPF” และได้คะแนนดีกว่ามากเพื่อหลีกเลี่ยง greylisting ในทรานแซกชันแรก ถ้าในเนื้อหาไม่มี URL ก็ยิ่งดี
      แต่นี่เป็นเรื่องพื้นฐานอยู่แล้ว

  • ชอบมากกับวิธีที่ทำให้ ไล่ตามกระบวนการแบบวนซ้ำได้ ถ้ามีสิ่งนี้เมื่อหลายปีก่อน ตอนที่บริษัทเก่าพยายามย้ายไปส่งอีเมลแบบโฮสต์เองพร้อมมาตรการความปลอดภัยที่เหมาะสม คงช่วยได้มาก

  • เมื่อส่งอีเมลผ่านบริการ “Hide My Email” ของ Apple แล้วเกิดข้อผิดพลาด: 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
    เกิดขึ้นหลังจากอินเทอร์เฟซเริ่มแสดง “Here are the message headers and message body:” และ DKIM-Signature: d=icloud.com s=1a1hai
    เว็บนี้ถูกนำไปแนะนำบน Hacker News มานานเกิน 1 ปีแล้ว ดูเหมือนว่าโค้ด JavaScript จะเก่าและใช้งานไม่ได้แล้ว หรืออาจไม่ได้รองรับ Safari ตั้งแต่แรก หรืออาจเป็นทั้งสองอย่าง ถึงอย่างนั้นก็ได้เรียนรู้อะไรมากจากส่วนแรกและส่วนที่สองของการทดสอบ DMARC และพอเดาได้ว่าขั้นตอนต่อ ๆ ไปจะเกิดอะไรขึ้น
    [2] dig +noall +answer -t TXT | grep -i SPF
    [3] dig +noall +answer -t A

    • ตอนทดสอบอีเมลปลอมก็เจอข้อผิดพลาดเดียวกันใน Chrome ด้วย
      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
      ระหว่างพิมพ์มีข้อความทำนองว่า “ไม่จำเป็นต้องเขียนจดหมายรักก็ได้” ซึ่งตลกดี อาจไม่ใช่ก็ได้ แต่ดูเหมือนว่าในช่วงข้อมูลต้องใส่ส่วนหัว From: และ To: ซ้ำอีกครั้ง
      พอนึกถึงจำนวนอีเมลที่ส่งมาตลอดหลายปีด้วย HELO there แทนชื่อโฮสต์ก็ยังขำอยู่ และก็สงสัยด้วยว่าในทราฟฟิกอินเทอร์เน็ตทั้งหมด สัดส่วนของ Enter message, ending with . on a line by itself จะมีมากแค่ไหน
    • มันพังเพราะส่งอีเมลโดยไม่มีฟิลด์ from เท่านั้นเอง โปรแกรมเมอร์แค่ไม่ได้คิดจะทดสอบกรณีที่ผู้ใช้ไม่ดีทำสิ่งไม่ดี ไม่ได้มีแผนลับอะไรเป็นพิเศษ
    • DMARC อาศัย ที่อยู่ RFC5322.From ดังนั้นถ้าไม่มีที่อยู่นี้ก็จะเกิดข้อผิดพลาด ตอนนี้จึงเพิกเฉยต่ออีเมลที่ไม่มีที่อยู่นั้นเพื่อเลี่ยงข้อผิดพลาดแบบนี้

  • น่าทึ่งจริง ๆ ที่เรายังพยายามเอาเทคโนโลยีซึ่งเมื่อราว 30 ปีก่อนสอดคล้องกับเจตนาดีและอุดมคติ มาใช้งานต่อในศตวรรษที่ 21 โดยต้องพึ่งพา ชั้นความเข้ากันได้และแฮ็ก ซ้อนกันเป็นชั้น ๆ
    ฝั่ง VOIP/โทรคมนาคมก็เหมือนกัน
    Microsoft ก็เพิ่งเจอปัญหาการส่งเมลถึงผู้รับ และใน O365 tenant ส่วนใหญ่ของเรามีการแจ้งเตือนให้ตรวจสอบ SPF, DKIM, DMARC เราตั้งค่าไว้อย่างถูกต้องอยู่แล้ว แต่ tenant บางส่วนมีปัญหาเมื่อส่งเมลไปยังผู้ให้บริการเมลรายเล็ก ๆ (ระดับ ISP) เพราะมีสแปมออกมาจาก IP address หรือ mail server เดียวกัน ผู้ให้บริการรายเล็กจึงบล็อกทั้ง IP และช่วง IP ไปเลย

  • เกร็ดน่าสนใจ: sns.amazonaws.com ยังไม่มี DMARC record ถ้าไม่ใช้ custom domain ข้อความ AWS SNS จะมาจากที่นี่ และการแจ้งเตือน CloudWatch ทั้งหมดก็มาจาก no-reply@sns.amazonaws.com

  • อีเมลควรทำงานแบบนี้ตั้งแต่แรก แต่ในความเป็นจริงมี allowlist อยู่

    • และก็มี blocklist ด้วย มีทั้ง blocklist แบบล่าเหยื่อ และ blocklist ที่แทบไม่ต่างจากการกรรโชกอย่างเป็นระบบ
    • ไม่รู้ว่า allowlist มีไว้เพื่ออะไร การกำหนด allowlist ล่วงหน้าว่าโดเมนไหนส่งมายังโดเมนของฉันได้ ไม่ใช่เรื่องที่พบได้ทั่วไป ถ้าทำแบบนั้นก็ทำลาย จุดประสงค์ของอีเมล ไปแล้ว

  • ต้องไม่ลืมตั้งค่าการตรวจสอบแบบนี้ให้ถูกต้องแม้ในกรณี DNS failover ด้วย
    เคยเห็นบริษัทหนึ่งถูกหลอกเพราะใช้ค่าเริ่มต้นของ Exchange Online
    พอผู้โจมตีทำให้ DNS อยู่ในสถานะ “ใช้งานไม่ได้” ชั่วคราว อีเมลฟิชชิงทั้งหมดก็ผ่านเข้ามา เพราะเซิร์ฟเวอร์ MS ตอบกลับด้วย DNS temp error และปล่อยให้อีเมลทั้งหมดผ่านโดยไม่ถือว่าเป็นสแปม
    รายละเอียดคือ received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout) ส่วน DKIM ถูกตรวจสอบกับโดเมน SMTP server ของผู้ส่ง ซึ่งในกรณีนี้คือเซิร์ฟเวอร์ของผู้โจมตีที่ใช้ทำฟิชชิง
    หลังจากนั้นได้ใช้เวลาอันยอดเยี่ยมกับฝ่ายสนับสนุน IT/ความปลอดภัยของ MS ซึ่งคนที่นั่นไม่เข้าใจด้วยซ้ำว่าอีเมลทำงานอย่างไร เป็นประสบการณ์ที่ทั้งตลกมากและน่าเศร้า และก็หวังว่าการเอาต์ซอร์สจะได้ผลดีกับพวกเขา