List of Figures

---

Chapter 1: Packet Filtering and Offsets

Figure 1: : Inside an analyzer.

Figure 2: : Filtering enables you to focus on specific packets of interest - applying multiple filters in succession enables you to view the surrounding or related traffic as well.

Figure 3: Wow! This guy is outta control! No one needs to ARP that often!

Figure 4: Which traffic would you focus on next?

Figure 5: The starting offset of network layer data is different for Ethernet and Token Ring frame structures.

Figure 6: The Ethernet II frame format with field offsets in decimal (d) and hexadecimal (0x).

Figure 7: We'll start using the Protocol offset value now that we're above the data link layer.

Figure 8: The TCP header is much more complex than the Ethernet or IP header. Whee!

Figure 9: The simplistic UDP header has the source and destination ports at the same offset as the TCP header.

Chapter 2: Address Filtering

Figure 10: To catch all broadcast traffic (regardless of the upper-layer protocol), filter on 0xFF-FF-FF-FF-FF-FF.

Figure 11: Building a filter on a device's hardware address.

Figure 12: When you are looking for a flow of data between devices (regardless of the upper-layer protocols), filter on the MAC addresses of the local source and destination.

Figure 13: What the heck is this doing on the wire?

Figure 14: Include traffic to and from to loopback address to nail this loser.

Figure 15: The filter to catch all traffic from systems using the Compaq OUI 0x00104B

Figure 16: When you define filter patterns you only need to define the first bytes of the address.

Figure 17: Building a filter on 0x0.FFFFFFFFFFFF reveals all devices that are booting up or have uninitialized frame types.

Chapter 3: Protocol Filtering

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.

Figure 19: Just click on a protocol to build a protocol filter.

Figure 20: EtherPeek's protocol filter list.

Figure 21: The Sniffer protocol distribution window.

Figure 22: The EtherPeek protocol distribution window.

Chapter 4: Pattern Filtering

Figure 23: The flags value 0x02 indicates that the SYN bit is the only bit that should be set.

Figure 24: Convert the port number to hexadecimal and then place it at the appropriate offset for the source port field. If you use EtherPeek you don't need to convert to hex or use the hex offset value.

Figure 25: The destination port field follows the source port field by 2 bytes.

Figure 26: The OR operand indicates that an acceptable packet must match one or the other pattern.

Figure 27: Just enter in the port value in decimal and you're done! Simple, eh?

Figure 28: Just click OR > Port and then enter the port number to build port filters in Ether- Peek -- really easy.

Figure 29: The type and code fields are adjacent - this means that we can build a single pattern that includes both field values.

Figure 30: This is a great pattern filter -- you don't even have to use AND/OR operands -- it's the only pattern you want to match.

Figure 31: The flags field is 6 bits long. It is preceded by two reserved bits (set to 0).

Figure 32: Based on the bit setting, the flag field value for a SYN packet is 02.

Figure 33: When both the ACK and SYN bits are set to 1, the flags field value is 12.

Figure 34: When just the Urgent bit is set, the flags field value is 20.

Figure 35: When just the Reset bit is set, the flags field value is 4.

Figure 36: The Urgent bit pattern.

Figure 37: The NetBIOS filter is based on traffic to port 137 (0x0089).

Figure 38: The two patterns are combined with the AND operand to ensure we only capture NetBIOS packets with the Urgent bit set to 1.

Figure 39: The TCP flag setting 02 is equivalent to the SYN bit setting of 1.

Figure 40: Although I named the filter using the entire network address 10.2.0.0, my filter is only based on the first two bytes of the address (the true network portion).

Figure 41: The top summary line indicates that we are going to catch packets with the flag setting of 02 (SYN) and NOT the IP source address value starting with 10.2.

Figure 42: Three patterns to catch FTP USER, PASS and NLST commands regardless of the port used.

Figure 43: The filter looks pretty cool when you put it all together.

Figure 44: The offset value used for the Flags and Fragment Offset fields is 30.

Figure 45: The first pattern will be used to catch the first and middle fragments.

Figure 46: The second pattern will be used to specify that the fragment is the first one. We'll also use this pattern with the NOT operand to find middle or last fragments.

Figure 47: The 'More to Come' bit is set to 0 indicating this would be the last fragment of the set.

Figure 48: This filter looks for packets that match one of three pattern sets. Cool!

Figure 49: The Subnet Calculator provides the subnet bit mask for a VLSM address.

Figure 50: Each filter is built in binary mode to focus on the network and subnet bit values.

Figure 51: Start by assigning a value to each bit as shown.

Figure 52: In the hex decode you can read the term 'GNUTELLA CONNECT.'

Figure 53: Gnutella responses follow the original request path through the network.

Figure 54: We can see a sudden spike in the traffic rate when a Gnutella client boots up.

Figure 55: The first pattern should catch the connection sequence.

Figure 56: The second pattern will catch the start of the actual file transfer process.

Figure 57: This first filter looks for all traffic that uses the source port 1214 (0x04BE in hexadecimal).

Figure 58: This pattern looks for packets going to the Morpheus default port 1214.

Figure 59: Always start DNS filters with a leading period. In this case, the entire site name doesn't fit in one pattern, but we're pretty sure we'll catch the relevant packets.

Figure 60: The second pattern should be used in your filter as well.

Figure 61: Build a filter that looks for the iMesh DNS query.

Figure 62: The only command that could be identified in the iMesh traffic is a reference to the 'mime type'.

---