Security Tips

有关设置 Web 服务器的安全性问题的一些提示和技巧。其中一些建议是笼统的，其他一些则是针对 Apache 的。

保持最新

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

当然，大多数情况下，Web 服务器受到威胁，并不是因为 HTTP Server 代码中的问题。而是来自附加代码，CGI 脚本或基础 os 的问题。因此，您必须始终注意系统上所有软件的问题和更新。

拒绝服务(DoS)攻击

所有 Web Service 器都可能遭受拒绝服务攻击，这些攻击试图通过占用服务器资源来阻止对 Client 端的响应。不可能完全阻止此类攻击，但是您可以做某些事情来减轻它们造成的问题。

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

还有一些 Apache HTTP Server 配置设置可以帮助缓解问题：

• RequestReadTimeout指令允许限制 Client 端发送请求所花费的时间。

• 在遭受 DoS 攻击的网站上，应降低TimeOut指令。将其设置为低至几秒钟可能是合适的。由于TimeOut当前用于几种不同的操作，因此将其设置为较低的值会导致长期运行的 CGI 脚本出现问题。

• 在遭受 DoS 攻击的网站上，KeepAliveTimeout指令也可能降低。有些网站甚至通过KeepAlive完全关闭了保持活动状态，这当然在性能上还有其他缺点。

• 应检查其他模块提供的与超时相关的各种指令的值。

• 应当仔细配置指令LimitRequestBody，LimitRequestFields，LimitRequestFieldSize，LimitRequestLine和LimitXMLRequestBody，以限制 Client 端 Importing 触发的资源消耗。

• 在支持该功能的 os 上，请确保使用AcceptFilter指令将部分请求处理卸载到 os。在 Apache httpd 中，默认情况下此功能是活动的，但可能需要重新配置内核。

• 调整MaxRequestWorkers指令以允许服务器处理最大数量的同时连接，而不会耗尽资源。另请参见性能调优文档。

• 使用线程mpm可以允许您处理更多同时连接，从而减轻 DoS 攻击。此外，eventmpm 使用异步处理来避免将线程专用于每个连接。由于 OpenSSL 库的性质，event mpm 当前与mod_ssl和其他 Importing 过滤器不兼容。在这些情况下，它会退回到worker mpm 的行为。

• http://modules.apache.org/提供了许多第三方模块，它们可以限制某些 Client 端行为，从而减轻 DoS 问题。

ServerRoot 目录的权限

在典型操作中，Apache 由 root 用户启动，并切换到User指令定义的用户以提供匹配。与 root 用户执行的任何命令一样，您必须注意防止非 root 用户修改它。文件本身不仅只能由 root 用户写入，而且目录以及所有目录的父目录也必须可以写入。例如，如果您选择将 ServerRoot 放置在/usr/local/apache中，则建议您使用以下命令将其创建为根目录：

mkdir /usr/local/apache cd /usr/local/apache mkdir bin conf logs chown 0 . bin conf logs chgrp 0 . bin conf logs chmod 755 . bin conf logs

假定/，/usr和/usr/local只能由 root 修改。安装httpd可执行文件时，应确保其受到类似的保护：

cp httpd /usr/local/apache/bin chown 0 /usr/local/apache/bin/httpd chgrp 0 /usr/local/apache/bin/httpd chmod 511 /usr/local/apache/bin/httpd

您可以创建一个 htdocs 子目录，该目录可被其他用户修改-因为 root 永远不会在其中执行任何文件，因此不应在其中创建文件。

如果您允许非 root 用户修改 root 执行或写入的任何文件，那么您将对 root 入侵打开系统。例如，有人可以替换httpd二进制文件，以便下次启动它时，它将执行一些任意代码。如果日志目录是可写的(非 root 用户)，则有人可以用与其他系统文件的符号链接替换日志文件，然后 root 可能会用任意数据覆盖该文件。如果日志文件本身是可写的(非 root 用户)，则有人可能会用伪造的数据覆盖日志本身。

服务器端包含

服务器端包含(SSI)为服务器 Management 员带来了一些潜在的安全风险。

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

通常，SSI 文件还具有与 CGI 脚本关联的相同风险。使用exec cmd元素，启用了 SSI 的文件可以在用户和 Apache 的运行组(如httpd.conf中配置)的许可下执行任何 CGI 脚本或程序。

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

