Packet Filtering: Catching the Cool Packets
There are times when you need to filter on more than an address and the predefined filters just won't do it for you. For example, let's say you want to catch all the packets that roam about the network with a Time to Live value of 1. Or perhaps you want to grab all packets that have the Urgent bit set in the TCP header. Or maybe you are most interested in all the TCP SYN packets coming through the firewall (that wasn't supposed to let TCP SYN packets through). Yehaa!
You can catch any packet based on a single bit setting or a pattern seen in a series of bytes up at the upper layer.
This is where things get really interesting. Consider all the ways you can use this powerful filtering system:
-
Test your IDS (Intrusion Detection System) to ensure that it is catching hacks it should.
-
Test your firewall to see if it's really filtering out the type of traffic you don't want on your network.
-
Check for a specific type of ICMP packet - the redirect packets, for example.
-
Determine whether someone is sending FTP commands across the wire using a non-standard port number (i.e., being sneaky).
-
Watch all traffic to and from a device using a specific protocol
-
Find out if your network has some of the dreaded peer-to-peer applications running about over various port numbers.
-
Look for all traffic except traffic to and from your own hardware address.
-
Catch all traffic destined to a subnet that uses variable-length subnet masking.
-
Find out if there are any fragmented IP packets on the network.
-
Identify rogue DHCP servers on the network.
-
Find out if there are any devices acting as a router that should not be acting as a router.
Wow! There are soooooo many things you can do with pattern filters. You are only limited by your knowledge of the protocols and your ability to work your analyzer. In this chapter I'll take you through pattern filtering using examples of various types of filters you might want to build. I'll take you through the filter building process using both Sniffer and EtherPeek.
Note | Reference Chapter One for information on the offsets used for both Sniffer (in hexadecimal format) and EtherPeek (in decimal format). -- Laura |
Let’s start!
What is a Pattern?
A pattern is simply a match of a value at a specific offset. For example, if you are interested in all the TCP connection-establishment sessions, build a pattern looking for the value 0x02 at the flags field offset (shown in Figure 23). In this case, we’re looking for 0x02 because we’re looking for the single bit setting of 1 in the SYN (synchronize bit location).
Given that this is what we’re interested in, our filter should have the following definition:
Protocol Offset | Value (in hexadecimal) |
---|---|
0x21/33d (Reserved/Flags byte) | 0x02 |
Simple, eh? Let’s put together another one - this time, however, we’ll look for a negative match. Let’s say you are interested in communications that set the urgent bit to 1. These communications would also place a value in the Urgent Pointer field. In this case, we could build a filter looking to see of the Urgent bit is set. This would give us the value 0x20 in the flags field.
Note | I’ll go over the TCP flags settings in more detail later in this chapter. -- Laura |
What if we set our filter on this simple flag setting and another bit is set? In that case, you’d miss the packets completely. In this example, I recommend that you build a filter that looks for a non-zero value in the Urgent Pointer field or you can go to all the trouble of building a binary filter on just the Urgent bit setting. The Urgent pointer field is the easy way to go.
Protocol Offset | Value (in hexadecimal) |
---|---|
0x26/38d (Urgent Pointer) | NOT 0x00 |
You can build all types of patterns -- in the rest of this chapter, I’m going to focus on the various pattern formats that you can use and the boolean operands. Finally, I’m going to spew out a bunch of filter examples and give you the details on why you should build them and how to build them.