NGINX App Protect 拒绝服务阻止应用程序级 DoS 攻击
数字化转型虽然正在加速释放商业潜力，但不幸的是，它也扩大了威胁格局。 当安全团队忙于适应不断增加的范围和责任时，攻击者就会利用这一点，他们滥用应用来获取经济利益的方式变得比以往任何时候都更加老练。 与网络级的传统拒绝服务 (DoS)攻击相比，应用级（第 7 层）DoS 攻击正在急剧增加，很大程度上是因为它们可以绕过那些不是为现代应用架构设计的传统防御措施。
从攻击者的角度来看，第 7 层 DoS 攻击有两个宝贵的特点：它们只需要很少的资源就能造成严重的破坏，而且很难被发现。 此类攻击使用复杂的工具和精准定位的请求发起，导致应用服务器和 API 无法处理合法请求，从而造成破坏。 当服务器接收到的请求超过其处理能力时，它会丢弃合法请求、变得无响应，甚至崩溃。
传统的 DoS 缓解解决方案对于现代应用程序无效。 它们提供基于静态规则的安全性，并需要持续维护以跟上现代应用程序领域变化和更新的步伐。
NGINX App Protect DoS 介绍
NGINX App Protect 拒绝服务（DoS）是 NGINX Plus 的一个新的轻量级动态模块，旨在保护现代应用免受最复杂的应用DoS 攻击。 NGINX App Protect DoS 可缓解旨在破坏和损害应用的攻击，确保持续的性能和收入收集，并在竞争激烈的数字世界中维护客户忠诚度和品牌。
NGINX App Protect DoS 可以部署在任何平台、架构或环境（包括 Kubernetes 集群）上的应用和微服务附近。 它会随着应用不断扩展，并始终保持较高的安全效率。
部署用例
NGINX App Protect DoS 可以部署在多种位置来保护应用服务：
- 边缘– 外部负载均衡器和代理
- Ingress Controller – Kubernetes 的入口点
- 每个服务代理– 内部服务代理层
- 每个 Pod 的代理– 嵌入在 Pod 中的代理
- API 网关——微服务的入口点
缓解的攻击类型
NGINX App Protect DoS 引入了针对多种复杂攻击类型的保护：
GET和POST洪水攻击- （HTTP 和 HTTPS）攻击者试图通过大量请求压垮服务器或 API，使其无法响应真实用户。“慢速”攻击——（HTTP 和 HTTPS） “慢速和低速”攻击会占用服务器资源，导致无法为实际用户的请求提供服务。 有两个因素使得它们难以防御：
- 与网络 DDoS 攻击不同，它们不会占用大量带宽，因此很难与正常流量区分开来。
- 它们不需要太多资源来启动，因此可以使用复杂的自动化工具从一台计算机发送数千个请求。
慢速攻击主要有三种类型：
- Slowloris——攻击者连接到服务器并以缓慢的速度发送部分请求标头。 服务器在等待剩余的标头时保持连接打开，从而耗尽可供实际用户使用的连接池。
- 读取速度慢——攻击者发送格式正确的 HTTP 请求，但读取响应的速度却很慢（甚至根本读不出来）。 这会累积消耗服务器资源，从而阻止合法请求的通过。
- 慢速
POST– 攻击者向服务器发送合法的 HTTPPOST标头，并正确指定后续消息正文的大小。 然后它会非常缓慢地发送消息主体。 由于该消息看起来有效，服务器保持连接打开，等待完整的消息体到达。 大量慢速POST攻击会耗尽可供实际用户使用的连接池。
上述攻击的分布式变体——显然，利用多台计算机可以轻松发送大量同时发起的攻击。 此外，每台计算机的流量可能相对较低，使其类似于普通用户。 计算机还可以退出攻击池然后重新加入，导致源 IP 地址集不断变化。 这些流量特性使得速率限制和地理封锁等传统缓解技术变得不那么有效。
挑战崩溃攻击/随机 URI - 在挑战崩溃 (CC) 攻击中，攻击者发送频繁的正常请求，但请求的 URI 需要执行复杂且耗时的算法或数据库操作，这会耗尽目标服务器上的资源。 攻击者还可以通过随机化 URI 和其他 HTTP 参数来突破静态规则等传统缓解工具。 NGINX App Protect DoS 依赖于先进的机器学习算法，可显著提高功效并减少误报。
隐藏在 NAT 后面– 攻击者使用加密或网络地址转换 (NAT) 来逃避检测。 尝试仅通过跟踪源 IP 地址来检测攻击是无效的，因为即使只有一个用户在攻击，它也会将所有 NAT 用户视为攻击者。
NGINX App Protect DoS 使用 IPv4 指纹识别来准确检测 NAT 背后的不良行为者。 由于大多数流量都是使用 SSL/TLS 加密的，因此可以将识别参与者的密钥从仅 IP 地址扩展为 IP 地址和 TLS 指纹的组合（指纹基于 TLS hello 消息）。
有针对性的 SSL/TLS 攻击– 攻击者滥用 SSL/TLS 握手协议。 一种流行的方法是将垃圾数据发送到目标 SSL/TLS 服务器。 处理无效消息与处理合法消息在计算上一样昂贵，但却没有有用的结果。 大多数防火墙在这种情况下都无济于事，因为它们无法区分有效和无效的 SSL/TLS 握手数据包，并且在防火墙上实施解密成本过高。
NGINX App Protect DoS 使用 SSL/TLS 签名机制，根据 CLIENT HELLO 消息提供基于异常的检测和缓解，该消息在 SSL/TLS 握手过程的早期未加密并传递，从而消除了解密的高成本。 此外，使用 SSL/TLS 签名与监控服务器健康机制可以在不终止 SSL/TLS 的情况下实现 DoS 保护和缓解。
概括
DoS 攻击针对应用而不是网络的情况正变得越来越常见。 由于许多第 7 层 DoS 攻击看起来像合法流量，因此传统的 WAF 防御无法有效检测到它们。
此外，攻击者继续利用机器学习和人工智能等新技术发起第 7 层 DoS 攻击，使得简单规则和静态签名变得不那么有效。 第 7 层 DoS 缓解措施也必须发展，NGINX App Protect DoS 带来了适合自适应和动态防御的技术。
如果您想了解有关如何确保 DoS 保护的更多信息，请查看我们的解决方案简介。 另请参阅这些相关博客：
亲自尝试 NGINX App Protect DoS – 立即开始30 天免费试用或联系我们讨论您的用例。
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息，请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”