[[341205]]

我是一個網(wǎng)絡(luò)監(jiān)控軟件，我被開發(fā)出來的使命就是監(jiān)控網(wǎng)絡(luò)中進(jìn)進(jìn)出出的所有通信流量。這個網(wǎng)絡(luò)中所有人的上網(wǎng)內(nèi)容我都看的清清楚楚，是不是很可怕?

我被一家公司老板買來運行在一個配置極高的Linux服務(wù)器上，這臺服務(wù)器上的網(wǎng)卡可不得了，公司進(jìn)出的網(wǎng)絡(luò)數(shù)據(jù)包都得流經(jīng)它，它源源不斷的把數(shù)據(jù)包抓上來交給我來分析。

你們應(yīng)該也知道，網(wǎng)絡(luò)通信是分層的，最常見的就是那個TCP/IP協(xié)議體系了。

拿到數(shù)據(jù)包后，我就得按照這個協(xié)議規(guī)范，一層層的脫去協(xié)議的外殼，拿到它們的負(fù)載數(shù)據(jù)。

TCP會話

重組我重點要照顧的是TCP協(xié)議，因為好多應(yīng)用都要使用TCP來傳輸，像上網(wǎng)沖浪HTTP、發(fā)郵件SMTP、微信聊天等等。

我想要掌控網(wǎng)絡(luò)中的通信，第一個就要拿TCP開刀，得想辦法把TCP傳輸?shù)囊粋€個數(shù)據(jù)包給重組起來，形成一個完整的會話，這樣我才好知道應(yīng)用層傳了什么東西，這個步驟叫做會話重組。

不過這個TCP協(xié)議有點復(fù)雜，拋開我們抓到的包本來就存在亂序的情況不說，它本身還有三次握手、四次揮手、超時重傳、延遲回復(fù)等很多機制，有時候還會遇到時間跨度很久的長連接，這無疑都給我想要重組TCP會話造成了很大的難度。

而我重組TCP會話的唯一線索就是數(shù)據(jù)包包頭中的序列號SEQ和確認(rèn)號ACK。

不過我還是死磕RFC規(guī)范，把這些問題都攻克了，能夠成功重組出一個個的TCP會話數(shù)據(jù)，成功率還蠻高的。

應(yīng)用協(xié)議識別

TCP會話重組出來了，我就可以拿到里面?zhèn)鬏數(shù)臄?shù)據(jù)了。接下來要做的一件事就是識別應(yīng)用層到底是什么應(yīng)用在傳輸?shù)哪?

用我們的行話說，那就是做應(yīng)用協(xié)議識別，這個時候我就得看一下端口了。

我根據(jù)三次握手?jǐn)?shù)據(jù)包的方向，就可以確定出誰是客戶端，誰是服務(wù)端。

再看一下服務(wù)端的端口號(這個在TCP包頭里面就可以看到)，就能知道這是一個什么服務(wù)了。

像常見的有下面這些：

• 22: SSH遠(yuǎn)程登陸
• 25: 郵件服務(wù)
• 53: 域名解析服務(wù)
• 80: HTTP Web服務(wù)
• 3306: MySQL數(shù)據(jù)庫服務(wù)
• 3389: 遠(yuǎn)程桌面連接服務(wù)
• ······

最常見的就是80端口的Web服務(wù)了，人類每天上網(wǎng)都在用到。有時候Web服務(wù)不走80端口，換成了別的，不過這難不倒我，我可以通過分析TCP的負(fù)載數(shù)據(jù)特征，看看有沒有HTTP協(xié)議的特征出現(xiàn)，因為HTTP協(xié)議的特征實在是太明顯啦!

到了后來，根據(jù)端口的經(jīng)驗出錯的概率越來越大了，我就統(tǒng)一根據(jù)內(nèi)容來進(jìn)行識別判斷，不再相信端口。每個應(yīng)用都有它們各自的協(xié)議特征，這個識別我可是下了點功夫，輕易不會透露。

文件還原

現(xiàn)在我知道應(yīng)用層是什么協(xié)議了，我就可以把應(yīng)用層協(xié)議傳輸?shù)臄?shù)據(jù)給整明白了。

