下面列出的建议适用于所有Web平台,无论它是现成的还是自定制的。
执行严格的双向网络访问控制
    我们认为在因特网的现今阶段,就不用再强调对Web服务器的入站通信进行严格防火墙过滤的必要性了。TCP端口80(如果你实现了SSL/TLS,还有443端口)应该是一般访问者在入站时唯一可以访问的端口(显然,特定的用户通信,比如内容管理,服务器管理等,可能需要访问其他特殊的端口)。
    虽然入站的过滤被广泛应用,但我们经常看到的一个错误是忽略了对出站的访问控制。一旦***者获得了在Web服务器上运行任意命令的权限,他首先要做的事情是得到一个出站Shell,或者创建出站的连接来上传更多的文件到受害机上。在Web服务器前端防火墙上,进行正确的出站过滤,可以阻止这些请求,从而从根本上阻止***者。最简单的规则是保留已经建立的连接,拒绝所有其他的出站连接,这可以通过保留有TCP SYN标志的包而阻止其他包来实现。这样不会阻止对合法请求的响应,服务器仍然可以被外部访问到(你的入站过滤器也是很严格的,对吧?)
请注意很重要的一点是,老练的***者可能会劫持合法的出站连接,来绕过出站过滤。但是,依据我们的经验,在实际中是很难做到的。严格的出站访问控制,是你可以为Web服务器建立的重要防范层。
及时更新安全补丁
    保持Web平台强健和安全的最有效方法,是随时保持系统更新最新的安全补丁。你必须不断地为你的平台和应用程序打上补丁,没有什么捷径可言。虽然这里还有很多其他的步骤可以用来加固你的系统以避免***,但是就像宣传的那样,及时更新系统的安全设置是你能做的最重要的事情。我们建议使用自动升级工具,比如微软更新服务,来帮助你保证获取最新的补丁。对于Apache来说,只需订阅Apache公告列表,就可以在新版本发布的时候得到通知,从而进行更新(其链接请查看本章末尾的“参考和进一步阅读”一节)。
不要在源代码中放置私密信息
    如果教导你的开发团队不犯此类错误,你就不用太担心最新、最严重的源代码泄漏会传遍***圈。这一类常见的错误包括:
    在ASP脚本中用明文SQL连接字符串  使用SQL集成安全或一个二进制的COM对象来代替。
    在应用配置文件中使用明文密码  在诸如global.asa或web.config应用程序配置文件中,永远不要使用明文密码。
    使用以.inc为扩展名的包含文件  把它们改名为.asp,并在其他脚本中改变对应的内部引用(或者像本章前面描述的那样,把.inc映射到ASP扩展)。
    在脚本中的注释中包含诸如E-mail地址、目录结构信息和密码等私密信息  不要把你自己放到如此高危的环境中,确认删除了会对自己不利的Web平台信息和应用程序信息。
定期为易受到***的服务器进行网络扫描
    防范***的最佳机制是定期进行漏洞扫描。这里有很多非常有效的检测Web应用程序的产品,比如SPI Dynamics的WebInspect,Watchfire的AppScan。对于识别Web平台漏洞和应用层漏洞,它们都非常棒。
!提示  关于自动化Web安全评估工具的评测,请查看第13章。
能判断自己是否受到了***
    应急响应措施就像防范措施一样重要,对于易受***的Web服务器来说更是如此。为了确认你的服务器是否已经成为了目录遍历***的受害者,我们推荐如下指定的调查行动,这包括了如下的经典技术。
    在受到***的Web服务器上使用Netstat程序,是确认任何连到Web服务器高端口的陌生入站连接的好办法。就像我们已经看到的那样,在漏洞被利用之后,可能随后有连接到流氓Shell实例。但是,要把出站连接和Web客户端的合法连接区分开有点困难。
!提示  在WindowsXP之后(包括XP)的版本,netstat命令做了修改,可以用-o选项显示使用TCP/IP端口的程序。
    另一个不错的调查切入点是文件系统。大量现成的***代码在因特网上流传。那里有很多与***相关的文件,它们最初是由很严肃的安全研究人员发布的,却常常被脚本小子完全重用。举个例子来说,在IIS上,诸如Sensepost.exe,Upload.asp,Upload.inc和Cmdasp.asp等文件都是常见的系统后门。虽然只是简单地重命名,但至少可以防范脚本小子的***。特别要注意诸如IIS的/script这类可写/可执行文件夹下的文件。另一种常见的情况是,IIS***代码常常带有root.exe(重命名后的命令行shell),e.asp,dl.exe,reggina.exe,regit.exe,restsec.exe,makeini.exe,newgina.dll,firedaemon.exe,mmtask.exe,sud.exe和sud.bak等文件。一定要留心它们!
    最后,也可能是最显眼的,首先显示未授权行为的地方常常是Web服务器日志(在本章的前面,我们已经讨论过日志绕过技术)。下面,我们举一个简单的例子,说明如何发现Code Red和Nimda蠕虫对服务器的访问。2001年末到2002年,Code Red和Nimda蠕虫在Internet上横行,它们感染带有缓冲区溢出漏洞的服务器,植入代码,然后继续感染其他的服务器。在Code Red感染的服务器上,Web服务器日志包含了像下面这样的项:
GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
NNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090
%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff
%u0078%u0000%u00=a
    Code Red和Nimda也会在受***的系统上留下很多文件。出现%systemdrive%\notworm目录是服务器已经被Code Red***的明显标记。如果存在已被重命名的叫做root.exe的Windows命令行shell,那也是Nimda曾访问过机器的标记。
    我们明白,即使在一个规模不大的Web服务器上定期监视日志和文件系统,都需要很大的精力。但是,我们希望一旦发现服务器已经受到***,这些提示可以帮助你。
 
本文节选自电子工业出版社2008年6月出版的《***大曝光——Web应用安全机密与解决方案(第2版)》