<mark id="oztn4"></mark>
0
小明和小紅是鄰居。
小明會點兒技術，他暗戀小紅。
但是情商低的小明在小紅不知情的情況下，入侵了鄰居小紅的網絡，順手從小紅電腦里偷出了小紅的各種生活照，并做了轟天動地的表白網站，配上了這些圖，自以為特別成功地發給了小紅。
小明，卒。
表白不成功不是啥事。世界上最痛苦的事兒，莫過于有人入侵了你家的網絡，你卻不知道。互聯網早已經變成了一個沒有硝煙的戰場。
對個人用戶而言，可能是隱私信息、電子財產被盜等，對企業網絡而言，形勢可能更嚴峻。
無時無刻，有成千上萬的掃描器在不停地掃，有各種各樣的系統、中間件、web 程序被曝出漏洞。有那么一群人，為了盜取用戶數據、發動 DDoS 攻擊、勒索等，瘋狂發起攻擊。
其實攻擊并不可怕，有數據顯示，98%的攻擊都是試探性的。可怕的是攻擊成功——入侵。如何抵抗入侵、及早發現入侵，甚至在萌芽階段就能阻止入侵，對一個企業網絡異常重要。
3月15日，百度安全資深安全工程師小灰灰在雷鋒網硬創公開課中，按照自己的實操經驗，詳細講解了如何建立一個有效的企業級安全防御。
小灰灰，百度安全資深安全工程師，主要負責百度業務應急響應、入侵排查、0Day 分析等，同時是百度安全監控體系建設技術負責人。主要技術攻關方向為 Web 安全及硬件安全。
由于曾就職在乙方安全公司，現在負責甲方安全，所以對整體的國內安全狀態、各方優勢以及存在的一些不足都有一些理解&感觸。
整體上來看，國內以BAT為首的互聯網公司，安全地位都比較高，整體研發能力也很強，基本上各大的安全系統都是自研，靈活性、效果、性能方面都有較大的優勢。而國內一些中小型企業，由于整體人員分配、資金投入、業務安全風險等各方面原因吧，處于想做安全但是人力不足、專業技能人員不足，主要靠大量的購買盒子類產品、安全服務等保障公司網絡安全。
上圖是我親身經歷的很多 case 挑了幾個典型代表。可以看見，針對這些安全研發能力一般的（估計這方面研發能力強的，也只有大型互聯網公司+一些金融機構了）公司，看起來像是投入了很多資源，也很重視安全（一些定期匯報之類的），但是實際效果其實很差。不是他們不想做好，只是可能缺少了正確的方法。
那么試想下，當前兩天的struts2 遠程命令漏洞來了，可以預見到，這些企業大多都會被無情的入侵。工程師早上上班一來，發現頁面被人改了、數據被人偷了、還搞了個locky病毒：要想贖回數據，請交錢。
所以我希望我能通過介紹互聯網公司的，包含理念和具體方法的最佳實踐，能夠幫助這些企業在安全建設方面開拓些思路，改善下當前買了安全、做了安全但又經常處處挨打的處境。
知己知彼，百戰不殆。首先我們來看看黑客們都是如何入侵到企業網絡中的，以及他們都做了什么惡事兒。
看起來，他們還是有幾個主要途徑的，這里面最重要的 莫過于web系統了。暴露的服務越多，遭受攻擊的可能性就越大。而且黑客獲取服務器權限后還會進一步漫游內網，獲取更多資源。
說到web系統，不得不提掃描器。其實黑客大多數也很忙，沒有時間針對每個網站一點點人工測試，大多數是這么做的：開一堆掃描器，任其瘋狂掃描，坐等最終結果。如果結果中有了一些中高危漏洞，他們便嘗試去利用，這時候才開始針對性測試。所以，掃描算是一個重要入口了吧，如果能擋住點掃描行為，擾亂掃描器這群傻機器，其實也可以很大程度上增強安全性了。
對webserver進行些加固、用個效果不錯的waf抵擋掃描器的探測、同時自己也用掃描器提前掃一下，針對已知漏洞還是有很大效果的。
但是針對struts2 s2-045 這樣的0day漏洞，效果就很有限了。那如何在0day下，也有一部分的防御&感知能力呢？
由于是0day，第一時間：
? 沒有規則，無法攔截
? 沒有poc詳情，無法掃描
但是，利用漏洞必定會 有攻擊路徑
? 特征（主要是 已入侵，得到shell的方法）
? 行為（主要是進一步攻擊，漫游，擴大戰果）
所以這時，用安全監控作為彌補，感知已入侵的入侵特征和行為，及時發現黑客入侵并應急處置，將變得異常重要和有效。
下面，我會從這三個方面給大家介紹下互聯網公司一般是如何做的，以及需要注意的問題。著重講下安全監控的思路。其中的一些實踐經驗總結來自于大量的攻防對抗、入侵排查、0day應急處理。
關于掃描器，我們需要明白，掃描器并不是萬能的，他主要的作用有兩個：
已知問題提前發現，先于黑客發現并修復漏洞，防止被外界利用
新問題 快速review（0day、SRC、其他公司等近期多發高危case）
掃描器只能是一個公司安全整體情況的晴雨表，通過掃描結果反饋不足并不斷改進。而這個晴雨表的效果來自于整體掃描能力的構建。
如何評判一個掃描系統是否優秀呢？Poc的數量、質量、是否有智能識別是一個很重要的指標。數量代表了能掃到的漏洞范圍（但切記范圍要本地化、實用，一些老舊、無大風險的漏洞其實并沒有必要），質量代表了掃描效果（例如sql注入掃描poc，是否覆蓋了各種注入類型等），智能識別能極大的降低由于“傻掃”帶來的資源占用、任務時間延長。
另一個常見問題是大多數掃描器資產發現能力很弱，單靠爬蟲等會使得掃描輸入源（訪問url和參數）很有限，輸入源少了，自然整體掃到的漏洞也少。一種有效的方法是通過流量中、瀏覽器插件、access日志等獲取更多的輸入源補充到掃描任務中。
如果不滿足商業掃描器的功能&靈活性，或者希望更深入了解掃描器的原理，或者干脆自己實現一款掃描器，那么可以參考下W3AF（如上圖所示）。W3AF是一款很優秀的開源掃描器，使用python語言實現。其中的audit模塊包含了常見漏洞的檢測及判斷方法。而crawl模塊包含了爬蟲、google hacking、dictionary list等多種資產發現方式。整體上來看，很具有參考價值。
WAF通常是放在了一些中小型企業DMZ區域的最外側。同樣的，WAF也不是萬能的，別指望有了WAF就一切萬事大吉了（這是大家一直的誤區）。它所解決的問題，其一是讓掃描器得不到想要的結果，混淆掃描器；其二是在攔截0day方面，由于是最外側入口，有著不可比擬的優勢，在業務沒有統一修復之前，針對性利用代碼，防范0day。
同時WAF也可以作為一些數據產出，比方說根據近期攻擊情況做防御調整，比方說收集最新的POC等。
上面第一個是我們從WAF收集到的具有攻擊性的POC（poc放出當天就發現了）。下面的兩個是我們收集到的構造十分精巧的POC，后來放在我們一部分掃描規則中。
既然我已經說了，WAF在0day攔截方面有著非常好的效果，那么大家就跟隨我一起，實際做下這次的struts2 0day在waf上的防御吧。
首先讓我們先對struts2進行下漏洞分析。
首先diff代碼，發現刪除了LocalizedTextUtil.findText(......);。由于這次poc也很快放出來了，時間原因我們取個巧，一會，邊觸發poc邊單步調試。
以上我們只通過diff代碼向上回溯LocalizedTextUtil.findText函數的調用關系，便找到了重要信息：該漏洞的觸發是在content type中，而且包含multipart/form-data時。
但是跟進了下findText尋找觸發命令執行的關鍵點，并沒有發現什么有價值信息（分支條件很多，不知道走到哪了）。這時候，poc上場（如果沒有poc，這個分析將會技術要求很高了）。
Poc如下：
header["Content-Type"]="aaa_multipart/form-data %{#_memberAccess=@ognl.OgnlContext@DEFAULT_MEMBER_ACCESS,@java.lang.Runtime@getRuntime().exec('calc')};"
單步調試，發現走到evaluator.evaluate(var)，彈出計算器。
分析之后，漏洞成因已經很清晰了。
Content type中包含multipart/form-data 而且內容包含%{….} 、 ${….} 的，中間內容會被當做 ognl 表達式執行，從而引發命令執行。
上圖是做 %{….} 、 ${….}的判斷。
通過分析后，把相關規則上到WAF上，保證了WAF攔截的有效性和防繞過。
關于監控，主要的思路是數據采集+數據分析。而采集方面，包含的內容非常之多，我們這里只看下通過hook大法實現的安全監控。這一類監控通常是在漏洞發生的最根本位置進行惡意識別，所以其獲取到的報警通常效果最好。
例如常見的SQL注入漏洞，好一點的情況是最外層有waf做攔截，但是waf存在各種各樣的繞過&誤傷等等，況且很多公司根本沒有沒有部署WAF。同時掃描器針對這種漏洞掃描起來也比較困難，需要考慮多種注入方式。那么如何有效的對SQL注入進行識別，做到：如果存在注入攻擊便及時報警呢？hook 數據庫拿到查詢日志并進行分析是一個很有效的方案。為了簡化，這里直接取數據庫的查詢日志log做分析（實際場景采用DB Proxy類技術會有更好的性能和穩定性）
由于每次的請求（包括攻擊請求）已經轉化為對應的數據庫查詢操作，故已經無需考慮編碼解碼、引號閉合等問題，只需要關注是否存在異常的查詢。例如：如果存在 union all select null,null 這樣的查詢操作，便為明顯的數據庫注入測試行為，并且關鍵的是，這種行為已經完成了引號閉合等動作，是一次成功查詢。
那么現在要做的，就是格式化查詢，最終匹配出惡意查詢行為并報警。
在演示例子中，我們實現了對查詢進行語法解析并且替換字符串的功能。
圖上第一行為原始查詢，第二行是經過解析和字符串替換后的查詢，可以清楚的看到，
第一次查詢為正常的業務請求
第二次查詢被解析成了select xx from xx where name =’s’ union all select null,null --。這是一個明顯的注入測試操作并且匹配了union all select null,null的規則
第三次 實際上仍然是黑客在做注入測試，只不過沒有成功閉合引號，一大串查詢測試僅是被當做成了一個長字符串。
通過這種方法，僅需要預定義幾種注入攻擊特征，便能很高效的對SQL這種攻擊進行監控識別。
PHP引擎的hook以及redis的hook也是類似原理，從最根本層面發現入侵行為，排除其他干擾因素。
篇幅的關系，這里不詳細介紹。
我們再來看看基于流量的監控。其實這一塊很早大家就在做，傳統的IPS、IDS就是做的這塊，也有很多人搭建開源的snort等系統。但是實際效果來看，這些硬件、軟件系統都沒有發揮太大的價值，究其原因，有可能一個是規則方面的問題，數量大而又老舊；一個是理念方面的問題，只著眼于一個方向的特征識別（請求或返回）。
其實基于流量方面的監控（這里指外部流量，非IDC內部），能做的事情非常的多，但是還是那個問題，覆蓋的太多 or 太寬泛，都會導致報警指數級增加，真正有用信息被淹沒。另一方面，外界的各種掃描是無時無刻的，這些信息觸發的報警實際上是無價值的。
如果只關注有效入侵&攻擊成功的高危漏洞，整體量級就會小很多，而且這些才是我們真正需要處理的。
在基于流量的監控方面，大帶寬下數據包捕獲是一個很棘手的問題。好在現在有PF_RING、DPDK等高性能數據包捕獲方案做支持。這兩種方案，都能達到線速收發，而新的瓶頸，似乎放到了如何快速解析4層or 7層協議的問題上了。
而在入侵行為的識別上，現在普遍的一種觀點是識別請求與響應報文，通過匹配兩個方向，找出已經入侵成功反彈shell 上傳shell等，或者利用高危漏洞（例如redis 遠程命令執行、代理漏洞等）成功的情況，這種報警一般非常準確并且不像是傳統IDS那樣量級巨大。
最后，我們來看一下以這次的struts2 為例，應急響應的流程該如何做。
如上只是一種推薦的應急響應流程，具體實施還得看企業的安全能力、漏洞種類等多種情況。
最后，其實一個企業能不能做好安全，技術只是一方面，同時還要看公司整體的支持、公司領導的支持、體系架構的建設等很多管理因素。但是不管現階段如何，總有方法可以改善并且做的更好。
1.發現被黑客利用 ST2-045 漏洞攻擊，如何第一時間修補漏洞降低損失？
百度小灰灰：我們經常遇到的case是，當一臺機器被入侵后，黑客有可能會將這臺機器種植后門，當做跳板，進行內網漫游，進一步入侵，時間通常很快。這臺機器如果不停，一條魚會攪得一鍋腥味，影響到期他機器，影響將擴大。
所以，建議先下線服務，或至少把外網先下了，再進行安全排查，看是否有可疑進程和網絡鏈接，如果判斷確認沒有問題，就可重新部署服務，強烈建議重裝系統再部署服務。
對于修復，建議替換成官網最新的 struts2 的 jar 包。經常遇到的問題是，業務線系統非常久遠，老的 jar包替換成新的 jar 包，會遇到很多不可預知的問題，這時建議使用 filter攔截器攔截content type中的惡意內容。
2.對于類似漏洞，企業今后應該做好哪些方面的防護體系？
百度小灰灰：把問題扼殺在萌芽中通常效果最好，也就是說，在編碼階段，就要防止很多漏洞。比如，SQL 注入，要求開發者強制使用參數化查詢，不使用拼接的方式。同時，大多數企業有很多安全設備，這些設備的最大問題是沒有對規則進行精細化設置，導致很多設備報警過多，都不知道哪些是真實有效的，處于無法運維狀態。所以，要優化規則，高優關注攻擊行為。
如果企業自身安全能力有限，做一些外界的眾測，也比較有效。但是做眾測不是單單為了找漏洞，更重要的是反饋企業的應用存在哪類問題。比如，眾測發現企業存在兩三個 SQL 注入的漏洞，就需要告訴我們的開發人員，可能有大量這些漏洞的存在，我們需要排查，解決類似問題，同時設定相應標準，以后用安全的方式避免問題再次發生。
3.對系統漏洞怎么進行評估風險，確定修復的必要性？漏洞修復的流程步驟如何？對于像大規模主機的漏洞修復又該如何進行修復更科學或快速？
百度小灰灰：如何評估？比如，linux 有些系統組件存在存在溢出問題，有安全風險，這種漏洞通常在入侵到內網后才能觸發，修與不修，安全整體收益不大。但是，如果修復，產生的不可控性比漏洞更嚴重，甚至會引發中斷業務，這種業務就不能接受。
比如，glibc版本過低，使用gethostbyname()可能會造成安全風險。但是貿然升級glibc會導致大量的依賴風險，對業務可能造成巨大影響。推薦的方法是，排查對外業務，如果使用了gethostbyname()，需要進行升級。否則內網中大量系統，不升級風險也不是太大。
漏洞的修復步驟，我只說下 WEB 漏洞的修復，系統漏洞方法類似。建議安全人員指導研發人員來修復，比如，SQL 注入，安全人員會對開發人員說，xxx 處存在 xx 類型的 SQL 注入漏洞，使用參數化查詢，不要用拼接的方式，同時告知該漏洞的具體風險。而開發人員對參數查詢很清晰，修復起來很容易。對方需要知道的是漏洞的類別、危害和修復方法的方向，如果能給他代碼級的修復方法更好。所以我們也可以寫文檔，總結常見漏洞的修復方法，讓他學習和修復，但是他修復完你必須進行復測，如果復測沒有問題，工單或者流程就可以關閉。
針對大規模主機的漏洞修復，如果規模很大，勢必會有統一的運維系統去進行操作、部署，不會讓你一個一個去安裝。所以，你要和運維人員溝通，為什么必須修復，給出必要性，讓運維人員進行灰度測試，比如，有 20 萬臺機器，先對2000臺機器進行灰度測試沒有問題，，再上一些機器測試，按部就班地進行。
4.請您推薦下比較好用的開源掃描器。
百度小灰灰：其實，我之前也推薦了 W3AF 的掃描器。為什么選它，一則是用Python語言寫的，安全工程師一般對python上手很容易。其次，這是開源掃描器，我們主要是借鑒掃描思路，甚至可以自己寫一個掃描器。比方說他的audit審計模塊，會包含大量常見漏洞的檢測和判斷方式和規則，參考這些規則就知道如何去實現一個掃描器了。
5.怎么才能成為您的同事？（實習生、正式員工）
百度小灰灰：
實習生：要求有安全背景、大量攻防對抗經驗。
正式員工：要求更高，需要是在攻防領域比較牛的人。
一句話：能力強就ok。有興趣的同學可以發簡歷到 security@baidu.com 。
以上就是本次雷鋒網硬創公開課的全部總結文，如果想看到更多網絡安全干貨，請關注雷鋒網宅客頻道，多多參與雷鋒網硬創公開課。如果你有特別期待的嘉賓，也可在雷鋒網宅客頻道公眾號里留言，或許，你的男神/女神就會來講課啦！
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
專題
