一個人的「安全部」

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

前言

我在某教育公司負責公司整體安全，保護6000多萬「熊孩子」的安全。一年半的時間從什麼都沒到現在的逐漸成型，此篇文章進行了一個總結，期間也碰到了的很多坑和坎，這裡再次感謝幫助過我的朋友們，感謝MottoInTeam小夥伴。

由於涉及到企業攻防，有些內容的細節部分這裡不方便展開。

對本篇文章有任何問題都可加我微信一起探討WeChat:atiger77

目錄

0×01. 情況概述
0×02. 運維安全
0×03. 業務安全
0×04. 應用安全
0×05. 內部安全
0×06. 總結

0×01情況概述

公司產品主要是一款教育類APP，後面我會分運維安全、業務安全、應用安全、內部安全和碰到的問題以及解決方法進行展開。

如果你的公司像我一樣只有一個人或者幾個同學負責，我建議把重心都放在存在的安全問題上，比如業務場景中的薅羊毛，刷單等，用戶模塊的掃號，盜號，業務安全線的安全測試等。

先處理這些直接會帶來損失的安全問題再逐漸完善，一點點進行橫縱向擴展。

0×02 運維安全

剛入職所在的公司因為沒有安全部門，我是運維安全的崗位進入了運維部。我在原有的基礎上又做了一些安全提升，這裡提一點如果公司沒有安全同學，對於運維同學而言，把控好安全基線也可以在一定程度上抵禦一些攻擊。

devops里的一些運維自動化工具比如ansible, saltstack,puppet等，以ansible為列在初始化的role里就規定安全的基線，如：SSH禁止ROOT登錄、修改SSH默認埠、禁止密碼登錄、新建普通用戶、設置別名把「rm -rf」類似命令進行替換等等。

保證交付給開發的機器都一樣，比如軟體的安裝目錄，由於歷史原因有一些記錄上的環境都是開發自己安裝的，導致會出現很多個nginx目錄，處理起來非常煩需要確定到底運行的是哪一個目錄下的nginx才可以繼續操作。

當然建議公司使用堡壘機，上了之後對許可權的管控對伺服器的安全又可以提高一個保障，之前也調研過目前堡壘機情況，具體的可以細聊。

除了伺服器，資料庫的初始化也同樣重要，初始化只給開發普通帳號並賦予對應許可權，設置連接白名單不允許非名單機器進行連接，密碼一律多位數複雜密碼。

作為安全運維這塊必須記錄所以外網IP及對應埠，所以伺服器對應的服務，由於每個公司情況不同，有些是安全部記錄有些會是運維部把控，根據自己的情況來即可。

a. 外網IP及對應開放埠

除了解析商那裡的記錄自己必須保存一份最新的，之前碰到過一個情況自己在做外網IP掃描的時候發現有一個IP開放了一個埠，爆破發現使用了弱密碼，平台的內容會對公司造成影響，先停止這個轉發通知開發進行整改。

對於這種情況有兩點，一是嚴格把控要求外網IP的要求，對於一些敏感業務若沒有經過安全測試不予提供外網訪問。

二是記錄所有外網IP及開放埠情況，有相關自己平台的可以添加一頁，沒的話可以記錄到confluence中即時更新。

b. 伺服器對應提供的服務

這些年爆出了大大小小一堆的漏洞，每次收到還都是下班以後orz。具體漏洞修復方法這裡就不具體闡述了，有興趣可以看之前寫的一篇文章：http://www.mottoin.com/92742.html

每一次高危的漏洞都是對安全人員的一次考驗，就是和時間賽跑晚一點服務就可能被黑，這裡主要講一下我從收到漏洞預警到處理的一個流程。

獲取漏洞信息

可以多訂閱一些高質量的公眾號，加一些相關的安全群盡量第一時間能知道哪個服務出了問題，收到的消息越早越是能給自己留多一點時間。

確定漏洞影響範圍&嚴重性

收到信息之後就要確認漏洞的影響和範圍，這個服務公司是否部署，部署的是測試環境還是生產環境，分別有多少台，漏洞的觸發條件是否苛刻，造成的影響有多大等問題。

如果自己無法判斷漏洞嚴重性的話可以多和朋友交流溝通，不要盲目的去修復升級，某些版本升級好性能兼容性可能會出現問題。

