NGINX 应用保护拒绝服务如何适应不断变化的攻击形势

随着我们日常生活的方方面面越来越多地转移到网上，网络攻击者也在紧跟步伐，努力降低我们所依赖的应用程序所提供的服务水平。 他们的动机多种多样，从报复到影响受影响公司的股价，再到制造烟幕以分散安全团队对数据泄露的注意力。

在之前的博客中，我们描述了安全团队过去如何不断开发新的防御措施以防御网络和传输层（第 3 层和第 4 层）的容量耗尽拒绝服务 (DoS)和分布式 DoS (DDoS) 攻击，这些攻击会通过向服务器发送大量 TCP/UDP 连接请求来耗尽服务器的可用带宽。 现在，攻击者又为其武器库添加了一个新工具——DoS 和 DDoS 攻击，这些攻击使用 HTTP 请求或 API 调用来耗尽应用级（第 7 层）的资源。

传统的针对网络和容量攻击的 DoS 保护对于第 7 层攻击无效，因为在应用级别，恶意请求通常看起来与合法请求相同。 此外，与网络级攻击相比，第 7 层的 HTTP 攻击以更低的速率和请求量就能造成破坏。 面对一系列全新的要求，第 7 层 DoS 防护必须更加灵敏：

• 区分攻击和常规流量模式
• 评估负载下的服务器健康状况
• 确定攻击何时开始以及是否结束
• 在不影响合法用户的情况下缓解攻击
• 确定应用程序行为的变化是由于攻击还是应用程序功能更新造成的
• 在长时间攻击下生存且不损失检测效力

NGINX App Protect 拒绝服务(DoS) 解决了所有这些挑战，以确保零日保护的简化、易于实施，并提供自适应、零接触策略配置。

NGINX App Protect DoS 如何自动阻止攻击

NGINX App Protect DoS 使用多步骤过程来检测和缓解第 7 层 DoS 攻击：

1. 在统计场地模型中捕捉典型行为
2. 检查服务运行状况
3. 检测异常
4. 识别恶意行为者和请求模式
5. 通过多层防御缓解攻击

在统计场地模型中捕捉典型行为

该流程的第一步是在我们知道站点未受到攻击时捕获用户和应用行为，以创建一个捕获典型行为基线的统计站点模型。 NGINX App Protect DoS 跟踪 320 个用户和应用程序指标，以全面了解您的应用程序部署。 它还会在观察流量时动态更新统计站点模型。 这样您就无需手动调整系统阈值，同时还能保证 NGINX App Protect DoS 能够考虑到随着时间的推移不可避免地发生的流量模式变化。

一类跟踪指标涉及 HTTP 请求特征 - HTTP 方法、 User-Agent标头的值以及图中所示的其他特征。

检查服务健康状况

许多第 7 层 DoS 缓解工具仅关注客户端流量模式。 为了实现更好的攻击检测，您还可以配置 NGINX App Protect DoS 来主动检查服务健康状况。 它跟踪多个服务器性能指标，例如响应时间和丢弃请求的比例。 这些指标值的恶化表明应用“处于压力之下”，可能是由于受到攻击。 跟踪服务器指标还有另一个好处：一旦 NGINX App Protect DoS 确定攻击正在进行，对健康检查的响应模式有助于识别攻击何时开始。

检测异常

当 NGINX App Protect DoS 根据站点统计模型的偏差和服务器响应的变化（如果已配置）确定正在进行攻击时，它会停止更新站点统计模型，而是分析当前指标值与既定基线的差异。 这些差异可能表明存在全球异常现象。

识别恶意行为者和请求模式

然后，NGINX App Protect DoS 启动两个并行运行的程序：

1. 分析个人用户的行为来检测谁造成或导致了异常。

   NGINX App Protect 最初将所有用户视为嫌疑人并分析他们的行为。 每个用户都可能是攻击者，但衡量所有用户的行为可以让 NGINX App Protect 创建一个统计图表，揭示哪些用户参与了攻击，哪些用户没有参与攻击。 通过使用 IP 地址或请求中的X-Forwarded-For标头来识别检测到的不良行为者。

