設計一個垃圾語音之防禦系統

設計一個垃圾語音之防禦系統

游坤明 江啟宏

中華大學資訊管理系

{yu；shazi}@pdlab.csie.chu.edu.tw

摘要

由於近年來網路科技技術的進步與普及，電子 郵件已成為人與人之間重要的溝通管道，因此，一 些 觸 覺 敏 銳 的 商 人 意 識 到 了 電 子 郵 件 帶 來 的 商 機，也成為駭客與廣告商一個極其可靠的訊息散播 工具，如今隨著 VoIP 的興起，技術也日趨成熟， 垃圾語音 / 網路廣告電話 ( Spam over Internet Telephony ; SPIT ) 將成為未來一個嚴重的安全性 議題，其嚴重程度甚至可以和垃圾郵件（SPAM） 相提並論，雖然使用者可以應用軟體加以防範垃圾 郵件之問題，但是 SPIT 的問題則無法依照相同的 方法解決，因為 VoIP 是即時性的服務，目前有關 防止垃圾郵件的工具無法直接套用在解決 SPIT 的 問題，加上傳統電話上詐騙電話的日趨猖獗，再配 合上低成本的 VoIP 相結合，勢必對社會治安與網 路安全帶來更大的傷害，因此本論文提出了一個有 效的垃圾語音防禦之架構，此架構除了能透過管理 者手動的方式增加黑名單外，還能夠經由系統中心 自動學習判斷相關資訊後將名單分散式傳送至各 VoIP 代理伺服器，來達到有效抵擋 SPIT 之功能。 關鍵字：會談啟始協定（SIP）、網路電話（VoIP）、 垃圾語音（SPIT）、Authenticated Identity Body（AIB）

Abstract

Due to the fast progress of networking technology, email has become an important communication tool in the present time. Now with the popularity of VoIP. Spam over Internet Telephony (SPIT) will become an important security issue, similar to SPAM. However, the users can apply some available mail software to block spam but SPIT cannot

be dropped in the same way. Since VoIP is a real-time service, the current available tools for SPAM cannot block SPIT effectively. Owning to the growing fraud via telephone and the application on VoIP, SPIT will be a great threat to the society as well as the network security. We propose an efficient infrastructure to block SPIT. The proposed infrastructure not only can manually add the entries of the black list by administrator, but also can distribute the malicious name list to every VoIP proxy by analyzing the information. Keywords：SIP、VoIP、SPIT、AIB

1. 前言 惡意

隨著 IP（Internet Protocol）電信快速發展之 下，從一開始 VoIP 最早是以軟體的形態問世，也 就是單純的 PC to PC，依照傳統電話的使用習慣， 也將 VoIP 和傳統電話 ( Public Switched Telephone Network ; PSTN ) 相互連結，VoIP 也成為企業間競 爭的未來趨勢，目前對許多企業來說，都已經開始 規劃與建置 VoIP 的服務。根據 Phillips Group InfoTech 2000 的調查研究指出，四年內將會有超過 80%的企業會採用此新技術，VoIP 應用隨著 Internet 的頻寬擴大，技術也日趨成熟，所擁有的品質也逐 漸和傳統電話沒有兩樣，只是傳輸技術的不同。 VoIP 的應不僅降低了整個營運成本外，並有效提升 網路服務的競爭力，再加上以 IP 為基礎，能提供企 業在語音、視訊等應用的整合服務，因此 VoIP 是 一種相當有效的「競爭武器」也成為企業商業基礎 的必備條件之一，但相對的帶來了一些安全上的問 題。

