一個土鱉安全工程師的十年奮鬥史

2008 年，我是看著《我的華為十年》這篇文章進入這家公司的，當時我的總監就是這篇文章的作者家駿。轉眼雲煙，第一份工作做到了現在。

菜鳥入職

我入職的時候，公司規模遠沒有現在這麼大，北京地區的研發零星分散在中關村的幾個寫字樓，包括理想國際、普天大廈和銀科大廈。

我是在普天大廈入職的，記得當時是 12 月份，第一次冬天來北京的我，領會到了啥叫冰火兩重天。

在武漢是沒有暖氣的，屋外四度，屋裡也是四度。北京是有暖氣的，屋外零下十度，屋裡起步價二十度。

公司里不少大姐大哥在公司裡面穿的和夏天一樣，出門套個大棉襖正合適。

我沒經驗，帶著一身毛衣毛褲來的，結果在外面還是凍死，在公司里熱死。

我大二的時候開始給華為三康做一些項目，在公司裡面是不能上外網，而且都是又重又大的台式機。

入職的時候，行政小哥發給我個筆記本，我當時一激動就問了一句，這個回家加班可以用不？

行政小哥一臉懵逼，為啥不可以呀。

剛到北京的第一個月我是住在南二環的親戚家，公司在擁擠的宇宙中心中關村，每天基本我就跟取經一樣，天蒙蒙灰就出門，天漆漆黑回家。

第一個任務：防火牆雙機上線

每一個自己覺得自己很牛逼的公司，都會有一個精心設計的新員工培訓，有的像傳銷，有的像傳教，有的講情懷，有的憶苦思甜。我對新員工培訓唯一的印象就是別在公司抽煙和養寵物，其他隨便。可見當初一定有個在公司抽煙又養寵物的人把大佬惹毛了。雖然我不抽煙，但是我想養個小烏龜小金魚，也只能放棄。

我的第一個任務是做防火牆雙機上線，首先感謝組織信任，其次覺得專業好像有點不對口，我是個 rd 呀，雖然我懂點網路，不過也是寫過交換機的軟體而已。於是我硬著頭皮看白皮書，看配置命令，幸好一起升級的還有經理黃姐和一個老員工永校，感覺自己打下手應該問題也不大。第一個任務總不能搞砸嘛，我還蠻認真的畫了網路拓撲和配置回滾方案。其實仔細想想，雙機以前不就是一個防火牆嗎，現在就是再放一台上去唄。

為了不影響業務，我們選擇在元旦凌晨上線。上線的過程確實非常順利，簡單描述，就是把新防火牆放上機架，插上電，配置灌進去，接線，搭完收工。十分鐘不到搞定了，我都準備撤了。

老員工說，這才哪到哪呀，我們要驗證可以自動切換。新防火牆和老防火牆之間有兩根心跳線，匯聚層有大概 6 台匯聚層交換機，分別會連到兩台防火牆上，要驗證諸如心跳線段，上聯線段的情況。另外國內眾所周知的原因，分為南北網，聯通電信互通很差勁，防火牆上聯四根運營商的鏈路，還要測試這幾根線路斷的情況下的自動切換。於是乎，不停插拔網線，ping 新浪 ping 搜狐。測試完凌晨 4 點了，總算搞得差不多了。我記得我走出普天大廈的時候，居然看到了 2009 年的第一個日出了。

第一個項目：准入系統 BNAC

我的第一個項目是開發准入系統。所謂的准入系統，簡單講，就是上網認證，主機安全檢查加上網路許可權控制。滿足一定安全基線要求的終端才允許接入公司辦公網，並且根據不同的部門和職位，賦予不同的網路訪問許可權。

公司當時已經買了號稱全球頂尖的准入系統，不過在易用性和可定製性上差強人意。另外一個原因，我們總監最初在華為就做了第一套准入系統，他對準入的理解非常深刻，從他的角度來看，目前這個國外的准入系統，有線無線不能自動切換，不能和微軟的域管理集成，許可權管理過於死板，最坑爹是對網路設備有要求，捆綁銷售他們的防火牆。

這些在傳統企業不是太大問題，但是在互聯網公司就是硬傷了。於是我入職前基本就拍下來要自己研發准入系統。他老人家是理解深刻，我理解不深刻呀，從網上搜了個遍，還是一知半解。還好有個老安全工程師志剛領路，介紹了一些廠商進行交流，總算整明白咋回事了。於是開工幹活，整個系統分為客戶端，策略管理平台，測試管理伺服器和防火牆。防火牆由系統部的一個大拿負責寫網路控制模塊，現在這哥們是我們公司 CDN、流量清洗這些基礎設施的負責人。

