來自一個網絡監控軟件的自述

自述

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

我被一家公司老闆買來運行在一個配置極高的 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 的數據包給客戶端，這樣鏈接就被我掐斷了！

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

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