为了隔离任性的 SSI 文件可能造成的损坏，服务器 Management 员可以按照一般的 CGI部分中的说明启用suexec。

为 extensions 为.html或.htm的文件启用 SSI 可能很危险。在共享或高流量的服务器环境中尤其如此。启用 SSI 的文件应具有单独的 extensions，例如常规.shtml。这有助于将服务器负载保持在最低水平，并简化风险 Management。

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

CGI 一般

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

所有 CGI 脚本都将以同一用户身份运行，因此它们有可能(偶然或故意)与其他脚本发生冲突。用户 A 讨厌用户 B，因此他编写了一个脚本来删除用户 B 的 CGI 数据库。 suEXEC是一个可用于允许脚本以不同用户身份运行的程序，它已包含在 Apache 自 1.2 起的版本中，并从 Apache 服务器代码中的特殊钩子中调用。另一种流行的方法是使用CGIWrap。

非脚本别名 CGI

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

• 您相信您的用户不要编写有意或无意使您的系统遭受攻击的脚本。

• 您认为站点的安全性在其他方面太弱了，以至于再也没有潜在的漏洞了。

• 您没有用户，也没有人访问您的服务器。

脚本别名 CGI

将 CGI 限制为特殊目录，使 Management 员可以控制进入这些目录的内容。这比非脚本别名的 CGI 不可避免地更安全，但是只有在对目录具有写访问权的用户受信任或者 Management 员愿意测试每个新的 CGI 脚本/程序中是否存在潜在的安全漏洞时，这种安全性才会提高。

大多数站点在非脚本别名 CGI 方法上选择此选项。

其他动态内容来源

作为服务器本身一部分运行的嵌入式脚本选项(例如mod_php，mod_perl，mod_tcl和mod_python)以服务器本身的身份运行(请参见User指令)，因此，由这些引擎执行的脚本可以访问任何服务器用户可以。某些脚本引擎可能会提供限制，但最好还是不要假设。

动态内容安全

设置动态内容(例如mod_php，mod_perl或mod_python)时，许多安全注意事项不在httpd本身的范围内，您需要从这些模块中查阅文档。例如，PHP 允许您设置Safe Mode，默认情况下通常禁用该功能。另一个示例是Suhosin，这是一个用于提高安全性的 PHP 插件。有关这些的更多信息，请查阅每个项目文档。

在 Apache 级别上，可以将名为mod_security的模块视为 HTTP 防火墙，并且只要对其进行了足够精细的配置，就可以帮助您增强动态内容的安全性。

保护系统设置

要运行一个非常严格的版本，您将希望阻止用户设置.htaccess文件，这些文件可以覆盖您已配置的安全功能。这是一种方法。

在服务器配置文件中，放入

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

除了专门启用的目录之外，这可以防止在所有目录中使用.htaccess文件。

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

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

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

例如，考虑以下示例：

# cd /; ln -s / public_html Accessing http://localhost/~root/

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

<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指令玩游戏；将其设置为类似./的效果，对于根来说，与上面的第一个示例相同。我们强烈建议您在服务器配置文件中包括以下行：

UserDir disabled root

查看日志

要了解服务器上实际发生的最新情况，您必须检查Log Files。即使日志文件仅报告已发生的事件，它们也可以使您了解对服务器进行的攻击，并允许您检查是否存在必要的安全级别。

几个例子：

grep -c "/jsp/source.jsp?/jsp/ /jsp/source.jsp??" access_log grep "client denied" error_log | tail -n 10

第一个示例将列出尝试利用Apache Tomcat Source.JSP 格式错误的请求信息泄露漏洞的攻击数量，第二个示例将列出最后十个被拒绝的 Client 端，例如：

[Thu Jul 11 17:18:39 2002] [error] [client foo.example.com] client denied by server configuration: /usr/local/apache/htdocs/.htpasswd

如您所见，日志文件仅报告已发生的事情，因此，如果 Client 端能够访问.htpasswd文件，您将看到类似以下内容：

foo.example.com - - [12/Jul/2002:01:59:13 +0200] "GET /.htpasswd HTTP/1.1"

在您的Access Log中。这意味着您可能在服务器配置文件中 Comments 了以下内容：

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

合并配置部分

配置节的合并很复杂，有时是特定于指令的。创建有关如何合并指令的依赖项时，请始终测试更改。

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