客戶端的主機檢查模塊由我們另外一個安全工程師負責，他現在也是 BAT 某公司的高 P 了。其他都是我弄的，第一次寫網頁還有點小興奮，尤其是自己畫 logo，盡顯人文修養。我在學校用 delphi 寫了系的教師考評系統，在那個年代 dephi + sqlserver 是絕配，access 也面對小 case 也是 ok 的，因此我們考核系統也是 cs 架構的。慣性思維，我的客戶端也是用 delphi 寫的。為了支持使用 linux 辦公的同學，還開發了 linux 客戶端。

網頁完全是新接觸，用了當時比較新的 groovy。這個時期我接觸了大量新知識，這些開發語言還是其次，主要是認識了不少網路設備，接入層的從啥 hub 到二層交換機，三層交換機，還有啥無線 AP 和 AC。和部署實施比起來，開發這個階段是多麼美好的回憶，事實上我差不多 3 個月開發完了第一版，為了驗證有效性，我們打算在部分辦公區部署。於是我們開始殺熟，先在我們部門使用，我待人和氣的好脾氣也是這個階段養成的。

我們把我們部門的辦公區的接入交換機和匯聚層交換機之間傳入了防火牆。所謂的防火牆其實就是台伺服器，最早用的是 dell 的 2850。現在看起來 2850 的配置確實差的可憐，四核八G內存，六塊七十三 G 的大硬碟，還齁沉齁沉的。我一個人搬它還很費勁，經常要和一個叫大肉的老員工一起搬。

由於當時交換機的機櫃就在辦公區，我們的防火牆也只能放辦公區。別看 2850 配置不行，風扇確極其彪悍，一開機地動山搖，半層樓能聽見。經常可以聽到旁邊部門罵，誰這麼缺德把伺服器放辦公區，還讓不讓人上班生孩子啥的。

我們公司沒有花名這一說，但是我處於怕人知道我真名罵我，我很早就用花名了。差不多那個時候開始叫麥兜了，至少名字這麼可愛，大家罵的時候也有所估計，後來歲數大了開始叫兜哥了，這也是我網名的由來。

總被罵，確實也覺得對不起大家，所以一直到現在也待人客氣。還好除了吵，基本沒出現過斷網的問題，偶爾出現過奇葩軟體和客戶端不兼容的情況，也很快解決了。在那個蠕蟲病毒泛濫的年代，我們通過准入系統強制電腦安裝殺毒、安裝補丁、開啟防火牆等等，簡直就是功德無量，很多年都沒有發生過大面積的病毒感染，一直服役到現在，差不多有 9 年了。我到現在還記得家俊在部門會上說某某廠做准入幾百人，我們就搭進去個麥兜。

槍版網工生活

2009 年，全部門的重點就是建設新大廈，所謂的新大廈，就是現在我們叫的老大廈，就是西二旗旁邊那個百度大廈。當時網路工程師就三個人，大肉，秀英和永校，人手不夠就把我也搭上了。我是革命一塊磚，哪裡需要新員工哪裡搬。

這次真成網路工程師了。小時候覺得工程師很牛逼，工作後發現其實叫網工更合適，就和電工一樣。好在安全工程師說起來還有點黑客帝國的感覺，即使簡稱安工，也感覺和同仁堂的救命神葯安宮硫磺一樣牛逼哄哄的。不過我們這幾位網工可牛逼了，一個是 3com 和華為研發出身的，另外一個是 2008 奧運會的網路建設負責人之一，相比我就是渣渣了，而且還是業餘渣渣。

給我的第一個任務是生成全部網路設備的配置，大概是 500 多台有線交換機，200 多台無線 ap 和交換機的配置。當時在奧運會的時候，他們是規劃好 IP 地址後，通過一個 java 的程序手工配置參數後生成一個設備的配置，然後通過 securecrt + js 腳本 + 串口把配置文件灌入設備。有多少台設備就要手工配置多少次，不過這個已經比手工寫配置文件牛逼很多了。

