污文play,国模无水印一区二区三区,欧美jizz18欧美

Cloudflare助您有效應對電子郵件欺騙和網絡釣魚,使用cloudflare犯法嗎

2022-07-05

1315

Cloudflare助您有效應對電子郵件欺騙和網絡釣魚,使用cloudflare犯法嗎Cloudflare助您有效應對電子郵件欺騙和網絡釣魚今天，我們推出了一個新的工具來對付電子郵件欺騙和網絡釣魚，并改善電子郵件的發快遞情況：全新電子郵件安全 DNS 向導可用于創建 DNS 記錄，防止其他人代表你的域發快遞惡意電子郵件......

Cloudflare助您有效應對電子郵件欺騙和網絡釣魚,使用cloudflare犯法嗎

Cloudflare助您有效應對電子郵件欺騙和網絡釣魚

今天，我們推出了一個新的工具來對付電子郵件欺騙和網絡釣魚，并改善電子郵件的發快遞情況：全新電子郵件安全 DNS 向導可用于創建 DNS 記錄，防止其他人代表你的域發快遞惡意電子郵件。這個新功能還會在用戶的域上存在不安全的 DNS 配置時發出警告，并顯示如何修復這些配置的建議。這項功能將首先在 Free 計劃中向用戶推出，在接下來的幾周內，Pro、Business 和 Enterprise 用戶也將可以使用。

在我們深入了解這個向導的神奇之處之前，我們先后退一步，了解一下這個問題：電子郵件欺騙和網絡釣魚。

什么是電子郵件欺騙和網絡釣魚？

欺騙指為了獲得某種非法利益而偽裝成別人的過程。例如域名欺騙：某人托管 mycoolwebpaqe.xyz 網站以欺騙 mycoolwebpage.xyz 的用戶提供敏感信息，使用戶誤以為這是正確的網站。在瀏覽器的地址欄并排查看時，很難發現兩者的區別。

此外還有電子郵件欺騙。為了了解它是如何工作的，請看一下我通過自己的個人電子郵件地址收到的一封 Cloudflare 產品更新電子郵件。對于大多數電子郵件提供者，您可以查看電子郵件的完整源代碼，其中包含多個標頭以及電子郵件的主體。

Date: Thu, 23 Sep 2021 10:30:02 0500 (CDT)From: Cloudflare productupdates@cloudflare.comReplyTo: productupdates@cloudflare.comTo: my_personal_email_address

在上面，您可以看到電子郵件的 4 個標頭，何時收到、來自誰、我應該回復給誰以及我的個人電子郵件地址。From 標頭的值用于在我的電子郵件程序中顯示發快遞者。

當我收到以上郵件時，我會自動認為這封郵件是由 Cloudflare 發快遞的。然而，任何人都可以從他們的電子郵件服務器發快遞帶有修改過的 From 標頭的電子郵件。如果我的電子郵件提供商沒有進行適當的檢查（這一點將在本文稍后討論），我有可能受騙，以為某一封電子郵件是從 Cloudflare 發快遞的，但實際上并非如此。

這就引出了第二種攻擊類型：網絡釣魚。假設惡意分子已經成功使用電子郵件欺騙向您公司的客戶發快遞電子郵件，這些電子郵件看起來像來自您的企業服務電子郵件。這些電子郵件使用相同的樣式和格式，其內容看起來完全像來自您公司的合法電子郵件。電子郵件文本可能是一條緊急信息，要求更新一些帳戶信息，包括一個到所謂門戶網站的超鏈接。如果用戶的接收郵件服務器沒有將郵件標記為垃圾郵件或不安全來源，他們可能會直接點擊鏈接，這樣可能會執行惡意代碼或引導他們進入一個欺騙域名并被要求提供敏感信息。

根據FBI 的 2020 年互聯網犯罪報告，網絡釣魚是 2020 年最常見的網絡犯罪，受害者超過 24 萬，造成的損失超過 5000 萬美元。自 2019 年以來，受害者人數增加了一倍多，幾乎是 2018 年的 10 倍。

為了了解大多網絡釣魚攻擊如何執行，我們仔細看看2020 年 Verizon 數據外泄調查報告中的發現。報告顯示，網絡釣魚占所有“社交行為”（社交工程攻擊的另一個說法）的 80% 以上，使其成為迄今此類攻擊中最常見的一種。此外，報告指出，96% 的社交行為是通過電子郵件傳快遞的，僅 3% 通過網站、1% 通過電話或短信息。

這種情況清楚地表明，電子郵件釣魚是一個嚴重的問題，讓互聯網用戶非常頭疼。我們來看看域名所有者能做些什么來阻止壞人濫用他們的域名進行電子郵件釣魚。

DNS 如何幫助您防止這種攻擊？