對於影響範圍之前也點到過必須記錄伺服器上部署的應用，在漏洞出現後可以快速定位而不是問開發你有沒有部署xxx服務，我是記錄在了運維的CMDB中

內部測試

我舉兩個漏洞為列， 一個臟牛漏洞，一個應用漏洞。

臟牛漏洞的影響力不言而喻，除了本地使用容器服務的同學記得要把baseimage也做對應的升級。確定了嚴重性以後找出公網提供web服務的對應機器，先用長亭的方法做線上應急操作。

然後找對應補丁對內網測試環境進行升級測試，由於是內核漏洞觀測的時間比較長確定沒問題在一點點的升級其他主機。

某應用漏洞，由於這個服務不對外提供服務所以緊急程度沒有臟牛來的這麼緊，同樣的找一台測試機器安裝高版本確定不受影響後讓測試同學幫忙做壓測，看新版和舊版性能差異，如果沒問題就上一個下一個直至全部升級完成。

上線觀測

這裡切記，並不是上線就沒事了，上線之後必須再做一次複測確定沒有問題並持續觀察服務穩定性，做好隨時回滾準備。

0×03 業務安全

只要公司到一定規模了都會碰到這些情況：掃號，撞庫，垃圾註冊，刷單，刷券，羊毛黨，競品攻擊，DDOS等等。

先說DDOS，根據一年的情況發現到年前年後，熊孩子開學，活動上線都是DDOS的高發期，對於流量攻擊我們選擇了一家做流量清洗業務的公司幫助我們做惡意流量的清洗，關於具體選型的話可以私聊。

接著說一下對其他情況的處理，這些情況都是互聯網公司常見的現象，只要規模上去了，有利益可以拿就會被攻擊。

想有效的去發現異常，阻斷異常需要一個完善的風控平台，我講一下我這邊風控是怎麼做的以及碰到的一些坑和對應接的方法。

首先要知道做風控是為了解決已經出現的安全問題並能即時的阻斷，剛開始做不要盲目的模仿大公司的玩法。

大公司有自己專門的團隊去做這個，盲目的模仿不但沒解決問題反而起到了反作用，一開始做也別想著可視化，可視化是在功能都成型了要向上級展示的時候在考慮的東西。

找到出現的問題，溯源問題的原因，並採取對應的策略。

做風控必須要有數據，沒有數據的支撐是無法做風控的。關於數據我的理解是這樣：風控使用到的日誌有別於BI日誌和業務日誌，安全日誌是可分析異常用戶行為，攻擊趨勢的增長情況，最後做到先於攻擊者進行阻斷保護系統安全穩定。

在和公司相關同學溝通的時候他們也會問一些問題，我總結了下。

Q：安全日誌 和 應用日誌 以及 BI日誌 有什麼區別？

A： 共同點：三者都是記錄業務產生的動作行為。

不同點：應用日誌本身只是查業務是否正常性能是否達到預期，切重於業務本身。

BI日誌根據事前埋點收集用戶行為進行分析為各個部門提供相關數據分析，如事件漏洞，轉換率等等。

安全日誌主要記錄安全相關信息，細化到哪一個用戶在哪裡用什麼設備進行了什麼動作並嘗試了多少次，切重於業務安全。

Q：有了BI日誌還需要安全日誌嘛？

A：需要。首先BI日誌目前沒有涉及到公司所有業務，BI的日誌並不是為了安全而生更重要的是為其他部分提供數據支撐，從而更好的掌握用戶需求。

安全日誌和BI日誌必然會產生交集，然而這並不衝突。對於風控策略而言安全日誌是實時可查看的，第一時間可以知道當前時間的狀態，BI日誌是事後進行統計數據廣度更大，兩者結合更能保障業務的安全。

Q：安全日誌主要記錄哪些內容？

A： 安全日誌需要記錄誰在什麼時候用了什麼東西幹了什麼結果是怎麼樣，等一連串用戶緯度指標。

和相關同學都達成共識以後就可以開始執行了，我使用ELK對日誌進行收集分析，logstash_agent把安全日誌output到redis中，再由一台logstash_indexer取redis中的數據output到ES集群中，最後通過kibana進行展示（安全日誌的格式，部署等細節可以私聊不佔太多的字了）。

有了數據以後通過kibana的聚合就可以發現異常的問題了，由於牽涉到相關數據我就不截圖了，以用戶模塊為例就可以有很多的判斷緯度，仔細觀聚合後的數據就可以發現對應的安全問題。