當時對我的預期是把思科設備的文件改成華為設備的。我對網路設備的配置完全是工作後學的，半桶水都不到，也是這個時期我學會了思科和華為設備的使用和配置方法。我看懂了原來的程序後，發現其實把網路規劃體現到電子表格後，通過程序讀取數據，可以一次性生成全部配置。而且這都是純文本的活，用 perl 更合適。於是我重頭開始寫，差不多一周多業餘時間完成了 demo，當時我還寫准入在。

中間也出過不少問題，比如關鍵字寫錯了，思科的一些命令沒改，有些參數寫死了，最後又改了幾次才能用，雖然被罵的也挺慘，不過最後對我評價是超出預期，大大節省了網工的工作量，唰唰唰 10 分鐘可以生成全部配置。尤其是有次網工發現自己電子表格寫錯了，要是以前他需要一台一台配置去生成，但是我這邊重新 run 一下就好了。

那段時間我還在陪大肉升級交換機 OS 和灌配置的過程中自學了 CCNA 和 CCNP，現在也很懷念和大肉在信威大廈裡面灌配置的日子。那段時間玩命加班，幾乎 3 個月沒有咋過雙休，最後竣工的時候居然有了 19 天調休。一直到現在，如果面有網路經驗的安全工程師時，我總能扯好久，一直可以問傻別人，也是這段時間積累的。

內部安全建設黃金時代

這個時期是我們公司內部安全建設的黃金時代，很大一個原因是我們有了級別非常高的 CIO John Gu。John 長期在國外工作，一直做到幾個巨型企業的 CIO。相對國內私企，國外企業對安全重視很多。和 John 不用太多介紹安全的重要性，而是想好怎樣做好安全就可以了。為了有更好的視野，我們還挖來了埃森哲的架構師歐陽。大概有 2-3 年的時間，我們都有非常充足的預算的進行安全建設，我也開始帶 team。這段時間我的工作才開始接近我理解的安全工程師和甲方安全。

這段時間我比較系統的建設了內部安全體系，從企業殺毒、終端補丁管理、DLP、郵件安全網關、IPS、漏洞掃描器、上網行為審計、APT 檢測到終端安全加固、軟 token、堡壘機、應用虛擬化、硬碟加密、文件加密等。那個時期，負責互聯網公司的國外安全廠商的銷售，應該大部分認識我。這段時間，是我安全知識面擴展非常快的一個時期。一直到現在，我跟許多解決方案架構師溝通很順暢，也是得益於這個時期積累的知識。我後面可以承擔 PGM 的工作，有相當一部分原因是我對安全產品需求的感覺，這種感覺的培養其實也來自於我這段經歷。

雲安全部成立

在很長一段時間，我們沒有安全部，安全的職責分散在技術體系下不同部門的幾個組裡面。早期問題並不大，大家各司其職，但是當公司發展到一定程度後，對外的產品線日趨繁雜，內部的協同配合壓力日趨變大。於是在某年某月的某一天，我們幾個分散的小組合併成立一個新部門，曰云安全部。人員合併後按照每個人的技能重組團隊，我負責基礎架構安全的 team，曰 isec，職責範圍包括內部網和生產網。我的核心 team 成員也是從那個時候一直和我到現在，現在想想也真不容易。

與內網相比，生產網有趣很多，安全工程師的壓力也大很多。物理伺服器的數量達到數萬甚至數十萬，虛擬機以及容器數量起步價也是百萬級了，出口帶寬幾百 G 的機房遍布全球，涉及的產品線更是複雜到令人髮指，只要想的到的業務幾乎都有，想不到的沒準也有。相對內部網，生產網攻擊面大很多，畢竟這些業務是 7 乘 24 對數億網名提供服務的。我們面對的最大挑戰就是如何在業務不中斷，不損失訪問流量的情況下保障業務的安全。因此我們的重點一個是安全加固，一個是入侵檢測，其中入侵檢測是我很喜歡的一個領域。在國內，入侵檢測經常被理解為 IDS/IPS 這樣的安全設備。在以 web 瀏覽訪問以及手機 app 訪問為主要業務形式的互聯網公司，入侵檢測覆蓋分範圍非常廣泛。

