防御 DDoS 攻击相关风险的组织中的错误几乎总是会导致其互联网资源对这些风险的抵御能力下降，并且不可能仅通过连接反 DDoS 服务来弥补这些错误，即使这些服务是最先进的。这种情况往往会因多个缺陷的组合而加剧，从而增加其整体负面影响。
在本文中，我们将分析在为管理数百个网站的大型客户构建 DDoS 风险防护时遇到的一些缺陷。
错误 #1：DDoS 保护仅覆盖部分互联网资源
客户只将部分资源连接到我们的云 DDoS 防护服务，大约有 100 个网站处于未受保护状态。更具体地说，防护仅连接到 OSI 模型中的 L3/L4 层，而 HTTP 应用层 (L7) 当时仍处于未受保护状态。显然，客户认为没有人会找到这些网站，也不会对它们感兴趣。如果他们是普通用户，情况可能也是如此。
然而，攻击者并没有休息，他们找到了这些网站，并通过应用层的DDoS攻击将其摧毁。
这个例子再次证明，部分保护措施对 DDoS 攻击的防御是“漏洞百出”的，因此在实践中是无效的。为了可靠地保护互联网资源免受 DDoS 风险，必须全面保护它们，并采取一系列相互关联的措施来降低这些风险（我们在本文中概述了我们的方法的细节）。
而且由于攻击非常猛烈，反 DDoS 服务能够快速识别非法流量的主要来源，并在数据包级别抑制大部分攻击。但是，剩余流量的量足以使客户未受保护的站点在 L7 层无法访问。
为了彻底解决问题，必须在应用程序级别加入过滤服务。我们很快就做到了这一点：在收到客户未完全保护的站点的完整列表后，我们将其置于 L7 层反 DDoS 服务的保护之下。
错误 #2：客户的网络不仅向我们公布，还向另外两家 ISP 公布
我们的客户决定“两面下注”：他们不仅通过 StormWall 注册了网络，还通过两家 ISP 注册了网络，并将他们的渠道视为备份。为了主要通过 StormWall 网络路由流量，他尝试使用 BGP 前置机制的公告来降低通过其他两家提供商的路径。
然而，这种技术并没有奏效：由于带有 BGP 前置参数的公告被许多提供商过滤，流量不仅会通过 StormWall，还会通过其他提供商。当 DDoS 攻击开始时，四分之三的非法流量被定向到客户的互联网资源，绕过了 StormWall 的保护。
花了一个多小时才提供网络的独家公告（换句话说，使得流量只经过 StormWall 过滤器），而攻击仍在继续。
有三种方法可以确保通过 HTTPS 运行的互联网应用程序和网站的安全：
- SSL 私钥泄露
- 反 DDoS 服务提供商收到证书和“Let's Encrypt”私钥，无需解密 SSL
- 通过向反 DDoS 提供商提供应用服务器系统日志的内容
无论如何，反 DDoS 提供商必须接收有关如何在 L7 级别交换数据的数据——没有这些信息就不可能建立对网站和互联网应用程序的可靠保护。
在我们的特定案例中，我们应用了披露 SSL 私钥的保护措施，因为资源本质上是信息性的，并且对传输数据的保护没有严格的要求。
错误 #3：在 GRE 隧道上应用了 ACL 机制
在所有流量重定向到 StormWall 过滤器后，我们发现部分网络数据包在某个地方丢失了。原因可能是路由器负载过大。但是，我们的客户声称他的路由器非常强大，并没有超载。
经过诊断，我司技术人员发现，网络丢包现象发生在GRE隧道中，同时该通道的带宽非常充足，GRE隧道中的流量也不是太大。
进一步分析发现，通过 GRE 隧道连接的客户路由器上的 ACL（访问控制列表）机制应用于隧道接口，导致数据包以编程方式而不是硬件方式处理，从而严重影响了这些路由器的性能。
当客户的专家在连接GRE隧道的路由器上禁用ACL机制后，就不再出现丢包的情况了。
* * *
虽然上述错误并不严重，但它们的结合导致我们客户很大一部分互联网资源无法使用。大约四个小时后，这些资源才恢复正常访问。
以下是针对此案例总结的三项最重要的建议：
- 为了使 DDoS攻击防护有效，它必须是全面的，涵盖所有互联网资源以及可用于对这些资源发起 DDoS 攻击的所有层。
- 为了最大限度地减少 DDoS 攻击中未经授权的流量，所有流量都必须经过反 DDoS 提供商的过滤器。
- 为了确保互联网资源对 DDoS 攻击具有较高的弹性，必须优化路由器的运行，以实现其最大性能。特别是，必须确保隧道 GRE 中的 ACL 机制不起作用。
