李大宇，馬 躍，李鴻彬，李俊超，3

（1.中國科學院研究生院，北京100049；2.中國科學院 沈陽計算技術(shù)研究所，遼寧 沈陽110168；3.中國科學技術(shù)大學 計算機科學與技術(shù)學院，安徽 合肥230027）

0 引 言

會話初始協(xié)議 （session initiation protocol，SIP）是由IETF提出的基于應用層的多媒體會話控制協(xié)議，因其簡單性和可擴展性而廣泛應用于多媒體通信中［1］。SIP是基于文本的應用層控制協(xié)議，用于建立、修改或終止一方或多方多媒體會話［2］。SIP網(wǎng)絡環(huán)境中使用了大量的中間設備，它們可以接收、發(fā)送SIP消息，并且重組收到的SIP消息。SIP規(guī)范對中間設備在構(gòu)建SIP消息方面給予了很大的自由，因此導致SIP服務器在實際網(wǎng)絡中可能收到很多非法的SIP消息，最終可能引起SIP服務器程序的崩潰。對測試工具的研究如文獻 ［3］講述的是對SIP多種漏洞的攻擊工具，文獻 ［4］是對SIP服務器性能進行測試的工具，但對SIP健壯性的測試工具研究比較少。而已有的健壯性測試方案，如文獻 ［5］講述的PROTOS每次只能進行一個測試案例，文獻 ［6－7］都是自動產(chǎn)生畸形消息進行健壯性測試，可是這樣導致工具實現(xiàn)相對繁瑣、畸形消息種類覆蓋不夠全面且容易產(chǎn)生錯誤。因此本文提出的測試工具本身不產(chǎn)生SIP畸形消息，而是自動修改合法SIP消息為非法后輸出給測試目標進行健壯性測試。

1 背 景

1.1 SIP

SIP事務包括客戶端發(fā)送給服務器的一個請求和服務器給客戶端的一個或多個響應。請求消息中的起始行由請求方法、方法名、請求URI和協(xié)議版本號組成。方法名標識請求類型，URI用于路由等，版本號是當SIP版本，如表1所示為SIP中的7個基本方法。SIP響應消息的起始行是一個狀態(tài)行，包含協(xié)議版本號、狀態(tài)碼和原因短語。狀態(tài)碼從100－699分類，如表2所示。

表1 SIP基本方法

請求和響應中的頭域很多是一樣的，例如Via、From、To、Call－ID和Cseq等。

表2 響應分類

SIP協(xié)議中有4個組件：SIP用戶代理、SIP注冊服務器、SIP代理服務器和SIP重定向服務器［8］。

1.2 SIP解析器和畸形消息

SIP解析器是SIP協(xié)議棧的子模塊用于處理輸入流并重新構(gòu)造SIP消息。接收消息中的頭字段是由SIP解析器進行調(diào)整并構(gòu)造SIP消息，然后發(fā)送給客戶端或服務器端進行進一步處理。SIP解析器同時支持TCP和UDP兩種傳輸方式［9］。SIP解析器一般只接收和處理遵守RFC3261中所規(guī)定的格式的消息。但攻擊者或客戶端的任何執(zhí)行錯誤都可能發(fā)送畸形消息，例如DoS攻擊、不穩(wěn)定的操作與未被授權(quán)的接入等。這是由于SIP代理中的解析器不會丟棄而是轉(zhuǎn)發(fā)這些畸形消息給其它代理服務器，因此當一個SIP服務器接收到大量的非預期SIP消息后就有可能產(chǎn)生較大的延遲甚至出現(xiàn)軟件的崩潰。本文中對于SIP解析采取固定字段的解析方法，實現(xiàn)起來更加簡便高效［10］。

1.3 相關(guān)測試工具

PROTOS采用黑盒測試方法對SIP服務器進行健壯性測試。該套件有4527個畸形SIP消息測試用例來檢測SIP服務器的執(zhí)行情況，但它僅覆蓋了INVITE消息不能對表1中的其它消息進行測試。PROTOS套件每次只能測試一個案例，且必須等到前一個測試案例有結(jié)果后才能開始下一個測試。

