五大难题拷问IP电话安全_voip

五大难题拷问IP电话安全

2005/04/25

　　“可以随意拨打、窃听随时会发生、正常通话有可能被拒绝……”越来越多运营商和企业所青睐的IP电话，正为安全所困。但面对无法信任的防火墙，我们还能有什么样的选择？

　　由于基础设施成本及使用成本较低，越来越多的电信公司和客户开始尝试IP电话。日前，信息产业部综合规划司发布的1～2月份通信行业分析报告显示，在长途电话业务中，IP电话通话时长已经占长途电话通话时长的45.7%。

　　不过，在搭建IP电话网络时，安全是非常重要的问题。现今的应用层软件防火墙，由于厂商、用户、产品等方面受五大难题的制约，很难为网络管理员提供相应的安全性和可靠性方面的保障。

难题一：厂商重犯10多年前的错误

　　网络安全领域的斗争从来就没有停止过，只不过斗争的前沿时常从OSI协议栈的一层转移到另外一层而已。几年前网桥和路由器为安全问题所困扰的情况，现在同样发生在IP电话网络身上。

　　近期，许多刚成立不久的公司纷纷发表调查报告，报告声称，尽管目前特定于具体应用的防火墙越来越多，但它们检测到的应用层蠕虫和病毒的数量正在不断增加。与此同时，各防火墙厂商都在紧锣密鼓地研发更智能化并带深度包检测（Deep Packet Inspection，DPI）功能的安全设备。我们知道，DPI功能将使得网络管理员能够配置数字位匹配模式，用以匹配和鉴别特定的数据报。

　　然而，恐怕这些防火墙厂商正在犯着10多年前以太网网桥制造商就曾经犯过的错误。那时候，为了对抗路由器，网桥制造商引入了能按位模式来转发数据报的所谓智能网桥，他们宣称这些智能网桥融合了路由器的优点同时摈弃了路由器的缺点。也许他们说的没错，但事实是，配置这些智能网桥的门槛实在太高了，如果你没有博士级的智商，恐怕很难能有机会弄明白这些智能网桥的配置细节。

　　现在看来，DPI的实现似乎避免不了与这些智能网桥相同的命运。目前多数DPI引擎的缺省设置是不分青红皂白地把所有外部数据通通拒之门外，因此表面上看起来好像确实提供了强有力的安全防护，然而对管理员来说，真正的挑战在于如何配置这些引擎，使其具有识别数据的能力;如何可以让它过滤掉那些无用或带攻击性的数据，而只让真正有用的数据进来。对于很多防火墙管理员来说，这个任务显得很是艰巨。

　　即使对那些经验丰富的工程师来说，这也是非常大的挑战。Nokia的产品概念工程师Wayne Fiori在谈到DPI时直言“感觉不太好”。他说，“我们有一个内部应用需要用到防火墙，我最终把所谓的智能应用给彻底关了，它实在是碍手碍脚，它缺省地把所有的数据都给挡住了，这不是添乱嘛，那时候我简直要疯了。”

　　先把易用性放在一边。很难想象通用防火墙软件厂商能保证自己的软件能够实现各种纷繁的IP语音（Voice over IP，VoIP）标准和协议。即使是那些做专用防火墙的公司在处理各种标准、RFC、VoIP相关的重要草案时，也是相当头疼。所以，通用防火墙公司很难像那些专用防火墙公司一样，又快又省地及时支持新标准，更不用说那些标准的扩展了。

　　碰到这些情况时，网络管理员该如何抉择呢？对于通话量较低并且对IP电话要求比较简单的情况，升级通用防火墙加入DPI支持是个可行的方案；另一方面，对高通话量的情况，通常需要把VoIP数据转移到专用的防火墙上，只有一种情况例外，就是如果防火墙软件厂商和IP专用分组交换机（IP PBX）厂商在技术上有合作的话，可以做到让通用DPI防火墙更好地支持IP PBX的特殊功能，那么通用防火墙也有可能应付高通话量的要求。