幸運的是，域名系統 (DNS) 中已經內置了三種反欺騙機制。

發快遞方策略框架 (SPF)

域名密鑰識別郵件 (DKIM)

基于域名的郵件身份驗證報告和一致性 (DMARC)

然而，正確配置它們并非易事，尤其是對缺乏經驗的人而言。如果您的配置過于嚴格，合法的電子郵件將被丟棄或標記為垃圾郵件。如果配置過于寬松，您的域名可能被濫用于電子郵件欺騙。

發快遞方策略框架（SPF）

SPF 用于指定哪些 IP 地址和域被允許代表您的域發快遞電子郵件。SPF 策略以 TXT 記錄的形式發布在您的網域上，以便人人都能通過 DNS訪問。我們來檢查 cloudflare.com 上的 TXT 記錄：

cloudflare.com TXTv=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:stspgcustomer.com include:_spf.salesforce.com all

SPF TXT 記錄始終需要以 v=spf1 開頭。它通常包含發快遞電子郵件服務器的 IP 地址列表（使用 ip4 或 ip6 機制）。include 機制用于參考其他域名上的其他 SPF 記錄。如果您依賴于其他需要代表我們發快遞電子郵件的供應商，則通常會這樣做。您可以在 cloudflare.com 的 SPF 記錄中看到一些例子：我們使用 Zendesk 作為客戶支持軟件，使用 Mandrill 作為營銷和交易電子郵件。

最后，還有一種全面捕獲機制 all，其中規定了所有未指定的入站電子郵件應如何處理。全面捕獲機制之前有一個限定符，可以是 + (Allow)、~ (Softfail) 或 (Fail)。不建議使用 Allow 限定符，因為它基本上會使 SPF 記錄無效，并允許所有 IP 地址和域名代表您的域名發快遞電子郵件。Softfail 通過接收郵件服務器進行不同解讀，將電子郵件標記為垃圾郵件或不安全，具體取決于服務器。Fail 告訴服務器不要接受任何來自不明來源的電子郵件。

上圖顯示了為確保收到的郵件符合 SPF 策略所采取的步驟。

電子郵件發快遞自 IP 地址 203.0.113.10，包含的 From 標頭值為hannes@mycoolwebpage.xyz。

收到這封電子郵件后，接收者查詢 mycoolwebpage.xyz 上的 SPF 記錄，以獲得這個網域的 SPF 策略。

接收者檢查發快遞 IP 地址 203.0.113.10 是否列于 SPF 記錄中。如是，該電子郵件成功完成 SPF 檢查。否則，all 機制的限定符定義結果。

關于所有機制的完整列表以及關于 SPF 的更多信息，請參閱RFC7208。

域名密鑰識別郵件（DKIM）

好啦，通過使用 SPF，我們已經確保只有允許的 IP 地址和域名才能代表 cloudflare.com 發快遞電子郵件。但是，如果其中一個 IP 在我們沒有注意到的情況下改變了所有者并更新了 SPF 記錄，我們怎么辦？或者，如果其他人也使用谷歌的電子郵件服務器以相同的 IP 試圖欺騙來自 cloudflare.com 的電子郵件怎么辦？

此時即可使用 DKIM。DKIM 提供一種機制，可加密簽署電子郵件的多個部分 — 通常為主體和某些標頭 — 它使用的是公共密鑰加密。在深入了解其工作原理之前，我們先看看 cloudflare.com 使用的 DKIM 記錄：

google._domainkey.cloudflare.com.TXTv=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDMxbNxA2V84XMpZgzMgHHey3TQFvHkwlPF2a11Ex6PGD71Sp8elVMMCdZhPYqDlzbehg9aWVwPz0+n3oRD73o+JXoSswgUXPV82O8s8dGny/BAJklo0+y+Bh2Op4YPGhClT6mRO2i5Qiqo4vPCuc6GB34Fyx7yhreDNKY9BNMUtQIDAQAB

DKIM 記錄的結構為 selector._domainkey.domain，其中，selector 由您的電子郵件提供商提供。DKIM TXT 記錄的內容始終以 v=DKIM1 開頭，之后是公共密鑰。我們可以看到公共密鑰的類型，引用了 k 標記和公共密鑰本身，前面是 p 標記。

下面是簽名和 DKIM 檢查工作原理的簡化序列：

發快遞電子郵件服務器根據電子郵件內容創建hash。

發快遞電子郵件服務器加密此 hash（使用 DKIM 私鑰）。

發快遞電子郵件時包含加密的 hash。

接收電子郵件服務器從電子郵件域名上發布的 DKIM TXT 記錄中檢索公鑰。

接收郵件服務器使用公共 DKIM 密鑰解密 hash。

接受電子郵件服務器根據電子郵件內容生成 hash。

