防止恶意请求 - DOS 攻击答案

【问题标题】：Prevent Malicious Requests - DOS Attacks防止恶意请求 - DOS 攻击
【发布时间】：2013-02-05 11:13:19
【问题描述】：

我正在开发一个 asp.net MVC Web 应用程序，客户要求我们尽最大努力使其尽可能地抵御拒绝服务攻击。他们担心网站可能会收到恶意的大量请求，以降低/关闭网站的速度。

我已经与产品负责人讨论过这个问题，因为它确实超出了实际 Web 应用程序的范围。我认为监控流量和响应恶意请求属于托管/网络团队的责任。

但是，他们坚持认为应用程序应该内置一些预防措施。不过，他们不想实施 CAPTCHA。

有人建议我们限制在给定时间范围内可以为会话发出的请求数。我正在考虑做这样的事情 Best way to implement request throttling in ASP.NET MVC? 但是使用会话 ID 而不是客户端 IP，因为这会给来自公司防火墙后面的用户带来问题 - 他们的 IP 都是相同的。

他们还建议添加关闭站点某些区域的功能 - 建议管理员用户可以关闭数据库密集区域.....但是这将通过 UI 进行控制，如果它在 DOS 下肯定会攻击管理员用户无论如何都无法访问它。

我的问题是，这样做真的值得吗？真正的 DOS 攻击肯定会更先进吗？

您还有其他建议吗？

【问题讨论】：

有趣的是，几分钟前我还在寻找一个解决方案来实现这个。
DoS 攻击是不可防御的，如果可以采取任何措施来减轻它，通常不会在应用程序级别完成。
我不是（根本）专家，但如果我想对服务器进行 DOS 攻击，我会首先尝试发送收费 ping。我不认为应该在网站端处理防止 DOS 攻击，而是用防火墙保护网站。 Sql 注入、跨站脚本等我们已经够用了……
这篇文章可能会帮助您在不同的攻击和领域中制定解决方案：esecurityplanet.com/network-security/…
我同意这是题外话，但它肯定不属于超级用户！

标签： c# asp.net-mvc ddos

【解决方案1】：

拒绝服务攻击几乎可以是任何会影响您对其他人的服务稳定性的攻击。在这种情况下，您谈论的是网络 DoS，如前所述，这通常不会发生在您的应用程序级别。

理想情况下，这种攻击会在网络级别得到缓解。为此构建了专用防火墙，例如Cisco ASA 5500 series，它的工作方式从基本保护到高吞吐量缓解。它们是非常聪明的盒子，我可以保证它们在阻止此类攻击方面的有效性，只要使用正确的模型来衡量您获得的吞吐量。

当然，如果无法访问为您执行此操作的硬件防火墙，您可以采取一些权宜之计来帮助防御这些类型的攻击。 请注意，这些都不会像专用防火墙那样有效。

一个这样的例子是 IIS 模块Dynamic IP Restrictions，它允许您定义最大并发请求的限制。然而，在实践中，这有一个缺点，它可能会开始阻止来自具有高并发请求吞吐量的浏览器的合法请求，以下载脚本和图像等。

最后，你可以做的事情真的很粗糙，但也真的有效，就像我之前写的一样。基本上，它是一个小工具，用于监控来自同一 IP 的重复请求的日志文件。因此，假设在 2 秒内从 1.2.3.4 向 /Home 发出 10 个请求。如果检测到这种情况，则会添加一条防火墙规则（在 Windows 高级防火墙中，使用 shell 命令添加）以阻止来自该 IP 的请求，然后可以在 30 分钟左右后删除该规则。

就像我说的那样，它非常粗糙，但是如果您必须在服务器级别执行此操作，那么您实际上并没有太多明智的选择，因为它不是应该执行的。您完全正确，责任在一定程度上在于托管服务提供商。

最后，您对 CAPTCHA 的看法也是正确的。如果有的话，它可以通过一遍又一遍地执行图像生成（这可能是资源密集型）来协助 DoS，从而使您的资源更加匮乏。验证码生效的时间是，如果您的网站被自动注册机器人发送垃圾邮件，但我相信您已经知道了。

如果您真的想要在应用程序级别做某事只是为了取悦现有的权力，那么在您的应用程序中实施基于 IP 的请求限制是可行的，尽管 90% 无效（因为您仍然会必须处理请求）。

【讨论】：

需要注意的是动态 IP 限制在 IIS 机器上运行，因此在受到攻击时服务器性能仍然会受到影响。建议使用可以提供更好保护的专用防火墙设备。使用云服务可以带来更多好处，因为在大多数情况下您无需担心这一点。
@LexLi 是的，这就是我所说的网络级缓解。我在回答中建议的所有内容都不太适合真正的缓解。

【解决方案2】：

如果您绝对必须熬夜，您可以在云中实施该解决方案并扩展服务器，但它可能会变得昂贵...

另一个想法是记录注册用户的 IP 地址。在 DOS 事件中，将所有流量限制为来自“好”用户的请求。

【讨论】：

【解决方案3】：

在应用程序级别防止真正的 DoS 攻击实际上是不可行的，因为请求很可能会在它杀死您的应用程序之前杀死您的网络服务器，因为您的应用程序与一个应用程序池相关联，该应用程序池再次具有最大值您正在使用的服务器技术定义的并发请求数。

这篇有趣的文章 http://www.asp.net/web-forms/tutorials/aspnet-45/using-asynchronous-methods-in-aspnet-45 声明 Windows 7、Windows Vista 和 Windows 8 最多有 10 个并发请求。更进一步的说法是“您将需要一个 Windows 服务器操作系统才能看到异步方法在高负载下的好处”。

您可以增加与您的应用程序相关联的应用程序池的 HTTP.sys 队列限制，以增加将排队的请求数量（以便在线程准备好后进行计算），这将阻止 HTTP 协议堆栈 (HTTP.sys) 当超出限制并且没有工作进程可用于处理进一步的请求时返回 Http 错误 503。

您提到客户要求您“尽 [您的] 尽力使其尽可能抵御拒绝服务攻击”。我的建议可能不适用于您的情况，但您可以考虑实施文章中提到的基于任务的异步模式 (TAP) 以满足客户的要求。

此模式将在执行长期操作时释放线程并使线程可用于进一步的请求（从而使您的 HTTP.sys 队列保持较低） - 同时还为您的应用程序提供了在多个请求到第三个时提高整体性能的好处方服务或多次密集的 IO 计算。

此措施不会使您的应用程序对 DoS 攻击具有弹性，但它会使您的应用程序对提供服务的硬件尽可能负责。

【讨论】：