有了漏洞掃描器，如何用好？一點不成熟的小總結

*本文原創作者：安惞，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

昨天晚上做夢，夢見不知道在之前還是現在的哪家公司，跟同事老闆談hc，說到，當前最大的問題是，人力問題，是人力不夠。只有人力解決了，這個team才能運轉下去。

我就問，那你們團隊是做啥的呢？他說做掃描器和漏洞運營。夢裡就開始回想在以前公司中，各種方法有效的效率提高和人力節省措施，我就回了一句，人力當然重要，不然事情做不起來，同時在有一定人力的情況下，方法更重要。

接著，就開始就掃描器的使用高談闊論了起來。

啥？掃描器不就一個工具么？有幾個人不會用？

這裡就講一講在甲方互聯網公司，掃描器在具體實踐中的用法，個人淺見，歡迎交流分享……頭次發文，不知道會被噴到多慘……

一、掃描器哪裡來？

以前就職的兩家公司里，黑盒掃描器都是自研，白盒掃描器只有其中一家有。直到有一次某M公司來做分享，才知道，原來他們的黑白盒掃描器都是靠購買的，乙方提供產品和售後支持。

當時納悶兒，如果是乙方提供，就不怕到時候也不知道代碼，添加規則的時候不能滿足需求嗎？

M公司的專家解釋，以前M也是自研掃描器，但是發現的問題是，掃描器的開發維護團隊的目標，很多時候和具體運營的安全團隊是不一致的，更新規則的效率效果也比較不好說；而乙方由於提供給多家服務，樣本也更多，產品更專業，提供的服務也更好一些。

回想起原來就職的兩家公司里，除非掃描器的開發運維和安全工程師就在一個小團隊，否則這其中的多個環節也確實很難保證掃描器的快速迭代。

除了比較大的公司，如果是初創公司或者是快速增長期的公司，購買一款質量有保證，售後服務好的掃描器產品都是個不錯的選擇。當然如果能挖到專業的掃描器大牛過來，進行產品開發，不僅少走很多彎路，還便於內部產品對接，就更好了。

二、掃描器誰來用？

剛入行的時候，發現掃描器定期通過全流量，域名或ip，進行掃描，然後推送到SOC上，安全工程師來進行報警運維，以及後續漏洞的分發。這是對掃描器最早的用戶的認識。

隨著時間的增長，遇到了一群群特別牛叉的小夥伴兒，見識了，除了常規安全工程師運維，還可以將安全工程師以外的員工動員起來，畢竟，安全不僅僅是一個安全團隊的事情，而是一個公司，甚至還有公司外部人員一起來構建的生態。

三、掃描器怎麼用？

1. 常規黑盒掃描

收集和維護公司流量，ip和域名信息，對這些資產進行定期全量和增量掃描。

全量掃描，重點在於，要收集和維護公司的資產，並對資產進行有效的去重策略。周期要比增量掃描的周期長一些，這裡的重點在於全，而不是快。去重也需要一套完整的策略，不過此處不作過多展開。

增量掃描，對比原有資產庫，一旦發現有新增資產，立即進行掃描，這裡的重點在於要快。因為如果在歷史漏洞能夠有效修復的情況下，新增資產出現新漏洞或高危漏洞的可能性更大，需要儘快發現並處理。

2. 黑盒插件掃描

據Net Market Share 的7月份數據，佔據全球瀏覽器排行榜首位的是Chrome瀏覽器，總市場份額為48.65%。實際工作中，也確實不少的程序員喜歡用Chrome瀏覽器。甚至於，不少瀏覽器直接使用的是Chrome的內核。

在這個前提下，開發Chrome瀏覽器掃描插件成為了可能。

由於黑盒掃描基於URL即可掃描發現漏洞的特性，只要通過Chrome或其內核瀏覽器瀏覽過的URL，都可以通過插件進行收集抓取，並進一步進行黑盒掃描。

只要安全工程師將插件開發成功，並推廣到公司的開發和測試安裝使用，那麼開發和測試在線下環境中就可以自行檢測出漏洞，只要安全工程師準備好相應漏洞的修復方案，開發即可自行修復上線。

無需等待產品上線，將安全風險暴露到外面後，外部或安全工程師再倒推給開發修復。不僅是降低了安全風險，也節省了安全工程師的工作成本。

3. 黑盒自助掃描

仍基於拿到URL即可掃描或爬取漏洞的特性，可以將掃描器後台功能，開發成前台產品，供對漏洞了解並未達到專業程度的開發或測試使用。

