有关设置Web服务器的安全问题的一些提示和技巧。一些建议通用的，其他建议特定于Apache版本。 保持最新 Apache HTTP Server具有良好的安全记录和高度关注安全问题的开发人员社区。但是，在软件发布之后，软件中会发现一些小问题或大问题是不可避免的。因此，了解软件更新至关重要。如果是直接从Apache获得了HTTP Server的版本，我们强烈建议您订阅Apache HTTP Server公告列表，以便随时了解新版本和安全更新。大多数Apache软件的第三方分销商都提供类似的服务。 当然，大多数情况下Web服务器受到攻击，并不是因为HTTP Server代码中存在问题。相反，它来自附加代码，CGI脚本或底层操作系统中的问题。因此，您必须了解系统中所有软件的问题和更新。 拒绝服务(DoS)攻击 所有网络服务器都可能遭受拒绝服务攻击，这些攻击试图通过占用服务器的资源来阻止对客户端的响应。不可能完全阻止此类攻击，但可以做某些事情来缓解这些问题。 通常，最有效的反DoS工具将是防火墙或其他操作系统配置。例如，大多数防火墙可以配置为限制来自任何单个IP地址或网络的同时连接数，从而防止一系列简单攻击。当然，这对分布式拒绝服务攻击(DDoS)没有帮助。 还有一些Apache HTTP Server配置设置可以帮助缓解问题： RequestReadTimeout指令允许限制客户端发送请求所花费的时间。 应该在受到DoS攻击的站点上降低TimeOut指令。将其设置为低至几秒可能是合适的。由于TimeOut当前用于多个不同的操作，因此将其设置为较低值会导致长时间运行的CGI脚本出现问题。 KeepAliveTimeout指令也可能会在受到DoS攻击的网站上降低。有些网站甚至通过KeepAlive完全关闭了Keepalive，这当然还有其他性能上的缺点。 应检查其他模块提供的各种超时相关指令的值。 应仔细配置LimitRequestBody，LimitRequestFields，LimitRequestFieldSize，LimitRequestLine和LimitXMLRequestBody指令，以限制客户端输入触发的资源消耗。 在支持它的操作系统上，确保使用AcceptFilter指令将部分请求处理卸载到操作系统。这在Apache httpd中默认是活动的，但可能需要重新配置内核。 调整MaxRequestWorkers指令以允许服务器处理最大数量的并发连接，而不会耗尽资源。 使用线程mpm可以让您处理更多的同时连接，从而减轻DoS攻击。此外，事件mpm使用异步处理来避免将线程用于每个连接。由于OpenSSL库的性质，事件mpm当前与mod_ssl和其他输入过滤器不兼容。在这些情况下，它会回落到工人mpm的行为。 通过http://modules.apache.org/可以使用许多第三方模块，这些模块可以限制某些客户端行为，从而缓解DoS问题。 ServerRoot目录的权限 在典型操作中，Apache由root用户启动，并切换到User指令定义的用户以提供命中。与root执行的任何命令一样，必须注意保护它免受非root用户的修改。文件本身不仅必须只能由root写入，而且目录和所有目录的父项也必须可写。例如，如果选择将ServerRoot放在/usr/local/apache中，则建议以root身份创建该目录，其命令如下： ``` 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二进制文件，以便下次启动它时，它将执行一些任意代码。如果logs目录是可写的(由非root用户)，则有人可以使用符号链接将日志文件替换为某个其他系统文件，然后root可能会使用任意数据覆盖该文件。如果日志文件本身是可写的(由非root用户)，那么有人可能能够用伪造的数据覆盖日志本身。 服务器端包含 服务器端包含(SSI)为服务器管理员提供了若干潜在的安全风险。 第一个风险是服务器上的负载增加。无论文件中是否包含任何SSI指令，所有启用SSI的文件都必须由Apache解析。虽然这种负载增加很小，但在共享服务器环境中，它可能会变得很重要。 SSI文件通常也会带来与CGI脚本相关的风险。使用exec cmd元素，启用SSI的文件可以在用户和Apache运行的组的权限下执行任何CGI脚本或程序，如httpd.conf中所配置的那样。 有一些方法可以增强SSI文件的安全性，同时仍然利用它们提供的好处。 要隔离任意SSI文件可能导致的损坏，服务器管理员可以启用suexec。 为具有.html或.html扩展名的文件启用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服务器代码中的特殊钩子调用的。另一种流行的方法是使用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 "/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 ``` 查看日志 要及时了解服务器的实际情况，需要检查日志文件。即使日志文件仅报告已发生的事件，它们也会让您了解针对服务器的攻击，并用于检查是否存在必要的安全级别。 参考几个例子： ``` 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，后面部分中的行为取决于后一部分是否具有来自模块的任何指令。继承配置，直到进行更改，此时配置被替换而不是合并。