Cloudflare助您有效應(yīng)對(duì)電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú)

來(lái)源: Cloudflare
作者:Cloudflare
時(shí)間:2021-10-21
18490
今天,我們推出了一個(gè)新的工具來(lái)對(duì)付電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú),并改善電子郵件的發(fā)送情況:全新電子郵件安全 DNS 向?qū)Э捎糜趧?chuàng)建 DNS 記錄,防止其他人代表你的域發(fā)送惡意電子郵件。這個(gè)新功能還會(huì)在用戶(hù)的域上存在不安全的 DNS 配置時(shí)發(fā)出警告,并顯示如何修復(fù)這些配置的建議。這項(xiàng)功能將首先在 Free 計(jì)劃中向用戶(hù)推出,在接下來(lái)的幾周內(nèi),Pro、Business 和 Enterprise 用戶(hù)也將可以使用。

今天,我們推出了一個(gè)新的工具來(lái)對(duì)付電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú),并改善電子郵件的發(fā)送情況:全新電子郵件安全 DNS 向?qū)Э捎糜趧?chuàng)建 DNS 記錄,防止其他人代表你的域發(fā)送惡意電子郵件。這個(gè)新功能還會(huì)在用戶(hù)的域上存在不安全的 DNS 配置時(shí)發(fā)出警告,并顯示如何修復(fù)這些配置的建議。這項(xiàng)功能將首先在 Free 計(jì)劃中向用戶(hù)推出,在接下來(lái)的幾周內(nèi),Pro、Business 和 Enterprise 用戶(hù)也將可以使用。

在我們深入了解這個(gè)向?qū)У纳衿嬷幹?,我們先后退一步,了解一下這個(gè)問(wèn)題:電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú)。

什么是電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú)?

欺騙指為了獲得某種非法利益而偽裝成別人的過(guò)程。例如域名欺騙:某人托管 mycoolwebpaqe.xyz 網(wǎng)站以欺騙 mycoolwebpage.xyz 的用戶(hù)提供敏感信息,使用戶(hù)誤以為這是正確的網(wǎng)站。在瀏覽器的地址欄并排查看時(shí),很難發(fā)現(xiàn)兩者的區(qū)別。

此外還有電子郵件欺騙。為了了解它是如何工作的,請(qǐng)看一下我通過(guò)自己的個(gè)人電子郵件地址收到的一封 Cloudflare 產(chǎn)品更新電子郵件。對(duì)于大多數(shù)電子郵件提供者,您可以查看電子郵件的完整源代碼,其中包含多個(gè)標(biāo)頭以及電子郵件的主體。

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 個(gè)標(biāo)頭,何時(shí)收到、來(lái)自誰(shuí)、我應(yīng)該回復(fù)給誰(shuí)以及我的個(gè)人電子郵件地址。From 標(biāo)頭的值用于在我的電子郵件程序中顯示發(fā)送者。


當(dāng)我收到以上郵件時(shí),我會(huì)自動(dòng)認(rèn)為這封郵件是由 Cloudflare 發(fā)送的。然而,任何人都可以從他們的電子郵件服務(wù)器發(fā)送帶有修改過(guò)的 From 標(biāo)頭的電子郵件。如果我的電子郵件提供商沒(méi)有進(jìn)行適當(dāng)?shù)臋z查(這一點(diǎn)將在本文稍后討論),我有可能受騙,以為某一封電子郵件是從 Cloudflare 發(fā)送的,但實(shí)際上并非如此。