SipBomber支持UDP和TCP兩種傳輸方式，且支持自動和手動測試，用戶可以運行定制的測試案例。它需要分析響應得到測試結(jié)果，優(yōu)點是支持圖形界面，缺點與PROTOS一樣，每次只能測試一個案例。文獻 ［11］對部分開源工具的優(yōu)缺點進行了總結(jié)。

2 測試工具的設計

新工具發(fā)送大量并行的畸形消息對目標進行健壯性測試，引起服務器軟件崩潰并找到原因。測試過程不需人工輔助，使用者無需了解相關(guān)知識。根據(jù)RFC3261規(guī)定的SIP消息格式，非法字段和字符可以有多種組合，要覆蓋所有組合幾乎是不可能通過手工完成的任務，例如PROTOS中只有INVITE消息的4527個用例。因此采用隨機測試，將SIP消息看作字符數(shù)組，根據(jù)制定的規(guī)則和概率對SIP消息進行修改，盡可能的覆蓋非法消息的組合。該工具設計采用黑盒測試和隨機測試［12］方法，設計中的兩個核心問題介紹如下：

2.1 引起服務器軟件的崩潰

集合A是所有SIP消息的集合，分為B和C集合。B是合法SIP消息集合，C是非法SIP消息集合。測試工具可以覆蓋幾乎A中所有元素，用戶決定A是如何劃分為B和C的。D是與合法SIP消息相似的非法SIP消息集合，是SIP元素有某些缺陷而產(chǎn)生的非法消息，容易被SIP服務器當作合法SIP消息導致軟件錯誤。集合間的關(guān)系如圖1所示。

圖1 集合韋恩

工具不產(chǎn)生B中的元素，只是修改與測試目標通信的SIP實體輸出的消息，這樣測試工具的輸出就沒有限制，并接近非法消息的各種組合，工具部署如圖2所示。

圖2 測試工具部署場景

UA發(fā)送B中的元素給測試工具，測試工具修改后的消息會自動發(fā)送給測試目標。消息的修改是隨機的，修改后的消息是C的一個盡可能大的子集。消息的修改不是完全隨機的，可以通過規(guī)則和概率的來控制。規(guī)則關(guān)注C的不同子集，概率決定要加強的規(guī)則，這樣可以對C的子集有側(cè)重點的測試。用戶決定所使用的規(guī)則和概率，也可以加入新的規(guī)則來制定個性化的測試用例。

實際網(wǎng)絡中SIP服務器會接收大量不同來源的非法輸入導致服務器崩潰，因此測試工具應該可以發(fā)送大量的非法SIP消息來引發(fā)測試目標的軟件崩潰。讓幾個SIP實體與測試目標通信并將它們的輸出發(fā)送給測試工具，這樣測試工具就好像有無限的輸出且是在連續(xù)工作的。測試工具也可以對不同SIP實體的消息制定不同的修改規(guī)則，使不同的SIP實體側(cè)重于不同的非法消息子集進行測試。

2.2 確定引起服務器軟件崩潰的原因

已有的測試工具，例如PROTOS，確定引起服務器軟件崩潰的原因并不難。因為測試案例每次只有一個，只要查看發(fā)送的消息就可以判定原因。這些工具都是在前一個測試結(jié)果出來后才進行下一個測試，而新測試工具是可以并行測試的，這也是新工具與其它工具的本質(zhì)區(qū)別。但也正因為這樣確定軟件錯誤的原因才更困難，必須要找到引起錯誤的相關(guān)畸形SIP消息才能找到原因。

首先發(fā)送存儲的非法SIP消息重現(xiàn)軟件崩潰場景，接著確定相關(guān)非法SIP消息，最后找到?jīng)Q定性的修改，即那些導致服務器軟件崩潰的修改，這樣就鎖定了軟件崩潰的原因。如果不能重現(xiàn)軟件崩潰工具會存儲一個文件ID為“未解決”的文件并進行下一個測試。工具可以自動連續(xù)工作而不需人工輔助，狀態(tài)轉(zhuǎn)換如圖3所示。

圖3 尋找軟件崩潰原因狀態(tài)轉(zhuǎn)換