我首先遇到的一個問題其實不是技術上的，如何衡量我們所做的努力對公司安全狀況的貢獻。換句話來說，就是如何描述我們做的事的產出。在大多數公司，甲方安全都是地道的成本中心，純成本消耗。如何證明安全團隊的價值是非常重要的，即使是在一個超大型互聯網公司。我觀察到有些同學其實幹的也很苦逼，情緒低落，總是抱怨。確實他負責很多小項目，每個事情看似很重要，但是確實也看不到啥產出，感覺做不做其實也一樣。於是明顯的惡性循環也產生了，一個事情沒做成業績，就繼續做另外一個，結果下一個也沒做出成績，繼續做下一個，手上一堆爛尾樓，還要抱怨辛苦沒人看到。

在那個時候，某知名漏洞平台還在，上面報的漏洞公司層面還是非常重視的。於是我想到一個重要的衡量指標，就是安全事故的主動發現比例。比如拿到伺服器的 webshell，SQL 注入點和敏感文件下載，這些都是影響大且容易量化的。如果能夠通過我們開發的入侵檢測系統，提高我們主動發現入侵事件的比例，這個貢獻是非常容易體現的。我們在相當長的一段時間就是從各個維度想辦法提高這些指標，其中印象深刻的就是 webdir 和 dbmon。

webdir&dbmon

webdir 和 dbmon 是我們內部取的名字，簡單講 webdir 分析 web 伺服器上的文件，及時發現後門文件，dbmon 分析資料庫日誌，及時發現 SQL 注入點以及拖庫行為。通過這兩個項目，我的 team 從一個安全技術團隊開始向一個安全產品團隊衍變，除了負責應急響應和滲透測試的的安全工程師，開始出現有安全背景的研發工程師以及負責 storm 和 hive 的大數據工程師，人數也開始兩位數了。

webdir 在一期的時候，主要是依賴收集的樣本提煉的文本規則，簡單有效，在部署的初期發現了不少 case，部署的範圍主要集中在重點產品線，量級在一萬台左右。我們在二期的時候，重點工作是一方面提高檢測能力，一方面是減少發現的延時，另外一個方面是全公司部署，這三方面都是為了提高 webshell 的主動發現比例。

在檢測能力方面，主要是提高準確率和召回率，關於這兩個指標的含義，有興趣的同學可以看下我機器學習的書，裡面用小龍蝦和魚來做了形象的比喻。基於文本特徵的 webshell 檢測，很難在這兩個指標之間做平衡，尤其是我們這種超大規模的公司，即使是每天新增的文件也可能上億，實驗室環境看著還蠻不錯的檢測效果，誤報也會被放大。因此大多數安全工程師的選擇就是寫極其精準的規則，所謂精準，就是根據搜集的樣本寫的過於嚴格苛刻的規則，用於大大降低誤報。這導致的結果是，誤報確實少了，但是漏報也非常嚴重。

我們仔細研究了下問題所在，主要是由於 php 語言的高度靈活性，一個很簡單的功能可以用多種方式實現，還有不少裝逼的語法。單純在語言文本特徵層面做非常吃力。通過調研，我們發現不管文本特徵層面如何做繞過我們的檢測，最後 webshell 還是要以 php 和 java 的語法來實現，如果我們可以實現 php 和 java 的語法，就可以在更底層提取特徵，與黑產進行對抗。

這個思路也一直影響了我們後面的流量分析產品以及基於機器學習的 webshell 識別，不過這個是後話了。這個思路也成為我們二期的主要提升點，當時根據我們搜集的數千樣本，挑選了專業的安全產品進行測試對比，我們的兩個指標綜合領先。我們另外的一個挑戰是工程上的，我們僅在國內就有大量的機房，每個機房之間的帶寬不盡相同，而且使用率也大不相同，即使是固定的兩個機房，帶寬使用也有明顯的時間特徵。

另外互聯網公司大多把伺服器的性能壓榨的非常膩害，運維部門對我們的性能指標限制的非常死，甚至超過一定的 CPU 或者內存就會自動把我們進程掛起甚至 kill。為了儘可能降低伺服器的性能消耗，我們使用雲模式，負責的語法解析與規則匹配放到雲端，伺服器上僅需要完成非常簡單的處理和上傳邏輯。但是幾十萬個伺服器如果因為上線新版本同時出現新文件需要檢測，也可能會出現帶寬的異常消耗，於是我們也使用了去中心化的部署方式。

