使用发件人验证来识别欺骗邮件 | SPF、DKIM、DMARC、Exchange 和 Exchange Online |第 8 部分#9
欺骗邮件攻击是由敌对分子试图欺骗发件人身份来实施的。处理欺骗邮件攻击的方法是,通过应用程序来检查和验证发件人身份(检查发件人是否认为是欺骗发件人的合法发件人)。
使用 SPF、DKIM 和 DMARC、Exchange 和 Exchange Online 验证发件人身份
在本文中,我们将回顾以下基础设施实现发件人验证过程的方式:
- 邮件发件人验证标准 - SPF、DKIM 和 DMARC。
- 基于 Exchange 的环境 - 通过使用发件人身份验证状态。
- 基于 Exchange Online (EOP) 的环境 - 通过使用网络钓鱼过滤器功能
本文的主要重点是了解发件人的“身份概念”,以及用于“存储”发件人身份的特定邮件字段。
在下一篇文章-中,我们的主要关注点是我们将回顾由每种不同方法实现的发件人验证过程的“流程”。
用于发件人验证的主要公共邮件标准+基于 Exchange 的环境中的可用选项。
我们可以使用的可用发件人验证方法的一般分类可以是:
1.处理发件人验证的公共邮件标准。
在这个“组”中,我们可以涉及三个主要的流行标准:
- SPF(发件人策略框架)。
- DKIM(域名密钥识别邮件)。
- DMARC(基于域的消息身份验证、报告和一致性)。
2.基于交换的环境
在这个组中,我们可以涉及一个解决方案,该解决方案可以帮助我们通过使用有关发件人的信息来实现发件人验证过程,其中包括他的身份验证状态+他的域名(出现在电子邮件地址上的域名) 。
“交换方式”仅适用于发件人电子邮件地址包含我们的域名的传入邮件的场景。
在这种情况下,我们可以通过检查发件人的身份验证状态来验证发件人的身份。
内部或匿名发件人
我们用于确定发件人是否“有效”的方法是 - 通过查看 X-MS-Exchange-Organization-AuthAs 邮件中“存储”的值场地。
使用上述邮件字段与任何基于 Exchange 的环境相关,包括依赖于 Exchange Online 的 Office 365。
此方法背后的概念是通过查看有关收件人的身份验证信息的状态来实现的,这些信息存储在 X-MS-Exchange-Organization-AuthAs 邮件字段中。
基本假设是,电子邮件地址包含我们组织域名的收件人应显示为经过身份验证的收件人,即提供用户凭据的用户。
如果电子邮件地址中包含我们域名的收件人的状态为“匿名”。这表明发件人身份存在一些“问题”。
3.基于 Exchange Online 的环境(EOP - Exchange Online Protection)|网络钓鱼过滤器
EOP(Exchange Online 保护)包括一种称为网络钓鱼过滤器的方法。
EOP网络钓鱼过滤器的机制基于以下概念:EOP 服务器验证MAIL FROM 中出现的发件人信息,并在 FROM 字段中。
- 如果信息相同,则发件人视为“有效发件人”。
- 如果信息不相同,发件人将视为“无效发件人”。
注意:这两种方法都只能针对“传入邮件”实现。换句话说,在收件人向外部收件人发送电子邮件的情况下,我们无法使用此方法来“保护”收件人的身份。
我们到底如何定义“发送者”?
1. SPF和DKIM标准
SPF 和 DKIM 标准通过与发件人的电子邮件地址相关来定义“发件人身份”。
如果我们想更准确的话,SPF标准指的是电子邮件地址含义的“正确部分”,即域名,而DKIM标准指的是“整个电子邮件地址”。
- SPF 标准与出现在MAIL FROM 邮件字段(出现在邮件信封上的信息)中的发件人电子邮件地址相关。
- DKIM 标准与出现在 FROM 邮件字段(出现在邮件标题中的信息)中的发件人电子邮件地址相关。
2. DMARC
DMARC 标准依赖于 SPF 或 DKIM 标准,作为实现发件人验证的机制。
DMARC 标准关于验证发件人身份的主题的附加值是通过使用与发件人验证相关的附加测试“层”来实现的。换句话说,DMARC 标准执行更严格的验证测试。
例如,当我们使用DMARC标准时,DMARC将检查电子邮件是否通过SPF检查。即使 SPF 检查状态为“通过”,DMARC 也会执行附加测试,称为“对齐”,其中检查 MAIL FROM 字段中出现的电子邮件是否等于发件人字段中显示的电子邮件地址
3.基于交换的环境|收件人身份验证状态。
在基于 Exchange 的环境中,我们可以使用附加的“安全信息”,该信息出现在电子邮件消息(邮件标头)中,告诉我们收件人是否被视为经过身份验证的收件人。
欺骗邮件攻击的“形式”之一是攻击者使用“我们的组织身份”(包含我们域名的电子邮件地址)来攻击我们的用户。
在这种情况下,我们可以使用存储在 X-MS-Exchange-Organization-AuthAs 邮件字段中的信息来识别“欺骗邮件攻击”(欺骗发件人)事件。
我们的基本假设是每个用户都应该提供他的用户凭据。
在欺骗邮件攻击的情况下,使用我们组织用户之一身份的敌对元素不提供 ant 凭据。
例如,如果发件人电子邮件地址包含我们的组织域名+发件人视为未经身份验证的用户(匿名),则这是欺骗电子邮件的“标志”。
4. Exchange Online - 网络钓鱼过滤器
术语“网络钓鱼过滤器”描述了 EOP 服务器用于识别可能的欺骗邮件事件的特定过滤器。这是一种欺骗电子邮件识别机制;适用于使用 EOP(Exchange Online Protection)作为独立版本的 Office 365 客户。
EOP 实现的网络钓鱼过滤器机制的作用类似于应用于 SPF 的 DMARC 对齐概念。
EOP 网络钓鱼过滤器 验证 MAIL FROM 字段中显示的电子邮件地址(发件人身份)是否与 FROM 中显示的发件人身份相同 领域。
发件人身份存储在哪里以及发件人身份验证流程如何实施?
1. SPF标准
SPF发件人身份验证按以下方式执行:
代表目标收件人的邮件服务器从发件人的
电子邮件地址“获取”域名,发件人出现在MAIL FROM字段中。
目标邮件服务器通过检查源邮件服务器是否被授权代表特定域发送电子邮件来验证发件人身份。
通过使用专用 SPF 记录(TXT 记录)实现的验证过程,其中包括特定域的授权邮件服务器的 IP 地址。
2. DKIM标准
DKIM 发件人身份验证通过以下方式实现:
代表目标收件人的邮件服务器“获取”发件人的电子邮件地址,发件人出现在发件人字段中。
目标邮件服务器通过检查邮件标头中显示的数字签名来验证发件人身份。
3. DMARC
DMARC 标准依赖 SPF 或 DKIM 标准作为实现发件人验证的机制。
DMARC 标准的目的是 - 验证通过 SPF 或 DKIM 执行发件人验证所接受的结果。
如果结果为“OK”(发件人验证状态为“通过”),则 DMARC 发件人验证过程“继续”到描述为“对齐”的下一步。
关于 SPF 结果 - DMARC 验证 MAIL FROM 字段中显示的电子邮件地址是否与 FROM 字段中显示的电子邮件地址相同。
关于 DKIM 结果 - DMARC 验证 DKIM 选择器域名是否与发件人的域名相同。
注意:DMARC 标准包括扩展发件人验证任务管理的附加功能和组件。
例如 - DMARC DNS 记录,包括对“另一个邮件基础设施”的“说明”,以防他们将包含我们域名的电子邮件识别为欺骗电子邮件。
“说明”包括我们关于以下方面的建议: “如何处理此电子邮件”,例如忽略、隔离或阻止。
4.基于交换的环境|收件人身份验证状态。
寻址 Exchange 服务器的“发件人”可以是
- 来自任何组织、要求向 Exchange 服务器上托管的收件人发送电子邮件的任何发件人
- 邮箱托管在 Exchange 上的 Exchange 用户
在“发件人”使用包含 Exchange 服务器上托管的域名的电子邮件地址的情况下,基本假设是 - 这是一个“Exchange 用户”,拥有交换邮箱。因此,这个“用户”应该通过提供用户凭证来证明他的身份。
有关身份验证过程的信息由 Exchange 保存在名为 - X-MS-Exchange-Organization-AuthAs 的专用邮件字段中
- 如果用户提供其凭据,则接收者的身份验证状态为“内部”。
- 如果用户未提供其凭据,则收件人的身份验证状态为“匿名”。
在发件人“声称”他属于 Exchange 组织的情况下,这意味着他使用电子邮件地址,其中包括托管在 Exchange 上的域名,但发件人没有提供他的凭据;这表明发件人可能是欺骗性发件人。
换句话说,保存在 X-MS-Exchange-Organization-AuthAs 字段中的发件人状态显示为匿名。
5. Exchange Online - 网络钓鱼过滤器
EOP(Exchange Online Protection)包括内置的过滤机制(网络钓鱼过滤器),创建该机制是为了识别很可能是欺骗邮件的电子邮件事件。
EOP 网络钓鱼过滤器的工作方式与 SPF 相关实施的 DMARC 对齐概念类似。
EOP 网络钓鱼过滤器会验证
MAIL FROM 中显示的电子邮件地址(发件人身份)是否与 FROM 邮件中显示的发件人身份相同场地。
如果存在差异,则将使用警告消息“标记”该电子邮件消息,通知用户该电子邮件可能是欺骗邮件。
发件人验证邮件标准和基于 Exchange 的解决方案之间的主要区别。
如前所述,当我们进入“欺骗电子邮件攻击战”时,有多种武器可供选择。
其中一些“武器”是公共邮件标准,可以适应任何邮件基础设施,其中一些只能在基于 Exchange 邮件服务器或 Exchange Online(Office 365 客户)的邮件基础设施的情况下使用。
基于 Exchange 的解决方案与“公共邮件标准”之间的主要区别是:
1. DNS配置设置
当我们使用基于 Exchange 的机制来识别欺骗电子邮件事件时,无需使用其他设置(例如 DNS 记录)。
2.传入邮件流
基于 Exchange 的解决方案的机制,用于识别欺骗邮件事件,只能针对以下场景实施: - 传入邮件。
含义是 - 敌对分子试图“攻击” Exchange 收件人的事件。
使用 SPF、DKIM 和 DMARC 来保护我们自己,防止敌对分子使用我们的身份。
简单提醒一下,“欺骗邮件”问题可以通过两种主要方式来实现:
- 情况 1 - 敌对分子通过发送
欺骗邮件来攻击我们的用户的情况。 - 情况2 - 敌对分子利用我们的组织身份(包含我们域名的电子邮件地址)攻击其他组织的情况。
当使用 SPF 和 DKIM 等公共邮件标准时,我们有能力“宣布”其他组织,发件人使用我们域名的特定电子邮件是否是合法电子邮件。
例如,当使用SPF时,我们可以通知其他组织,这些组织是可以代表我们的域名发送电子邮件的授权邮件服务器。
此外,某些邮件站(例如 SPF 和 DMARC)使我们能够指示另一个邮件基础设施“做什么”,以防我们的收件人之一看似发送的电子邮件不是从授权的邮件服务器发送的。
Exchange 和 Exchange Online 选项不包含可在此类出站邮件场景中使用的机制。
识别欺骗电子邮件的最佳选项是什么?
在不了解您个人的情况下,我很确定在阅读完上述所有信息后,您的脑海中可能会出现以下问题:
问:底线是什么?哪一个是适合我的组织的“正确工具”?
A:我的答案包括几个部分:
有总比没有好
最好从实施至少一种邮件发件人验证标准开始,而不是“什么都不做”,让您的组织邮件基础设施面临各种风险和危险。
使用特定的发件人验证机制与多种机制的组合
理论上,我们只能对一种“选择的”邮件标准或机制感到满意
例如 - SPF、DKIM 或一种 Exchange 选项。
实际上,“正确的解决方案”需要基于多个标准,因为不同的标准相互补充,并且每个标准都涵盖其他或不同类型的欺骗邮件场景。
婴儿步|一步一步
最佳实践是从简单的发件人验证标准开始,只有在我们感到舒服之后,“继续”到我们实施附加标准的下一步。
我的观点是,最简单的选择是——从实施SPF标准开始,因为SPF标准可以说是一个相对容易实施的标准。
如果您的邮件基础设施基于 Exchange 基础设施,建议还添加“附加层”,我们在其中使用 Exchange 规则,该规则可识别传入邮件中包含拥有我们的电子邮件地址但不知道我们的电子邮件地址的发件人的事件。不提供用户凭据。
如果您想了解有关如何使用欺骗电子邮件规则实现“Exchange 选项”的更多信息,可以阅读文章 - 使用 Exchange Online 规则检测欺骗电子邮件并发送事件报告(学习模式) ) |第 2 部分#12
那么,发件人识别标准\选项的最佳组合是什么?
答案是——没有一种特定的“鸡尾酒”可以形容为“最好的鸡尾酒”。
例如——一个合理的问题可以是——
Q1:为什么不使用所有可用的选项?
Q2:我们可以使用“越多越好”的概念吗?
A:答案是“是”和“否”。
从理论上讲,最好使用所有可用于识别欺骗电子邮件事件的可用选项,但我们不应忘记,每个“标准”或“机制”都需要自己的资源。
需要分配的资源:
- 学习并实施每个“发件人验证解决方案”所需的配置设置
- 正在进行的任务,例如 - 监视由特定标准“捕获”的欺骗邮件事件 - 需要审查和检查被识别为欺骗邮件的电子邮件项目以及需要决定如何处理该邮件电子邮件项目。
发件人电子邮件地址的秘密位置
如前所述,验证发件人身份的邮件标准会验证有关发件人的电子邮件地址的信息。
SMTP 协议定义了两个邮件字段,用于存储有关发件人身份的信息,即发件人的电子邮件地址。
- 有关发件人的一种类型的“信息”保存在名为“MAIL FROM”的邮件字段中,该字段“位于”邮件信封中。
- 有关发件人的一种类型的“信息”保存在名为“FROM”的邮件字段中,该字段“位于”邮件标头中。
邮件信封被视为“临时数据存储”,在两个邮件服务器通信的 SMTP 会话阶段充当数据的“逻辑容器”。
邮件信封的概念与“心理邮件信封”非常相似。
在电子邮件之后,消息被代表目标收件人的目标邮件服务器接受,并且在目标邮件服务器读取所有所需信息之后存储在邮件信封中的信息,邮件信封被“销毁”。
在这个阶段,我们的脑海中可能会出现两个可选问题:
Q1:为什么我们需要使用两个不同的邮件字段来存储有关发件人身份的信息(发件人电子邮件地址)?
问题2:你为什么要告诉我所有这些信息?这些信息与所讨论的主题有何关联?
A1:
邮件信封中出现的“发件人信息”
(MAIL FROM) 的主要用途是作为“退回邮件”地址。
使用的“退回邮件”地址目标邮件服务器,在电子邮件无法发送到目标收件人的情况下,邮件服务器需要将电子邮件“返回”给原始发件人。
邮件标题中出现的“发件人信息”(FROM) 的主要目的是通知目标收件人,即“撰写”电子邮件的发件人。
在某些情况下,MAIL FROM(邮件信封)中显示的发件人可能与 FROM 中显示的发件人身份不同字段(邮件标题)。
A2:我之所以告诉你这个“无聊的信息”是因为邮件标准——SPF和DKIM使用了这个字段中存储的信息(MAIL FROM和FROM)用于获取有关发件人身份的信息,并执行发件人验证程序。
注意:SPF 标准流程配置为仅验证 MAIL FROM 字段中存储的发件人信息。换句话说,SPF发件人验证过程不会涉及FROM字段中存储的发件人信息。这是一个固有的弱点,可以被敌对分子利用。
如果您想了解有关此漏洞的更多信息,可以阅读文章 - 敌对分子如何执行欺骗电子邮件攻击并绕过现有的 SPF 实施? |简介 | 1#2
电子邮件消息组件 - 邮件信封、邮件和邮件标题
在下图中,我们可以看到标准电子邮件的结构,包括两部分:邮件信封和邮件。
在下图中,我们可以看到“邮件组件”的结构,它也包含两部分:“邮件部分”,包括邮件正文和邮件标头。
邮件信封——保存发件人和收件人信息的“邮件字段”
邮件信封使用以下字段来存储有关发件人身份和目标收件人身份的信息:
- 发件人身份 - 邮件信封使用名为 - MAIL FROM 的“邮件字段”,用于“保存”有关发件人身份的信息(发件人电子邮件地址) 。
- 收件人身份——邮件信封使用名为-RCPT TO的“邮件字段”,用于“保存”有关收件人身份的信息(目标收件人电子邮件地址) )。
邮件标头——保存发件人和收件人值的“邮件字段”
对于“邮件组件”,保存发件人和收件人身份信息的部分是邮件标头。
邮件标头使用以下字段来存储有关发件人身份和目标收件人身份的信息:
- 发件人身份——邮件标头使用名为-FROM的“邮件字段”,用于“保存”有关发件人身份的信息(发件人电子邮件地址)。
- 收件人身份 - 邮件标头使用名为 - TO 的“邮件字段”,用于“保存”有关收件人身份的信息(目标收件人电子邮件地址) 。
当前文章系列的下一篇文章
发件人验证如何进行? (我们如何识别欺骗邮件)|五英雄的SPF、DKIM DMARC、Exchange和Exchange Online防护 |第 9 部分#9

