　　另外，部署专用安全设备可能可以比较快地解决问题，提供所谓的“单项优势”（best-of-breed）安全防护。但这也意味着，你要管理和维护更多的专业设备，从长期来看会造成成本的增加。

　　如果网络管理员和防火墙厂商恰好是DPI追随者的话，应该说也还是很有盼头的。基本上，改进DPI防火墙软件人机交互功能的方式有两种：其一是通过内部开发改进完善；另一种则是通过收购那些刚起步的专用防火墙软件公司，并融合它们的技术优势。

问题二：用户投资难以应对安全现状

　　由于目前已知的IP电话攻击并不多见，所以想说服CEO们和预算管理人员在IP电话安全方面增加资金投入还是有一定难度的，网络管理员们应该会认同这一点。然而就在今年1月份，英国国家基础建设安全响应中心（NISCC）报导他们发现了目前被普遍认为是在分组网上支持语音、图像和数据业务最成熟的H.323协议的多个漏洞，而其中又以负责建立IP电话连接的H.225.0子协议里问题最多。如果漏洞遭到攻击，结果可能造成恶意代码的执行或是拒绝服务（DoS）攻击。

　　会话启动协议（Session Initiation Protocol，SIP）的情况也好不到哪里去。2003年2月，国家计算机网络应急技术处理协调中心（CERT）报导了SIP协议栈中的一个漏洞。利用该漏洞，攻击者将有机会获得非法访问特权，发起DoS攻击，造成系统不稳等问题。

　　从原理上说，利用漏洞可以发起各种类型的攻击。比如一旦网关被黑客攻破，IP电话不用经过认证就可随意拨打，未经保护的语音通话有可能遭到拦截和窃听，而且可以被随时截断。黑客利用重定向攻击可以把语音邮件地址替换成自己指定的特定IP地址，为自己打开秘密通道和后门，等等。

　　与此同时，其他流行的攻击手段也会对网络语音环境造成巨大的威胁，除了DoS和DDoS攻击外，如果PC中了特洛伊木马的话，窃听就随时可能发生。类似地，乱序语音数据报（比如媒体数据报在会话数据报之前被接收到）和过长的电话号码都可能为缓冲区溢出攻击打开方便之门，而VoIP滥用（类似垃圾邮件）则可以通过不停播打同一号码使该号码陷于瘫痪。

　　另一个复杂的问题是，如果在防火墙之上同时运行网络地址转换(NAT)服务的话，外呼请求可能就无法正常工作。虽然NAT能够转换语音数据报中IP层和传输层的源地址与端口号，但NAT并不理会语音数据报中其他更底层的源地址信息。所以，对VoIP来说这意味着主叫方的地址将是个内部地址，而被叫方在试图建立通话时则会被导向错误的源地址。

　　当涉及到外部呼叫者时，VoIP面临的安全挑战就愈加复杂了。典型的情况是，对于一个公司搭建的IP电话网络来说，防火墙只认可从该网络内部发起的会话请求。然而对IP电话来说，公司外部的人也可能需要打电话进来。对于内部用户来说，为他们安装VPN客户端是个暂时的解决方案。但长远来说这肯定不够，外部呼叫者可能是个陌生人，所以不可能为他们预装VPN客户端。

问题三：防火墙产品缺陷明显

　　为了对抗针对IP电话的攻击，防火墙必须要更智能、更高效地检验进来的数据报里与SIP相关的信息。对此，不同的防火墙厂商采取了不同的方案。但大体来看，各方案或多或少都存在一些问题（详见下表）。

　　对于具有全状态检测（stateful-inspection）功能的防火墙来说，它本身并不具有应付应用层攻击的防护能力，这种防火墙在传输层对数据进行检查，它首先跟踪从公司IP电话网络出去的会话连接，然后利用这些信息来决定哪些外部数据是安全的，可以进入公司网络。

