SIP自动测试工具的设计实现

李大宇，马 跃，李鸿彬，李俊超，3

（1.中国科学院研究生院，北京100049；2.中国科学院 沈阳计算技术研究所，辽宁 沈阳110168；3.中国科学技术大学 计算机科学与技术学院，安徽 合肥230027）

0 引 言

会话初始协议 （session initiation protocol，SIP）是由IETF提出的基于应用层的多媒体会话控制协议，因其简单性和可扩展性而广泛应用于多媒体通信中［1］。SIP是基于文本的应用层控制协议，用于建立、修改或终止一方或多方多媒体会话［2］。SIP网络环境中使用了大量的中间设备，它们可以接收、发送SIP消息，并且重组收到的SIP消息。SIP规范对中间设备在构建SIP消息方面给予了很大的自由，因此导致SIP服务器在实际网络中可能收到很多非法的SIP消息，最终可能引起SIP服务器程序的崩溃。对测试工具的研究如文献 ［3］讲述的是对SIP多种漏洞的攻击工具，文献 ［4］是对SIP服务器性能进行测试的工具，但对SIP健壮性的测试工具研究比较少。而已有的健壮性测试方案，如文献 ［5］讲述的PROTOS每次只能进行一个测试案例，文献 ［6－7］都是自动产生畸形消息进行健壮性测试，可是这样导致工具实现相对繁琐、畸形消息种类覆盖不够全面且容易产生错误。因此本文提出的测试工具本身不产生SIP畸形消息，而是自动修改合法SIP消息为非法后输出给测试目标进行健壮性测试。

1 背 景

1.1 SIP

SIP事务包括客户端发送给服务器的一个请求和服务器给客户端的一个或多个响应。请求消息中的起始行由请求方法、方法名、请求URI和协议版本号组成。方法名标识请求类型，URI用于路由等，版本号是当SIP版本，如表1所示为SIP中的7个基本方法。SIP响应消息的起始行是一个状态行，包含协议版本号、状态码和原因短语。状态码从100－699分类，如表2所示。

表1 SIP基本方法

请求和响应中的头域很多是一样的，例如Via、From、To、Call－ID和Cseq等。

表2 响应分类

SIP协议中有4个组件：SIP用户代理、SIP注册服务器、SIP代理服务器和SIP重定向服务器［8］。

1.2 SIP解析器和畸形消息

SIP解析器是SIP协议栈的子模块用于处理输入流并重新构造SIP消息。接收消息中的头字段是由SIP解析器进行调整并构造SIP消息，然后发送给客户端或服务器端进行进一步处理。SIP解析器同时支持TCP和UDP两种传输方式［9］。SIP解析器一般只接收和处理遵守RFC3261中所规定的格式的消息。但攻击者或客户端的任何执行错误都可能发送畸形消息，例如DoS攻击、不稳定的操作与未被授权的接入等。这是由于SIP代理中的解析器不会丢弃而是转发这些畸形消息给其它代理服务器，因此当一个SIP服务器接收到大量的非预期SIP消息后就有可能产生较大的延迟甚至出现软件的崩溃。本文中对于SIP解析采取固定字段的解析方法，实现起来更加简便高效［10］。

1.3 相关测试工具

PROTOS采用黑盒测试方法对SIP服务器进行健壮性测试。该套件有4527个畸形SIP消息测试用例来检测SIP服务器的执行情况，但它仅覆盖了INVITE消息不能对表1中的其它消息进行测试。PROTOS套件每次只能测试一个案例，且必须等到前一个测试案例有结果后才能开始下一个测试。

SipBomber支持UDP和TCP两种传输方式，且支持自动和手动测试，用户可以运行定制的测试案例。它需要分析响应得到测试结果，优点是支持图形界面，缺点与PROTOS一样，每次只能测试一个案例。文献 ［11］对部分开源工具的优缺点进行了总结。

2 测试工具的设计

新工具发送大量并行的畸形消息对目标进行健壮性测试，引起服务器软件崩溃并找到原因。测试过程不需人工辅助，使用者无需了解相关知识。根据RFC3261规定的SIP消息格式，非法字段和字符可以有多种组合，要覆盖所有组合几乎是不可能通过手工完成的任务，例如PROTOS中只有INVITE消息的4527个用例。因此采用随机测试，将SIP消息看作字符数组，根据制定的规则和概率对SIP消息进行修改，尽可能的覆盖非法消息的组合。该工具设计采用黑盒测试和随机测试［12］方法，设计中的两个核心问题介绍如下：

2.1 引起服务器软件的崩溃

集合A是所有SIP消息的集合，分为B和C集合。B是合法SIP消息集合，C是非法SIP消息集合。测试工具可以覆盖几乎A中所有元素，用户决定A是如何划分为B和C的。D是与合法SIP消息相似的非法SIP消息集合，是SIP元素有某些缺陷而产生的非法消息，容易被SIP服务器当作合法SIP消息导致软件错误。集合间的关系如图1所示。

