SIP通信网络技术概论-关于SIP/RTP呼叫语音加密技术架构讨论

2022-04-12 Asterisk

今天，VoIP网络或者基于SIP架构的网络随着部署环境复杂程度的不断加强，基于IP的企业通信网络环境也更加灵活，以及SIP终端用户的普及，网络攻击等安全问题越来越严重。在针对SIP网络的安全问题上，目前存在各种针对SIP网络安全部署机制的措施，比如使用SBC来处理相对比较复杂的环境，或者针对单点服务器端使用信令加密或者RTP加密来保证其呼叫和语音的安全。关于SBC的安全机制以及商业场景，笔者在很多历史文档中有非常深入的讨论，读者可以查阅历史文档学习和了解各种应用场景。

今天，为了确保SIP协议及新IP企业通信网络技术概论这个系列分享的完整性，笔者计划和读者分享关于笔者针对SIP端的信令和语音加密以及SIPS使用，TLS，SRTP等问题进行一个全面的讨论。在本次分享中，笔者将要讨论的核心要点包括：authentication（签权）和authorization（授权），安全证书处理机制讨论，关于SIP、RTP加密的相关技术讨论，SIP trunk加密，安全攻击和响应处理机制，测试工具使用等几个主要的章节，希望通过这些环节的讨论为读者提供一个全面的关于新IP企业通信中的关于SIP和RTP加密的完整详解。我们首先从安全机制的基本问题谈起-签权和授权的背景介绍。

关于签权（authentication）和授权（authorization）的背景介绍

如果我们提到安全证书，我们首先应该了解两个关于安全认证的基本问题（authentication和authorization）。下面，笔者针对这两个基本的问题进行讨论。

此图例以及以下图例均来自于互联网资源

这两个基本问题其中一个就是认证签权（authentication）。另外一个就是授权的问题（authorization）。简单来说，authentication 是负责处理身份认定的问题，比如登录系统确认身份等问题。authorization 是一个授权问题，简言之，就是系统允许用户登录以后允许干什么的问题。

在SIP网络中，我们仍然使用同样的机制来管理用户注册，管理呼叫和其他的业务功能。现在我们以SIP 呼叫或者INVITE举例来说明其认证的流程。以下示例中使用了SIP代理和用户验证服务器，在实际应用环境中，代理服务器可能是一个SIP 服务器端或者IPPBX支持本身自己的数据库来存储用户验证信息。

在以上图例中，整个认证过程经过了以下八个核心步骤：

UA james 首先对proxy 服务器发出INVITE请求表示需要呼叫，验证身份。
Proxy 服务器第一次回复407 Proxy Auth Required，表示UA需要发送认证信息，并且对此UA发送nonce（number once）消息。这个nonce消息会保存到Proxy中。
UA 收到了nonce 消息以后，获悉服务器需要重新发送INVITE，并且需要携带hash重新认证。因此，UA结合密码和nonce进行加密运算（MD5）。
UA 通过MD5运算，最后获得hash。
然后reINVITE 消息，告诉abc.com Proxy， UA携带了计算后的hash。
Proxy服务器通过以前保存的nonce，结合设置的密码进行计算
如果Proxy计算出的hash和UA发送到hash是完全一样的，则表示密码匹配成功。
Proxy服务器接受了这个reINVITE，最后对其UA发送200 OK，确认了用户身份。

以上过程中，双方密码都没有以明文的形式公开进行传输，SIP安全得到了保证。关于MD5在SIP中的运算，我以前在文章中有所介绍。这里，笔者不做过多解释。关于nonce的算法参考rfc2617. 如果读者对MD5HA1有兴趣的话，也可以参考开源的工具来验证这些MD5HA1的验证结果。另外，hash的算法是一个比较复杂的技术范围，用户可以参考很多专业的文档研究其使用方式。目前，大量的数据证明，128 bits的MD5存在很多的缺陷，现在SHA-1相对比较安全，支持了160bits，但是SHA-1 仍然有一些安全问题，所以比较完整的是SHA-2（支持512bits），和最新的SHA-3。更多关于SIP认证技术架构的规范，读者可以参考最新的RFC8760来学习。

一些开源的用户也发布了比较多的开源的关于SIPdigestcalculator 计算的工具，读者可以尝试测试，使用情况参考链接。