這就引出了第二種攻擊類(lèi)型:網(wǎng)絡(luò)釣魚(yú)。假設(shè)惡意分子已經(jīng)成功使用電子郵件欺騙向您公司的客戶(hù)發(fā)送電子郵件,這些電子郵件看起來(lái)像來(lái)自您的企業(yè)服務(wù)電子郵件。這些電子郵件使用相同的樣式和格式,其內(nèi)容看起來(lái)完全像來(lái)自您公司的合法電子郵件。電子郵件文本可能是一條緊急信息,要求更新一些帳戶(hù)信息,包括一個(gè)到所謂門(mén)戶(hù)網(wǎng)站的超鏈接。如果用戶(hù)的接收郵件服務(wù)器沒(méi)有將郵件標(biāo)記為垃圾郵件或不安全來(lái)源,他們可能會(huì)直接點(diǎn)擊鏈接,這樣可能會(huì)執(zhí)行惡意代碼或引導(dǎo)他們進(jìn)入一個(gè)欺騙域名并被要求提供敏感信息。

根據(jù) FBI 的 2020 年互聯(lián)網(wǎng)犯罪報(bào)告,網(wǎng)絡(luò)釣魚(yú)是 2020 年最常見(jiàn)的網(wǎng)絡(luò)犯罪,受害者超過(guò) 24 萬(wàn),造成的損失超過(guò) 5000 萬(wàn)美元。自 2019 年以來(lái),受害者人數(shù)增加了一倍多,幾乎是 2018 年的 10 倍。

為了了解大多網(wǎng)絡(luò)釣魚(yú)攻擊如何執(zhí)行,我們仔細(xì)看看 2020 年 Verizon 數(shù)據(jù)外泄調(diào)查報(bào)告中的發(fā)現(xiàn)。報(bào)告顯示,網(wǎng)絡(luò)釣魚(yú)占所有“社交行為”(社交工程攻擊的另一個(gè)說(shuō)法)的 80% 以上,使其成為迄今此類(lèi)攻擊中最常見(jiàn)的一種。此外,報(bào)告指出,96% 的社交行為是通過(guò)電子郵件傳送的,僅 3% 通過(guò)網(wǎng)站、1% 通過(guò)電話(huà)或短信息。

這種情況清楚地表明,電子郵件釣魚(yú)是一個(gè)嚴(yán)重的問(wèn)題,讓互聯(lián)網(wǎng)用戶(hù)非常頭疼。我們來(lái)看看域名所有者能做些什么來(lái)阻止壞人濫用他們的域名進(jìn)行電子郵件釣魚(yú)。

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

幸運(yùn)的是,域名系統(tǒng) (DNS) 中已經(jīng)內(nèi)置了三種反欺騙機(jī)制。

  • 發(fā)送方策略框架 (SPF)

  • 域名密鑰識(shí)別郵件 (DKIM)

  • 基于域名的郵件身份驗(yàn)證報(bào)告和一致性 (DMARC)

然而,正確配置它們并非易事,尤其是對(duì)缺乏經(jīng)驗(yàn)的人而言。如果您的配置過(guò)于嚴(yán)格,合法的電子郵件將被丟棄或標(biāo)記為垃圾郵件。如果配置過(guò)于寬松,您的域名可能被濫用于電子郵件欺騙。

發(fā)送方策略框架(SPF)

SPF 用于指定哪些 IP 地址和域被允許代表您的域發(fā)送電子郵件。SPF 策略以 TXT 記錄的形式發(fā)布在您的網(wǎng)域上,以便人人都能通過(guò) DNS訪(fǎng)問(wèn)。我們來(lái)檢查 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 開(kāi)頭。它通常包含發(fā)送電子郵件服務(wù)器的 IP 地址列表(使用 ip4 或 ip6 機(jī)制)。include 機(jī)制用于參考其他域名上的其他 SPF 記錄。如果您依賴(lài)于其他需要代表我們發(fā)送電子郵件的供應(yīng)商,則通常會(huì)這樣做。您可以在 cloudflare.com 的 SPF 記錄中看到一些例子:我們使用 Zendesk 作為客戶(hù)支持軟件,使用 Mandrill 作為營(yíng)銷(xiāo)和交易電子郵件。