　　基于代理的防火墙如TIS的Guantlet，具有在应用层对具体应用进行安全保护的能力。它的工作方式是首先检测从外部进来的会话连接，分析其所使用的协议，然后掐断该外部连接，最后从自己这方重新发起一个到对方的新连接。这种防火墙虽然能直接在应用层对不同的具体应用提供相应的保护，但它是以牺牲性能为条件的，并且需要对每个具体应用进行特别调整。

　　没有任何一款VoIP防火墙(包括全状态检测防火墙)是纯粹工作在网络层和传输层的，最起码它们也要利用应用层网关（ALG）在网络层、传输层和应用层查找地址信息并进行相应修改。ALG对终端设备来说是透明的，所以在处理SIP时，它们并不会向请求连接一方发送TRYING消息。

　　有些防火墙在处理SIP数据报时会利用DPI查看数据报更细节的信息，比如在应用层检查数据报是否符合标准格式，这样，这些基于DPI的防火墙就能防住某些缓冲区溢出攻击。实现该功能的厂商有Cisco、NetScreen和WatchGuard。

　　基于代理的防火墙位处主叫方和被叫方中间，截取两端的通话信号和媒体流，这些设备工作方式类似SIP代理服务器，只不过它们同时还能进行协议正确性校验和检查。边界会话控制器（Session Border Controllers，SBC）是一种被众多运营商用于连接VoIP服务和支持QoS的设备，它们也属于基于代理的防火墙这一类。很多制造SBC的厂商同时也为企业提供类似的防火墙产品。

问题四：应用层过于复杂

　　每种防火墙实现方案都面临着诸如应用层复杂性、性能、价格以及数据加密的问题。

　　显然，如果通话数据被加密的话，防火墙是没法对数据进行检查的。而基于代理的防火墙可能可以绕过这个问题，但同时又造成其他的安全隐患。因为此类防火墙位于通话两端的信号和媒体流之间，通话方会“认为”他们已经和对方建立了直接的安全对话，但实际上他们只是和防火墙建立了安全会话，因此基于代理的防火墙实际上有着潜在的不安全因素。

　　应用层的复杂性又是一个问题。有些基于代理的防火墙自诩其有强大的检查校验数据报SIP正确性的能力，但我们恐怕不能尽信其言。SIP是一个极端复杂的协议，涉及到60多个RFC和标准草案，仅仅是准确实现这些纷繁的特性和功能就足以把这些防火墙厂商压得喘不过气来。

　　SIP还具有极强的扩展性，许多厂商在此基础上进行了很多专有的扩展。如果没有这些厂商的支持的话，是几乎不可能对其功能和正确性进行检查的，所以在购买此类产品之前建议进行认真细致的试用和评估。

　　绝大多数防火墙厂商的产品只实现了一小部分SIP的RFC和标准草案，而且厂商对这类事实一般都秘而不宣。

　　然而SIP也仅仅只是众多IP电话协议中的一个而已。Nortel、Avaya和Cisco在连接电话终端和它们的IP PBX时都使用了其专有的基于H.323协议的变种协议。目前市场上有许多H.323协议的变种，媒体网关控制协议（MGCP和MEGACO）也不例外。为了进行企业电话客户端和这些IP PBX的安全防护，对防火墙来说，支持这些专有H.323变种协议就显得相当重要。

　　然而，仅仅只是能支持这些协议还远远不够，网络管理员还非常重视防火墙部署时的简易性。美国劳伦斯·利弗莫尔国家实验室安全应急主管Jon Diaz就说“我研究过DPI的实现，但问题是，要具有很多相关的专业知识才可能弄明白整个配置过程。”

问题五：性价比阻碍应用推广

　　现在来谈谈性能和价格问题。Check Point的Besser宣称说，实现DPI并不会对防火墙的性能造成太大的影响。我们知道，如果防火墙要对通话内容进行检查的话，那么整个过程必须要以非常快的速度进行，否则会对通话造成负面影响。IP语音与HTTP类型的连接不同，IP语音的信号量极大，如果DPI防火墙厂商拿不出什么绝招的话，那么在应用层对数据进行检查肯定会对防火墙性能造成极大的影响。

