1. <dd id="au9n3"></dd>
    2. <tbody id="au9n3"><pre id="au9n3"></pre></tbody>

      <dd id="au9n3"><center id="au9n3"></center></dd>
    3. En

      捻亂止于河防——淺談企業入侵防御體系建設

      作者:lake2公布時間:2014-09-16閱讀次數:70401評論:16

      分享

      前言:噩夢序章

       

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

       

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

       

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

       

      騰訊安全中心早在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環境下的安全防御方案多維度的入侵檢測

       

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

       

      評論留言

      提交評論 您輸入的漏洞名稱有誤,請重新輸入
      放荡的寡妇