如何防止Exchange组织中的内部电子邮件欺骗

        确保电子邮件安全性多是管理员必须面对的最重要和最困难的任务之一。天天，服务器处理数以千计封的电子邮件，控制这么大的邮件流量并不容易。难怪***策划***的时候会把注意力集中在这个渠道上。他们使用各类技巧，使用户认为打开一个可疑的依恋是一个好主意。

                                                                                  

1. 什么是电子邮件欺骗？

    电子邮件欺骗是一种很是流行的***手段。发件人修改邮件标题，以便从其余人发送电子邮件。例如，***使用它来模仿公司的员工以获取登陆凭据，我的数据或其余机密信息。保护您的组织免受外部欺骗***的两种最多见的方式是：

• 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 <PRA>不容许”。

即便用户在-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机制，只须要一点努力。