SPIT（Spam Over Internet Telephony）-「垃圾 語音」，也有人稱之為垃圾網路電話（Spam Call）， SPIT 的議題是在 InBox IT 2005 電子郵件會議中首 度提出的， IP 通訊匯流中的 VoIP 正促使一種新型 態的垃圾件產生，這個字很快就會橫掃全球。。 假設現有的傳統電話詐騙手法再與 VoIP 相結 合，勢必在社會治安與網路安全會造成更大的影 響，因為 VoIP[2,3,7,10]的不當使用者，可以藉由錄 製好的語音利用 VoIP 的服務進行散播，比起傳統 電話的使用，不但能降低通話成本及人力資源的運 用，且 VoIP 為即時性的服務，如果 VoIP 參照垃圾 郵件殭屍網路（Spam Zombie）的技術，發展出 SPIT Zombie 的網路，可能利用這些網路進行 SPIT 發 送，藉由一傳十、十傳百的方式濫打網路電話或有 意要針對企業 VoIP 或 VoIP 服務提供者進行 DoS 攻 擊，將會造成企業的頻寬嚴重負荷及 VoIP 的服務 癱瘓。 本論文提出了一個有效的垃圾網路電話防禦 架構，此架構除了能透過管理者手動的方式增加黑 名單外，還能夠經由系統中心自動學習判斷相關資 訊後將名單分散式傳送至各 VoIP 代理伺服器，來 達到有效抵擋 SPIT 之功能。

2. 背景

2.1 SIP（Session Initiation Protocol）

現在網路電話主要都遵循 SIP、H.323、MGCP 等三種主要的通訊協定，在過去的產品主要仍是以 H.323 為主，但因為 H.323 協定本身還具有一些技 術上的受限問題以及複雜性相當高，因此 IETF ( Internet Engineering Task Force )在 1999 年 3 月提 出 SIP ( Session Initiation Protocol )[5] 新架構，SIP 則是直接採用文字式( text-based )的通訊協定，簡單 講，SIP 解決了針對 H.323 標準過於龐雜，呼叫建 立的速度慢與擴充性低的缺點，所以在未來 SIP 將 會取代 H.323 成為最多人使用的網路電話之協定。 SIP 網路主要由四種 SIP 元件所組成[9]，分為別用 戶端（User Agent）、代理伺服器（Proxy Server）、

重新導向伺服器（Redirect Server）、註冊伺服器 （Registrar Server），以下分別對每一個元件做說 明：

‧ User Agent：用戶端的終端設備（Terminal）， 簡稱 UA，UA 可以是一個軟體（Soft Phone） 或者是一個獨立的 SIP 話機，主要功能為請 求、回應初始和終止會話（Session）。

‧ Proxy Server：它可視為用戶端及伺服器兩種角 色，當它接收到 User Agent 或其它的 Proxy Server 請求時，並針對請求由 Proxy Server 轉送 到正確的目地位置，圖 1 為 User Agent 透過 SIP Proxy 進行通話的簡易流程。

圖 1 SIP Proxy Server

‧ Redirect Server：重定位伺服器，當 User Agent 或 Proxy 對 Redirect Server 發出請求訊息時， Redirect Server 會回覆一個 Redirect（3xx）的 訊息，讓 User Agent 或 Proxy 得知正確的位置。 ‧ Registrar Server：註冊伺服器，提供 User Agent

進行註冊的界面，並記錄至 Location Server 中 的資料庫。 2.2 SIP 的身份回覆及認證 在 SIP 這種標準的開放式架構之協定，很容易 產生安全上的漏洞，因此 IETF（Internet Engineering Task Force）在 2004 年的 RFC 3893 提出了一個利 用 在 SIP 協 定 上 的 一 種 身 份 驗 證 的 機 制 Authenticated Identity Body (AIB)，這個機制主要是 複製一個 SIP 的表頭附加在請求（Request）的訊息 裡面，再利用複製出來的這個表頭進行數位簽章的 加密動作來進行確保傳送資料中途遭攔截修改，基

