跳到主要内容

11. 安全考虑

本节讨论 DMARC 的安全问题以及可用的缓解措施.

11.1. 认证方法​

DMARC 所使用认证方法的安全考虑通过引用并入本文.

DMARC 底层的两种电子邮件认证方法都在一定程度上保证电子邮件由获授权的 MTA 传输. SPF 策略将域名映射到一组获授权的 MTA, 参见 [RFC7208] 第 11.4 节. 经过验证的 DKIM 签名表明, 电子邮件由一个可以访问私钥的 MTA 传输, 该私钥与已发布的 DKIM key record 匹配.

只要发送邮件, 就存在这样的风险: 过于宽松的源可能发送并非 Domain Owner 本意授权的邮件, 但该邮件仍获得 DMARC "pass" 结果. 当系统把 DMARC "pass" 结果解释为消息在某种意义上真实可信时, 这些结果可能引发问题. 它们还会允许此类未授权发送方规避 Domain Owner 针对 DMARC 验证失败所期望的消息处理方式.

为避免此风险, 必须确保未授权源既不能为该域的邮件添加 DKIM 签名, 也不能发送会被评估为 SPF "pass" 结果的邮件. 不过, 如果 Domain Owner 希望在域的 SPF record 中包含宽松源, 可以在与该源相关联的 SPF record 机制上使用 "?" qualifier, 从而将该源排除在 DMARC 考量之外. DMARC Working Group 曾就是否完全移除 SPF 作为 DMARC 底层认证机制进行了充分讨论, 但未达成共识, 因此本文改为提出对宽松源使用 "?" qualifier 的建议.

11.2. 针对 Reporting URI 的攻击​

发布在 DNS TXT record 中的 URI 是众所周知的潜在攻击目标. 例如, [RFC1035] 和 [RFC2142] 等规范会暴露或导致暴露可能被攻击者大量灌入流量的电子邮件地址. DNS 中的 MX, NS 等记录会公布潜在攻击目标. 常见 DNS 名称, 如 "www", 会明确标识特定服务所在位置, 从而为定向 denial-of-service 或渗透攻击提供目标. 这意味着 Domain Owner 需要加固这些地址以抵御多种攻击, 包括但不限于:

  • 高流量 denial-of-service 攻击.

  • 故意构造格式错误的报告, 以识别或利用解析或处理漏洞.

  • 故意构造在 Submitter 或 Reported-Domain 字段中包含虚假声明的报告, 包括来自已受入侵但已知 Mail Receiver 的虚假数据.

11.3. DNS 安全​

DMARC 机制及其底层认证机制 SPF 和 DKIM 依赖 DNS 的安全性. 恶意方可能对 DNS 流量造成不利影响的示例包括:

  • 如果能够窥探 DNS 流量, 它们可以大致了解谁在接收使用相关域的邮件.

  • 如果能够阻断传出的 DNS 消息或 DNS 回复消息, 它们可以阻止系统发现发送方的 DMARC 策略.

  • 如果能够发送伪造响应包, 它们可以使已对齐的邮件看起来未对齐, 或反之.

这些威胁都不是 DMARC 所独有的, 可以使用多种技术处理, 包括但不限于:

  • 使用 Domain Name System Security Extensions (DNSSEC) [RFC9364] 对 DNS record 进行签名, 使接收方能够验证 DNS 数据完整性, 并检测和丢弃伪造响应.

  • DNS over TLS [RFC7858] 或 DNS over HTTPS [RFC8484] 可以缓解窥探和伪造响应.

11.4. Display Name 攻击​

消息滥用中越来越常见的一类攻击, 是在 RFC5322.From header field 的 display name 部分呈现虚假信息. 例如, 该字段中的电子邮件地址可以是任意地址或域名, 同时在 display name 中包含知名名称, 如个人, 品牌, 角色等, 以诱骗最终用户相信该名称的使用是合法的.

此类攻击称为 display name attack, 不在 DMARC 范围内.

11.5. 拒绝 DMARC 处理攻击​

第 5.3.1 节以及本文其他位置声明, 不包含且仅包含一个 RFC5322.From domain 的消息不在本文范围内. 这暴露了一个必须考虑的攻击向量.

由于此类消息不在本文范围内, 攻击者可以构造包含多个 RFC5322.From domain 的消息, 其中包括被仿冒域, 试图绕过 DMARC 验证, 并让受害者的 Mail User Agent (MUA) 显示该欺诈消息, 同时成功向受害者呈现被仿冒域. 在此类消息未因其他原因被拒绝的情况下, 例如许多此类消息会违反 [RFC5322] 中必须且只能存在一个 From: header field 的要求, Mail Receiver 必须谨慎识别此类消息可能构成的威胁, 并适当处理.

语法有效的多值 RFC5322.From field 是一个特殊挑战. 经验表明, 大多数此类消息都具有滥用性质和/或不受接收方欢迎. 基于这一事实, Mail Receiver 可以在消息进入 DMARC 处理之前, 或替代 DMARC 处理, 对该消息作出负面处置决定. 然而, 如果 Mail Receiver 要求消息接受 DMARC 验证, 根据 [RFC7489] 推荐的方法是: 将 RFC5322.From field 中找到的每个域作为 Author Domain 应用 DMARC 机制, 并在失败的检查中选择最严格的策略. 对少量 Author Domain 而言, 这种方法可能有用, 但对包含大量域的消息应用此逻辑时, 其中 "大量" 由各 Mail Receiver 自行定义, 可能会使 Mail Receiver 暴露于某种 denial-of-service 攻击. 限制所处理 Author Domain 的数量可避免此风险. 如果并非所有 Author Domain 都被处理, 则 DMARC 评估是不完整的.

