[ DMARC和政策 ]

身份验证和授权:为什么有效的发件人仍然不安全

使用DMARC来回答其所回答的身份问题,然后根据其实际需要的控制措施对相​​似帐户、受损帐户和欺诈请求进行分类。

由EmailAuth研究团队提供 · 6 分钟阅读

[ 要点 ]

  • 有效的域关系并不能证明安全内容或授权意图。
  • 对精确域、相似域、显示名称和受损帐户风险进行分类。
  • 保持独立的交易检查和受控证据。
在此页面上

经过身份验证的消息仍然可能携带欺诈性请求。该声明并不表示 SPF, DKIM 或者 DMARC 不重要。它定义了它们的边界。

电子邮件身份验证提供有关域身份和消息处理的证据。业务授权回答了一个不同的问题:这个人或系统是否有权提出此请求,组织是否应该采取行动?安全的过程需要两者。

询问通行证实际上证明了什么

在下面 RFC 9989 §5.3.5 和 RFC 9989 §5.4,消息级DMARC传递意味着接收方发现至少一条传递的SPF或DKIM路径,其经过身份验证的域与 From 中的域一致。它并不能证明:

  • 哪个人控制该账户;
  • 该帐户没有被泄露;
  • 发票或银行变更是合法的;
  • 链接或附件是无害的;
  • 该域名是收件人心目中的品牌。

精确的声明很有用:消息提供了一个 From 域,并生成了与该域相关的合格身份验证证据。避免将其转换为更广泛的声明,即发件人或消息是安全的。

在选择响应之前对身份滥用进行分类

不同的攻击在收件箱中看起来相似,但位于身份验证边界的不同一侧。

  • 模式:精确域伪造;身份验证可能显示什么:没有对齐的传递路径,取决于接收者的证据和处理;控制和响应重点: DMARC政策、发件人覆盖范围、收件人控制和调查
  • 图案: 相似域名;身份验证可能会显示什么:相似者可能会成功验证其自己的域;控制和响应重点:领域监控、用户提示、过滤、报告和适当的滥用行为
  • 模式:显示名称欺骗;身份验证可能显示什么:不相关的域可以在提供熟悉的名称时进行身份验证;控制和响应重点:显示名称分析、上下文、用户报告和独立验证
  • 模式:授权账户被盗;认证可能显示什么:真实域名可以通过认证;控制和响应重点:帐户安全、会话和登录调查、遏制和业务验证
  • 模式:供应商受损;认证可能显示什么:供应商的真实域名可以通过;控制和响应重点:供应商事件协调、交易控制和备用渠道确认

DMARC能够最强地防止未经授权使用其所涵盖的域身份。它不会创建视觉上相似的域的所有权、验证显示名称的真实性或决定是否以适当的权限使用真实帐户。

追踪虚构的付款更改事件

以下场景是综合的。它旨在显示证据链而不暗示客户事件。

财务员工收到来自 accounts@supplier.example 要求更改银行详细信息。假设适用的策略,受信任的接收者结果显示一致的DKIM通行证 supplier.example,因此邮件会通过DMARC 。线程的历史和写作风格也显得很熟悉。

员工不会根据这些信号批准变更。他们拨打了之前验证过的供应商号码,得知邮箱已被盗用。该组织冻结请求的更改,保留原始消息并向供应商提供时间戳和相关标头。

身份验证按设计进行:它表明该消息使用了供应商的经过身份验证的域。独立验证控制阻止了域身份验证无法裁决的未经授权的事务。

保留协议证据和业务证据

对于后续事件,请在生成经过编辑的副本之前保留访问控制的原始消息。 RFC 8601 §7.1 定义可信结果边界;对签名材料的编辑可能会影响重新验证 RFC 6376 §3.7。有用的技术证据可以包括可信的 Authentication-Results、相关已接收字段、发件人、回复收件人、 Return-Path、 DKIM签名、消息标识符、时间戳和接收日志。

有用的业务证据包括请求、预期的操作、既定的批准规则、用于验证的联系方法和结果。将事实与推论分开。原始通行证并不是妥协的证据, DMARC失败也不是发生损害的证据。

在下面 RFC 9990 §3.1、聚合DMARC报告可以帮助域所有者了解观察到的身份验证和处置模式。它们不是单个消息的完整记录,并且通常不提供确定特定请求是否获得授权所需的内容。在下面 RFC 9989 §5.3.9, 故障报告生成后,需要仔细的隐私和访问处理,并且并不普遍可用。

在敏感工作流程中构建独立验证

