As we described above, packet trace files generated on separate machines that were communicating directly with one another can be compared to see how packets sent by each computer correspond to packets received by the other computer.
Since a simple file transfer or VoIP conversation could generate thousands of packets, the lack of automated tools to perform this comparison can make the process tedious.
We intend to collaborate with other interested parties to produce such comparison tools in the near future, enabling much larger data sets to be analyzed quickly for spoofed packets, even where specific sorts of spoofing are not suspected. Here are a few tips for comparing packet traces by hand:
* Spoofed packets may correspond to protocol errors or extreme delays reported or observed in application software; for example, if a client program gives an error like “Connection reset by peer”, “Connection closed by foreign host”, “Lost connection”, etc., or data rates suddenly drop, packet spoofing may have occurred. Noting the timing of suspicious errors may provide guidance for where to look for spoofed packets in a packet trace file.
* Spoofed packets used to disrupt connections are often TCP segments with the FIN or RST flags set (also known as “FIN packets” and “RST packets”); each of these flags indicates that a computer does not want to continue a TCP conversation.
No comments:
Post a Comment