topic Re: CIDR raw search? in Splunk Search

CIDR raw search?

the_wolverine — Thu, 03 Dec 2015 01:34:11 GMT

I'm using a CIDR lookup table against raw data (find a match in the entire event, any field.) It won't work, understandably with CIDR notation as my lookup.

Is there a command that can be used to expand the CIDR notation into all possible IP combinations?

Re: CIDR raw search?

Runals — Thu, 03 Dec 2015 13:15:11 GMT

Just to be sure - have you gone under the covers to the transforms and added the CIDR match_type? Unfortunately unless something has changed in like 6.2+ you can't do this via the GUI. As an example I have a lookup named network-allocations and want to do CIDR lookups against the field network

[network-allocations]
filename = network-allocations.csv
match_type = CIDR(network)
max_matches = 1
min_matches = 1

Re: CIDR raw search?

the_wolverine — Thu, 03 Dec 2015 17:48:09 GMT

Yes, I've done this. Unfortunately, the configuration can only be applied a single field, not the entire event.

The method I'm using is to apply the match to "search":

[| inputlookup network-allocations | rename network as search | format ]

Re: CIDR raw search?

Runals — Thu, 03 Dec 2015 18:10:24 GMT

First thing is remove | format. That command can be used to show you what the output of a search would be if it were a subsearch but you don't want to bake it into an actual subsearch.

It sounds as though if you had 10.10.10.0/24 in your lookup you are wanting to search across all of your data for each of the 256 addresses - correct? I don't think there is a command that will allow you to do that. I suppose you could come up with a case statement that translates 10.10.10.0/24 into 10.10.10.* and then maybe use a regex command after the initial results to make sure your data matches an IPv4 address (ie \d{1,3}.\d{1,3}.\d{1,3}.\d{1,3} ) but that seems like it would be high overhead and becomes a pain if you aren't using A, B, or C blocks . The most ideal scenario is if address fields have been defined in your data and search on explicit fields. The state of the data might not support that currently though.