一群只玩過單機版 syslog-ng 分析日誌的土鱉，一下子可以有上百台伺服器，還用上了大型消息隊列和自研的沙箱集群，想想確實很有成就感。二期上線後，無論從部署範圍還是檢測能力上，都上了一個新台階，並且由於檢測技術上的創新以及客觀的評測結果，這個項目獲得了公司層面的創新獎。在這個項目上另外一個收穫是開發伺服器端的程序的經驗，在一個如此大規模的集群上部署客戶端，還要做到性能消耗小，考慮各種異常情況的處理，考慮各種兼容性問題，這些都是干過才能積累的。

dbmon 在一期的時候，依託於公司運維部的 DBA 團隊的現有系統，離線分析公司部門產品線託管的 mysql 查詢日誌。檢測的效果確實不理想，一堆暴力破解的報警，仔細一查都是密碼過期了。檢測的重點沒有放到 SQL 這些上，而是更像針對資料庫的異常訪問檢測了，這個其實從實踐角度，安全人員很難去定位問題，小同學弄兩次就煩了，所以效果一直很差，最後運維繫統的同學根本不想看報警了。

二期的時候我們聚焦到 SQL 檢測上，相對於 waf 和流量層面，SQL 日誌層面做 SQL 注入點檢測非常合適，因為在 http 協議層面可以有大量繞過 sql 注入檢測的技巧，但是最終還是會落地到可以執行的 SQL 語句，在 SQL 日誌層面會大大簡化這方面的檢測，相對於負責的 WAF 規則，SQL 日誌層面上的檢測是在黑客難以控制的更底層進行對抗。在這個階段即使是文本特徵的檢測，在準確率和召回率上表現已經不錯了。

上線效果非常好，同學們對這個也有了信心。集思廣益，在三期的時候我們在 SQL 層面嘗試了也使用語法而不僅僅是文本規則檢測，不過這個是後話了。也是通過這個項目，我們團隊熟悉了在 hadoop 和 storm 環境下的開發，值得一提的是，通過使用 storm 我們把檢測延時大大縮小了，另外由於把 storm 性能壓榨太膩害，我們在一次事故中發現了 storm 的一個深層 bug，storm 中關於這個 bug 的修復代碼就是我們提交的。作為一個土鱉，我們很自豪可以把 storm 玩到這個地步。

另外一個收穫是，為了在應急響應時查詢日誌方便，我們把常用的日誌部署在 ELK 集群上。起先沒有經驗，每天大約數十 T 的日誌部署在常見的機械硬碟上，運行起來非常慢，一個查詢內存居然還爆了。後來在大數據部的大拿指導下，我們混合使用了固態硬碟和機械硬碟，啟用單機多示例，優化內存和 java 配置等，搭建起了 50 台物理伺服器的 ES 集群，每台機器上雙實例，當時 github 也才維護了不到二十台 es 伺服器。同樣在實戰中我們熟悉了 kafka、hadoop 的優化，這個讓我的 team 也有了大數據處理使用經驗，這也為後面我們完全轉向安全產品團隊打下了基礎。這種通過更底層進行降維對抗的思想，也影響了我的安全觀，後面我們開源的 openrasp 也是這一思路的另外一種體現。

土鱉 PGM

機緣巧合，又遇到一次方向調整，部門的重點是對外提供商業安全產品，為此我們還收購了一家公司，這個是對我影響比較大的一次調整。相對於辦公網和生產網的安全，商業安全產品的收益更加容易量化，而且可以服務更多的用戶，得到更多的一線反饋。以前在游泳池游的，現在可以在大海里遊了。

這時我們已經有 WAF 和抗 D 產品了，以及滲透測試服務。現在需要做的是豐富產品線滿足不同層次的需要。起先我想到的是把 webdir 和 dbmon 產品化，因為確實效果不錯。但是和幾個用戶聊完後，不是很感冒。先說 webdir 吧，在我們公司內部部署啥都好說，畢竟我們夠強勢去做這個事情，運維的同學不管心裡服不服，表面上還是認可我們的。但是在不少互聯網公司，安全工程師沒有那麼強勢，恰巧在伺服器上安裝安全軟體，容易導致一些糾纏不清的問題。所謂糾纏不清只可意會不可言傳。

另外，程序需要直接掃描 web 代碼文件，這個又是個敏感問題。dbmon 的問題也是類似，尤其是對於不少公司，資料庫是不開啟日誌的，更別說是還要把日誌從伺服器搜集上來了。換句話來說，如果是影響業務的檢測類產品，沒準可以有市場。於是我們抱著嘗試的心態，也沒和老闆吹啥牛，默默先做產品化，小步快走。我們把之前我們在公司內部做全流量鏡像分析的系統做了產品化，相比於公司內部起步價 20G、50G 甚至幾百 G 的帶寬，用戶側上 1G 的都很少，於是我們做了很多簡化處理，更多考慮的是便於部署和穩定性。