於 SIP 這種開放式的協定，就可以運用此種的方式 來進行表示傳送者的身份及接收者的位置之正確 性，以下針對 Authenticated Identity Body (AIB)進一 步的介紹及說明： 表 1 SIP 回應代碼類型 代 碼 類型 說 明 1xx 訊息通知，請求處裡中尚未完成。 (例如：Trying) 2xx 請求處理成功。 3xx 重新導向，將請求訊息重新導向至另一個 SIP 元件。 4xx 客戶端錯誤，錯誤的原因在於請求端。 可以修正後重試。 5xx 伺服器端錯誤，錯誤的原因在於目的端。 可以重試其他的伺服器。 6xx 錯誤(Global Error)，請求失敗且無法重試。

2.2.1 Authenticated Identity Body (AIB)

Authenticated Identity Body (AIB)[12]是一種 類似 MIME 的訊息格式，主要是將 AIB 的訊息加以 數位簽章（Digital Signature）加入在 SIP 的表頭 （header）中，並且提供了身份驗證的功能，AIB 主要是使用 message / sipfrag [16] MIME 的形式， 當要發送一個帶有 AIB 表頭的 INVITE 訊息時，其 內容會包含：Form, Date, Call-ID, Content, To 及 CSeq 等的表頭欄位，除了這些訊息外，也可以增加 更多的表頭資料，有助於加強身份辨識的能力，針 對發送一個 AIB 格式的 INVITE 訊息，範例如下： Content-Type: message/sipfrag

Content-Disposition: aib; handling=optional

From: Alice <sip:[email protected]> To: Bob <sip:[email protected]> Contact: <sip:[email protected]> Date: Thu, 21 Feb 2002 13:02:03 GMT

Call-ID: a84b4c76e66710 CSeq: 314159 INVITE

2.2.2 AIB 回覆身份證明

AIB 回 覆 身 份 證 明 [4] 是 基 於 DAS （Domain-based Authentication Service）的一些優點 進行改良而提出來的一種新的回覆身份及證明的 機制，它滿足了 DAS 的所有要求，且可經由中間 傳送的回應訊息有能力抵擋 SPIT 從中攔截修改資 料的可能，就 DAS 而言，它有能力處理匿名的訊 息，因為回應者必需在回應的訊息表頭清楚加以表 示，但無法隱藏中間所有傳送的資訊，所以 AIB 提 出了解決 DAS 無法隱藏中間資訊的這項缺點加以 改進，接下來說明 AIB 是如何被使用在回應身份及 身份的完整性，圖 2 為 AIB 說明的執行環境圖。 圖 2 執行回覆身份之環境圖

假設 Alice 傳送一個 INVITE 的請求給 Bob， Proxy-2 會收到這個請求並通知回應一個訊息給 Alice，再處理兩個新的表頭欄位，為 Responder 及 Responder-Info： Responder: [email protected]; verifymethod=AIB Responder-Info: https://www.destination.com/certification 在這回覆的訊息內容裡面 AIB 應該最少要包 括 以 下 欄 位 { To, From, Call-ID, CSeq, Date, Responder }，如有額外增加的欄位也可以放入 AIB 中，用來提高回覆訊息的完整性。AIB 也可以在傳 送回覆訊息時，選擇是否隱藏欄位中的資訊，如果

要隱藏資訊可以選擇使用公開金鑰（Public Key） 加密的方式進行加密的動作，換言之，AIB 是利用 私密金鑰（Private Key）在回覆訊息進行簽章的動 作來保證資料的完整性。

2.3 SIP Social Network

SIP Social Network（SIP 社群網路）[13]是一 種以信譽為基礎的機制，在利用 SIP 社群去預防發 垃圾郵件者（SPAMMER）的攻擊，在這種網路架 構是使用口碑系統（Reputation System [1,8]）做為 機制，這種機制應用於在一些不同的區域去將使用 者與一個可靠的社群建立信任，簡單來說，就是給 每位使用者或系統打分數的一個機制，例如：就以 eBay 電子商務網站來說，網站可以依照使用者的交 易 行 為 去 給 予 該 使 用 者 評 價 ， 而 在 SIP Social Network 就提出了一個 SIP Reputation Network 的網 路架構，如圖 3 所示：

圖 3 SIP Reputation Network

