今天，我們推出了一個新的工具來對付電子郵件欺騙和網(wǎng)絡釣魚，并改善電子郵件的發(fā)送情況：全新電子郵件安全 DNS 向?qū)Э捎糜趧?chuàng)建 DNS 記錄，防止其他人代表你的域發(fā)送惡意電子郵件。這個新功能還會在用戶的域上存在不安全的 DNS 配置時發(fā)出警告，并顯示如何修復這些配置的建議。這項功能將首先在 Free 計劃中向用戶推出，在接下來的幾周內(nèi)，Pro、Business 和 Enterprise 用戶也將可以使用。
在我們深入了解這個向?qū)У纳衿嬷幹埃覀兿群笸艘徊?，了解一下這個問題：電子郵件欺騙和網(wǎng)絡釣魚。
什么是電子郵件欺騙和網(wǎng)絡釣魚？
欺騙指為了獲得某種非法利益而偽裝成別人的過程。例如域名欺騙：某人托管 mycoolwebpaqe.xyz 網(wǎng)站以欺騙 mycoolwebpage.xyz 的用戶提供敏感信息，使用戶誤以為這是正確的網(wǎng)站。在瀏覽器的地址欄并排查看時，很難發(fā)現(xiàn)兩者的區(qū)別。
此外還有電子郵件欺騙。為了了解它是如何工作的，請看一下我通過自己的個人電子郵件地址收到的一封 Cloudflare 產(chǎn)品更新電子郵件。對于大多數(shù)電子郵件提供者，您可以查看電子郵件的完整源代碼，其中包含多個標頭以及電子郵件的主體。
Date: Thu, 23 Sep 2021 10:30:02 -0500 (CDT)
From: Cloudflare <product-updates@cloudflare.com>
Reply-To: product-updates@cloudflare.com
To: <my_personal_email_address>
在上面，您可以看到電子郵件的 4 個標頭，何時收到、來自誰、我應該回復給誰以及我的個人電子郵件地址。From 標頭的值用于在我的電子郵件程序中顯示發(fā)送者。
當我收到以上郵件時，我會自動認為這封郵件是由 Cloudflare 發(fā)送的。然而，任何人都可以從他們的電子郵件服務器發(fā)送帶有修改過的 From 標頭的電子郵件。如果我的電子郵件提供商沒有進行適當?shù)臋z查（這一點將在本文稍后討論），我有可能受騙，以為某一封電子郵件是從 Cloudflare 發(fā)送的，但實際上并非如此。
這就引出了第二種攻擊類型：網(wǎng)絡釣魚。假設惡意分子已經(jīng)成功使用電子郵件欺騙向您公司的客戶發(fā)送電子郵件，這些電子郵件看起來像來自您的企業(yè)服務電子郵件。這些電子郵件使用相同的樣式和格式，其內(nèi)容看起來完全像來自您公司的合法電子郵件。電子郵件文本可能是一條緊急信息，要求更新一些帳戶信息，包括一個到所謂門戶網(wǎng)站的超鏈接。如果用戶的接收郵件服務器沒有將郵件標記為垃圾郵件或不安全來源，他們可能會直接點擊鏈接，這樣可能會執(zhí)行惡意代碼或引導他們進入一個欺騙域名并被要求提供敏感信息。
根據(jù) FBI 的 2020 年互聯(lián)網(wǎng)犯罪報告，網(wǎng)絡釣魚是 2020 年最常見的網(wǎng)絡犯罪，受害者超過 24 萬，造成的損失超過 5000 萬美元。自 2019 年以來，受害者人數(shù)增加了一倍多，幾乎是 2018 年的 10 倍。
為了了解大多網(wǎng)絡釣魚攻擊如何執(zhí)行，我們仔細看看 2020 年 Verizon 數(shù)據(jù)外泄調(diào)查報告中的發(fā)現(xiàn)。報告顯示，網(wǎng)絡釣魚占所有“社交行為”（社交工程攻擊的另一個說法）的 80% 以上，使其成為迄今此類攻擊中最常見的一種。此外，報告指出，96% 的社交行為是通過電子郵件傳送的，僅 3% 通過網(wǎng)站、1% 通過電話或短信息。
這種情況清楚地表明，電子郵件釣魚是一個嚴重的問題，讓互聯(lián)網(wǎng)用戶非常頭疼。我們來看看域名所有者能做些什么來阻止壞人濫用他們的域名進行電子郵件釣魚。
DNS 如何幫助您防止這種攻擊？
幸運的是，域名系統(tǒng) (DNS) 中已經(jīng)內(nèi)置了三種反欺騙機制。
發(fā)送方策略框架 (SPF)
域名密鑰識別郵件 (DKIM)
基于域名的郵件身份驗證報告和一致性 (DMARC)
然而，正確配置它們并非易事，尤其是對缺乏經(jīng)驗的人而言。如果您的配置過于嚴格，合法的電子郵件將被丟棄或標記為垃圾郵件。如果配置過于寬松，您的域名可能被濫用于電子郵件欺騙。
發(fā)送方策略框架（SPF）
SPF 用于指定哪些 IP 地址和域被允許代表您的域發(fā)送電子郵件。SPF 策略以 TXT 記錄的形式發(fā)布在您的網(wǎng)域上，以便人人都能通過 DNS訪問。我們來檢查 cloudflare.com 上的 TXT 記錄：
cloudflare.com TXT"v=spf1 ip4:199.15.212.0/22 ip4:173.245.48.0/20 include:_spf.google.com include:spf1.mcsv.net include:spf.mandrillapp.com include:mail.zendesk.com include:stspg-customer.com include:_spf.salesforce.com -all"
SPF TXT 記錄始終需要以 v=spf1 開頭。它通常包含發(fā)送電子郵件服務器的 IP 地址列表（使用 ip4 或 ip6 機制）。include 機制用于參考其他域名上的其他 SPF 記錄。如果您依賴于其他需要代表我們發(fā)送電子郵件的供應商，則通常會這樣做。您可以在 cloudflare.com 的 SPF 記錄中看到一些例子：我們使用 Zendesk 作為客戶支持軟件，使用 Mandrill 作為營銷和交易電子郵件。
最后，還有一種全面捕獲機制 -all，其中規(guī)定了所有未指定的入站電子郵件應如何處理。全面捕獲機制之前有一個限定符，可以是 + (Allow)、~ (Softfail) 或 - (Fail)。不建議使用 Allow 限定符，因為它基本上會使 SPF 記錄無效，并允許所有 IP 地址和域名代表您的域名發(fā)送電子郵件。Softfail 通過接收郵件服務器進行不同解讀，將電子郵件標記為垃圾郵件或不安全，具體取決于服務器。Fail 告訴服務器不要接受任何來自不明來源的電子郵件。
上圖顯示了為確保收到的郵件符合 SPF 策略所采取的步驟。
電子郵件發(fā)送自 IP 地址 203.0.113.10，包含的 From 標頭值為hannes@mycoolwebpage.xyz。
收到這封電子郵件后，接收者查詢 mycoolwebpage.xyz 上的 SPF 記錄，以獲得這個網(wǎng)域的 SPF 策略。
接收者檢查發(fā)送 IP 地址 203.0.113.10 是否列于 SPF 記錄中。如是，該電子郵件成功完成 SPF 檢查。否則，all 機制的限定符定義結(jié)果。
關于所有機制的完整列表以及關于 SPF 的更多信息，請參閱 RFC7208。
域名密鑰識別郵件（DKIM）
好啦，通過使用 SPF，我們已經(jīng)確保只有允許的 IP 地址和域名才能代表 cloudflare.com 發(fā)送電子郵件。但是，如果其中一個 IP 在我們沒有注意到的情況下改變了所有者并更新了 SPF 記錄，我們怎么辦？或者，如果其他人也使用谷歌的電子郵件服務器以相同的 IP 試圖欺騙來自 cloudflare.com 的電子郵件怎么辦？
此時即可使用 DKIM。DKIM 提供一種機制，可加密簽署電子郵件的多個部分 — 通常為主體和某些標頭 — 它使用的是公共密鑰加密。在深入了解其工作原理之前，我們先看看 cloudflare.com 使用的 DKIM 記錄：
google._domainkey.cloudflare.com.TXT"v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMxbNxA2V84XMpZgzMgHHey3TQFvHkwlPF2a11Ex6PGD71Sp8elVMMCdZhPYqDlzbehg9aWVwPz0+n3oRD73o+JXoSswgUXPV82O8s8dGny/BAJklo0+y+Bh2Op4YPGhClT6mRO2i5Qiqo4vPCuc6GB34Fyx7yhreDNKY9BNMUtQIDAQAB"
DKIM 記錄的結(jié)構(gòu)為 <selector>._domainkey.<domain>，其中，selector 由您的電子郵件提供商提供。DKIM TXT 記錄的內(nèi)容始終以 v=DKIM1 開頭，之后是公共密鑰。我們可以看到公共密鑰的類型，引用了 k 標記和公共密鑰本身，前面是 p 標記。
下面是簽名和 DKIM 檢查工作原理的簡化序列：
發(fā)送電子郵件服務器根據(jù)電子郵件內(nèi)容創(chuàng)建 hash。
發(fā)送電子郵件服務器加密此 hash（使用 DKIM 私鑰）。
發(fā)送電子郵件時包含加密的 hash。
接收電子郵件服務器從電子郵件域名上發(fā)布的 DKIM TXT 記錄中檢索公鑰。
接收郵件服務器使用公共 DKIM 密鑰解密 hash。
接受電子郵件服務器根據(jù)電子郵件內(nèi)容生成 hash。
如果解密的 hash 與生成的 hash 匹配，則電子郵件真實性得到驗證。否則，DKIM 檢查不通過。
完整 DKIM 規(guī)范可參閱 RFC4871 和 RFC5672。
基于域名的郵件身份驗證報告和一致性（DMARC）
基于域名的郵件身份驗證報告和一致性，這個名稱確實很拗口。我們來關注兩個詞：報告和一致性。這正是 DMARC 提供的內(nèi)容。定期報告讓郵件發(fā)送者知道有多少郵件不符合要求，可能受到欺騙。一致性有助于向郵件接收者提供一個明確的信號，告訴他們?nèi)绾翁幚聿环弦蟮泥]件。即使沒有 DMARC 記錄，郵件接收者也可能會對 SPF 或 DKIM 檢查不通過的郵件施加自己的策略。但是，在 DMARC 記錄上配置的策略是電子郵件發(fā)送者的顯式指令，因此它增強了電子郵件接收者處理不符合要求電子郵件的信心。
這是 cloudflare.com 的 DMARC 記錄
_dmarc.cloudflare.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:rua@cloudflare.com"
DMARC TXT 記錄始終在電子郵件域名的 _dmarc 子域上設置 — 類似于 SPF 和 DKIM — 內(nèi)容需要以 v=DMARC1 開頭。之后是三個附加標記：
策略標記 (p) 指示電子郵件接收者如何處理 SPF 或 DKIM 檢查不通過的電子郵件?？赡苤禐?none、reject 和 quarantine。none 策略也稱為僅監(jiān)視，允許仍然接受檢查不通過的電子郵件。通過指定 quarantine，電子郵件接收者將不符合 SPF 或 DKIM 的電子郵件放入垃圾郵件文件夾。對于 reject，如果 SPF 或 DKIM 檢查不通過，將丟棄電子郵件，根本不發(fā)送。
百分比標記 (pct) 可用于僅對傳入電子郵件的子集應用指定的策略。如果您剛剛推出 DMARC，并且希望通過在子集上測試以確保所有配置都正確無誤，則這樣很有幫助。
我們可以在記錄中找到的最后一個標記是報告 URI (rua)。這用于指定一個電子郵件地址，該地址將接收關于不符合要求的電子郵件的匯總報告(通常是每天)。
以上，我們可以看到 DMARC 是如何逐步工作的。
From 標頭值為 hannes@mycoolwebpage.xyz 的電子郵件被發(fā)出。
接收者查詢網(wǎng)域 mycoolwebpage.xyz 的 SPF、DKIM 和 DMARC 記錄以獲取所需原則和 DKIM 公鑰。
接收者執(zhí)行如上所述的 SPF 和 DKIM 檢查。如兩者均通過，該電子郵件被接受并投遞到收件箱。如果 SPF 或 DKIM 檢查失敗，將遵循 DMARC 原則并確定郵件是否仍被接受、丟棄或發(fā)送到垃圾郵件文件夾。
最后，接收者返回一個匯總報告。根據(jù) rua 標記中指定的電子郵件，報告也可能被發(fā)送到負責該電子郵件的另一個電子郵件服務器。
其他可選標記和完整的 DMARC 規(guī)范可參閱 RFC7489。
關于目前采用情況的一些數(shù)據(jù)
現(xiàn)在我們已經(jīng)知道了問題是什么，以及如何使用 SPF、DKIM 和 DMARC 來解決問題，下面，我們看看它們的普及情況。
Dmarc.org 已經(jīng)發(fā)布了一個代表性數(shù)據(jù)集中采用 DMARC 記錄的域名的情況。其中顯示，到 2020 年底，仍只有不到 50% 的域名擁有 DMARC 記錄。記住，沒有 DMARC 記錄，就不會明確執(zhí)行 SPF 和 DKIM 檢查。研究進一步表明，在具有 DMARC 記錄的域名中，超過 65% 的域名使用僅監(jiān)視策略 (p:none)，因此，推動更高的采用率潛力巨大。該研究沒有提到這些域名是否有在發(fā)送或接收電子郵件，但即使它們沒有接收或發(fā)送，安全配置也應該包括 DMARC 記錄（稍后詳細介紹）。
2021 年 8 月 1 日的另一份報告指出，屬于銀行業(yè)實體的域名也出現(xiàn)了類似情況。在美國 2881 家銀行實體中，只有 44% 的實體在其域名上發(fā)布了 DMARC 記錄。在有 DMARC 記錄的實體中，大約有 2/5 的實體將 DMARC 策略設置為 None，另外 8% 的實體存在“配置錯誤”情況。丹麥銀行領域的域名中使用 DMARC 的比例非常高，達94%，而日本只有 13% 的域名使用 DMARC。SPF 的采用平均顯著高于 DMARC，這可能與 2006 年首次引入 SPF 標準作為實驗性 RFC、而 DMARC 僅在 2015 年才成為標準這一情況有關。
這表明我們還有很大的改進空間。
進入：電子郵件安全 DNS 向?qū)?/strong>
那么，我們要怎樣做才能增加 SPF、DKIM 和 DMARC 的采用率并應對電子郵件欺騙和網(wǎng)絡釣魚？進入新的 Cloudflare 電子郵件安全 DNS 向?qū)А?/span>
從今天開始，當您瀏覽到 Cloudflare 儀表盤的 DNS 標簽時，您會看到兩個新功能：
1) 新增的電子郵件安全部分
2) 新增的關于不安全配置的警告
為了開始使用電子郵件安全 DNS 向?qū)?，您可以?/span>接點擊警告中的鏈接（引導您進入向?qū)У南嚓P部分）或點擊新的電子郵件安全部分中的配置。后者將向您顯示以下可用選項：
有兩種情況。您使用您的域名發(fā)送電子郵件，或沒有這樣做。如果是前者，您可以通過以下幾個簡單的步驟配置 SPF、DKIM 和 DMARC 記錄。這里是針對 SPF 的步驟。
如果您的域名不發(fā)送電子郵件，有一個簡單的方法可一鍵配置所有三個記錄：
單擊 Submit 之后，將創(chuàng)建所有三個記錄，并以相應方式配置，使所有電子郵件都檢查不通過并被傳入電子郵件服務器拒絕。
example.comTXT"v=spf1 -all"
*._domainkey.example.com.TXT"v=DKIM1; p="
_dmarc.example.com.TXT"v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;"幫助應對電子郵件欺騙和網(wǎng)絡釣魚
確保您的域名是安全的，能夠防止電子郵件欺騙和網(wǎng)絡釣魚。只需前往 Cloudflare 儀表盤上的 DNS 標簽，或者，如果您還沒有使用 Cloudflare DNS，只需在 cloudflare.com 上花幾分鐘時間進行免費注冊。
如果您想了解關于 SPF、DKIM 和 DMARC 的更多信息，請查閱我們關于電子郵件相關 DNS 記錄的新學習頁面。
Cloudflare
專欄
閩公網(wǎng)安備 35010202001226號
