Nhiều đối tác của Zimbra đã triển khai DMARC và do đó sẽ không bị ảnh hưởng bởi chính sách mới. Nếu bạn muốn tìm hiểu thêm về cách triển khai các yêu cầu mới, hãy theo dõi các bài viết trước đây của Zimico hoặc thực hiện theo hướng dẫn sau của chúng tôi.

Trong bài viết này, Zimico còn tổng hợp tất cả các thông tin liên quan đến việc thiết lập bảo mật khi gửi nhận mail giữa các máy chủ. Bài viết này khá dài và chi tiết, bạn hãy chuẩn bị một cốc cà phê và giấy bút để ghi chú nếu thấy cần thiết nhé.

SPF & DKIM: là nền tảng trong hoạt động xác thực email hiện đại và là bước đầu tiên để bảo vệ độ uy tín của email gửi đi và domain bên gửi.
SPF cung cấp cơ chế xác thực bên gửi email bằng cách liệt kê các địa chỉ IP được phép gửi email đi. Một record SPF luôn bắt đầu bằng v=spf1 và kết thúc bằng all. Ví dụ
v=spf1 ip4:1.1.1.1 ip4:2.2.2.2 mx ~all
Trong đó all là đại diện cho toàn bộ internet IP.
~all: nếu địa chỉ IP máy chủ gửi email không nằm trong số các IP được liệt kê thì xếp vào soft fail (tức chấm điểm spam và vẫn nhận).
-all: nếu địa chỉ IP máy chủ gửi email không nằm trong số các IP được liệt kê thì loại bỏ email này (từ chối nhận).
Một số ví dụ về spf record:
v=spf1 mx a a:blog.zimico.vn ip4:1.1.1.1 include:_spf.marketingemail.com -all
(version spf1, chấp nhận server gửi mail từ IP trong record mx, record a blog.zimico.vn, địa chỉ ip4 cụ thể 1.1.1.1 và từ dịch vụ bên thứ 3 là marketingemail.com, ngoài các IP này thì không nhận).
Khi mới thiết lập spf record, bạn có thể dùng ~all để theo dõi trạng thái hệ thống. Mục đích cuối cùng là sử dụng -all để đảm bảo các email gửi từ IP không được bạn xác thực sẽ bị chặn ở phía nhận.
Đối với các domain không dùng để gửi email (nếu công ty bạn có nhiều domain), sử dụng spf record
v=spf -all
để chắc chắn email gửi từ các domain này sẽ bị chặn bởi phía nhận. Điều này hạn chế việc hacker lợi dụng các domain khác của công ty để gửi email lừa đảo.
DKIM: giúp bạn xác thực email được gửi từ domain của bạn và nội dung email không bị thay đổi trong quá trình gửi nhận. Để thiết lập DKIM, bạn sử dụng 2 bước:
Bước 1: tạo cặp khoá public/private trên mail server.
– Dùng lệnh: /opt/zimbra/libexec/zmdkimkeyutil -a -d zimilab.com
o a: thêm domain sử dụng DKIM
o d: tên domain.
– Trên màn hình zimbra sẽ hiển thị thông tin selector và giá trị public key bạn cần thêm vào DNS TXT record. Ví dụ
OE9F184A-9577-11E1-AD0E-2A2FBBACC6BCB._domainkey IN TXT “v=DKIM1;=rsa;”
“p=ABC1PIOAONGM/ÀPOIGHA;IHAH” “CHOIAERANBHC;DA-ADAO-ADVNAPEI”
—-DKIM OE9F184A-9577-11E1-AD0E-2A2FBBACC6BCB for zimilab.com
Bước 2: phát hành khoá public qua DNS TXT record.
– Host name: OE9F184A-9577-11E1-AD0E-2A2FBBACC6BCB._domainkey.zimilab.com.
– Nội dung: v=DKIM1;=rsa; p= ABC1PIOAONGM/APOIGHA;IHAH CHOIAERANBHC;DA-ADAO-ADVNAPEI
– Nếu bạn sử dụng dịch vụ (ví dụ email marketing) của đối tác để gửi email quảng cáo từ domain của bạn, bạn cũng cần tạo một DKIM record với SELECTOR và public key được cung cấp bởi họ. Ví dụ, tạo thêm một TXT record từ thông tin được cung cấp:
– Host name: client01._domainkey.zimilab.com (client01 là SELECTOR mà bên đối tác sẽ cung cấp cho bạn)
– Nội dung: v=DKIM1;=rsa; p=VNA50UNGAG869ANG/AGA;HIGNDPAHE
DMARC: hỗ trợ SPF&DKIM bằng việc cung cấp các chính sách xử lý các email không thoả điều kiện SPF&DKIM cũng như cung cấp cơ chế phản hồi thông qua các báo cáo từ phía nhận.
Tạo DNS TXT record cho DMARC:
– Host name: _dmarc.zimilab.com (hoặc chỉ cần _dmarc)
– Nội dung: v=DMARC1; p=reject; rua=mailto:admin@zimilab.com; sp=reject
o p=none: không áp dụng DMARC policy, mục đích dành cho giám sát.
o p=quarantine: cho email không thoả mãn DMARC (sai SPF, DKIM) vào thư mục rác.
o p=reject: chặn các email không thoả mãn DMARC.
o rua: reporting URI for aggregate reports.
o sp=reject: không cho phép gửi email từ các subdomain không có DKIM và SPF.
Bạn nên bắt đầu với p=none và sp=none, thực hiện việc giám sát, thu thập report. Việc này có thể mất vài tuần để phát hiện các lỗi về DKIM alignment, SPF alignment và tiến hành chỉnh sửa. Sau đó tiến hành đổi thành p=reject và sp=reject.
SPF alignment: so sánh trường FROM và RETURN-PATH hoặc EHLO (nếu return-path=<>) có phần hoặc 1 phần domain giống nhau.
DKIM alignment: so sánh trường d=<domain> và RETURN PATH có phần hoặc 1 phần domain đảm bảo giống nhau.
Bạn có thể chính định DMARC mode (chuyển từ relax sang strict mode bằng cách chỉ định aspf=1 và adkim=1) để bắt buộc các trường này phải có domain giống nhau hoàn toàn.
MTA-STS (Mail Transfer Agent Strict Transport Security). Mục đích:
– Khắc phục nguy cơ trong tiêu chuẩn STARTTLS.
– Hướng dẫn bên gửi email cần làm gì khi việc mã hoá email không thể thực hiện.
– Chống lại tấn công main-in-the-middle và email eavesdropping.
Hiện tại khoảng 90% hệ thống mail sử dụng Opportunistic Encryption of Email. Có nghĩa là đầu tiên 2 email server kết nối với nhau sử dụng kết nối không được mã hoá để trao đổi các tính năng mà 2 server có thể hỗ trợ, bao gồm cả việc mã hoá. Nếu có hỗ trợ mã hoá thì sử dụng nó để gửi nhận email, còn nếu không thì sẽ gửi nhận email ở dạng không mã hoá (plain-text).
Để triển khai MTA-STS cần chuẩn bị:
– Mỗi mail server cần chứng thư SSL. Chứng thư này cần được cấp chính xác cho cả hostname và mx record name. Nếu hostname và mx record name khác nhau, bạn cần dùng wildcard ssl.
– Các server cần hỗ trợ STARTTLS (Opportunistic Encryption). Kiểm tra bằng cách:

su - zimbra
zmprov gs `zmhostname` zimbraMtaTlsSecurityLevel
zmprov gs `zmhostname` zimbraMtaSmtpTlsSecurityLevel
zmprov ms `zmhostname` zimbraMtaTlsSecurityLevel may
zmprov ms `zmhostname` zimbraMtaSmtpTlsSecurityLevel may
zmmtactl restart

– Email server cần hỗ trợ TLS 1.2 trở lên. Kiểm tra bằng lệnh:
zmprov gcf zimbraMtaSmtpdTlsProtocols
Nếu TLS thấp hơn 1.2 thì cần điều chỉnh theo https://wiki.zimbra.com/wiki/Cipher_suites#Configuring_Zimbra_MTA_Postfix
Xuất bản MTA-STS policy
– Tạo 1 website https://mta-sts.zimilab.com
(Định dạng là https://mta-sts.[email-domain-name])
– Tạo text file https://mta-sts.zimilab.com/.well-known/mta-sts.txt
– Với nội dung sau:

version: STSv1
mode: testing
mx: mail.zimilab.com
mx: mail1.zimilab.com (nếu có nhiều mta phục vụ gửi nhận mail)
max_age: 31557600

31557600 giây tương ứng với 1 năm và 6 giờ là thời gian lớn nhất của max_age.
Có 3 mode là: none, testing và enforce. Sau khi testing 1 vài tuần, bạn sẽ chuyển sang mode enforce.
Tạo MTA-STS DNS record:
– Record type: TXT
– Hostname: _mta-sts.zimilab.com
– Nội dung: v=STSv1; id=2024020401;
id là số bất kỳ, khuyến nghị lấy theo format YYYYMMDDNN (Year, month, day, number).
Bạn có thể dùng S3 để chứa file mta-sts.txt mà không cần tạo riêng 1 website. Xem hướng dẫn tại đây.
TLS-RPT (Transport Layer Security Reporting): cung cấp phản hồi việc gửi email thành công hay thất bại. Dùng như một cơ chế cảnh báo sớm về các lỗi cấu hình trên mail server của bạn hoặc cảnh báo về các cuộc tấn công đang diễn ra.
Thiết lập TLS-RPT DNS record:
– Record type: TXT
– Host name: _smtp._tls.zimilab.com
– Nội dung: v=TLSRPTv1; rua=mailto:admin@zimilab.com
BIMI (Brand Indicators for Message Identification): cho phép các khách hàng yêu cầu nhà cung cấp dịch vụ email hiển thị logo của họ bên cạnh email mà họ gửi đến người nhận.
Yêu cầu: bạn cần có DMARC với policy là quarantine hoặc reject để có thể thiết lập BIMI.
Bước 1: tạo logo trên Abode Illustrator với định dạng svg
Bước 2: định dạng logo hình vuông với kích thước < 32KB.
Bước 3: Điều chỉnh logo theo hướng dẫn tại https://bimigroup.org/creating-bimi-svg-logo-files/
Bước 4: upload file logo.SVG lên https website.
Bước 5: Tạo DNS TXT record với nội dung sau
– hostname: default._bimi.zimilab.com
– nội dung: v=BIMI1; l=https://zimico.vn/logo.svg
Bạn cũng có thể ký số cho logo của mình (tradmarked) và thêm thông tin này vào BIMI. Chúng tôi không trình bày bước này ở đây.
DNSSEC: bảo vệ hạ tầng DNS của bạn để không trở thành điểm yếu nhất trong chuỗi bảo mật, hỗ trợ bạn phòng ngự trước các kiểu tấn công spoofing và main-in-the-middle.
Để triển khai DNSSEC, bạn cần chuẩn bị và thoả mãn các điều kiện sau:
– Nhà cung cấp dịch vụ tên miền cần hỗ trợ DNSSEC.
– Firewall của bạn cần:
o Cho phép inbound/outbound traffic trên cổng UDP và TCP 53.
o Cho phép gói tin UDP lớn hơn 512 Bytes (ít nhất là 4KB)
o Tắt chức năng DNS ALG (Applicaion-level gateway).
o Cho phép các gói tin UDP bị phân mảnh.
Khi kích hoạt dịch vụ DNSSEC, dns server sẽ tự động tạo ra các bản ghi phù hợp.
DNSSEC phụ thuộc nhiều vào đồng bộ thời gian. Cần đảm bảo bạn đã cài đặt chronyd đã được cài đặt và chạy trên các server (dns server).
TLS & DANE: khắc phục điểm yếu cố hữu của cơ quan cấp chứng chỉ ssl bằng cách sử dụng tính năng ghim chứng chỉ.
Hiện tại, khuyến cáo bạn không nên sử dụng tất cả phiên bản SSL (từ 1.0 đến 3.0) cũng như TLS phiên bản 1 và 1.1. Chỉ nên sử dụng TLS 1.2 và 1.3.
Symmetric Encryption, yêu cầu bên gửi và nhận chia sẻ trước với nhau một pre-shared key, để có hiệu suất cao.
Asymmetric Encryption: không sử dụng pre-shared key và có hiệu suất thấp. Các kênh truyền thông bảo mật thường bắt đầu bằng Asymmetric và chuyển sang Symmetric Encryption ngay sau đó.
Cipher Suites: ECDHE-ECDSA-AES128-GCM-SHA256

Ý nghĩa của các thành phần trong Cipher suites:
ECDHE: Asymmetric Key Exchange Methode
ECDSA: Authentication Method
AES128-GCM: Symmetric Encryption Method
SHA256: Integrity Checking Method.
Trước khi thực hiện cấu hình liên quan đến TLS cipher, bạn nên chạy lệnh sau để lấy và copy lại thông tin cấu hình hiện tại:

zmprov gcf zimbraReverseProxySSLCiphers

Không thay đổi cùng 1 lúc quá nhiều thông số TLS và nên tiếp cận tăng dần khi bạn muốn loại bỏ các giao thức hoặc bộ mã hoá cũ. Ví dụ như loại bỏ TLS 1.0, sau khi không thấy than phiền, tiến hành loại bỏ TLS 1.1.
DANE: DNS-Based Authentication of Named Entities.
Để sử dụng DANE, bạn cần kích hoạt dùng DNSSEC trước.
Để enable dnssec cho dns resolver server, ví dụ như bạn đang dùng dnsmasq, thêm phần sau vào file /etc/dnsmasq.conf

conf-file=/usr/share/dnsmasq/trust-anchors.conf
dnssec

Để thiết lập DANE, bạn thực hiện các bước sau:
1. Lấy SSL cert từ nhà cung cấp dịch vụ CA như bình thường.
2. Tạo một chuỗi băm (hash) SHA-256 từ một phần hoặc toàn bộ SSL cert.
3. Tạo TLSA (Transport Layer Security Authentication) record như sau:
_25._tcp.mail.domain.example. IN TLSA 3 1 1 0820307308201efa003020102020
Trong đó:
_25: là port của dịch vụ dùng SSL certification
_tcp: là giao thức của dịch vụ.
mail.domain.example: là tên server, domain dùng SSL certification.
3: Certificate Usage: thể hiện đây là certification dùng cho domain.
1: Selector: thể hiện chỉ có thành phần public key của SSL certification là có trong hàm băm.
1: Matching Type: thể hiện đây là hàm băm SHA-256.
0820307…: giá trị hàm băm của SSL certificate.
Mỗi khi renew SSL certificate, bạn sẽ cần tạo lại TLSA record với giá trị hash mới. Để không phải tạo lại TLSA record, bạn có thể dùng lại private key cũ khi yêu cầu SSL certificate từ bên cung cấp dịch vụ.
Bạn có thể dùng tool online để tạo TLSA record: https://www.huque.com/bin/gen_tlsa
Tham khảo thêm tại:
https://blog.zimbra.com/2022/03/zimbra-skillz-enable-dane-verification-for-outgoing-email-in-zimbra/
https://blog.zimbra.com/2022/04/zimbra-skillz-enable-dane-verification-for-incoming-email-in-zimbra/
Hiện tại việc thiết lập DANE khá phức tạp, đặc biệt khi bạn phải renew ssl cert liên tục. Bạn có thể chỉ dừng ở mức thiết lập MTA-STS như hướng dẫn ở trên.