咨詢郵箱?咨詢郵箱:[email protected] 咨詢熱線?咨詢熱線:0431-81793699 微博 微信
網易郵箱率先支持新電郵安全協議 DMARC 了!
發表日期:2018-01-02   文章編輯:    瀏覽次數: 934

【Email安全性的現狀】

————————————————————————

    人如其名,[SMTP](Simple Mail Transfer Protocol)協議的工作原理簡單+直接,但同時也存在諸多安全隱患,發件人身份合法性驗證就是其一。

    原始的[SMTP]沒有要求驗證發件人的合法性,各路壞人利用了此紕漏制造出來大量釣魚郵件phish)和詐騙郵件fraud)等涉及到安全性的垃圾郵件(spam),這類spam的最大企圖就是從收件人手動誘騙到一些有價值的信息(個人密碼,銀行卡密碼,信用卡資料等等)。

    常見地,spammer們可以不費吹灰之力地偽造一封發自[email protected]的郵件,郵件正文內容則仿照著Paypal官方的密碼找回郵件的樣式和口吻,要求收件人輸入自己的銀行卡帳號和密碼。如果不明真相的群眾不知道這是一封釣魚郵件,則非常容易上當受騙。

 

    近來有統計數據(http://www.marketingtechblog.com/dmarc-infographic/)顯示,全球范圍內每天仍有約1億的釣魚郵件在投遞著,每年因phishing/fraud spam而泄漏的個人密碼,銀行卡/信用卡信息等資料更是不計其數,對受害人和社會造成的影響實在太大,太惡劣!

    同時各家電子郵件服務運行商(Email Sevice Provider,如網易,Gmail,Hotmail等)也苦不堪言,想盡辦法希望能解決這類問題。

    后來相繼出現了[SENDERID],[SPF],[DKIM]等電郵安全協議,試圖輔助[SMTP]加強其安全性,解決偽造郵件的問題。這些安全協議在一定程度上發揮了功效,攔截掉一部分釣魚郵件或詐騙郵件。無奈道高一尺魔高一丈,狡猾的spammer們的造假手段極其豐富和專業,他們很快發現并利用這些安全協議的不足之處,繼續制造和發送釣魚/詐騙郵件,其數量仍舊不菲??!無辜的郵箱用戶們仍亟需幫助!

 

【DMARC誕生】

————————————————————————

    2012年1月30號,由Paypal,Google,微軟,雅虎,ReturnPath等15家行業巨頭(主要包括 金融機構,Email服務提供商,數據分析機構等)聯手宣布成立了新的互聯網聯盟dmarc.org,致力于提交并推廣一款[DMARC]新電子郵件安全協議。隨著該聯盟的日漸發展,繼而有網易等其他行業先行者也加入到其中。

    “DMARC”是Domain-based Message Authentication, Reporting and Conformance的英文首字母縮寫,其官網為 http://www.dmarc.org 。

    目前該組織的官方成員有:

網易郵箱率先支持新電郵安全協議 DMARC 了! - panda - 紐約市委陳書記s Blog

 

    和其他電郵安全協議的美好初衷一樣,[DMARC]協議的主要目的是識別并攔截釣魚郵件,使釣魚郵件不再進入用戶郵箱中(收件箱or even垃圾箱),減少郵箱用戶打開/閱讀到釣魚郵件的可能性,從而保護用戶的帳號密碼等個人信息安全。

    目前(2012-07-19)DMARC協議尚未成熟,仍處于草案(draft)階段,至今已有兩個草案版本,待其完善后將提交給IETF變成正式的RFC規范。所以嚴格地說,目前還只有DMARC草案(DMARC1 Version),未能稱DMARC協議。

    [基本原理]:[DMARC]協議基于現有的[DKIM]和[SPF]兩大主流電子郵件安全協議,由Mail Sender方(域名擁有者Domain Owner)在[DNS]里聲明自己采用該協議。當Mail Receiver方(其MTA需支持DMARC協議)收到該域發送過來的郵件時,則進行DMARC校驗,若校驗失敗還需發送一封report到指定[URI](常是一個郵箱地址)。

 

 

【DMARC vs DKIM/SPF】

————————————————————————

  1. DKIM/SPF/DMARC都是由Mail Sender/Domain Owner聲明在DNS里,但DKIM/SPF策略單一(如只能是Reject/Pass/Etc),而DMARC策略更靈活(多種組合策略,支持百分比等)。
  2. DKIM/SPF 的Mail Sender和Mail Receiver雙方無任何信息交流(協議本身已無這方面的考慮和設計),而DMARC協議本身就支持Report的功能(Domain Owner除可以聲明策略,還可以聲明自己用于接收Report的[URI])。
  3. DKIM/SPF 可以嚴格限制某個域名的來源合法性,但無法限制該域名的子域名,相當于子域名無法得到保護(無法窮舉每一個子域名并為它們逐一添加SPF記錄)。
  4. 當一個站點的郵件服務器數量多或IP更換頻繁時,這個域通常不設置SPF或僅設置為軟失敗。
  5. 有些允許合法使用多個域名的郵箱服務器(譬如企業郵箱提供商),所有在同一家服務商上注冊企業郵服務的域名(如A.Com和B.Com),它們的SPF記錄都指向相同的IP列表,這種情況下僅僅靠SPF是阻止不了A.Com發送一封謊稱發自B.Com的偽造郵件的!
  6. 當Mail Receiver方在MX機器上依據DKIM/SPF發現一封驗證失敗但僅僅只能定性為可疑(如ADSP不是Discardable 或 SPF結果不是Hard-Fail)時,這時Mail Receiver方會很困惑(這封郵件到底是不是偽造的??。?,無法確定下來到底要不要拒收(因為Mail Receiver方不知道Domain Owner方對這類可疑郵件的處理態度,到底你們是希望我拒收呢還是漏進來呢?漏進來是放收件箱還是垃圾箱呢?)。。。而當這封Spam逃過其他反垃圾手段(黑名單,郵件特征過濾,郵件內容過濾等)的檢查之后,它就能漏進到收件人的郵箱了。而如果Domain Owner方采用DMARC協議(可以在DNS記錄里明確地聲明對這類可疑郵件的處理策略,Reject或進垃圾箱,相當于授權給Mail Receiver方),那Mail Receiver方就可以非常果斷地(因為是依據Domain Owner的授權和策略),不帶一絲猶豫(擔心誤判)地處理這類郵件了。
  7. Etc

 

由于DMARC有諸多先天優勢,故其發起者(DMARC聯盟)稱DMARC協議的目的之一就是替換掉[ADSP]。

 

 

【誰需要DMARC】

————————————————————————

[1]  首先,對于Mail Sender/Domain Owner一方,他們大多會 發布SPF記錄 或 使用DKIM 來保護自己的域名免遭壞人偽造,現在有了這么一個優秀的DMARC協議,是不是他們都需要再發布一條DMARC記錄來加強保護呢?

我個人的看法是:并非所有的域名都需要DMARC。理由是:

有這么一類特別的域名,它們經常被spammer利用于偽造各種釣魚/詐騙郵件,譬如一些 銀行/保險公司等金融企業(花旗,Bank Of America,FDIC,etc),支付商(支付寶,Paypal,etc),知名網站(Facebook,LinkedIn,etc),政府網站等等。這種類型的域名,事實已經證明他們的域名僅僅靠SPF/DKIM的保護是不夠的,再新增依靠DMARC更有助于降低他們的域名被利用于偽造的可能性。

而對于一些普通域名(中小型企業,不知名網站,對外開放注冊的服務商(如163.com/126.com/gmail.com/hotmail.com)),偽造這類域名的釣魚郵件的利益很低,大多數spammer不屑于去偽造來自這些域名的詐騙郵件(他們通過常規手段(批量注冊或低價購買)就可以獲得一大堆合法帳號)。對于這類域名(數量應遠多于第一類),依靠SPF/DKIM就足夠保護自己的域名了,不再需要多一個DMARC,否則效果不明顯還反倒加大了維護成本(不是絕對^_^)

 

[2]  其次,對于Mail Receiver這一方,他們需要DMARC嗎?

當然需要了,無論是對專業郵箱提供商(網易,Gmail等),還是個人架設的郵箱服務器(單位郵箱等),他們都非常希望攔截掉所有類型的垃圾郵件和偽造郵件。所以只要條件允許,他們都會支持越多的安全檢查手段(SPF/DKIM/DMARC等)。

 

[3]  再次,對于普通的郵箱用戶,他們需要DMARC嗎?

普通用戶是間接受益于DMARC。他們不需要每個人都參與到DMARC中,但他們需要選擇優秀的已支持DMARC協議的郵箱服務商(如網易,Gmail等)來注冊,或要求他們的管理員升級自己的郵箱服務器使之支持DMARC協議,確保自己的個人信息安全受到更好的保護。

 

 

【DMARC技術方案】

————————————————————————

[1]  DMARC不用于判斷一封郵件是否為垃圾郵件,而是將郵件區分為 Aligned / Non-Aligned 兩種類型。

  • Aligned 表示郵件合法性驗證通過,是一封來源可信的郵件。
  • Non-Aligned 表示郵件合法性驗證失敗,是一封來源偽造的郵件。

 

[2]  首先,由Mail Sender/Domain Owner方為“_dmarc”子域創建一條DNS TXT記錄(簡稱DMARC記錄),以此來聲明自己的域名將使用DMARC協議來保護。

如下面paypal和支付寶兩個域名的DMARC記錄實例(DMARC記錄中各個tag的含義詳見[DMARC] spec 6.1):

[[email protected] ~] $ dig +short txt _dmarc.paypal.com

"v=DMARC1\\; p=reject\\; rua=mailto:[email protected]\\; ruf=mailto:[email protected]\\;"

[[email protected] ~] $ dig +short txt _dmarc.alipay.com

"v=DMARC1\\; p=none\\; rua=mailto:[email protected]\\; ruf=mailto:[email protected]"

[[email protected] ~] $

 

[3]  接下來主要就是Mail Receiver方的工作了。當Mail Receiver方收到一封郵件,發現信頭的From:域已設置有DMARC記錄,則開始做DMARC校驗,并結合DMARC校驗結果和DMARC記錄里的p tag or sp tag里的策略來決定下一步的投遞動作,而忽略這封郵件的DKIM/SPF檢查結果。

 

[4]  DMARC校驗的核心過程:

  1. 從郵件信頭中提取出信頭From字段的Domain(RFC5322.From Domain),稱域名A。域名A只能有一個域名。
  2. 查詢DNS,得到域名A的DMARC記錄。若該域無設置DMARC記錄,忽略本次DMARC校驗。
  3. 校驗DKIM,若DKIM驗證成功的話,則獲取DKIM簽名中的"D="字段值,稱域名B。信頭中有多個DKIM簽名驗證通過,則域名B有多個域名。
  4. 校驗SPF,若SPF驗證成功的話,則獲取本次SMTP會話中MAIL FROM值的Domain(RFC5321.MailFrom Domain,或稱Envelope Sender Domain),稱域名C。域名C只能有一個域名。
  5. 校驗DMARC,將域名B+域名C中的每一個域名和域名A進行DMARC比較(見第6點),若當中有至少一個域名的比較結果為一致(Aligned)則認為DMARC檢查通過( Aligned ),否則認為DMARC檢查失?。?Non-Aligned )。
  6. DMARC比較: Relaxed模式下,所比較的域名和域名A完全一致,或為域名A的父域名,則認為是Aligned 。 Strict模式下,所比較的域名和域名A完全一致,才認為是Aligned。
  7. 一旦整個DMARC校驗結果為 Non-Aligned 且Pct命中,收信域將執行DMARC策略:None/Quarantine/Reject(見[5])。
  8. 上述過程中有很多因素會中斷/放棄本次DMARC檢查,如提取不到域名A,域名A不存在(Mx/A/DMARC記錄不存在),DMARC記錄Pct值限制等。
  9. 收信域還有義務( 非強制 )發送三類Report(見[6])。

 

[5]  DMARC策略(來自DMARC記錄的p/sp標簽),DMARC1版本只有3個可選值:

  • None 僅做測試,收信方應忽略DMARC檢查結果,進入后續的反垃圾流程,但不影響Report的發送。
  • Quarantine 收信方應認為這是一封可疑郵件,投遞到垃圾箱或做特殊標記。
  • Reject 收信方應直接拒絕本次SMTP會話請求(550)。

 

[6]  DMARC report(來自DMARC記錄的rf/ri/rua/ruf標簽),DMARC1版本定義3類report:

  • Failure Reports(詳見[DMARC] Sepc 8.2),當郵件的SPF或DKIM驗證失敗時發送;Report格式可為[AFRF](基于[ARF])或[IODEF] ;Report發送方式有 Ssl Mailto/Http Post/Https Post 三種途徑。
  • Aggregate Reports(詳見 [DMARC] Sepc 8.1),匯總某個時間區間(Ri標簽,缺省為86400)中的所有DMARC校驗歷史數據(成功+失?。?;Report格式為[XML](Zip壓縮) ,其XML Schema見Spec  Appendix E附錄;Report發送方式同 Failure Reports。
  • Error Reports(詳見 [DMARC] Sepc 12.2.4),當發送某份Failure Reports或 Aggregate Reports失敗時,需至少嘗試發送一次 Error Reports;Report格式為[MIME],具體內容要求見Sepc;須發送往全部Mailto URIs,可選地發送給其他Listed URIs(如Http/Https)。

 

 

【一個DMARC攔截釣魚郵件的例子】

————————————————————————

    下面偽造一封自稱發自[email protected]的郵件,發往網易郵箱(以163.com為例),看163.com的MX機器是否會拒收這封郵件。

[1]  首先查詢一下paypal.com的DMARC記錄:

[[email protected] ~] $ dig +short txt _dmarc.paypal.com

"v=DMARC1\\; p=reject\\; rua=mailto:[email protected]\\; ruf=mailto:[email protected]\\;"

[[email protected] ~] $

 

[2]  連接網易域163.com的一臺MX機器,發送一封paypal偽造郵件:

[[email protected] ~] $ telnet 220.181.12.55 25     <-- 連接163.com域的mx機器

Trying 220.181.12.55...

Connected to 163.mxmail.netease.com (220.181.12.55).

Escape character is '^]'.

220 163.com Anti-spam GT for Coremail System (163com[20111010])

helo aa.com

250 OK

mail from:  <-- 自稱來自[email protected],那么aa.com將作為本次會話的域名C(RFC5321.MailFrom domain)。

250 Mail OK

rcpt to:

250 Mail OK

data

354 End data with .

from:  <-- 偽造稱自己是[email protected],那么paypal.com將作為本次會話的域名A(RFC5322.From domain)。

to:test

subject:test

<-- 本封郵件的信頭無DKIM簽名,那么域名B將為空("d" tag of DKIM-Signature)。

test

.

550 MI:DMA mx30, UMCowEA5KktUto9Pd5j7AQ--.2229S2 1334818442 http://mail.163.com/help/help_spam_16.htm?ip=220.181.15.243&hostid=mx30&time=1334818442  <-- 163.com返回550 MI:DMA并拒收了這封郵件。

quit

221 Bye

Connection closed by foreign host.

[[email protected]r ~] $

 

[3]  本次測試的說明:

  • 上面這封偽造郵件,域名B+域名C中沒有一個域名和域名A能匹配上,即DMARC校驗不通過(Non-Aligned)。那么根據Paypal.Com的DMARC策略(Reject)要求,163.Com的MX服務器拒收了這封郵件(返回了550 MI:DMA)。
  • 在網易郵箱的幫助頁面(Http://Help.163.Com/09/1224/17/5RAJ4LMH00753VB8.Html)上,可以找到網易對其550 MI:DMA退信原因的解釋說明:

網易郵箱率先支持新電郵安全協議 DMARC 了! - panda - 紐約市委陳書記s Blog

 

【小結】

————————————————————————

    在[DMARC]協議出現之前,網易/Gmail/Hotmail/Yahoo等ESP廠商對詐騙郵件的有效技術手段是有限的,而spammer和phisher們則仍舊肆無忌憚地不知疲倦地制造著各種偽造郵件(利益鏈還在,技術手段又有限,悲。。)。

    現在有了DMARC協議,如上文測試例子中的簡單偽造郵件,甚至是用心良苦制作精良的釣魚郵件,都將被識別出來,無法再進入到收件人的郵箱中(連垃圾箱都不會進入)!

    而對于DMARC這個新鮮事物,DMARC聯盟,電子郵件服務商,IT媒體等各方無不拍手稱好,但也已經有部分資深IT專業人士指出其局限性。各方對DMARC的態度和看法,有興趣的童鞋可見我的另一篇博文 http://blog.163.com/[email protected]/blog/static/980032452012320115635999/ 。

 

    無論如何,[DMARC]確實是一個很給力的電郵安全協議,目前,DMARC聯盟中的多家ESP廠商(Gmail/Hotmail)都已經率先支持該協議。

    在中國,網易郵箱也是相當給力。作為該聯盟的官方成員,2012年4月起就開始支持[DMARC]協議,是國內首家支持DMARC協議的互聯網服務提供商,竭力保護著163.com/126.com/yeah.net等網易郵箱用戶的個人信息安全。感謝網易郵箱造福我們這些普通的郵箱用戶 ^_^ 網易郵箱率先支持新電郵安全協議 DMARC 了! - panda - 紐約市委陳書記s Blog 。

    隨著越來越多的廠商了解并支持[DMARC]協議,相信全球會有越來越多的Email用戶受益于此,免遭釣魚郵件和詐騙郵件之苦。


相關文章推薦
腾讯分分彩全天开奖