中文
随着我们的日常生活日益转向线上，网络攻击者也在努力跟上步伐，试图降低我们所依赖的应用提供的服务水平。他们的动机多种多样，从实施报复到影响相关公司的股价再到制造烟幕以转移安全团队对数据泄露的注意等等。
在上篇博文中，我们介绍了过去安全团队如何不断地开发新的防御措施来应对网络层和传输层（三层和四层）的容量耗尽型拒绝服务 (DoS) 和分布式 拒绝服务 (DDoS) 攻击——这些攻击通过向服务器发送大量 TCP/UDP 连接请求来耗尽服务器的可用带宽。如今，攻击者为其武器库添加了新的工具，即使用 HTTP 请求或 API 调用来耗尽应用层（七层）资源的 DoS 和 DDoS 攻击。
针对网络和容量耗尽型攻击的传统 DoS 防护措施无法有效拦截七层攻击，因为站在应用层角度来看，恶意请求通常与合法请求看起来别无二致。此外，相比网络层攻击，七层 HTTP 攻击能够用更低的速率和请求量来说实施破坏。因此，七层 DoS 防护必须更加敏感和智能，以满足一系列新的要求：
- 将攻击流量与常规流量模式区分开来
- 评估负载下的服务器健康状况
- 确定攻击何时开始以及是否已结束
- 在不影响合法用户的情况下缓解攻击
- 确定应用行为的变化是由于攻击还是应用功能的更新造成的
- 在持久的攻击中生存下来，同时不丧失检测效力
NGINX App Protect Denial of Service (DoS) 可化解所有这些挑战，确保零日安全防护的精简顺畅以及易实施，并能够提供自适应、零接触策略配置。
NGINX App Protect DoS 如何自动拦截攻击
NGINX App Protect DoS 采用以下流程来检测和缓解七层 DoS 攻击：
在统计网站模型中捕捉典型行为
该流程的第一步是在网站已知没有受到攻击之时，捕捉用户和应用的典型行为，并以此为基线创建一个统计网站模型。NGINX App Protect DoS 跟踪 320 个用户和应用指标，以全面了解您的应用部署。它还在观测流量时动态更新统计网站模型。这无需您手动调整系统阈值，同时也保证了 NGINX App Protect DoS 会将未来不可避免的流量模式变化考虑在内。
跟踪的指标涉及 HTTP 请求的特征——HTTP 方法、User-Agent 请求头的值，以及图中所示的其他指标。
检查服务健康状况
许多七层 DoS 缓解工具只关注客户端流量模式。为了确保有效的攻击检测，您可以将 NGINX App Protect DoS 配置为主动检查服务健康状况。它跟踪多个服务器性能指标，例如响应时间和丢弃请求占比。这些指标值的恶化表明，应用正处于“压力之下”，这可能是由于遭到了攻击所致。追踪服务器指标的另一个好处是，一旦 NGINX App Protect DoS 确定攻击正在进行中，对健康检查的响应模式可帮助确定攻击是何时开始的。
检测异常情况
当 NGINX App Protect DoS 确定攻击正在进行时——基于网站统计模型的偏差和服务器响应的变化（如果已配置），它会停止更新网站统计模型，并分析当前指标值与既定基线的差异。这些差异可能是全局异常的表征。
识别攻击者和请求模式
然后，NGINX App Protect DoS 会启动两个并行程序。
-
分析个别用户的行为，以检测是谁造成或促成了异常。
NGINX App Protect 最初会将所有用户都视为嫌疑人并分析他们的行为。虽然每个用户都是攻击者的可能性不大，但通过衡量所有用户的行为，NGINX App Protect 能够创建一个统计视图，揭示究竟是谁促成了攻击。使用相关 IP 地址或者请求中的
X-Forwarded-For请求头来标识检测到的攻击者。 -
生成实时的特征库（一个描述攻击流量同时不拦截合法用户的规则列表）来防御零日攻击。并且，之前攻击中生成的特征库可以重复使用。
生成的特征库可以识别与攻击相关的 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
采用多层防御缓解攻击
七层攻击防御的主要目标是在造成任何损坏之前拦截攻击。
如下图所示，您可以配置保守或标准缓解策略。在这两种策略中，第一层防御是拦截来自攻击者的请求——可通过上一步中提到的 IP 地址和 X-Forwarded-For 请求头来识别这些攻击者。下一层防御则会拦截命中上一步生成的特征库的请求。
最后，如果您已经配置了标准缓解策略，并且 NGINX App Protect DoS 认为上述两层防御依然无法阻挡攻击，那么它会在短时间内应用全局速率限制策略。
在缓解攻击期间最大限度地减少误报
当 NGINX App Protect DoS 应用全局速率限制策略时，合法用户的请求有可能被拦截，造成误报。NGINX App Protect DoS 可帮助减少误报，这是因为典型的 DoS 攻击是利用僵尸网络控制器（受感染计算机上的恶意软件）运行的脚本来创建的，而不是由人类直接创建的。与 Web 浏览器不同的是，许多这些简单的脚本都不能正确处理 HTTP 重定向，更别提处理 JavaScript 了。脚本和浏览器之间的这些能力差异可帮助 NGINX App Protect DoS 分辨出是谁生成了可疑流量
因此，NGINX App Protect DoS 并非对所有客户端的请求都进行速率限制。它会先发送 HTTP 重定向，然后再发送一段 JavaScript 代码片段。使用脚本的机器人（bot）无法成功响应，但浏览器可以。基于此，NGINX App Protect DoS 可以拦截来自脚本的流量，同时允许浏览器流量通过。
我们承认，一些用户不习惯使用自适应学习，因为有可能出现大量的误报，但我们发现这是缓解七层 DoS 攻击的最有效方法。NGINX App Protect DoS 通过结合采用多种方法来减少误报——分析用户行为、检查服务健康状况和测量缓解策略的有效性。这三种方法结合使用，可提供全面的可视化和安全防护，无需您手动更改配置来应对攻击。
我已经部署了 WAF，为什么还需要七层 DoS 防护？
您可能会想，您的 WAF 已经能够防护 bot 了，为什么您还需要七层 DoS 防护？虽然七层 DDoS 攻击通常由 bot 发起，但其目标不同于其他 bot 的行为。Bot 总尝试在不中断服务的情况下获取信息，而七层 DoS 和 DDoS 攻击的目标就是中断服务。
另一个区别是，标准反 bot 工具总尝试将“无害 bot”和“恶意 bot”区分开来——这是一项具有挑战性的任务，通常需要人工复核以避免误报。相比之下，NGINX App Protect DoS 并不关心流量是由 bot 或是其他机制生成的，只专注于根据行为来区分攻击者和合法用户。由于 NGINX App Protect DoS 仅在确定 bot 参与七层 DoS 攻击时才使用反 bot 技术，因此它产生的误报远少于标准反 bot 软件。此外，NGINX App Protect DoS 缓解攻击的方法 CPU 使用率较低，能够在整个 DoS 攻击期间持续保护您的应用。
结语
NGINX App Protect DoS 会追踪与用户和应用行为有关的 320 多个指标，形成一个多因素统计模型，从而提供最精准的防护。其独特的算法大大减少了误报。在每个攻击请求都看起来完全合法的情况下，甚至在一个攻击者产生的流量比普通合法用户还要少的情况下，这些功能也能帮助 NGINX App Protect DoS 拦截高度分布式的 DoS 攻击。借助自适应技术，NGINX App Protect DoS 不仅能保护现代基础架构免遭当今的攻击，还能有效防范未来不断演进的攻击。
如欲详细了解如何确保 DoS 防护，请查看我们的解决方案简介。还请查看这些相关博客：
如欲试用 NGINX App Protect DoS，请立即下载 30 天免费试用版，或与我们联系以讨论您的用例。
