SPF 洋葱：走进 SPF 混乱的世界-优快云博客

作者：
Ed Gibbs，WHOIS API Inc. 首席技术官
Jeff Vogelpohl，Outackle

引言

2024年9月25日的深夜，我在个人邮箱中收到了一封可疑的电子邮件。邮件伪装得非常巧妙，仿佛来自我当前合作的一家保险公司，但我感觉有些不对劲——公司标志看起来有些不同。通常，我会通过点击图标来检查发件人的电子邮件地址，但这次却无法弹出信息。察觉到异常，我决定深入调查。

在查看邮件的文本信息后——是的，就是那些几乎需要博士学位才能理解的SMTP数据长串！——我发现隐藏在这些数据中的发件人信息和一些安全检查，这些检查居然全都通过了，使这封邮件穿过了电子邮件提供商通常用来拦截垃圾邮件和网络钓鱼邮件的多层保护。

快速检查了SPF、DKIM和DMARC——全部通过了。

简而言之，邮件正文包含不可打印字符、Base64编码以及其他一些坏人常用的规避检测的手段。我与几位电子邮件安全专家交谈过：一位来自知名安全公司，提供了关于这封邮件如何绕过安全检查的见解；另一位每天都处理此类攻击。他们都提到了一个知名但常被忽视的问题：SPF链接。来自Outackle的杰夫·沃格波尔称其为“SPF洋葱”——一张复杂的IP地址和域名链接网，很快就会变得难以管理。

什么是SPF洋葱？

在不断发展的电子邮件安全领域，发件人策略框架（SPF）长期以来都是一项基础工具。SPF的设计目的是验证声称来自某个域的电子邮件确实是由授权的邮件服务器发送的，从而防止欺骗和网络钓鱼攻击。然而，随着组织的发展，其SPF记录往往会演变为更加复杂的结构——一个包含众多相互链接的IP地址和域名的复杂网络。我们称之为“SPF洋葱”，它代表了SPF记录中层层叠叠、难以管理的结构，这既是一个安全挑战，也带来了运营难题。

SPF洋葱的层次

SPF记录的核心是域名系统（DNS）中的一个简单文本条目。它通常包含如ip4、ip6和include等机制，用于指定被授权代表某个域发送邮件的IP地址或域名。当SPF记录被妥善管理时，它是简洁明了的，仅包含必要的验证细节。

然而，就像洋葱的多层结构一样，SPF记录会随着时间的推移而扩展，越来越复杂，因为越来越多的第三方服务、邮件服务器和云服务被加入其中。每一层的增加，往往未经深思熟虑，会带来自己的IP地址和域名，导致一个复杂、多层次的结构。随着组织将服务外包给如营销、CRM和客户支持等第三方，其SPF记录的深度和复杂性不断增加。每个第三方服务可能拥有自己的SPF记录，可以通过include指令引用，这便形成了所谓的“SPF链”，一个SPF记录包含另一个，而后者又包含另一个，如此不断递归。很快，记录就变成了SPF洋葱。

层次的深度有多深？

技术上，SPF标准（RFC 7208）对SPF验证期间的DNS查找次数有严格的限制，最多为10次。这一限制包括所有导致DNS查找的include、a、mx、ptr、exists和redirect机制。可以想象，如果一条记录引用了多个外部服务，每个服务都进行DNS查找，很容易超出这一限制。

例如，一家公司的SPF记录可能以通常的ip4或ip6机制开始，以定义其授权的邮件服务器。但随后它添加了用于第三方电子邮件营销服务的include，而该服务可能又有自己的一组SPF记录。该服务进一步引用其基础设施的另一个域。这可能会导致SPF链超出10次查找限制，层层叠叠，几乎无法理清。

这些埋藏的层次可能变成腐烂的SPF洋葱。

安全性和性能影响

乍看之下，这些逐层增长的SPF记录似乎无害——毕竟，只要SPF记录通过验证，电子邮件就应该被正常投递，对吧？不幸的是，SPF记录越深、越复杂，它就越脆弱。

首先，超出10次查找限制将导致SPF检查失败，产生“permerror”（永久性错误）。此类失败可能导致合法邮件被拒绝或被标记为垃圾邮件，特别是在依赖深度嵌套的SPF记录的服务发送的邮件时。

其次，管理多层次的SPF记录带来了重大安全风险。一个SPF洋葱可能包含组织无法控制的外部域名。如果其中一个第三方域名被攻破，攻击面便扩大，坏人可以利用链条中的薄弱环节。简而言之，SPF记录的层次越多，暴露于组织外部的威胁的可能性就越大。

