DMARC Không Phải Là Bộ Lọc Chống Lừa Đảo: Những Gì Nó Thực Sự Bảo Vệ

DMARC bị yêu cầu làm rất nhiều việc mà nó không được thiết kế để làm. Các đội ngũ sử dụng nó như một bộ lọc thư rác, bộ lọc chống lừa đảo, và tín hiệu tin cậy chung. Nó không phải là bất kỳ thứ nào trong số đó. Giao thức DMARC hiện tại, được định nghĩa trong RFC 9989, trả lời một câu hỏi hẹp một cách có chủ đích: chủ sở hữu của tên miền trong địa chỉ From hiển thị có ủy quyền cho thông điệp này không, và sự ủy quyền đó có thể được thiết lập thông qua kết quả SPF hoặc DKIM khớp không?

Câu hỏi đó đáng để trả lời. Nó cũng hẹp hơn nhiều so với danh tiếng mà DMARC đã có. Việc hiểu đúng ranh giới rất quan trọng, bởi vì một đội ngũ đạt p=reject tin rằng họ đã chống lừa đảo sẽ bỏ qua các biện pháp kiểm soát bao phủ mọi thứ mà DMARC để lại.

Email chứng minh ai đã gửi như thế nào

Ba thuật ngữ xuất hiện xuyên suốt, vì vậy đây là chúng bằng tiếng Việt đơn giản. SPF là danh sách công khai các máy chủ mà một tên miền cho phép gửi thư; người nhận kiểm tra xem thông điệp có thực sự đến từ một trong số chúng không. DKIM là chữ ký mật mã được thêm vào thông điệp, để người nhận có thể xác nhận nó thực sự đến từ tên miền ký và không bị can thiệp trong quá trình truyền. DMARC liên kết cả hai trở lại một thứ: địa chỉ From hiển thị.

Thuật ngữ cuối cùng này quan trọng hơn vẻ ngoài của nó. Mỗi email mang hai địa chỉ "từ". Một là From hiển thị, tên và địa chỉ mà ứng dụng thư của bạn hiển thị (ví dụ: "Ngân hàng của bạn <alerts@your-bank.com>"); đó là phần mà con người thực sự đọc và tin tưởng. Cái còn lại là địa chỉ phong bì ẩn được sử dụng hậu trường để gửi, mà bạn không bao giờ thấy. Kẻ tấn công có thể đặt hai giá trị này khác nhau, đó chính là cách một thông điệp có thể trông như từ ngân hàng của bạn trong khi được gửi thay mặt cho nơi khác. Công việc của DMARC là đảm bảo xác thực khớp với địa chỉ bạn có thể thấy, không phải địa chỉ ẩn.

Chúng trông như thế nào

Cả ba đều tồn tại dưới dạng bản ghi văn bản trong DNS của tên miền bạn, cùng nơi mà địa chỉ trang web của bạn được cấu hình. Bạn không cần phải nhớ cú pháp; nó giúp nhận ra hình dạng.

Bản ghi SPF liệt kê ai được phép gửi. Bản ghi này ủy quyền cho Google Workspace và một công cụ tiếp thị, và nói rằng bất kỳ thứ gì khác nên được coi là đáng ngờ:

example.com.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Các mục include: kéo vào danh sách máy chủ của từng nhà cung cấp, và -all có nghĩa là "nếu nó không nằm trong danh sách đó, nó không phải là chúng tôi".

Bản ghi DKIM công bố phần công khai của khóa ký, để người nhận có thể kiểm tra chữ ký trên thư của bạn. Chuỗi dài là chính khóa:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQ...AB"

Cuối cùng, bản ghi DMARC liên kết mọi thứ lại và cho người nhận biết phải làm gì khi một thông điệp thất bại. Bản ghi này yêu cầu họ từ chối các thất bại và gửi báo cáo cho bạn:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:reports@example.com"

p=reject ở đây là chính sách mà phần còn lại của bài viết này liên tục đề cập, và rua= là địa chỉ mà các báo cáo tổng hợp của bạn được gửi đến.

Cách một lần vượt qua thực sự được quyết định

DMARC nằm trên SPF và DKIM, và nó đánh giá chúng một cách độc lập. Có hai cách riêng biệt để một thông điệp có thể vượt qua: SPF vượt qua cho tên miền phong bì ẩn và tên miền đó khớp với tên miền From hiển thị, hoặc chữ ký DKIM xác thực và tên miền ký của nó khớp với tên miền From hiển thị. Nếu một trong hai đường dẫn khớp thành công, DMARC vượt qua. Nếu không, nó thất bại. "Khớp" chỉ đơn giản có nghĩa là hai tên miền khớp đủ chặt để được coi là cùng một tổ chức.

Khớp là phần mà hầu hết các giải thích bỏ qua, và đó là nơi có một chi tiết hữu ích, có thể xác minh. DMARC định nghĩa hai chế độ khớp. Trong chế độ nới lỏng (mặc định), hai tên miền chỉ cần chia sẻ cùng một tên miền tổ chức, vì vậy chữ ký DKIM từ mail.example.com khớp với From là example.com. Trong chế độ nghiêm ngặt, chúng phải giống hệt nhau, và cùng một chữ ký đó sẽ thất bại. Nếu bạn đã thấy "SPF pass, DMARC fail" và tự hỏi làm thế nào cả hai có thể đúng cùng một lúc, điều đó thường có nghĩa là SPF xác nhận tên miền phong bì ẩn thành công, nhưng tên miền đó không khớp với địa chỉ From hiển thị đủ chặt để khớp. Chế độ nghiêm ngặt so với nới lỏng sau đó quyết định liệu các tên miền liên quan chặt chẽ có được tính là giống nhau không.

