安全提示

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

保持最新

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

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

拒绝服务（DoS）攻击

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

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

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

该RequestReadTimeout指令允许限制客户端发送请求所花费的时间。
TimeOut在遭受DoS攻击的站点上，该指令应降低。将其设置为低至几秒钟可能是适当的。正如TimeOut当前用于几种不同操作的方法一样，将其设置为较低的值会导致长期运行的CGI脚本出现问题。
在KeepAliveTimeout遭受DoS攻击的站点上，该指令也可能降低。有些站点甚至通过完全关闭了keepalive KeepAlive，这当然在性能上还有其他缺点。
应检查其他模块提供的与超时相关的各种指令的值。
该指令LimitRequestBody，LimitRequestFields，LimitRequestFieldSize，LimitRequestLine，并LimitXMLRequestBody应仔细配置为通过客户端输入触发限制资源消耗。
在支持它的操作系统上，请确保使用AcceptFilter指令将请求处理的一部分卸载到操作系统上。在Apache httpd中，默认情况下此功能是活动的，但可能需要重新配置内核。
调整MaxRequestWorkers指令以允许服务器处理最大数量的同时连接而不会耗尽资源。另请参阅性能调整文档。
使用线程式mpm可能使您可以处理更多同时连接，从而减轻DoS攻击。此外，eventmpm使用异步处理来避免将线程专用于每个连接。由于OpenSSL库的性质，eventmpm当前与mod_ssl和其他输入过滤器不兼容。在这些情况下，它会退回到workerMPM 的行为。
通过http://modules.apache.org/提供的许多第三方模块可以限制某些客户端行为，从而减轻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）为服务器管理员带来了一些潜在的安全风险。

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

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

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

为了隔离任性的SSI文件可能造成的损坏，服务器管理员可以按照CGI中“常规”部分中的说明启用suexec。

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

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

一般的CGI

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

所有CGI脚本都将以同一用户身份运行，因此它们有可能（偶然或故意）与其他脚本发生冲突，例如，用户A讨厌用户B，因此他编写了一个脚本来丢弃用户B的CGI数据库。suEXEC是一个可用于允许脚本以不同用户身份运行的程序，它自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映射规则找到其到达文件的方式，则可以将其提供给客户端。

例如，考虑以下示例：

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

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

<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

看你的日志

为了及时了解服务器上实际发生的情况，您必须检查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格式错误的请求信息泄露漏洞的攻击数量，第二个示例将列出最后十个被拒绝的客户端，例如：

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

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

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

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

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

合并配置部分

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

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