RST產生原因

　　一般情況下導致TCP傳送RST報文的原因有如下3種：

　　　   1、 SYN資料段指定的目的埠處沒有接收程序在等待。

　　       2、TCP想放棄一個已經存在的連線。

　　　   3、TCP接收到一個數據段，但是這個資料段所標識的連線不存在。

　　對於第一種情況，常見的例子是終端訪問伺服器未開放的埠，伺服器回覆RST報文。比如，訪問Web伺服器的21埠（FTP），如果該埠伺服器未開放或者阻斷了到該埠的請求報文，則伺服器很可能會給終端SYN報文迴應一個RST報文。因此，伺服器對終端的SYN報文響應RST報文在很多時候可以作為埠掃描器判斷目標埠未開放的一個可靠依據。當然，在大多數場景下，伺服器對到達自身未監聽埠的報文進行丟棄而不響應是一種更為安全的實現。

　　第二種情況比較好理解，正常拆除一個已有TCP連線的方式是傳送FIN，FIN報文會在所有排隊資料都發出後才會傳送，正常情況下不會有資料丟失，因此，這也被稱為是有序釋放。另外一種拆除已有TCP連線的方式就是傳送RST，這種方式的優點在於無需等待資料傳輸完畢，可以立即終結連線，這種通過RST拆除連線的方式被稱為異常釋放。大多數時候伺服器需要針對兩種不同的拆鏈方式提供不同的處理方法，也有很多伺服器無法識別RST方式的拆鏈，這時候就需要格外小心，因為一旦出現這種情況，尤其是大量終端使用RST方式拆鏈，可能會導致伺服器側連線無法得到有效釋放，影響其正常業務側處理能力。

　　最後一種情況，TCP通過4元組（源目IP，源目埠）唯一的標識一個連線，由於TCP狀態機的存在，觸發TCP連線建立的第一個報文標誌位一定是SYN置位，因此，當伺服器接收到一個新四元組（伺服器本地沒有這個連線）的非SYN首包就會丟棄該報文並向終端響應一個RST報文。最後一種情況，TCP通過4元組（源目IP，源目埠）唯一的標識一個連線，由於TCP狀態機的存在，觸發TCP連線建立的第一個報文標誌位一定是SYN置位，因此，當伺服器接收到一個新四元組（伺服器本地沒有這個連線）的非SYN首包就會丟棄該報文並向終端響應一個RST報文。

問題現象

　　通過終端登入Web，輸入使用者名稱密碼後Web頁面顯示連線被重置。抓包報文如下：

　　終端10.153.47.104訪問伺服器10.153.42.65的8051埠，三次握手建立完成後，終端向伺服器傳送認證請求，提交使用者名稱和密碼，而後伺服器立即迴應RST拆除已有連線。

問題分析

　　通過對比前述3種情況，發現只能匹配上原因2，但從原因2來看也只是說明伺服器在這個位置確實可以回覆RST報文，無法解釋為什麼伺服器要回復RST。

　　這個時候我們需要考慮一個問題：這個RST報文是不是真的是伺服器回覆的？從RST報文的seq來看確實可以和前序報文對應得上（由於SYN標誌位在邏輯上佔用1位元組序號，所以RST報文的序號是第二個報文的序號加1）。一個很好的判斷一條流是否是同一個伺服器傳送的方法是對比同一個方向的報文的IP頭中的TTL值。由於TCP對亂序非常敏感，而網路裝置逐包轉發資料會引入更嚴重的亂序，因此網路中的裝置一般都是逐流轉發（按五元組，源目IP、源目埠、協議），所以，大部分情況下，在捕獲的資料流中，同一條流的同一個方向的報文總是有相同的TTL值，我們基於這個判斷來看一下上方截圖中的第二個和第五個報文的TTL值：

　　第二個報文的TTL值為251：

　　第五個報文的TTL為122：

　　因此，基本可以判斷RST報文為中間傳輸裝置發出。排查流量路徑上的安全裝置，在IPS中找到對應的日誌：

　　由於使用者名稱和密碼都是admin且明文傳輸，因此觸發了Web使用者登入弱口令的防禦規則，連線被重置，IPS冒充伺服器向終端傳送RST報文拆鏈，如果在IPS裝置抓包，可以看到IPS也同時冒充終端傳送了RST給伺服器。

　　在很多環境中，中間安全裝置通過RST攔截報文時初始TTL一般是64、128、255，這時候根據終端抓包的TTL就能反推出進行攔截的安全裝置所處的位置。當然也有一些安全裝置進行攔截的時候TTL初始值無跡可尋，這時候只能逐跳排查了。

&n