整個移植的過程其實比較簡單，畢竟有點殺雞用牛刀的感覺。銷售側也幫我們找到了幾個天使用戶，由於產品比較新，售前不懂，我就和銷售去和用戶介紹。還記得第一個用戶部署測試的時候，第一天就發現了潛伏了好久的一個後門，當時正有人在使用這個後門。用戶那安全設備其實部署的也不少，但是還是有這個後門，當時對方的安全負責人一激動就說他們全部機房都要部署這個。於是第一單就這麼成了，互聯網公司果然就是爽快。後面一段時間，我和銷售一起見過不少客戶，通常我們測試的用戶都會有微信群，大家反饋問題都在微信群里，我那段時間經常在微信群里和用戶溝通交流，產品側的問題我們很快就迭代修改，經常上午反饋的問題我們下午就可以上線。

很多人好奇我回微信咋那麼快，其實我對手機的重度使用也是那個時候開始的。我的好脾氣也在這個時候展現了優勢，很多產品細節使用的問題，每個好脾氣就會忽略了。現在回顧那段時光，其實我們產品最後可以有不少用戶，得力於從售前、測試、研發和售後的溝通順暢，基本是把我搭進去了。我也使用過商業產品，通病是這四個環節非常脫節，越大的公司問題越大，因為公司越大，分工越細。售前不懂技術細節，滿口跑火車的也不少見，售後只會抱怨說不清產品問題所在也正常。研發天天趕進度，自嗨的增加功能，不屑與沒技術含量的功能修改也是常事。在我們產品的初期這些問題很少出現。一直到現在我都對這段經歷很感慨，如果一個產品經理能說出自己產品哪裡牛逼，其實不算牛逼，如果還能說出自己產品哪裡不如競爭對手的，這個才算有點牛逼了。各種原因吧，其中肯定也包含我這段經歷的加分，我後面負責了整個 web 安全產品的產品和技術，我們內部叫做 PGM，整體打通去看這些產品。有人說我安全圈認識人咋這麼多，很多一部分是這個時間積累的，其實我在外面開會扯的很少。

兜哥帶你學安全

不得不提的是我的公眾號，這與我之前做安全產品的經歷有一定的關係。我接觸到不少從事互聯網公司一線安全工作的童鞋。剛接觸我的時候還是蠻防著我的，生怕我是來騙錢的。其實也可以理解，有點預算的甲方，估計都被乙方洗腦 N 遍了。另外我長的比較喜感，眼神比較清純，人來熟，不像大家對黑客或者說安全從業人員的印象。接觸幾次後逐漸建立了信任，大家也比較聊的開了。雖然安全技術一直在演進，各種新的思想和概念也不斷湧現，幾乎每年安全會議的側重點都會不太一樣，大數據、AI 再到區塊鏈。安全的攻擊形式也層出不窮，針對 web 的、智能硬體的、AI 模型的等等。

但是一個現實是，甲方的需求和乙方介紹的技術和產品的鴻溝卻一直不斷擴大。一些很基礎的安全加固知識可以搞定的，一些通過配置就可以搞定的事情，黑產關注了，但是大家卻沒怎麼關注。mongodb、es 之類匿名訪問放到公網裸奔，直到被加密勒索了；沒打補丁的 window 伺服器防火牆也不打開，還對外提供服務，直到被人全盤加密勒索；智能攝像頭的 root 密碼也不改，放到公網還拍些敏感內容，結果被人一個初始密碼就劫持了。

我把我的一些經驗和大家分享了下，發現大家蠻感興趣。於是我抱著玩的心態，開始寫我的公眾號。起先我也沒有多大把握會有多少人看，畢竟講的都是些基礎乾貨，比如如果做網路區域劃分和隔離策略，如何對無線網路安全加固，生產網的伺服器如何做加固等等。開始的時候，我是遇到用戶問的問題，就把公眾號裡面相關的發給大家看。沒想到一下子轉發的很多，關注用戶數漲的不錯。最後我把文章進行了分類，分為了企業安全和 AI 安全兩個板塊。我公眾號並不追求思路多新多領先，就是想成個小筆記本，大家有需要時可以找到使用的辦法，一不小心成了一個粉絲數相當不錯的安全自媒體。

