確定電子郵件安全性可能是管理者必須面對的最重要和最困難的任務之一。每天，伺服器處理數以千計封的電子郵件，控制這麼大的郵件流量并不容易。難怪黑客策劃攻擊的時候會把注意力集中在這個管道上。他們使用各種技巧，使使用者認為打開一個可疑的依戀是一個好主意。
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就足以實作這一點。在下面的示例中，[email protected]模拟[email protected]并發送一封電子郵件給[email protected]
user1使用的cmdlet如下所示：
Send-MailMessage –SmtpServer 192.168.23.2 –To [email protected] –From [email protected] –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)
<code>MAIL FROM: [email protected] (address of the user you want to impersonate)</code>
<code>RCPT TO: [email protected] (your victim’s address)</code>
<code>DATA: it enables you to specify subject and body of your email. Enter a full stop (.) in a new line to finish data input.</code>
<code> </code>
<code>兩種方法都以相同的結果結束：</code>
<code>對于更現實的情況，部署在不同環境中的類似攻擊如下所示：</code>
<code></code>
正如您所看到的，電子郵件與其他任何通過正常方式發送的消息沒有差別。接受者很容易陷入這個詭計。作為管理者，您可以在Exchange日志中檢測到這樣的操作，但是在擁有大量使用者和密集郵件流的大型組織中，至少可以說是麻煩的。更不要說在這樣的嘗試被發現之前就可以做到這一點。那麼為什麼Exchange允許這樣的行為？以及如何阻止它？
在預設的Exchange部署中，将建立一個接收連接配接器。預設前端（您的伺服器的名稱）配置，以便它：
從所有IP位址接收
使用預設的SMTP端口25接收電子郵件
禁用來自匿名使用者的電子郵件
最後一點是内部使用者濫用郵件系統的原因。不幸的是，關閉匿名使用者的權限也會阻止從外部電子郵件位址接收電子郵件。那麼，我不知道在什麼環境下這将是一個合理的選擇。
可能有許多第三方解決方案可以抵禦這種威脅，但是在本文中，我将隻介紹如何排除使用本機Exchange機制的組織内部的欺騙行為。我将示範兩種方法：
正如我在描述外部攻擊時已經提到的那樣，反欺騙嘗試中最受歡迎（也是最有效）的武器之一是使用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是：
<code>& $env:ExchangeInstallPath\Scripts\Install-AntiSpamAgents.ps1</code>
成功的安裝應該是這樣的：
現在要應用所做的更改，請重新啟動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将嘗試發送一條消息到[email protected]作為[email protected]。
PowerShell指令在本文中已經使用了幾次，這次不發送電子郵件。錯誤代碼與使用上述方法出現的錯誤代碼不同：5.7.60 SMTP; 用戶端沒有權限發送此發件人。
好吧，如果使用者在提供他/她的憑據後嘗試相同的技巧呢？
好，還是沒有運氣。但是，當同一個使用者停止嘗試顯示為其他人：
該cmdlet執行其工作。今天的受害者[email protected]可以讀取郵件以及原始發件人：
如果惡意使用者嘗試使用telnet，則内部欺騙嘗試也會被阻止：
作為Exchange Server管理者，您必須知道，預設的Exchange部署不足以保護您的使用者免受惡意郵件的攻擊。幸運的是，您可以使用本指南徹底防止内部電子郵件欺騙。兩種方法都基于本機Exchange機制，隻需要一點努力。
版權聲明：原創作品，如需轉載，請注明出處。否則将追究法律責任
本文轉自 Juck_Zhang 51CTO部落格，原文連結:http://blog.51cto.com/itsoul/2047459