我正在开发一个asp.net MVC Web应用程序，客户端要求我们尽最大努力使其尽可能具有抵御拒绝服务攻击的能力。他们担心该网站可能会收到恶意的大量请求，意图放慢/取消该网站。
我与产品所有者讨论过这个问题，因为它实际上不属于实际的Web应用程序。我认为托管/网络团队有责任监控流量并响应恶意请求。
然而，他们坚持认为应用程序应该内置一些预防措施。他们不想实施CAPTCHA。
有人建议我们限制在给定时间范围内可以为会话提出的请求数。我在考虑做这样的事情 Best way to implement request throttling in ASP.NET MVC?但是使用会话ID而不是客户端IP，因为这会给来自公司防火墙后面的用户带来问题 - 他们的IP都将是相同的。
他们还建议添加关闭网站某些区域的功能 - 建议管理员用户可以关闭数据库密集区域......但是这可以通过UI控制，当然如果它是在DOS下攻击管理员用户无论如何都无法访问它。
我的问题是，这样做真的值得吗？当然真正的DOS攻击会更先进吗？
你还有其他建议吗？
答案 0 :(得分：8)
拒绝服务攻击几乎可以影响其他人服务的稳定性。在这种情况下，您谈论的是网络DoS，并且如前所述，这通常不会发生在您的应用程序级别。
理想情况下，这种攻击会在网络级别得到缓解。有专门为此构建的防火墙，例如Cisco ASA 5500 series，它可以从基本保护到高吞吐量缓解。它们是非常智能的盒子，只要正在使用正确的吞吐量模型，我就可以保证它们有效阻止这些类型的攻击。</ p>
当然，如果无法访问为您执行此操作的硬件防火墙，则可以采取一些权宜措施来协助防御这些类型的攻击。 请注意，这些都不会像专用防火墙那样有效。
一个这样的例子是IIS模块Dynamic IP Restrictions，它允许您定义最大并发请求的限制。但是，实际上这有一个缺点，它可能会开始阻止来自具有高并发请求吞吐量的浏览器的合法请求，以便下载脚本和图像等。
最后，你可以做的事情真的粗糙，但真的有效，就像我之前写的那样。基本上，它是一个小工具，可以监视来自同一IP的重复请求的日志文件。因此，假设/Home超过2秒钟向1.2.3.4发出10次请求。如果检测到这种情况，将添加防火墙规则（在Windows高级防火墙中，使用shell命令添加）来阻止来自此IP的请求，然后可以在30分钟左右删除该规则。
就像我说的那样，它非常粗糙，但是如果你有在服务器级别这样做，那么你并没有真正有很多明智的选择，因为它不应该在那里完成。你完全正确，责任在于托管服务提供商。
最后，你对CAPTCHA也是对的。如果有的话，它可以通过一次又一次地执行图像生成（可能是资源密集型）来协助DoS，从而使您的资源更加匮乏。 CAPTCHA有效的时间是，如果您的网站被自动注册机器人发送垃圾邮件，但我相信您已经知道了。
如果确实想要在应用程序级别做一些事情只是为了取悦那些权力，在你的应用程序中实现基于IP的请求限制是可行的，尽管90％无效（因为你仍然会必须处理请求。）
答案 1 :(得分：2)
如果你绝对不得不熬夜，你可以在云中实施解决方案并扩展服务器，但它可能会变得昂贵......
另一个想法是记录注册用户的IP地址。如果DOS限制所有来自“好”用户的请求的流量。
答案 2 :(得分：2)
在应用程序级别上防止真正的DoS攻击实际上并不可行，因为请求很可能在它杀死您的应用程序之前杀死您的Web服务器，因为您的应用程序与应用程序池相关联，而应用程序池又具有最大值由您正在使用的服务器技术定义的并发请求。
这篇有趣的文章 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攻击，但它会使您的应用程序尽可能对其所服务的硬件负责。