重現(xiàn)軟件崩潰前要查找存儲的文件，若是已有原因就繼續(xù)下一個測試。工具發(fā)送緩沖區(qū)中的SIP消息來重現(xiàn)軟件崩潰。引起軟件崩潰的SIP消息應該是最新存儲的，因此通過啟發(fā)式方法發(fā)送最小間隔的消息。如果沒有重現(xiàn)場景就發(fā)送更大間隔的SIP消息。有兩種可能性導致最終沒有成功重現(xiàn)場景：緩沖區(qū)的容量限制導致相關(guān)消息被覆蓋；服務器在軟件崩潰時處于某個特殊的狀態(tài)，場景重現(xiàn)時即便發(fā)送相同的消息但狀態(tài)不符合也不會重現(xiàn)場景。因此覆蓋緩沖區(qū)中消息時會通知用戶，若最終沒有成功重現(xiàn)場景，可以通過配置文件增大緩沖區(qū)容量重新測試。

接著要找到引起崩潰的相關(guān)SIP消息。使用折半查找找到起始元素，如圖4所示。發(fā)送間隔 ［k，n－1］的消息，若軟件發(fā)生崩潰則開始點在緩沖區(qū)尾部附近。第二個箭頭間隔 ［m，n－1］的消息發(fā)送，但沒有重現(xiàn)場景，所以開始點在k和m之間，接下來箭頭3，4，5描述了開始點是如何被找到的。結(jié)束點的查找與起始點類似。

圖4 起始點的查找

最后要找到?jīng)Q定性的修改，修改一般是添加頭域或刪除SIP消息中的某些字符，其特性導致經(jīng)常使用一些固定組合。一個SIP消息的修改是在原有基礎上進行的，所以工具不刪除原始的修改。如下所示為確定決定性修改的算法偽代碼， “Try this setup”代表發(fā)送一定間隔修改后的SIP消息。

Input：a SIP message with the modifications 1to n

Output：the SIP message with the minimal number of interesting modifications

Remove all modifications in the SIP message；

Try this setup；

If the software failure occurs then

the number of modifications in this SIP message has been minimized；

exit；

else

foreach modification i＝1to n do

add modification I to the SIP message；

try this setup；

if the software failure occures then

the number of modifications in this SIP message has been minimized；

exit；

end

end

3 測試工具的實現(xiàn)

如圖5所示，測試工具分為5個基本的功能模塊，不同的模塊間通過接口進行通信。

（1）控制模塊：控制和管理工具的所有行為，其它模塊接收控制模塊的命令并向它報告?？刂颇K負責路由收到的消息。除了外部消息的路由，控制模塊還負責內(nèi)部SIP消息的路由。例如每個SIP實體發(fā)送過來的SIP消息都要經(jīng)過工具的修改，并且每個SIP實體都和工具中修改模塊的某個修改器綁定，控制模塊負責將這些SIP消息路由到對應的修改器。

圖5 測試工具的功能模塊

（2）修改模塊：將合法的輸入修改為非法后輸出給測試目標。修改模塊中有預先制定的規(guī)則集和概率，不同的修改器可以制定不同的修改規(guī)則。修改規(guī)則由3個子規(guī)則組成的：刪除、插入和替換。子規(guī)則用于實際SIP消息的修改，規(guī)則可以由用戶配置，修改一個消息的流程如下：

1）是否所有的SIP消息都要被修改，如果是就到2），否則到3）；

2）對于每個規(guī)則：

a）是否應用規(guī)則，是到b），否則到2）；

b）是否用刪除規(guī)則，是到c），否則到d）；

c）根據(jù)刪除規(guī)則修改SIP消息；

d）是否用插入規(guī)則，是到e），否則到f）；

e）根據(jù)插入規(guī)則修改SIP消息modify；

f）是否用替換規(guī)則，是到g），否則到2）；

g）根據(jù)替換規(guī)則修改SIP消息；

3）完畢，將SIP消息返回給控制模塊。

修改模塊的另一個功能是還原SIP消息，用于確定引起軟件崩潰的原因。

（3）存儲模塊：存儲SIP消息在一個圓形隊列中，用戶通過配置文件設置隊列大小。重現(xiàn)軟件崩潰場景時，可以通過存儲的事務ID發(fā)送整個相關(guān)的事務消息來縮小SIP消息范圍。

（4）測試處理模塊：監(jiān)控測試目標，如果檢測到服務器軟件的崩潰就通知控制模塊。運行一個單獨的線程專門用于檢測。檢測到失敗信息后先與存儲的信息比對，若是已有的原因就發(fā)送信號和結(jié)論給控制模塊。測試處理模塊如何確定軟件是否崩潰決定于測試目標的具體實現(xiàn)。

（5）傳輸模塊：接收和發(fā)送SIP消息，支持UDP和TCP兩種傳輸方式。對接收的SIP消息進行路由，采用多線程并行接收消息并將它們放入共享隊列中。工具不改變原SIP消息的發(fā)送順序，主線程采用FIFO的模式處理隊列。接收對象從隊列取出一個SIP消息到修改模塊進行修改，將消息按其它模塊要求的格式重組，必要時對消息流過濾。另一個作用是將從控制模塊收到的SIP消息發(fā)送給對應的SIP實體。

測試工具有兩種工作模式：嘗試引起測試服務器軟件崩潰；查找引起崩潰的原因。嘗試引起服務器軟件崩潰的典型場景如圖6所示。

圖6 引起服務器軟件崩潰場景

測試處理模塊檢測到軟件崩潰后會通知控制模塊，工具轉(zhuǎn)到查找原因模式。

4 實 驗

在3種不同的環(huán)境中對工具進行測試，評價工具的功能。括號內(nèi)是IP地址，箭頭旁邊的是端口號。

（1）測試一個模擬的SIP代理服務器

實驗環(huán)境如圖7所示，代理服務器不檢查SIP消息內(nèi)容只是起到路由的功能。兩個UA配置經(jīng)過測試工具路由，并且使用不同的修改規(guī)則。

圖7 測試模擬SIP代理服務器

實驗證明測試工具可以接收、路由和發(fā)送SIP消息，兩個UA收到的消息都是由測試工具路由轉(zhuǎn)發(fā)的。因為模擬的SIP代理服務器并不檢查接收到SIP消息的內(nèi)容所以不會發(fā)生崩潰。模擬崩潰時測試工具可以檢測到軟件崩潰并且通知控制模塊改變工具的工作模式。模擬的SIP代理服務器使用日志文件，測試工具可以通過檢測日志文件檢測到軟件的崩潰，該環(huán)境很好的測試了工具的功能。

（2）測試一個SIP UA服務器

如圖8所示UA B是測試目標。實驗證明該工具可以修改從UA A收到的SIP消息并發(fā)送給UA B。本實驗是為了驗證測試工具可以對SIP UA進行測試。

（3）測試SIP代理服務器

如圖9所示，SIP服務器為測試目標。測試工具在SIP服務器看來是一個UA，因為所有的消息都是工具發(fā)送的。由于UA A和UA B不能自動產(chǎn)生足夠負荷的SIP消息，因此不能導致SIP服務器崩潰。通過模擬SIP服務器的軟件崩潰，測試工具成功的發(fā)現(xiàn)并且重現(xiàn)了相關(guān)的SIP消息。

圖8 UA B為測試目標

圖9 對SIP服務器進行測試

實驗證明測試工具能夠很好的接收、路由和發(fā)送SIP消息，能夠?qū)⒑戏ǖ妮斎胂⒘餍薷臑榉欠ê筝敵鰜韺θ我釹IP服務器進行測試。如果測試目標發(fā)生了軟件崩潰，測試工具能夠檢測到并且找到引起崩潰的相關(guān)消息給出原因。

5 結(jié)束語

SIP協(xié)議因其簡單、易于擴展、便于實現(xiàn)等優(yōu)點已受到越來越多的青睞，隨著SIP產(chǎn)品越來越流行，SIP服務器在互聯(lián)網(wǎng)中會經(jīng)受大量非法輸入消息流的考驗，因此SIP服務器的健壯性備受關(guān)注。

