安全提示

保持最新

Apache HTTP 服务器在安全方面拥有良好的记录，并且开发人员社区高度关注安全问题。但不可避免的是，在软件发布后，会发现一些问题 - 大小不一。因此，了解软件更新至关重要。如果您直接从 Apache 获得了 HTTP 服务器版本，我们强烈建议您订阅 Apache HTTP 服务器公告列表，以便了解新版本和安全更新。大多数 Apache 软件的第三方分发商也提供类似的服务。

当然，大多数情况下，Web 服务器被入侵并非因为 HTTP 服务器代码中的问题。而是来自附加代码、CGI 脚本或底层操作系统中的问题。因此，您必须了解系统上所有软件的问题和更新。

拒绝服务 (DoS) 攻击

所有网络服务器都可能受到拒绝服务攻击，这些攻击试图通过占用服务器资源来阻止对客户端的响应。无法完全阻止此类攻击，但您可以采取一些措施来减轻它们带来的问题。

通常，最有效的反 DoS 工具将是防火墙或其他操作系统配置。例如，大多数防火墙可以配置为限制来自任何单个 IP 地址或网络的并发连接数量，从而阻止一系列简单的攻击。当然，这对于分布式拒绝服务攻击 (DDoS) 毫无帮助。

还有一些 Apache HTTP 服务器配置设置可以帮助减轻问题

• RequestReadTimeout 指令允许限制客户端发送请求所需的时间。
• TimeOut 指令应在容易受到 DoS 攻击的站点上降低。将其设置为几秒钟可能很合适。由于 TimeOut 目前用于多种不同的操作，因此将其设置为较低的值会导致长时间运行的 CGI 脚本出现问题。
• KeepAliveTimeout 指令也可能在容易受到 DoS 攻击的站点上降低。某些站点甚至通过 KeepAlive 完全关闭了 Keepalives，这当然会对性能产生其他不利影响。
• 应检查其他模块提供的各种超时相关指令的值。
• 指令 LimitRequestBody、LimitRequestFields、LimitRequestFieldSize、LimitRequestLine 和 LimitXMLRequestBody 应仔细配置，以限制由客户端输入触发的资源消耗。
• 在支持的操作系统上，确保使用 AcceptFilter 指令将部分请求处理卸载到操作系统。这在 Apache httpd 中默认处于活动状态，但可能需要重新配置内核。
• 调整 MaxRequestWorkers 指令，以允许服务器处理最大数量的并发连接，而不会耗尽资源。另请参阅 性能调整文档。
• 使用线程化的 mpm 可能会允许您处理更多并发连接，从而减轻 DoS 攻击。此外，event mpm 使用异步处理来避免为每个连接分配一个线程。
• 有许多可用的第三方模块可以限制某些客户端行为，从而减轻 DoS 问题。

ServerRoot 目录的权限

在典型操作中，Apache 由 root 用户启动，并切换到由 User 指令定义的用户以提供命中。与 root 执行的任何命令一样，您必须注意保护它免受非 root 用户的修改。不仅文件本身必须只能由 root 写入，目录和所有目录的父目录也必须如此。例如，如果您选择将 ServerRoot 放置在 /usr/local/apache 中，那么建议您以 root 身份创建该目录，并使用以下命令：

假设 /、/usr 和 /usr/local 只能由 root 修改。当您安装 httpd 可执行文件时，您应该确保它也受到类似的保护

您可以创建一个 htdocs 子目录，该目录可以由其他用户修改 - 因为 root 从未执行过任何文件，也不应该在其中创建文件。

如果您允许非 root 用户修改 root 执行或写入的任何文件，那么您将使系统面临 root 攻击的风险。例如，某人可以替换 httpd 二进制文件，以便下次您启动它时，它将执行一些任意代码。如果日志目录可写（由非 root 用户），某人可以将日志文件替换为指向其他系统文件的符号链接，然后 root 可能会用任意数据覆盖该文件。如果日志文件本身可写（由非 root 用户），那么某人可能能够用虚假数据覆盖日志本身。

服务器端包含

服务器端包含 (SSI) 为服务器管理员带来了几个潜在的安全风险。

第一个风险是服务器负载增加。所有启用 SSI 的文件都必须由 Apache 解析，无论文件中是否包含任何 SSI 指令。虽然这种负载增加很小，但在共享服务器环境中，它可能会变得很大。

SSI 文件还存在与 CGI 脚本相关的相同风险。使用 exec cmd 元素，启用 SSI 的文件可以以 Apache 运行的用户和组的权限执行任何 CGI 脚本或程序，如 httpd.conf 中配置的那样。

有一些方法可以增强 SSI 文件的安全，同时仍然利用它们提供的优势。

为了隔离一个不正常的 SSI 文件可能造成的损害，服务器管理员可以启用 suexec，如 CGI 通用 部分所述。

为具有 .html 或 .htm 扩展名的文件启用 SSI 可能很危险。这在共享或高流量的服务器环境中尤其如此。启用 SSI 的文件应该具有单独的扩展名，例如传统的 .shtml。这有助于将服务器负载保持在最低限度，并允许更轻松地管理风险。

另一个解决方案是禁用从 SSI 页面运行脚本和程序的能力。为此，请在 Options 指令中将 Includes 替换为 IncludesNOEXEC。请注意，如果这些脚本位于由 ScriptAlias 指令指定的目录中，用户仍然可以使用 <--#include virtual="..." --> 来执行 CGI 脚本。

