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