下面列出的建議適用於所有Web平臺，無論它是現成的還是自定製的。
執行嚴格的雙向網絡訪問控制
我們認爲在因特網的現今階段，就不用再強調對Web服務器的入站通信進行嚴格防火牆過濾的必要性了。TCP端口80（如果你實現了SSL/TLS，還有443端口）應該是一般訪問者在入站時唯一可以訪問的端口（顯然，特定的用戶通信，比如內容管理，服務器管理等，可能需要訪問其他特殊的端口）。
雖然入站的過濾被廣泛應用，但我們經常看到的一個錯誤是忽略了對出站的訪問控制。一旦***者獲得了在Web服務器上運行任意命令的權限，他首先要做的事情是得到一個出站Shell，或者創建出站的連接來上傳更多的文件到受害機上。在Web服務器前端防火牆上，進行正確的出站過濾，可以阻止這些請求，從而從根本上阻止***者。最簡單的規則是保留已經建立的連接，拒絕所有其他的出站連接，這可以通過保留有TCP SYN標誌的包而阻止其他包來實現。這樣不會阻止對合法請求的響應，服務器仍然可以被外部訪問到（你的入站過濾器也是很嚴格的，對吧？）
請注意很重要的一點是，老練的***者可能會劫持合法的出站連接，來繞過出站過濾。但是，依據我們的經驗，在實際中是很難做到的。嚴格的出站訪問控制，是你可以爲Web服務器建立的重要防範層。
我們認爲在因特網的現今階段，就不用再強調對Web服務器的入站通信進行嚴格防火牆過濾的必要性了。TCP端口80（如果你實現了SSL/TLS，還有443端口）應該是一般訪問者在入站時唯一可以訪問的端口（顯然，特定的用戶通信，比如內容管理，服務器管理等，可能需要訪問其他特殊的端口）。
雖然入站的過濾被廣泛應用，但我們經常看到的一個錯誤是忽略了對出站的訪問控制。一旦***者獲得了在Web服務器上運行任意命令的權限，他首先要做的事情是得到一個出站Shell，或者創建出站的連接來上傳更多的文件到受害機上。在Web服務器前端防火牆上，進行正確的出站過濾，可以阻止這些請求，從而從根本上阻止***者。最簡單的規則是保留已經建立的連接，拒絕所有其他的出站連接，這可以通過保留有TCP SYN標誌的包而阻止其他包來實現。這樣不會阻止對合法請求的響應，服務器仍然可以被外部訪問到（你的入站過濾器也是很嚴格的，對吧？）
請注意很重要的一點是，老練的***者可能會劫持合法的出站連接，來繞過出站過濾。但是，依據我們的經驗，在實際中是很難做到的。嚴格的出站訪問控制，是你可以爲Web服務器建立的重要防範層。
及時更新安全補丁
保持Web平臺強健和安全的最有效方法，是隨時保持系統更新最新的安全補丁。你必須不斷地爲你的平臺和應用程序打上補丁，沒有什麼捷徑可言。雖然這裏還有很多其他的步驟可以用來加固你的系統以避免***，但是就像宣傳的那樣，及時更新系統的安全設置是你能做的最重要的事情。我們建議使用自動升級工具，比如微軟更新服務，來幫助你保證獲取最新的補丁。對於Apache來說，只需訂閱Apache公告列表，就可以在新版本發佈的時候得到通知，從而進行更新（其鏈接請查看本章末尾的“參考和進一步閱讀”一節）。
保持Web平臺強健和安全的最有效方法，是隨時保持系統更新最新的安全補丁。你必須不斷地爲你的平臺和應用程序打上補丁，沒有什麼捷徑可言。雖然這裏還有很多其他的步驟可以用來加固你的系統以避免***，但是就像宣傳的那樣，及時更新系統的安全設置是你能做的最重要的事情。我們建議使用自動升級工具，比如微軟更新服務，來幫助你保證獲取最新的補丁。對於Apache來說，只需訂閱Apache公告列表，就可以在新版本發佈的時候得到通知，從而進行更新（其鏈接請查看本章末尾的“參考和進一步閱讀”一節）。
不要在源代碼中放置私密信息
如果教導你的開發團隊不犯此類錯誤，你就不用太擔心最新、最嚴重的源代碼泄漏會傳遍***圈。這一類常見的錯誤包括：
在ASP腳本中用明文SQL連接字符串 使用SQL集成安全或一個二進制的COM對象來代替。
在應用配置文件中使用明文密碼 在諸如global.asa或web.config應用程序配置文件中，永遠不要使用明文密碼。
使用以.inc爲擴展名的包含文件 把它們改名爲.asp，並在其他腳本中改變對應的內部引用（或者像本章前面描述的那樣，把.inc映射到ASP擴展）。
在腳本中的註釋中包含諸如E-mail地址、目錄結構信息和密碼等私密信息 不要把你自己放到如此高危的環境中，確認刪除了會對自己不利的Web平臺信息和應用程序信息。
如果教導你的開發團隊不犯此類錯誤，你就不用太擔心最新、最嚴重的源代碼泄漏會傳遍***圈。這一類常見的錯誤包括：
在ASP腳本中用明文SQL連接字符串 使用SQL集成安全或一個二進制的COM對象來代替。
在應用配置文件中使用明文密碼 在諸如global.asa或web.config應用程序配置文件中，永遠不要使用明文密碼。
使用以.inc爲擴展名的包含文件 把它們改名爲.asp，並在其他腳本中改變對應的內部引用（或者像本章前面描述的那樣，把.inc映射到ASP擴展）。
在腳本中的註釋中包含諸如E-mail地址、目錄結構信息和密碼等私密信息 不要把你自己放到如此高危的環境中，確認刪除了會對自己不利的Web平臺信息和應用程序信息。
定期爲易受到***的服務器進行網絡掃描
防範***的最佳機制是定期進行漏洞掃描。這裏有很多非常有效的檢測Web應用程序的產品，比如SPI Dynamics的WebInspect，Watchfire的AppScan。對於識別Web平臺漏洞和應用層漏洞，它們都非常棒。
防範***的最佳機制是定期進行漏洞掃描。這裏有很多非常有效的檢測Web應用程序的產品，比如SPI Dynamics的WebInspect，Watchfire的AppScan。對於識別Web平臺漏洞和應用層漏洞，它們都非常棒。
！提示 關於自動化Web安全評估工具的評測，請查看第13章。
能判斷自己是否受到了***
應急響應措施就像防範措施一樣重要，對於易受***的Web服務器來說更是如此。爲了確認你的服務器是否已經成爲了目錄遍歷***的受害者，我們推薦如下指定的調查行動，這包括瞭如下的經典技術。
在受到***的Web服務器上使用Netstat程序，是確認任何連到Web服務器高端口的陌生入站連接的好辦法。就像我們已經看到的那樣，在漏洞被利用之後，可能隨後有連接到流氓Shell實例。但是，要把出站連接和Web客戶端的合法連接區分開有點困難。
應急響應措施就像防範措施一樣重要，對於易受***的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服務器上定期監視日誌和文件系統，都需要很大的精力。但是，我們希望一旦發現服務器已經受到***，這些提示可以幫助你。
另一個不錯的調查切入點是文件系統。大量現成的***代碼在因特網上流傳。那裏有很多與***相關的文件，它們最初是由很嚴肅的安全研究人員發佈的，卻常常被腳本小子完全重用。舉個例子來說，在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版）》。