AI 探索

大概在 2014 年底還是 15 年初，組織架構調整，我收了一個研究機器學習的小團隊。團隊的 leader 是個非常活躍的小孩，而且特別有激情。他一直鼓搗我增加在機器學習方面的投入。

當時 HC 控制非常嚴格，但是我還是被他傳銷式的彙報感動或者說屈服，我儘力支持他。當時我們在線上環境的離線數據上做了大量的嘗試，在部分場景下也取得了不少進展。也是這個階段，我對 AI 建立起了信心。我開始重新梳理 AI 比較成功的使用場景，然後嘗試移植到安全領域。那段時間我自學了機器學習，也經歷過激情澎湃地買了一堆機器學習書籍後發現一個公式也看不懂的尷尬，幾次想放棄。最後我發現自己是碼農出身，我對代碼的理解能力遠強於文字和公式，於是我從有示例代碼的書籍學習起，逐漸理解了機器學習的常見演算法。

如何挖掘場景並使用合適的演算法呢？

這個確實靠悟性和經驗，很難就靠看書就理解了，需要大量的實踐。我投入了大量的個人時間用於學習和實踐。熟悉我的人都知道我喜歡看電子書，我的電子書里除了老羅的書和幾本歷史的書，基本都是機器學習的書。每天上下班有將近一個小時在城鐵上看書，算起來一個月就是 20 個小時，約 3 個工作日。回顧這段學習的經歷，我的感受是機器學習的學習坡度很陡，所以很多人會半途放棄或者一知半解，但是這恰恰是它的門檻。 sqlmap 的常見命令一天掌握問題不大，你覺得是門檻嗎？

寫書

為啥會寫書呢？

說起來原因很簡單，因為我的公眾號和文章經常被人抄，有去掉我水印的，有去掉我圖片的，還有完全抄只是改作者名稱的。抄襲的有自媒體，有小媒體，還有一些廠商，我也無力吐槽和維權。最後我就寫書吧，抄我的好歹你要買一本複印。也正是這段被抄襲的經歷，我的書和 PPT，盡量連引用的圖片也標註，算是一種尊重吧。

寫書的選材，我選擇了 AI 安全，而不是企業安全。因為實話實說，企業安全也不急於一時，市場上已經有了，但是 AI 安全的卻沒有。另外，大家其實對於如何使用 AI 做安全更多停留在概念層面。更有甚者，在 PR 稿上就是羅列一堆公式，然後說人能識別威脅，人能看病，所以他能用 AI 搞定。我也只能呵呵。

基於這複雜的原因，我開始寫我的 AI 安全書籍。由於 AI 的知識太多，最終定稿成三本，一本講入門的，叫《web安全之機器學習入門》，一本講實戰的，叫《web安全之深度學習實戰》，目前都已經出版了。出版前我很擔心賣不出去，結果讓我非常意外，從甲方到乙方，從國內到國外，都有我的讀者，就在今天美國 fireeye 的一位總監，當然也是我好友還在朋友圈 show 我的書。還要感謝我的幾位老闆幫我寫序，以及眾多業內好友的幫助。據說我的書還入選了出版社的計算機類年度十佳。感謝 Freebuf 的提名，我在 FIT 年度安全人物評選排到第三。

生命不息折騰不止

也許我繼續做我的安全產品，今天改個 bug，明天加個按鈕，日子也慢慢也會過去。具體的產品也有具體負責的經理，我把經理管好就 ok 了，我也可以過的比較 happy，就和以前巨牛無比的萬能充一樣。當年萬能充賣的火熱時，哪裡會想到現在充電介面統一後，再難見到它的蹤影。

時代拋棄你的時候，連招呼都不會打。尤其是你覺得舒適的時候。

我自己研究 AI，我的幾次轉型，其實都是我主動的走出了舒適區。就像我最近，以 30 歲高齡，從帶團隊的，轉去實驗室稿新產品預研一樣。在一堆 20 多歲的小夥子高呼搞技術沒用，要搞管理崗的時候，我選擇了在一個技術型公司繼續深耕技術。我有自己的技術理想，我覺得搞這些蠻開心不枯燥。

精彩待續

我的奮鬥還在繼續，精彩等著我繼續譜寫。

推薦閱讀：