【前言：噩夢序章】

信息化時代對企業(yè)的信息安全威脅最嚴重的就是黑客入侵。由黑客入侵對企業(yè)帶來的危害大家自行百度，在此不贅述。

互聯(lián)網(wǎng)企業(yè)由于其業(yè)務特性，業(yè)務會向全互聯(lián)網(wǎng)用戶開放，只要接入互聯(lián)網(wǎng)的人都可以訪問到這個業(yè)務，覆蓋全網(wǎng)用戶的同時又等于是給黑客暴露了攻擊面，一旦業(yè)務出現(xiàn)安全漏洞，黑客就會迅速入侵進而對企業(yè)帶來災難性的破壞。

傳統(tǒng)企業(yè)即使有信息化業(yè)務，那也是在線下，覆蓋用戶有限(互聯(lián)網(wǎng)上的黑客很難接觸到)，相對還算安全。但傳統(tǒng)企業(yè)也在互聯(lián)網(wǎng)化，這里或許又會經(jīng)歷一輪腥風血雨。

騰訊安全中心早在2005年成立之初就開始關注入侵防御體系建設，經(jīng)過近十年的系統(tǒng)建設和運營，也算小有一些血淚教育和經(jīng)驗。筆者不揣淺陋，愿拋磚引玉，大家一起PK探討企業(yè)的入侵防御策略，共襄盛舉。

【啟示錄：捻亂止于河防】

木桶理論是信息安全的一個經(jīng)典理論，也就是說防御要面面俱到，隨便漏掉一個點就可能導致全盤崩潰——所謂“千里之堤毀于蟻穴”是也。這也就造成了攻防雙方的不對等：攻方只需要找到防方一個破綻，就可以把防方打敗。有點類似游擊戰(zhàn)術(shù)：打得贏就打，打不贏就跑。這情景與清末的捻軍何其相似。

捻軍是清末的反政府武裝，主要戰(zhàn)斗模式是游擊，主力是馬隊，遇到正規(guī)軍打得贏就打，打不贏就跑，馬隊跑得快，清軍步兵、洋槍隊根本追不上，搞得清政府很頭痛。連當時剛剛打敗了太平天國的天下無敵的湘軍(湖南人打仗太厲害了，號稱“無湘不成軍”)也拿捻軍沒有辦法。

后來湘軍參考明末將領孫傳庭對付流寇的辦法，以黃河為界，在重要位置步步設防，逐步推進，把捻軍趕到一個包圍圈里面，再集中優(yōu)勢兵力逼其決戰(zhàn)殲滅之。最終捻軍被河防策略消滅。

從捻軍的事例我們可以看到，對于這種攻防不對等的情況，防方要贏就要靠一個字：“控”——把對手控制在一個可控范圍，再用豐富的資源打敗他。這個思路就有點類似xti9er在《如何建立有效的安全策略》中提到的“降維攻擊”。

回到企業(yè)入侵防御上來，“控”的思路就是堅壁清野步步為營層層設防，讓黑客即使入侵進來也是在我們可控的位置活動。

一般而言，一個企業(yè)內(nèi)部網(wǎng)絡與外部網(wǎng)絡的交界是內(nèi)部員工的外網(wǎng)訪問和生產(chǎn)環(huán)境的互聯(lián)網(wǎng)業(yè)務。前者是幾乎所有企業(yè)都有的(除非你的企業(yè)不讓員工上外網(wǎng)——咳，太不人道了)，后者是有互聯(lián)網(wǎng)業(yè)務的公司才有。

內(nèi)部的外網(wǎng)訪問是很大的安全風險，這些非專業(yè)員工往往又沒有太高的安全意識。很多企業(yè)內(nèi)部就是因為黑客使用0 day甚至是N day漏洞進行網(wǎng)頁掛馬或釣魚郵件攻擊淪陷的。而生產(chǎn)環(huán)境的互聯(lián)網(wǎng)業(yè)務講究快，需要敏捷開發(fā)快速迭代，這個過程中往往容易出現(xiàn)安全漏洞，且易于被外部發(fā)現(xiàn)。黑客入侵到一臺服務器后就可以在生產(chǎn)環(huán)境內(nèi)網(wǎng)馳騁了。

只要我們重兵布防在這兩個位置，則大局可定。

大致的示意圖如下：

我們布防的位置和安全策略如下(只談主要的，其他不贅述)：

以生產(chǎn)網(wǎng)的外部入口為例，很多年前騰訊就實施了嚴格的端口管控(不允許服務器的非業(yè)務端口對外網(wǎng)開放)，所以基本上這些年的安全漏洞和入侵事件都控制在了Web層。這樣我們就可以投入大量精力在Web層進行入侵發(fā)現(xiàn)和防御。#p#

【對抗中成長：V的故事】

道哥在《中國黑客傳說——游走在黑暗中的精靈》中描述了超級黑客V的故事。沒錯，今天的主角就是V。