還是拿最常見的Web服務(wù)來說吧，HTTP協(xié)議是一個基于請求-響應(yīng)的協(xié)議，比如下面的這一次通信：

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

再看響應(yīng)包，狀態(tài)碼是200 OK，看來沒啥問題。再看看Content-Type，image/jpeg，是個JPG圖片沒跑了。

現(xiàn)在我就可以定位到響應(yīng)包的負(fù)載段，就是在HTTP頭，兩個回車換行(0D0A)后面就是數(shù)據(jù)了。

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

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

上面這個把協(xié)議中傳輸?shù)奈募崛〕鰜淼倪^程叫做文件還原，除了HTTP協(xié)議，我還支持文件傳輸協(xié)議FTP、郵件傳輸協(xié)議SMTP、文件共享的SMB協(xié)議呢。你們通過這些協(xié)議傳輸?shù)奈募叶寄芙o你還原出來，是不是很可怕?

HTTPS解密

有一天，我發(fā)現(xiàn)80端口的數(shù)據(jù)包越來越少了，與此同時，443端口的通信數(shù)據(jù)不知不覺多了起來。后來才知道原來為了防止被我這樣的網(wǎng)絡(luò)中間人窺探隱私，他們都用上了一個叫HTTPS的技術(shù)。

HTTPS把數(shù)據(jù)進(jìn)行了加密傳輸，這樣我拿到以后都是加密后的，沒辦法知道傳輸了什么內(nèi)容。

不過這家公司的老板很聰明，他要求公司的員工電腦上都裝上了一個“安全軟件”，美其名曰保護(hù)電腦不被入侵，實際上啊是在他們的電腦上做了一個中間人劫持，進(jìn)行了HTTPS的證書替換(你不信可以看看這個：誰動了你的HTTPS流量?)。

這個“安全軟件”作為中間人把HTTPS證書和密鑰告訴我，我就可以解密HTTPS流量了!你們上網(wǎng)干了啥我還是能知道的一清二楚!

網(wǎng)絡(luò)阻斷

你以為我只能在一旁監(jiān)聽嗎?圖樣!

要是你們訪問那些敏感的網(wǎng)站，或者嘗試把老板交代給我重點看護(hù)的數(shù)據(jù)偷偷傳出去，那我就不只是看著那么簡單了，這個時候我就要啟動阻斷功能。

為了不影響公司網(wǎng)絡(luò)的運轉(zhuǎn)，我一般都是旁路部署的，這樣要是我哪天抽風(fēng)遇到了bug，還可以立即把我撤下去。這個所謂旁路部署呢，就是抓取的包都是一份拷貝，而不是通過我轉(zhuǎn)發(fā)。

不過這樣一來也給我阻斷網(wǎng)絡(luò)通信帶來了一些麻煩，如果我是串聯(lián)到網(wǎng)絡(luò)中，那可就簡單了，遇到那些可疑的網(wǎng)絡(luò)連接我直接丟掉數(shù)據(jù)包，不轉(zhuǎn)發(fā)出去就得了。

可現(xiàn)在我不是串聯(lián)，而是旁路部署，怎么辦呢?

聰明如我，怎么可能被這小小的問題難住?我可是深諳TCP協(xié)議的行家，在發(fā)現(xiàn)可疑的連接建立的時候，就將它掐滅在萌芽狀態(tài)!

具體來說，TCP連接的建立是要經(jīng)過三次握手的：

當(dāng)我發(fā)現(xiàn)可疑的SYN數(shù)據(jù)包時，在服務(wù)端回復(fù)第二次握手包之前，以迅雷不及掩耳盜鈴之勢，用服務(wù)器IP的名義偽造一個RST的數(shù)據(jù)包給客戶端，這樣連接就被我掐斷了!

這一招雖然不能保證百分之百成功，但我離客戶端更近，我的偽造包一般都能比真正的服務(wù)端響應(yīng)包早一步到達(dá)客戶端，所以成功率還是蠻高的!

唉，說曹操，曹操就到!發(fā)現(xiàn)了一個可疑的連接來了，先不說了，我要去忙了～

本文轉(zhuǎn)載自微信公眾號「 編程技術(shù)宇宙」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系 編程技術(shù)宇宙公眾號。