怎样发现 SMTP 认证被绕过或发信凭据被滥用？有哪些必须监控的信号？

很多所谓的「认证绕过」，追查到最后会发现根本没有绕过——是那条路径本来就不要求认证，而运维以为它要求。邮件系统的入站至少有三条语义完全不同的路径：

• 25 端口，MTA 之间的中继。这条路径按 RFC 5321 运作，互联网上任意一台 MTA 都可以连上来投递给你的用户，这里不存在也不应该要求认证。这条路径的安全边界是「只接受投递给本域用户的邮件」，即不做开放中继。
• 587 端口，用户提交。RFC 6409 把「提交」与「中继」明确区分为两种不同的操作，提交服务器应当要求认证，并且可以对提交的报文做修正与策略强制。这条路径的安全边界是「已认证用户才能通过我向外发信」。
• 465 端口，隐式 TLS 的提交。RFC 8314 明确了在提交与访问场景使用隐式 TLS 的做法，语义与 587 相同，区别在于 TLS 建立的时机。

这三条路径必须在配置上彻底分开，用不同的策略集。如果一台主机同时用同一套策略服务 25 与 587，那么任何一次策略调整都在同时改变两种语义完全不同的流量，出问题只是时间问题。判断一个配置是否健康，最快的方法就是问：「25 端口上有没有任何一条规则是为已认证用户写的？」如果有，说明两条路径已经混了。

不涉及任何攻击手法，纯粹从防守方视角自查。以下每一项都应当用外部视角实测确认，而不是读配置文件确认——配置文件里的意图和实际生效的行为经常不一致。

1. 开放中继。最基本也最致命。必须从外部网络实测：本机不在任何白名单内、不做认证的情况下，能否让服务器接受一封收件人不属于本域的邮件。这一项要定期复测，因为它可能被某次「临时」的策略变更重新打开。
2. 遗留的免认证网段。为打印机、监控系统、老业务系统开的 IP 白名单，往往写下去就再没人看过。这些网段一旦有主机失陷，它就是一条无需凭据的外发通道。每条白名单都应当有申请人、用途、有效期。
3. 明文通道上的认证。RFC 4954 对在无保护通道上宣告与使用明文认证机制有明确限制，RFC 8314 更进一步要求提交与访问强制使用 TLS。自查点是：在未建立 TLS 的连接上，服务器是否仍然宣告了明文认证机制？宣告本身就是问题。
4. 备用 MX 与历史遗留主机。主网关策略很严，备用 MX 却是几年前配的、策略宽松，这是一条绕过全部检测的合法路径。所有 MX 记录指向的主机必须策略一致，并核查是否有历史 A 记录直接暴露了内部投递主机。
5. 内网到互联网 25 端口的直连。如果内网任意主机都能直连外部 25 端口，那么一台失陷主机可以完全绕过你的外发网关与全部策略。外发必须收敛到指定中继。
6. 负载均衡器后的真实源地址。如果后端看到的都是均衡器地址，那么所有基于源地址的策略与审计都失效了，滥用检测也就无从谈起。

凭据被盗用时，认证是成功的、日志是干净的、协议是合规的。能区分正常与异常的只有行为基线。值得监控的信号包括：

• 认证成功但发信模式突变。一个历史上每天只发内部邮件的账号，突然开始向大量外部地址投递，这是最强的单一信号。基线应当按账号维度建立，而不是全局阈值——全局阈值必然要么漏掉小号，要么误伤群发账号。
• 同账号在短时间内来自地理或网络上不相容的位置。注意这里的判据是「不相容」而不是「异地」：出差、代理、移动网络都会造成异地。真正有意义的是在物理上不可能同时成立的组合。
• 大量收件人被拒。正常业务发信的收件人绝大多数是有效的。如果某个已认证会话产生了大量无效收件人拒绝，通常意味着对方在使用一份不属于本组织业务的地址清单。
• 客户端标识与历史不符。EHLO 标识、认证机制选择、连接特征的突然改变，单独看是弱信号，与上面的信号叠加则显著。
• 发信时间分布异常。与该账号历史作息完全不重叠的时间段出现集中外发。
• 提交与信头身份不一致。这一条见下一步，是邮件场景特有的强信号。