產品形態可以就是簡單的輸入框，用戶輸入URL，點擊掃描，即可對該URL進行黑盒漏洞掃描。

對於更深度的用戶，也研發定期，批量，爬蟲或介面掃描等功能……可以做的事情就很豐富了。

4.伺服器掃描

這個原理是，抓取開發或測試的伺服器上的日誌，推到掃描器，進行定期自動化掃描。好處是一旦配置了，就能準確的收集到最新變動的代碼的日誌，並且中途無須人工進行更多的操作，只需等待結果即可。

需要注意的是，要盡量開發封裝的agent，而不僅僅是介面，因為封裝的agent在開發或者測試接入的時候成本更低，推廣起來也更容易。如果公司內webserver類型不統一，那麼可能需要開發Apache,Ngnix，lighttpd等多個適用版本來進行接入。

5. 白盒代碼掃描

白盒的代碼掃描，理論上也可以運用方法3中，輸入代碼路徑的方式進行自主掃描。還有一種方案就是，將白盒代碼掃描，封裝成一個腳本或者包，推廣給開發，在開發常規開發的時候，跑一遍腳本或者包，顯示哪裡的代碼可能會產生安全漏洞。

這個方案的難點有兩點。

一是，如果公司開發使用的是多種語言，那麼包的適配和開發上可能就需要花比較多的心思。

二是，白盒掃描本身產生的誤報，想做好控制也比較難，這就要在漏報和誤報間做好權衡，至少選擇添加誤報達到某一基準線的規則，並做好引導說明，否則容易敗RP。

6. 上線平台掃描

如果是比較專業的公司，代碼上線，一般都會有上線的平台或者系統做支撐。

如果在上線前接入黑盒白盒掃描，並對漏洞進行修復，更是事半功倍。

需要注意的幾個事情是：

第一，要和上線的平台打通，取得相應平台，以及平台的用戶的支持，這部分建議還是先走試點然後逐步推開。

第二，接入黑白盒掃描，不要等到最終上線那一刻再去掃描，而是盡量將掃描的步驟提前，進行預掃描，加快速度，提高用戶體驗。

第三，對於掃描的結果，哪些可以不修復就上線，哪些必須修復後上線，必須制定相應的策略，明確不修復上線的風險確認方式。

第四，對於掃描器掃描規則的維護，需要在安全自己的系統中，而不是上線的平台。這樣添加規則，設置白名單，能夠不受上線平台的影響，自己掌握主動權。

最後，任何一種掃描器都不能解決所有的問題，有必要的情況下，對於重點業務可以通過設定策略，添加人工測試。

四、掃描器怎麼維護？

衡量掃描器好壞最簡單的就是漏報和誤報率，如何盡量降低漏報和誤報，是掃描器安全上的最主要目標。當然，穩定性，效率，速度不可忽視，不過此處不做詳細說明。

1.漏報

漏報是難免的，重要的是每次發現漏報後能夠更好的處理和解決，並且和誤報做好平衡取捨。漏洞一旦通過各種非掃描器的渠道上報後，要有專門的人對該漏洞進行分析和規則添加。

這其中，疑似漏報的漏洞的通知規則和方式，根據漏洞類型進行初步的過濾和篩選，以及後續的規則添加都可以進行策略制定，這些都可以提高工作的效率。

此外，對於基礎資產，包括但不限於流量，域名，ip，代碼路徑相關信息，進行收集和維護，也是減少漏報的重要途徑。不過，大公司資產分布較多，初創公司基礎建設又有可能不完整，收集資產都是個不易的任務。

根據過往有限的經驗，如果安全團隊有人力的話，最有質量的方案，是將資產梳理和資產數據，通過各種方式，匯總到自己的平台上，自己進行維護。

如果依賴其他平台運維，後續無論是工作對接上，還是保證數據準確性上，都會有無窮無盡的麻煩。梳理資產確實是個比較需要耐心，恆心，毅力和溝通能力的工作。

2.誤報

這裡涉及到的是添加規則。如果是自研掃描器，非常非常建議，添加規則是通過動態配置，而非更新代碼。因為規則本身就是不斷變化的，如果每次規則變化都依賴開發，後續的麻煩，你懂的。

最後，安全不是一個團隊的事情，而是聯合公司內外各種力量建立起來的生態。

任何一種掃描器也無法掃描出全部的漏洞。

向奮鬥在第一線的安全從業人員致敬。

*本文原創作者：安惞，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載