最后,還有一種全面捕獲機(jī)制 -all,其中規(guī)定了所有未指定的入站電子郵件應(yīng)如何處理。全面捕獲機(jī)制之前有一個(gè)限定符,可以是 + (Allow)、~ (Softfail) 或 - (Fail)。不建議使用 Allow 限定符,因?yàn)樗旧蠒?huì)使 SPF 記錄無(wú)效,并允許所有 IP 地址和域名代表您的域名發(fā)送電子郵件。Softfail 通過(guò)接收郵件服務(wù)器進(jìn)行不同解讀,將電子郵件標(biāo)記為垃圾郵件或不安全,具體取決于服務(wù)器。Fail 告訴服務(wù)器不要接受任何來(lái)自不明來(lái)源的電子郵件。

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

  1. 電子郵件發(fā)送自 IP 地址 203.0.113.10,包含的 From 標(biāo)頭值為hannes@mycoolwebpage.xyz。

  2. 收到這封電子郵件后,接收者查詢(xún) mycoolwebpage.xyz 上的 SPF 記錄,以獲得這個(gè)網(wǎng)域的 SPF 策略。

  3. 接收者檢查發(fā)送 IP 地址 203.0.113.10 是否列于 SPF 記錄中。如是,該電子郵件成功完成 SPF 檢查。否則,all 機(jī)制的限定符定義結(jié)果。

關(guān)于所有機(jī)制的完整列表以及關(guān)于 SPF 的更多信息,請(qǐng)參閱 RFC7208。

域名密鑰識(shí)別郵件(DKIM)

好啦,通過(guò)使用 SPF,我們已經(jīng)確保只有允許的 IP 地址和域名才能代表 cloudflare.com 發(fā)送電子郵件。但是,如果其中一個(gè) IP 在我們沒(méi)有注意到的情況下改變了所有者并更新了 SPF 記錄,我們?cè)趺崔k?或者,如果其他人也使用谷歌的電子郵件服務(wù)器以相同的 IP 試圖欺騙來(lái)自 cloudflare.com 的電子郵件怎么辦?

此時(shí)即可使用 DKIM。DKIM 提供一種機(jī)制,可加密簽署電子郵件的多個(gè)部分 — 通常為主體和某些標(biāo)頭 — 它使用的是公共密鑰加密。在深入了解其工作原理之前,我們先看看 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āi)頭,之后是公共密鑰。我們可以看到公共密鑰的類(lèi)型,引用了 k 標(biāo)記和公共密鑰本身,前面是 p 標(biāo)記。

下面是簽名和 DKIM 檢查工作原理的簡(jiǎn)化序列:

  1. 發(fā)送電子郵件服務(wù)器根據(jù)電子郵件內(nèi)容創(chuàng)建 hash

  2. 發(fā)送電子郵件服務(wù)器加密此 hash(使用 DKIM 私鑰)。

  3. 發(fā)送電子郵件時(shí)包含加密的 hash。

  4. 接收電子郵件服務(wù)器從電子郵件域名上發(fā)布的 DKIM TXT 記錄中檢索公鑰。

  5. 接收郵件服務(wù)器使用公共 DKIM 密鑰解密 hash。

  6. 接受電子郵件服務(wù)器根據(jù)電子郵件內(nèi)容生成 hash。

  7. 如果解密的 hash 與生成的 hash 匹配,則電子郵件真實(shí)性得到驗(yàn)證。否則,DKIM 檢查不通過(guò)。

完整 DKIM 規(guī)范可參閱 RFC4871 和 RFC5672。

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

基于域名的郵件身份驗(yàn)證報(bào)告和一致性,這個(gè)名稱(chēng)確實(shí)很拗口。我們來(lái)關(guān)注兩個(gè)詞:報(bào)告一致性。這正是 DMARC 提供的內(nèi)容。定期報(bào)告讓郵件發(fā)送者知道有多少郵件不符合要求,可能受到欺騙。一致性有助于向郵件接收者提供一個(gè)明確的信號(hào),告訴他們?nèi)绾翁幚聿环弦蟮泥]件。即使沒(méi)有 DMARC 記錄,郵件接收者也可能會(huì)對(duì) SPF 或 DKIM 檢查不通過(guò)的郵件施加自己的策略。但是,在 DMARC 記錄上配置的策略是電子郵件發(fā)送者的顯式指令,因此它增強(qiáng)了電子郵件接收者處理不符合要求電子郵件的信心。

