Packet forensics using TCP

Quote:

Most of us who work in the security world have at one time or another looked at the raw output of a firewall, IDS, or other type of security device. What that output invariably leads one to is viewing packets directly for an investigation. Doing packet forensics can be a difficult and time consuming endeavour. Due to this fact, many of us prefer to use convenient tools such as Ethereal to help facilitate our analysis. There is a notable problem with this approach, however.
While packet analyzers such as Ethereal do an excellent job of breaking out the packets contents, there is one thing that it cannot do for you: it cannot help you understand some of the key relationships that certain packet metrics have. Packet metrics such as the TCP sequence and acknowledgement numbers are a good example of this. Case in point, Ethereal will not tell you if there is a missing packet in your packet capture. The only way to know that a packet is missing would be to go through each and every packet with a keen eye on the aforementioned TCP packet metrics.

If this does not immediately seem all that important to you, please understand that it most certainly is. As a consultant, when we approach a computer network breach for a client, we most definitely need to know exactly what has happened. That means being able to account for each and every packet that was sent during an attack. It is most certainly possible that, for some reason, tcpdump or windump dropped some packets, especially if you are in a high bandwidth network. The problem is that you would not know this fact if you were not aware of how to truly do packet forensics. The ability to see this comes from having a deep understanding of just how protocols talk to each other, in this case the TCP protocol.

This article is set to arm you with the knowledge that allows one to approach a packet stream and successfully be able to determine if there are any missing packets. This is imperative in cases where your data set is missing packets that may contain crucial indicators of the breach. You would only know that by doing the analysis shown below.

One aspect we will not deal with in this article is analysis of application layer data. We shall concentrate with trying to arm you with just the knowledge that you require in order to pull off packet forensics. With that said, let's get to it!

full article at: http://www.securityfocus.com/print/infocus/1845

Network forensics in the case of any compromise is almost just as important and as telling as disk forensics. One of the most recent honeynet project scan of the month tests was based on using logfiles and network data and that's it. It's incredibly useful and important. However, the catch is to make sure the device that is capturing the network data doesn't drop packets, and that the timestamps it collects are accurate.

The trick is to do packet capturing prior to the need for forensics. Most people want to find out what happened to their systems after the fact but they didn't do any logging or any other type of tracking. Packet capturing can take alot of resources such as storage space but can be invaluable when combined with syslog, IDS alerts, ACL logs, etc.