　　即使是Nokia的防火墙也很难同时支持2000个VoIP用户。Nokia的说法是: 在协调VoIP用户数和通过防火墙的会话数上他们还没有成熟的测试方案。

　　目前防火墙最大的问题可能是会对通话质量造成影响。“防火墙的存在会造成一些语音延迟和不稳定等问题。” 为加拿大政府安装VoIP系统的IT主管Michel Labelle说道，“防火墙并没有意识到传统的服务质量（QoS）问题，所以避免不了对通话质量造成影响。”

　　解决方案也有，但产品的价格就要高出许多。确切数字不好说，不过作为参考，Nokia的能同时支持200个网络通话的IP 1260安全平台价格为6万美元。

　　基于代理的防火墙由于不需要那么多的硬件支持，所以相对来说价格较低。比如Jasomi PeerPoint的企业版支持600个注册用户和100个同时通话的用户，起价为12000美元。

放弃防火墙？

　　由于目前没有任何一个防火墙方案能完美地解决VoIP安全问题，因此有些安全专家认为在应用层这个级别可能最好的处理办法就是完全放弃防火墙。RTFM安全咨询公司的主管兼传输层安全（TLS）工作小组副主席Eric Rescorla认为，防火墙并不如想象的那么好，“看看电子邮件应用中蠕虫是如何突破防火墙的吧。”

　　Dynamicsoft公司的CTO和SIP创建者之一Jonathan Rosenberg也赞同这种观点，他在一封电子邮件里写道“防火墙厂商必须要非常熟悉SIP和其他IP电话协议，这样才能保证它们产品的质量，而实际上它们做不到这一点，结果就是当一个新的应用或协议出现时，在部署它们的时候你不得不寻求厂商的帮助。这种情况完全体现不出网络的主要优点。”

　　Rosenberg建议采用一种新的模式，即防火墙不用理会SIP和其他应用层协议。他说，现在一些客户端技术如简单UDP穿越NAT协议（STUN）、交互式连通建立方式（ICE）、通过中继方式穿越NAT技术（TURN），它们使得防火墙不需要处理SIP就能让IP通话穿过防火墙。这些协议和技术为客户端获取NAT和防火墙所使用的外部传输层地址提供了途径。

　　Rosenberg相信那些开发基于SIP的应用的开发人员会比较倾向于支持该协议，而网络管理员就不一定了。过去的经验表明，安全问题从来都是很棘手的，开发人员并不总是愿意或者说并不总是有能力在开发的时候完全解决安全问题。而从CERT和NISCC发布的安全报告来看，我们也没什么理由期待SIP开发人员会与众不同。（译/春雷）

VoIP如何部署防火墙

　　尽管当今绝大多数公司的VoIP网络都是不对外开放的，但仍然有必要在企业内部部署VoIP防火墙。越来越多的攻击开始时是从VoIP网络内部发起，对此进行防卫是必不可少的。作为对策，第一步可以将所有网络语音数据隔离在虚拟局域网中，与此同时在可信任的域内部署代理和网闸同样很重要。

　　对于带DPI的全状态检测防火墙，部署过程是一个在不受信任的网络和受信任的企业之间的隔离带里的防火墙端口上安装SIP代理的过程。而实现了SIP背对背用户代理的防火墙则有所不同，因为它们的功能类似代理服务器，用户代理(User Agent)可以在上面注册。这类防火墙可以和全状态检测防火墙一起部署在隔离带中，只要使用不同的端口即可，或者单独部署在公司网络的其他地方。

　　除了技术实现细节之外，网络管理员也要留意协议问题。由于绝大多数IP PBX在和其他设备终端连接时使用了专有协议、SIP或H.323中继，所以在部署时很可能需要厂商的直接支持。

计算机世界网(www.ccw.com.cn)