【前言：噩夢序章】
信息化時代對企業的信息安全威脅最嚴重的就是******。由******對企業帶來的危害大家自行百度，在此不贅述。
互聯網企業由於其業務特性，業務會向全互聯網用戶開放，只要接入互聯網的人都可以訪問到這個業務，覆蓋全網用戶的同時又等於是給***暴露了***面，一旦業務出現安全漏洞，***就會迅速***進而對企業帶來災難性的破壞。
傳統企業即使有信息化業務，那也是在線下，覆蓋用戶有限（互聯網上的***很難接觸到），相對還算安全。但傳統企業也在互聯網化，這裏或許又會經歷一輪腥風血雨。
騰訊安全中心早在2005年成立之初就開始關注***防禦體系建設，經過近十年的系統建設和運營，也算小有一些血淚教育和經驗。筆者不揣淺陋，願拋磚引玉，大家一起PK探討企業的***防禦策略，共襄盛舉。
【啓示錄：捻亂止於河防】
木桶理論是信息安全的一個經典理論，也就是說防禦要面面俱到，隨便漏掉一個點就可能導致全盤崩潰——所謂“千里之堤毀於蟻穴”是也。這也就造成了***雙方的不對等：攻方只需要找到防方一個破綻，就可以把防方打敗。有點類似游擊戰術：打得贏就打，打不贏就跑。這情景與清末的捻軍何其相似。
捻軍是清末的反政府武裝，主要戰鬥模式是遊擊，主力是馬隊，遇到正規軍打得贏就打，打不贏就跑，馬隊跑得快，清軍步兵、洋槍隊根本追不上，搞得清政府很頭痛。連當時剛剛打敗了太平天國的天下無敵的湘軍（湖南人打仗太厲害了，號稱“無湘不成軍”）也拿捻軍沒有辦法。
後來湘軍參考明末將領孫傳庭對付流寇的辦法，以黃河爲界，在重要位置步步設防，逐步推進，把捻軍趕到一個包圍圈裏面，再集中優勢兵力逼其決戰殲滅之。最終捻軍被河防策略消滅。
從捻軍的事例我們可以看到，對於這種***不對等的情況，防方要贏就要靠一個字：“控”——把對手控制在一個可控範圍，再用豐富的資源打敗他。這個思路就有點類似xti9er在《如何建立有效的安全策略》中提到的“降維***”。
回到企業***防禦上來，“控”的思路就是堅壁清野步步爲營層層設防，讓***即使***進來也是在我們可控的位置活動。
一般而言，一個企業內部網絡與外部網絡的交界是內部員工的外網訪問和生產環境的互聯網業務。前者是幾乎所有企業都有的（除非你的企業不讓員工上外網——咳，太不人道了），後者是有互聯網業務的公司纔有。
內部的外網訪問是很大的安全風險，這些非專業員工往往又沒有太高的安全意識。很多企業內部就是因爲***使用0 day甚至是N day漏洞進行網頁掛馬或釣魚郵件***淪陷的。而生產環境的互聯網業務講究快，需要敏捷開發快速迭代，這個過程中往往容易出現安全漏洞，且易於被外部發現。******到一臺服務器後就可以在生產環境內網馳騁了。
只要我們重兵佈防在這兩個位置，則大局可定。
大致的示意圖如下：
我們佈防的位置和安全策略如下（只談主要的，其他不贅述）：
以生產網的外部入口爲例，很多年前騰訊就實施了嚴格的端口管控（不允許服務器的非業務端口對外網開放），所以基本上這些年的安全漏洞和***事件都控制在了Web層。這樣我們就可以投入大量精力在Web層進行***發現和防禦。
【對抗中成長：V的故事】
道哥在《中國***傳說——遊走在黑暗中的精靈》中描述了超級***V的故事。沒錯，今天的主角就是V。
筆者根據一些線索以及不願意透露姓名的接近V的人士爆料推測，V在烏雲上的ID叫豬豬俠。翻看豬豬俠在烏雲提交過的漏洞，可以看出這是一個頂尖高手。繼續爆料，他還有一個名字叫ring04h，很早就活躍在互聯網安全圈了（不熟悉的同學可以百度一下這個關鍵字），很多年前ring04h就給我們提交過漏洞。
當然，以上只是基於福爾摩斯演繹法的推論，筆者不保證這個推論的正確性。
｛第一場｝開源系統弱口令血案
2013年9月的某天凌晨，我們的流量監控系統（對HTTP全流量進行分析，發現異常的HTTP請求）發出警報，某個網站存在WebShell通信，看到請求URL的第一反應是nginx的解析漏洞（漏洞原理參見nginx文件類型錯誤解析漏洞）的利用。
應急響應團隊立即排查，發現網站目錄出現了一個gif後綴的PHP WebShell，再利用nginx解析漏洞執行。由於是gif後綴，一般情況下不會執行，所以主機安全Agent沒有檢測這個“圖片”文件，幸好有縱深防禦——在網絡流量特徵檢測到了。同時服務器上的PHP的SafeMod爲On，***者沒有執行系統命令的權限。
檢討下，此次事件主要是某個業務擅自使用WordPress，而又沒有做安全加固導致（WordPress的後臺管理頁面對外網開放且有弱口令，***利用WordPress的後臺權限上傳了這個WebShell文件）。雖然防線被突破，但是有重兵把守（主機安全Agent系統檢測主機層的可疑行爲；流量監控系統檢測網絡層的可疑流量）於後，以致***過程被及時發現阻斷。
於是接下來我們就開始清理各種Web管理頁面、弱口令以及nginx安全配置檢測。過程中我們又發現幾個沒備案的WordPress，趕緊驅動加固。具體按下不表。
此次事件從***者視角看，參見一次失敗的漫遊騰訊內網過程。
流量監控系統的好處是對全HTTP請求進行分析，只要規則得當，***利用漏洞的時候就會觸發警報，有好多Web漏洞就是被我們的流量監控系統發現並修復的。比如某些在線XSS***平臺利用時會引入它域名下的JS，這個域名就是強關鍵字；再比如一些WebShell的HTTP通信模型。這個話題以後有機會再寫。
｛第二場｝備份文件帶來的***
2013年11月某天，主機安全Agent系統發出警報，發現某臺服務器出現WebShell文件，我們的應急響應團隊一看安全事件單嚇壞了，這不就是一個典型的PHPWebShell麼：
主機安全Agent系統是運行在服務器的一個程序，主要負責收集基礎信息（後臺對基礎信息分析發現安全風險）和***行爲發現。由於Web層***都會用到WebShell，所以我們把WebShell檢測做爲第一道防線，一旦由於一些原因系統未能發現，進程/端口數據是第二道防線——比如Apache的屬主用戶執行了命令，就是個典型的WebShell執行命令特徵。
話分兩頭。應急響應團隊接到警報後趕緊登機，關閉服務器外網，然後開始***檢查。
因爲是config_ucenter.php裏面被改了，所以首先想到是discuz的後臺獲取WebShell漏洞（看來是個0day漏洞）。果然後來知道是因爲業務把config_ucenter.php備份了一個config_ucenter.php.bak文件，導致配置文件裏的UC_KEY泄漏。有了UC_KEY就可以給論壇添加管理員了，再通過那個0day漏洞，就可以直接***服務器。
全過程見***者的自述：又一次失敗的漫遊騰訊內網過程 。雖然被黑了有點臉上無光，不過連經驗豐富的豬豬俠都說“騰訊在PHP安全領域的防護實力，當屬國內第一”，這點還是很讓人欣慰。
檢討時間。此次事件主要是discuz的Web管理頁面對外網開放（還是河防沒搞好），當然也有文件備份不當的問題。接下來繼續清理遺漏的Web管理頁面，重點針對部署discuz的服務器進行全方位加固。
｛第三場｝配置不當產生安全風險
2013年12月某天，Kobin97反饋了我們某個discuz論壇的一個PHP文件源代碼可以下載到，導致泄漏UC_KEY（見這個漏洞報告）。discuz論壇泄漏了UC_KEY是會被拿到WebShell的，所以應急團隊趕緊處理。
在上次discuz出事後，我們開始了大規模的排查和加固，某些業務在加固過程中誤把目錄 /uc_server/data/ 配置爲不解析PHP，結果反而導致目錄下的PHP文件可以被下載到，UC_KEY泄漏。
萬幸的是經過驗證，這個漏洞暫時拿不到WebShell。因爲在上次加固中我們已要求所有的discuz的登錄頁面/admin.php禁止外網訪問，即使UC_KEY泄漏了，***者也很難進一步***。下圖就是從非管理IP訪問管理後臺被拒絕的截圖。
豬豬俠也發現了這個問題，還精心設計了一個XSS***試圖用有授權的人的瀏覽器來自動獲取WebShell。不過被Kobin97報了漏洞之後我們就迅速修改了UC_KEY，豬豬俠的計劃落空了。參見豬豬俠自述又又一次失敗的漫遊騰訊內網過程。你們還有沒有看出什麼破綻？
檢討時間。這次事件主要是在實施安全加固策略的過程中，對配置是否正確的情況缺乏審計；同時還有流量監控系統若發現PHP、JSP這種該解析的腳本被下載了，就應該告警出來。
｛第四場｝安全策略失效帶來的問題
在第二場後，我們的discuz論壇都進行了安全加固，特別是在管理頁面做了訪問IP限制，本來以爲高枕無憂了，其實不然。
某天可能是因爲策略回滾，某個discuz論壇管理頁面的訪問IP限制失效了，正好管理員又有個弱口令，結果就給了豬豬俠可乘之機。
這個訪問控制策略失效是被我們的Web漏洞掃描系統檢測到了的，但是在修復的過程中被豬豬俠掃到並利用——大家可以想象，你的業務有多少人24小時盯着，稍微出點疏忽就會出問題。
然後就是利用discuz管理後臺的0day漏洞生成WebShell。有了前幾次的經驗，這次豬豬俠比較謹慎，沒有進行提權、端口掃描、漏洞掃描等大動作，所以一直未被發現。參見豬豬俠的一次成功的漫遊騰訊內網過程。
又到了檢討時間。此次事件是訪問IP限制策略失效再加上管理員存在弱口令導致。然後豬豬俠的一系列動作比較輕，沒有觸發各種安全系統警報。
此次的關鍵節點還是在管理頁面限制措施失效的處理時間稍長。對於高危漏洞，一定要立即處理，不可拖延；對抗高級***，除了已知***模式的黑名單模型，還要更進一步使用白名單模型，依靠平時的網絡訪問、運維行爲建立時間/行爲/動作模型，一旦出現不符合的情況就判定爲異常事件——我們在覈心區域已經開始這樣做了。
｛總結｝
因爲我們已經屏蔽了服務器的外網所有非業務端口，所以四次***都是從Web應用過來的。雖然還是被***不同程度地獲取到部分權限，但是***的活動範圍被控制在一個有限的區域（都是普通業務區），至少說明河防大策略還是正確的。
我們可以看到，***們都對這種開源的程序漏洞（如discuz、WordPress、phpwind等）研究得爐火純青，企業能不用就不用。
對於越來越多的互聯網Web業務，一定要做好安全加固，簡單口訣：“目錄默認不可寫，可寫目錄不解析，Web Server非root，管理頁面不對外”。對於企業來說，這個工作大部分是個系統工程問題而不是安全技術問題。
【後記：未完待續】
河防大計定下來後，要考慮對敵人的精準打擊了——也就是在可控區域進行縱深防禦。
縱深防禦就是要聯動多個層面的安全系統層層設防，這樣即使哪個點被突破了還可以在其他層面發現和阻斷***。比如我們正在嘗試的PHP環境下的安全防禦方案和多維度的***檢測。
我們需要始終記得，安全是一個整體。