SIPdigestcalculator.exe -u username -r realm -p password -n nonce -cn client nonce -nc nonce count -uri SIP URI

笔者介绍了关于呼叫的认证的示例，如果需要关于SIP注册的示例的话，用户可以访问参考链接获得更多关于SIP注册中签权的处理流程。

另外，我们在一些工作场景中，经常会看到不同环境中，有时用户端收到的是401或者407响应消息。401 Unauthorized 一般是通过注册服务器进行注册流程处理。

407 错误响应码是代理服务器的协议消息。

407 Proxy authentication required则一般都是Proxy回复的客户消息, 它和401非常相似，但是它需要UA首先对Proxy认证。401 头中包含的是WWW-Authenticate，而407 则包含的proxy_authentication。

authorization或者授权是一个相对比较简单的概念，授权是通过签权以后，用户可以访问的一些服务功能。在一般的呼叫业务场景中，用户可以通过数据库的授权设置，允许SIP终端根据不同的授权级别支持各种不同的业务功能，例如某些用户仅支持语音呼叫，某些用户可以支持语音和视频呼叫；某些用户可以支持多种语音编码，某些用户仅支持一种语音编码；某些用户可以支持语音邮箱，盲转，某些用户则不支持这些功能。这些设置权限都可以作为授权的设置。

在以上讨论中，笔者简单介绍了关于签权和授权的区别，结合签权和授权在SIP的具体应用中的示例说明了签权的流程以及授权的应用场景。在下一个章节笔者将真正进入到关于SIP加密的技术的讨论。

关于SIP加密（Encryption）的相关技术讨论

目前大部分的SIP网络的通信交互都是通过互联网进行的。如果SIP交互通过互联网传输的话，SIP信令和RTP语音流存在很多的安全隐患。这些安全问题已经在互联网环境中存在了很多年。用户确实需要通过安全机制对系统进行非常严格的安全保障。以下是目前SIP网络中和IMS网络所面对的安全威胁：

各种SIP网络的安全威胁

以上这些问题都涉及了如何设置SIP安全策略的问题。所以，用户为了尽可能减少这些安全问题，只能通过对SIP加密和语音加密来增加通信的安全或者其他机制来降低安全风险。另外，在IMS网络环境中，同样存在着这些风险：

IMS 网络安全威胁

因此，我们需要一套安全加密机制针对SIP信令和RTP流进行安全设置来保护SIP网络的安全。加密（Encryption）技术是一个非常庞杂的技术，本人对此技细节没有更多深入了解，我仅从两个基本的主流概念中为大家介绍一下关于加密技术的轮廓。加密或者Encryption支持两种基本的形式的加密类型，一种是symmetric（对称加密）方式，另外一种则是asymmetric（非对称）加密方式。它们两者之间有非常明显的不同。

对称加密是一种比较老的加密方式，主要是双方通过共享秘钥方式来进行加密和解密处理，其秘钥可以支持不同的长度，最长可以支持到2048 bits，几种常见的算法包括DES，3DES，RC4和AES。它可以应用在实时语音视频传输，可满足加密解密快速处理的要求。但是，其存在的问题也是比较明显的，密钥交互双方需要完全获悉对端可以支持密钥共享。如果在非常广泛的部署环境中，SIP网络中的各种终端就很难保证其良好的兼容性和安全性，特别是针对TLS-1.3 方面的支持缺乏很好的兼容性。asymmetric（非对称加密）则具备了比对称加密更安全的密钥算法。非对称加密使用了public key（公钥）和private key（私钥）的方式进行加密处理。非对称加密仅使用了public key公开和对端交互，所以安全性得到了很大提升。但是其算法相对比较复杂，当然其处理速度也相对比较慢，比较有名的算法包括Diffie–Hellman（D-H）和RSA。

在部署使用加密方式时，除了安全因素以外，我们同样还要考虑部署成本。我们知道，这个世界上没有存在绝对的事情。绝对安全需要付出极大的部署成本，不同的加密算法需要耗费不同的系统资源。笔者列出一个简单的示例说明关于不同加密机制导致的不同的资源要求。Charles Shen在其发表的论文中针对TLS加密方式对系统的性能影响有一个比较完整的研究，读者可以参考其论文来针对加密处理对系统影响做进一步研究。

