Two (or More) Filters Are Better Than One
By Jeff Trawick, WildPackets Professional Services
"Filters" is a powerful feature in Omni that can make your analysis efforts more efficient and effective. Yet most Omni users rarely take full advantage of filters used in combination. A single filter can isolate packets based on very specific criteria, but combinations of filters can be used to perform more complex tasks. When used with triggers, multiple filters can enable Omni to perform more complex and granular analysis.
For example, I was recently at a customer site where FTP is a huge part of day-to-day business operations. The customer needed to have Omni start a capture at the beginning of an FTP session from a specific client system. Once the capture was initiated, they wanted to capture all FTP traffic for that client, and terminate the capture when the FTP session ended. The catch here is that the client uses two port numbers – port 21 for the management or control connection and port 20 for the data connection. In order to see the beginning of the overall FTP session, we needed to watch for a TCP SYN packet coming from the client on port 21. Then, we needed to capture all FTP Control and FTP Data traffic. Finally, we needed to end the capture when either the client or server transmitted a TCP FIN or RST on port 21. This job requires three filters and a trigger, which are described below.
Before moving on, we need to realize that this technique only works with active FTP. In active FTP, the client initiates the control connection on port 21, but the server initiates the data connection on port 20. If we were using passive FTP, the client would setup both connections, and the data connection would not use port 20, but would employ a random ephemeral port that we cannot predict. Consequently, we would not know which protocol to capture for the data flows. The overall process for active FTP is shown above.
Filter 1, shown at right, watches for the TCP SYN from the client to port 21 on the server. Assuming the client’s IP address is 10.10.10.100, that filter needs an address condition, a port condition, and a value condition to find the packet with the TCP SYN flag set to 1. The address condition needs to specify that the TCP SYN is sent by 10.10.10.100, so we specify the traffic direction.
Filter 2 captures all FTP Control or Data traffic from 10.10.10.100. The condition logic is shown at left. In this case, be sure that the flow direction is set to "Both" in the address condition.
Filter 3 is similar to Filter 1, but the value condition needs to find the TCP FIN flag or the TCP RST flag, so we need two value conditions with "OR" logic. Both use an offset of 47 for Ethernet packets. The first of these conditions watches for the FIN flag, and uses a mask and value that are both 0x01. The mask and value to watch for the Reset flag are both 0x04 in the second condition. As in Filter 2, the flow direction is set to "Both" in the address condition.
Once these three filters are built, the rest is easy. Configure a capture with a trigger. The Start Trigger event is Filter 1, and the Stop Trigger event is Filter 3. Then, configure a capture filter using Filter 2. Now, the capture will start when the FTP session begins. During the session all control and data traffic will be collected. When the FTP session ends, so will the capture. If you want to capture multiple sessions from this IP node, just check the "Repeat" box when setting up the Trigger.
By using a combination of filters and triggers, we have just enabled Omni to automatically recognize and capture related traffic streams that use different ports numbers. With a little thought, you can apply similar techniques to sessions that are composed of multiple flows. So, sometimes, two (or more) filters really are better than one!