這是 cloudflare.com 的 DMARC 記錄

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

DMARC TXT 記錄始終在電子郵件域名的 _dmarc 子域上設(shè)置 — 類(lèi)似于 SPF 和 DKIM — 內(nèi)容需要以 v=DMARC1 開(kāi)頭。之后是三個(gè)附加標(biāo)記:

策略標(biāo)記 (p) 指示電子郵件接收者如何處理 SPF 或 DKIM 檢查不通過(guò)的電子郵件??赡苤禐?none、reject 和 quarantine。none 策略也稱(chēng)為僅監(jiān)視,允許仍然接受檢查不通過(guò)的電子郵件。通過(guò)指定 quarantine,電子郵件接收者將不符合 SPF 或 DKIM 的電子郵件放入垃圾郵件文件夾。對(duì)于 reject,如果 SPF 或 DKIM 檢查不通過(guò),將丟棄電子郵件,根本不發(fā)送。

百分比標(biāo)記 (pct) 可用于僅對(duì)傳入電子郵件的子集應(yīng)用指定的策略。如果您剛剛推出 DMARC,并且希望通過(guò)在子集上測(cè)試以確保所有配置都正確無(wú)誤,則這樣很有幫助。

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


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

  1. From 標(biāo)頭值為 hannes@mycoolwebpage.xyz 的電子郵件被發(fā)出。

  2. 接收者查詢(xún)網(wǎng)域 mycoolwebpage.xyz 的 SPF、DKIM 和 DMARC 記錄以獲取所需原則和 DKIM 公鑰。

  3. 接收者執(zhí)行如上所述的 SPF 和 DKIM 檢查。如兩者均通過(guò),該電子郵件被接受并投遞到收件箱。如果 SPF 或 DKIM 檢查失敗,將遵循 DMARC 原則并確定郵件是否仍被接受、丟棄或發(fā)送到垃圾郵件文件夾。

  4. 最后,接收者返回一個(gè)匯總報(bào)告。根據(jù) rua 標(biāo)記中指定的電子郵件,報(bào)告也可能被發(fā)送到負(fù)責(zé)該電子郵件的另一個(gè)電子郵件服務(wù)器。

其他可選標(biāo)記和完整的 DMARC 規(guī)范可參閱 RFC7489。

關(guān)于目前采用情況的一些數(shù)據(jù)

現(xiàn)在我們已經(jīng)知道了問(wèn)題是什么,以及如何使用 SPF、DKIM 和 DMARC 來(lái)解決問(wèn)題,下面,我們看看它們的普及情況。

Dmarc.org 已經(jīng)發(fā)布了一個(gè)代表性數(shù)據(jù)集中采用 DMARC 記錄的域名的情況。其中顯示,到 2020 年底,仍只有不到 50% 的域名擁有 DMARC 記錄。記住,沒(méi)有 DMARC 記錄,就不會(huì)明確執(zhí)行 SPF 和 DKIM 檢查。研究進(jìn)一步表明,在具有 DMARC 記錄的域名中,超過(guò) 65% 的域名使用僅監(jiān)視策略 (p:none),因此,推動(dòng)更高的采用率潛力巨大。該研究沒(méi)有提到這些域名是否有在發(fā)送或接收電子郵件,但即使它們沒(méi)有接收或發(fā)送,安全配置也應(yīng)該包括 DMARC 記錄(稍后詳細(xì)介紹)。


