Học và kiểm tra DMARC

 (learndmarc.com)
2 điểm bởi GN⁺ 2023-10-02 | 1 bình luận | Chia sẻ qua WhatsApp
  • LearnDMARC cho phép học và kiểm tra SPF, DKIM, DMARC — các thành phần cốt lõi của xác thực email — trên một màn hình, và phần giải thích trực quan tổng thể có thể xem trên máy tính để bàn
  • Màn hình kết quả trước tiên hiển thị thông tin kết nối như Source IP address, Hostname, Sender để xác định điểm khởi đầu cho việc đánh giá xác thực
  • SPF và DKIM lần lượt hiển thị domain mục tiêu xác thực và kết quả, đồng thời cho biết có Alignment hay không — yếu tố cần thiết để đánh giá DMARC
  • Khu vực DMARC gom RFC5322.From domain, Policy(p=), kết quả SPF, DKIM và nối chúng thành DMARC Result cuối cùng
  • Cuối cùng, có thể kiểm tra đánh giá tổng thể qua Final verdict, đồng thời có cung cấp tính năng ẩn danh hóa kết quả và liên kết học về DMARC

Mục đích của LearnDMARC

  • Đây là trang để học và kiểm tra SPF, DKIM, DMARC
  • Để xem phần giải thích trực quan toàn bộ về cách DMARC hoạt động, cần mở trang trên máy tính để bàn

Các mục có thể kiểm tra trên màn hình kết quả

  • 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

