Question

我刚读了一篇有趣的文章。基本上它说，你应该以两种方式微调每个应用程序的IIS设置：

处理程序映射 - 删除应用程序未使用的所有内容
modules - 删除所有未使用的应用程序

好吧，我现在开发ASP.NET已经有一段时间了，即使是在工作中，我们也从来没有在生产环境中做过这件事。我理解所提出的理论优势 - 最小化应用程序（安全性）的“表面”，并提高性能。但我真的很好奇，如果你在现实生活中这样做（为你的客户提供真正的项目，而不是概念验证项目）。这有什么缺点（可能性？）。最重要的问题 - 值得吗？例如，性能增益是否可见？

此外，如果您认为这是一个很好的做法，请提供一些良好且一致的方式（或指向我的教程），您是如何完成此过程的 - 您如何决定留下什么以及要删除什么。

例如，什么是ASP.NET MVC 3应用程序的最小但工作集，它使用自定义身份验证（基于会话，不依赖于Forms身份验证，Windows身份验证等），没有Web服务和类似功能？

修改

我找到了这篇文章：http://madskristensen.net/post/Remove-default-HTTP-modules-in-ASPNET.aspx

其中，Scott Guthrie说：

一般来说，使用这种方法可以获得一些非常小的性能胜利 - 尽管我可能建议不要这样做。原因是ASP.NET的某些功能（表单身份验证，角色，缓存等）当然会在您删除它们所依赖的模块后停止工作。试图找出发生这种情况的原因往往令人困惑。

但仍然没有任何测量，实践（我不相信“你以后可能会感到惊讶”的论点：）

Answer 1

<modules runAllManagedModulesForAllRequests="false">
  <!-- disable authorization section -->
  <remove name="UrlAuthorization" />
  <!-- disable unused authentication schemes -->
  <remove name="WindowsAuthentication" />
  <remove name="PassportAuthentication" />
  <!-- disable ACL file and directory check -->
  <!-- <remove name="FileAuthorization" /> -->
  <!-- We don't use ASP.NET Profiles -->
  <remove name="Profile" />
  <!-- We don't provide any WCF service -->
  <remove name="ServiceModel" />
  <!-- Remove modules not used by ASP.NET MVC + jQuery -->
  <remove name="ScriptModule-4.0" />
</modules>

Answer 2

对于它的价值，Security Best Practices for IIS 8有这个：

仅安装所需的IIS模块。

IIS 8由40多个模块组成，允许您添加所需的模块并删除不需要的任何模块。如果你   只安装您需要的模块，减少可能受到攻击的表面区域。



定期删除未使用或不需要的模块和处理程序。

查找不再使用和删除的模块和处理程序   它们来自您的IIS安装。努力保持你的IIS表面   面积尽可能小。

IIS Modules Overview还有一个IIS模块引用，其中包含每个模块的“删除此模块时的潜在问题”部分。例如，如果删除了DefaultAuthentication模块：

如果ASP.NET身份验证模式为Forms，则某些ASP.NET功能可能无法用于匿名请求。此外，不会引发DefaultAuthentication.OnAuthenticate事件。

Answer 3

这并不能直接回答您的问题，但在回答another question on SO时，我刚刚了解了URL Rewrite module turned on对MVC的性能影响。

执行URL生成时（例如通过类似的方法） Html.ActionLink）在某些情况下MVC检查当前是否存在请求的URL已由URL Rewrite模块重写。如果那样的话处理结果以便正确匹配URL的情况客户要求。检查URL是否已被检查的行为重写有一个非常重要的成本（因为它涉及检查服务器变量）。 ASP.NET MVC 3检查URL Rewrite是否已关闭并且可以缓存该事实，从而避免检查服务器的需要每个请求的变量。如果启用URL重写，MVC将具有检查服务器变量，即使没有重写特别请求，所以如果您不使用URL Rewrite，则应该转向它关闭。

因此，即使您没有使用模块，也可能会对您的应用程序产生影响。

但是，我认为除非您对特定模块或处理程序存在安全问题，否则我必须与Scott Gu达成一致，否则您可能不会注意到（除非您每天处理约100万个请求）花这段时间调整缓存（数据库和内容）配置文件会更好。

哦，所以我有点回答你的问题，不，我们不这样做。

Answer 4

从性能的角度来看，这是一个很好的最佳实践。但通常还有其他因素需要考虑。

大多数应用程序随着时间推移而扩展。如果您现在没有使用某项功能，可能会在将来使用。当你这样做时，我可以想象有人忘记重新配置IIS设置，导致你的生产环境停滞不前。
生产环境通常不在开发人员手中。

一个。这些人可能已经有足够的想法进行琐碎的性能调整。

湾发布手册越短越好。为性能调整添加不必要的（在这种情况下，微不足道的）步骤可能会导致查看步骤。

同样，从性能的角度来看，这是一个很好的最佳实践。根据我的经验，大多数应用程序不需要这些性能调整。因此，缺点超过了优点。但是，就像汤米所说，如果你的应用程序每天处理数百万个请求，那么每一点都有帮助。

Answer 5

首先，我会在这里说实话，并且明确表示我没有这样做，但有一次（下面有更多内容）。

从安全角度来看，你必须考虑到这一点并不是一件容易的事。如果您知道自己没有使用一组功能，为什么要继续曝光呢？

现在让我们回到2010年9月。有一个严重的漏洞：asp.net填充oracle。我有一些博客文章，一篇关于asp.net padding oracle: impact on asp.net MVC and PHP

请注意，即使没有积极使用asp.net，这也会影响PHP。

所以问题出现在asp.net MVC中通常不常用的处理程序上。事实上，在我当时正在处理的一些客户端服务器/应用程序上，我们禁用了有问题的处理程序。在MS推出解决方案之前，漏洞已经关闭;应用程序没有受到影响，因为我们没有使用任何处理程序。

权衡，并非所有处理程序都如此简单。在某些应用程序中使用哪些处理程序肯定很难。另一方面，很高兴知道你正在使用的asp.net正在发生什么。

ASP.NET MVC应用程序的性能和安全性 - 处理程序映射和模块

5 个答案: