掩盖您的 Web 服务器以增强安全性

引言

伪装或匿名化 Web 服务器涉及删除入侵者可能用来检测您的操作系统、Web 服务器供应商和版本的所有识别细节。这些信息虽然对合法用户几乎没有或根本没有用处，但通常是破解者、黑帽黑客和“脚本小子”的起点。本文探讨了一些可以最大程度降低此类检测风险的方法。以下大部分示例都侧重于 Microsoft 的 Internet Information Server (IIS)，因为它因其漏洞而受到最广泛的抨击，但也涵盖了一些 Apache 检测对策。虽然 IIS 用户可能对此最感兴趣，但服务器匿名化与任何负责管理 Web 服务器的人员都相关。

破解者从这里开始。您不也应该吗？

让我们从攻击者的角度来看：安全漏洞往往取决于软件供应商和版本。盲目探测可能会导致进一步的请求被拒绝或系统暂时下线。了解 Web 服务器详细信息可以大大提高任何攻击的效率。如果攻击者可以针对漏洞利用进行攻击，那么在检测之前成功破解的机会就会显著增加。脚本小子可以利用现成的、新发现的漏洞，通过针对具有可识别签名的主机，更快地造成更大的损害。一个自我识别的系统会招致麻烦。

Port80 Software 开发了一个名为 ServerMask 的 IIS 服务器模块，用于解决本文中探讨的大部分 Windows Web 服务器问题。

服务器头信息泄露一切

大多数 Web 服务器都会礼貌地向任何询问者识别自己和操作系统。使用像 Sam Spade 或此 Header Check 这样的网络查询工具，您可以识别 HTTP Server 头信息。只需请求一个网站的主页，然后检查服务器返回的 HTTP 头信息或“横幅”即可。其中，您很可能会发现类似这样的内容

Server: Microsoft-IIS/5.0

这里没有太多神秘之处。Apache 的默认设置也同样容易识别

Server: Apache/2.0.41-dev (UNIX)

您可以根据您的平台，通过多种方式删除或模糊此 HTTP Server 头信息。Apache 用户可以使用模块 mod_headers。IIS 用户可以安装 IISLockDown 并使用 URLScan INI 文件中的配置选项来删除或替换头信息。如果您正在使用 Cold Fusion 应用程序服务器，请小心使用 URLScan，因为当前版本替换 Server 头信息的方式会破坏 CFM 页面。事实上，在使用 URLScan 时，删除头信息是更好的选择，因为如果您尝试替换头信息，它会移到头信息顺序的底部——这几乎可以表明您正在 IIS 上运行 URLScan。

不雅的文件扩展名

在网站中显示 .asp 或 .aspx 等文件扩展名清楚地表明您正在运行 Microsoft 服务器，而且通常情况下，隐藏文件扩展名是伪装生成动态页面的技术的好做法。您可以更改您的应用程序映射（.asp 变为 .htm 或 .foo 等），但这种一对一的映射会使混合服务器端技术变得痛苦，并且无助于减轻网站迁移时的麻烦。完全不使用文件扩展名是一个更好的主意，不仅是为了安全，也是为了易于迁移和内容协商。Apache 用户会希望查看 mod_negotiation。不过，请注意服务器响应中的 Content-Location 头信息，它可能会泄露 URL 中未显示的文件扩展名。您可能需要使用 mod_headers 单独抑制此头信息。同样，Port80 正在开发一种解决方案，以允许在 IIS 中隐藏文件扩展名。

半生不熟的 Cookie

ASP 会话 ID cookie，由 Session 对象用于维护客户端状态，是另一个明显的泄露点

Set-Cookie: ASPSESSIONIDQGQGGWFC=MGMLNKMDENPEOPIJHPOPEPPB;

您可以 禁用 ASP 会话状态，这样就不会放置此 cookie，但您将失去使用 Session 对象维护客户端状态的便利性。您还可以创建一个 ISAPI 过滤器来更改任何会话 ID cookie 的名称。另一方面，ASP 会话是资源密集型的，关闭它们可以提高 ASP 应用程序的性能和可伸缩性，同时也有助于匿名化您的服务器。

