Are TCP resets bad?
Wireshark can sure make them look that way. After all, bold red lines rarely highlight something positive. But like many things TCP, the good-or-bad factor of resets just depends on when they happen and how they are affecting end users.
There are a two common ways that a TCP connection can be torn down. I like to call these the polite way (FIN) and the talk-to-the-hand way (Reset). Tearing down TCP connections is a good thing as long as it is not actively in use, or won’t be needed in the very near future. We want each side of the conversation to open up the resources for other connections rather than maintaining idle ones in an active state.
In most cases, we want to see FINs tear down a connection rather than resets. However there are some examples of normal behavior where a reset is sent rather than a FIN.
Here are a few questions to answer about resets when they appear in a trace file.
When in the conversation do they occur?
Filter on the TCP conversation. Is the reset at the end of the conversation after data has been exchanged by client and server? It could be that this is TCP simply cleaning things up. It could be using a FIN to do this, however some stacks send a RST depending on the configuration and circumstances. This screenshot is an example. The conversation is idle for an extended period and the server finally shut the connection down.
This behavior will be invisible to the end user in most cases. So these are what we would consider “normal”.
If a RST happens abruptly, mid-stream in a TCP connection, this is something to worry about. Likely, the user experienced an application disconnect, or had a problem starting the app in the first place. These can be a result of a load-balancer, firewall, or router in the middle that is timing the connection out prematurely, or can be an application problem on the server side. Clients can also generate these on-demand by stopping a page from loading manually - depending on the browser used.
Is the TCP reset sent right after a SYN?
This could mean several things. Typically, these are received when the port is not open on the system or the service is down. However, keep in mind that some servers will not send a reset for an unsupported port. They will just drop the SYN without responding.
Who sent the reset?
Something important to check when analyzing TCP resets is their source - which may be different than the source IP address of the packet.
Look at the TTL. How many routes has the reset traveled through?
Just recently, I was analyzing a problem with a client where resets were originating from the local gateway. Due to a misconfiguration, a Sonicwall was terminating new connections initiated by clients, regardless to where they were sent. The TTL’s on the reset packets showed 255, which meant they were unrouted. These were not sent by the IP source IP advertised in the packet.
On another occasion, resets were being sent from a load balancer that was shutting down connections it considered dead. We saw this by looking at the IP identification numbers in the reset packets and comparing them to surrounding “working” connections.
The point is, dig deep and analyze whether the resets are coming from where you THINK they are coming from. It may very will be that a device in the middle is sending them instead of the end system you are targeting. Also, analyze where the reset occurs in the packet stream. In many cases, they are benign and aren't the red alert that they are painted as.
Want to know more about TCP?
Stay tuned to LoveMyTool for more on this series in the future. Also, check out my YouTube channel in the meantime for tips and tricks in packet analysis.