Loading...

Bài 62. Bảo mật email: SPF, DKIM, DMARC, BIMI và secure email gateway

Khóa học CompTIA Security+ SY0-801 · Phần 4: Vận hành bảo mật · Bài 62 · 🎯 Objective 4.1 · ⏱️ Đọc khoảng 18 phút · 🧪 Không cần lab · 📝 5 câu bài tập cuối bài

🎯 Mục tiêu bài học

  • Hiểu vì sao email dễ bị giả mạo người gửi và vì sao đây là cửa ngõ của phishing và BEC.
  • Phân biệt SPF, DKIM, DMARC: mỗi cái kiểm tra gì, công bố ở đâu, và hạn chế ra sao.
  • Đọc được các bản ghi DNS mẫu và biết lộ trình triển khai DMARC an toàn.
  • Hiểu vai trò của BIMI và secure email gateway (SEG).

📎 Vị trí trong đề thi: email là vector tấn công số một mà bạn đã gặp ở Bài 18 và Bài 22 (phishing, BEC). Bài này là phía phòng thủ. Ba cơ chế xác thực dựa trên DNS và dùng lại kiến thức chữ ký số và khóa công khai ở Bài 9 và Bài 10. Phần đọc header email để tìm dấu hiệu giả mạo sẽ được thực hành ở Bài 36.

💡 Liên hệ thực tế: thư giả mạo tên chị Lan

Một khách hàng của công ty chị Lan nhận được email có tên người gửi hiển thị là "Lan Nguyen", yêu cầu chuyển khoản gấp sang một tài khoản mới. Email trông giống thật, và domain trong địa chỉ người gửi trông giống domain của công ty. Khách hàng gần như đã chuyển tiền thì kịp gọi điện xác nhận. Công ty chị Lan chưa cấu hình bất kỳ cơ chế xác thực email nào cho domain của mình. Đây là tình huống minh họa, không phải vụ việc có thật.

Nam giải thích: "Giao thức gửi email gốc (SMTP) không kiểm tra người gửi có thật sự là người đó. Ai cũng có thể gõ bất kỳ địa chỉ vào ô From. Muốn chống giả mạo, chủ domain phải công bố trên DNS ai được phép gửi thư thay mặt domain, và người nhận phải kiểm tra theo công bố đó. Đó là việc của SPF, DKIM và DMARC."

🔐 Hình 62a. Ba lớp kiểm tra nối tiếp; DMARC tổng hợp kết quả và áp dụng chính sách của chủ domain.

📘 Kiến thức cốt lõi

📮 Vì sao email dễ giả mạo?

Một email có hai lớp địa chỉ người gửi: địa chỉ trong phong bì SMTP (envelope, MAIL FROM, còn gọi Return-Path), và địa chỉ trong tiêu đề thư (From:) mà người dùng nhìn thấy. Giao thức gốc không bắt buộc hai địa chỉ này khớp nhau hay có thật. Kẻ tấn công lợi dụng để mạo danh người quen, lãnh đạo hay thương hiệu (phishing, BEC), hoặc đăng ký domain gần giống (typosquatting, Bài 23) để đánh lừa mắt người đọc.

📋 SPF: ai được phép gửi thư cho domain?

SPF (Sender Policy Framework): chủ domain công bố trong DNS (bản ghi TXT) danh sách máy chủ/địa chỉ IP được phép gửi thư cho domain đó. Máy chủ nhận so sánh địa chỉ IP gửi với danh sách; không có trong danh sách thì thư bị coi là không hợp lệ theo SPF.

Ví dụ bản ghi SPF (dùng tên miền và IP ví dụ theo dải tài liệu):

congty-lan.example.  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.mailprovider.example -all"
  • ip4:203.0.113.10: cho phép địa chỉ IP này gửi.
  • include:...: kế thừa danh sách của nhà cung cấp dịch vụ email (ví dụ dịch vụ email đám mây).
  • Cuối bản ghi: -all nghĩa là từ chối (fail) những nguồn không được liệt kê; ~all là softfail (nghi ngờ nhưng thường vẫn nhận, đánh dấu).

