下面列出的建议适用于所有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版）》。