2005-08-16
Article continued from Page 1
Please bear in mind that one would normally be running this filter against an already logged binary file, as we'll see below. If we were using the above filter I would be telling tcpdump to only log packets with the above noted IP address and a flag combination equalling 24. The filter below would be one that I would run against an existing binary log file I have called "bleh."
tcpdump –r bleh 0 ip and host 10.10.10.10 and host 192.168.1.1 and tcp[13] = 24 > bleh2
The file bleh would be an already logged file of a session between the two noted IP addresses. By having an existing binary log file we can apply bpf/bitmask filters against it interactively. By doing the above, we are telling tcpdump to look for the conditions specified above only, and then to write it to an ASCII file called bleh2.
Remember that it is always best to log in binary for the simple reason that you can write an ASCII file from the binary, but you cannot create a binary log file from an ASCII one. Many tools such as Snort and tcpdump will only work with binary log files, and they will simply not accept flat ASCII files for parsing. With this TCP flag concept fully explained lets move on!
Back to packet forensics
Let's take a look at a second packet:
04/10/2005 10:11:46.264343 192.168.1.1.25 > 10.10.10.10.2748: S [tcp sum ok] 727167800:727167800(0) ack 1635370672 win 24820 <nop,nop,sackOK,mss 1460> (DF) (ttl 62, id 18217, len 48) 0x0000 4500 0030 4729 4000 3e06 b503 c0a8 0101 E..0G)@.>....... 0x0010 0a0a 0a0a 0019 0abc 2b57 b338 6179 c6b0 ........+W.8ay.. 0x0020 7012 60f4 cff0 0000 0101 0402 0204 05b4 p.`.............
The second step of the handshake is the SYN/ACK. In this packet, we now have the ISN + 1 as evidenced by the number underlined. We also have a TCP sequence number that is underlined: 727167800:727167800.
Let's move on to step three.
04/10/2005 10:11:47.381612 10.10.10.10.2748 > 192.168.1.1.25: . [tcp sum ok] ack 727167801 win 8760 (DF) (ttl 112, id 8426, len 40) 0x0000 4500 0028 20ea 4000 7006 a94a 0a0a 0a0a E..(..@.p..J.... 0x0010 c0a8 0101 0abc 0019 6179 c6b0 2b57 b339 ........ay..+W.9 0x0020 5010 2238 3b71 0000 0000 0000 0000 P."8;q........
This packet is the final step in the TCP/IP three way handshake. The ACK is displayed by the "." (next to the destination port number 25). Don’t be confused by the "ack" seen above, which is followed by a number, as it does not signify that the ACK flag is set in the 13th byte offset from zero in the TCP header. In reality, that is the "acknowledgement number" plus one, hence the long number following it. This is an important point to remember.
04/10/2005 10:11:47.670592 192.168.1.1.25 > 10.10.10.10.2748: P [tcp sum ok] 727167801:727167830(29) ack 1635370672 win 24820 (DF) (ttl 62, id 18218, len 69) 0x0000 4500 0045 472a 4000 3e06 b4ed c0a8 0101 E..EG*@.>....... 0x0010 0a0a 0a0a 0019 0abc 2b57 b339 6179 c6b0 ........+W.9ay.. 0x0020 5018 xxxx xxxx xxxx xxxx xxxx xxxx xxxx P.`.....xxxxxxxx 0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx 0x0040 xxxx xxxx xx xxxxxx
We now have our 192.168 address sending data, as evidenced by the P seen above. Also, set in the 13th byte offset from 0 is the ACK flag. Note that the 13th byte's offset from zero in the TCP header is where all of the flags reside, in other words: SYN, ACK, RST, FIN, URG, PSH. However, we now know that we do not see a visual representation of the ACK flag in the packet headers above. We do, however, see it in byte 5018. Specifically, the "18" is in hex, which represents 24 in decimal. This 24 adds up to the PSH and ACK flag decimal values combined.
04/10/2005 10:11:49.770114 10.10.10.10.2748 > 192.168.1.1.25: . [tcp sum ok] ack 727167830 win 8731 (DF) (ttl 112, id 8473, len 40) 0x0000 4500 0028 2119 4000 7006 a91b 0a0a 0a0a E..(!.@.p....... 0x0010 c0a8 0101 0abc 0019 6179 c6b0 2b57 b356 ........ay..+W.V 0x0020 5010 221b 3b71 0000 0000 0000 0000 P.".;q........
In this packet, we have the 10.10.10.10 address acknowledging receipt of the data packet sent to it. In other words, the packet directly above it in this case. Once again, the number fields in question have been underlined. By using an acknowledgement number of 727167830, we know that 192.168.1.1 has received all of the data in that packet.
04/10/2005 10:11:51.682538 10.10.10.10.2748 > 192.168.1.1.25: P [tcp sum ok] 1635370672:1635370706(34) ack 727167830 win 8731 (DF) (ttl 112, id 8501, len 74) 0x0000 4500 004a 2135 4000 7006 a8dd 0a0a 0a0a E..J!5@.p....... 0x0010 c0a8 0101 0abc 0019 6179 c6b0 2b57 b356 ........ay..+W.V 0x0020 5018 221b b622 0000 4845 4c4f 2074 7332 P.".."..HELO.ts2 0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx 0x0040 6c2e 726f 6c2e 7275 0d0a l.rol.ru..
A key concept to remember here is that the "ack" number of a given packet is the next expected TCP sequence number from the other IP address in question. So one should note that we have the TCP sequence number here matching the "ack" number of the packet, listed two packets above us. This is exactly as it should be. The packet directly above this one is only acknowledging receipt of a packet, and is not as such sending any data, hence the lack of a TCP sequence number. Sending data would necessitate a TCP sequence number. We can see that above. As this packet is sending data, it has both a TCP sequence number and an "ack" number as well. We would once again will expect to see 192.168.1.1 use this packet's "ack" number as the TCP sequence number.
04/10/2005 10:11:51.682814 192.168.1.1.25 > 10.10.10.10.2748: . [tcp sum ok] ack 1635370706 win 24820 (DF) (ttl 62, id 18219, len 40) 0x0000 4500 0028 472b 4000 3e06 b509 c0a8 0101 E..(G+@.>....... 0x0010 0a0a 0a0a 0019 0abc 2b57 b356 6179 c6d2 ........+W.Vay.. 0x0020 5010 60f4 fc75 0000 0000 0000 0000 P.`..u........
In this packet our 192.168 address is only acknowledging receipt of the packet above it. That is why there is no TCP sequence number there. This is only an Acknowledgement. Be sure to look at the TCP sequence number of the packet above this one. Note the TCP sequence number on the right. This is being acknowledged by our packet's "ack" number. In essence, this packet is saying I have received your data, and processed it.
04/10/2005 10:11:51.682916 192.168.1.1.25 > 10.10.10.10.2748: P [tcp sum ok] 727167830:727167853(23) ack 1635370706 win 24820 (DF) (ttl 62, id 18220, len 63) 0x0000 4500 003f 472c 4000 3e06 b4f1 c0a8 0101 E..?G,@.>....... 0x0010 0a0a 0a0a 0019 0abc 2b57 b356 6179 c6d2 ........+W.Vay.. 0x0020 5018 60f4 xxxx xxxx xxxx xxxx xxxx xxxx P.`.....xxxxxxxx 0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx
First at all, in this packet we have both a TCP sequence number and an "ack" number. Therefore we know that this packet is both acknowledging receipt of data, and is also sending some in return. In this case, our TCP sequence number is based off of the "ack" number seen two packets above us. This is again exactly as it should be. Remember, the "ack" number of the packet is the next expected TCP sequence number of the other IP address's packet. We also have the same "ack" number repeated here. That is fine, and this "ack" number is once again the next expected TCP sequence number from the other IP address (in this case 10.10.10.10)
04/10/2005 10:11:54.820932 10.10.10.10.2748 > 192.168.1.1.25: . [tcp sum ok] ack 727167853 win 8708 (DF) (ttl 112, id 8541, len 40) 0x0000 4500 0028 215d 4000 7006 a8d7 0a0a 0a0a E..(!]@.p....... 0x0010 c0a8 0101 0abc 0019 6179 c6d2 2b57 b36d ........ay..+W.m 0x0020 5010 2204 3b4f 0000 0000 0000 0000 P.".;O........
This packet is only an acknowledgement packet as evidenced by the "ack." There is no TCP sequence number here because there was no data sent. In essence 10.10.10.10 is simply saying, "thanks 192.168.1.1, I have received your data."
04/10/2005 10:11:58.070622 10.10.10.10.2748 > 192.168.1.1.25: P [tcp sum ok] 1635370706:1635370747(41) ack 727167853 win 8708 (DF) (ttl 112, id 8591, len 81) 0x0000 4500 0051 218f 4000 7006 a87c 0a0a 0a0a E..Q!.@.p..|.... 0x0010 c0a8 0101 0abc 0019 6179 c6d2 2b57 b36d ........ay..+W.m 0x0020 5018 2204 42ec 0000 4d41 494c 2046 524f P.".B...MAIL.FRO 0x0030 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx 0x0040 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxxxxxxxxxxxxxx 0x0050 0a .
In this packet we have both a TCP sequence number and a "ack" number. To clarify, once again this packet's TCP sequence number is based on the "ack" number of the packet two packets above this one. This makes sense, as the packet directly above is only acknowledging the receipt of data, and that "ack" number is also seen here in this packet again. You can now see how hard it would be then to actually hijack a session using TCP sequence number prediction.
04/10/2005 10:11:58.070913 192.168.1.1.25 > 10.10.10.10.2748: . [tcp sum ok] ack 1635370747 win 24820 (DF) (ttl 62, id 18221, len 40) 0x0000 4500 0028 472d 4000 3e06 b507 c0a8 0101 E..(G-@.>....... 0x0010 0a0a 0a0a 0019 0abc 2b57 b36d 6179 c6fb ........+W.may.. 0x0020 5010 60f4 fc35 0000 0000 0000 0000 P.`..5........
This packet above is once again only acknowledging the receipt of data. We are used to seeing the "S" to denote a SYN packet and a "P" for a PSH packet. Please realize that an "ACK" is denoted merely as a "." In this case, the "." directly after the destination addresses port number.
Conclusion
This had been a tutorial on the relationship between the TCP Sequence number and the Acknowledgement number. Understanding this will help you if you ever have to do packet forensics, and will generally increase your knowledge of TCP/IP overall. The authors sincerely hope that you enjoyed it and are able to put this knowledge good use in an effort to further secure your networks.About the Authors
Don Parker holds the GCIA and GCIH certifications, and specializes in Intrusion Detection and Incident Handling. He also offers services of a specialized nature to clients with high assurance networks.
Mike Sues is the CEO of Rigel Kent Security & Training services. In addition to providing clients with specialized, high-assurance security services, he offers an extensive curriculum of technical, lab-oriented computer security training.