Điểm cần nhớ và hạn chế:

  • SPF kiểm tra địa chỉ trong phong bì (MAIL FROM), không phải địa chỉ From: hiển thị. Vì vậy một mình SPF chưa chống được việc giả mạo địa chỉ mà người đọc nhìn thấy.
  • Mỗi domain chỉ nên có một bản ghi SPF; SPF còn bị giới hạn số lần tra cứu DNS (thường là 10).
  • Chuyển tiếp thư (forwarding) thường làm SPF thất bại vì IP gửi bây giờ là máy chủ chuyển tiếp.

✍️ DKIM: thư có được ký và còn nguyên vẹn?

DKIM (DomainKeys Identified Mail): máy chủ gửi ký số một số phần của thư (một số tiêu đề và nội dung) bằng khóa riêng; khóa công khai được công bố trong DNS. Máy chủ nhận dùng khóa công khai để xác minh chữ ký: nếu đúng thì thư đến từ hệ thống được domain ký ủy quyền và nội dung chưa bị sửa trên đường đi.

selector1._domainkey.congty-lan.example.  TXT  "v=DKIM1; k=rsa; p=<khóa công khai>"
  • Selector (selector1) cho phép một domain có nhiều khóa cùng lúc và xoay khóa an toàn.
  • Chữ ký DKIM nằm trong tiêu đề thư (DKIM-Signature), có chỉ rõ domain đã ký (d=) và selector (s=).
  • DKIM đảm bảo toàn vẹn và nguồn ký, và thường sống sót khi chuyển tiếp tốt hơn SPF. Hạn chế: domain ký trong chữ ký không bắt buộc trùng với domain trong From: nếu không có DMARC.

🧾 DMARC: chính sách và báo cáo dựa trên SPF và DKIM

DMARC (Domain-based Message Authentication, Reporting and Conformance) giải quyết khoảng trống ở trên. Nó yêu cầu SPF hoặc DKIM không chỉ đạt mà còn phải khớp (alignment) với domain trong From: mà người dùng nhìn thấy. Đồng thời, chủ domain công bố chính sách xử lý thư không đạt, và nhận báo cáo.

_dmarc.congty-lan.example.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@congty-lan.example"
ThẻÝ nghĩa
p Chính sách cho thư không đạt: none (chỉ giám sát), quarantine (cách ly, thường vào thư rác), reject (từ chối)
rua Địa chỉ nhận báo cáo tổng hợp (aggregate): ai đang gửi thư dưới tên domain của bạn, đạt hay không
ruf Địa chỉ nhận báo cáo từng thư lỗi (forensic); nhiều nhà cung cấp hạn chế gửi loại này vì lý do riêng tư
adkim, aspf Mức khớp domain: relaxed (r) cho phép subdomain khớp, strict (s) yêu cầu giống hệt
sp, pct Chính sách cho subdomain; tỉ lệ phần trăm thư áp dụng chính sách (để triển khai dần)

DMARC đạt khi ít nhất một trong hai điều sau đúng: SPF đạt và domain SPF khớp From:; hoặc DKIM đạt và domain ký khớp From:.

Một header kết quả mà máy chủ nhận ghi vào thư có dạng:

Authentication-Results: mx.example.net;
 spf=pass smtp.mailfrom=congty-lan.example;
 dkim=pass header.d=congty-lan.example;
 dmarc=pass header.from=congty-lan.example

Đọc dòng này là kỹ năng cơ bản khi phân tích email đáng ngờ (Bài 36). Thư giả mạo thường cho kết quả fail hoặc none ở một hoặc nhiều dòng.

🪜 Lộ trình triển khai DMARC an toàn

Đặt p=reject ngay từ đầu có thể chặn nhầm thư hợp lệ của chính bạn (thư gửi bởi nhà cung cấp marketing, hệ thống hóa đơn, phần mềm CRM chưa được khai báo trong SPF hoặc DKIM). Vì vậy nên đi từng bước:

