1. <dd id="qqztp"><noscript id="qqztp"></noscript></dd><li id="qqztp"></li>
      <th id="qqztp"></th>

      <dd id="qqztp"><pre id="qqztp"></pre></dd>

      En

      自研之路:騰訊漏洞掃描系統的十年歷程

      作者:lake2公布時間:2015-12-16閱讀次數:164925評論:18

      分享


      【前言】

       

      在業務的生命周期里面,測試階段——不管是上線前測試還是上線后測試都是安全團隊的重要戰場,歷來為兵家必爭之地,所以這里成就了漏洞掃描系統(這里指系統和Web漏洞)。漏洞掃描系統的市場非常火爆,很多安全公司都出售自己的漏洞掃描設備或者提供遠程漏洞檢測服務。

       

      但是對于大型企業,特別是在線業務龐大的大型互聯網企業來講,服務器和Web站點眾多,且發布變更頻繁,傳統的商業漏洞掃描器往往不能滿足其大規模和定制化的個性需求,這里就產生了自行研發的需求。

       

      “十年生聚十年教訓”,騰訊自2005年就開始研發漏洞掃描系統,迄今為止正好十年,歷經了三代架構變遷,最近正好在總結規劃,于是我就順便把騰訊漏洞掃描系統的一些建設經驗和教訓分享出來,供同行參考。

       

       

      【石器時代:艱苦創業】

       

      騰訊安全平臺部的前身騰訊安全中心剛剛成立之初,準備自動化的發現和清理安全漏洞,所以就產生了使用漏洞掃描系統的需求。當時公司又發布了《高危端口管理規范》,推動業務把對外暴露的服務控制在Web層面(簡單理解就是非HTTP端口無必要不對外開放),所以就可以集中精力來保證Web安全。

       

      那時條件比較艱苦,整個團隊也就幾個人,也沒有專業的開發,所以當時采用的方案是開源的Nessus做系統漏洞掃描,NiktoWikto等加上自己寫的Perl腳本來做Web漏洞掃描。那時網站還沒有現在那么多,系統對外暴露的比較少,這套方案勉強滿足了當時的需求。

       

      其實說起原理來也比較簡單,漏洞掃描系統的常規工作模式無非是基于HTTP協議的請求發送和響應檢查(正則匹配),而Perl自身的LWP包(當然你也可以用IO::Socket自己來實現HTTP協議)就支持HTTP協議,所以用Perl寫一個簡單的漏洞掃描器非常方便。比如以下就是在2007年寫的臨時檢測Apache Expect HTTP Header XSS漏洞的Perl代碼:

       



      由于年代久遠,騰訊第一代漏洞掃描器的Perl代碼應該早已失傳——不過也不一定,或許在benjurrycoolc、熾天使他們老一輩無產階級革命家的某個塵封已久的電腦里能找到。不要小看這個簡易掃描器,當年它為騰訊安全立下了汗馬功勞。

       

      這個時期商業的漏洞掃描系統大致分為兩類:一類是Windows客戶端軟件,如IBMAPPScanAcunetixWVS、惠普的WebInspect等;另一類是硬件設備,一個硬件設備直接接入網絡工作,如綠盟的極光、啟明星辰的天鏡等。

       

       

      【鐵器時代:初具雛形】

       

      隨著時間的推進,Perl掃描器的各種問題就暴露出來了。

       

      首當其沖的就是Perl代碼是解釋執行的,執行速度慢,也沒有分布式任務,整體效率非常低下,往往檢測一遍全部業務要花很長時間。加之當時Web 2.0時代,Web業務急速膨脹,在線業務也經常會有更新,這時候安全團隊迫切需要一個更快速的漏洞掃描系統。

       

      時勢造英雄,當時正好有新的血液加入團隊:來自武漢大學的mango。信息安全專業在2002年首次在武漢大學成立,mango正是當年的首批畢業生(關于他在騰訊經歷可以看他的文章《武大學子在騰訊做應用安全》)。他一來就在做Web安全,積累了一定經驗,開發功底又比較好,所以新的漏洞掃描系統的就由他當時的導師apple(騰訊掛馬檢測系統之父,業內首創JS解析檢測掛馬攻擊,我也有幸作為運營人員為掛馬檢測系統配置了第一批規則)帶著他一起做了。

       

      新的漏洞掃描系統使用C++開發,掃描節點分別部署在幾臺服務器上(節點很容易安裝部署,方便擴容),還有一個總控的任務調度服務器,采用爬蟲先爬行URL再檢測的方式,支持像SQL注入、XSS、命令執行、任意文件讀取等大部分常見的Web應用漏洞。

       

      這個階段基本也沒有研發流程,主要是靠mango自己開發測試甚至運營;漏洞處理流程也是剛剛建立,就是檢測出漏洞后運營人員確認無誤報后通知到安全接口人處理——我畢業那會兒剛到騰訊的工作職責之一就是這個。

       

      還記得當時XSS漏洞原理并不普及,而我們的XSS漏洞驗證PoC就是alert彈框,導致很多開發人員誤以為XSS漏洞就是彈框,進而認為這不是漏洞,往往會挑戰這里的專業度,然后我把PoC改成了類似下面這樣的代碼,一切都迎刃而解了(運營思路是多么重要)。



       

      這里還有個坑要注意,漏洞掃描系統在檢測生產環境時一定要避免進行破壞性測試或者要對破壞性測試有應急預案(這是另外一個話題了,參見這篇《安全產品的自我修養》)。當年mango用延時法檢測SQL注入漏洞的時候把業務數據庫掛起了一段時間——這是一個一秒鐘幾十萬上下的業務,我們把花了巨資買來的教訓無私奉獻出來了,請點贊。

       

      新的漏洞掃描系統完成后速度和效率基本滿足了當時的場景。今天我們為了紀念mango當年的功勞,都尊他為騰訊“掃描器之父”。后來mango去了某銀行安全團隊,不再寫漏洞掃描系統,但是他的傳奇仍然延續——據說mango在新的單位負責滲透測試,在內網驅馳如入無人之境,以至于藍軍團隊不得不把他全程視頻監控起來避免他找到新的漏洞而自己不知道。

       

       

      【工業時代:全面開戰】

       

      mango之后薪盡火傳,新一屆畢業生接手了漏洞掃描系統。現在團隊壯大了,項目、研發、運營、安全各司其職。

       

      這個階段公司業務飛速發展,每年服務器和Web站點都在增加,IDC也在增加,跨IDC掃描會有速度慢、網絡不通、誤報、網絡阻塞等問題,所以團隊在之前的架構下優化代碼并大規模部署(基本上要每個IDC都有一個掃描節點,已成為IDC建設標配),同時接入SOC流程(2008年我們自建了SOC),所有漏洞通過安全事件工單來跟進閉環。

       


       

      名正言順,與流程對應的是配套安全規范的制定和發布。公司專門發布了安全漏洞處理規范,規定了安全的責任口徑、上線前安全檢測流程、漏洞處理細則(基本上外部報告的高危漏洞必須立即修復)、違反規范的處罰等。

       

      接下來又進行了一系列技術上的優化。

       

      隨著Web2.0的技術應用,傳統的HTML爬蟲已經不能勝任,所以研發團隊需要優化爬蟲。我們拋棄了舊版基于SpiderMonkey的爬蟲,而使用了基于瀏覽器內核的QtWebKit來解析JavaScript,這樣遇到類似JavaScript拼接或者ajax的頁面也可以暢通無阻了(這需要解決幾個問題,例如消除所有彈窗、支持代理、解決執行死循環問題等等,業界已經有非常成熟的實現方案了),這個新一代的爬蟲啟動后URL量立即新增了一倍多。除了爬蟲,QtWebKitJavaScript解析和模擬執行能力還可以應用到一些DOM類漏洞的檢測上,比如DOM XSSDOM Jump等。

       

      很多業務邏輯需要QQ登錄才能觸發,所以漏洞掃描器也增加了這個定制功能——市面上的商業掃描器還沒有自動支持QQ登錄的吧,當然他們的客戶也不需要這個功能。

       


       

      類似的還有一些跟QQ業務邏輯關聯的漏洞(統稱為業務邏輯漏洞),都做了定制化的策略,這些能力也是商業設備不具備的。

       

      即使如此還是有URL會漏,直接導致漏洞不能被漏洞掃描系統發現,所以團隊又集思廣益做了四件事情:IDS改造、Proxy部署、客戶端插件和業務提交——分別通過部署在機房入口的IDS、辦公網的HTTP代理、測試人員PC上安裝瀏覽器插件以及業務主動上報URL列表來實現最大化的URL收集。

       

      然后又遇到一個海量數據的處理問題。騰訊Web站點龐大,據不完全統計,把各種渠道收集到的URL去重后大概有兩千萬(未去重的全量就更多了),把這些URL放到數據庫中作為緩存,可以在快速模式檢測的時候直接檢測而不用再用爬蟲去抓取(這個有點類似知道創宇的ZoomEye)。海量數據放到MySQL后,效率完全跟不上,團隊又采用了Storm來解決這個問題

       

      這里就不得不說到快慢速模式,它其實就是一個速度優先或準確度優先的方案。快速模式可以迅速過一遍已知的URL,適用于新的漏洞出現后的快速掃描,目前我們能夠兩小時內檢測完全量URL;慢速模式就是犧牲速度提升準確度,適用于常規漏洞的日常掃描。

       

      新建一個系統的時候往往備受矚目,而系統建成后就會平靜下來,所以做實事的我們一定要避免“重建設輕運營”。

       

      在運營上,團隊一方面是優化規則,這個主要是通過漏報案例來優化。比如我們分析外部報告漏洞的時候發現有個白帽子連續發現很多高危漏洞,再從技術上分析他的手法,發現他是經常找一些偏僻業務,這種小業務的運維團隊安全意識很弱,非常容易出問題。于是我們也用掃描器增加了類似的掃描,采用“疑罪從有”的思路,每天人工去跟進確認,很快就把這塊漏洞清理完畢。

       

      另一方面是數據分析(嗯,用時髦的話來說就是數據驅動需求)。下面是2011年的一個報表,當時XSS漏洞量比較大,于是就深入分析出問題較多的部門和原因并進行了優化。比如當時某個部門線上漏洞多的原因是他們發布前未接入漏洞掃描系統檢測,于是我們的運營人員就拿著數據去推動該部門在測試階段加上這個流程。

       


       

      也得益于公司業務的蓬勃發展和部門的穩步前進,這個時期漏洞掃描系統也在快速發展,不管是系統功能還是人力都得到了增強,特別是后來圈內元老zhaohuan的加入,讓漏洞掃描系統如虎添翼。

       

      我們來看一下這幾年騰訊的外部發現漏洞趨勢圖,可以看到2013年起有一個明顯的收斂,一方面是因為騰訊安全應急響應中心的工作,另一方面就是漏洞掃描系統的發力。

       


       


      這個時期商業漏洞掃描系統進化成云服務,一些新興安全公司提供了基于云的遠程漏洞掃描的服務,如知道創宇的SCANV360WebScan等。同時互聯網巨頭如阿里、百度都已走上自研之路。

       

       

      【后工業時代:全新架構】

       

      雖然漏洞掃描系統取得了前述的一定進展,但是隨著時代的進步,我們又遇到了新問題。

       

      第一個問題就是漏洞轉化為規則慢。我們發現一個漏洞更新到規則或者修改一個規則至要花上好幾天,這是不能容忍的。再深入分析發現,原來舊的系統架構大部分核心規則是被編譯到二進制里的,規則還需要運營人員先跟開發人員講清楚原理和方案,然后開發人員再編碼,然后再編譯再測試再發布,結果導致任何規則變更都要重新編譯、測試、灰度部署,一套發布流程下來幾天就過去了。

       

      第二個是產品化問題。以前漏洞掃描系統就是運營人員自己使用,最多也給業務的測試人員用,都是技術流,又都是內部自己人,所以就是一個簡單的又土又挫的Web頁面進行配置就行。但是隨著騰訊云的發展,我們的漏洞掃描系統也會給到騰訊云上的用戶以及合作方使用,很多用戶是小白,根本搞不清楚這些配置參數,這塊用戶體驗也需要重新整改。

       

      最后是資源問題。漏洞掃描系統一般是通過單個線程或者進程處理同一個CGI的漏洞檢測,這樣就會阻塞起來,提高性能的唯一辦法就是采用多線程/多進程,但是頻繁的進程間切換就會耗費大量CPU時間,太多進程也會耗費大量內存,最終導致性能低下。之前是通過堆服務器的方式解決了性能問題,現在回過頭來發現架構上是可以優化的——嗯,是時候展示真正的后臺能力了。

       

      由于以上種種原因,我們決定重構,打造一個全新的漏洞掃描系統(內部代號:“C”),主要實現規則插件化、UI產品化、性能大大優化。于是“漏洞掃描系統重構項目”啟動,我們跨中心組建了包括安全、研發、前端、產品的十余人敏捷團隊歷時五個月完成一期工程。

       

      這個版本的主要設計思想是把平臺和規則分離,也就是說平臺只負責性能和調度,而規則由插件集合組成,一個規則對應一個或者多個插件。

       

      平臺由C++開發,插件是Lua語言。為了方便一些非專業人士(未來會對合作方和云用戶開放),我們把一些簡單的規則做成Web頁面編寫,比如輸入X,若輸出Y,則存在該漏洞這種簡單邏輯;對于一些復雜邏輯,可以用Lua來實現——你可以自定義任何HTTP請求字段乃至TCP/IP的數據包格式。

       

      以下就是一個簡單的Lua插件。


       

      新的系統采用全異步事件驅動、協程的方案來解決性能問題。這個方案立竿見影,服務器立即節約出來了。一臺8CPU8G內存的服務器一天可以掃描的CGI數大約是10萬個,發送的HTTP請求為2億個,是之前的N倍。

       

      來看一下系統架構圖:

       


       

      目前這套新架構已經在騰訊內部灰度上線,后續也會支持到騰訊云,所以騰訊云用戶將來也可以體驗到。

       


       


      插件化看起來是未來的趨勢,國內新一代安全公司如四葉草的BugScan、烏云的TangScan都是這種插件化的掃描器,而且它們直接是采用眾包模式來開發插件。

       

       

      【后記】

       

      總結來看,企業的漏洞掃描器不管是采購還是自研,都不是越強大越高級越昂貴越好,而是能適合企業當前乃至未來一段時間的需求,能夠解決企業所遇到的實際問題才行。

       

      十年磨一劍,騰訊漏洞掃描系統的十年發展歷程,也是騰訊安全團隊從小到大由弱變強的一個縮影,有幸能夠跟這樣一個積極上進、低調務實的團隊一起見證——業務發展、老板支持、團隊穩定三因素缺一不可。

       

      隨著漏洞掃描系統的更迭優化,運營中我們逐漸明白一個道理:安全是一個整體,安全風險并不是只依靠漏洞掃描系統能夠解決的。

       

      當你意識到這一步的時候,你又將踏上新的征程。

       

      評論留言

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