Slowloris DOS攻击的原理及防护（续）

负载均衡器和SSL

我们已经解决了房子的HTTP侧，但是HTTPS(SSL)呢？ 如果您有一个必须运行端到端加密的环境，并且使用SSL侦听器运行基于Apache的HTTP服务器，那么它很脆弱。 在基于Apache的SSL侦听器前面放置硬件负载均衡器并不能减轻这种漏洞。

这里有一个典型的场景：

客户端尝试HTTPS连接到Web站点。
加载均衡器“前端”网站，可能能够检测SSL会话ID，但不能检查SSL通信量，因此没有进一步的HTTP协议检查能力。
硬件负载均衡器将HTTPS连接发送回基于Apache的HTTP服务器，执行SSL握手，然后在SSL连接中发送HTTP数据。
如果HTTP请求使用该漏洞，则将使用基于Apache的HTTP Server工作线程。由于这是在SSL上完成的，所以使用硬件负载均衡器检查和检测漏洞的能力受到限制。
由于硬件负载均衡器必须能够检查HTTP请求头，以便执行延迟绑定和防止Slowloris，所以它首先必须能够看到HTTP数据。 要做到这一点，您的硬件必须配置为解密SSL，然后执行延迟绑定，这是我们以前讨论过的。
这种配置可以通过CiscoCSS上的后端SSL配置来完成，或者通过在不同的硬件负载均衡器上使用类似的特性来完成。 这确实需要您的负载均衡器使用加密卸载解密传入的SSL通信量。

结论：

默认情况下，硬件负载平衡器不能防止Slowloris。 然而，当配置为执行延迟绑定时，硬件负载均衡器可以是对HTTP的非常有效的保护。 然而，对于HTTPS来说，事情变得更加复杂，因为硬件负载均衡器检查流量的能力上受到限制。 可以通过配置负载均衡器来解密SSL通信量来解决这个问题，以便可以检查HTTP请求并执行延迟绑定。

Apache

我们已经研究了如何配置负载均衡器，那么如何修复Apache本身？
Apache目前的问题在于，它可以通过相对温和的Slowloris攻击脱机。 当然，Apache开发人员肯定正在着手解决这个问题（你懂得）毕竟Apache开发人员的反应好坏参半…
举个例子
ha.ckers.org博客文章中引用的这一问题并未得到重视的回应，以及官方apache.org Slowlorisbug中这一问题被描述为“INVALID”。
幸运的是，一些Apache开发人员对这个问题更加诚实，比如Apache提交者Paul Querna的apache-dev post中关于这个问题：

分裂是错误的方法。

我们都知道我们的建筑是错误的。

我们已经开始修复它，但我们需要完成异步输入
重写主干，但所有黑客攻击它的人，我自己
包括在过去的几年里已经击中了ENOTIME。

希望由此产生的宣传将重新引起人们的兴趣
在解决这个问题的正确方法中，一劳永逸
为了有效地处理Slowloris，有许多修改Apache或添加额外Apache模块的工作。 到目前为止，我们已经研究了其中一个修改。

anti-slowloris.diff

Andreas Krennmair于2009年6月21日在apache-dev列表中发布了一个名为“anti-slowloris.diff.”的补丁，该补丁只适用于prefork MPM，它是Apache如何能够更好地抵御Slowloris攻击的概念证明。

在我们的测试中，我们发现这个补丁不是完全有效的。 虽然它确实允许Apache在基本的Slowloris攻击中生存下来，但当使用更强大的Slowloris攻击时，Apache仍然离线。

其他选择

还有其他选项，如mod_noloris，这些选项正在开发中，并可能被集成到Apache中。 我们还没有时间测试mod_noloris，以确定它是否有效。

结论：
我们还没有找到可以直接集成到Apache中的Slowloris的防御方法。

网过滤器

防止Slowloris的另一种选择是使用类似Linux的netfilter connectimit功能（在内核2.6.23中可用），以限制来自特定主机的传入连接的速率。 这可以为HTTP实现如下：
iptables-A INPUT-p TCP-syn-dport80-m connectimit-connectimit- above100-j DROP
虽然可以有效防御Slowloris，但我们对这种方法确实有一些担忧。

