天天看點

反垃圾郵件技術之密徑追蹤 反垃圾郵件技術之   密徑尋源

中國的網民數量已突破1 億,每年電子郵件發送量達500 億封,但是這樣的資料卻并不能令我們驚喜,因為在這500 億封電子郵件中,有将近60%也就是有300 億封是垃圾郵件。垃圾郵件已經成為一個綜合性的社會問題,要想從根本上杜絕垃圾郵件的泛濫,必須采取全民總動員的方式。由政府出面組織立法,行業制訂規則、積極協調,郵件服務商則提供技術,使用者積極參與、協同合作。隻有這樣,形成一個大衆化的反垃圾郵件聯盟,才能從根本上取得顯著成效。

垃圾郵件泛濫的今天,如果收到了垃圾郵件,你可能會根據郵件的提示采用取消訂閱的操作,而這些取消訂閱的方法根本就是一種僞裝,幾乎沒有一個是有效的。相反,郵件的發起者卻根據你的回報資訊,将你的郵件位址納入有效投遞使用者資料庫,得不償失。追其原因,主要和商業利益以及SMTP協定的安全機制不健全有關。

SMTP協定對我們來說,應該是再熟悉不過的了,但是,這個協定在建立的時候并沒有考慮到未來的郵件會成為垃圾,是以安全性很差(人們還是以RFC524為基礎來執行SMTP的),郵件頭可以任意建立、僞造和修改。郵件伺服器一般不檢查發送者的内容,而隻關心接收者,這就給了垃圾郵件發送者可乘之機。網際網路上的SMTP認證是針對無限制轉發采取的措施。所謂無限制轉發,就是任何人都可以使用你的伺服器發送郵件,一方面降低了投入成本,另一方面隐藏了真實的來源。隐藏真實位址的原因主要是因為垃圾郵件發送在許多國家屬于違法行為,另外,垃圾郵件發送者(spammer)都明白垃圾郵件是不受歡迎的,通過僞造發送者位址,就可能減少這種反應。早在2002年的時候,歐美的一些IT技術論壇上,關于因為大量的垃圾郵件引起了西方ISP屏蔽中國郵件伺服器的“熱潮”,就曾經廣為部署過。當時,中國電信的202.96.0.0—202.111.255.255範圍内的全部位址都被屏蔽,這都是垃圾郵件惹的禍。伺服器被中繼(Open Relay)的現象不但阻止垃圾郵件的首要任務,而且也是病毒郵件泛濫的罪魁禍首。

追蹤郵件将很大程度依靠對郵件頭的分析,RFC2076 列出了多數通用的消息頭,此外也可以參考RFC2822。比如在Outlook Express中,我們可以通過點選郵件的進階屬性打開郵件頭部的資訊(圖1),一個郵件頭中常用于分析的項目如下:

1.      <b>Return-Path</b>: [email][email protected][/email] ;回複時發送的位址。很容易被僞造,但常常提供線索,比如有些垃圾郵件經常用該域指向一個合法的郵件位址,以便spammer能夠接收到回複的郵件;

2.      <b>Delivered-To</b>: [email][email protected][/email];和後面的“To”相同,收信人位址;

3.      <b>Received</b>: from mail.domian1.net (unknown [192.168.x.148])

    by mail.domain2.com (Postfix) with ESMTP id 66B1612191F

    for &lt;nospammer% mymail.com @domian2.net &gt;; Mon, 24 Jul 2006 05:11:54 +0800 (CST)

郵件頭中最可信部分。一般會有幾條,形成站點清單,這些資訊表明達到目的地過程中郵件所經過的伺服器,域名都是郵件伺服器自動插入的,spammer 可以僞造,但是在被僞造以後經過的域名是可信的。這個清單從下往上表明了伺服器路徑,最上面的一條Received是最終目的郵件伺服器,也就是自己要接收郵件的伺服器,除非它也出現了問題。Receive 語句的基本表達格式是:from Server A by Server B,Server A 為發送伺服器, Server B 為接收伺服器。ESMTP ID 表示

4.      <b>Message-ID</b>: &lt;000001c6ae9c$a563a520$a4e8a8c0@saj61&gt; ,郵件系統在建立郵件時的唯一标記(參考RFC822、RFC1036)。也經常被僞造,但如果是正常的,那麼Message-ID:也通常能确定發送者所登入的系統,而不僅僅是郵件被建立的系統。Message-ID 的結構同郵件伺服器程式有直接關系,不同的郵件伺服器的ID也不相同,但差別于ESMTP ID;

5.      伺服器産生的ID 也不一樣,有時相同郵件伺服器的不同處理也會産生不一樣的ID