图1 集合韦恩

工具不产生B中的元素，只是修改与测试目标通信的SIP实体输出的消息，这样测试工具的输出就没有限制，并接近非法消息的各种组合，工具部署如图2所示。

图2 测试工具部署场景

UA发送B中的元素给测试工具，测试工具修改后的消息会自动发送给测试目标。消息的修改是随机的，修改后的消息是C的一个尽可能大的子集。消息的修改不是完全随机的，可以通过规则和概率的来控制。规则关注C的不同子集，概率决定要加强的规则，这样可以对C的子集有侧重点的测试。用户决定所使用的规则和概率，也可以加入新的规则来制定个性化的测试用例。

实际网络中SIP服务器会接收大量不同来源的非法输入导致服务器崩溃，因此测试工具应该可以发送大量的非法SIP消息来引发测试目标的软件崩溃。让几个SIP实体与测试目标通信并将它们的输出发送给测试工具，这样测试工具就好像有无限的输出且是在连续工作的。测试工具也可以对不同SIP实体的消息制定不同的修改规则，使不同的SIP实体侧重于不同的非法消息子集进行测试。

2.2 确定引起服务器软件崩溃的原因

已有的测试工具，例如PROTOS，确定引起服务器软件崩溃的原因并不难。因为测试案例每次只有一个，只要查看发送的消息就可以判定原因。这些工具都是在前一个测试结果出来后才进行下一个测试，而新测试工具是可以并行测试的，这也是新工具与其它工具的本质区别。但也正因为这样确定软件错误的原因才更困难，必须要找到引起错误的相关畸形SIP消息才能找到原因。

首先发送存储的非法SIP消息重现软件崩溃场景，接着确定相关非法SIP消息，最后找到决定性的修改，即那些导致服务器软件崩溃的修改，这样就锁定了软件崩溃的原因。如果不能重现软件崩溃工具会存储一个文件ID为“未解决”的文件并进行下一个测试。工具可以自动连续工作而不需人工辅助，状态转换如图3所示。

图3 寻找软件崩溃原因状态转换

重现软件崩溃前要查找存储的文件，若是已有原因就继续下一个测试。工具发送缓冲区中的SIP消息来重现软件崩溃。引起软件崩溃的SIP消息应该是最新存储的，因此通过启发式方法发送最小间隔的消息。如果没有重现场景就发送更大间隔的SIP消息。有两种可能性导致最终没有成功重现场景：缓冲区的容量限制导致相关消息被覆盖；服务器在软件崩溃时处于某个特殊的状态，场景重现时即便发送相同的消息但状态不符合也不会重现场景。因此覆盖缓冲区中消息时会通知用户，若最终没有成功重现场景，可以通过配置文件增大缓冲区容量重新测试。

接着要找到引起崩溃的相关SIP消息。使用折半查找找到起始元素，如图4所示。发送间隔 ［k，n－1］的消息，若软件发生崩溃则开始点在缓冲区尾部附近。第二个箭头间隔 ［m，n－1］的消息发送，但没有重现场景，所以开始点在k和m之间，接下来箭头3，4，5描述了开始点是如何被找到的。结束点的查找与起始点类似。

图4 起始点的查找

最后要找到决定性的修改，修改一般是添加头域或删除SIP消息中的某些字符，其特性导致经常使用一些固定组合。一个SIP消息的修改是在原有基础上进行的，所以工具不删除原始的修改。如下所示为确定决定性修改的算法伪代码， “Try this setup”代表发送一定间隔修改后的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 测试工具的实现

如图5所示，测试工具分为5个基本的功能模块，不同的模块间通过接口进行通信。

（1）控制模块：控制和管理工具的所有行为，其它模块接收控制模块的命令并向它报告。控制模块负责路由收到的消息。除了外部消息的路由，控制模块还负责内部SIP消息的路由。例如每个SIP实体发送过来的SIP消息都要经过工具的修改，并且每个SIP实体都和工具中修改模块的某个修改器绑定，控制模块负责将这些SIP消息路由到对应的修改器。

图5 测试工具的功能模块

（2）修改模块：将合法的输入修改为非法后输出给测试目标。修改模块中有预先制定的规则集和概率，不同的修改器可以制定不同的修改规则。修改规则由3个子规则组成的：删除、插入和替换。子规则用于实际SIP消息的修改，规则可以由用户配置，修改一个消息的流程如下：

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

2）对于每个规则：

a）是否应用规则，是到b），否则到2）；

b）是否用删除规则，是到c），否则到d）；

c）根据删除规则修改SIP消息；

d）是否用插入规则，是到e），否则到f）；

e）根据插入规则修改SIP消息modify；

f）是否用替换规则，是到g），否则到2）；

g）根据替换规则修改SIP消息；

3）完毕，将SIP消息返回给控制模块。

修改模块的另一个功能是还原SIP消息，用于确定引起软件崩溃的原因。