Phán định cuối cùng và các tính năng hỗ trợ

  • Màn hình kết quả hiển thị đánh giá tổng thể bằng Final verdict
  • Có thể ẩn danh hóa kết quả bằng Anonymize results
  • Có cung cấp liên kết Learn more about DMARC

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-10-02
Ý kiến trên Hacker News

  • Đây là một cách hay để thúc đẩy các dịch vụ email cốt lõi cần thiết nhằm giảm spam. Tôi luôn hy vọng rằng chỉ SPF, DKIM, DMARC thôi cũng đủ tạo động lực cho các công ty từng làm việc cùng, nhưng chỉ dựa vào uy tín thì thường chưa đủ để đưa khoản đầu tư này lên ưu tiên
    May mắn là với những công ty muốn giao tiếp đáng tin cậy với khách hàng, có một tiêu chuẩn mà marketer có thể thích: Brand Indicators for Message Identification(BIMI). Giờ không chỉ có bảo mật, mà còn có cả logo đẹp: https://www.litmus.com/blog/what-is-bimi-and-why-should-emai...
    Tôi từng dùng BIMI ở một số công ty với lý do “trải nghiệm khách hàng” để khiến họ triển khai DMARC cho đúng, tức là P=Reject

    • DMARC vẫn còn vấn đề. Tài liệu từ vài năm trước: https://i.blackhat.com/USA-20/Thursday/us-20-Chen-You-Have-N...
      Cả SPF lẫn DKIM đều không giải quyết triệt để việc chống giả mạo email. SPF xác thực định danh HELO/MAIL FROM, DKIM xác thực trường d= trong header DKIM-Signature, nhưng cả hai đều không xác thực header From hiển thị cho người dùng cuối. Vì vậy ngay cả khi vượt qua kiểm tra SPF và DKIM, địa chỉ From vẫn có thể bị giả mạo
      Việc một domain email không có DMARC+ rõ ràng là vấn đề, nhưng chỉ DMARC+ cũng không giải quyết được bài toán “có phải người gửi thật không”
    • Từ góc nhìn kẻ tấn công, tôi tự hỏi điều gì ngăn họ tạo một domain phishing dùng cùng logo rồi không thiết lập BIMI
    • BIMI chẳng phải tốn khoảng 1000 USD mỗi năm sao?

  • Tài liệu liên quan: xem tương tác cách DMARC, SPF, DKIM hoạt động - https://news.ycombinator.com/item?id=29869266 - Tháng 1/2022, 108 bình luận

  • Tôi muốn biết có cách mã nguồn mở, hoặc ít nhất là miễn phí, nào để xử lý báo cáo DMARC không
    Tôi có vài domain email đã bật SPF, DKIM, DMARC và chúng hoạt động, nhưng DMARC có hai vấn đề phiền phức
    (1) Một số site gửi báo cáo DMARC kiểu “bạn đã gửi 3 tin nhắn, tất cả đều bình thường và vượt qua mọi kiểm tra”
    (2) Thỉnh thoảng có những nỗ lực gửi spam bằng domain của tôi qua máy chủ khác, và tôi nhận được báo cáo rằng “ai đó đã đưa domain của bạn vào HELO/FROM để thử gửi spam, nhưng kiểm tra thất bại nên đã bị chặn”
    Cả hai đều vô dụng với tôi. Tôi không muốn biết rằng người dùng của tôi đã gửi thư tới @gmail.com hay @mail.ru, còn trong trường hợp thứ hai thì đó không phải IP máy chủ của tôi nên tôi cũng chẳng làm được gì
    Tự giải nén XML rồi kiểm tra quá rườm rà, nên nếu có bộ lọc hoặc dashboard thì sẽ rất hữu ích

  • Theo tôi biết, mô tả “để DMARC pass thì kiểm tra DKIM và/hoặc SPF phải pass và domain phải được căn chỉnh” là sai
    Không phải “and/or” mà là or. Chỉ cần một trong DKIM hoặc SPF pass là được, và không có cách nào yêu cầu cả hai

    • Gần đây đã có vấn đề liên quan đến việc hợp tác giữa Cloudflare và MailChannels về chuyện này, và có thể giả mạo email
      Vấn đề cơ bản là MailChannels không yêu cầu xác thực. Cloudflare Workers có thể gọi endpoint API của MailChannels để gửi email, và MailChannels yêu cầu thêm bản ghi include: vào chính sách SPF. Kết quả là MailChannels trở thành người gửi hợp lệ cho mọi domain, khiến bất kỳ ai cũng có thể giả danh bất kỳ ai
      Trong số 2 triệu domain được host, chỉ khoảng 400 domain thiết lập DKIM, nhưng ngay cả khi có DKIM thì chỉ cần SPF pass là DMARC cũng pass
      [1] https://blog.cloudflare.com/sending-email-from-workers-with-...
    • Có vẻ bạn đang diễn giải sai cú pháp. Tôi cho rằng and/or ở đây nghĩa là OR bao hàm. “and” không nhất thiết có nghĩa là một lựa chọn khả dĩ
    • Không hiểu sao bị downvote, nhưng nói rằng chỉ or mới đúng là chính xác
    • Nếu dùng literal địa chỉ IP mà không trả tiền mua domain, bạn có thể có SPF miễn phí
      Chỉ cần trong trường From:/Reply-To: có địa chỉ email chứa literal địa chỉ IP là bạn có “SPF”, và nhận được điểm số tốt hơn nhiều để tránh greylisting trong giao dịch đầu tiên. Càng tốt hơn nếu phần thân không có URL
      Nhưng đây là kiến thức phổ thông

  • Tôi rất thích cách cho người ta làm theo quy trình một cách lặp đi lặp lại. Vài năm trước, khi ở công ty cũ tôi cố chuyển sang tự host việc gửi email kèm các biện pháp bảo mật đúng chuẩn, nếu có thứ như thế này thì đã giúp ích rất nhiều

  • Tôi gửi email bằng dịch vụ “Hide My Email” của Apple thì gặp lỗi: 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
    Lỗi xảy ra sau khi giao diện bắt đầu hiển thị “Here are the message headers and message body:” và DKIM-Signature: d=icloud.com s=1a1hai
    Đã hơn 1 năm kể từ khi trang web này được giới thiệu trên Hacker News, nên có vẻ mã JavaScript đã cũ và không còn hoạt động. Cũng có thể ngay từ đầu nó đã không hỗ trợ Safari, hoặc cả hai. Dù vậy, tôi đã học được rất nhiều từ phần đầu và phần thứ hai của bài kiểm thử DMARC, và có thể hình dung được chuyện gì sẽ xảy ra ở các bước tiếp theo
    [2] dig +noall +answer -t TXT | grep -i SPF
    [3] dig +noall +answer -t A

    • Khi kiểm thử email giả mạo, Chrome cũng báo cùng lỗi
      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
      Trong lúc nhập, câu kiểu “không cần viết hẳn thư tình đâu” khá buồn cười. Có thể tôi nhầm, nhưng có vẻ trong phần dữ liệu phải lặp lại các header From: và To:
      Nghĩ lại trong nhiều năm tôi đã gửi bao nhiêu email với HELO there thay vì hostname vẫn thấy buồn cười. Tôi cũng tò mò không biết Enter message, ending with . on a line by itself chiếm tỷ lệ bao nhiêu trong lưu lượng Internet
    • Lỗi xảy ra vì email được gửi không có trường from. Chỉ là lập trình viên không nghĩ tới việc kiểm thử trường hợp người dùng xấu làm chuyện xấu, không có âm mưu đặc biệt nào cả
    • DMARC phụ thuộc vào địa chỉ RFC5322.From, nên nếu thiếu địa chỉ này sẽ phát sinh lỗi. Để tránh lỗi như vậy, hiện nay các email không có địa chỉ đó đang bị bỏ qua

  • Thật đáng kinh ngạc khi đến thế kỷ 21 chúng ta vẫn dựa vào từng lớp compatibility layer và hack chồng lên nhau để vận hành một công nghệ từng phù hợp với thiện chí và lý tưởng cách đây khoảng 30 năm
    Mảng VOIP/viễn thông cũng tương tự
    Microsoft gần đây cũng gặp vấn đề về khả năng gửi mail vào hộp thư đến, và phần lớn tenant O365 của chúng tôi nhận được thông báo yêu cầu kiểm tra SPF, DKIM, DMARC. Chúng tôi vốn đã cấu hình đúng, nhưng một số tenant gặp vấn đề khi gửi mail tới các nhà cung cấp email nhỏ (cỡ ISP). Lý do là spam phát ra từ cùng địa chỉ IP hoặc máy chủ mail, nên các nhà cung cấp nhỏ đang chặn toàn bộ IP và dải IP

  • Sự thật thú vị: sns.amazonaws.com vẫn chưa có bản ghi DMARC. Nếu không dùng domain tùy chỉnh, các tin nhắn AWS SNS đến từ đây, và mọi cảnh báo CloudWatch cũng đến từ no-reply@sns.amazonaws.com

  • Email vốn nên hoạt động như vậy, nhưng thực tế có danh sách cho phép

    • Và cũng có danh sách chặn. Có những danh sách chặn mang tính săn mồi, và có những danh sách chặn chẳng khác nào tống tiền có tổ chức
    • Tôi không biết danh sách cho phép này dùng cho việc gì. Việc định sẵn danh sách cho phép các domain có thể gửi tới domain của mình không phổ biến. Làm vậy sẽ phá vỡ mục đích của email

  • Ngay cả khi DNS failover cũng đừng quên thiết lập đúng các kiểm tra kiểu này
    Tôi từng thấy một công ty bị lừa vì dùng cấu hình mặc định của Exchange Online
    Khi kẻ tấn công tạm thời làm DNS ở trạng thái “không khả dụng”, tất cả email phishing đều lọt qua. Vì máy chủ MS trả về DNS temp error và cho toàn bộ email đi qua như không phải spam
    Cụ thể là received-spf: TempError (protection.outlook.com: error in processing during lookup of : DNS Timeout), còn DKIM được kiểm tra trên domain máy chủ SMTP của người gửi, trong trường hợp này là máy chủ của kẻ tấn công dùng để phishing
    Sau đó tôi đã có một khoảng thời gian tuyệt vời với bộ phận hỗ trợ IT/bảo mật của MS, nơi những người ở đó thậm chí còn không hiểu email hoạt động như thế nào. Đó là một trải nghiệm vừa rất buồn cười vừa đáng buồn, và tôi hy vọng việc outsource phù hợp với họ