关于SIP证书（CA）的处理流程

为了实现TLS处理流程，我们需要一个数字证书。用户可以购买或者免费使用数字证书实现TLS的安全处理。通常情况下，用户需要从第三方数字证书发放厂家(Certification authority-CA)购买或者申请一个数字证书。市场上证书签发的厂家很多，绝大部分是国外的厂家。目前市场中主流的几个证书厂家的市场份额如下，用户可以参考。

目前可能开源社区用户使用的比较多的是免费的Let's Encrypt，其他则是商业证书，用户需要支付费用购买这些证书。因为Let's Encrypt是免费的证书，而且安装方便，使用的用户数量也正在稳步增加，它每天签发的证书接近3百万，其用户数量是非常庞大的。

在数字证书中包含了public key（公钥）和private key（私钥）。Public key（公钥）和private key（私钥）存在着互相绑定的算法关系。具体的申请处理流程和第三方用户访问流程如下：

在实际运行环境中，为了让用户对加密有一个比较全面的了解，首先，我们介绍一个比较典型的示例，关于安全证书在购物网站的基本工作原理。

让我们看看具体的证书实现流程细节：

首先，用户访问购物网站，例如通过80端口。
网站会切换到HTTPS通过端口443 访问购物网站。当然，现在很多网站都使用了443 端口，用户不需要访问80端口。
购物网站发送一个public key，然后对其生成一个private保存到服务器端。
终端用户通过浏览器和public key自动生成一个新的key消息，然后发送到服务器端，服务器端通过这个消息，然后结合保存在服务器端的private key 进行匹配检查。如果双方的key匹配，则进行购物付款交易。

客户服务器购买了商业证书以后，如果用户访问此服务器，服务器就会发送一个public key要求进行证书的核实，终端用户需要访问第三方的证书发放机构来验证是否是有效的证书。如果是否都验证了证书的有效性，则执行下一步的流程。一般用户终端会接受一些著名机构发放的证书，有时会弹出对话框，用户需要点击浏览器对话框接受此证书。当然，证书包括了证书发放者名称，版本，subject，有效期，算法等修改参数。如果证书失效或者其他参数不兼容，则需要用户重新安装。

另外一种发放证书的模式就是自签的证书，顾名思义，就是用户服务器端用户自己创建的证书。以下图例说明了如何实现自签证书的流程。

客户端需要接受服务器端的证书以便保证证书的有效性。这里，笔者要提醒用户，自签的证书一般仅使用在测试环境，它的兼容性不好，同时可能导致其他的安全漏洞。

在证书的分发中，我们经常会看到一些用户公钥基础设施。这些基础设施的创建涉及了非常大型的公司或者组织，需要耗费大量的资源和复杂的平台环境才能实现。基于目前国产化进程的不断推进，国内很多比较大型的公司提供了类似的服务。

关于TLS的介绍

SIP的安全机制是基于HTTP的安全机制演进而来的。针对SIP安全机制，目前的安全机制通过不同的层级来实现其安全策略，主要的策略包括应用层安全机制，传输层安全机制和网络层安全机制。

前面我们介绍了一些证书和加密机制的概念和功能流程，现在我们把这些必要的技术整合在一起为读者详细说明TLS的处理机制。TLS是基于SSL的新的传输层安全机制。目前用户使用的标准规范是TLS-1.2 版本，最新版本支持TLS-1.3。关于TLS-1.3 版本的详解，读者可以参考RFC8446。和TLS-1.2相比，TLS-1.3 处理速度比较快，移除了一些旧的安全协议，更新了比较新的安全协议，例如，H-D，AES等，因此其安全性相比1.2版本有了更多保证。以下是激活http的一个关于TLS实战的具体处理流程：

很多用户担心自己的场景中是否使用最新的TLS版本。关于TLS-1.3的版本问题，用户可以访问专业的测试网站可参考TLS的版本支持，直接输入相应的IP地址就可以获得TLS版本详情。笔者为读者提供了一个测试工具示例，用户可以直接访问此网站检查自己的TLS版本，例如浏览器的TLS版本等。

https://www.ssllabs.com/

SIP 信令加密和RTP加密