BướcViệc làm
1. Kiểm kê Liệt kê mọi hệ thống gửi thư dưới tên domain: máy chủ email, dịch vụ marketing, phần mềm kế toán, hệ thống ticket...
2. Công bố SPF và DKIM Khai báo từng nguồn hợp lệ trong SPF; cấu hình ký DKIM cho từng nguồn
3. DMARC p=none Bật giám sát, đọc báo cáo rua vài tuần để tìm nguồn hợp lệ còn thiếu
4. Sửa các nguồn lỗi Bổ sung SPF/DKIM cho nguồn hợp lệ; xác định nguồn giả mạo
5. p=quarantine Tăng dần (có thể dùng pct) và theo dõi tác động
6. p=reject Chuyển sang chặn hẳn khi đã chắc chắn

Có thể kiểm tra bản ghi bằng lệnh tra cứu DNS, ví dụ:

bash

dig +short TXT congty-lan.example
dig +short TXT _dmarc.congty-lan.example
dig +short TXT selector1._domainkey.congty-lan.example

🖼️ BIMI: hiển thị logo thương hiệu

BIMI (Brand Indicators for Message Identification) cho phép hiển thị logo thương hiệu bên cạnh thư trong hộp thư của người nhận, khi thư đã được xác thực. Điều kiện nền tảng là domain đã bật DMARC ở mức thực thi (quarantine hoặc reject). Nhiều nhà cung cấp hộp thư còn yêu cầu chứng chỉ xác minh thương hiệu (như VMC hoặc CMC) và mỗi nhà cung cấp hỗ trợ khác nhau, nên cần kiểm tra điều kiện hiện hành của từng bên.

BIMI không phải biện pháp chống giả mạo trực tiếp: nó thưởng cho domain đã làm đúng DMARC bằng khả năng nhận diện thương hiệu, giúp người dùng dễ thấy thư thật.

🚪 Secure email gateway (SEG)

Secure email gateway là lớp lọc đứng trước hộp thư người dùng, kiểm tra thư đến (và đi) trước khi chuyển tiếp:

  • Kiểm tra SPF, DKIM, DMARC của thư đến.
  • Lọc spam và phishing dựa trên danh tiếng người gửi, nội dung, mẫu đã biết.
  • Quét mã độc trong tệp đính kèm, thường kèm sandbox (chạy thử tệp trong môi trường cô lập).
  • Kiểm tra URL, kể cả kiểm tra tại thời điểm bấm (click-time) vì đường link có thể bị đổi thành độc hại sau khi thư đã được nhận.
  • DLP (ngăn lộ dữ liệu nhạy cảm qua thư ra ngoài) và mã hóa thư theo chính sách.
  • Cách ly (quarantine) thư đáng ngờ để người quản trị xem xét.

Gateway có thể nằm ở đường đi của thư (thư đi qua gateway theo bản ghi MX), hoặc tích hợp qua API với dịch vụ email đám mây để kiểm tra thư sau khi đã vào hộp thư. Không có bộ lọc nào hoàn hảo, nên cần kết hợp với đào tạo nhận thức (Bài 102) và quy trình xác minh ngoài kênh cho yêu cầu chuyển tiền.

🚪 Hình 62b. Thư sạch vào hộp thư, thư đáng ngờ bị cách ly, thư độc hại bị chặn hoặc từ chối.

🔒 Mã hóa trong quá trình truyền

Ngoài xác thực, cần mã hóa kênh truyền giữa các máy chủ thư bằng TLS để tránh bị nghe lén (đã học ở Bài 49), và có thể dùng mã hóa đầu cuối cho thư nhạy cảm bằng S/MIME hoặc PGP, dựa trên chứng chỉ và khóa công khai (Bài 11). Những cơ chế này bảo vệ bí mật nội dung, khác với SPF, DKIM, DMARC bảo vệ nguồn gốc người gửi.

