2017-05-02 05:30 PM
For packet decoders running 10.6.2.0, is it possible in some way to specify which IPv4 meta fields the values from the index column will be placed in? For instance, we're putting together a list of our vulnerability scanners to whitelist. Because we selected 'IP', we don't have the option to specify why IPv4 meta fields this matches against.
Am I correct in assuming this will match against all against traffic where either the ip.src or ip.dst matches an IPv4 value in the index column? It would be nice just to specify ip.src (don't care about return traffic).
Also, what about custom IPv4 meta fields? We have one called client.ip. Will Netwitness include this field when comparing values in the index column or is it ignored since it's not a standard meta key?
Thanks.
2017-05-03 12:21 AM
When you select "IP" the feed is only going to look at "ip.src" and "ip.dst" meta keys, same for IP Range or CIDR. if you need to match against any other IP fields, the select "non-IP" and in the meta-callback section, select which fields you want to match against (I,e, "device.ip", "alias.ip", etc.)
I would suggest NOT using a feed if at all possible to filter out your Vulnerability scanners. it would be much more advantageous to filter them prior to the decoder processing anything from them. If you can have them filtered by IP at the Tap, or using a BPF filter at the decoder (unless you are using 10G pfring capture, then you will have to create "Network" Rules to filter them, as BPF is not supported for pfring capture)
2017-05-03 12:21 AM
When you select "IP" the feed is only going to look at "ip.src" and "ip.dst" meta keys, same for IP Range or CIDR. if you need to match against any other IP fields, the select "non-IP" and in the meta-callback section, select which fields you want to match against (I,e, "device.ip", "alias.ip", etc.)
I would suggest NOT using a feed if at all possible to filter out your Vulnerability scanners. it would be much more advantageous to filter them prior to the decoder processing anything from them. If you can have them filtered by IP at the Tap, or using a BPF filter at the decoder (unless you are using 10G pfring capture, then you will have to create "Network" Rules to filter them, as BPF is not supported for pfring capture)
2017-05-03 09:07 AM
Ah ok thank you! Unfortunately, our Taps are overwhelmed and can't apply any additional filters for processing reasons and we are indeed using 10G pfring captures. I thought about switching to a non-IP and using orig_ip since it's a text variable, but we need to be able to sort by CIDR. Might try some network rules then. Thanks for clarification.