那麼這些緯度大部分都是基於行為的判斷，除了行為的還有基於特徵的，比如用戶的手機號是否執行過欺詐行為，我測試過某安的反欺詐產品結果還不錯。

以上這些都是不同的規則有基於行為的也有基於特徵的，規則都是一個判斷的緯度但不是觸發了規則用戶就一定不好，為了降低誤殺率我們會給規則定分數。

當一個用戶總分到了閾值那麼會直接對他做功能限制等操作，如果觸發高危動作也會直接阻斷，具體策略每個公司都不一樣根據自己實際情況制定即可。

如果有人力的話也可以把日誌導入到Storm里根據自己的需求用bolt去做一些統計，要高可用的話推薦用flume+kafka+storm的架構去處理。我現在是使用Python去進行分析處理，根據自己情況選擇一個合適的即可。

當我這邊的程序發現異常時會自動的給用戶打上對應標籤並同步到BI的系統中進行記錄，同時為了不給客服同學帶來壓力這個標籤也會同步到客服後台中方便她們進行查看。

講一下羊毛黨，有了風控數據我發現每天都會有惡意註冊，反溯這些帳號以後發現這些號里都有我們的活動券，根據活動券內容確定是哪個活動，詢問相關產品活動規則策略，詢問開發活動頁的校驗機制並自己黑盒在測試下，確定不是因為漏洞導致的就開始做自己的提升，風控就是一個攻防的對壘。

對應措施：

a. 提高註冊門檻；機器識別，人機對抗，驗證碼機制

b. 修改產品策略；調整產品策略，

c. 優化風控規則；異常情況簡訊認證，

對抗羊毛黨是個長期的過程，隨著你的機制升級了，他的機制也會隨之升級，就是成本和利益的問題，那對於甲方來說就是不斷提高自己的門檻增加攻擊的成本，把實惠給到真正的用戶上。

現在也有很多安全、風控團隊在分享的時候會講到機器學習，通過設定的模型來判斷異常用戶，但是具體分享細節的比較少，由於公司里很多機器學習方面的科學家，向他們學習以後我這裡把我用到的一些機器學習方法和大家分享一下。

我覺得在風控中機器學習的優勢在於，基於大數據不斷的提煉調優模型會越來越完善，可以通過訓練後的模型找出一些規則沒有命中的異常用戶，在逐漸的完善規則。

之前有看到過有同學用隨機森林去判斷異常流量的，我自己有一個模型是判斷註冊用戶是否異常的，模型的分數如下：

可以看到模型跑出的分數很高，我的樣本是根據規則判斷的，所以最好的情況結果就是逼近規則，需要一直對模型進行迭代去提煉更多的規則，繼續調優參數，讓模型判斷不單單限於幾個限定的樣本規則。

0×04 應用安全

由於只有一個人，SDL在公司很難去推行，快速迭代的版本上線每次檢測到的漏洞一問都已經上線了好幾個月，這也是挺被動的一點。

開發的安全意識和水平都不一樣，也出現過線上業務出現SQL注入的問題，我是搞過一次全員的技術分享，講一下主流的一些WEB漏洞和一些邏輯漏洞，讓開發有一個印象。

我主要這樣做記錄開放公網的web服務每周都用掃描器去跑一次，對於大版本的升級我會自己再測一次。前段時間同程開源了一款內部漏掃工具-巡風挺不錯的，也希望有越來越多的安全公司開源一些好的項目。

備註

項目地址： https://github.com/ysrc/xunfeng

Medicean Docker版本：https://github.com/Medicean/VulApps/tree/master/tools/xunfeng

Atiger77 Docker版本：https://github.com/atiger77/XunFeng_Docker

詳細介紹&&ubuntu安裝方法可以看:http://www.mottoin.com/94253.html

公司主要的產品是app，對於移動端的反編譯這塊我不是很熟悉找了一家公司做過滲透測試，測試下來也會發現一些問題，和公司安卓的老司機交流以後確定修復方案。

端的東西加固就是讓攻擊者噁心，真的要破解理論上都是可以的畢竟所有人都可以下載研究，只是增加攻擊者的破解成本。

APP的反編譯主要還是針對安卓，網路層面用https+ Pinning在一定程度上增加了抓包的成本（IOS市場將不再支持http協議的app，如果還沒升https可以儘早升級）。

