Trilight Zone

[tricore]

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!
The journey begins
This document is an effort to fully explain the relationship between TCP sequence numbers and acknowledgement numbers. These two numbers play a logical role in the transmission of packets.

Once the TCP/IP three way handshake is done, the following happens. The next packet sent will have an acknowledgement number in it. This acknowledgement number sent will be the next expected TCP sequence number of the other IP address communicating with it. To further clarify this statement, the Source IP address will send an acknowledgement number that is the next expected TCP sequence number of the Destination IP address. This concept, which is often confusing, is further explained below. Please note that the packet will be provided, and the comments on it shall follow.

04/10/2005 10:11:46.263921 10.10.10.10.2748 > 192.168.1.1.25: S [tcp sum
ok] 1635370671:1635370671(0) win 8760 <mss 1460,nop,nop,sackOK> (DF) (ttl 112, id 8408, len 4
0x0000 4500 0030 20d8 4000 7006 a954 0a0a 0a0a E..0..@.p..T....
0x0010 c0a8 0101 0abc 0019 6179 c6af 0000 0000 ........ay......
0x0020 7002 2238 ed4d 0000 0204 05b4 0101 0402 p."8.M..........

The number underlined above is called the "Initial Sequence Number," or the ISN. This always has to exist in the SYN packet, the first step of the TCP/IP three way handshake. The above packet starts with sending a SYN packet to 192.168.1.1 The "mss 1460" we see above relates to the "maximum segment size" and the 1460 is a value measured in bytes, in other words, 1460 bytes. The "mss 1460" means that 10.10.10.10 wants to receive no more than 1460 bytes of data in any one given packet from 192.168.1.1.

The "nop" as seen above is simply a pad instruction to be used for other TCP options which don’t fill out a four byte word. Lastly, "sackOK" relates to "selective acknowledgement," and indicates that it can be used for this session. This "sackOK" and "mss" value should only ever be seen during the SYN and SYN/ACK portion of the TCP/IP handshake. They should not appear during the data portion of the session.

Our last metric of "win 8760" relates to the amount of buffer space that the source IP 10.10.10.10 has, and it is measured in bytes. This value is also commonly known as the receive buffer.

We can determine that the above packet is a SYN packet. The reason for this is we can see the "S," but we also know it more definitively by its hex value of 02, as underlined in the hex content. This is known in hexadecimal as 0x.... The 0x signifies that the number which follows is in hexadecimal format.

Now let's discuss this SYN packet and the byte offset that it's found in (in the TCP header) a little bit more.
TCP flags explained
The four core protocols are IP, TCP, UDP and ICMP. When counting the bytes in a packet's core protocol headers, you must start counting from zero instead of one, as you might normally do. Contained in the 13th byte offset from zero in the TCP header is where the TCP flags of FIN, SYN, RST, PSH, ACK, URG are found. Each of these flags has a value assigned to it, and whether that value is best known by you in decimal, or hexadecimal, it amounts to the same thing. The flags each have a value assigned to it. This in turn will allow us to write a bit mask against a binary log file, or when collecting a file via tcpdump. Let's look at a diagram to visualize what we are referring to before moving on.

CWR ECE URG ACK PSH RST SYN FIN
128 64 32 16 8 4 2 1

This diagram maps out the "decimal" values of the various flags found in the 13th byte offset (once again, counting from zero) in the TCP header. With this information in hand I could easily devise a BPF filter which also includes a bit mask to pull all packets with a specific flag combination set. For example, using the packet above once again, we could write up the following BPF filter and bitmask to display only PSH/ACK packets, in other words packets that contain data.

tcpdump –nXvSs 0 ip and host 10.10.10.10 and host 192.168.1.1 and tcp[13] = 24

We arrived at the decimal value of 24 as seen in the above filter by adding up the decimal values of both the ACK and PSH flags. This equals 24, hence our need to tell tcpdump to look in the TCP header, specifically the 13th byte offset from zero, see if that byte has a decimal value of 24 then display it for me.