Apache 2.0手册中文版翻译项目 [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版

 


安全方面的提示 - Apache HTTP服务器
<-
Apache主站 > HTTP服务器 > 文档 > 2.0版本 > Miscellaneous Documentation

安全方面的提示


现有的语种:  en 

本文中的提示和技巧有些是针对网络服务器的建立的, 有些是综合性的,其余的则是针对Apache的。

top

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执行或读写的文件有写权限,则会危及系统。 比如,别人有可能会覆盖httpd的执行文件, 那么下一次启动时,就会执行任意的代码。 如果日志目录(对一个非root用户)是可写的, 别人就有可能用一个指向其他系统文件的连接来覆盖日志文件, 使那个文件被改写为杂乱的数据。 如果日志文件本身是可写的,别人就可能伪造其记录。

top

服务器端包含

服务器端包含(SSI)会带来一些潜在的安全隐患。

首先是增加了服务器的负载。 Apache必须解析所有允许SSI的文件,而无论其中是否包含SSI指令。 虽然增加的负载较小,但是在共享服务器环境中会变得很显著。

SSI文件与CGI脚本一样存在风险。 使用"exec cmd",允许SSI的文件得以执行任何CGI脚本, 以及由httpd.conf设置的执行Apache的用户或组所允许执行的任何程序。

有若干方法可以在得其利的同时提高SSI文件的安全性。

服务器管理员可以使用有关CGI中所描述的suexec,以隔离野蛮SSI文件所造成的破坏。

对.html或.htm后缀的文件都允许SSI是危险的, 尤其是在一个共享的高流量的服务器环境中。 允许SSI的文件应该有一个独立的后缀,比如常规的.shtml, 使服务器负载保持在最低水平,并使风险管理更容易。

另一个方案是,关闭SSI页面执行脚本和程序的功能,即, 在用Options指令中, 用IncludesNOEXEC替换Includes。 注意,用户仍然可以使用<--#include virtual="..." -->来执行位于ScriptAlias指令所指定的目录中的CGI脚本。

top

有关CGI

首先,你不得不信任CGI脚本/程序的作者以及你自己的发现CGI中潜在安全漏洞的能力, 而无论这些漏洞是有预谋的或者仅仅是意外。 CGI脚本可以执行网络服务器执行身份所允许执行的任意系统命令, 如果没有经过仔细的检查,这可能是极其危险的。

由于所有CGI脚本都以相同的身份执行,所以可能会和其他脚本(有意或无意地)冲突。 比如,用户A憎恨用户B,因此他就可能写一个脚本去破坏用户B的数据库。 suEXEC是一个允许脚本以不同的身份运行的程序, 它包含在Apache 1.2以后的版本中,并被Apache服务器代码中特殊的挂钩所调用。 还有一种常用的方法是,使用CGIWrap.

top

未指定为脚本的CGI

仅在下列情况下,可以考虑允许用户执行位于任意目录中的CGI脚本:

top

指定为脚本的CGI

把CGI集中在特定的目录中,并由管理员决定其中的内容。 这样绝对比使用不作为脚本的CGI来得安全, 除非对这些目录有写权限的用户被信任, 或者管理员希望对每个CGI脚本/程序进行潜在安全漏洞测试。

大多数站点都选择这种方案,而不使用未指定为脚本的CGI。

top

系统设置的保护

为了得到真正严密的保护, 应该禁止用户使用可能导致安全特性被覆盖的.htaccess文件,方法是:

在服务器配置文件中,设置

<Directory />
AllowOverride None
</Directory>

使所有目录无法使用.htaccess文件,明确指定可以使用的目录除外。

top

默认配置下服务器文件的保护

默认访问是偶尔会被误解的Apache特性之一。即,除非你采取措施, 否则,如果服务器能够通过标准URL映射规则找到一个文件,那么就可能把它提供给客户端。

比如下例:

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

它会允许客户端遍历整个文件系统。 其解决方法是,在服务器配置中增加下列指令:

<Directory />
Order Deny,Allow
Deny from all
</Directory>

如此,对文件系统的默认访问被禁止。 而对需要访问的区域,可以增加正确的Directory块,如:

<Directory /usr/users/*/public_html>
Order Deny,Allow
Allow from all
</Directory>
<Directory /usr/local/httpd>
Order Deny,Allow
Allow from all
</Directory>

必须予以特别注意LocationDirectory指令的相互作用, 比如,即使<Directory />拒绝访问, <Location />指令仍然可能推翻其设置。

还必须留意UserDir指令, 此设置如果类似"./",则与上述例子有相同的风险。 如果你使用的是1.3或更高版本,我们强烈建议在服务器配置文件中包含以下指令:

UserDir disabled root

top

观察日志文件

要了解服务器上发生了什么,就必须检查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 Malformed Request Information Disclosure Vulnerability的攻击次数。 下例会列出最后十个被拒绝的客户端:

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

可见,日志文件只是记录已经发生的事件, 所以,如果客户端可以访问.htpasswd文件, 而且在Access Log发现类似如下的记录:

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

这可能表示服务器配置文件中的下列指令被注解了:

<Files ~ "^\.ht">
Order allow,deny
Deny from all
<Files>

现有的语种:  en 

 


项目维护者: kajaa [本文译者: kajaa * ]

项目说明 | 项目进度 | 项目讨论区 | Apache手册中文版