6. Examples (示例)

本节包含若干 Security Considerations 章节示例, 旨在让读者体会本文档的意图.

第一个示例是 "回顾性" 示例, 将本文档的标准应用于广泛部署的现有协议 SMTP. 第二个示例摘自当前某协议的良好 Security Considerations 章节.

6.1. SMTP

撰写 RFC 821 时, RFC 尚不要求 Security Considerations 章节, 该文档也不包含此类章节. [RFC 2821] 更新了 RFC 821 并添加了详细的 security considerations 章节. 此处转载该文档的 Security Considerations 章节 (采用新的章节号). 我们的评论采用缩进并以 NOTE: 开头. 我们还添加若干新小节以涵盖我们认为重要的主题. 这些小节在章节标题中标注 [NEW].

6.1.1. Security Considerations (安全考量)

6.1.1.1. Mail Security and Spoofing (邮件安全与欺骗)

SMTP 邮件天生不安全, 因为即便是相当随意的用户也可以直接与接收和中继 SMTP 服务器协商并创建消息, 使朴素接收者相信邮件来自别处. 构造此类消息使 "欺骗 (spoofed)" 行为无法被专家检测要困难一些, 但还不足以阻止坚定且知情的人. 因此, 随着对互联网邮件的了解增加, 人们也越来越了解 SMTP 邮件天生无法在传输层认证或提供完整性检查. 真正的邮件安全仅存在于涉及消息体的端到端方法中, 例如使用数字签名的方法 (见 [14], 例如 PGP [4] 或 S/MIME [31]).

NOTE: 发送方认证的一种糟糕做法是 [IDENT], 其中接收邮件服务器联系声称的发送方并询问发送方的用户名. 由于中继, TCP 连接劫持以及源站简单撒谎等原因, 这是一个糟糕的主意. 除了 IDENT 安全价值低之外, 接收站点使用 IDENT 可能导致运维问题. 许多发送站点将 IDENT 请求丢弃 (blackhole), 导致邮件被搁置直到接收服务器的 IDENT 请求超时.

在传输层提供认证的各类协议扩展与配置选项 (例如从 SMTP 客户端到 SMTP 服务器) 在一定程度上改善了上述传统情形. 然而, 除非在精心设计的信任环境中谨慎交接责任, 它们仍然弱于使用数字签名消息而非依赖传输系统完整性的端到端机制.

使用户更难将信封返回路径与头部 From 字段设为指向非本人有效地址的努力在很大程度上是误入歧途: 它们妨碍了合法应用, 例如由一名用户代表另一名用户发送邮件, 或将错误 (或正常) 回复定向到特殊地址. (提供便于用户按消息更改这些字段的系统应尝试为用户建立主要且永久的邮箱地址, 以便在消息数据中合理生成 Sender 字段.)

本规范除倡导不因希望向试图伪造邮件的无知用户提供微薄保护而禁用有用功能外, 不再进一步讨论与 SMTP 相关的认证问题.

NOTE: 我们在第 6.1.2 节增加了关于通信安全与 SMTP 的额外材料. 在最终规范中, 上文会稍作编辑以反映该事实.

未出现在消息头中的地址可能出于多种原因出现在发往 SMTP 服务器的 RCPT 命令中. 两个最常见的原因是使用邮件地址作为 "列表展开器 (list exploder)" (单个地址解析为多个地址) 以及出现 "密送 (blind copies)". 尤其当存在多个 RCPT 命令时, 为避免部分抵消这些机制的目的, SMTP 客户端与服务器不应该将完整的 RCPT 命令参数集复制到头部中, 无论是作为跟踪头部的一部分还是作为信息性或私有扩展头部. 由于此规则在实践中常被违反且无法强制执行, 了解 bcc 用途的发送 SMTP 系统可以觉得将每个密送作为单独的消息事务发送有帮助, 该事务仅包含单个 RCPT 命令.

SMTP 事务 ("信封") 中的 "反向" (来自 MAIL, SAML 等命令) 或 "正向" (RCPT) 地址与头部中的地址之间没有内在关系. 接收系统不应该试图推断此类关系并用来

在投递时更改消息头部. 流行的 Apparently-to 头部既违反此原则, 又常常造成非预期的信息泄露, 不应该使用.

6.1.1.3. VRFY, EXPN, and Security (VRFY, EXPN 与安全)

如第 3.5 节所讨论, 各站点可能出于安全原因希望禁用 VRFY 或 EXPN 或两者. 作为上述推论, 允许此行为的实现绝对不能表现得好像已验证实际并未验证的地址. 若站点出于安全原因禁用这些命令, SMTP 服务器必须返回 252 响应, 而非可能与成功或失败验证混淆的代码.