在以上的章节中，我们介绍了签权授权，证书，TLS等和SIP加密必要的基础知识，在具体的SIP呼叫环境中，我们需要根据以上基础知识对SIP加密做进一步的深入的了解。在关于SIP加密的内容讨论中，我们主要针对SIP和SIPS，以及RTP加密进行详解说明。大家应该知道，我们讨论加密的话，我们通常仅笼统地说加密这个概念。事实上，在具体的应用场景中，如果对一个SIP呼叫进行加密的话，我们考虑的因素会远远超过了我们的想象。在不同的呼叫场景中会面对不同的挑战，一个SIP呼叫可能仅仅限于内网呼叫，另外一个呼叫也有可能需要穿越多个网络环境，其呼叫路径可能涉及了多个hops节点才能最终抵达呼叫目的地地址。很多时候，如果一个SIP呼叫需要穿越多个hops节点时，很多用户使用了SIPS的方式：（sips:bob@example.com，而不是sip:bob@example.com的格式）。但是，使用SIPS需要确保全部的呼叫路径都能支持TLS，如果其中一个hop没有使用TLS，此呼叫将可能会失败。因此，在使用SIPS呼叫时，用户一定要确保TLS的使用和其兼容性支持。在关于SIPS的支持，RFC5630-3.3对TLS支持进行了非常详细说明，包括了hop-by-hop检测等问题的讨论。以下示例是在呼叫路径中某些节点没有使用TLS的情况。

在大部分使用SIP-TLS的场景中，TLS仍然支持的是hop-by-hop的TLS加密方式。这种方式可以针对自己内网环境中的终端，SIP服务器或者IPPBX加密，或者针对自己的SBC加密。因为运营商自己的网络之间是相互信任的网络，运营商之间可以不使用TLS。

在以上的解释中，笔者说明了使用SIPS或者SIP的简单场景，在实际部署过程中，SIPS仍然需要面对很多的问题，具体表现在以下几个方面：

读者应该注意，在使用了TLS加密以后，维护方面就相对比较复杂，一些抓包工具不能有效支持其加密文件的解析，在系统用户维护方面会带来很多困难。
另外，如果使用SIPS的话，传输将使用TCP而不是UDP，一些厂家的SIP终端对TCP支持可能不是非常好，因此，在使用SIPS时要注意这个问题。
SIPS需要正确的DNS配置，支持NAPTR和SRV。但是在实际的应用场景中，仍然面对地址解析的问题。
边缘设备或者终端支持的证书需要进一步完善和统一，这是SIPS部署时需要完善的兼容性支持。
tls参数在SIP头支持还是VIA支持的兼容性问题需要用户进一步确认核实，这样会导致很多的兼容性问题。目前在SIP头中支持tls的方式已经被弃用。

这里，笔者根据前面介绍的TLS处理流程，结合SIP呼叫和读者再重复一次TLS处理流程。TLS支持的呼叫也经过同样的处理流程，TLS握手成功以后开始SIP INVITE呼叫。

端对端（Hop By Hop）加密方式是目前部署非常普遍的一种加密方式，一般部署在集成商或者简单的电话系统中。但是，它存在一些问题，例如，Proxy不能读取SIP消息，甚至告警消息。另外，因为已经SIP已经加密，运营商或者服务提供商所提供的服务可能不能得到完整的支持。最后，如果是跨国的服务的话，端对端的SIP加密是不允许的。从服务端角度来说，Hop By Hop的加密方式则相对比较好一点。如果遇到跨国的测试时，则可以取消加密，呼叫仍然可以正常工作。另外，Hop by Hop 的方式可以支持SIP修改一些SIP头参数，例如可以修改Record-Route 或Via 头域。当然，选择什么样的加密方式都是有成本的。两种加密方式同样会导致不同的语音数据结果，例如，丢包情况，和时延。以下图例是两种方式的延迟测试结果，希望读者一定要注意：

对RTP语音流加密处理机制

我们前面讨论了对SIP信令的加密，但是仅对SIP加密仍然不会实现真正的加密，电话系统必须对语音也进行加密。对语音加密的则称之为SRTP。在下面的内容中，笔者将从几个主要的方面针对RTP加密进行剖析，这些主要核心要点包括SRTP使用，Crypt和DTLS等相关细节。