一個社群網路可視為一個連繫相同形態或者 相互連結的一群人，再從這群人的關係去繪製出一 個以圖形來表示他們之間的關係，通常這些人都是 通訊軟體的好友名單或者通訊錄名單的集合，再經 由使用者針對通訊名單的每位使用者給予不同的 名譽值（Reputation Value），在完成設定名譽值之 後，可以將大家之間的關係以圖形表示，如圖 3 所 示。

3. 垃圾語音之防禦系統架構

理論上，VOIP 的服務是一項透過 IP 封包傳送 的服務，同樣容易遭受傳統網路的各種攻擊，例 如：DoS 攻擊、病毒、蠕蟲、垃圾郵件、網路釣魚 （phishing）。網路釣魚這種攻擊方式，據華爾街日 報（WSJ）報導，利用網路詐取個人資料的手法再 度翻新，繼「網路釣魚」之後，現在又有「網路釣 語（voice phishing，簡稱 vishing）」，而網路電話 （VoIP）竟成詐騙者的主要工具。在目前針對垃圾 語音（SPIT）的問題，目前還未有一個明確的解決 方 法 ， 就 目 前 研 究 中 ， 有 學 者 提 出 利 用 Social Network[13]的方式，來將使用者給予一個名譽值 （Reputation Value）來決定這通電話是否過於門檻 值而進一步判斷是否為 SPIT，但這種方式只能運用 於小範圍的網路環境，還有其它學者提出[12]，將 通話的兩方建立一個安全的連線，但是這都忽略了 SPIT 的特性，SPIT 是一個即時性的服務且是一個 來自於從未出現過的來源位置，所以要因應 SPIT 這樣一個問題，本論文提出了一個過濾來源的方式 及應用於抵擋 SPIT 的網路架構來抵擋垃圾語音， 在抵擋 SPIT 的網路架構中，由於 SIP 是屬於開放 式的標準，所以在本研究中，利用 AIB 這樣一個機 制來達到以 SIP 建立的網路架構之間連線及資料傳 輸的安全性，再利用階層式架構的方式來收集並分 享 SPIT 資訊，主要是將 SPIT 的 IP 位址加以有時 間限制的列表封鎖，因為 SPIT 即時的服務，所以 要防止 SPIT 必須是即時性的處理，主要元件分為 SPITTrap（垃圾語音補捉器）、SPIT Center（垃圾語 音中心），本論文所提出垃圾語音之防禦系統架構 如圖 4 所示，以下章節針對 SPITTrap 與 SPIT Center 做進一步的說明：

3.1 SIP Filter 運作流程

一般 VoIP 的運作流程如圖 5 所示，由呼叫方 Caller 撥打給被呼叫方 Callee，當 SIP Proxy 接收到 Invite 的訊息時，都會經過 SIP Filter 來判斷是否為 SPIT。

圖 4 垃圾語音之防禦系統架構

圖 5 一般的 VoIP 運作方式

此例子假設由 Caller 撥打 SIP 給 Callee，且 SIP Filter 在 Callee 的 SPITTrap。

流程說明：

1、 當 SIP Filter 收到 INVITE 的訊息時，會先 比對 Caller 是否在 Callee 的通訊錄名單上 2、 如果 Caller 不是 Callee 通訊錄名單上人 員，再進行第二次比對，此時會針對 Proxy 上所有人員名單做比對 3、 此時如果 Caller 都不在 Proxy 上所有人名單 上，再進行黑名單比對（此時才進行比對 黑名單是因為要讓合法使用者優先接通電 話，且有可能黑名單中，如廣告信，對個 人需求來說是合法的通訊名單） 4、 如果 Caller 是在黑名單上，此時會告知 Caller 被 列 入 為 黑 名 單 ， 並 拒 絕 處 理 此 INVITE 的訊息，將此連絡人新增至 SPIT Info 資料庫中 5、 如果不是通訊錄名單上也不是黑名單上的

Caller，此時會進行 Challenge Response 的 測試

