Skip to main content

12. Security Considerations (安全考虑)

本节讨论 DMARC 特定的安全考虑。

12.1. Authentication Methods (认证方法)​

DMARC 建立在 SPF 和 DKIM 之上。因此，DMARC 的安全性取决于这些底层机制的安全性。实施者应熟悉 SPF [SPF] 和 DKIM [DKIM] 的安全考虑。

关键点:

  1. SPF 安全性: 如果攻击者可以通过 SPF 记录中授权的服务器发送邮件，则可以绕过 SPF。

  2. DKIM 安全性: 如果签名密钥被泄露，DKIM 签名可能会被伪造。密钥管理至关重要。

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

12.2. Attacks on Reporting URIs (对报告 URI 的攻击)​

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

  1. 为攻击者控制的域发布 DMARC 记录，在"rua"或"ruf"标签中包含受害者的地址。

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

第 7.1 节中描述的验证机制通过要求外部报告目的地明确授权报告关系来防止这种攻击。

此外，邮件接收方应该:

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

12.3. DNS Security (DNS 安全)​

DMARC 严重依赖 DNS 进行策略分发。DNS 安全考虑包括:

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

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

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

  3. 缓存中毒: DNS 缓存中毒可能导致不正确的 DMARC 策略被缓存和应用。

12.4. Display Name Attacks (显示名称攻击)​

DMARC 不能防止对 RFC5322.From 字段的显示名称部分的攻击。攻击者可以使用看起来值得信赖的显示名称，同时在地址中使用不同的域:

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

用户可能只看到"Trusted Bank"而没有注意到实际的发送域。此限制在第 2.2 节中明确指出为超出范围。

需要用户教育和 MUA 改进 (例如突出显示实际电子邮件地址) 来解决此威胁。

12.5. External Reporting Addresses (外部报告地址)​

当 DMARC 报告发送到外部地址 (被报告域以外的域的地址) 时，适用以下几个安全考虑:

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

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

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

  3. 验证: 第 7.1 节中的验证机制确保外部目的地已获授权，但域所有者仍应仔细考虑他们共享的信息。

12.6. Secure Protocols (安全协议)​

虽然 DMARC 本身不强制使用特定的安全协议，但实施者应考虑:

  1. DNSSEC: 如第 12.3 节所述，DNSSEC 可以防止 DNS 欺骗攻击。

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

  3. 报告 URI 的 HTTPS: 如果未来的扩展允许 HTTPS URI 用于报告传递，应使用 TLS 来保护报告数据。

  4. 安全密钥存储: DKIM 私钥必须安全存储以防止泄露。

Last updated on