Keep in mind that there are legitimate uses for FIN and RST packets within the TCP standards and that the presence of forged FIN or RST packets, not the presence of such packets generally, is suspicious.
A client software or firewall bug, for example, could cause one end of a connection to disconnect prematurely - but that isn’t the ISP’s fault!
*If a problem you’re investigating is widespread, someone may already have published claims about precisely when or under what circumstances spoofed packets may appear; you can consult the details of other people’s allegations to see whether you can reproduce these claims for yourself.
Setting aside the possibility of fragmentation, we have explained that packets are spoofed when they are received by one computer but were not transmitted by the other computer.
Below, we give examples of summary views showing a BitTorrent transfer disrupted by TCP RST spoofing:
Before the RST packets begin (packet no. 2338 in the local capture and packet no. 2549 in the remote capture 9), the packets transmitted and received correspond directly to one another (although they appear in rather different orders).
Ten Once the RST packets begin, a large number of packets are received at each end that do not correspond to packets transmitted at the other end. We can verify this by looking at the detailed contents of these packets (for example, their sequence numbers, which are displayed by Wireshark as Seq=nnnnn), although simply counting them tells the tale in this case.
No comments:
Post a Comment