如果解密的 hash 與生成的 hash 匹配，則電子郵件真實性得到驗證。否則，DKIM 檢查不通過。

完整 DKIM 規范可參閱RFC4871和RFC5672。

基于域名的郵件身份驗證報告和一致性（DMARC）

基于域名的郵件身份驗證報告和一致性，這個名稱確實很拗口。我們來關注兩個詞：報告和一致性。這正是 DMARC 提供的內容。定期報告讓郵件發快遞者知道有多少郵件不符合要求，可能受到欺騙。一致性有助于向郵件接收者提供一個明確的信號，告訴他們如何處理不符合要求的郵件。即使沒有 DMARC 記錄，郵件接收者也可能會對 SPF 或 DKIM 檢查不通過的郵件施加自己的策略。但是，在 DMARC 記錄上配置的策略是電子郵件發快遞者的顯式指令，因此它增強了電子郵件接收者處理不符合要求電子郵件的信心。

這是 cloudflare.com 的 DMARC 記錄

_dmarc.cloudflare.com. TXT v=DMARC1; p=reject; pct=100; rua=mailto:rua@cloudflare.com

DMARC TXT 記錄始終在電子郵件域名的 _dmarc 子域上設置 — 類似于 SPF 和 DKIM — 內容需要以 v=DMARC1 開頭。之后是三個附加標記：

策略標記 (p) 指示電子郵件接收者如何處理 SPF 或 DKIM 檢查不通過的電子郵件。可能值為 none、reject 和 quarantine。none 策略也稱為僅監視，允許仍然接受檢查不通過的電子郵件。通過指定 quarantine，電子郵件接收者將不符合 SPF 或 DKIM 的電子郵件放入垃圾郵件文件夾。對于 reject，如果 SPF 或 DKIM 檢查不通過，將丟棄電子郵件，根本不發快遞。

百分比標記 (pct) 可用于僅對傳入電子郵件的子集應用指定的策略。如果您剛剛推出 DMARC，并且希望通過在子集上測試以確保所有配置都正確無誤，則這樣很有幫助。

我們可以在記錄中找到的最后一個標記是報告 URI (rua)。這用于指定一個電子郵件地址，該地址將接收關于不符合要求的電子郵件的匯總報告(通常是每天)。

以上，我們可以看到 DMARC 是如何逐步工作的。

From 標頭值為 hannes@mycoolwebpage.xyz 的電子郵件被發出。

接收者查詢網域 mycoolwebpage.xyz 的 SPF、DKIM 和 DMARC 記錄以獲取所需原則和 DKIM 公鑰。

接收者執行如上所述的 SPF 和 DKIM 檢查。如兩者均通過，該電子郵件被接受并投遞到收件箱。如果 SPF 或 DKIM 檢查失敗，將遵循 DMARC 原則并確定郵件是否仍被接受、丟棄或發國際快遞垃圾郵件文件夾。

最后，接收者返回一個匯總報告。根據 rua 標記中指定的電子郵件，報告也可能被發國際快遞負責該電子郵件的另一個電子郵件服務器。

其他可選標記和完整的 DMARC 規范可參閱RFC7489。

關于目前采用情況的一些數據

現在我們已經知道了問題是什么，以及如何使用 SPF、DKIM 和 DMARC 來解決問題，下面，我們看看它們的普及情況。

Dmarc.org已經發布了一個代表性數據集中采用 DMARC 記錄的域名的情況。其中顯示，到 2020 年底，仍只有不到 50% 的域名擁有 DMARC 記錄。記住，沒有 DMARC 記錄，就不會明確執行 SPF 和 DKIM 檢查。研究進一步表明，在具有 DMARC 記錄的域名中，超過 65% 的域名使用僅監視策略 (p:none)，因此，推動更高的采用率潛力巨大。該研究沒有提到這些域名是否有在發快遞或接收電子郵件，但即使它們沒有接收或發快遞，安全配置也應該包括 DMARC 記錄（稍后詳細介紹）。

2021 年 8 月 1 日的另一份報告指出，屬于銀行業實體的域名也出現了類似情況。在美國 2881 家銀行實體中，只有 44% 的實體在其域名上發布了 DMARC 記錄。在有 DMARC 記錄的實體中，大約有 2/5 的實體將 DMARC 策略設置為 None，另外 8% 的實體存在“配置錯誤”情況。丹麥銀行領域的域名中使用 DMARC 的比例非常高，達94%，而日本只有 13% 的域名使用 DMARC。SPF 的采用平均顯著高于 DMARC，這可能與 2006 年首次引入 SPF 標準作為實驗性 RFC、而 DMARC 僅在 2015 年才成為標準這一情況有關。

國家/地區實體數量存在 SPF存在 DMARC