筆者根據(jù)一些線索以及不愿意透露姓名的接近V的人士爆料推測，V在烏云上的ID叫豬豬俠。翻看豬豬俠在烏云提交過的漏洞，可以看出這是一個頂尖高手。繼續(xù)爆料，他還有一個名字叫ring04h，很早就活躍在互聯(lián)網(wǎng)安全圈了(不熟悉的同學可以百度一下這個關鍵字)，很多年前ring04h就給我們提交過漏洞。

當然，以上只是基于福爾摩斯演繹法的推論，筆者不保證這個推論的正確性。

{第一場｝開源系統(tǒng)弱口令血案

2013年9月的某天凌晨，我們的流量監(jiān)控系統(tǒng)(對HTTP全流量進行分析，發(fā)現(xiàn)異常的HTTP請求)發(fā)出警報，某個網(wǎng)站存在WebShell通信，看到請求URL的第一反應是nginx的解析漏洞(漏洞原理參見nginx文件類型錯誤解析漏洞)的利用。

應急響應團隊立即排查，發(fā)現(xiàn)網(wǎng)站目錄出現(xiàn)了一個gif后綴的PHP WebShell，再利用nginx解析漏洞執(zhí)行。由于是gif后綴，一般情況下不會執(zhí)行，所以主機安全Agent沒有檢測這個“圖片”文件，幸好有縱深防御——在網(wǎng)絡流量特征檢測到了。同時服務器上的PHP的SafeMod為On，入侵者沒有執(zhí)行系統(tǒng)命令的權(quán)限。

檢討下，此次事件主要是某個業(yè)務擅自使用WordPress，而又沒有做安全加固導致(WordPress的后臺管理頁面對外網(wǎng)開放且有弱口令，黑客利用WordPress的后臺權(quán)限上傳了這個WebShell文件)。雖然防線被突破，但是有重兵把守(主機安全Agent系統(tǒng)檢測主機層的可疑行為;流量監(jiān)控系統(tǒng)檢測網(wǎng)絡層的可疑流量)于后，以致滲透過程被及時發(fā)現(xiàn)阻斷。

于是接下來我們就開始清理各種Web管理頁面、弱口令以及nginx安全配置檢測。過程中我們又發(fā)現(xiàn)幾個沒備案的WordPress，趕緊驅(qū)動加固。具體按下不表。

此次事件從入侵者視角看，參見一次失敗的漫游騰訊內(nèi)網(wǎng)過程。

流量監(jiān)控系統(tǒng)的好處是對全HTTP請求進行分析，只要規(guī)則得當，黑客利用漏洞的時候就會觸發(fā)警報，有好多Web漏洞就是被我們的流量監(jiān)控系統(tǒng)發(fā)現(xiàn)并修復的。比如某些在線XSS攻擊平臺利用時會引入它域名下的JS，這個域名就是強關鍵字;再比如一些WebShell的HTTP通信模型。這個話題以后有機會再寫。

{第二場｝備份文件帶來的攻擊

2013年11月某天，主機安全Agent系統(tǒng)發(fā)出警報，發(fā)現(xiàn)某臺服務器出現(xiàn)WebShell文件，我們的應急響應團隊一看安全事件單嚇壞了，這不就是一個典型的PHPWebShell么：

主機安全Agent系統(tǒng)是運行在服務器的一個程序，主要負責收集基礎信息(后臺對基礎信息分析發(fā)現(xiàn)安全風險)和入侵行為發(fā)現(xiàn)。由于Web層入侵都會用到WebShell，所以我們把WebShell檢測做為第一道防線，一旦由于一些原因系統(tǒng)未能發(fā)現(xiàn)，進程/端口數(shù)據(jù)是第二道防線——比如Apache的屬主用戶執(zhí)行了命令，就是個典型的WebShell執(zhí)行命令特征。

話分兩頭。應急響應團隊接到警報后趕緊登機，關閉服務器外網(wǎng)，然后開始入侵檢查。

因為是config_ucenter.php里面被改了，所以首先想到是discuz的后臺獲取WebShell漏洞(看來是個0day漏洞)。果然后來知道是因為業(yè)務把config_ucenter.php備份了一個config_ucenter.php.bak文件，導致配置文件里的UC_KEY泄漏。有了UC_KEY就可以給論壇添加管理員了，再通過那個0day漏洞，就可以直接入侵服務器。

全過程見入侵者的自述：又一次失敗的漫游騰訊內(nèi)網(wǎng)過程 。雖然被黑了有點臉上無光，不過連經(jīng)驗豐富的豬豬俠都說“騰訊在PHP安全領域的防護實力，當屬國內(nèi)第一”，這點還是很讓人欣慰。

檢討時間。此次事件主要是discuz的Web管理頁面對外網(wǎng)開放(還是河防沒搞好)，當然也有文件備份不當?shù)膯栴}。接下來繼續(xù)清理遺漏的Web管理頁面，重點針對部署discuz的服務器進行全方位加固。