6、 Challenge Response 測式：Caller 聽完由 Proxy Server 發出來的問題之後，利用電話 按鍵方式回答問題，如果答錯，則將此 Caller 的帳號列為黑名單並結束通話 7、 如果 Caller 答對問題，則將此 Caller 新增 至白名單並發送 Redirect（3xx）訊息至 SIP Proxy 接通此通話 其 SPIT Filter 流程如圖 6 所示：

圖 6 SPIT Filter Process

如果 Caller 是通訊錄名單上的人員，經過 SIP Filter 所花費的時間是非常少的，幾乎感覺不到有 SIP Filter 的動作，因為 SIP Filter 將比對白名單 （White List）及黑名單（Block List）的處理放在第 一個步驟，再加上比對黑名單及白名單這樣子的比 對的動作是最為快速、準確的比對方式，所以如果 Caller 是合法的使用者，就很快速的接通此通話， 以下是運用 SPITTrap 之通話運作流程，如圖 7 所示：

圖 7 通過 SPITTrap 流程圖

3.2 SPITTrap

SPITTrap 主要功能是經由 SIP Filter 過濾後收 集 SPIT 的資訊，再將這些資訊回傳至 SPIT Center， 當有 INVITE 的訊息要傳送至 SIP Proxy 之前都必須 經由 SIP Filter 進行過濾，會依照管理者在 SIP Filter 設定的門檻值進行判斷是否為 SPIT，SPITTrap 架構 如圖 8 所示，其主要元件是由 Rate Control、SIP Filter、SPIT Info 和 SIP Proxy 所組成：

‧ Rate Control：此元件主要進行網路流量 的監視，防止遭受到 DoS 的攻擊。 ‧ SIP Filter：此元件主要進行過濾非黑名單

及白名單的 INVITE 訊息，並將可疑發送 INVITE 的相關資訊儲存至 SPIT Info。 ‧ SPIT Info：儲存 SPIT 的資料庫，其儲存

欄 位 有 From (IP Address) 、 To (IP Address)、Time…等資訊。

‧ SIP Proxy：處理 User Agent 所發出的 INVITE 訊息，並且針對 INVITE 的內容 做正確的回應來建立連線。

圖 8 SPITTrap

SIP Filter 在過濾的過中程，所比對的黑名單 主要來自於與 SPIT Center 所提供的黑名單，儲存在 SPIT Info 資料庫中，SPIT Info 所儲存的黑名單除了 以 SPIT Center 所提供外，還可以自行新增所要過濾 的黑名單資訊，其架構說明為圖 9 所示：

圖 9 SIP Filter 比對黑名單流程

3.3 SPIT Center 之運作方式

SPIT Center 會藉由已註冊的 SPITTrap 所傳送 來的 SPIT Info 收集 SPIT 資訊，主要是將 SPIT 的 IP Address 等資訊回傳至 SPIT Center，IP Address 有可能會是 SPIT 的 IP Address 或者是 SPIT 所使用 的 Proxy 位址，為了防止有不法使用者想破壞 SPIT Center 的資料，所以在 SPITTrap 與 SPIT Center 之 間的網路必須是授權的方式來傳送 SPIT 資訊並建 立 一 個 安 全的 網 路 （ Chain of Response Trust； CRT）。

在這些 SPITTrap 中，SPIT Center 也會給予各 SPITTrap 之權重值（Weight），會因為 SPITTrap 的 不同權重值，來增加資料的可信度，SPIT Center 所

記錄的資料並不會一直留存著，只保留一星期的時 間，因為 SPIT 是即時的服務，所以主要能即時讓 SPIT 無了進行散播的服務。

3.4 SPIT Center 規則

SPIT Center 會基於以下幾點進行 SPIT 篩選： ‧ SPIT Center 會收集大量有可能為 SPIT 的 IP

