There's more to a primitive under the surface, and once we discover what it's actually doing, it opens up a whole new way for us to inspect and filter packets.
Lets use the TCP primitive as an example. What is it actually doing? How does it show us only TCP packets?
To see this we need to look at the IP header..not the TCP header. Here's a really simple version of a nicely color coded diagram.
Now we can see in the IP header we have a field called Protocol, or more accurately, Embedded Protocol. This signifies the next layer protocol embedded in the packet.
If that field is 01, we have an ICMP packet. If it's 06, it's TCP. If it's 0x11 hex, or 17 in decimal, it's UDP.
So the tcp primitive is checking the Protocol field and seeing if that field contains 6, and if so it passes the packet on to be displayed or captured.
Now, what field IS that. When counting header fields we start counting at zero. So we can count from the beginning of the packet and see that the protocol field is field 9.
Not clear from the diagram? You're right, it's not..too simple now..here's one showing the number of bits in each field.
Now we can see each line is 4 bytes, 32 bits. And starting from zero and counting the bytes we find Protocol in the ninth field.
The first two fields are divided into half bytes, call nibbles, 4 bits each. Just count them both as one byte.
We'll cover what they do later and why the authors who wrote the protocol divided them up.
Most fields in the protocol header break on byte, or nibble (half byte) boundaries.
There are a few notable examples, which we'll cover as we look at bitmasking. Bitmasking can be simply defined as showing only the bits you need to see and masking out the others.
The same principles apply to any protocol. If there's a header, you can parse it.
Getting yourself a good set of diagrams, in the format and layout YOU like is really going to help you. Unless you're in the rare position of doing nothing but analyzing packets all day, you're not going to memorize the protocol headers, probably.
But from practice, you will remember the embedded protocol is in the ninth byte offset from zero in the IP header, or the flags bits are in the 13th byte in the TCP header, or the IP version is in the most significant 4 bits of byte 0 in the IP header.
Without bunny trailing into big endian and little endian, for the purposes of packet inspection just remember that network byte order always starts from the left (you start counting at the leftmost bit and move right).
So to make this practical (and start at the beginning), the first byte of the IP header (byte zero) is split in half. The first four bits are the IP
The second 4 bits, or nibble, is the header length. This is a value multiplied by 4. A normal IP header, with no options, is 20 bytes, so this should normally be 5.
Now that's your first visual clue when looking at a packet capture in hex. If the capture included the Ethernet header and you're looking for the start of the IP header, it SHOULD, but isn't always, be 45.
So if you see a packet capture and don't know what it is, a quick way to start orienting yourself is to look for a 45 byte.
No comments:
Post a Comment