Lưu ý những gì bài kiểm tra không bao giờ kiểm tra: nội dung, liên kết, tệp đính kèm, hoặc ý định của người gửi. Đây là kiểm tra nguồn gốc, không phải nội dung.

Nơi DMARC giúp ích

Trường hợp DMARC được xây dựng cho là giả mạo tên miền chính xác. Nếu ai đó đặt your-bank.com trong địa chỉ From mà không tạo ra kết quả SPF hoặc DKIM khớp, chính sách p=reject yêu cầu các nhà cung cấp tham gia từ chối thông điệp, mặc dù nhà cung cấp giữ quyền kiểm soát cuối cùng đối với việc xử lý và có thể áp dụng chính sách địa phương hoặc ngoại lệ. Đây là sự bảo vệ thực sự, và đối với cuộc tấn công cụ thể này, nó mạnh mẽ. Nó cũng cung cấp cho bạn thứ bạn chưa từng có: các báo cáo tổng hợp (được định nghĩa trong RFC 9990) tiết lộ nhiều hệ thống mà các nhà cung cấp tham gia đã quan sát gửi dưới tên miền của bạn, đó là cách bạn tìm thấy công cụ tiếp thị bị lãng quên hoặc relay cấu hình sai trước khi kẻ tấn công làm điều đó.

Nơi nó thiếu sót

Tên miền giả mạo. Kẻ tấn công đăng ký your-bank-support.com, thiết lập SPF và DKIM hợp lệ, và vượt qua DMARC trên tên miền của chúng. Chính sách của bạn không có quyền đối với tên miền bạn không sở hữu. Đối với mọi nhà cung cấp, thư đó được xác thực đầy đủ.

Giả mạo tên hiển thị. Tên hiển thị đọc "Your Bank Security" trong khi địa chỉ thực tế là alerts@some-unrelated-domain.com. DMARC xác thực tên miền, không phải tên thân thiện mà hầu hết mọi người thực sự đọc. Thông điệp có thể vượt qua và vẫn là giả mạo.

Hộp thư bị xâm nhập. Khi kẻ tấn công đăng nhập vào tài khoản thực thông qua thông tin đăng nhập bị lừa đảo và gửi qua nhà cung cấp hợp pháp, thông điệp thường sẽ vượt qua SPF, DKIM và DMARC bởi vì, theo thuật ngữ của giao thức, nó được gửi qua cơ sở hạ tầng được ủy quyền. Xác thực không thể phân biệt người dùng thực với kẻ tấn công kiểm soát tài khoản của người dùng đó.

Tên miền được xác thực nhưng độc hại. Bất kỳ ai cũng có thể đăng ký một tên miền và cấu hình xác thực hoàn hảo; những kẻ gửi thư không mong muốn làm điều này thường xuyên. Một lần vượt qua trên totally-legit-invoices.com xác nhận chủ sở hữu đã ủy quyền thư. Nó không nói gì về việc chủ sở hữu có trung thực hay không.

Thư rác và vị trí hộp thư đến. DMARC không phải là bộ lọc thư rác và không quyết định liệu thư có đến hộp thư đến hay không. Bộ lọc có thể coi nó là một đầu vào, nhưng thư rác được xác thực vẫn là thư rác, và vị trí là một hệ thống riêng với logic riêng của nó.

Chuyển tiếp và danh sách gửi thư. Các trung gian hợp pháp có thể phá vỡ xác thực. Chuyển tiếp thường phá vỡ SPF vì máy chủ chuyển tiếp không được ủy quyền bởi tên miền của người gửi ban đầu, trong khi danh sách gửi thư có thể sửa đổi chủ đề hoặc nội dung và làm mất hiệu lực DKIM. Do đó, một thông điệp hợp pháp có thể thất bại DMARC mặc dù không ai giả mạo người gửi. Đây là một lý do tại sao việc thực thi nên tuân theo giám sát và khắc phục cẩn thận thay vì chuyển đổi mù quáng sang p=reject.

Xác thực không phải là sự tin tưởng

Một lần vượt qua thiết lập một sự thật: tên miền trong địa chỉ From đã ủy quyền thông điệp này, thông qua SPF hoặc DKIM, với sự khớp. Sự thật đó chặn giả mạo tên miền chính xác và cung cấp cho bạn khả năng hiển thị ai gửi dưới tên bạn. Những gì nó không thiết lập là liệu thông điệp có trung thực hay an toàn để hành động. Đó là các thuộc tính của nội dung và ý định, và không có kiểm tra xác thực nào chạm đến chúng. Đáng để thẳng thắn về điều này, bởi vì các nhà cung cấp ngụ ý DMARC "ngăn chặn lừa đảo" khiến khách hàng của họ tiếp xúc với mọi danh mục trên.

Quan điểm của SenderLedger là hẹp hơn một cách có chủ đích: chúng tôi giúp bạn đạt được thực thi mà không phá vỡ thư hợp pháp, chứng minh người gửi nào là của bạn, và chấm dứt giả mạo tên miền chính xác. Mọi thứ vượt qua điều đó (giám sát tên miền giả mạo, phát hiện xâm nhập hộp thư, và phán đoán của con người) là một công việc riêng biệt, và giả vờ khác đi là cách các tên miền kết thúc ở p=reject với cảm giác an toàn sai lầm.