“溢出”一直以來都是很多黑帽子黑客最常用(或者說是最喜歡用)的手段之一，隨安全文化的逐步普及，大量的公開shellcode(“溢出”代碼)與溢出攻擊原理都可以隨意在各大的網絡安全網站中找得到，由此衍生了一系列的安全隱患...小黑黑使用它們來進行非法的攻擊、惡意程序員使用它們來制造蠕蟲等等...而網絡防火墻作為人們最喜歡的網絡安全“設施”之一，它又能如何“攔截”這一類型的攻擊呢？
目前大多的防火墻系統都是針對包過濾規則進行安全防御的，這類型的防火墻再高也只能工作在傳輸層，而溢出程序的shellcode是放在應用層的，因此對這類攻擊就無能為力了。打個比方:前段時間比較火熱的IIS WEBDAV溢出漏洞，若黑客攻擊成功能直接得到ROOTSHELL(命令行管理員控制臺)，它是在正常提供HTTP服務的情況下產生的溢出漏洞，若在不打補丁與手工處理的情況下一臺防火墻又能做到什么呢？相信你除了把訪問該服務器TCP80端口(提供正常地HTTP服務的情況下)的包過濾掉以外就什么都不會去做了，當然，這樣也會使你的HTTP服務無法正常地開放(等于沒有提供服務...)。下面就以這個漏洞為“論點&題材”，說說自己的解決方案。
1)對希望保護的主機實行“單獨開放端口”訪問控制策略
所謂“單獨開放端口”就是指只開放需要提供的端口，對于不需要提供服務的端口實行過濾策略。打個比方，現在我們需要保護一臺存在WebDAV缺陷的WEB服務器，如何能令它不被駭客入侵呢？答案是：在這臺WEB服務器的前端防火墻中加入一個“只允許其他機器訪問此機的TCP80端口”的包過濾規則(至于閣下的防火墻能否實現這樣的規則就另當別論了)。加上這個規則又會有怎樣的效果呢？經常做入侵滲透測試的朋友應該比我還清楚遠程溢出的攻擊實施流程了吧？
①使用缺陷掃描器找到存在遠程溢出漏洞的主機-》②確認其版本號(如果有需要的話)-》③使用exploit(攻擊程序)發送shellcode-》④確認遠程溢出成功后使用NC或TELNET等程序連接被溢出主機的端口-》⑤得到SHELL
使用“單獨開放端口”策略的解決方案對整個遠程溢出過程所發生的前三步都是無能為力的，但來到第四步這個策略能有效地阻止駭客連上有缺陷主機的被溢出端口，從而切斷了駭客的惡意攻擊手段。
優點：操作簡單，一般的網絡/系統管理員就能完成相關的操作。
缺點：對溢出后使用端口復用進行控制的EXPLOITS就無能為力了；對現實中的溢出后得到反向連接控制的EPLOITS也是無能為力；不能阻止D.o.S方面的溢出攻擊。
2)使用應用層防火墻系統
這里所謂的應用層并不是想特別指明該防火墻工作在應用層，而是想指明它能在應用層對數據進行處理。由于應用層的協議/服務種類比較多，因此針對應用層形式的防火墻就有一定的市場局限性了。就樓上所提到的案例而言我們可以使用處理HTTP協議的應用層防火墻對存在WebDAV缺陷的服務器訂制保護規則，保證服務器不收此類攻擊的影響。應用層中的HTTP協議防火墻系統不多，其中比較出名的有EEYE公司的SecureIIS，其使用方式就可謂是“弱智型”了，說說它的基本防御原理與特點吧。當服務端接受到一個發送至TCP80端口的數據包時首先就會將該包轉移至SecureIIS，SecureIIS就會對該包進行分析并解碼該包的應用層數據，將得到的數據與你本身定制的規則進行數據配對，一旦發現條件相符餓數值就會執行規則所指定的相應操作。
優點：能有效地切斷一些來自應用層的攻擊(如溢出、SQL注入等)。
缺點：因為需要安裝在服務器上，所以會占用一定的系統資源；(eeye公司本身并無開發該軟件的中文版本，所以一旦它受到POST行為發出的中文數據時就會自動認為是高位攻擊代碼，自動將其隔離，并進行相關的處理操作)。
3)使用IDS功能的防火墻系統
現在國內自主開發的防火墻系統可謂是進入“白熱化”了，什么百兆、千兆、2U、4U...性能參數的比較本已經日趨激烈了，再開始有不少廠商將技術重點轉移在了“多功能”的方面上，在防火墻中繼承IDS模塊已經不是什么新鮮事了，使用這類產品可以達到監控應用層數據的效果。
優點：便于管理。
缺點：費用支出增大；長期需要人力資源對其進行管理與設施維護；防火墻上的IDS模塊功能有限。
綜合以上三種解決方案，希望有一種能為閣下提供反思的空間，也希望各位能為提出相應的建議與意見，謝謝各位，需要與我聯系請EMAIL至demonalex[at]demonalex.net。