不要试图用单条信号触发处置。邮件的正常行为方差很大，单条信号的误报会迅速消耗运维的信任，最终导致告警被静音——那比没有告警更糟。

SMTP 提交时，认证身份、信封发件人（MAIL FROM）、信头 From 是三个可以互不相同的东西。正常业务中它们通常一致，或者存在有限且已知的例外（代发、共享邮箱、群组）。

RFC 6409 允许提交服务器对提交的报文执行策略强制与必要的修正，这为「拒绝认证身份与 From 不匹配的提交」提供了规范依据。但在收紧之前必须先测量，因为例外往往比想象中多：工单系统代发、财务系统以部门地址发出、秘书代高管发信。

可执行的推进路径：

1. 先只记录不拦截。在提交侧记录（认证身份，MAIL FROM，From）三元组，跑满一个完整业务周期。
2. 把不一致的组合分类。区分出「已知合法的代发关系」与「说不清来源的组合」。
3. 把合法关系显式化为授权表，而不是靠默认放行。
4. 然后再对表外的不一致执行拒绝。

入站侧同样要留痕。RFC 7601 定义的 Authentication-Results 信头用于记录本地认证判定结果，它的价值在于把「当时判定了什么」固化在报文里——事后 DNS 记录已经变了，但这条信头还在。需要注意的是，这个信头只有在由可信的边界节点添加、并且对来自外部的同名信头做了清理时才有意义，否则它本身就可以被伪造。

越来越多的客户端不再使用口令，而是通过 OAuth 获取令牌访问邮箱。RFC 7628 定义了用于 OAuth 的 SASL 机制，使 IMAP 与 SMTP 提交可以使用令牌完成认证。这带来一个运维上的盲区：

令牌是独立于口令的凭据。改密码不会使已经签发的令牌失效，除非平台明确实现了联动。因此「已重置密码」不能作为「已处置完毕」的结论。

需要单独建立的监控与自查：

• 新增的高权限授权。特别是被授予了邮件读取或发送范围、且带有离线访问（可获得刷新令牌）的应用。RFC 6749 规定授权服务器最终授予的范围可能与请求的不同，且必须在响应中返回实际授予的范围——审计时要看实际授予的范围，不能只看应用声称请求了什么。
• 存量授权的定期复核。长期未使用但仍持有宽泛范围的授权应当清理。RFC 9700 强调了令牌生命周期管理与最小权限原则。
• 用户自助同意的策略收紧。把「任意用户可授权任意应用访问自己的邮件」改为需要管理员审批，是消除这一整类风险最直接的手段。CISA SCuBA 云办公安全配置基线项目 针对主流云办公平台发布了安全配置基线，其中涉及应用授权与同意管控的条目可作为配置对照。
• 处置时的吊销顺序。先取证（导出授权详情与调用审计），再撤销同意，再吊销令牌，最后复查是否留下了转发规则等持久化。只吊销令牌而不查规则，等于清了入口留了后门。

检测是兜底，减少凭据被盗用的机会才是根本。NIST SP 800-63B 在口令与认证器管理上给出了若干与传统做法相反的建议，其中对运维最有价值的两点是：优先校验口令是否出现在已泄露口令集合中，而不是靠强制复杂度组合规则；以及不要强制周期性更换口令，除非有证据表明已被泄露。频繁更换会系统性地把用户推向可预测的变形，反而降低强度。

其他可落地的方向：

• 对提交通道启用多因素。如果协议路径不支持，则应当推动客户端迁移到支持的认证方式，而不是为兼容旧客户端而长期保留仅口令的通道。那条为兼容而保留的通道，就是所有攻击最终会走的那条。
• 应用专用凭据要能单独枚举与吊销。它们通常绕过多因素，是处置时最容易漏掉的一类。
• 失败认证的速率限制与账号锁定策略要区分对待：针对单账号的限制与针对单源地址的限制解决的是不同问题，只做其中一个会留下明显缺口。
• 把认证日志纳入统一留存。成功与失败都要留，且留存期要覆盖典型的发现延迟。NIST SP 800-61 Rev. 3《Incident Response Recommendations and Considerations for Cybersecurity Risk Management》 强调响应能力依赖事前的准备，日志留存正是其中最基础的一项。