首先，连接限制率必须非常低才能保护Apache。 这可能会导致合法的请求被拒绝，而且可能不是一个可行的解决方案，更高的流量网站。 这也给源自“超级产品”背后的流量带来了问题，因为这些产品很容易达到限制连接速率的截止值。

由于该解决方案不提供任何类型的延迟绑定功能，因此也可以编写Slowloris攻击，以便它利用多个主机，以较慢的连接速率操作，并且Apache很容易脱机。 因此，我们不能单独推荐netfilter作为Slowloris的完全缓解措施。 它可能适用于一些低流量的站点，但不能对有动机的攻击者提供健壮的保护。

替代Web服务器
对于一些组织来说，切换到一个不应该易受Slowloris影响的替代Web服务器可能是防止Slowloris的可行选择。 我们使用切罗基Web服务器进行测试。
初步的切罗基测试
我们在Funtoo Linux上配置了Cherokee，发现它对Slowloris具有弹性，当Slowloris与默认设置一起使用时。 我们甚至能够在Slowloris上增加一点，并且仍然能够从Web服务器加载页面。
然而，当我们进一步发展Slowloris时，我们发现切罗基开始拒绝连接。 经过调查，我们发现切罗基已经耗尽了1024个可用的文件描述符，将服务器限制在512个同时连接。 在提高了系统的默认限制之后，切罗基能够承受一个非常有代表性的Slowloris攻击，并且仍然提供页面。 然而，在主机系统上消耗了数千个文件描述符。

为Slowloris配置Cherokee

在Gentoo Linux或Funtoo Linux上，您可以通过增加Cherokee用户可用的文件描述符的数量来配置Cherokee对Slowloris具有弹性。 为此，首先通过向/etc/security/limits.conf添加以下行来提高用户可用的文件描述符的默认数量：

•           soft    nofile          4096
  

•           hard    nofile          5028
  

若应用于Cherokee用户，请将*更改为Cherokee。
接下来，您将需要配置Cherokee，通过修改/etc/cherokee/cherokee.conf或使用Cherokee-admin（高级设置)来利用所有这些文件描述符。可以通过在/etc/cherokee/cherokee.conf中添加以下一行并重新启动Cherokee：

                      server!fdlimit = 4096

虽然Cherokee-admin表示Cherokee将自动检测可用文件描述符的数量，但在我们的测试中似乎没有这样做。

结论
如果您试图防止Slowloris，我们目前的首要建议是：

1. 测试基础设施以确定其弹性水平。
2. 不要假设您的基础设施不容易受到Slowloris的影响。
3. 尽可能利用多层防御。
4. 在测试时找出限制。 不要仅仅使用默认的Slowloris设置。

一般来说，在配置为执行延迟绑定时，具有SSL加密卸载的硬件负载均衡器是对Slowloris的第一个很好的防御。 这将阻止Apache看到Slowloris流量。 我们关心的仅仅是依赖硬件负载均衡器，它只是一层防御。 然而，一层抗辩可能是一个可接受的临时解决办法。

如果您没有可以配置的硬件负载均衡器来防止Slowloris，并且您处于能够切换Web服务器的位置，那么我们的建议是部署替代HTTP服务器，如Cherokee，并配置它，以便它能够处理大量同时连接。

还可以考虑将Cherokee和Linux netfilter连接速率限制（对于内核2.6.23）与高阈值相结合使Web服务器将有足够的资源来处理典型的Slowloris攻击，极端攻击将达到连接速率限制并被拒绝。 我们对这种方法的一个担忧是，它仍然会导致重要的内核资源被使用，因为没有执行延迟绑定。 这可能导致资源问题，导致性能下降，并可能使复杂的多主机攻击有效。

如果可能的话，可以使用多种方法的组合，例如配置正确的硬件负载均衡器和弹性Web服务器。 并请测试您的配置，以确保您的防御工作正常！

https://catalog.caida.org/