高影响力的操作应该使用不仅仅依赖于传入消息的控件。示例包括:

  1. 通过先前批准的渠道验证银行详细信息更改;
  2. 要求对超出规定阈值的付款进行双重批准;
  3. 防止电子邮件线程同时提供请求和验证联系人;
  4. 使用经过身份验证的门户进行敏感数据交换;
  5. 将紧急保密、不寻常的时机或控制绕过视为风险信号。

这些是业务控制,不能替代身份验证。身份验证减少了域使用的模糊性,而事务控制则减少了经过身份验证但未经授权的请求的后果。

沟通边界而不削弱程序

说DMARC并不能阻止所有 网络钓鱼 技术准确。因此说它无效并不是。强制执行的策略可以减少对受保护域的成功未经授权​​的使用,改善接收者证据并明确合法发送路径的所有权。

正确的信息是分层的:保护域名、保护帐户、检测相似和欺骗性演示,并独立验证敏感操作。使用 DMARC身份指南 对于域级结果和 发件人库存 对于授权服务所有权。

将结论保留在证据范围内

虚构的支付变更案例有两个独立的结果:域认证通过;经单独核查,拟议交易未获批准。不要仅通过通行证报告妥协。仅保留授权的事件披露,并在传入请求之外保留可信的验证联系人。未联系任何供应商,也未执行任何交易或事件响应。

[ 外卖 ]

有效的域关系并不能证明安全内容或授权意图。对精确域、相似域、显示名称和受损帐户风险进行分类。保持独立的交易检查和受控证据。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

IT/邮件管理员

保留证据而不夸大其词。

可信标头和日志解释了域使用情况,但事件结论还需要帐户和业务上下文。

后续步骤

  1. 在访问控制下保留原始消息。
  2. 确定精确对齐的路径。
  3. 与身份和企业主协调。

CISO / SecOps

使用分层威胁模型。

精确域名伪造、相似域名、欺骗性显示名称和受损帐户需要不同的控制和指标。

后续步骤

  1. 映射攻击模式以控制所有者。
  2. 将发件人覆盖率与欺诈结果分开衡量。
  3. 在练习中测试交易验证。

创始人/非技术人员

保护决策和领域。

身份验证可减少身份滥用,而独立审批可防止经过身份验证的请求成为未经授权的交易。

后续步骤

  1. 为敏感更改定义备用通道验证。
  2. 在影响力允许的情况下需要双重批准。
  3. 将受信任的供应商联系人保留在电子邮件线程之外。

[ 常见问题解答 ]

常见问题

网络钓鱼能否通过SPF 、 DKIM和DMARC ?

是的。攻击者拥有的域、受损帐户或受损供应商可以成功进行身份验证。身份验证不批准内容或请求。

RFC 9989 §5.4

DMARC是否保护每个视觉上相似的域?

否。策略适用于所涵盖的域身份。相似域需要单独的监控、过滤、用户感知和响应。

RFC 9989 §3.2.2 RFC 9989 §5.4

DMARC通过后,显示名称是否具有欺骗性?

是的。域可以在提供熟悉的显示名称的同时验证自己的邮件。检查实际地址和上下文。

RFC 9989 §3.2.2 RFC 9989 §5.4

由于DMARC通过,付款变更是否应该获得批准?

不会。通过独立建立的授权流程验证敏感变更。

DMARC在帐户泄露期间有何贡献?

它可以确认该消息使用了对齐的经过身份验证的域。需要帐户、会话和业务证据来确定妥协和权限。

RFC 9989 §5.4

汇总报告能否证明是哪个人发送了消息?

不会。聚合数据概括地描述了身份验证和处置观察结果。它不是个人身份证明。

RFC 9990 §3.1

对于后续事件应保留哪些证据?

保留访问控制的原始消息、可信身份验证结果、相关标头和日志、时间戳、请求的操作和独立验证结果。

滥用报告是否能保证相似域名被删除?

不会。结果取决于提供者、证据、适用的政策和审查。记录提交和回复,但不承诺删除。

[ 来源 ]

来源

  1. RFC 9989

    部分 §3.2.2 · §5.3.5 · §5.3.9 · §5.4

  2. RFC 9990

    部分 §3.1

  3. RFC 8601

    部分 §7.1

  4. RFC 6376

    部分 §3.7

[ 词汇表 ]

词汇表

作者域
消息 From 标头字段中的域用作DMARC对齐的参考。

RFC 9989 §3.2.2

业务审批
授权采取行动的单独负责任的决定; DMARC通行证本身无法提供此功能。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库