12. 安全考虑

本节讨论 DMARC 特有的安全考虑.

12.1. 认证方法

DMARC 构建在 SPF 和 DKIM 之上. 因此, DMARC 的安全性依赖于这些底层机制的安全性. 实现者应熟悉 SPF [SPF] 和 DKIM [DKIM] 各自的安全考虑.

要点如下:

1. SPF 安全性: 如果攻击者能够通过 SPF 记录中授权的服务器发送邮件, SPF 可能被绕过.

2. DKIM 安全性: 如果签名密钥被攻破, DKIM 签名可能被伪造. 密钥管理至关重要.

3. 组合安全性: DMARC 对标识符对齐的要求提供了比单独使用 SPF 或 DKIM 更强的认证.

12.2. 针对报告 URI 的攻击

攻击者可能尝试通过以下方式使邮件接收方向受害者地址发送大量报告:

1. 为攻击者控制的域发布 DMARC 记录, 并在 "rua" 或 "ruf" 标签中放入受害者地址.

2. 发送大量声称来自该域的未经认证邮件.

Section 7.1 中描述的验证机制要求外部报告目的地显式授权报告关系, 从而防止这种攻击.

此外, 邮件接收方应:

• 对报告生成实施速率限制
• 监控异常报告模式
• 尊重报告接收者的退订请求

12.3. DNS 安全

DMARC 在策略分发方面高度依赖 DNS. DNS 安全考虑包括:

1. DNS 欺骗: 能够伪造 DNS 响应的攻击者可能:

   • 提供虚假的 DMARC 策略
   • 将报告重定向到攻击者控制的地址
   • 通过移除策略记录造成拒绝服务

2. DNSSEC: 使用 DNSSEC 可以缓解 DNS 欺骗风险. 实现者应考虑为发布 DMARC 策略的域部署 DNSSEC.

3. 缓存投毒: DNS 缓存投毒可能导致错误的 DMARC 策略被缓存并应用.

12.4. 显示名攻击

DMARC 不防护针对 RFC5322.From 字段显示名部分的攻击. 攻击者可以使用看似可信的显示名, 同时在地址中使用不同的域:

From: "Trusted Bank" <[email protected]>

用户可能只看到 "Trusted Bank", 而没有注意到实际发送域. Section 2.2 明确指出此限制不在范围内.

需要通过用户教育和 MUA 改进 (例如醒目显示实际电子邮件地址) 来应对此威胁.

12.5. 外部报告地址

当 DMARC 报告发送到外部地址 (位于被报告域之外的域中的地址) 时, 适用若干安全考虑:

1. 数据暴露: 报告包含关于该域电子邮件基础设施和流量模式的信息. 这些信息对攻击者可能具有价值.

2. 第三方信任: 域所有者必须信任第三方报告接收者会:

   • 安全处理报告数据
   • 不滥用这些信息
   • 遵守适用的隐私法规

3. 验证: Section 7.1 中的验证机制确保外部目的地已获授权, 但域所有者仍应仔细考虑自己正在共享哪些信息.

12.6. 安全协议

虽然 DMARC 本身并不强制使用特定安全协议, 实现者仍应考虑:

1. DNSSEC: 如 Section 12.3 所述, DNSSEC 可以防护 DNS 欺骗攻击.

2. 报告使用 TLS: 通过电子邮件发送报告时, 使用 STARTTLS 或其他加密机制可以保护传输中的报告内容.

3. 报告 URI 使用 HTTPS: 如果未来扩展允许使用 HTTPS URI 投递报告, 应使用 TLS 保护报告数据.

4. 安全密钥存储: DKIM 私钥必须安全存储, 以防被攻破.

---