爲何服務器忽然回覆RST——當心網絡中的安全設備

RST產生緣由

　　通常狀況下致使TCP發送RST報文的緣由有以下3種：

　　　   一、 SYN數據段指定的目的端口處沒有接收進程在等待。

　　       二、TCP想放棄一個已經存在的鏈接。

　　　   三、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通常是6四、12八、255，這時候根據終端抓包的TTL就能反推出進行攔截的安全設備所處的位置。固然也有一些安全設備進行攔截的時候TTL初始值無跡可尋，這時候只能逐跳排查了。