如何防止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機制，只需要一點努力。