在仅检查语法后在 VRFY 命令所列地址后返回 250 回复码违反此规则. 当然, 通过无论地址是否有效都始终返回 550 来 "支持" VRFY 的实现同样不合规.

在过去几年中, 邮件列表内容已成为所谓 "垃圾邮件发送者" 的地址信息来源. 随着列表管理员针对列表本身不当使用安装防护, 使用 EXPN "收割" 地址的情况有所增加. 实现仍应提供对 EXPN 的支持, 但站点应该仔细评估权衡. 随着向 SMTP 引入认证机制, 某些站点可能选择仅向已认证的请求者提供 EXPN.

NOTE: 不清楚禁用 VRFY 能增加多少保护, 因为常常可以用 RCPT TO 发现地址是否有效.

6.1.1.4. Information Disclosure in Announcements (公告中的信息披露)

关于在问候响应或对 HELP 命令的响应中公告服务器类型与版本 (有时甚至是服务器域名) 的调试优势, 与在潜在敌对攻击中暴露可能有用的信息之间的权衡, 一直存在持续争论. 调试信息的用处毋庸置疑. 主张提供这些信息的人认为, 实际保护 SMTP 服务器远比试图通过隐藏服务器精确身份来掩盖已知漏洞更能提供保护. 鼓励站点在考虑该问题时评估

权衡; 强烈鼓励实现至少以某种方式向其他网络主机提供类型与版本信息.

6.1.1.5. Information Disclosure in Trace Fields (跟踪字段中的信息披露)

在某些情况下, 例如当邮件源自其主机不直接在公共互联网上的 LAN 时, 按本规范生成的跟踪 (Received) 字段可能披露正常情况下不可用的主机名及类似信息. 这通常不成问题, 但对名称披露有特殊顾虑的站点应了解这一点. 此外, 涉及多个收件人时应谨慎提供可选的 FOR 子句或完全不提供, 以免无意中向他人披露 "密送" 收件人身份.

6.1.1.6. Information Disclosure in Message Forwarding (转发中的信息披露)

如第 3.4 节所讨论, 使用 251 或 551 回复码标识与邮箱关联的替换地址可能无意中披露敏感信息. 关心这些问题的站点应确保适当选择与配置服务器.

6.1.1.7. Scope of Operation of SMTP Servers (SMTP 服务器的操作范围)

SMTP 服务器可以出于任何对其有意义的运维或技术原因拒绝接受邮件, 这是公认原则. 然而, 站点与安装之间的协作使互联网成为可能. 若站点过度利用拒绝流量的权利, 电子邮件的普遍可用性 (互联网的优势之一) 将受到威胁; 若站点决定对接受的流量有所选择, 应极其谨慎并保持平衡.

近年来, 通过任意站点使用中继功能已成为敌对行为隐藏邮件真实来源的一部分. 某些站点已决定将中继功能的使用限制为已知或可识别的来源, 实现应提供执行此类过滤的能力. 当出于这些或其他策略原因拒绝邮件时, 应在回应 EHLO, MAIL 或 RCPT 时使用 550 代码 (视情况而定).

6.1.1.8. Inappropriate Usage (不当使用)

SMTP 本身不提供针对未经请求的商业批量电子邮件 (即垃圾邮件) 的防护. 事先判断给定消息是否为垃圾邮件极其困难. 从协议视角, 垃圾邮件与其他电子邮件无法区分, 区别几乎完全是社会性的且常常相当微妙. (例如, 来自你曾购物的商家推销类似商品的消息算不算垃圾邮件?) SMTP 反垃圾邮件机制一般限于识别已知垃圾邮件发送者并拒绝为其服务或对其惩罚/断连. [RFC-2505] 对使 SMTP 服务器抗垃圾邮件提供了广泛指导. 此处简要讨论该主题.

拒绝为垃圾邮件发送者服务的主要工具是黑名单. 诸如 [MAPS] 等机构收集并公布已知垃圾邮件发送者列表. 各个 SMTP 服务器随后阻止黑名单上的违规者 (通常按 IP 地址).

为避免被列入黑名单或以其他方式被识别, 垃圾邮件发送者常常试图掩盖身份, 要么简单发送虚假的 SMTP 身份, 要么通过 Open Relay (开放中继) 转发邮件, 即为任何发送者执行邮件中继的 SMTP 服务器. 因此, 现在也存在开放中继的黑名单 [ORBS].

6.1.1.8.1. Closed Relaying (封闭中继)

