2023年，Microsoft宣布更改Microsoft Exchange中處理DMARC的方式。儘管有警告，許多使用者並未遵循Microsoft的建議來設定增強的過濾功能，或者可能對此變更並不知情。結果未正確配置Microsoft Exchange的使用者現在暴露於電子郵件欺詐攻擊的風險中，可能導致電子郵件被攻破、資料洩露等問題。
微軟（Microsoft）2023年於宣布更改Microsoft Exchange中處理DMARC的方式。儘管有警告，許多使用者並未遵循Microsoft的建議來設定增強的過濾功能，或者可能對此變更並不知情。結果未正確配置Microsoft Exchange的使用者現在暴露於電子郵件欺詐攻擊的風險中，這可能導致電子郵件被攻破、資料洩露等問題。
在歐盟和美國，約36%的資料外洩事件來自釣魚攻擊。釣魚郵件通常偽裝成來自合法來源，如「admin@microsoft.com」或「IT管理員email@google.com」，並以工資、薪資等資訊為主題，設計引起用戶關注。
在某些情況下，攻擊者可以偽造電子郵件地址，使其看似來自可信任來源，例如「your_boss@yourcompany.com」。因為電子郵件客戶端將寄件者的地址識別為自己的經理，它可能會自動顯示相關聯絡人照片，進一步增強合法性的幻覺。這使得欺騙用戶採取有害行動變得更加容易，例如輸入他們的憑據、啟動惡意應用程式，或將錢匯入不知道的帳戶。
有哪些協議可以保護自身免受釣魚攻擊呢？
DMARC、DKIM和SPF：保護你的電子郵件免受欺騙
Simple Mail Transfer Protocol（SMTP）是用於發送電子郵件的協定，它於1982年首次創建，並沒有考慮郵件安全性。最初，預期安全性將由其他方法處理。如今，電子郵件伺服器之間的SMTP流量可以使用TLS協定進行加密和驗證，但最初的SMTP並未包含任何驗證電子郵件的方式。
由於電子郵件仍然是針對垃圾郵件、網路釣魚和郵件偽造等網路安全威脅的主要目標，已開發了三個主要協議來強化電子郵件安全性：
1. 寄件者政策架構（Sender Policy Framework，SPF）：此協定透過DNS檢查郵件伺服器是否有權傳送特定域名的電子郵件。
2. 域名識別郵件（DomainKeys Identified Mail，DKIM）：此協定允許電子郵件進行數位簽名，證明其來自授權的郵件伺服器。DKIM簽章有助於郵件提供者驗證寄件者域名的真實性。
3. 基於域名的訊息認證、報告和遵循（Domain-based Message Authentication, Reporting, and Conformance，DMARC）：此協定決定如何處理未通過SPF或DKIM檢查的郵件。當電子郵件未通過驗證時，有助於決定適當的措施。
電子郵件流程示例
以下是電子郵件流程的範例說明：
1. 伺服器A發出DNS要求以查找公司的MX（郵件交換）伺服器。
2. 伺服器A透過MX伺服器之一（伺服器B）向user@company.com發送一封電子郵件至user2@ourcompany.com。
3. 伺服器B透過以下方式驗證電子郵件：檢查郵件是否來自授權伺服器（SPF驗證）、確保郵件具有有效的DKIM簽名、遵循DMARC政策指定的操作。
例如，如果Server A未列在SPF記錄中，並且郵件缺乏DKIM簽名或具有無效簽名、公司.com域名設置DMARC政策為「拒收」，則Server B應拒收該郵件。
如果有如圖1所示的設定，則期望所有來自未列在MX記錄中之來源的郵件都將被拒收。
圖1 設定範例一。
但是，如果接收伺服器設定為忽略這些政策呢？如果這不是你（MX管理員）的決定呢？或者，若是你有一個以上的郵件交換伺服器，但對此卻不瞭解它是如何運作的？
接下來，深入探討這個問題。
Microsoft Exchange Online
當可以配置和使用Exchange Online作為郵件伺服器，在這種情況下，不需要本機的Exchange伺服器或第三方防垃圾郵件。
如果在不使用本地伺服器或第三方MX的情況下使用Exchange Online，則此情境不適用於你。這個情境涵蓋了兩種情況：
‧混合環境：如果使用本機Exchange，你的線上與本機Exchange透過連接器溝通。
‧使用第三方MX伺服器：如果使用第三方垃圾郵件或其他郵件安全解決方案。
第三方MX伺服器
如果你的MX指向第三方MX，應該參考Microsoft的這篇文章（https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud）來配置你的EXO實例。
這意味著，例如，而不是如圖2所示的設定。
圖2 設定範例二。
在「Exchange Server hybrid deployments | Microsoft Learn」（https://learn.microsoft.com/en-us/exchange/exchange-hybrid）的文章可以找到關於它是什麼以及應該如何配置的完整文章。如果沒有自己的MX並且所有流量都是透過*.protection.outlook.com進行的，那麼就不存在配置濫用的威脅。
但如果是使用自己的MX呢？預設情況下，混合設定精靈將為Exchange Online和本地Exchange之間的資料交換創建一些標準的輸入和出站連接器。
在Hybrid Exchange文件中找不到有關第三方MX的任何參考資料，而在傳輸路由文件中發現了一處提到第三方MX的內容。
如果決定將MX記錄指向你的內部部署組織：所有發送至任一組織中任何收件人的郵件都會先透過你的內部部署組織傳送。發送給位於Exchange Online的收件人的郵件會先經過你的內部部署組織，然後再傳送至Exchange Online中的收件人。這種路由對於有合規政策要求，必須使用日誌記錄解決方案檢查組織內外發送郵件的公司來說，會很有幫助。如果選擇了此選項，Exchange Online Protection將無法有效掃描垃圾郵件。
問題出在哪裡？
最重要的一點是，如果租戶接收方的網域MX記錄指向Office 365前面的不同電子郵件安全方案，那麼Honor DMARC將不會被應用。
因為你使用的MX不是Microsoft的，所有郵件將由這個第三方MX進行驗證。應該沒問題，對吧？
如果沒有將你的Exchange Online鎖定，僅接受來自第三方服務的郵件，或者如果沒有為連接器啟用增強篩選，任何人都可以透過ourcompany.protection.outlook.com或ourcompany.mail.protection.outlook.com向你發送郵件，DMARC（SPF和DKIM）驗證將被跳過。
輸入連接器
要全面瞭解這個運作方式，需要查看輸入連接器的配置（圖3）。
圖3 設定範例三。
如圖4所示，這個設定的重要部分是：這個連接器將用於哪些伺服器？是用於任何IP和任何域名。
圖4 設定範例四。
對於不在範圍內的連線該怎麼處理？什麼都不需要做（圖5）。
圖5 設定範例五。
這表示如果只有這種類型的連接器，ourcompany.protection.outlook.com或ourcompany.mail.protection.outlook.com之間的連接則不受你的本地Exchange限制。
而如果有查看本文有關第三方MX的文章，將會發現一個重點：
倘若已經有相同憑證或寄件者IP地址的OnPremises輸入連接器，仍須創建合作夥伴輸入連接器（RestrictDomainsToCertificate和RestrictDomainsToIPAddresses，其參數僅適用於合作夥伴連接器）。這兩個連接器可以毫無問題地共存。
這意味著，在預設情況下這些的配置並不安全。
合作夥伴連接器的重要資訊
如果想配置第三方MX的輸入連接器，可以使用PowerShell或GUI。而且，可以使用兩種類型的驗證：「寄件者網域」或「IP」。
如果有一個具有SenderIPAddresses: {}的合作夥伴連接器，例如透過「寄件人網域」進行驗證的合作夥伴連接器，則所有連接（除了在設定了此特定地址的連接器的IP之外）將通過這個連接器。
如果建立透過IP認證和限制網域到IP位址的合作夥伴連接器，所有沒有連接器的連線都將被阻擋。
如果嘗試透過GUI建立連接器，則無法設置RestrictDomainsToIPAddresses以用於IP進行驗證的情況，因為並不存在「拒絕電子郵件消息（如果它們不是從此IP位址範圍發送）」的選項。這只能透過PowerShell完成。或者，應該使用寄件者驗證（圖6）。
圖6 用寄件者驗證。
並設置：如果電子郵件不是從該IP位址範圍內發送，則拒收該電子郵件訊息（圖7）。
圖7 如果電子郵件不是從設定的IP位址範圍內發送則拒收。
你如何保護自己？
如果有第三方MX，應根據Microsoft的建議設置至少一個額外的輸入連接器。
對於混合情況，則應該建立一個帶有相同IP∕憑證的合作夥伴連接器，就像在OnPremises連接器中使用的一樣（圖8）。
圖8 設定範例六。
除此之外，還可以實施以下的方法來加以強化（Hardening）：
‧在Exchange Online中的連接器進行增強篩選
‧DLP
‧運輸規則，例如以丟棄所有未來自你的MX伺服器的電子郵件。
概念驗證（POC）
可以使用以下代碼自行檢查。請留意，TO是一個真實地址。如果不使用混合方案，在Exchangeonline端必須存在該電子郵件地址。此外，可以從請求的結果中獲取服務器：
‧執行dig yourdomain.onmicrosoft.com mx
‧執行dig yourdomain.mail.onmicrosoft.com mx
PowerShell代碼示範：
$from="user1@yourdomain.com" $to = "user2@yourdomain.com" $server = "yourdomain.mail. protection.outlook.com" $SMTPMessage = New-Object System. Net.Mail.MailMessage($from,$to) $SMTPMessage.Subject = "Misconfiguration in the M365 tenant" $SMTPMessage.Body = "From user@yourdomain.com" $SMTPClient = New-Object Net.Mail. SmtpClient($server, 25) try { $SMTPClient.Send($SMTPMessage) Write-Host (Get-Date).ToUniversal Time() Write-Output "Email sent successfully to $to. From $from" } catch [System.Net.Mail. SmtpException] { Write-Host (Get-Date).ToUniversal Time() Write-Output "SMTP Exception: $_" } catch [System.Exception] { Write-Host (Get-Date).ToUniversal Time() Write-Output "General Exception: $_" }
＜本文作者：王榮信，Acronis大中華區首席技術顧問。專精外對內之資安技術防護措施、內對外之機敏資料外洩保護、資安事件關連分析及進階勒索軟體防護，透過企業資訊安全風險評估及框架，規劃符合需求的安全策略及架構。曾輔導多個大金融機構建立資料外洩防護架構、進階惡意程式防護架構及ATM與伺服器系統防駭解決方案。＞