为什么网络电话可能被窃听？
当您的企业使用 IP 电话（也称 VoIP，Voice over Internet Protocol，即基于互联网协议的语音传输）时，每次通话都会被拆分成成千上万个数据包在网络中传输，就像电子邮件或网页一样。这正是它的一大优势：无需电话布线，可以在任何城市设置分机，费用也低得多。
问题在于，默认情况下许多数据包是以明文传输的，也就是说没有任何保护。任何能在传输路径上某个位置插足的人（公共 Wi-Fi、您办公室内一台被入侵的设备、一条配置不当的链路）都可能看到您在和谁通话，最坏的情况下甚至能还原通话音频。美国国家标准与技术研究院（NIST）早在其 VoIP 安全指南 SP 800-58 中就提出警告：基于数据网络的语音会继承这些网络的风险，需要专门的防护措施。
好消息是，已有经过多年验证的开放标准可以堵住这道门。只需正确启用和配置即可。
需要保护的两样东西：信封和信件
一通网络电话由两部分组成，每部分的保护方式各不相同。您可以把它想象成一封邮寄的信：
- 信封就是信令：谁在呼叫、呼叫谁、通话何时开始、何时结束。在 IP 电话中，这由 SIP 协议（Session Initiation Protocol，会话初始协议）负责，由 IETF（制定互联网标准的组织）在 RFC 3261 中定义。
- 信件就是语音：您和客户所说内容的音频。这些音频通过另一种名为 RTP（Real-time Transport Protocol，实时传输协议）的协议传输。
如果只保护信封，别人仍可能读到信件；如果只保护信件，别人也会知道您写信给谁、何时写的。因此，真正安全的通话会对两者都进行加密。
SIP over TLS：封好的信封
TLS（Transport Layer Security，传输层安全）正是您在浏览器中看到小锁图标时保护网上银行的那项技术。据 IETF 介绍，它的目标是防止第三方窃听、篡改或伪造消息。现行版本为 TLS 1.3，发布于 RFC 8446，并于近期在 RFC 9846 中修订；上一版本 TLS 1.2 则在 RFC 5246 中描述。
当 SIP 信令在 TLS 中传输时，就好比把信封放进一个只有寄件人和收件人才能打开的保险箱。此外，TLS 使用数字证书，让双方都能确认自己连接的是正确的服务器，而不是冒充者。RFC 3261 本身就通过 SIPS 方案考虑到了这一点，要求在通往目标域的路段上使用 TLS 加密传输。
SRTP：只有通话双方才能听懂的语音
SRTP（Secure Real-time Transport Protocol，RTP 的安全版本）在 RFC 3711 中定义。它对语音做了三件重要的事：
- 保密性：对音频加密，默认使用 AES 算法，即使有人截获数据包，得到的也只是毫无意义的噪音。
- 消息认证：能够检测数据包是否在传输途中被篡改。
- 防重放保护：拒绝攻击者企图重新发送以扰乱通话的数据包。
一个关键细节：SRTP 本身并不负责分发密钥，这由信令过程中协商的外部机制完成。因此 SRTP 与 TLS 搭配使用效果最好：如果信封是敞开的，语音的密钥就可能暴露。
针对 IP 电话最常见的攻击
理解这些风险并不需要专业背景。RFC 3261 和 NIST 指南描述了以下场景，等等：
- 窃听（拦截）：有人捕获未加密的语音流量并还原对话内容。
- 冒充：第三方假冒合法服务器或其他用户，或伪造屏幕上显示的号码来欺骗您的团队。
- SIP 凭证被盗和注册劫持：如果攻击者获得某个分机的用户名和密码，就能代替它注册、接收它的来电，或用您的线路拨打电话，而费用由您承担。
- 中断或篡改通话：利用伪造的信令消息，可能试图挂断进行中的通话或篡改其内容。
- 拒绝服务：用大量消息或呼叫淹没您的系统，使其丧失处理能力。美国网络安全机构（CISA）专门针对电话拒绝服务攻击（TDoS）发布了指南，此类攻击会用海量自动呼叫占满线路。
举个例子：一个弱密码分机
设想麦德林一家分销企业，在云端电话交换机上有 40 个分机。为了加快安装，所有分机都被设置了很短、且与分机号相似的密码，而服务器接受来自任何国家的连接。
某个周五晚上，有人自动尝试各种组合，猜中了一个分机的密码，并从别处完成注册。整个周末，他用这条线路拨打国际电话。周一，公司才发现这笔消费，同时还意识到该分机的业务来电可能已被转移。
怎样才能避免？使用长且唯一的密码；配置防火墙，只接受企业运营所在国家和网络的连接；多次失败尝试后自动封锁；设置消费上限和异常流量告警。这些措施都不昂贵；真正昂贵的是没有它们。
保护企业通话的最佳实践
- 尽可能全部加密：在话机、软电话和中继线上，信令使用 SIP over TLS，语音使用 SRTP。
- 强且唯一的密码：每个分机都有自己的长密码，绝不使用出厂默认密码或基于分机号的密码。如果平台支持，请按照 MinTIC 对企业工具的建议，在管理门户上启用多因素认证。
- 防火墙与访问控制：只开放必要的端口，并限制可连接的网络。NIST 建议使用支持 VoIP 的防火墙或会话边界控制器（SBC，Session Border Controller）。
- 及时更新：厂商一发布安全补丁，就立即为交换机、话机和服务器打上补丁。
- 隔离语音网络：NIST 建议将语音和数据置于逻辑上相互隔离的网络中（例如使用 VLAN，即同一布线中的虚拟网络），使受感染的电脑无法直接访问话机。
- 受保护的远程管理：只通过 VPN（虚拟专用网络）或 SSH 等加密通道进行管理。
- 持续监控：检查日志、认证失败记录和异常呼叫模式，并设置告警和消费上限。
应向电话服务商提出哪些问题
在签约（或续约）云 PBX 或企业移动通信服务之前，请提出以下问题，并要求得到具体答复：
- 分机和中继线是否支持 SIP over TLS 和 SRTP？是否默认启用？
- 使用哪个版本的 TLS？如何管理证书？
- 如何保护 SIP 凭证？多次尝试失败后会怎样处理？
- 我能否按国家、网络或 IP 地址限制分机的注册来源？
- 是否提供全天候监控、欺诈告警和可配置的消费上限？
- 平台多久更新一次？如何通报安全事件？
- 基础设施由谁运营：自有团队，还是转售的第三方？
如果服务商支支吾吾或泛泛而谈，那就说明您该继续寻找了。您也可以在我们的法规栏目中了解行业监管框架。
开源软件同样讲安全
全球大部分 IP 电话都运行在开源软件之上，而最常用的工具都支持这些标准。Kamailio 是运营商广泛使用的 SIP 服务器，其 TLS 模块支持 TLS 1.3。Asterisk 提供了分步文档，介绍如何将信令的 TLS 与语音的 SRTP 结合使用。FreeSWITCH 同样支持 SIP over TLS 配置和基于 SRTP 的安全媒体传输。
软件支持并不等于默认启用：真正起作用的是每天负责配置、更新和监控的团队。在 19 80 TIC Cloud，我们的工程师团队自主运营自己的 IP 电话平台，因此这些安全决策都由内部制定和审查。