SRTP的主要作用当然是确保语音流和RTP Payload的加密安全，同时防范第三方软件对语音的注入，确保本身语音的完整性。SRTP不使用PKI的方式来交换密钥，它使用的是Master key的方式。如果直接通过明文的SDP发送key是不安全的，所以必须使用加密的方式来传输。如果发起INVITE之前没有开启TLS的话，SDP消息中的k就会被暴露出来，这也是非常不安全的。

如何在传输中以安全的方式传输SDP中的k是一个非常复杂的流程。以下是一个传输SDP k的流程图。这里需要注意到是，在传输过程中，用户需要设置SRTCP来保护第三方侵入，防止对呼叫方强制发送BYE消息，挂断呼叫。

cipher加密默认使用的是AES，它是一种高级的加密方式。RFC3711标准对此加密方式的类型和算法有非常详细的说明，AES本身就非常复杂，笔者对此不是太了解，如果读者希望获得更多算法的话，笔者建议读者查阅RFC 3711。我们现在介绍的SDP中的k属性，它相对比较简单，所有的k的消息都在交互中进行。另外一种方式就是使用SDP中的crypto，它也是一种交互机制，但是支持了很多参数，而且比较灵活。它主要描述了前一个单播媒体中的cryptographic suite，key 参数和会话参数。注意，crypto必须出现在SDP的媒体中，不会出现在信令中。基本的语法格式为：

a=crypto:<tag> <crypto-suite> <key-params> [<session-params>]

在以上的举例中，SDP包含了3个m 媒体流，但是其中的两个媒体流则使用了RTP/SAVP传输，每个媒体流都有自己的crypto。

关于crypto具体的解释如下：

tag 1 定义crypto的suite。一般默认是1。
AES_CM_128_Hmac_SHA1_80 则表示是SRTP使用的cipher。
HMAC_SHA1_80是一个80bit的认证tag消息。
Master key的长度是128 bit（前面已经定义为AES_CM_128），默认的最大生命周期是2^20。
inLine 是一种Key的方式。这里已经明确，inLine 后面的一串字符（PSXXXVBR）。注意，这里也可能是一个URL。
1：32这里不是1 是Master Key ID，32 Bytes长。也可以支持更多更多的Master key，这些key未来可能会更新。

我们的示例中使用的是默认的设置。关于crypto suite在RFC4586中有非常详细的定义，我们这里不再更多讨论。如果读者有兴趣的话，也可以参考AES Crypt 免费开源工具来了解其加密命令使用。

以下是一个终端设置的举例，用户必须启动相应的安全设置和参数。注意，不同的终端可能支持的参数有所不同，用户要注意检查。

在SDP中的消息举例中，这里通常出现的两个crpto中，用户会首先选择第一个crpto。另外，读者一定要注意，因为加密是双方的安全机制，需要双方检查，同时需要IPPBX本身要配置相应的设置，否则可能导致呼叫失败。

尽管SIP加密方式已经对SIP信令点安全设置了很多复杂的算法，但是仍然缺乏对呼叫方的身份（Caller Identity）认证经过多次转发的身份保护机制。如果初始的SIP请求发起方经过多个路径，当初SIP消息的发起者的身份在到达最终目的地之前可能因为安全的问题发生修改。RFC4474对类似呼叫方身份做了安全的保护。RFC4474在头域中定义了两个参数值：Identity和Identity-Info来确保发起请求者的安全。Identity负责传输用户有效性的签名消息，Identity-Info负责对证书签名者传输一个证明信息。

以下图例解释了如何通过SIP头域中的Indentity和Indentify-Info 发送到呼叫请求中的身份消息。

整个身份验证的流程经过以下几个步骤：

终端发起INVITE消息，Proxy收到消息以后和自签的证书服务器进行交互。
本地Proxy通过证书服务器，使用hash和from header生成本用户的Indentity。
签名服务器返回证书消息，Proxy在SIP消息中添加证书的Indentity和Indentity-Info（证书发放签名）。然后对对端Proxy发起一个INVITE消息。
对端Proxy收到INVITE消息以后，通过web server 获取证书信息，然后提取SIP消息中的Indentity和Indentity-Info，结合hash来计算用户安全身份。
如果验证成功，则对另外一个终端发起INVITE消息。整个验证过程结束。

注意，RFC4474仅发布了SIP请求中的安全机制，并没有规定如果发生错误时的响应处理机制。响应处理是一个更加复杂的处理流程，希望未来有更多RFC规定来进一步的优化。