11.6. 外部报告地址​

为避免恶意行为者滥用, 报告地址通常必须位于请求报告所涉及的域之内. 为适应特殊情况, 例如需要获取关于实际无法接收邮件的域的报告, [RFC9990] 第 3 节描述了一种基于 DNS 的机制, 用于验证已获批准的外部报告.

这里显而易见的考虑是, 声称作为外部接收方的域会承受增加的 DNS 负载. Negative caching 可缓解此问题, 但程度有限, 主要取决于该域 SOA record 中的默认 TTL.

在可能的情况下, 实现外部报告的最佳方式是将报告定向到能够接收邮件的域, 再由其自动转发到期望的外部目标.

注意, "ruf" tag 中显示的地址会接收更多可能被视为私人数据的信息, 因为故障报告中可能出现实际电子邮件内容. 因此, 其中标识的 URI 比 "rua" tag 中的 URI 更容易成为入侵尝试的目标. 此外, 攻击相关域的 DNS 以欺诈方式将失败数据路由到攻击者系统, 也可能具有吸引力. 如果对此有顾虑, 建议部署 DNSSEC [RFC9364].

11.7. 安全协议​

本文鼓励使用安全传输机制, 防止私人数据泄露给可能监视这些传输的第三方. 未加密机制 SHOULD 避免.

特别是, 原本经过加密或以其他方式保护的消息, 可能出现在未安全发送的报告中, 从而泄露私人信息.

11.8. 宽松对齐考虑​

DMARC 机制允许 DKIM-Authenticated Identifier 和 SPF-Authenticated Identifier (第 4.4 节) 代表 Domain Owner (第 3.2.7 节) 验证 Author Domain (第 3.2.2 节) 的授权使用. 如果恶意用户或不了解风险的用户能够控制 Organizational Domain 某个子域的 SPF record 或 DKIM selector record, 则该子域可用于生成代表 Organizational Domain 获得 DMARC pass 的电子邮件.

此类场景可能在以下条件下发生:

  • 域 "example.com" 存在 DMARC Policy Record, 因而 "example.com" 是 Organizational Domain.

  • 攻击者控制域 "evil.example.com" 的 DNS, 并为该域发布 SPF record.

  • 攻击者发送电子邮件, 其 RFC5322.From header field 包含 "[email protected]", 且 SPF-Authenticated Identifier 为 "evil.example.com".

虽然此电子邮件未获 Domain Owner 授权, 但由于 SPF-Authenticated Identifier ("evil.example.com") 与 Author Domain ("example.com") 具有 Identifier Alignment, 它可以产生 DMARC pass.

如果这是一个问题, Organizational Domain Owner 应谨慎避免委派对子域的控制, 并在适当时考虑使用 strict alignment (第 3.2.10.2 节) 选项.

如果 Author Domain 没有发布 DMARC Policy Record (第 3.2.6 节), 则宽松对齐的 DMARC 评估还高度依赖于 Organizational Domain 判定是否正确. 如果错误选定的 Organizational Domain 是正确 Organizational Domain 的父域, 则宽松对齐可能允许恶意发送方发送获得 DMARC pass 判定的邮件. 无论是旧的 [RFC7489] 方法还是当前确定 Organizational Domain 的方法, 都存在这种可能性. 后者见第 4.10.2 节.

以下示例说明了这种可能性:

  • 发送的邮件使用 Author Domain "a.mail.example.com", Authenticated Identifier 为 "mail.example.com".

  • "_dmarc.a.mail.example.com" 没有发布 DMARC Policy Record.

  • "_dmarc.mail.example.com" 发布了一个 DMARC Policy Record, 且它预期作为此消息的 Organizational Domain.

  • "_dmarc.example.com" 也发布了一个 DMARC Policy Record, 其对齐方式为默认值 relaxed.

  • 攻击者能够发送 Author Domain 为 "evil.example.com", Authenticated Identifier 为 "mail.example.com" 的邮件.

在此场景中, 如果 Mail Receiver 错误地将 Organizational Domain 判定为 "example.com", 则攻击者的邮件将通过 DMARC 验证检查.

使用 strict alignment 并为组织电子邮件所使用的所有 Author Domain 发布显式 DMARC Policy Record, 可以完全避免此问题.

对于不适合 strict alignment 的情况, Domain Owner 可以通过定期检查 DNS 树中位于 Organizational Domain 之上的 PSD (第 3.2.15 节) 的 DMARC Policy Record 来缓解此问题, 如果存在这些记录的话. 检查频率可以是每周, 或适合给定组织运营需求的其他频率. 对于旧的 [RFC7489] 方法, 还需检查适当的 PSL 条目是否仍然存在. 如果某个 PSD 发布了不带适当 "psd=y" tag 的 DMARC Policy Record, Organizational Domain owner 可以向其 Organizational Domain 的 DMARC Policy Record 添加 "psd=n", 使该 PSD 的 DMARC Policy Record 不会被错误解释为表明该 PSD 是 Organizational Domain.

最后于 更新