199
從一個0day漏洞看數據中心防護效果大比拚
記得郭德綱有這麼一個著名的段子：家中屋漏，外麵下小雨，屋裏下大雨；外麵下大雨，全家人就隻能站到院子裏避雨。如果我們把屋子換成傘，外麵下雨，傘裏也下雨，你還會用這樣的傘嗎？
“簡直是笑話，誰會用這樣的傘？”，你可能會這麼說。不過，是不是有漏雨的傘，咱先別著急下結論。這凡事都有個體驗和比較。沒有體驗和比較，你就不知道到底什麼樣的傘叫好傘。
在前兩天阿裏雲論壇的安全版塊裏有這麼一個有趣兒的熱帖。在這個帖子裏，樓主講了這麼一個有趣兒的事兒：“我現在操作2個網站： 一個心理測試大百科www.A.com，部署在阿裏雲，開通雲盾。另 一個是www.B.cn，部署在XX數碼。 昨天這2個網站後台都發現了同樣的警告框。但是隻有XX數碼上的www.B.cn中招了。 2個程序版本一樣，為什麼阿裏雲上的心理測試大百科www.A.com沒中招呢? ”
樓主所謂的“中招”是指在他采用PHPCMS係統的網站後台多了一個超級管理員用戶－pcmanage。而這個pcmanage超管用戶並非他自己添加，而是被別人偷偷地加上去的。
好個從石頭縫裏蹦出來的孫悟空。開過網站的小夥伴想必都應該非常清楚事情的嚴重性了。PHPCMS係統的“超級管理員”就像它的命名一樣，擁有對網站係統的一切權限。如果黑客擁有了攻擊目標網站的超級管理員賬號，後果可想而知。
那麼，黑客是如何偷偷添加超級管理員賬號的呢？簡言之，黑客利用PHPCMS係統的0day漏洞，竊取了網站專門用來防護跨站攻擊的Token，通過劫持管理員的HTTP會話，在管理員絲毫沒有察覺的情況下，利用管理員的身份成功添加了超級管理員賬戶——一個無所不能的孫悟空。
有些拗口，別急，下麵我們詳細說說黑客是怎麼攻擊的。經過阿裏雲安全技術團隊的分析，黑客當時是利用了PHPCMS係統存在的一個漏洞發起了CSRF攻擊，最終添加了超管賬號。
CSRF（Cross-site request forgery），中文名稱跨站請求偽造，是在用戶會話下通過第三方網站發起GET/POST的請求——這些請求用戶未必知道和願意做，可以把它視作一種HTTP會話劫持。下圖是典型的CSRF攻擊過程：
圖1: CSRF典型攻擊過程
從上圖可以看出，A網站通過cookie來識別用戶（C），當用戶成功進行身份驗證之後瀏覽器就會得到一個標識其身份的cookie，隻要不關閉瀏覽器或者退出登錄，以後訪問A網站會一直帶上這個cookie。如果這期間瀏覽器被人控製著向A網站發起請求去執行一些用戶不想做的功能（比如添加賬號），這就是會話劫持了。因為這個不是用戶真正想發出的請求，這就是所謂的“請求偽造”。此外，由於請求可以從第三方網站提交，所以前綴跨站二字，即從B網站發起。
PHPCMS係統對於CSRF的防護主要是通過在會話中加入令牌（Token）方式來實現，黑客恰恰是利用了0day漏洞在偷竊了Token後，發起了CSRF攻擊並劫持了管理員的身份。
麵對這樣一個0day漏洞攻擊，阿裏雲雲盾如何實現有效防護的呢？眾所周知，0day漏洞是沒有補丁的，客觀地講，在防護的時候也無法采用針對性的防護手段。然而，阿裏雲雲盾多層麵縱深化防護體係對於未知攻擊同樣可以做到有效防護。
雲盾在網絡、係統以及應用上均有相應的防護策略，這些防護策略對於網站來說，就像一層層的防護網。更為關鍵的是，這些“防護網”是一體化的，是一個整體，並非彼此孤立。無論在網絡流量攻擊、還是係統入侵或是應用破壞上，黑客隻要在入侵過程中觸發任何一個防護點的策略，均會引發雲盾整體的迅速響應。在上麵的攻擊過程中，由於黑客采取了“組合化”進攻手段，觸發了雲盾對某單項攻擊手段的防護策略，從而導致整個攻擊過程戛然而止。
既有點，也有麵，點麵結合，這正是雲盾強大的地方。這種點麵結合的整體防護體係考驗的是多個安全子係統能否實現彼此無縫配合、策略分布式部署以及麵向攻擊的整體化視野。這樣的防護體係不是簡單部署一個DDoS防護係統、入侵防禦係統或WAF係統就可以實現。
傳統IDC數據中心普遍采取糖葫蘆串式的防護手段，在服務器前部署一長串的防護設備，這些防護設備之間是獨立工作，沒有彼此關聯關係。這種安全防護模型無疑增加了防禦一方的建設和運營管理成本，而麵對0day或者更為複雜攻擊的時候卻往往束手無策。
事實上，強大的雲盾也不是一朝鍛造而成，而是得益於阿裏安全部十年攻防積累的數據和經驗。其全麵的DDoS防護、主機入侵防護、Web防護牆以及貼心而全麵的網站安全體檢服務，也是幾十萬網站站長選擇阿裏雲的重要原因。
最後，再回到文章開始時候提到的雨傘。這傘好不好，最關鍵還是要看漏不漏雨；而漏雨不漏雨，隻有用過的人才知道。
最後更新：2017-04-03 05:39:27