顿悟
直到几天前，我还认为模拟体积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 攻击的危害较小。在提供商承认带宽饱和确实是一个关键问题之前，它不会得到缓解。
就我们而言，我知道我们将确保明确检查和证明这些漏洞，而不是采取行动，无所事事的方法。