为避免被用于垃圾邮件转发, 许多 SMTP 服务器作为 closed relays (封闭中继) 运行, 仅对能够识别的客户端提供中继服务. 此类中继一般应坚持发送者宣告的发送地址与其已知身份一致. 若中继为可识别网络 (如公司网络或 ISP 网络) 提供服务, 则阻止所有其他 IP 地址通常已足够. 在其他情况下, 必须使用显式认证. 两种标准选择是 TLS [STARTTLS] 与 SASL [SASLSMTP].

6.1.1.8.2. Endpoints (端点)

现实地说, SMTP 端点不能拒绝对未认证发送者的服务. 由于绝大多数发送者未认证, 这会破坏互联网邮件互操作性. 例外情况是端点服务器应仅从另一台也能接收未认证消息的服务器接收邮件. 例如, 公司可能运营公共网关, 但将其内部服务器配置为仅与网关通信.

6.1.2. Communications security issues (通信安全问题)

SMTP 本身不提供通信安全, 因此大量攻击是可能的. 被动攻击足以恢复以 SMTP 传输的消息文本. 协议不提供端点认证. 发送方欺骗轻而易举, 因此伪造电子邮件也轻而易举. 某些实现确实添加通过反向名称解析得到的主机名头部行 (其安全性仅取决于伪造 DNS 的难度, 并不高), 尽管这些头部行通常不向用户显示. 接收方欺骗也相当直接, 要么使用 TCP 连接劫持要么使用 DNS 欺骗. 此外, 由于电子邮件消息常常经过 SMTP 网关, 所有中间网关都必须被信任, 在全球互联网上这几乎不可能.

有多种途径可缓解这些威胁. 按协议栈层级从低到高, 我们有:

SMTP over IPSEC, SMTP/TLS, S/MIME 与 PGP/MIME.

6.1.2.1. SMTP over IPSEC

在 IPSEC 上运行的 SMTP 连接可以为发送方与第一跳 SMTP 网关之间或任意一对相连的 SMTP 网关之间的消息提供机密性. 也就是说, 它为 SMTP 连接提供信道安全. 在消息直接从客户端到接收方网关的情形下, 这可能提供实质性安全 (尽管接收方仍须信任网关). 由于数据本身受保护且分组无法重放, 可提供对重放攻击的防护.

然而, 除非接收方地址可以直接经密码学认证, 否则端点标识存在问题. 发送方标识一般不可用, 因为通常只认证发送方的机器而非发送方本人. 此外, 发送方身份只是出现在消息的 From 头部, 发送方易于伪造. 最后, 除非安全策略设置得极其严格, 还存在主动降级到明文的攻击.

将 IPsec 作为 SMTP 安全解决方案的另一问题是缺乏标准 IPsec API. 为利用 IPsec, 应用一般需能指示 IPsec 实现其安全策略并发现对其连接应用了何种保护. 没有标准 API 很难可移植地做到这一点.

SMTP 服务器实现者或 SMTP 管理员绝对不能假定 IPsec 可用, 除非有理由相信其可用 (例如两台机器之间已存在预先建立的关联). 然而, 在投递邮件时尝试与对等服务器机会性地创建 IPsec 关联可能是合理流程. 注意, 在 IPsec 用于在两站点之间提供 VPN 隧道的情况下, 这具有实质性安全价值, 尤其在提供机密性的范围内, 但需考虑上述注意事项. 另见 [USEIPSEC] 关于 IPsec 适用性的一般指导.

6.1.2.2. SMTP/TLS

SMTP 可按 [STARTTLS] 所述与 TLS 结合. 这提供与使用 IPSEC 时类似的保护. 由于 TLS 证书通常包含服务器主机名, 接收方认证可能稍微更明显, 但仍易受 DNS 欺骗攻击. 尤其常见 TLS 实现包含美国可出口 (因而低安全) 模式. 需要高安全的应用应确保禁用此模式. 由于数据本身受保护且分组无法重放, 可提供对重放攻击的防护. Note: SMTP over TLS 文档的 Security Considerations 章节相当出色, 值得作为范例阅读.

6.1.2.3. S/MIME and PGP/MIME

S/MIME 与 PGP/MIME 均为面向消息的安全协议. 它们为单条消息提供对象安全. 在不同设置下, 可提供发送方与接收方认证以及机密性. 更重要的是, 标识针对的是发送方与接收方本人, 而非发送与接收机器. (或者, 至少是针对与发送方与接收方对应的密码学密钥.) 因此, 可以获得端到端安全. 注意, 然而, 未提供对重放攻击的防护. 另注意 S/MIME 与 PGP/MIME 一般为发送方与接收方都提供可识别标记. 因此即便提供机密性, 仍可能进行流量分析.

6.1.3. Denial of Service (拒绝服务)

这些安全措施都不能真正防护拒绝服务. SMTP 连接可以多种方式轻易占用系统资源, 包括过度消耗端口, 过度磁盘使用 (电子邮件通常投递到磁盘文件) 以及过度内存消耗 (例如 sendmail 相当大, 通常为每条消息 fork 新进程.)