2. 生成描述攻击流量的规则列表而不阻止合法用户——用于零日攻击保护的实时签名。 以前的攻击期间生成的签名可以重复使用。

   生成的签名识别与攻击相关的 HTTP 属性，如以下示例所示：

   http.request.method eq GET和http.user_agent包含Chrome和http.uri_parameters eq6并且http.accept_header_exists eq false并且http.headers_count eq 7
   

通过多层防御缓解攻击

防御第 7 层攻击的主要目标是在它造成任何损害之前阻止它。

如下图所示，您可以配置保守或标准的缓解策略。 对于这两种策略，第一层防御是阻止上一步中通过 IP 地址和X-Forwarded-For标头识别的恶意行为者的请求。 下一层防御将阻止与上一步生成的签名相匹配的请求。

最后，如果您已经配置了标准缓解措施，并且 NGINX App Protect DoS 发现前两层防御不足，它会在短时间内应用全局速率限制。

在缓解攻击期间尽量减少误报

当 NGINX App Protect DoS 应用全局速率限制时，合法用户的请求有可能被阻止——这是一种误报。 NGINX App Protect DoS 可以减少误报，因为典型的 DoS 攻击是使用僵尸网络控制器（受感染计算机上的恶意软件）运行的脚本创建的，而不是直接由人类创建的。 与网络浏览器不同，许多这些简单脚本无法正确处理 HTTP 重定向，甚至更少的脚本可以处理 JavaScript。 脚本和浏览器之间的这些功能差异有助于 NGINX App Protect DoS 判断哪一个脚本和浏览器正在生成可疑流量。

因此，NGINX App Protect DoS 不会对所有客户端的请求进行速率限制，而是首先发送 HTTP 重定向，然后发送一段要处理的 JavaScript 代码。 脚本机器人无法成功响应，但浏览器可以，这使得 NGINX App Protect DoS 能够阻止来自脚本的流量，同时允许浏览器流量通过。

我们承认，由于可能出现大量误报，一些用户不愿意依赖自适应学习，但我们发现这是缓解第 7 层 DoS 攻击的最有效方法。 NGINX App Protect DoS 通过结合多种方法来减少误报——分析用户行为、检查服务健康检查以及衡量缓解策略的有效性。 这三种方法结合在一起提供了全面的可视性和保护，而无需您手动更改配置来应对攻击。

我已经有 WAF 了，为什么还需要第 7 层 DoS 保护？

您可能想知道，如果您的 WAF 已经可以防御机器人攻击，为什么还需要第 7 层 DoS 保护。 虽然第 7 层 DDoS 攻击通常由机器人发起，但其目的与其他机器人活动不同。 机器人通常试图在不中断服务的情况下获取信息，而服务中断正是第 7 层 Dos 和 DDoS 攻击的目标。

另一个区别是，标准的反机器人工具试图区分“好机器人”和“坏机器人”，这是一项具有挑战性的任务，通常需要人工监督以避免误报。 另一方面，NGINX App Protect DoS 并不关心流量是由机器人还是其他机制生成的——它专注于根据行为区分攻击者和合法用户。 由于 NGINX App Protect DoS 仅在确定机器人正在参与第 7 层 DoS 攻击时才使用反机器人技术，因此它产生的误报比标准反机器人软件少得多。 此外，NGINX App Protect DoS 缓解方法具有 CPU 效率，使其能够在整个 Layer DoS 攻击过程中继续保护您的应用程序。

结论

NGINX App Protect DoS 跟踪与用户和应用行为相关的 320 多个指标，从而形成可提供最准确保护的多因素统计模型。 其独特的算法大大减少了误报。 这些功能使 NGINX App Protect DoS 能够缓解高度分布式的 DoS 攻击，其中每个攻击请求看起来都完全合法，并且单个攻击者甚至可能产生的流量比一般合法用户还少。 NGINX App Protect DoS 凭借其自适应技术，不仅可以保护现代基础设施免受当今的攻击，还可以保护现代基础设施免受未来的攻击。

如果您想了解有关如何确保 DoS 保护的更多信息，请查看我们的解决方案简介。 另请参阅这些相关博客：

• 保护applications免受复杂和现代攻击
• NGINX App Protect 拒绝服务阻止应用程序级 DoS 攻击

亲自尝试 NGINX App Protect DoS – 立即开始30 天免费试用或联系我们讨论您的用例。