在撰写本文时，一家名为 VoIP.ms 的主要 VoIP 提供商已经受到分布式拒绝服务 （DDoS） 攻击一周多了。结果，他们无法为他们的客户服务，客户反馈说他们无法连接到 VoIP.ms 的 SIP 服务器以及其他资源。与此同时，有人声称自己是 REvil 勒索软件组织的一员，要求支付赎金来恢复业务。

　　这并不是一个孤立的案例，因为本月早些时候，一些英国供应商也受到了攻击，报告还提到 REvil 是攻击的来源。来自安全社区的许多人都认为它不太可能是真正的 REvil，但这不是我想在这里写的。

　　我们确实联系了其中一家受到攻击的英国供应商的人，他解释说，在他们对攻击流量的采样中，他们没有看到任何 SIP 数据包。相反，他们确实看到的是 DNS、SNMP 和其他通常出现在放大攻击和僵尸网络 DDoS 攻击中的流量。

　　通过阅读这些DDoS攻击的公开报告，可以清楚地看到，受害公司不仅在其SIP终端遭受攻击。有人提到了大量的流量，这表明攻击可能是饱和性的，而不是特定于应用程序的。

　　在 VoIP.ms 的示例中，他们最初有一个 DNS 中断，然后转向使用 Cloudflare 作为他们的 DNS。他们还将他们的网站置于 Cloudflare 的网站 DDoS 保护之后，并开始要求验证码等。

　　他们还移动了 POP（接入点）SIP 服务器的 IP 地址，并且在论坛上可以看到人们抱怨 SIP 连接失败。最近，有人注意到他们正在通过 Cloudflare 的 Magic Transit 路由他们的 SIP 流量，它提供 UDP DDoS 保护。

　　然而，它们似乎仍然存在断断续续的连接，或者有时似乎处于离线状态。

　　以下是来自 SIPVicious PRO 的 SIP ping 的日志：

　　这不是SIP服务器第一次遭到攻击了

　　早在 2011 年，一个感染了名为 Sality 的恶意软件的僵尸网络就开始传播 sipvicious。赛门铁克当时就写了文章进行分析，我们当时也进行了分析。本质上，目标 SIP 提供商无法处理正在传播的 SIP 破解攻击。这与对 SIP 服务器的 DDoS 攻击具有相同的效果，即使这可能是无意的。

　　攻击 SIP 很容易

　　我们在进行 DoS 和 DDoS 模拟练习时发现，攻击 SIP 服务器很少需要饱和攻击。相反，SIP 洪水式攻击通常会覆盖大多数以前从未经过测试的 SIP 服务器，因此可以抵御此类攻击。对于我们的许多客户来说，他们已经拥有针对 SIP DoS 的保护，但我们经常发现，一旦我们开始传播，他们的系统就会出现故障。所谓传播，我指的是少量的服务器，而不是你在实际攻击中看到的大规模僵尸网络。

　　这种失败的主要原因似乎是保护机制往往没有任何实际的测试。因此，它们往往有差距，我们在DoS模拟中滥用，导致目标服务停止响应合法用户。

　　这就是我们经常在测试中取得成功的原因。但是还有一个很好的问题要问：为什么 SIP 服务器如此容易被攻击？因为SIP服务器很复杂。

　　以下是一些经常被攻击的项：

　　?身份验证机制，由于存储凭据的数据库存在安全漏洞；

　　?大量 SIP 调用导致媒体服务器端口耗尽；

　　?处理 SIP 会话和对话所需的 CPU 和/或内存使用量超过了可用资源；

　　?已知会导致错误、填充日志文件或日志服务器的特定格式错误的 SIP 消息；

　　?在基于TCP或TLS的SIP上，我们会遇到文件描述符资源耗尽的情况，特别是在SIP INVITE洪水式攻击期间；

　　大多数都是在没有大量网络流量的情况下触发的。不幸的是，即使在速率受限的地方，这些攻击工作得也相当好。

　　如何测试 SIP DDoS 漏洞？

　　在测试过程中使用 SIPVicious PRO 的 SIP DoS Flood 工具。在侦察阶段，我们进行各种测试，以发现最明显的漏洞，例如通过测试各种不同的SIP消息类型。在 SIP INVITE 洪水式攻击的情况下，我们还指定如何处理调用，是否在某个时间挂断调用。并发连接的数量或用于 SIP 的传输协议是另一个重要的考虑因素。最后，我们选择低于任何现有保护机制但高于 SIP 服务器可能承受的发送速率。

　　然后，我们就可以开始攻击了。

　　举个简单的例子，你可以观看我们为 Kamailio World 2019 提供的无脚本演示。

　　当然，设置目标设备的人没有时间准备我们的拒绝服务测试。运行 FreeSWITCH（我相信它是 FusionPBX 安装）的系统没有任何保护。所以这根本不是一个公平的例子，但它确实展示了我们的一些工具，部分地展示了我们如何进行此类测试。

　　保护和缓解

　　解决这一威胁的一个很好的解决方案是，首先避免将关键基础设施暴露给基于网络的攻击者。

　　另一方面，如果你的业务模型必须把 SIP 服务器暴露给网络，那么缓解措施就不那么明确了。因此，我们首先应该区分饱和攻击和应用程序级攻击。

　　容量攻击所需的保护通常需要DDoS缓解提供商提供足够大的管道，以处理承受此类攻击所需的大规模带宽。对 VoIP.ms 和英国提供商的攻击似乎属于饱和攻击的范畴。

　　另一方面，针对特定于SIP或应用程序的攻击的DDoS保护将涉及对基础设施、架构和底层软件配置的调整。通常，人们可能会将配置良好的Kamailio / opensip服务器放置在边缘，可能配置为阻止过多的SIP通信。为了使这些变化有效，需要通过DDoS模拟的结果来通知它们。这个反馈循环对于加强对此类攻击的防范至关重要。

　　如果对 VoIP.ms 的攻击实际上确实包含饱和攻击中的 SIP 流量，那么很可能需要两种保护或缓解机制来实际解决它们的问题。这或许可以解释为什么即使在 Cloudflare 的 Magic Transit 之后，VoIP.ms 似乎仍然存在重大安全隐患。