最重要的是，SPF管理需要持续的主动防范，以防止未经授权的通信源于这些所谓的腐烂SPF记录，这些记录构成了SPF洋葱。

管理噩梦

除了安全风险，维护一个SPF洋葱也是一种运营上的痛苦。IT管理员必须追踪包括的第三方服务，确保其保持更新，并检查潜在的漏洞。当这些服务更改基础设施、弃用IP地址或修改SPF记录时，挑战变得更加严峻。突然之间，一个本应简单的更新变成了剥开一个不断增长的SPF洋葱的层次，每一层都需要更多的调查和关注。

此外，每增加一个include指令，就延长了SPF链，使得在出现邮件投递问题时排查问题变得困难。往往不清楚是哪一层导致了问题，管理员不得不通过日志和DNS记录查询来找出错误。

剥开层次：如何管理SPF洋葱

有效管理SPF洋葱需要采取积极的措施。以下是保持SPF记录精简和可管理的几个关键策略：

合并服务：尽量将多个第三方服务整合到一个供应商之下，以减少include指令的使用并简化SPF管理。
监控DNS查找：定期审核SPF记录以检查触发的DNS查找次数。如果接近限制，寻找简化记录的方法。
使用子域：对于复杂的组织，将SPF记录分布到子域中可能是一个好策略。通过将不同功能（例如营销、CRM）分配给单独的子域，可以更好地控制每个记录所需的查找次数。
使用DMARC和DKIM：虽然SPF很重要，但它并非唯一的电子邮件认证工具。与SPF一同部署DMARC（基于域的消息认证、报告和一致性）和DKIM（域密钥识别邮件）可以提供更强的安全防护，不必将所有压力都放在SPF验证上。

SPF洋葱的实例

在这个例子中，我们会用一个假域名，例如“Not Suitable for Work”，来看它的SPF记录：试着跟着它看看…我们会等着。”

v=spf1 ip4:89.185.250.240/28 ip4:66.232.98.202 ip4:104.156.55.80/28 ip4:162.213.194.160/29 ip4:194.15.114.40/29......ip4:217.156.66.0/24 ip4:86.106.113.0/24 ip4:141.98.117.32/27 ip4:204.10.163.64/27 -all

邮件开头示例

在此示例中，这封邮件恰好在审核本文档时到达，明显带有网络钓鱼的特征，但让我们看看以下的邮件头信息：

让我们开始查看这些洋葱层：

ogcge.opencart-service.ru
v=spf1 include:instanttranslates.dynu.net include:informationshout.dynu.net -all

instanttranslates.dynu.net
v=spf1 include:justifyintegrated.accesscam.org include:handlerhedriver.accesscam.org include:occupationsociety.casacam.net include:commemorate.ddnsfree.com include:requestdistort.ddnsgeek.com include:strategicpromote.freeddns.org include:biographydetermine.giize.com include:compartmentrelevance.gleeze.com include:multimediatan.kozow.com -all

以下图表总结了初始层及其检测到的 SPF 条目——显然通过设计混淆了内容：

SPF记录分析见解：年度回顾

通过过去365天对SPF记录的分析，我们使用被动DNS TXT记录数据库的数据，揭示了电子邮件安全状态的重要洞见。我们共分析了736,363,363条DNS TXT记录，其中有显著的464,975,836条被识别为SPF记录。这些数字表明SPF已被广泛采用，作为电子邮件身份验证和垃圾邮件防范的重要工具。

然而，这些SPF记录的复杂性揭示了更深层次的问题。我们的研究发现，有1,808,746条SPF记录包含超过10个条目（包括IP地址和域名的组合），这表明配置过于复杂。我们称这些为“SPF洋葱”，因为SPF记录的层数越多，管理、监控和排查问题就越困难。每一层都会增加潜在的漏洞，延长DNS查询时间，并可能引入导致电子邮件验证失败的错误。

另一方面，大多数SPF记录——共计463,167,090条——包含10个或更少的条目，表明大多数域的SPF复杂性保持在可控范围内。然而，这并不意味着它们完全没有安全风险，因为即使是较为简单的SPF记录也可能配置错误，无法完全防御钓鱼和伪造攻击。

