为什么体积 DDoS 会削弱 VoIP 提供商以及我们在渗透测试期间看到的内容

顿悟

直到几天前,我还认为模拟体积DDoS 攻击不是我们应该做的事情。如果您要求我们进行此类测试,我们会给出否定的答案。

具有讽刺意味的是,我们一直在不知不觉中模拟体积DDoS 攻击,同时悄悄地忽略了我们自己的结果。但是,是时候停止忽视带宽饱和并开始给予它应有的关注了。

最近的VoIP DDoS 攻击

那么是什么改变了我的想法?为了解释我自己,我需要描述一些主要VoIP 提供商在过去 2 个月中发生的事情。

在我之前的帖子中,我解释说提供商在他们的服务成为持续DDoS 攻击的牺牲品后被勒索。首先,这些攻击似乎包含通常由引导程序服务产生的流量。这不是特定于SIP。相反,它们使网络带宽和服务器资源饱和。

自从我写那篇文章以来,发起了更多的攻击。最令人担忧的是Bandwidth.com 的案例。他们在 VoIP.ms 之后立即成为攻击目标,并在 9 月 25 日至 30 日左右遭受停机。在此期间,通过受害者提供者以及其他关键服务的 911 紧急呼叫失败。这也影响了许多其他通过带宽路由呼叫的提供商,包括 Twilio、Accent、DialPad、Phone.com 和 RingCentral。

他们是如何解决他们的问题的?与VoIP.ms 类似,他们通过 Cloudflare 的 Magic Transit 路由流量。

Cloudflare 的员工写了两篇有价值的博客文章,分享了他们在这些攻击中看到的流量类型的详细信息。第一篇文章解释了大部分恶意流量如何来自 DNS 反射和其他常见的放大和反射向量。他们还给出了一些数字,最有趣的是,恶意流量的峰值为 130 Gbps 和每秒 1740 万个数据包。自然而然地,他们强调了他们的提议和技术——例如,他们已经为 SIP 目标上的无效流量创建了过滤。在第二篇文章中,我发现有趣的是他们开始看到其他流量,包括特定于SIP 协议的攻击。

这背后的网络犯罪分子现在又回到了针对英国提供商VoIP Unlimited 的目标。该受害者之前曾在 8 月底和 9 月初成为攻击目标。在撰写本文时,不仅他们的 SIP 服务似乎无法访问,而且他们的网站也无法访问。因此,虽然攻击并没有停止,但他们又转移到了不同的目标。

我们的VoIP DDoS 测试经验

那么这与我们的拒绝服务安全测试有什么关系呢?很多,实际上。

我们对DDoS 模拟的重点一直放在针对测试应用程序的非体积攻击上。在攻击处理 SIP、RTP 和其他用于实时通信的协议的应用程序的特定行为时,我们认为这些攻击远比简单的 UDP 洪水复杂得多。自豪地,我们会开始我们的攻击,比如说,一个 SIP 目标,结果发现网络已经充满了我们的流量。

因此,我们学会了向客户询问他们的带宽限制,以避免压倒他们的管道。我们还将缓慢地增加我们的测试,以便如果突然发现未知的限制,可以及早发现它们。然后,在这种情况下,我们将使用内置于SIP 泛洪工具(以及SIPVicious PRO 的几乎所有工具部分)中的速率限制器来运行我们的测试。

然后,我们将限制我们的流量保持在其总带宽的给定百分比以下。我们已经看到带宽限制范围从10Gbit/秒到 1Gbit/秒,再到 100Mbit/秒。我们所做的测试通常不是针对较小的提供商,而是针对一些拥有大量安全预算的重量级提供商。

自然,暴徒不尊重,在实际攻击中会全力以赴。

一个灯泡瞬间

通过在我们的渗透测试中达到这样的带宽限制,我们发现了这些攻击背后的勒索者为自己发现的同一件事:对于VoIP 提供商来说,容量 DDoS是一回事。此漏洞似乎影响了许多VoIP 提供商——包括一些主要参与者。

使用合法的VPS 服务器进行此类攻击的成本仅为几美分。对于僵尸网络、引导程序服务和其他黑市报价,价格标签要低得多。在许多情况下,证明这种脆弱性很简单,但不幸的是,痛苦的经历似乎正在推动。

这使我得出结论,应用程序级DDoS 攻击的危害较小。在提供商承认带宽饱和确实是一个关键问题之前,它不会得到缓解。

就我们而言,我知道我们将确保明确检查和证明这些漏洞,而不是采取行动,无所事事的方法。

你可能感兴趣的:(为什么体积 DDoS 会削弱 VoIP 提供商以及我们在渗透测试期间看到的内容)