通过以上身份的验证，整个INVITE信息的安全处理结束后，接下来启动语音的安全认证流程。这里使用了DTLS（Datagram Transport Layer Security）来验证Indentity和语音的加密处理。以前我们介绍过，TLS不能支持UDP的传输，但是实际工作场景中，仍然有很多应用使用UDP。所以，为了满足UDP的安全处理机制，通过对TLS拓展实现DTLS的安全机制。DTLS可以适用于时延比较敏感的应用场景和VPN（隧道）等场景。在以下场景中，INVITE完成以后，用户通过DTLS实现对双方Indentity加密认证，也包括来对语音进行加密。

当然，以上场景仅是一个非常简单的双方呼叫的场景，事实上，在DTLS加密的环境中，很多应用层面的功能需要考虑，例如，匿名呼叫的防范，早期媒体流的处理，分拆SIP请求，多个媒体处理的握手认证流程。如果Proxy在处理这些功能处理时不能正确处理DTLS握手的流程，也同样会导致很多呼叫问题。关于DTLS的规定，用户可以参考RFC5763进行进一步的研究，我们这里不做更多讨论。

上面我们提到了关于对发起呼叫方的安全控制机制，但是，目前仍然没有看到非常完整的关于呼叫方安全保障的完整的解决方案，除了RFC4474以外，以下规定也对caller的身份做了相关的规定：

RFC 4474bis-00是RFC 4474的升级，除了header中的identiy以外使用，不仅仅在from header中使用SIP URL，在from header中还增加了Tel的号码支持。
STIR（Secure Telephone Identity）是目前专门针对VoIP-to-PSTN规定的标准，主要目的对发起呼叫者的号码进行保护和确认。因为，在实际电话应用的场景中，大部分的用户仍然相信普通电话号码的呼叫，但是因为网络的介入，PSTN号码可能最终被其他非法业务利用来进行非法呼叫。此标准专门针对非法呼叫，语音语音邮箱攻击等业务设计了不同的机制。具体规定请读者查阅STIR证书草案。关于最新美国FCC对此规范的强制执行的细节，读者可以参考链接。
P-Asserted-Identity：服务提供商对号码服务提供的认证用户保护。其中，在SIP INVITE的呼叫中包括了caller id消息，Proxy 通过在SIP头中添加P-Asserted-Identity对呼出的网络声明其真实性。
PSTN网络中的ISUP通过S/MIME 支持了SIP的SDP加密，需要说明的是，SIP header 不会被加密，仍然需要通过TLS处理。此图例中，SIP经过两个Gateway 传输，最后到达另外一边的终端，并且通过MIME来传输ISUP消息。

SIP trunk 加密

在前面的提到的安全策略中，我们所探讨的都是基于本地认证机制来实现的。这些解决方案相对比较复杂。如果用户部署了企业IPPBX的话，企业IPPBX通过SIP 中继实现外部呼叫连接的话，可以通过以下方式实现：

企业用户的IPPBX 使用TLS时一般需要注意以下几个方面的问题：

企业PBX必须自己对运营商做认证，使用数字证书或者自签证书实行。运营商可以实现对企业IPPBX的控制和计费等功能支持。
如果使用TLS的话，必须对所有介于企业PBX和运营商之间的信令进行加密，所有代理服务器需要TLS支持。
所有企业PBX使用的证书对运营商来说是有效的证书。
公司可以使用自签证书来实现对运营商的认证，但是，运营商必须经过调整能够支持此证书。

除了企业IPPBX使用SIP加密的trunk来实现运营商和企业呼叫之间的加密处理以外，企业IPPBX也可以通过防火墙接入或者SBC的方式来实现。使用对SIP支持比较好的防火墙来对SIP进行安全处理。事实上，类似的方法也可能遇到很多问题。

使用IP-Sec设备或者SBC来连接，通过IP-Sec设备来对所有语音设备进行加密处理。这里要注意，因为IP-Sec设备会处理全部的信令和媒体，增加了很多网络开销，带宽要求也会随之增加。从目前市场情况来看，如果针对VOIP或者SIP语音应用场景来说，可能SBC是最佳的解决方案。在后期的讨论中，我们会重点介绍SBC的作用，读者可以了解更多比较全面的关于SBC的解决方案。

