Splunk Search

Best way to filter clientips as internal/external and group them by class

sideview
SplunkTrust
SplunkTrust

Given a set of clientip values from internal IP's, external IP's, as well as different classes of internal networks on different interfaces...

a) what's the cleanest and most efficient way to classify each clientip as internal/external?

and

b) what's the best way to put an actual class=A, class=B class=C field in there?

Tags (1)
1 Solution

Stephen_Sorkin
Splunk Employee
Splunk Employee

In 4.0 and 4.1, the best way to classify a field, like clientip is through eventtypes. For example, in splunk's own app to monitor the splunk.com website we use eventtypes like:

[clientip-internal]
search = clientip=64.127.105.32/27

[clientip-nonroutable]
search = clientip=10.0.0.0/8 OR clientip=172.16.0.0/12 OR clientip=192.168.0.0/16

[clientip-public]
search = eventtype!=clientip-internal eventtype!=clientip-nonroutable

With these, you can construct a field like clientip_class through the search fragment: ... | eval clientip_class = mvfilter(clientip LIKE "clientip-%") | ...

Now, another alternative is to use scripted lookups, since native lookup tables don't support CIDR netblocks or wildcards in 4.0 and 4.1.

In 4.2, the best practice is to use lookup tables. For example, in transforms.conf add:

[ipdomain]
filename = clientipclass.csv
match_type = CIDR(clientip)

And in clientipclass.csv have:

clientip,class
10.0.0.0/8,internal
172.16.0.0/12,internal
192.168.0.0/16,internal
64.127.105.32/27,corporate

Of course, in this case you'll have to set min_matches and default_value in transforms.conf to fill in the default of external.

View solution in original post

Stephen_Sorkin
Splunk Employee
Splunk Employee

In 4.0 and 4.1, the best way to classify a field, like clientip is through eventtypes. For example, in splunk's own app to monitor the splunk.com website we use eventtypes like:

[clientip-internal]
search = clientip=64.127.105.32/27

[clientip-nonroutable]
search = clientip=10.0.0.0/8 OR clientip=172.16.0.0/12 OR clientip=192.168.0.0/16

[clientip-public]
search = eventtype!=clientip-internal eventtype!=clientip-nonroutable

With these, you can construct a field like clientip_class through the search fragment: ... | eval clientip_class = mvfilter(clientip LIKE "clientip-%") | ...

Now, another alternative is to use scripted lookups, since native lookup tables don't support CIDR netblocks or wildcards in 4.0 and 4.1.

In 4.2, the best practice is to use lookup tables. For example, in transforms.conf add:

[ipdomain]
filename = clientipclass.csv
match_type = CIDR(clientip)

And in clientipclass.csv have:

clientip,class
10.0.0.0/8,internal
172.16.0.0/12,internal
192.168.0.0/16,internal
64.127.105.32/27,corporate

Of course, in this case you'll have to set min_matches and default_value in transforms.conf to fill in the default of external.

xvxt006
Contributor

Hi, I was reading thru this and is very helpful. One question i have is, you have mentioned match_type=CIDR(clientip). If i want to mention clientips of both types in the same file, how can i do that? meaning some are regular IPs and some are CIDR blocks..The version i have is - version 5.0.2.3

0 Karma

sideview
SplunkTrust
SplunkTrust

Thanks a ton. I knew some little bits of it but I was hoping someone would write it all up and you came through huge. 😃

0 Karma
Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...