CGI 通用

首先，您必须始终记住，您必须信任 CGI 编写者的脚本/程序，或者您有能力发现 CGI 中的潜在安全漏洞，无论它们是故意的还是意外的。CGI 脚本可以在您的系统上以 Web 服务器用户的权限运行本质上任意的命令，因此如果它们没有经过仔细检查，它们可能非常危险。

所有 CGI 脚本都将以相同用户身份运行，因此它们有可能（意外或故意）与其他脚本发生冲突，例如用户 A 讨厌用户 B，因此他编写了一个脚本来破坏用户 B 的 CGI 数据库。一个可以用来允许脚本以不同用户身份运行的程序是 suEXEC，它从 Apache 1.2 开始包含在 Apache 中，并从 Apache 服务器代码中的特殊钩子调用。另一种流行的方法是使用 CGIWrap。

非脚本别名 CGI

只有在以下情况下才应考虑允许用户在任何目录中执行 CGI 脚本：

• 您信任您的用户不会编写故意或意外地将您的系统暴露于攻击的脚本。
• 您认为您网站的安全漏洞非常多，以至于多一个潜在漏洞无关紧要。
• 您没有用户，也没有人访问您的服务器。

脚本别名 CGI

将 CGI 限制在特殊目录中，可以让管理员控制这些目录中的内容。这必然比非脚本别名 CGI 更安全，但前提是拥有这些目录写入权限的用户是可信的，或者管理员愿意测试每个新的 CGI 脚本/程序是否存在潜在的安全漏洞。

大多数网站选择此选项而不是非脚本别名 CGI 方法。

其他动态内容来源

作为服务器本身一部分运行的嵌入式脚本选项，例如 mod_php、mod_perl、mod_tcl 和 mod_python，在服务器本身的身份下运行（参见 User 指令），因此由这些引擎执行的脚本可能访问服务器用户可以访问的任何内容。一些脚本引擎可能提供限制，但最好安全起见，假设没有限制。

动态内容安全

在设置动态内容（例如 mod_php、mod_perl 或 mod_python）时，许多安全注意事项超出了 httpd 本身的范围，您需要参考这些模块的文档。例如，PHP 允许您设置 安全模式，该模式通常默认情况下是禁用的。另一个例子是 Suhosin，这是一个用于增强安全的 PHP 插件。有关这些内容的更多信息，请参考每个项目的文档。

在 Apache 级别，一个名为 mod_security 的模块可以被视为一个 HTTP 防火墙，如果您对其进行足够精细的配置，它可以帮助您增强动态内容安全。

保护系统设置

要真正严格地控制，您需要阻止用户设置可以覆盖您已配置的安全功能的 .htaccess 文件。以下是一种方法。

在服务器配置文件中，添加以下内容：

<Directory "/">
    AllowOverride None
</Directory>

这将阻止在所有目录中使用 .htaccess 文件，除了那些明确启用的目录。

请注意，此设置是 Apache 2.3.9 后的默认设置。

默认情况下保护服务器文件

Apache 的一个偶尔会被误解的方面是默认访问功能。也就是说，除非您采取措施进行更改，否则如果服务器可以通过正常的 URL 映射规则找到文件，它就可以将其提供给客户端。

例如，考虑以下示例：

这将允许客户端遍历整个文件系统。要解决此问题，请将以下代码块添加到您的服务器配置中：

<Directory "/">
    Require all denied
</Directory>

这将禁止对文件系统位置的默认访问。添加适当的 Directory 代码块，以仅允许您希望访问的区域访问。例如：

<Directory "/usr/users/*/public_html">
    Require all granted
</Directory>
<Directory "/usr/local/httpd">
    Require all granted
</Directory>

请特别注意 Location 和 Directory 指令之间的交互；例如，即使 <Directory "/"> 拒绝访问， <Location "/"> 指令也可能会推翻它。

还要注意使用 UserDir 指令进行的操作；将其设置为类似 ./ 的内容，对于 root 来说，将与上面的第一个示例具有相同的效果。我们强烈建议您在服务器配置文件中包含以下行：

UserDir disabled root

监视日志

要了解服务器上实际发生的情况，您必须检查 日志文件。即使日志文件只记录已发生的事情，它们也能让您了解针对服务器发起的攻击，并让您检查是否存在必要的安全级别。

以下是一些示例：

第一个示例将列出尝试利用 Apache Tomcat Source.JSP 畸形请求信息泄露漏洞 的攻击次数，第二个示例将列出最后十个被拒绝的客户端，例如：

如您所见，日志文件只记录已发生的事情，因此如果客户端能够访问 .htpasswd 文件，您将看到类似以下内容：

在您的 访问日志 中。这意味着您可能在服务器配置文件中注释掉了以下内容：

<Files ".ht*">
    Require all denied
</Files>

配置部分的合并

配置部分的合并很复杂，有时还与指令有关。在创建对指令合并方式的依赖关系时，始终测试您的更改。

对于没有实现任何合并逻辑的模块，例如 mod_access_compat，后面部分的行为取决于后面部分是否包含来自该模块的任何指令。配置将被继承，直到进行更改，此时配置将被替换，而不是合并。