Packet Filtering: Catching the Cool Packets
Over the years of making filters, I've come down to a standard basic set of offsets that you just must know! Write these down and keep them taped to your analyzer.
| Offset | Layer | Purpose |
|---|---|---|
| 0x00/0d | Packet | Destination Hardware Address Catch all traffic going to this hardware device. Use to catch traffic going to broadcast, multicast, or a specific device on the network. |
| 0x06/6d | Packet | Source Hardware Address Catch all traffic coming from this hardware address. I use this when I'm capturing a client boot sequence and they use DHCP to get their IP address. |
| 0x0C/12d | Protocol | Source IP Address Most analyzers have a quick way to set up filters based on source IP address so you don't have to put in the offset. If you are doing advanced Boolean operations (see Chapter 4), however, you'll need to build some filters using this offset. |
| 0x10/16d | Protocol | Destination IP Address See my notes under Source IP Address above. |
| 0x14/20d | Protocol | Source Port Number Catch everything coming from this port number. For example, if you want to catch every device acting as a DHCP/BOOTP server (ya know there are those rogue DHCP/BOOTP servers out there somewhere), look for all traffic from port 67d (listed as the Bootstrap Protocol server port number - also used for DHCP). Anyone who sends traffic from this port is acting as a DHCP/BOOTP server. |
| 0x16/22d | Protocol | Destination Port Number Set up filters on this port to capture any packets going to an application or service of interest. For example, I set up filters to capture all traffic sent to the Gnutella and iMesh default port numbers (ports 6346d and 1214d respectively). |
| 0x21/33d | Protocol | Flags fields All those lovely flags! Ok, I did get the 3 reserved bits into this field (refer back to Figure 8). This is where I look for the beginning of the TCP handshake (filtering on the SYN bit set) and the unusual flags that indicate someone is playing around on the network (typically doing a reconnaissance procedure). In Chapter 4, you’ll learn how to get down to a binary level filter. |
| 0x1C/28d | Protocol | Data over UDP This is where data starts after the UDP header. If you have a non-standard application that sits right after the UDP header, the chances are pretty good that this is where the application's commands are going to be located. |
| 0x28/40d | Protocol | Data over TCP This is where data starts after the TCP header. If you have a non-standard application that sits right after the TCP header, most likely this is where the application's commands are going to be located. I have several examples of this in Chapter 4. |
| Note | You may have noticed that there are 'options' fields in the IP and TCP headers. If the options are used, then what happens to our offsets? Yipes! Well… take heart folks… the IP options field is rarely used and the TCP options field is used primarily in the handshake packets (that have nothing after the TCP header anyway). So don't get too concerned about the options - they won't get in your way. -- Laura |