把这些送到回收站

WebDAV：识别 Microsoft 服务器的另一种方法是它们（从 Windows 2000 和 IIS 5.0 开始）对 WebDAV 的实现——用于分布式创作和版本控制的 HTTP 扩展。WebDAV 本身并非 Microsoft 或 IIS 独有；它是一个拟议的标准 (RFC 2518)，并有一个 IETF 工作组。然而，Microsoft 的 WebDAV 支持会向服务器发回的标头添加大量信息，尤其是在发出 HTTP OPTIONS 请求时。如果您不使用 WebDAV（例如支持 Outlook Web Access 或 Web 文件夹等），您可以通过编辑注册表或通过使用 IISLockDown 和 URLScan 完全禁用它。

公共标头：某些 Web 服务器通过在 HTTP 响应中显示公共标头来暴露其身份。很少有流行的 Web 服务器在响应 OPTIONS 请求时发送此标头（而几乎所有都响应类似的 Allow 标头）。Public 的存在很好地表明您连接的是 IIS 机器或 Netscape Enterprise 3.6。Public 标头可以通过自定义 ISAPI 过滤器 (IIS) 或 NSAPI 插件 (Netscape) 删除。

集成 Windows 身份验证：IIS 用户不应依赖“集成 Windows 身份验证”——尤其是不要将其作为隐藏服务器上任何内容的方式。这种方法会泄露它本应保守的秘密，因为脚本或可视化黑客可以通过服务器发送的 WWW-Authenticate 标头识别 Windows 机器。当文件或目录受 NT 质询-响应身份验证保护时，其中一个身份验证标头包含字符串“NTLM”（NT LAN Manager）——一种 Microsoft 特有的 HTTP 身份验证形式。

整理好您的头信息

您的 HTTP 头信息的数量和顺序，以及某些平台特定头信息的存在或缺失，为更高级的黑客提供了便捷的方式来识别您的 Web 服务器。这是一个相对未开发的服务器配置文件领域，随着管理员开始实施针对明显 HTTP 漏洞（如 Server 头信息）的对策，这将成为一种更常见的攻击手段。对于 IIS 用户，自定义 ISAPI 过滤器可以更改 Microsoft 特定的头信息顺序或序列，以模拟，例如，默认的 Apache 安装。Apache 用户可以通过试验 mod_headers 中 Header 指令的位置和顺序来完成他们想要的任何头信息顺序模拟。

那是谁的默认设置？

各种默认消息、页面和脚本通常包含服务器身份的线索，应相应地删除或修改这些线索。Web 服务器后面的软件通常会将错误消息通过 HTTP 请求/响应周期冒泡返回，而自定义 HTTP 错误可以掩盖应用程序服务器、数据库服务器、Web 服务器和操作系统的身份。对于 IIS，CustomError 使开发人员可以轻松部署自定义 404 和其他 HTTP 错误页面。本文展示了如何在 Apache 中实现自定义 HTTP 错误。在开发服务器上避免这样做，因为如果操作得当，它会阻止数据库和服务器端脚本错误被看到——这会使开发人员难以调试他们的应用程序！删除或隐藏安装在服务器 Web 根目录下的任何 Web 或应用程序服务器管理页面、脚本或文档，并确保替换那些默认主页。

我们不需要额外的服务

除了 HTTP 服务本身，许多用作 Web 服务器的计算机还托管着许多其他网络服务。也许最常见的是 FTP 和 SMTP。作为一般安全规则，尽量避免在您的 Web 服务器上运行这些服务。特别是，避免使用 Microsoft IIS 中的默认 FTP 和 SMTP 服务。尽管集成服务很方便，但没有理由将 Web、FTP 和 SMTP 服务相互关联。对于 Apache 来说，这不是问题，因为 Web 服务器不通过公共管理服务与 FTP 和 SMTP 服务相关联。如果您确实使用这些服务，请注意它们会公开您的 IIS 服务器的身份。

