When it comes to filtering network traffic, a scenario that appears simple in nature can be hard to accomplish at scale. Understanding top talker information or bandwidth trends isn’t really a problem for most traffic analysis solutions—the challenges I encounter revolve around:
- Proactive network monitoring
- Sifting through large amounts of data
This blog isn’t meant to cover proactive network monitoring; other blogs from Plixer address that in detail. The following will address the search for the needle in the haystack, and why having a powerful filtering mechanism is necessary for a network traffic analysis solution.
In order to understand filtering with Scrutinizer, you must first understand the concepts of Filter Type, Value, and Parameters.
When you apply multiple filters, the Filter Type and Filter Parameters ultimately decide what type of relationship those filters will share (AND vs. OR).
The Filter Value only impacts what data you are asking for. It has no impact on the relationship of multiple filters.
Filter Type is the first decision criteria considered when Scrutinizer decides what kind of relationship filters will share. Simply put, if the Filter Types are different, the relationship will always be AND.
Filters of a different type
Filter Parameters are used to decide the relationship between filters of the same type. One thing to consider is that some filters have a parameter to specify direction (Source, Destination, or Both) and some filters do not.
Is there a parameter for direction?
With this understanding, we can now define another rule. If the Filter Type is the same and at least one of the Filter Parameters is set to Both for direction, the relationship will always be OR.
The last case would be when the direction parameter is not set to ‘both’ or it isn’t an available option in the filters. If this is the scenario, then the results are:
- OR relationship if all parameters share the same value
- AND relationship if any of the parameters share different values
So that’s it. By understanding these filter types, you can carve data up at will and get down to the nitty gritty to help with incident response and network traffic forensics. In addition to this blog, I put together a flow chart to help with the understanding of how filter relationships work within Scrutinizer. This chart is particularly useful if you are planning on adding many filters. For example, a user may want to filter for traffic from a particular subset of servers and be notified if those servers communicate to servers that are not part of a trusted group. Understanding these relationships is critical to achieving this level of granularity when filtering network traffic. If you are interested in any of the advanced filtering possibilities listed in this blog, please feel free to contact Plixer for assistance.