{第三場｝配置不當產(chǎn)生安全風險

2013年12月某天，Kobin97反饋了我們某個discuz論壇的一個PHP文件源代碼可以下載到，導致泄漏UC_KEY(見這個漏洞報告)。discuz論壇泄漏了UC_KEY是會被拿到WebShell的，所以應急團隊趕緊處理。

在上次discuz出事后，我們開始了大規(guī)模的排查和加固，某些業(yè)務在加固過程中誤把目錄 /uc_server/data/ 配置為不解析PHP，結(jié)果反而導致目錄下的PHP文件可以被下載到，UC_KEY泄漏。

萬幸的是經(jīng)過驗證，這個漏洞暫時拿不到WebShell。因為在上次加固中我們已要求所有的discuz的登錄頁面/admin.php禁止外網(wǎng)訪問，即使UC_KEY泄漏了，入侵者也很難進一步滲透。下圖就是從非管理IP訪問管理后臺被拒絕的截圖。

豬豬俠也發(fā)現(xiàn)了這個問題，還精心設計了一個XSS攻擊試圖用有授權(quán)的人的瀏覽器來自動獲取WebShell。不過被Kobin97報了漏洞之后我們就迅速修改了UC_KEY，豬豬俠的計劃落空了。參見豬豬俠自述又又一次失敗的漫游騰訊內(nèi)網(wǎng)過程。你們還有沒有看出什么破綻?

檢討時間。這次事件主要是在實施安全加固策略的過程中，對配置是否正確的情況缺乏審計;同時還有流量監(jiān)控系統(tǒng)若發(fā)現(xiàn)PHP、JSP這種該解析的腳本被下載了，就應該告警出來。

{第四場｝安全策略失效帶來的問題

在第二場后，我們的discuz論壇都進行了安全加固，特別是在管理頁面做了訪問IP限制，本來以為高枕無憂了，其實不然。

某天可能是因為策略回滾，某個discuz論壇管理頁面的訪問IP限制失效了，正好管理員又有個弱口令，結(jié)果就給了豬豬俠可乘之機。

這個訪問控制策略失效是被我們的Web漏洞掃描系統(tǒng)檢測到了的，但是在修復的過程中被豬豬俠掃到并利用——大家可以想象，你的業(yè)務有多少人24小時盯著，稍微出點疏忽就會出問題。

然后就是利用discuz管理后臺的0day漏洞生成WebShell。有了前幾次的經(jīng)驗，這次豬豬俠比較謹慎，沒有進行提權(quán)、端口掃描、漏洞掃描等大動作，所以一直未被發(fā)現(xiàn)。參見豬豬俠的一次成功的漫游騰訊內(nèi)網(wǎng)過程。

又到了檢討時間。此次事件是訪問IP限制策略失效再加上管理員存在弱口令導致。然后豬豬俠的一系列動作比較輕，沒有觸發(fā)各種安全系統(tǒng)警報。

此次的關鍵節(jié)點還是在管理頁面限制措施失效的處理時間稍長。對于高危漏洞，一定要立即處理，不可拖延;對抗高級滲透，除了已知入侵模式的黑名單模型，還要更進一步使用白名單模型，依靠平時的網(wǎng)絡訪問、運維行為建立時間/行為/動作模型，一旦出現(xiàn)不符合的情況就判定為異常事件——我們在核心區(qū)域已經(jīng)開始這樣做了。

{總結(jié)｝

因為我們已經(jīng)屏蔽了服務器的外網(wǎng)所有非業(yè)務端口，所以四次入侵都是從Web應用過來的。雖然還是被黑客不同程度地獲取到部分權(quán)限，但是黑客的活動范圍被控制在一個有限的區(qū)域(都是普通業(yè)務區(qū))，至少說明河防大策略還是正確的。

我們可以看到，黑客們都對這種開源的程序漏洞(如discuz、WordPress、phpwind等)研究得爐火純青，企業(yè)能不用就不用。

對于越來越多的互聯(lián)網(wǎng)Web業(yè)務，一定要做好安全加固，簡單口訣：“目錄默認不可寫，可寫目錄不解析，Web Server非root，管理頁面不對外”。對于企業(yè)來說，這個工作大部分是個系統(tǒng)工程問題而不是安全技術(shù)問題。

【后記：未完待續(xù)】

河防大計定下來后，要考慮對敵人的精準打擊了——也就是在可控區(qū)域進行縱深防御。

縱深防御就是要聯(lián)動多個層面的安全系統(tǒng)層層設防，這樣即使哪個點被突破了還可以在其他層面發(fā)現(xiàn)和阻斷入侵。比如我們正在嘗試的PHP環(huán)境下的安全防御方案和多維度的入侵檢測。

我們需要始終記得，安全是一個整體。