本文提出了一種新的健壯性測試工具，該工具能夠?qū)⒑戏ǖ妮斎肓餍薷暮笞優(yōu)榉欠ㄏ⒘鬏敵鼋o測試目標，用來檢測服務器的健壯性。工具采用黑盒測試方法，使用者不需要了解服務器內(nèi)部結(jié)構(gòu)就可以對各種不同類型的SIP產(chǎn)品進行健壯性測試。一旦成功的引發(fā)了SIP服務端軟件崩潰，測試工具會檢測到并且可以快速的給出原因。該工具對于手動測試來說是一個很好的補充。測試工具性能將在下一步進行研究。

［1］LONG Zhao－h(huán)ua，LI Ming－zhe.Design of SIP security mechanism on application－layer ［J］.Computer Engineering and Design，2010，31 （15）：3350－3370 （in Chinese）.［龍昭華，李明哲.基于應用層的SIP安全機制設計 ［J］.計算機工程與設計，2010，31 （15）：3350－3370.］

［2］MIN Han，CHEN Shen－meng，ZHANG Qi－h(huán)ui.Research on security in SIP－based network ［J］.Computer Engineering and Design，2004，25 （3）：386－389 （in Chinese）.［閔涵，陳莘萌，張琦輝.基于SIP協(xié)議的網(wǎng)絡安全性分析 ［J］.計算機工程與設計，2004，25 （3）：386－389.］

［3］LI Hong－bin，LEI Wei－min，YANG Xue－h(huán)ua.Securtiy testing tool in SIP－based VoIP system ［J］.Journal of Chinese Computer Systems，2010，31 （10）：2017－2023 （in Chinese）.［李鴻彬，雷為民，楊雪華.基于SIP的VoIP安全測試工具的研究 ［J］.小型微型計算機系統(tǒng)，2010，31 （10）：2017－2023.］

［4］LIN Hu，WANG Yang，LEI Wei－min.Research on SIP protocol testing and testing tools ［J］.Journal of Chinese Computer Systems，2008，29 （3）：406－410 （in Chinese）.［林滸，王陽，雷為民，等.SIP協(xié)議測試方法和測試工具的研究 ［J］.小型微型計算機系統(tǒng)，2008，29 （3）：406－410.］

［5］Wieser C，Laakso M，Schulzrinne H.SIP robustness testing for large－scale use ［C］.Erfurt，Germany：1st Int Workshop on Software Quality，2004.

［6］XU Luo，WU Ji，LIU Chao.TTCN－3based robustness test generation and automation ［C］.Kiev，Ukraine：Informaion Technology and Computer Science，2009：120－125.

［7］XIANG Yang，WANG Zhi－liang，Yin Xia.SIP robustness testing based on TTCN－3 ［C］.Bradford，United Kingdom：Advanced Information Networking and Applications Workshops，2009：122－128.

［8］ZHAO Hui－qun，ZHAO Jie，SUN Jing.Study on method of SIP software testing based on TTCN－3 ［J］.Computer Engineering and Design，2009，30 （23）：5424－5427 （in Chinese）.［趙會群，趙潔，孫晶.基于TTCN－3的SIP協(xié)議軟件測試方法研 究 ［J］.計算機工程與設計，2009，30 （23）：5424－5427.］

［9］DU Shi－xing，CHEN Hong－chang，YU Hong－tao.Attack and defence aiming at sip parser ［J］.Computer Engineering，2008，34 （23）：106－163 （in Chinese）.［杜世星，陳鴻昶，于洪濤.針對SIP解析器的攻擊與防范 ［J］.計算機工程，2008，34 （23）：106－163.］

［10］JIANG Xiu－yu，YANG Feng，CUI Zai－h(huán)ui.Improvement of SIP header parsing via static search table ［J］.Computer Engineering and Design，2010，31 （13）：2988－2995 （in Chinese）.［姜秀玉，楊峰，崔再惠.SIP協(xié)議實現(xiàn)中消息解析的研 究 ［J］.計算機工程與設計，2010，31 （13）：2988－2995.］

［11］McGann S，Sicker D C.An analysis of security threats and tools in SIP－based VoIP systems ［C］.Second VoIP Security Workshop，2005.

［12］Wieser C，Laakso M，Schulzrinne H.Security testing of SIP implementations［R］.NY：Technical Report CUCS－024－03，2005.