Chapter 3: Protocol Filtering | Packet Filtering: Catching the Cool Packets

The filtering gets much more interesting as you move deeper into the packets. In this chapter, we're going to look closely at the various protocol filters that you should build - of course, the actual filter set you need depends on your network, but this chapter will give you an idea of how these things are built and which ones you should consider.

First, let's talk about how we differentiate the protocols as we look inside the packets.

Using the Protocol ID Field

Each header has some sort of a Protocol ID field (PID) that indicates the next header or protocol coming up in the packet. For example, in the Ethernet II header, the Ethertype field indicates the protocol that follows the Ethernet header. If the Ethertype field contains the value 0x0800, then we know that an IP header is coming up next. If the Ethertype field contains the value 0x0806, then we know this is an ARP packet. If we build filters that point to the Ethertype field and look for either 0x0800 or 0x0806, we have built IP and ARP filters.

As we move further into the packet, we can build more protocol filters by looking for additional PID fields.

For example, in the IP header, the Protocol field indicates what type of protocol is using IP for networking. The value 1d in the Protocol field indicates that this is an ICMP packet. The value 6d indicates that a TCP header follows the IP header. The value 17d indicates that a UDP header follows the IP header.

See? It's pretty easy, hunh? Just look inside any packet and there will always be a PID field to tell you what's coming up next. ^[1]

Figure 18 highlights some of the PID fields. These fields are used to identify the upcoming protocols. The first PID field is the Ethertype field in the Ethernet header. The second PID is the Protocol field in the IP header. The third PID field is the Destination Port number field in the TCP header. So… to build basic protocol filters you only need to know which PID you are interested in, the location of that PID and the value for the protocol you are interested in. For example, if you want to capture all TCP traffic, you need to filter on the value 6d in the Protocol field in the IP header.

click to expand
Figure 18: Each packet contains PID fields that identify what's coming up next. We use the values in these fields to build protocol-based filters.

^[1]Well, now that I said 'always,' I'll have to give you an example of an exception to this rule - the old ugly Ethernet 802.3 frame type that Novell used to use as the default frame type. This frame type did not have an Ethertype field or any field that indicated what was coming up next. This means that you couldn't filter on the Ethertype field to build any protocol filter for the IPX header that followed these Ether- net headers. You actually had to look further into the packet - into the place where the IPX default checksum value of 0xFFFF was - to identify the packet as an IPX packet over the Ethernet 802.3 frame type.