NGINX App Protect Denial of Service 如何应对不断演变的攻击形势

Vadim Krishtal

随着日常生活越来越多地转移到线上，网络攻击者也在不断加大力度，试图降低我们所依赖应用的服务水平。他们的动机多种多样，包括报复、影响受攻击公司的股价，或制造烟幕，分散安全团队对数据泄露事件的注意力。

在上一篇博客中，我们介绍了过去安全团队如何不得不持续开发新的防御措施，以抵御网络层和传输层（第3层和第4层）的流量型拒绝服务（DoS）和分布式拒绝服务（DDoS）攻击。这类攻击会发送大量TCP/UDP连接请求，耗尽服务器的可用带宽。如今，攻击者又增加了一种攻击手段，即利用HTTP请求或API调用耗尽应用层（第7层）资源的DoS和DDoS攻击。

针对网络攻击和大流量攻击的传统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 and http.user_agent contains Chrome and http.uri_parameters eq 6 and http.accept_header_exists eq false and 
http.headers_count eq 7

通过多层防御缓解攻击

防御第7层攻击的首要目标，是在其造成任何损害之前将其拦截。

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

最后，如果已配置标准缓解策略，并且NGINX App Protect DoS发现前两层防御不足，则会在短时间内实施全局速率限制。

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

当NGINX App Protect DoS应用全局速率限制时，合法用户的请求可能会被阻止，从而产生误报。典型的DoS攻击通常由僵尸网络控制器（受感染计算机上的恶意软件）运行脚本发起，而非由人直接发起。NGINX App Protect DoS可利用这一特点减少误报。与Web浏览器不同，许多此类简单脚本无法正确处理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效率，能够在整个应用层DoS攻击期间持续保护应用。

结论

NGINX App Protect DoS可跟踪与用户和应用行为相关的320多项指标，并据此构建多因素统计模型，尽可能提供准确的防护。其独特算法可大幅减少误报。借助这些功能，NGINX App Protect DoS能够缓解高度分布式DoS攻击。在此类攻击中，每个攻击请求看起来都完全合法，单个攻击者产生的流量甚至可能低于普通合法用户。NGINX App Protect DoS采用自适应技术，不仅能保护现代基础设施免受当前攻击，还能抵御未来不断演变的攻击。

如需进一步了解如何确保DoS防护，请查看我们的解决方案简介。另请参阅以下相关博客：

• 保护应用免受复杂的现代攻击
• NGINX App Protect Denial of Service 可阻止应用层DoS攻击

亲自体验NGINX App Protect DoS，立即开始30天免费试用，或联系我们，探讨您的用例。

关于作者

Vadim Krishtal

Vadim Krishtal 的更多博客文章