如何防止Exchange组织中的内部电子邮件欺骗
确保电子邮件安全性可能是管理员必须面对的最重要和最困难的任务之一。每天，服务器处理数以千计封的电子邮件，控制这么大的邮件流量并不容易。难怪***策划***的时候会把注意力集中在这个渠道上。他们使用各种技巧，使用户认为打开一个可疑的依恋是一个好主意。
什么是电子邮件欺骗？
电子邮件欺骗是一种非常流行的***手段。发件人修改邮件标题，以便从其他人发送电子邮件。例如，***使用它来模仿公司的员工以获取登录凭据，个人数据或其他机密信息。保护您的组织免受外部欺骗***的两种最常见的方式是：
SPF记录 - 被授权从域发送电子邮件的IP地址列表。
DKIM检查 - 一种电子邮件认证方法。它使您能够使用公钥和私钥签署和验证电子邮件。发布在DNS记录中的公钥用于验证邮件是否来自原始发件人。您不能本地配置它在Exchange Server上 - 您需要SMTP网关的插件。
与外部欺骗作斗争时，这两种方式都能带来很不好的结果。当一名员工试图冒充一名同事时，我们遇到了内部欺骗的问题。这可能是一个笑话，或者为了获得一些好处 - 无论哪种方式，它可以通过多种方式破坏公司：
导致混乱，
诱发物质损害，
危害数据完整性，
损害公司声誉。
更糟糕的是，与内部欺骗尝试做斗争需要稍微不同的方法。现在我将介绍如何防止Exchange组织中的内部电子邮件欺骗。但首先，快速说明测试环境：
测试环境
为了演示和测试目的，我将使用以下机器：
- Windows Server 2012作为域控制器。域名是domain128.lab，IP为192.168.23.1
- Windows Server 2012 R2与Exchange 2016 CU3，IP 192.168.23.2,192.168.170.79
- 带有Outlook 2013的Windows 10，IP 192.168.23.3
- Windows 7，IP 192.168.23.4
现在是适当的部分。我将展示如何执行电子邮件欺骗***以及如何防止它们：
内部电子邮件欺骗
首先，让我们看看员工在发送电子邮件时如何伪装成另一个用户。一个PowerShell cmdlet就足以实现这一点。在下面的示例中，user1@domain128.lab模拟user3@domain128.lab并发送一封电子邮件给user2@domain128.lab
user1使用的cmdlet如下所示：
Send-MailMessage -SmtpServer 192.168.23.2 -To user2@domain128.lab -From user3@domain128.lab -Subject "It`s me user3" -Body "Send me your report"
当然，这样的电子邮件不应该有任何伤害。如果user2回复消息，则电子邮件将转到user3，而不是***者。问题是经过一些修改后，Send-MailMessage可以发送带有恶意链接的HTML电子邮件，或附加一个受感染的文件。我不会通过例子来说明如何使用欺骗来伤害一个组织，但相信我; 有许多。
使用Telnet客户端也可以实现同样的技巧。Telnet客户端默认情况下未安装，但可以打开或关闭" 控制面板">" 程序" >" 打开Windows功能"，然后选择" Telnet客户端"将其打开。要测试内部电子邮件欺骗，运行cmd.exe并通过插入端口25连接到您的服务器：
Telnet 192.168.23.2 25
只记得用你的IP地址来代替。
接下来，使用SMTP命令，您可以发送一封电子邮件：
HELO domain128.lab (connects to your domain)
MAIL FROM: user3@domain128.lab (address of the user you want to impersonate)
RCPT TO: user2@domain128.lab (your victim's address)
DATA: it enables you to specify subject and body of your email. Enter a full stop (.) in a new line to finish data input.
两种方法都以相同的结果结束：
对于更现实的情况，部署在不同环境中的类似***如下所示：
正如您所看到的，电子邮件与其他任何通过正常方式发送的消息没有区别。接受者很容易陷入这个诡计。作为管理员，您可以在Exchange日志中检测到这样的操作，但是在拥有大量用户和密集邮件流的大型组织中，至少可以说是麻烦的。更不要说在这样的尝试被发现之前就可以做到这一点。那么为什么Exchange允许这样的行为？以及如何阻止它？
在默认的Exchange部署中，将创建一个接收连接器。默认前端（您的服务器的名称）配置，以便它：
从所有IP地址接收
使用默认的SMTP端口25接收电子邮件
禁用来自匿名用户的电子邮件
最后一点是内部用户滥用邮件系统的原因。不幸的是，关闭匿名用户的权限也会阻止从外部电子邮件地址接收电子邮件。那么，我不知道在什么环境下这将是一个合理的选择。
如何防止内部电子邮件欺骗
可能有许多第三方解决方案可以抵御这种威胁，但是在本文中，我将只介绍如何排除使用本机Exchange机制的组织内部的欺骗行为。我将演示两种方法：
使用SPF记录
正如我在描述外部***时已经提到的那样，反欺骗尝试中最受欢迎（也是最有效）的武器之一是使用SPF记录。请参阅下面的SPF记录的语法：
V=spf1 ip4:your_server's IP -all
简而言之，SPF记录驻留在DNS区域文件中。它们指定允许从某个域发送电子邮件的服务器的IP地址。该机制可以用来确保内部通信的类似于通常用于外部通信的方式。要使这种方法适用于内部电子邮件欺骗，您需要配置三个元素：
本地DNS中的SPF记录，
Exchange Server中的反垃圾邮件功能，
发件人ID代理。
在介绍配置过程之前，我会先谈谈它的主要缺点。要使用此方法完全阻止内部电子邮件欺骗，必须包括允许在网络中发送电子邮件的所有IP地址（包括打印机，应用程序和其他Web对象）。如果你有一个庞大的网络与各种设备的负载这不是最方便的解决方案。但是，如果你没有压倒性的基础设施，而且你知道它像你的手，那么解决方案应该运行良好。
一步一步的演练
首先，您应该在本地域的DNS服务器上创建txt记录。就我而言，记录将如下所示：
v=spf1 ip4:192.168.23.2 ip4:192.168.170.79 ip4:192.168.169.51 -all
192.168.23.2和192.168.170.79是我的Exchange Server的IP地址，而192.168.169.51是我网络打印机在另一个子网中的IP地址。打印机将电子邮件发送到Exchange。
下一步是安装Exchange Antispam Agent。你可以使用PowerShell来做到这一点。该cmdlet是：
& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1
成功的安装应该是这样的：
现在要应用所做的更改，请重新启动MSExchangeTransport服务：
重新启动服务MSExchangeTransport
提供所有Exchange服务器的IP地址：
Set-TransportConfig -InternalSMTPServers
我必须提供两个地址，因为我的Exchange Server有两个网络接口。
我们差不多完成了。现在，您必须配置拒绝来自您的SPF记录中未包含的地址的电子邮件的规则。PowerShell cmdlet是：
Set-SenderIdConfig -SpoofedDomainAction Reject
剩下的就是测试当前的配置是否成功地阻止了内部欺骗尝试。我将使用本文开头介绍的相同的cmdlet。***者应该得到以下错误，而不是发送电子邮件：
如您所见，Exchange服务器阻止尝试并显示错误5.7.1"发件人ID
即使用户在-From属性中输入自己的邮箱，效果也将保持不变：
最后，让我们检查一下，如果我尝试伪装成IP地址为192.168.169.51的计算机上的另一个用户（我之前添加到本地SPF记录中），将会发生什么情况：
邮件经过没有问题：
这个例子显示了SPF记录方法的另一个缺点。由于身份验证基于发件人的IP，错误的配置不能保证贵公司完全防范内部欺骗。
实施此方法不会影响从电子邮件客户端（Outlook，OWA或ActiveSync）发送电子邮件，因为他们通过HTTP使用RPC或MAPI通过不同的端口（443或80）。
使用专用的接收连接器
第二种方法是在端口25上创建一个额外的接收连接器。连接器控制本地网络，并只允许来自域用户的电子邮件。这种方法使用不同的授权方法。它使用域凭据（登录名和密码）代替使用IP。授权方法的更改会产生一个问题 - 所有内部交换连接必须被授权。换句话说，每个向Exchange发送电子邮件的Web设备和应用程序都需要一个域帐户（或者至少可以有一个普通帐户）。
正如我之前提到的，连接器将被设置为TCP端口25.但是，正如您所知，已经有一个接收连接器，它接受从端口25上的SMTP服务器的匿名连接。那么该连接器如何与你将要创建一个？Exchange如何知道选择哪一个？Exchange Server相当聪明，当谈到这一点。服务器将始终为每个连接选择更精确的连接器。我配置的接收连接器是为LAN网络定义的，而默认的适用于所有的连接。因此，对于内部SMTP连接，Exchange将始终选择为LAN指定的新连接器。
一步一步的演练
除了更安全之外，第二种方法更容易实现。这是因为它只需要创建一个新的接收连接器。您可以使用一个很好的PowerShell cmdlet。我将为连接器使用内部客户端SMTP名称，以便稍后可以轻松识别它。请记住，IP范围是为我的环境个性化的：
New-ReceiveConnector -Name "Internal Client SMTP" -TransportRole FrontendTransport -Usage Custom -Bindings 0.0.0.0:25 -RemoteIPRanges 192.168.23.0/24,192.168.170.0/24 -AuthMechanism TLS,Integrated -PermissionGroups ExchangeUsers
我也应该能够在Exchange管理中心 > 邮件流 > 接收连接器 > 新建：
这些设置与上面使用的cmdlet类似。该连接器应该是内部的，角色应该设置为前端传输 ...不幸的是，默认角色是集线器传输，而且我似乎无法将其更改为我需要的选项。让我们继续看看会发生什么。
下一页是非常重要的 - 这是您必须指定您的组织中的所有LAN网络。在我的情况下，它是192.168.23.0/24和192.168.170.0/24。
这是Exchange引发错误的地方。
您为Bindings和RemoteIPRanges参数指定的值与接收连接器"ENV128-E2016 \ Default Frontend ENV128-E2016"上的设置冲突。在单个服务器上分配给不同传输角色的接收连接器必须侦听唯一的本地IP地址和端口绑定。
看起来Exchange不喜欢让两个具有不同传输角色的连接器监听相同的端口。但是，这两个角色是不同的，只是因为一个选项变灰了...考虑到一个单一的cmdlet没有抛出任何错误的事实，这是独特的。您可以检查是否遇到同样的错误，但是我的建议是使用PowerShell。
连接器（不管你如何创建它）应该出现在列表中：
现在进行测试。user1将尝试发送一条消息到user2@domain128.lab作为user3@domain128.lab。
PowerShell命令在本文中已经使用了几次，这次不发送电子邮件。错误代码与使用上述方法出现的错误代码不同：5.7.60 SMTP; 客户端没有权限发送此发件人。
好吧，如果用户在提供他/她的凭据后尝试相同的技巧呢？
好，还是没有运气。但是，当同一个用户停止尝试显示为其他人：
该cmdlet执行其工作。今天的受害者user3@domain128.lab可以读取邮件以及原始发件人：
如果恶意用户尝试使用telnet，则内部欺骗尝试也会被阻止：
概要
作为Exchange Server管理员，您必须知道，默认的Exchange部署不足以保护您的用户免受恶意邮件的***。幸运的是，您可以使用本指南彻底防止内部电子邮件欺骗。两种方法都基于本机Exchange机制，只需要一点努力。