端的加固主要是保證apk不能被重打包，主代碼做混淆，公共調用部分做人工混淆，so文件不允許被調用，不允許模擬器調試等等的加固手段。

APP的升級不像網站，修復漏洞以後測試過就可以上線（有些框架支持動態更新），移動端會有版本問題，用戶用著有問題的版本除非系統大的升級否則不會讓用戶進行強更（太影響用戶體驗了會導致用戶流失）。

對於APP的情況可以這麼做，降低低版本的功能使用限制。對過低的版本使用人數也少的可以要求產品進行強制升級的操作。

最後說一下數據存儲問題，最近一直會流出被泄露的庫有些庫密碼就是簡單的Md5+salt，撞庫一下就可以跑出大量的用戶密碼，無論是對企業還是用戶都會造成傷害。

有能力的話還是建議設計加解密服務專門有一台機器進行加解密計算，把用戶的敏感信息（任何能聯繫上用戶的信息都算敏感信息，不單單是密碼）進行加密，這個我是沒推成功，因為收益在不出事前很小甚至是沒有。

如果這個推送不動還可以推一下加密方案，關於加鹽每個用戶應該使用隨機鹽的方式進行加密存儲，目前大部分的公司都是使用固定鹽的方式來生成每個用戶的密碼。

這個改的話都需要和業務方進行深入溝通，如果在項目剛啟動需求討論的時候就提出會很好，一旦項目起來了再改會比較困難。

0×05 內部安全

內部安全說兩方面，一個是內部訪問的一些系統比如XX後台，這種可以查看到敏感信息的平台。另一個講一下人員的安全意識和辦公網的安全。

第一是內部的平台，重要的內部平台也需要做安全日誌對於一些高危規則做到實時的報警，如果沒有WAF的可以使用腳本簡單模擬一下，比如單位時間內調用登錄介面等行為做一個報警，設計到修改金額的面板必須做到實時的記錄。

含有查看用戶信息功能的平台需要記錄使用者的操作日誌，方便做到審計，和開發同學確認做好許可權把控，要對這些平台做好安全保障。對於資料庫而言可以做蜜罐表，一旦有觸發也立刻報警。

內網可以部幾台低交互的蜜罐掛著，之前有寫過一個有需要的朋友拿來改改就能用https://github.com/atiger77/Dionaea。

第二個是人員的安全意識，入職這家公司以後做的就是內部安全的提升，統計了下第三方對外的平台然後社工了下幾個同學一個個破掉他們的帳號並發出郵件告知（授權行為進去截個圖就可以了）。

然後要求對所以外網的一些平台都要求二次認證。內部的話每次新同學入職都會加入網路安全，給他們講講一些常見的詐騙方法提高自身的安全意識。

還有一個，定期掃github上的代碼，發現有自家業務代碼的直接讓他下線，有時候也可以發現一些競品公司寫的代碼，厲害了。

0×06 總結

我把這一年半的東西都簡單概述了下，顆粒度再細的可以加我微信聊。總結了幾點：

1.

沒有老闆支持一切都是吹牛逼

2. 先做最緊急的需求，全部解決以後再考慮可視化；東西丑不重要 關鍵是管用，東西再好看解決不了問題也是白搭；

3. 必要時可考慮商業化產品/合作，如堡壘機，滲透測試等；

4. 統計公司相關資源如外網IP,機器部署服務，別到了漏洞爆發在去問開發你的機器有沒有部署XX服務；

5. 做好外部控制別忘記做內控，有時候內部安全事件比外面攻擊更可怕；

6.多和公司老司機聊聊天，你碰到的一些坑他們可能也遇到過，一些架構上的設計、冗餘、優化方案都可以多找他們討論下；

每個人的精力有限不可能什麼都面面俱到，多和公司的老司機交流有些東西他們可能都接觸過了，沒事找他們吃吃飯交易交易會有意想不到的收穫，比如告訴你Strom的任務優先順序控制，架構的選型問題，機器學習的一些玩法等等。

在沒有人力的情況下不要一味地模仿大公司的玩法，找到自己公司出現的問題並著手解決，必要的時候可以藉助外部的力量（前提是你公司有預算）。

「你之所以看不見黑暗，是因為有人拚命把它擋在你看不見的地方。」向所有做安全的好同志致敬。

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