编辑“Apache的安全方面的提示”

== 保持不断更新和升级 ==

[[Apache]] HTTP服务器有一个很好的安全记录和一个高度关注安全问题的开发社团。但是这仍然不能避免在发行版中存在或大或小的问题。所以知道这个软件的版本更新和升级补丁是至关重要的。如果你是直接从Apache组织得到Apache HTTP服务器的，我们强烈建议你订阅Apache HTTP服务器通告邮件列表以保证能够在第一时间得知软件的版本更新和升级补丁。许多第三方Apache软件发行版也有类似的服务。<br>

当然，Web服务器出现的问题在绝大多数时候不是由Apache源代码引起的，而是由附加的代码、[[CGI]]脚本、底层操作系统引起的。因此你必须保持机器上所有软件的及时更新。<br>


----


== ServerRoot目录的权限 ==

通常，Apache由root用户启动，在提供服务时切换为由User指令所指定的用户。正如root所执行的任何命令那样，你必须保证ServerRoot下的文件是受保护的，不允许非root用户对它修改。不仅文件本身，而且目录及其父目录都必须只能由root来改写。例如，如果将ServerRoot指定为/usr/local/apache ，则推荐以root身份来建立此目录，如：<br>

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

这里已经假定了"/"、"/usr"、"/usr/local"只能由root来改写。在安装httpd可执行文件时，应该确保它也受到了同样的保护：<br>

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

你可以在其中建立htdocs子目录，该子目录可以允许其他用户改写 -- root不会执行其中任何文件，也不应该在其中建立文件。<br>

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


----

== 服务器端包含 ==

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

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

[[SSI]]文件与CGI脚本一样存在风险。使用"exe ccmd"元素，允许SSI的文件可以执行任何CGI脚本，以及由httpd.conf设置的执行Apache的用户或组所允许执行的任何程序。<br>

有若干方法可以在得到SSI好处的同时提高SSI文件的安全性。<br>

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

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

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



----

== 关于CGI ==

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

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

'''未指定为脚本的CGI''' 

仅在下列情况下，可以考虑允许用户执行位于任意目录中的CGI脚本：<br>

你绝对信任用户不会写一些有意无意会使系统遭受攻击的脚本。 <br>
你认为安全因素与其他因素相比显得不那么重要，存在一两个潜在漏洞也无关紧要。 <br>
你没有用户，而且没人会来访问你的服务器。 <br>
'''指定为脚本的CGI'''

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

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


----


== 其他动态内容的来源 ==

嵌入在Apache中作为模块运行的脚本解释器，比如：mod_php, mod_perl, mod_tcl, mod_python 将会使用和Apache一样的用户身份运行(参见User指令)，所以被这些模块执行的脚本可能访问任何Apache服务器能够访问的对象。一些脚本引擎可能提供了某些方面的限制，但是最好在假定他们并不存在的前提下做好安全防护。<br>


----


== 系统设置的保护 ==

为了得到真正严密的保护，应该禁止用户使用可能导致安全特性被覆盖的.htaccess文件，方法是在服务器配置文件中设置：<br>

<Directory /> <br>
AllowOverride None <br>
</Directory> <br>

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



----

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

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

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

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

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

这样，对文件系统的默认访问被禁止。而对需要访问的区域，可以增加正确的Directory块，比如：<br>

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

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

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

UserDir disabled root <br>


----


== 观察日志文件 ==

要了解服务器上发生了什么，就必须检查日志文件。虽然日志文件只是记录已经发生的事件，但是它会让你知道服务器遭受的攻击，并帮助你判断是否提达到了必要的安全等级。<br>

一些例子：<br>

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

上例会列出试图使用Apache Tomcat Source.JSP Malformed Request Information Disclosure Vulnerability的攻击次数。下例会列出最后十个被拒绝的客户端：<br>

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

可见，日志文件只是记录已经发生的事件，所以，如果客户端可以访问.htpasswd文件，而且在访问日志中发现类似如下的记录：<br>

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

这可能表示服务器配置文件中的下列指令已经被注解了：<br>

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


----

== 解决Apache服务器日志文件日益增大的办法 ==


Apache 的日志默认是直接写入一个独立的 log 文件。如果网站流量大，日志文件很快就会变得很庞大；而 AWStats 等日志分析软件，要求日志文件以天的格式保存。cronolog 正好可以解决这个问题：它可以对 Apache 的日志按需要进行截断处理（cronolog 也是Apache推荐使用的日志工具之一），是使用 AWStats 进行日志分析的基础。 <br>

这里简单地说明一下 cronolog 在 Windows + Apache 下的安装： <br>

1. 首先到 cronolog 的网站 http://www.cronolog.org/下载。注意应该下载 Win 32 version (ZIP file) 的版本。目前最新的 win 32 version 是 1.6.1。 <br>

2. 将 zip 文件下载之后，将 cronolog.exe　解压并复制到 Apache 的 bin 目录 <br>

3. 在 apache 的配置文件 httpd.conf 中,　修改以下代码： <br>
4. CustomLog "|bin/cronolog.exe logs/access_%Y%m%d.log" combined <br>
ErrorLog "|bin/cronolog.exe logs/error_%Y%m%d.log" <br>
也可以在虚拟主机配置中使用，例如： <br>
＜VirtualHost *:80＞ <br>
ServerName www.xxx.com <br>
CustomLog "|bin/cronolog.exe logs/xxx.com/access_%Y%m%d.log" combined <br>
ErrorLog "|bin/cronolog.exe logs/xxx.com/error_%Y%m%d.log" <br>
＜/VirtualHost＞ <br>
5. 重新启动 Apache. <br>

6. 其他设置说明，请见下载包中的 README 文件。<br>

[[category:Apache]]