🎯 Mẹo làm bài: "Bản ghi DNS liệt kê địa chỉ IP/máy chủ được phép gửi thư cho domain" → SPF. "Chữ ký số trên thư, khóa công khai ở DNS, đảm bảo toàn vẹn" → DKIM. "Chính sách none/quarantine/reject, báo cáo, yêu cầu khớp domain From" → DMARC. "Hiển thị logo thương hiệu cho thư đã xác thực" → BIMI. "Lọc spam, phishing, mã độc, sandbox trước khi thư tới hộp thư" → secure email gateway. "Nên bắt đầu DMARC ở mức nào?" → p=none để giám sát, rồi mới siết dần. SPF kiểm tra phong bì (MAIL FROM), DMARC đòi khớp với From hiển thị.

🧠 Áp vào câu chuyện của Nam

Câu hỏi của chị LanKhái niệm trả lời
"Vì sao ai cũng giả được địa chỉ người gửi?" SMTP gốc không xác thực; cần SPF, DKIM, DMARC để chủ domain công bố và người nhận kiểm tra
"Làm sao nói với thế giới 'chỉ máy chủ này được gửi thư tên tôi'?" SPF: bản ghi TXT liệt kê nguồn được phép
"Làm sao chứng minh thư không bị sửa và đúng từ hệ thống của tôi?" DKIM: chữ ký số, khóa công khai ở DNS
"Thư giả mạo thì xử lý thế nào?" DMARC: đặt chính sách quarantine hoặc reject, nhận báo cáo
"Có nên bật reject ngay không?" Không: bắt đầu p=none, đọc báo cáo, sửa nguồn hợp lệ rồi mới siết
"Thư độc hại gửi tới nhân viên thì sao?" Secure email gateway lọc, sandbox và cách ly

📖 Thuật ngữ cần nhớ

Thuật ngữNghĩa
SPF Bản ghi DNS liệt kê nguồn được phép gửi thư cho domain.
DKIM Chữ ký số trên thư; khóa công khai nằm ở DNS.
DMARC Chính sách và báo cáo dựa trên SPF/DKIM, yêu cầu khớp với domain From.
Alignment Domain xác thực khớp với domain trong From: hiển thị.
MAIL FROM (envelope) Địa chỉ người gửi trong phong bì SMTP; SPF kiểm tra địa chỉ này.
p=none / quarantine / reject Chính sách DMARC: giám sát / cách ly / từ chối.
rua / ruf Địa chỉ nhận báo cáo tổng hợp / báo cáo từng thư lỗi.
BIMI Hiển thị logo thương hiệu cho thư đã xác thực.
Secure email gateway Lớp lọc thư trước hộp thư: spam, phishing, mã độc, DLP.
Sandbox Môi trường cô lập để chạy thử tệp đáng ngờ.

📌 Tóm tắt nhanh

  • Email dễ giả mạo vì SMTP gốc không xác thực người gửi; chống giả mạo dựa trên bản ghi DNS do chủ domain công bố.
  • SPF: ai được gửi (kiểm tra địa chỉ phong bì). DKIM: chữ ký số, toàn vẹn và nguồn ký. DMARC: chính sách none/quarantine/reject, báo cáo, và yêu cầu khớp domain From.
  • Triển khai DMARC theo bậc: kiểm kê nguồn gửi, SPF và DKIM, p=none, đọc báo cáo, quarantine, reject.
  • BIMI hiển thị logo cho thư đã xác thực (cần DMARC thực thi); secure email gateway lọc spam, phishing, mã độc, URL trước hộp thư.
  • Các biện pháp kỹ thuật cần đi cùng đào tạo nhận thức và quy trình xác minh yêu cầu nhạy cảm ngoài kênh email.

💬 Hỏi & Đáp nhanh