若对 SMTP 连接使用传输层或应用层安全, 则可以使用伪造 RST 或其他分组注入对单个连接发起多种攻击.

6.2. VRRP

第二个示例来自 VRRP, 即 Virtual Router Redundancy Protocol (虚拟路由器冗余协议) ([VRRP]). 此处转载该文档的 Security Considerations 章节 (采用新的章节号). 我们的评论采用缩进并以 NOTE: 开头.

6.2.1. Security Considerations (安全考量)

VRRP 面向可能采用不同安全策略的一系列互联环境而设计. 协议包含若干认证方法, 从无认证, 简单明文口令, 到使用 IP Authentication 与 MD5 HMAC 的强认证. 每种方法的细节, 包括可能的攻击与建议环境, 见下文.

独立于任何认证类型, VRRP 包含一种机制 (发送时设 TTL=255, 接收时检查), 防止从其他远程网络注入 VRRP 分组. 这将大多数漏洞限制为本地攻击.

NOTE: 以下各节讨论的安全措施仅提供各类认证. 完全不提供机密性. 应明确描述为超出范围.

6.2.1.1. No Authentication (无认证)

使用此认证类型意味着 VRRP 协议交换未经认证. 此认证类型应该仅用于安全风险极小且配置错误机会很小的环境 (例如 LAN 上的两台 VRRP 路由器).

6.2.1.2. Simple Text Password (简单文本口令)

使用此认证类型意味着 VRRP 协议交换通过简单明文口令认证.

此认证类型有助于防护 LAN 上路由器的意外错误配置. 它防止路由器无意中为另一台路由器做备份. 新路由器必须首先配置正确口令才能与另一台路由器一起运行 VRRP. 此认证类型不能防护口令可被通过嗅探 LAN 上 VRRP 分组的节点学得的敌对攻击. 简单文本认证与 TTL 检查相结合, 使从另一 LAN 发送 VRRP 分组以干扰 VRRP 操作变得困难.

当 LAN 上的节点主动干扰 VRRP 操作的风险极小时, 推荐使用此认证类型. 若使用此认证类型, 用户应意识到此明文口令发送频繁, 因此不应与任何有安全意义的口令相同.

NOTE: 本节应更清楚. 基本要点是无认证与简单文本仅对非常有限的威胁模型有用, 即 LAN 上没有任何节点是敌对的. TTL 检查防止离 LAN 的敌对节点冒充合法节点, 但无法阻止 LAN 上的敌对节点冒充授权节点. 这在许多情形下并不是特别现实的威胁模型. 特别地, 它极其脆弱: LAN 上任何节点被攻陷都允许重新配置 VRRP 节点.

6.2.1.3. IP Authentication Header (IP 认证头)

使用此认证类型意味着 VRRP 协议交换使用 IP Authentication Header [AH] 与 [HMAC] 定义的机制认证. 这为配置错误, 重放攻击以及分组损坏/篡改提供强防护.

当对 LAN 上节点的管理控制有限时, 推荐使用此认证类型. 虽然此认证类型保护 VRRP 的操作, 仍存在可在共享介质链路上使用的其他攻击类型 (例如生成伪造 ARP 应答), 这些与 VRRP 无关且不受保护.

NOTE: 在此上下文中将 AH 标为推荐是一个错误. 由于 AH 是唯一保护 VRRP 免受同一 LAN 上其他节点攻击的机制, 在存在不可信节点的情况下它应该是必须的. 无论如何, AH 应该是必须实现 (MUST implement) 的.

NOTE: 本文档仅暗示的一项重要安全分析是 VRRP 认证的成本/收益权衡.

[本节其余部分为新材料] VRRP 认证旨在防止的威胁是攻击者安排自己成为 VRRP master (主路由器). 这可能通过加入组 (可能多次), 压制 master 然后选自己为 master 来完成. 此类节点随后可以任意不良方式引导流量.

然而, 攻击者不必成为 VRRP master 也能做到这一点. 攻击者可以通过伪造 ARP 分组或 (在交换网络上) 欺骗交换机对网络造成类似损害. VRRP 认证对这些攻击没有真正的防护.

遗憾的是, 认证使 VRRP 网络在配置错误面前非常脆弱. 考虑两个节点配置了不同口令时会发生什么. 各方将拒绝来自对方的消息因此都会试图成为 master. 这会造成严重的网络不稳定.

这组成本/收益权衡表明 VRRP 认证不是好主意, 因为增量安全收益微不足道但增量风险很高. 若当前非 VRRP 威胁集合被消除, 应重新审视此判断.