Packet-Sniffer Filtering Concepts-01

This article is also available as a "The Sniffer Guy" Podcast on iTunes.

The most frequent questions we receive are about how to create filters with a packet-sniffer. In an article titled “The 7 Most Common Mistakes Using Packet-Sniffers” I do touch on this topic. However, it was just one of seven items discussed and rates more attention on its own.

Creating filters is one of the most important skills required for successfully using packet-sniffers, and one of the most common reasons for inconclusive or just plain wrong results. You can design a perfect test--place the probes in exactly the right places--capture data during the tests as planned—and still end up with garbage if your Capture Filters are incorrect. Similarly, you can have perfect captures in the can and never find what you need to see, if your Display Filters are incorrect.

There is a problem with discussing this topic. Since each product uses different screens and commands to perform what are essentially the same functions, a command or GUI tutorial would not be able to address the real issue. After all, there are instruction manuals and guides from Network General (now NetScout), or Wireshark or whatever product you are using. Those guides are readily available and are usually well written. So, why is there still a problem? It is because the real problem is not how to tell the software what you want it to filter, it is instead, knowing what you want to filter—and why. Knowing what you want to filter is a thought process and a troubleshooting process. It is conceptual rather than a set of instructions. This makes it difficult to say exactly where to click or what to type, but it does makes it possible to show you an approach that applies to all packet-sniffers. This topic is huge and this brief article cannot cover it all so there will be follow up articles in the future. But first let’s review Capture Filters compared to Display Filters.

Capture Filters:

Filter out unwanted information from entering the capture buffer during capture. There is no way to correct a bad capture filter other than retesting. If it didn’t make it to the buffer it is gone to the bit bucket. Ideally, you will only use these when the data flow is too large for you to be able to get what you need in a single buffer. Under those conditions, they are mandatory as you are drinking from the Fire Hose and will completely recycle your capture buffers before the entire transaction you are looking for can complete resulting in buffers that only have part of the transaction. This is of limited value.

Display Filters:

Filter out unwanted information from displaying. They do not affect what is in the capture buffer and can be changed again and again while you work out what you want to see.

The following are a few points to remember when creating filters. They provide a conceptual approach rather than a list of instructions.

Compounding Filters:

Display filters can be compounded. This is where you filter, look and then filter again—further reducing the display. It is a good practice. Filter from the general to the specific. Do not try for that hole-in-one. Take your strokes and get the ball closer and closer to the tee. You will know more about what you are looking at each time and are far less likely to overlook something important.

Filters Only Remove:

Always remember that filters remove what you don’t want; they do not add what you do want. Even if you filter “for” a string, or address, it means filter out everything but that string—it is still filtering out. This is important for the way that you think about the process.

Boolean:

Pay attention to the basics of Boolean Statements. A classic mistake is filtering for a given address in both Source and Destination. For example:

Source = 10.10.10.10 AND Destination = 10.10.10.10. You may want to see or capture everything To or From 10.10.10.10, but the statement means, capture only packets that have 10.10.10.10 as their source address AND their destination address. Typically, nothing will qualify because most protocols would only have any given IP address as either the source OR the destination. (There are exceptions.) This illustrates the difference between “AND” and “OR.” If you made this mistake on a capture filter, it will mean performing the test over again.

TCP Port Numbers:

When creating filters in order to follow a specific conversation, determine which IP address would most likely be initiating the conversation. They will have the Ephemeral (temporary) TCP Port while the receiver will be addressed on the predetermined TCP Port appropriate for that implementation of that specific protocol with that particular application. Verify the Destination TCP Port value. It may not be what you expect. HTTP is usually TCP 80, but will often be implemented as 8080 or any other value. Don’t assume the Port Number. Get it from the application Subject Matter Expert or discover this through the process of capturing and following the initiator’s communication with the destination IP address. If you filter on an assumption, you will have nothing in the buffer or displayed—if you are wrong. Measure twice; cut once.

To further complicate matters, I myself will frequently recommend that different TCP Ports be used than what is typical for a given service. Besides the obvious security benefits such a practice offers, there are solid monitoring and troubleshooting benefits. For example, if different instances of a database that are hosted on the same server use different TCP Ports, monitoring and troubleshooting become easier. But, these non-standard port assignments can have side-effects on standard packet-sniffer filters. For example, Oracle would not use TCP 1521. This means that your Packet-Sniffer may not find it if you use a default filter for Oracle. That filter may simply map Oracle to TCP 1521, which wouldn’t work in such a situation. That is exactly why I make such a recommendation. I want to be able to differentiate between them. This way I can filter to capture one instance versus another instance of the same database on the same server! That can be a great way to monitor an application or to simply avoid drinking packets out of the Fire Hose.

Sting Filters:

Pay attention to where the string you are looking for is likely to be displayed in your particular Packet-Sniffer. Think about the nature of the value you are using for your filter. Is it a value created by the software that you are using or is it something actually embedded in the packet? For example, the Delta Time (time between packets) is not something that is actually part of the packet, nor is any “Absolute” time value. On the other hand, if there are TCP Time Stamps in the packet, that is part of the data. This is especially important when working with the same captures across different packet-sniffer software. The software generated values are created by that code and will not always be identical to the same field generated by different code. Don’t lose time trying to reconcile them; you can’t.

RFC’s:

Take the time to research the protocols you are investigating. An hour with the RFC can save you days of trouble and make the difference between success and failure. They will show you what should be focus of your filters.

Misleading Yet Normal Results: Some situations can cause you to think your filters are bad when they are fine. Such as environments or protocols, where you may only see one side of the conversation. For example, let’s use ARP. The ARP Query is a broadcast and widely visible, but the response is unicast and only visible on the segment to which it is directed, or along that Interpath. You may see many queries and no replies but that is normal. Another example is where load balancing or asynchronous routing are involved. In such cases, you may see only one side of the conversation and to make matters worse—they might switch on you. All of this is normal. If you need to see both sides (as you usually will) you will need to place your probes where they will be able to do so. This requires planning, which brings us to my closing recommendation.

Planning:

Filtering is best done with a plan. That plan should be created BEFORE captures begin. For example, know the throughput of the segments you are planning to monitor or test before you start live testing. Know if capture filters are needed and experiment with ways of getting what you need with minimal use of capture filters. Know what you are looking for and place your probes where you will be able to see what you need. Once that degree of planning is in place, the filters to use come naturally.