❓ Có SPF rồi thì có cần DKIM và DMARC không? Có. SPF chỉ xét địa chỉ trong phong bì và dễ hỏng khi chuyển tiếp thư. DKIM bổ sung chữ ký toàn vẹn. DMARC mới là lớp buộc xác thực phải khớp với địa chỉ From mà người đọc nhìn thấy và cho chủ domain quyền quyết định xử lý, kèm báo cáo.

❓ Bật DMARC reject có làm mất thư hợp lệ không? Có thể, nếu còn hệ thống gửi thư hợp lệ chưa được khai báo trong SPF hoặc DKIM. Vì vậy phải bắt đầu bằng p=none để thu báo cáo, bổ sung các nguồn còn thiếu, rồi mới siết dần.

❓ Domain của tôi không gửi thư thì có cần cấu hình không? Có. Domain không dùng để gửi thư vẫn có thể bị kẻ tấn công giả mạo. Bạn có thể công bố SPF không cho phép nguồn nào và DMARC p=reject để người nhận từ chối thư giả mạo domain đó.

📝 Bài tập đánh giá

Tự chọn đáp án cho từng câu, rồi đối chiếu với phần đáp án ở cuối bài.

Câu 1. Cơ chế nào cho phép chủ domain công bố trong DNS danh sách các máy chủ hoặc địa chỉ IP được phép gửi thư thay mặt domain?

  • A. DKIM
  • B. DMARC
  • C. SPF
  • D. BIMI

Câu 2. Cơ chế nào dùng chữ ký số trên thư, với khóa công khai công bố trong DNS, để xác nhận thư chưa bị sửa và được ký bởi domain?

  • A. DKIM
  • B. SPF
  • C. Captive portal
  • D. Secure email gateway

Câu 3. Cơ chế nào cho phép chủ domain đặt chính sách (none, quarantine, reject) cho thư không đạt xác thực, nhận báo cáo, và yêu cầu kết quả SPF hoặc DKIM phải khớp với domain trong địa chỉ From?

  • A. SPF
  • B. DKIM
  • C. BIMI
  • D. DMARC

Câu 4. Một tổ chức lần đầu triển khai DMARC, chưa kiểm kê hết các hệ thống gửi thư của mình. Bước khởi đầu hợp lý nhất là gì?

  • A. Đặt ngay chính sách reject
  • B. Đặt p=none để giám sát và đọc báo cáo trước khi siết chính sách
  • C. Tắt toàn bộ SPF và DKIM
  • D. Chỉ dùng BIMI

Câu 5. Thiết bị hoặc dịch vụ nào đứng trước hộp thư người dùng để lọc spam, phishing, quét mã độc bằng sandbox và cách ly thư đáng ngờ?

  • A. Web filter
  • B. Host-based firewall
  • C. Secure email gateway
  • D. NAC

👉 Đáp án

Câu 1: C — SPF công bố danh sách nguồn được phép gửi thư cho domain trong bản ghi DNS.

Câu 2: A — DKIM ký số thư, khóa công khai nằm ở DNS, đảm bảo toàn vẹn và nguồn ký.

Câu 3: D — DMARC đặt chính sách none/quarantine/reject, có báo cáo và yêu cầu khớp domain với From.

Câu 4: B — Bắt đầu bằng p=none để giám sát và thu báo cáo, bổ sung các nguồn hợp lệ còn thiếu, rồi mới siết dần để tránh chặn nhầm thư hợp lệ.

Câu 5: C — Secure email gateway lọc spam, phishing, mã độc (kèm sandbox), kiểm tra URL và cách ly thư đáng ngờ trước khi tới hộp thư.


📚 Bài viết thuộc khóa học CompTIA Security+ của VNExperts

🧭 Điều hướng

⬅️ Bài trước🏠 Mục lục khóa họcBài kế tiếp ➡️
Bài 61: Bảo vệ endpoint: EDR/XDR, antivirus, posture check Mục lục khóa học CompTIA Security+ Bài 63: Bảo mật ứng dụng: input validation, SAST/DAST, sandboxing