（3）存储模块：存储SIP消息在一个圆形队列中，用户通过配置文件设置队列大小。重现软件崩溃场景时，可以通过存储的事务ID发送整个相关的事务消息来缩小SIP消息范围。

（4）测试处理模块：监控测试目标，如果检测到服务器软件的崩溃就通知控制模块。运行一个单独的线程专门用于检测。检测到失败信息后先与存储的信息比对，若是已有的原因就发送信号和结论给控制模块。测试处理模块如何确定软件是否崩溃决定于测试目标的具体实现。

（5）传输模块：接收和发送SIP消息，支持UDP和TCP两种传输方式。对接收的SIP消息进行路由，采用多线程并行接收消息并将它们放入共享队列中。工具不改变原SIP消息的发送顺序，主线程采用FIFO的模式处理队列。接收对象从队列取出一个SIP消息到修改模块进行修改，将消息按其它模块要求的格式重组，必要时对消息流过滤。另一个作用是将从控制模块收到的SIP消息发送给对应的SIP实体。

测试工具有两种工作模式：尝试引起测试服务器软件崩溃；查找引起崩溃的原因。尝试引起服务器软件崩溃的典型场景如图6所示。

图6 引起服务器软件崩溃场景

测试处理模块检测到软件崩溃后会通知控制模块，工具转到查找原因模式。

4 实 验

在3种不同的环境中对工具进行测试，评价工具的功能。括号内是IP地址，箭头旁边的是端口号。

（1）测试一个模拟的SIP代理服务器

实验环境如图7所示，代理服务器不检查SIP消息内容只是起到路由的功能。两个UA配置经过测试工具路由，并且使用不同的修改规则。

图7 测试模拟SIP代理服务器

实验证明测试工具可以接收、路由和发送SIP消息，两个UA收到的消息都是由测试工具路由转发的。因为模拟的SIP代理服务器并不检查接收到SIP消息的内容所以不会发生崩溃。模拟崩溃时测试工具可以检测到软件崩溃并且通知控制模块改变工具的工作模式。模拟的SIP代理服务器使用日志文件，测试工具可以通过检测日志文件检测到软件的崩溃，该环境很好的测试了工具的功能。

（2）测试一个SIP UA服务器

如图8所示UA B是测试目标。实验证明该工具可以修改从UA A收到的SIP消息并发送给UA B。本实验是为了验证测试工具可以对SIP UA进行测试。

（3）测试SIP代理服务器

如图9所示，SIP服务器为测试目标。测试工具在SIP服务器看来是一个UA，因为所有的消息都是工具发送的。由于UA A和UA B不能自动产生足够负荷的SIP消息，因此不能导致SIP服务器崩溃。通过模拟SIP服务器的软件崩溃，测试工具成功的发现并且重现了相关的SIP消息。

图8 UA B为测试目标

图9 对SIP服务器进行测试

实验证明测试工具能够很好的接收、路由和发送SIP消息，能够将合法的输入消息流修改为非法后输出来对任意SIP服务器进行测试。如果测试目标发生了软件崩溃，测试工具能够检测到并且找到引起崩溃的相关消息给出原因。

5 结束语

SIP协议因其简单、易于扩展、便于实现等优点已受到越来越多的青睐，随着SIP产品越来越流行，SIP服务器在互联网中会经受大量非法输入消息流的考验，因此SIP服务器的健壮性备受关注。

本文提出了一种新的健壮性测试工具，该工具能够将合法的输入流修改后变为非法消息流输出给测试目标，用来检测服务器的健壮性。工具采用黑盒测试方法，使用者不需要了解服务器内部结构就可以对各种不同类型的SIP产品进行健壮性测试。一旦成功的引发了SIP服务端软件崩溃，测试工具会检测到并且可以快速的给出原因。该工具对于手动测试来说是一个很好的补充。测试工具性能将在下一步进行研究。

［1］LONG Zhao－hua，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－hui.Research on security in SIP－based network ［J］.Computer Engineering and Design，2004，25 （3）：386－389 （in Chinese）.［闵涵，陈莘萌，张琦辉.基于SIP协议的网络安全性分析 ［J］.计算机工程与设计，2004，25 （3）：386－389.］

［3］LI Hong－bin，LEI Wei－min，YANG Xue－hua.Securtiy testing tool in SIP－based VoIP system ［J］.Journal of Chinese Computer Systems，2010，31 （10）：2017－2023 （in Chinese）.［李鸿彬，雷为民，杨雪华.基于SIP的VoIP安全测试工具的研究 ［J］.小型微型计算机系统，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协议测试方法和测试工具的研究 ［J］.小型微型计算机系统，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协议软件测试方法研 究 ［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－hui.Improvement of SIP header parsing via static search table ［J］.Computer Engineering and Design，2010，31 （13）：2988－2995 （in Chinese）.［姜秀玉，杨峰，崔再惠.SIP协议实现中消息解析的研 究 ［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.