Apache mod_wsgi slowloris DoS保护

Question

假设以下设置：

• Apache server 2.4
• 具有默认设置的mpm_prefork（256名工作人员？）
• 默认超时（300秒）
• 高KeepAliveTimeout（100s）
• 使用以下配置启用reqtimeout_mod：RequestReadTimeout header=62,MinRate=500 body=62,MinRate=500
• 过时的mod_wsgi 3.5使用带有15个线程和1个进程的守护进程模式
• AWS ElasticBeanstalk的负载均衡器充当具有60秒空闲连接超时的apache的反向代理
• Python / Django是wsgi应用程序

一个简单的slowloris攻击，就像这里描述的那样，使用“慢”请求体：https://www.blackmoreops.com/2015/06/07/attack-website-using-slowhttptest-in-kali-linux/

上述攻击只有15个请求（与mod_wsgi线程相同）可以轻松锁定服务器，直到超时发生，原因可能是：

• 由于没有发送数据而发生负载均衡器超时（60秒），这会导致apache连接失败，mod_wsgi可以再次发送请求
• Apache RequestReadTimeout由于发送数据而发生，但还不够，mod_wsgi能够在此之后提供请求

但是，只有15个并发的“慢”请求，我能够将服务器锁定最多60秒。

重复相同但有更奇怪的数字，如4096个请求，几乎永久地锁定服务器，因为一旦前一次超时，mod_wsgi总会有一个新的请求。

我希望负载均衡器在向apache发送请求之前应该处理/检测这个问题，它已经针对类似的攻击做了（部分头文件，或tcp syn flood攻击从来没有打过apache，这很好）

有哪些选项可以帮助解决这个问题？我知道没有防故障选项，因为这类攻击难以检测和保护，但服务器可以轻松锁定是非常愚蠢的。

另外，如果wsgi应用程序永远不会读取请求体，我希望问题不会发生，因为请求应该立即返回，但我不确定这个或mod_wsgi的内部，例如，这当使用本地dev wsgi服务器（攻击文件，因为请求体永远不会被读取）时是真的，但是当使用mod_wsgi时攻击成功，这使我认为它甚至在将它发送到wsgi代码之前就试图读取正文。 / p>

Answer 1

Slowloris是一种非常简单的拒绝服务攻击。这很容易被发现和阻止。

检测和预防DoS和DDos攻击是许多解决方案的复杂主题。在您的情况下，您通过使用过时的软件并选择较低的工作线程数来使情况变得更糟，以便快速出现问题。

可用于管理Dos和DDos攻击的服务组合。

整个系统的前端将受到防火墙的保护。通常，此防火墙将包含Web应用程序防火墙，以了解HTTP协议的细微差别。在AWS世界中，通常使用Amazon WAF和Shield。

另一项有用的服务是CDN。 Amazon CloudFront使用Amazon Shield，因此它具有良好的DDoS支持。

下一步是将负载均衡器与自动缩放机制相结合。当运行状况检查开始失败（由Slowloris引起）时，自动缩放器将开始启动新实例并终止失败的实例。然而，持续的Slowloris攻击只会击中新的服务器。这就是Web应用程序防火墙需要检测攻击并开始阻止攻击的原因。

对于您的学习，请查看 mod_reqtimeout 。对于大多数Slowloris攻击，这是一个有效且可调整的解决方案。

[更新]

在2015年6月的亚马逊DDoS白皮书中，特别提到了Slowloris。

  

在AWS上，您可以使用Amazon CloudFront和AWS WAF来保护您的   应用这些攻击。 Amazon CloudFront允许您   缓存静态内容并从可以的AWS Edge Locations提供静态内容   有助于减少原产地的负担。 此外，还有Amazon CloudFront   可以自动关闭慢速读取或慢速写入的连接   攻击者（例如，Slowloris）。

Amazon DDoS White Paper June 2015

Answer 2

在mod_wsgi守护进程模式中，有许多选项可以通过从中恢复以及丢弃等待时间过长的排队请求来进一步帮助抵御此类攻击。使用mod_wsgi-express尝试测试，因为它定义了很多这些选项的默认值，而直接使用mod_wsgi时，没有默认值。使用mod_wsgi-express start-server --help查看默认值。您想要查看mod_wsgi守护程序模式的实际选项是request-timeout，connect-timeout，socket-timeout和queue-timeout。还有其他与缓冲区大小和监听器积压相关的选项。请注意，最终主要Apache工作进程的监听积压仍然是一个问题，因为它通常默认为500，这意味着许多请求可以排队卡住，甚至可以用一段时间标记它们以帮助丢弃通过跟踪队列时间来积压。

您可以在以下网址找到相关文档：

• http://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html

关于mod_wsgi在发送请求体之前是否读取请求体，不是没有。 Apache本身因为它读取块可能会在读取标题时部分读取请求体，但它不应该阻塞它。将完整的请求标头传递给mod_wsgi并发送到守护程序进程后，mod_wsgi将开始传输请求主体。

Answer 3

<强> Soloution：
如果你受到了打击，我建议你去一个防范DDoS攻击的提供商。但是，一旦确定IP是恶意的，最好的办法就是以编程方式阻止IP。如果您收到两个大Content-Length POST个请求，那么您应该阻止IP几分钟以进行可疑活动。许多大公司都非常便宜，其中一些公司可以免费使用Cloud Flare这样的基本软件包。我将它们用于我的公司，我很高兴拥有它们！

编辑：他们的工作只是为了保护你。就是这样。