我们遇到的最长的SPF记录包含166个条目，这是一个极端的例子，显示了SPF记录膨胀的潜在可能性。这样的记录不仅难以维护，而且很可能超出标准的DNS查询限制，从而导致邮件投递失败或出现安全漏洞。

这些发现强调了持续监控和管理SPF记录以维护电子邮件安全和性能的重要性。数据表明，组织需要定期审查和优化其SPF配置，以确保其不仅符合标准，还能优化安全性。

SPF 记录的建议

根据发件人策略框架 (SPF) 规范 (RFC 7208)，SPF 记录的限制主要在于 DNS 查询次数，而不是单个条目的数量（如 IP 地址或机制）。SPF 协议允许最多 10 个基于 DNS 的机制或修饰符，这些机制会执行 DNS 查询（例如 a、mx、ptr、include、exists、redirect），但不包括不会触发 DNS 查询的机制，如 ip4 或 ip6。

关键限制：

DNS 查询限制：SPF 实现必须限制 DNS 查询次数至 10，以防止基于 SPF 的拒绝服务攻击。这包括由 a、mx、ptr、include、exists 和 redirect 机制执行的查询。
记录大小：整个 SPF 记录不应超过 512 字节（某些旧邮件服务器可能有更严格的限制），尽管 DNS 协议允许 TXT 记录的大小上限为 65535 字节。
机制/条目数量：对于不需要 DNS 查询的机制，如 ip4 或 ip6，数量没有严格限制。但应保持 SPF 简单，以避免错误并符合建议的大小限制。

如果存在超过 10 次 DNS 查询会怎样？

如果 SPF 检查产生的 DNS 查询超过 10 次，查询将失败并返回“permerror”（永久性错误），这意味着 SPF 检查不会成功，邮件可能会被拒收或标记为潜在欺诈邮件，具体取决于收件方邮件服务器的策略。

利用 WhoisXML API 工具集应对 SPF Onion 复杂性

在应对电子邮件安全和 SPF 记录复杂性的过程中，可靠的数据来源和工具至关重要。随着我们进一步研究“SPF Onion”现象（SPF 记录因域、IP 地址和第三方服务的层层嵌套而变得复杂），WHOISXMLAPI.com 成为提供关键资源以发现、管理和保护 SPF 记录的重要角色。

WHOISXMLAPI.com 提供了一系列强大的 API，可提供 DNS 记录、所有者信息、IP 地理位置和历史 DNS 数据的有价值见解。以下是 WHOISXMLAPI.com 提供的四个主要产品，可显著增强我们分析并缓解 SPF 记录复杂性挑战的能力。

DNS Lookup API：获取用于 SPF 分析的 DNS TXT 记录了解 SPF Onion 的第一步是获取特定域的 DNS TXT 记录。WHOISXMLAPI.com 的 DNS Lookup API 是完成此任务的必备工具。该 API 允许我们查询任何域的 DNS 记录，包括存储 SPF 信息的关键 TXT 记录。
WHOIS API：识别与 SPF 相关域的所有者在处理 SPF Onion 尤其是涉及多个第三方服务的情况时，了解 SPF 记录中引用的域的控制方至关重要。WHOIS API 提供详细的域所有者信息，包括注册人联系方式、注册日期和管理信息。
IP Geolocation API：追踪 SPF 记录的地理分布了解 SPF 记录中引用的 IP 地址的地理分布是分析的重要部分。WHOISXMLAPI.com 提供的 IP Geolocation API 使我们能够获取每个 IP 地址的详细信息，包括物理位置、ISP（互联网服务提供商）、国家和时区。
DNS Premium Data Feed：使用被动 DNS 进行广泛研究 WHOISXMLAPI.com 的 DNS Premium Data Feed 是一项强大的资源，被动 DNS 数据库提供了来自全球的历史 DNS 数据。

这些工具在 SPF Onion 项目中的应用

利用 WHOISXMLAPI.com 的工具集，我们可以全面分析和管理 SPF Onion 研究中的 SPF 记录。以下是每个 API 的具体作用：

DNS Lookup API：实时获取任意域的 SPF 记录，以绘制 IP 地址和域的相互关联。
WHOIS API：识别 SPF 记录中引用的域的所有者，帮助追踪负责 SPF 配置的实体并评估其可信度。
IP Geolocation API：提供与 SPF 记录中 IP 地址相关的地理位置信息，以检测异常。
DNS Premium Data Feed：提供历史和被动 DNS 数据，使我们能够在互联网上进行大规模 SPF 记录研究并检测 SPF Onion 的模式和风险。