I am analyzing a packet capture and I noticed when going to a certain website I receive a RST from the website after normal conversation. The TTL from previous messages always shows 45 from the website. However, in the middle of the conversation, the website sends an RST packet. The TTL is 122.
I suspect that it may be the firewall in between the client and the website. There are several hops between the client and the internet since traffic backhauls through a datacenter so looking at the Layer 2 info isn't really helpful in determining where the RST is coming from. I am not sure if it is really coming from the website server or the firewall.
Also, I am able to determine it is not a timeout. The RST packet only shows milliseconds from the previous packet received.
Are there any tricks to look at in the packet capture that would help to help point to the firewall or website by the TTL?
The capture was taken from the client side and of course, I don't own the website we are going to so I can not capture from the server side.
asked 30 Mar '17, 09:19
If the TTL in the RST packet is "closer" (less hops) to the client than the TTL of the normal content it is usually a sign for a forged RST. This can be a firewall or IDS terminating a connection forcefully, or a proxy that quickly releases a sessions when it knows that the server has finished sending data (which would explain why it shows up so fast).
The TTL of 122 means that the device creating the RST is probably 3 hops away, which is in the normal range of devices found in the same data center, so I guess it's at the client infrastructure somewhere. You can try to pinpoint it by doing a traceroute to the server to see which device is three hops away for that route (asuming the routing isn't asymetrical).
answered 30 Mar '17, 14:49
A fair assumption would be that the device sending the RST is 6 hops away from the capture point, when you do a traceroute to the website, is the sixth hop still within your network? Is it already in the websites owner network or somewhere in between at an ISP?
Without being able to capture on multiple points between the client and the website, there is not much you can do yourself and you would need to rely on cooperation from people in the intermediate networks to find the source of the RST packets.
Another approach would be to look at the content being exchanged just before the RST and if you have multiple cases, compare them to see if there is a pattern. Also check whether the RST has the ACK flag and see which packet it ACKs, then you might learn the RTT between the capture point and the RST sending device. This might help in determining where the RST was generated.
answered 30 Mar '17, 15:00