6.      <b>Reply-To</b>: "Olabode Eberly" &lt;[email][email protected][/email]&gt; 回複位址,被僞造;

7.      <b>From</b>: "Olabode Eberly" &lt;[email][email protected][/email]&gt; 發信人位址,被僞造;

8.      <b>To</b>: nospammer@ mymail.com

一個完整的郵件傳輸過程如下:<b>“郵件發送者→ MUA → MTA → 網絡傳輸→MTA → MDA→ 可能會有的郵件過濾 →MUA → 郵件接收者”。</b>通過郵件傳輸原理,就可以将每個環節的不同特征拿出來,這為我們判别垃圾郵件帶來幫助<b>(圖2)</b>。

l         <b>MUA </b>(Mail User Agent)

Mail Client端的軟體,它幫我們傳送與接受Mail,使用者通過它來跟 Mail Server 溝通,最常見的 MUA 有 Outlook Express和Fox Mail等

l         MTA (Mail Transfer Agent)

它的作用是幫助我們把Mail傳送給其它Mail Serve,同時接受外部主機寄來的信件,所有的 SMTP servers 都可稱為MTA。

l         MDA (Mail Delivery Agent)

這項服務是用來把 MTA 所接受的Mail傳遞至使用者 Mailbox(收信箱)裡面,部分SMTP Servers 也兼顧這MDA的角色。

l        收信、發信人位址

在我們收到的垃圾郵件中經常遇到發信人是我們自己的名字,或者收信人根本是與自己毫無關系的名字。這是因為收信人的MUA會從郵件中提取,From、To、Date字段,如果發信人的MUA不是按照正常的邏輯工作的,或者發信人有意的使用垃圾郵件發送軟體,那麼就會變更MAIL FROM 和RCPT TO 的值,使其擁有了不同的郵件位址。這個時候,MAIL FROM的值絕對是不可信的,而發信者為了得到收信人的回報資訊,所有我們可以通過RCPT TO 中的域名位址來定位來源。

l        非法中繼

如果發信人使用的不是自己所擁有的郵件伺服器,在傳輸過程中使用網際網路上帶有Open Relay漏洞的伺服器,這就為判别郵件的真實來源帶來的困難。在<b>Received</b>字段中如果包含了既不是發信人,又不是收信人域名的郵件伺服器,這就很有可能是被非法中繼的伺服器,我們可是使用TELNET等工具測試這台伺服器是否具有Open Relay漏洞。

l        反向解析不同

如果發信人的域名為sender.com,但他在SMTP對話中的HELO指令後冒充另外一個域名是,比如 HELO testname.org ,此時信件的<b>Received</b>字段很有可能是如下形式:<b>Received</b>: from testname.org (sender.com [192.168.100.100]) by……, 我們通過對testname.org進行反向位址查詢後,就能發現IP位址資訊與這個域名位址不符。

l        查找僞造的<b>Received</b>

由于怕暴露自己的真實資訊,垃圾郵件的發送者經常在郵件頭中插入大量的<b>Received</b>行。如果你的郵件頭中存在大量的<b>Received</b>字段,最後幾行一般是被插入的,因為信件一旦離開主機後,發信人是無法進行控制的,所經過的郵件服器将自動将資訊加入到信頭頂部。從上到下追蹤From和by的資訊,以及IP的路由資訊,是可以判别那些行是被僞造的。

通過上述内容我們有可能查找出郵件的真實發送IP,将其屏蔽,但如果發信方采用撥号的方式進行發送,或者機場經常更換位址,這就增加了判别正确的可信度。早在 1999 年,垃圾郵件與病毒郵件還未成為全球IT業關注議題時,制定網際網路與電子郵件相關标準的 IETF/IRTF等機關就送出檔案 RFC 2505, 針對反制垃圾郵件的 SMTP MTA 主機設計提出規劃建議:需要SMTP MTA 主機應針對郵件發送來源進行通透解析,判定是否具匿名、僞造、濫發等非法行為,以采取退件或延遲反制機制;RFC 2505 更提出技術洞見,預言具彈性辨識機制、精良設計的 MTA 才能時時因應垃圾濫發者的反制手法。深度垃圾郵件行為解析必需在 MTA 階段執行,以郵件傳輸值追蹤技術、郵件通訊行為解析技術與預設濫發者類型Pattern,追蹤、驗證并判斷來信是否為垃圾郵件。絕非淺層郵件行為解析如聯機次數分析、發送 IP 位址、發送時間、發送頻率、收件者數目、淺層電子郵件标頭檢查、發送行為偵測與檢驗Handshaking 聯機階段等資訊可判斷

本文轉自張琦51CTO部落格,原文連結:http://blog.51cto.com/zhangqi/33834,如需轉載請自行聯系原作