可怕！公司部署了一個東西，悄悄盯着你！

我是一個網絡監控軟件，我被開發出來的使命就是監控網絡中進進出出的全部通訊流量。這個網絡中全部人的上網內容我都看的清清楚楚，是否是很可怕？

我被一家公司老闆買來運行在一個配置極高的Linux服務器上，這臺服務器上的網卡可不得了，公司進出的網絡數據包都得流經它，它源源不斷的把數據包抓上來交給我來分析。

大家應該也知道，網絡通訊是分層的，最多見的就是那個TCP/IP協議體系了。

拿到數據包後，我就得按照這個協議規範，一層層的脫去協議的外殼，拿到它們的負載數據。

TCP會話重組

我重點要照顧的是TCP協議，由於好多應用都要使用TCP來傳輸，像上網衝浪HTTP、發郵件SMTP、微信聊天等等。

我想要掌控網絡中的通訊，第一個就要拿TCP開刀，得想辦法把TCP傳輸的一個個數據包給重組起來，造成一個完整的會話，這樣我纔好知道應用層傳了什麼東西，這個步驟叫作會話重組。

不過這個TCP協議有點複雜，拋開咱們抓到的包原本就存在亂序的狀況不說，它自己還有三次握手、四次揮手、超時重傳、延遲迴復等不少機制，有時候還會遇到時間跨度好久的長鏈接，這無疑都給我想要重組TCP會話形成了很大的難度。

而我重組TCP會話的惟一線索就是數據包包頭中的序列號SEQ和確認號ACK。

不過我仍是死磕RFC規範，把這些問題都攻克了，可以成功重組出一個個的TCP會話數據，成功率還蠻高的。

應用協議識別

TCP會話重組出來了，我就能夠拿到裏面傳輸的數據了。接下來要作的一件事就是識別應用層究竟是什麼應用在傳輸的呢？

用咱們的行話說，那就是作應用協議識別，這個時候我就得看一下端口了。

我根據三次握手數據包的方向，就能夠肯定出誰是客戶端，誰是服務端。

再看一下服務端的端口號(這個在TCP包頭裏面就能夠看到)，就能知道這是一個什麼服務了。

像常見的有下面這些：

• 22: SSH遠程登錄

• 25: 郵件服務

• 53: 域名解析服務

• 80: HTTP Web服務

• 3306: MySQL數據庫服務

• 3389: 遠程桌面鏈接服務

• ······

最多見的就是80端口的Web服務了，人類天天上網都在用到。有時候Web服務不走80端口，換成了別的，不過這難不倒我，我能夠經過分析TCP的負載數據特徵，看看有沒有HTTP協議的特徵出現，由於HTTP協議的特徵實在是太明顯啦！

到了後來，根據端口的經驗出錯的機率愈來愈大了，我就統一根據內容來進行識別判斷，再也不相信端口。每一個應用都有它們各自的協議特徵，這個識別我但是下了點功夫，輕易不會透露。

文件還原

如今我知道應用層是什麼協議了，我就能夠把應用層協議傳輸的數據給整明白了。

仍是拿最多見的Web服務來講吧，HTTP協議是一個基於請求-響應的協議，好比下面的這一次通訊：

​

請求是一個GET包，看請求的資源貌似是一張JPG圖片。

再看響應包，狀態碼是200 OK，看來沒啥問題。再看看Content-Type，image/jpeg，是個JPG圖片沒跑了。

如今我就能夠定位到響應包的負載段，就是在HTTP頭，兩個回車換行(0D0A)後面就是數據了。

找到數據位置，再根據Content-Length的大小，把數據摳出來寫成一個PNG格式的文件就大功告成了！

​

OMG，這是哪一個血氣方剛的小夥子又在看美女圖片了！

上面這個把協議中傳輸的文件提取出來的過程叫作文件還原，除了HTTP協議，我還支持文件傳輸協議FTP、郵件傳輸協議SMTP、文件共享的SMB協議呢。大家經過這些協議傳輸的文件，我都能給你還原出來，是否是很可怕？

HTTPS解密

有一天，我發現80端口的數據包愈來愈少了，與此同時，443端口的通訊數據不知不覺多了起來。後來才知道原來爲了防止被我這樣的網絡中間人窺探隱私，他們都用上了一個叫HTTPS的技術。

HTTPS把數據進行了加密傳輸，這樣我拿到之後都是加密後的，沒辦法知道傳輸了什麼內容。

不過這家公司的老闆很聰明，他要求公司的員工電腦上都裝上了一個「安全軟件」，美其名曰保護電腦不被入侵，實際上啊是在他們的電腦上作了一箇中間人劫持，進行了HTTPS的證書替換（你不信能夠看看這個：誰動了你的HTTPS流量？）。

這個「安全軟件」做爲中間人把HTTPS證書和密鑰告訴我，我就能夠解密HTTPS流量了！大家上網幹了啥我仍是能知道的一清二楚！

網絡阻斷

你覺得我只能在一旁監聽嗎？圖樣！

要是大家訪問那些敏感的網站，或者嘗試把老闆交代給我重點看護的數據偷偷傳出去，那我就不僅是看着那麼簡單了，這個時候我就要啓動阻斷功能。

爲了避免影響公司網絡的運轉，我通常都是旁路部署的，這樣要是我哪天抽風遇到了bug，還能夠當即把我撤下去。這個所謂旁路部署呢，就是抓取的包都是一份拷貝，而不是經過我轉發。

不過這樣一來也給我阻斷網絡通訊帶來了一些麻煩，若是我是串聯到網絡中，那可就簡單了，遇到那些可疑的網絡鏈接我直接丟掉數據包，不轉發出去就得了。

可如今我不是串聯，而是旁路部署，怎麼辦呢？

聰明如我，怎麼可能被這小小的問題難住？我但是深諳TCP協議的行家，在發現可疑的鏈接創建的時候，就將它掐滅在萌芽狀態！

具體來講，TCP鏈接的創建是要通過三次握手的：

當我發現可疑的SYN數據包時，在服務端回覆第二次握手包以前，以迅雷不及掩耳盜鈴之勢，用服務器IP的名義僞造一個RST的數據包給客戶端，這樣鏈接就被我掐斷了！

這一招雖然不能保證百分之百成功，但我離客戶端更近，個人僞造包通常都能比真正的服務端響應包早一步到達客戶端，因此成功率仍是蠻高的！

唉，說曹操，曹操就到！發現了一個可疑的鏈接來了，先不說了，我要去忙了～

彩蛋

悄悄告訴大家，上次公司HR給我導入了一批URL列表，讓我重點關注下都是誰在訪問：

• www.lagou.com

• www.zhipin.cpm

• www.liepin.com

• www.geekxh.com（重中之重）

往期TOP5文章

太慢不能忍！CPU又拿硬盤和網卡開刀了！

由於一個跨域請求，我差點丟了飯碗

完了！CPU一味求快出事兒了！

哈希表哪家強？幾大編程語言吵起來了！

一個HTTP數據包的奇幻之旅