Address 及權重值，再由管理者設定的門檻值去 篩選出可疑 SPIT 散播者的 IP Address。 ‧ 會依照 SPITTrap 回傳 Report 的時間去分別加以 權重值，以四十八小時為一個單位，最新與過 去的資料權重值為 4：1，資料保留時間為一週。 ‧ SPIT Center 並不會去管通話的內容，只針對 IP Address 去進行統計 ‧ 如果在一週內小於兩筆以下的 IP Address 的資 料，在十二小時內會自動刪除 ‧ 如果在二十四小時都還未被視為 SPIT，也會自 己刪除 以上針對 SPIT Center 所提出的一些篩選規 則，則會根據資料量及環境架構的不同，做適當的 調整。 其整體的階層式架構過濾垃圾語音如圖 10 所 示： 圖 10 階層式架構防禦垃圾語音

4. 結論及未來工作

雖然 VoIP 的 Spam（SPIT）問題，對目前的網 路安全還尚未有明顯的影響，但在未來 VoIP 逐漸 被廣泛使用的情況下，將來 SPIT 的威脅比電子郵 件信箱的垃圾嚴重許多，也勢必成為 VoIP 不當使 用者的廣告散播工具，因此在本論文中提出了一個 垃圾語音之防禦系統來有效降低 SPIT，在未來，我 們將會針對 SPIT Center 進行判斷 SPIT 的演算法進 行 改 良 ， 達 到 更 快 速 、 更 高 的 準 確 率 來 提 供 SPITTrap 有效的對 SPIT 進行抵擋的動作。

參考文獻

[1]. B. Yu et al, “A Social Mechanism of Reputation Management in Electronic Communities”, Proceedings of Fourth International Workshop on Cooperative Information Agents”, pp. 154-165, 2000.

[2]. Cao F. and Malik S., “Security Analysis and Solutions for Deploying IP Telephony in the Critical Infrastructure”, Proceedings of IEEE/Create-Net Workshop on Security and Quality of Service in Communication Networks, pp. 165 - 174, September 2005, Athens, Greece [3]. Cao, F, “Call Filtering and Tracking in IP

Telephony”, Proceeds of IASTED International Conference on Internet and Multimedia Systems and Applications,pp. 400-058, (IMSA 2003) [4]. Cao, F.; Jennings, “Providing response identity

and authentication in IP telephony”, Availability, Reliability and Security, pp. 198-205, 2006. ARES 2006. The First International Conference on

[5]. IETF, Rosenberg, J., et al, “RFC3261: SIP: Session Initiation Protocol”, June 2002.

[6]. Jennings, C. and J. Peterson, “Certificate Management Service for The Session Initiation Protocol (SIP)", draftietf-sipping-certs-01 (work

in progress), February 2005.

[7]. Larson, J. et. al., “Defending VoIP Networks from DdoS attacks”, Globecom 2004 VoIP Security Workshop, Houston, USA.

[8]. L. Xiong, L. Liu, “A Reputation-Based Trust Model for Peer-to-Peer eCommerce Communities”, Proc of the IEEE International Conference on E-commerce (CEC’03),pp. 275, 2003

[9]. Mark J. Handley, Henning Schulzrinne, Eve M. Schooler, Jonathan Rosenberg, “SIP: Session Initiation Protocol, Internet proposed standard RFC 2543”, March 1999.

[10]. NIST SP 800-58, “Security Considerations for Voice Over IP Systems”, pp. 800-58, 2005

[11]. Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity anagement in the Session

Initiation Protocol (SIP)”, draft–ietf–sip–identity-05 (work in progress),

May 2005.

[12]. Peterson, J., “Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format”, RFC 3893, September 2004.

[13]. Rebahi, Y.; Sisalem, D., “SIP Service Providers and the Spam Problem”, 2nd workshop on securing voice over IP, June 2005, Washington, USA

[14]. Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E.Schooler, “SIP: Session Initiation Protocol”, RFC 3261, June 2002.

[15]. “SpamCop”, http://www.spamcop.net/

[16]. Sparks, R., “Internet Media Type message/sipfrag”, RFC 3420, November 2002.