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初始值無跡可尋，這時候只能逐跳排查了。