2021 年 8 月 1 日的另一份報(bào)告指出,屬于銀行業(yè)實(shí)體的域名也出現(xiàn)了類(lèi)似情況。在美國(guó) 2881 家銀行實(shí)體中,只有 44% 的實(shí)體在其域名上發(fā)布了 DMARC 記錄。在有 DMARC 記錄的實(shí)體中,大約有 2/5 的實(shí)體將 DMARC 策略設(shè)置為 None,另外 8% 的實(shí)體存在“配置錯(cuò)誤”情況。丹麥銀行領(lǐng)域的域名中使用 DMARC 的比例非常高,達(dá)94%,而日本只有 13% 的域名使用 DMARC。SPF 的采用平均顯著高于 DMARC,這可能與 2006 年首次引入 SPF 標(biāo)準(zhǔn)作為實(shí)驗(yàn)性 RFC、而 DMARC 僅在 2015 年才成為標(biāo)準(zhǔn)這一情況有關(guān)。

國(guó)家/地區(qū)實(shí)體數(shù)量存在 SPF存在 DMARC
丹麥5391%94%
英國(guó)8388%76%
加拿大2496%67%
USA2,88191%44%
德國(guó)3974%36%
日本9082%13%

這表明我們還有很大的改進(jìn)空間。

進(jìn)入:電子郵件安全 DNS 向?qū)?/strong>

那么,我們要怎樣做才能增加 SPF、DKIM 和 DMARC 的采用率并應(yīng)對(duì)電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú)?進(jìn)入新的 Cloudflare 電子郵件安全 DNS 向?qū)А?/span>

從今天開(kāi)始,當(dāng)您瀏覽到 Cloudflare 儀表盤(pán)的 DNS 標(biāo)簽時(shí),您會(huì)看到兩個(gè)新功能:

1) 新增的電子郵件安全部分


2) 新增的關(guān)于不安全配置的警告


為了開(kāi)始使用電子郵件安全 DNS 向?qū)?,您可以?/span>接點(diǎn)擊警告中的鏈接(引導(dǎo)您進(jìn)入向?qū)У南嚓P(guān)部分)或點(diǎn)擊新的電子郵件安全部分中的配置。后者將向您顯示以下可用選項(xiàng):

有兩種情況。您使用您的域名發(fā)送電子郵件,或沒(méi)有這樣做。如果是前者,您可以通過(guò)以下幾個(gè)簡(jiǎn)單的步驟配置 SPF、DKIM 和 DMARC 記錄。這里是針對(duì) SPF 的步驟。

如果您的域名不發(fā)送電子郵件,有一個(gè)簡(jiǎn)單的方法可一鍵配置所有三個(gè)記錄:

單擊 Submit 之后,將創(chuàng)建所有三個(gè)記錄,并以相應(yīng)方式配置,使所有電子郵件都檢查不通過(guò)并被傳入電子郵件服務(wù)器拒絕。

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;"

幫助應(yīng)對(duì)電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú)

確保您的域名是安全的,能夠防止電子郵件欺騙和網(wǎng)絡(luò)釣魚(yú)。只需前往 Cloudflare 儀表盤(pán)上的 DNS 標(biāo)簽,或者,如果您還沒(méi)有使用 Cloudflare DNS,只需在 cloudflare.com 上花幾分鐘時(shí)間進(jìn)行免費(fèi)注冊(cè)。

如果您想了解關(guān)于 SPF、DKIM 和 DMARC 的更多信息,請(qǐng)查閱我們關(guān)于電子郵件相關(guān) DNS 記錄的新學(xué)習(xí)頁(yè)面。

立即登錄,閱讀全文
版權(quán)說(shuō)明:
本文內(nèi)容來(lái)自于Cloudflare,本站不擁有所有權(quán),不承擔(dān)相關(guān)法律責(zé)任。文章內(nèi)容系作者個(gè)人觀(guān)點(diǎn),不代表快出海對(duì)觀(guān)點(diǎn)贊同或支持。如有侵權(quán),請(qǐng)聯(lián)系管理員(zzx@kchuhai.com)刪除!
個(gè)人VIP