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. Thanks, Greg Wiedeman asked 30 Mar '17, 09:19  gregwiedeman |
2 Answers:
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  Jasper ♦♦ 1 Funny, I had 3 hops in mind at first, but I think it should be 6... (do we share some strange brain-malfunction???) (30 Mar '17, 15:02) SYN-bit ♦♦ 1 Man, you're right... how the hell did that happen?!? :-D (30 Mar '17, 15:06) Jasper ♦♦ Just curious how did you arrive at that conclusion on the TTL. If the previous TTLs that were normal from the end device (website) were 45 and the RST was 122. I know that the TTL will decrement at each hop but I can not for some reason figure out the math. When I receive the RST doesn't that have to decrement too? (31 Mar '17, 07:30) gregwiedeman 1 45 means that the sending device probably started at 64, so it's 19 hops away. 122 means it started probably at 128 (which means it's a different device), 6 hops away. 64, 128 and 255 are very common start TTLs, so you can calculate hops from that, and in almost all situations it'll be a correct guess. So you have one sender (the web site) starting at 64, and suddenly someone creating a reset starting at 128. That means it's most likely a different device (much closer to you). (31 Mar '17, 07:38) Jasper ♦♦ Ahh ok so the RST from the device started the TTL over again at 128 ok that makes sense. I see now very interesting thank you for that. I did not realize that a device would reset the TTL. I have the sanitized file just figuring out how to upload. Dang newbies :) (31 Mar '17, 08:04) gregwiedeman Well can not upload to this Q&A but here is the link to the sanitized file if you want it for your records. The answers given were excellent. Thanks you both Jasper and SYN-bit. I want to give you guys both checks but I think it will only allow one. https://s3-us-west-2.amazonaws.com/packetcapturesgw/SanatizedPacketCapture_1_anon.pcapng (31 Mar '17, 08:47) gregwiedeman Just to clarify. The device issuing the Reset didn't modify the TTL of a Reset that was passing though, the different TTL means that it actually issued the Reset itself. That is, the Reset didn't originate from the website, it originated from the device that it 6 hops away from you. (02 Apr '17, 05:18) Philst showing 5 of 7 show 2 more comments |
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  SYN-bit ♦♦ Yes the traceroute show six hops is still in the network and is our firewall. Just out of curiousity how did you arrive that it was 6 hops? Did you start at 128 for the TTL and then subtract 122 leading you to six hops. (31 Mar '17, 07:26) gregwiedeman 1 yep, exactly, see my comment below my answer on more math :) (31 Mar '17, 07:39) Jasper ♦♦ |
Are you able to share the pcap file? It would be nice to have a look and see what we could come up with...
@gregwiederman: this tutorial can help you sanitize the file, in case you can't share details like IPs, MACs or the payload:
https://blog.packet-foo.com/2016/11/the-wireshark-qa-trace-file-sharing-tutorial/
Let me sanitize the file and I will share out.