鼎信通达SBC对接企业IPPBX示例

安全攻击和响应处理机制

在前面的章节和本章节的前几个部分我们重点从技术的角度讨论了关于SIP中安全机制的设置和一些技术概念。在以下的图例中，我们看到VOIP用户仍然面对很多的安全问题，包括上面提到的那些问题，这些安全问题涉及了整个网络的方方面面，同时也涉及了公司安全策略和各种规章制度。以下是关于SIP网络安全在不同层级的安全威胁举例：

研究人员Dimitris Geneiatakis发表的关于几种SIP安全的汇总：

如果我们回到具体的现实环境中，SIP安全的问题主要包括以下几个方面：

IMS 网络安全威胁

通常情况下，VOIP电话系统都会受到至少五种以上的攻击或侵入。因为篇幅的关系，我们这里不展开讨论所有的攻击方式和细节。关于以上攻击方式的介绍，请读者查阅SANS Institute Reading Room 发表的文章，作者重点介绍了各种攻击方式的概念和基本原理。哥伦比亚大学的SIP研究机构也发布过关于SIP安全的介绍，用户可以查阅。如果读者对安全方面的加密算法有非常浓厚的兴趣，可以查阅Amruta Ambre发表的关于算法加密讨论的文章。以下是一个示例通过修改SIP信息，把真正的呼叫转入到侵入者自己的终端。因此，用户必须使用TLS/PKI/SRTP对信令和语音加密。

更多关于使用工具侵入或伪装的操作方式，请参阅笔者提供的参考资料。

另外一个案例是一个所谓通过钓鱼的方式获取用户信息。很多时候，钓鱼者会给用户发送邮件或者短信通知用户呼叫一个电话号码（例如：07558101000），说银行有什么业务需要客户马上联系银行。如果用户呼叫上面的号码的话，这时这个号码会呼叫网关的号码，然后通过VOIP网关修改路由，最后转呼到银行的电话号码上（真正的银行号码：07558100000）。如果用户不小心的话，可能听到银行的呼叫就会按照银行系统的要求输入用户密码信息（323345），这时，钓鱼者可以通过SIP线路上的DTMF按键音获取到用户的真正的密码消息。当然，这样的后果是用户信息被暴露。

另外，非法的盗打情况也可能经常发生，因为很多国际长途的话费是非常高昂的，犯罪分子利用国际话费结算的差价获利。中国国内经常会看到电话骚扰，电话盗打，电话欺骗的新闻。国外也有类似的问题发生。

国家安全监管机构，VOIP行业，设备解决方案厂家，用户等都有非常明确的安全机制来防范安全问题，但是可能仍然会出现安全问题。除了设备或者软件层面的安全机制以外，我们今天介绍几个防范措施来最大限度保证用户的VOIP网络安全。目前，有效地防范VOIP网络攻击的手段很多需要公司系统管理员从不同角度来进行排查，其中也包括了对公司员工的安全教育，公司规定的安全规则，技术手段，安全设备部署等。

关于技术方面的讨论我们前面的章节部分和以前的讲座中已经做了很多分享，现在，我们再补充一点来自于政府权威机构和研究机构的一些安全建议。

美国国家安全监管机构FBI 建议，FBI的建议中，包括了从地理位置的安全处理，设备的安全处理，人员安全培训，管理员的安全培训，采购商的安全处理等方面的内容。以下图例解释了多种网络设备在安全方面的设置和相关的公司规章制度的设立，值得读者去参考。

美国负责计算机安全的机构NIST也给出了几个方面的建议，读者可以作为安全运维等指导：

网络数据和语音分离，私有网络和公网的分离。
使用支持ALG的防火墙或者SBC来提升安全性能。
使用比较严格的安全认证机制来防范被破解。
使用TLS加密方式。
尽量少用个人电脑软电话或者来自未经授权的第三方基于SIP的软电话。

SIP安全测试工具使用

因为VOIP网络中可能出现很多网络安全的问题，公司层面虽然制定了很多安全策略，管理人员也部署了针对安全机制的设备，但是仍然需要一些非常有经验的系统管理员来进行维护检测。技术人员必须了解一些安全工具，以免让攻击者侵入。俗话说，知己知彼才能百战百胜。现在，我们罗列几个已经在VOIP方面使用多年的工具，以便帮助管理员进一步防范攻击者的攻击。

