Intro to Filtering with Network Monitor 3.0

 

https://blogs.technet.microsoft.com/netmon/2006/10/17/intro-to-filtering-with-network-monitor-3-0/

https://social.technet.microsoft.com/wiki/contents/articles/1130.network-monitor-ipv4-filtering.aspx

https://blogs.technet.microsoft.com/messageanalyzer/

Challenges of Filtering

One of the biggest changes between NM2.x and NM3.0 is the way you do filtering. Old NM2.x hacks may be challenged by the loss of the UI wizard to build filters. On the other hand, Ethereal users may be pleased and further encouraged by the built in intellisense, but more on this later. Hopefully I’ll be able to ease the transition and provide some tips and tricks for filtering with NM3.0.

What exactly does filtering do?

When you type in a filter and hit apply, each frame is evaluated against the filter. If the result of the filter is TRUE, then the frame is displayed (or captured in the case of a capture filter). So to start simple, if you want to see every frame where the TCP source port is 80, you could type:

Tcp.SrcPort == 80

In this example, the parser engine looks at each frame and evaluates this expression. If the current frames port is set to 80, then it includes that frame in your view.

Where do I start?

Intellisense is technology in many MS products that shows you a list of possibilities given some starting place. In the context of filtering, it allows you to see the available data items for a given protocol or structure. So if you type “TCP.” in any of the filter windows you will see a list of available data fields. If you further type in “TCP.Flags.” you then see a list of the names for each of the TCP flags. Now unfortunately in the Beta2 version of NM3.0 we only show you two levels deep. So when you type “TCP.Flags.” you won’t actually see anything more. But in the released version of NM3.0, we should have this implemented fully.

So one little known trick is that you can start off with a “.” (period) and you will see intellisense for all the top level items.

                             

 

In this list you can see stuff like Protocol, which will show you a list of all protocols underneath. So when you are not sure where to start, this is as good a place as any.

Built-in Filters (Standard Filters)

We’ve actually included a bunch of built in filters with the product. These are common filters that do mostly general things, like target a specific protocol, or narrow traffic down to a specific machine. Once you choose a filter the filter text box is populated with the filter, and you can then apply it. You may have to change some part of the filter, as often they reference placeholder for IP Addresses or Ports. These filters provide a bunch of examples that may help you understand how filters work.

              

 

You can also save your own filters and bring them up in other sessions. This lets you access your most used filters easily.

Applying a filter

In order to apply a filter in NM3.0, you can either press the button (paper with a pin on it), or you can hit Ctrl+Enter. One advantage to using the key stroke, Ctrl+Enter, is that it always applies the current filter. When you use the button, you may have to turn off the current filter if you have one applied already. This UI glitch will probably be something we address in the future. Note that we use Ctrl+Enter because our filters can be multiple lines. Having multiple lines helps readability and allows you to add comments as well.

What do I want to filter on?

I suppose it depends on what you are looking for. In general you have some problem you are investigating, or perhaps you simply want to get rid of all uninteresting traffic. Filters allow you to narrow down the traffic and see only the data you want to focus on. You’ll often start with something and then further narrow down what you are looking for by adding expressions separated by ORs and ANDs.

Filters can reference anything in the NPL. So this includes protocol data fields like we mentioned above. But this also includes Properties, which are derived by NPL and usually based on the data.

For example, the value of the TCP Window size is a combination of the Windows Scale and the TCP Window Size. So we could create a property to hold the real window size. Each column, with a few exceptions, is also just property value. So this means you can search any column for data in a filter as well. We’ll show some examples of this.

Show me all frames where X exists…

So let’s start with a simple filter to find all the ARP packets.

ARP

OK, almost too easy. A simple principle to remember is that by simply typing a protocol, structure or property you filter for the existence. So when you type ARP, you are looking for any frame which parses as an ARP protocol. Similarly if you wanted to get rid of all ARP frames, you just say

NOT ARP

Also if you like C like terminology you can type

!ARP

So let’s apply this same principle to a structure. Say we want to find all TCP traffic where SACKs are used (Selective Acknowledgments). You don’t care what the values of the SACK are, you just want to show only those frames where they exist. So your filter would be:

Tcp.TCPOptions.Option.SACK

And finally, let’s apply this to a property. In TCP we have a property called “TCPRetransmit” that gets set whenever a retransmit is found. By the way, this property requires that conversations are enabled, which isn’t the default in NM3. So to find all retransmit frames, just type:

Property.TCPRetransmit

Actually the Property portion is only needed if the term was defined as something other than a property as well. Preceding it with the Property suffix makes sure you are referencing it correctly in case it is defined as a structure or protocol too. It never hurts to begin you terms with Property, Struct, or Protocol as called for.

Using equivalence and comparative operators

Another type of filtering that is often required is to look for a specific value in a trace or a value within a certain range. For example, say you wanted to look for traffic on a certain port. In this case you would type a filter like:

Tcp.Port == 5555

This would return any frame with a port (either source or destination) is 5555. What’s interesting here is that Port is defined as a “pair”. This simply means that we pair up the source and destination port so you don’t have to. If you were to explicitly type this out using source and destination ports you would have to type:

Tcp.SrcPort == 5555 OR Tcp.DstPort == 5555

But the Port “Pair” property takes care of this for you. This makes creating filters with paired properties much easier. Since NPL defines these pairs, this could be established for any pair of terms that act this way. Pairs have also been created for Ethernet and IP addresses. So to filter on frames that involve at least one IP address containing 192.168.1.1, you would type:

IPv4.Address == 192.168.1.1

And similarly for Ethernet addresses:

Ethernet.Address==0x1185AE4E95

It’s also important to note that when you use this in the negative case, != (not equals), the expansion is different.

Tcp.Port != 5555

Expands to:

Tcp.SrcPort != 5555 AND Tcp.DstPort != 5555

This should be no surprise to you Boolean math heads, but for the commoner this may seem incorrect at first. The typical reaction is to use OR instead of AND.  But this will show you only frames where either port is not 5555.

You can also use all the comparative operators like >, <, >=, <=. So if you wanted to search for instances where the window size started getting small, you could so something like.

Tcp.Window < 1200

Now as I mentioned before, if windows scaling is enabled, this may not be the real size. So a better way to do this in NM3.0 is to use the property that calculates the real window size. So this filter would be:

Property.WindowSize < 100

Using Contains to search strings

A common task is to be able to search ASCII and Unicode strings. You can use the Contains plug-in to do this. It searches the associated string and ignores case. This can be used in two different ways, with the same results. Use which ever method you feel more comfortable with.

Contains(property.Description, “error”)

You can also use as an operator on a string object.

Property.Description.Contains(“error”)

As I mentioned before, you can search any property. And remember that most columns are just properties. The exceptions are FrameNumber, TimeOffset, TimeDelta, TimeOfDay, and ConvID. But the rest are fair game. So in this case we can search the description property text using the Contains plug in. Note that using this to search binary data doesn’t work. This is something that will probably be addressed in future versions, as it is useful to search binary data.

Generating compound statements by using AND’s and OR’s:

When narrowing down frames, you’ll often start by using one expression to filter the frames down and then you’ll want to add other expressions to further restrict your search. So let’s say I wanted to look for all frames on port 5555 that also have a window size less than 100 bytes.

Tcp.Port == 5555 AND Property.WindowSize < 100

You can also use the C like shorthand:

Tcp.Port == 5555 && Property.WindowSize < 100

Or to search for traffic between two machines, you could type

IPv4.Address == 192.168.1.1 && IPv4.Address == 10.0.0.1

You have to be careful when using AND’s and OR’s. The English language tends be more ambiguous when using these terms. Asking a car dealer to see all the Red and Green cars may make sense to both you and him, but the same query to NM3.0 would result in a potentially ugly car that maybe only Santa would appreciate.

Here’s another example for filtering on subnets.

(IPv4.Address >= 10.53.0.0) && (IPv4.Address <= 10.53.255.255)

In this example, it’s important to understand that the address is really just 32 bits of data. So checking if an address is between the lower and upper bounds of the networks range, is really the same thing as checking if it’s in the same subnet.

Using math operators in filters

It’s also possible to use math operators, like +, -,*, /,&, and | in filters. The last two being “bitwise and” (&) and “bitwise or” (|). As an example, we can use this to filter out on a subnet, but this time using the “bitwise and”. This simulates what subnet mask does.

((ipv4.SourceAddress & 255.255.0.0) == 10.53.0.0)

||

((ipv4.DestinationAddress & 255.255.0.0) == 10.53.0.0)

Comments in the filter window

It’s also possible to add comments in the filter window. This helpful if you want to document how a filter works. This also allows you to comment out a section temporarily so you don’t have to remove that portion of the filter completely. Comments can be used with either // for a single line comment and /* */ if you want to comment more than one line.

Extra Credit, modifying NPL to filter on a new property IPTTL

We talked before about searching on properties. There may be special cases where you want to create a property yourself so that you can search on it. For this example, we’ll create an IPTTL property that can reference both the IPv4 and IPv6 hop count values.

So the first step is to modify both IPv4.NPL and IPv6.NPL to add our property. For IPv4, we’ll add the property to the TimeToLive data field and for IPv6 the HopLimit data field. In NPL properties are placed in square brackets “[ ]” before the data field definition. The bracket section can contain multiple lines separated by commas but we won’t have to worry about this for our example.

In IPv4.NPL, we see that the TTL parameter is defined as follows.

…

};

UINT8 TimeToLive;

    

[NextProtocol]

UINT8 NextProtocol = FormatString(“%s, %d(%#x)”,

ProtocolTypeTable(this), this, this);

So what we do is add in property called IPTTL as follows:

[IPTTL]

UINT8 TimeToLive;

The property automatically attaches itself to the data that follows it. So now let’s modify the IPv6 parser. Here’s how it looks in its original form.

[NextHeader]

UINT8 NextProtocol = FormatString(“%s, %d(%#x)”,

ProtocolTypeTable(this), this, this);

UINT8 HopLimit;

So we’ll make the same change here:

[IPTTL]

UINT8 HopLimit;

The properties are named the exact same, so we now can reference the same property name. If IPv4 exists it references TimeToLive, and if IPv6 exists we reference HopLimit.

You must now reload the parsers. This is similar to a recompile as we want to save time each time you run NM3.0. This can be done from the parsers tab. You can hit the button from the tool bar, select Tools Reload Parsers, or type Ctrl+Alt+B.

Once the parsers are reloaded, you can then use this in a filter as follows:

Property.IPTTL == 0

This will return all frames where the TimeToLive or HopLimit is set to zero.

And that’s your filtering introduction

While it takes a while to get good at filtering the discussion above should give you a good premier. Hopefully this will help you understand the basics of how to use filtering to find the data you want with Network Monitor 3.0.

C:Documents and SettingspaulloMy DocumentsNetmon projectBlogIntelliExample.bmp