当与 SMTP 服务建立连接时，接收方服务器会向客户端发送一个人类可读的问候语，即“SMTP 欢迎信息”。SMTP 欢迎信息显示的内容对电子邮件服务没有影响，但与 HTTP Server 头信息一样，它会泄露有关计算机上运行的软件的详细信息。默认的 Windows SMTP 服务会暴露此类信息。要了解如何更改 SMTP 欢迎信息，请查看此处。

默认的 Microsoft IIS FTP 服务器也会显示一个已知的横幅。由于修改 FTP 横幅比修改 SMTP 横幅更复杂（计划破解几个系统 DLL），所以您最好的选择是使用替代的 FTP 服务器，例如 RhinoSoft 的 Serv-U FTP 服务器，它可以在 FTP 横幅中显示任何文本消息。此外，像 Serv-U 这样的第三方 FTP 服务器在安全措施方面比 IIS FTP 服务更具可配置性，例如为用户分配自己的登录目录。

不安全的输入

许多平台特定的漏洞利用复杂的 URL 字符串来获取对 shell 或 CGI 程序的访问权限，黑客可以通过这些程序轻松获取目录列表，从而揭示操作系统的默认文件结构。一旦 shell 或 CGI 程序被劫持并且文件系统被暴露，大门就完全敞开了。防御这种试错攻击的最佳方法是用户输入过滤器或“消毒器”，它可以从用户提供的数据中删除不可接受的字符（例如元字符及其各种可能的编码）。对于 IIS，当前的标准是 IISLockDown/URLScan。新一代的 应用程序防火墙 将这种保护扩展到 Web 服务器后面的应用程序层。在 Apache 世界中，用户输入净化传统上是 CGI 作者的责任。这是关于该主题的经典 CERT 文章，其中包含 Perl 和 C 的示例。如果您正在设置新机器，请考虑更改默认文件结构。输入净化和重新排列的文件结构具有双重作用——帮助伪装机器并同时中和常见的漏洞利用。

梳理堆栈

即使从您的 Web 服务器的应用程序层移除了所有识别标志，在较低的网络层仍然存在检测弱点。任何具有网络连接的服务器都有一个网络协议栈，可以被扫描和识别。最好的堆栈扫描器（例如来自 insecure.org 的 NMAP）可以通过使用各种技术来识别大多数操作系统，以对系统的 TCP 堆栈进行指纹识别。特定于操作系统的 IP 堆栈也容易通过 Internet 控制消息协议 (ICMP) 进行检测，该协议由流行的 Ping 工具使用。有关 ICMP 漏洞的良好资源可以在这里找到。针对这些类型的网络扫描漏洞的第一道防线是一个良好、管理得当的防火墙。但是，仔细的网络分析仍然可以通过检查防火墙必须允许 Web 服务器通过的响应 HTTP 请求的数据包来识别一台机器。

Netcraft 正在监视

查看 Netcraft 上的“这个网站运行什么？”工具。如果您将网站分析工具指向您自己的网站，它可能会正确报告您的 Web 服务器和操作系统。更改您的 HTTP Server 标头将导致 Netcraft 报告您的 Web 服务器的错误值——如果标头完全删除，则只报告“未知”（更改不是即时的，因为 Netcraft 会缓存结果一段时间）。

尽管如此，您的操作系统可能仍会被正确识别——即使在好的防火墙后面也是如此。要让 Netcraft 将您的操作系统报告为“未知”，您必须修改一些默认的 TCP/IP 设置，例如接收窗口大小 (RWIN)、最大传输单元 (MTU)、最大分段大小 (MSS) 和/或 IP 头生存时间 (TTL)。更改这些设置将以不同的方式影响服务器的性能，具体取决于网络条件，因此在更改这些默认设置时应格外小心。然而，在熟练的网络管理员手中，此策略可以有效对抗通过堆栈扫描进行的信息泄露。

外面小心

任何检测规避的组合都无法完全匿名化您的 Web 服务器——就像任何防火墙、IDS 和其他安全对策的组合都无法完全击败一个熟练而坚定的破解者一样。与服务器强化一样，服务器匿名化可以帮助击败大多数潜在攻击者。而且，就像网络安全的所有方面一样，这是一场永无止境的战斗，旨在领先于坏人。