以下列表列出了VOIP工程师可能经常使用的排查工具和平台，大家可以学习：

使用Wireshark 工具抓包解析数据：
Nmap 扫描网络
SIPScan和HoverIP：扫描端口，IP地址。
Authtool 获取认证的工具，密码破解。
进行洪水工具的工具：
linux 工具：inviteflood，registerflood
SIP 信令篡改工具：erase_registrations（删除注册），add_registrations（添加注册流程)
Linux 系统缺陷检测工具：protos SIP test suite
Linux 工具：reghijacker（攻击注册流程），authtool（窃取认证消息）
Linux 工具：sip_rogue（伪装B2BUA，或者SIP Proxy）
Linux 工具：teardown 对已创建的SIP 会话拆线工具，自动结束终端通话。
Linux 工具：check_sync 创建一个SIP 终端重启命令。
Linux 工具：redirector 对SIP呼叫执行重定向，可能转接到非法服务器。
Linux RTP 语音注入工具：rtpinjector 对RTP语音进行注入。
“正式的”Linux平台工具：Asterisk，FreeSWITCH， SIPp以上这些工具或平台是正规的开源语音平台，用户可以通过这些平台开发呼叫中心，IPPBX，压力测试等相关业务。

总结

在本文章中，笔者通过基本的安全认证授权背景知识介绍，SIP加密原理，证书签发，证书验证流程和具体的SIP呼叫签权流程介绍了基本的SIP加密方式，并且介绍了SIPS的部署问题，关于TLS加密包括端对端部署的问题，各种加密算法和最新的TLS-1.3使用情况。另外，笔者介绍了各种SIP网络中所面临的安全隐患和IMS网络中的安全威胁，关于针对SIP网络安全中需要采用的响应措施，SIP trunk加密和企业应用中应该采取的措施和SIP安全工具等管理层面的讨论。网络安全是一个永恒的话题，SIP安全管理也是一个持久关注的话题。为了满足不断更新的SIP网络部署环境以及各种软硬件的安全隐患，用户需要通过认知层面的提升才能面对最新的安全问题。笔者自己也缺乏非常充足的知识储备来面对最新的技术挑战，笔者希望借此文章对SIP网络安全问题进行更加深入的讨论开始，仅当抛砖引玉，希望和读者一起共同提高自己的知识认知。

参考资料：

https://www.slideshare.NET/oej/sips-must-die-die-die-about-tls-usage-in-the-sip-protocol

https://www.cs.columbia.edu/~hgs/papers/Shen1008_TLS.pdf

https://www.scitepress.org/Papers/2007/24335/24335.pdf

https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-58.pdf

https://github.com/miconda/md5ha1

https://www.site.uottawa.ca/~bob/gradstudents/DigestAuthenticationReport.pdf

https://allenluker.WordPress.com/2014/07/16/sip-digest-authentication-part-1-sip-registration-method/

https://github.com/OlegPowerC/SIPdigestCalculator

https://datatracker.ietf.org/doc/rfc8760/

https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443829&idx=1&sn=a32214c98b2c4c877e8dc624769323dc&chksm=8465bbefb31232f950609bd5b2c9eddf48860f762c6123603c317afa0a0e836b58c10442c590&token=730889991&lang=zh_CN#rd

https://mp.weixin.qq.com/s?__biz=MzA4NjU0NTIwNQ==&mid=2656443879&idx=1&sn=f54fc7f5451baf304b3ae2a77ccb269f&chksm=8465bbbdb31232ab12e0acc204ab588316a51d6918b181e55793aaf64d8876493341563387ad&token=895020875&lang=zh_CN#rd

https://www.clickssl.net/blog/what-is-symmetric-encryption#:~:text=%20Symmetric%20Encryption%20Algorithms%20%201%201.%20DES,3.%20AES%20%28%20Advanced%20Encryption%20Standard%29%20More%20

Charles Shen，The Impact of TLS on SIP Server Performance: Measurement and Modelling。

http://www.ciia.org.cn/news/6132.cshtml

https://datatracker.ietf.org/doc/html/rfc8446

https://www.aescrypt.com/linux_aes_crypt.html