Splunk Search
Highlighted

How do I take a variable from one search and pass it to another, in order to return a final value?

New Member

Apologies for what I assume is a fairly simple question, but my searches online and on here have led me nowhere.

I have two indexes, one called DHCP and one called IPS, I need to take a search from IPS which looks like this and return a field that is contained in those logs, called "SrcIP".

index=firepower AccessControlRuleName="Block Bittorrent"

I then need to search the DHCP index to find the most recent entry which contains "ip" (SrcIP) and pick out the machines hostname, which is in the field "dest".

Ultimately I am trying to create an alert which searches for the BitTorrent activity, then search the DHCP table with the user's IP address, which returns the hostname...then send an alert out that shows all of this info.

Any help to point my in the right direction would be very much appreciated!

0 Karma
Highlighted

Re: How do I take a variable from one search and pass it to another, in order to return a final value?

Motivator

try the | join command. You can do something like

index=firepower AccessControlRuleName="Block Bittorrent" | join SrcIp [ search index=dhcp ...]

Check out docs:
http://docs.splunk.com/Documentation/SplunkCloud/6.6.0/SearchReference/Join

0 Karma
Highlighted

Re: How do I take a variable from one search and pass it to another, in order to return a final value?

New Member

I think I am misunderstanding...lots of things. First, I am sure entirely sure how to get the output I'm looking for. I am having to search across these two indexes and ideally display fields from both in an email or something for alerting purposes.

In your example above, you have the searching of the dhcp index in the subsearch, but isn't the subsearch performed first? If so, I would need to reverse that order. Also, I've read the join command documentation but I am still unsure how that data is displayed upon a successful join.

My order of operations is something like this.

1.) index=firepower AccessControlRuleName="Block Bittorrent" (The "SrcIP" field in this search result is what I'm most interested in and is what I need to search the dhcp index, however I would like to take other fields from this search and ultimately display them in the final alert.)

2.) index=dhcp "Renew" (I am not sure how to search this WITH the SrcpIP field above)

3.) Return the combination of fields from both of these searches.

I've done a lot of messing around with this and this is the closest I've gotten is with this search....

index=dhcp "Renew" [search index=firepower AccessControlRuleName="Block Bittorrent" | dedup SrcIP | fields + SrcIP | rename SrcIP as ip] | dedup ip | table ip, nt_host

However, I have a couple issues. First, this only returns one value in the end, which appears the be the most recent entry. If I swap "fields" with "return" to try and have it return more results, I just get No Results Found. Second, when I am building my table at the end, I am unable to populate the table with events from the subsearch, which is something I need to do.

Any help would be much appreciated.

0 Karma
Highlighted

Re: How do I take a variable from one search and pass it to another, in order to return a final value?

Motivator

try a | stats command at the end to count the times it occurs.

index=dhcp "Renew"| join SrcIP [search index=firepower AccessControlRuleName="Block Bittorrent"  | rename SrcIP as ip]  | stats count by ip, nt_host
0 Karma
Highlighted

Re: How do I take a variable from one search and pass it to another, in order to return a final value?

New Member

That gives me the same output, but with a count of 1. Doesn't a subsearch return 1 result by default? It seems like that's what's happening to me.

Also, do you know how to pick out more fields from the subsearch and use them to build my table?

0 Karma
Highlighted

Re: How do I take a variable from one search and pass it to another, in order to return a final value?

Motivator

subsearches return up to 10000 results by default, unless you manually change it in limits.conf.

to add more fields from your subsearch just add them to the back end of that search.

index=dhcp "Renew"| join SrcIP [search index=firepower AccessControlRuleName="Block Bittorrent" | stats count as count1 by SrcIP nthost | rename SrcIP as ip] | stats count by ip, nthost

I'm shooting in the dark here, as I don't understand what you're expecting.

0 Karma
Highlighted

Re: How do I take a variable from one search and pass it to another, in order to return a final value?

SplunkTrust
SplunkTrust

This searches for the relevant srcIPs that are showing up in the firepower index and returns a unique list, labeled as ip

index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP | table srcIP | rename srcIP as ip  

That output is just a table of ip values, which you can run into this command ...

| format

...which turns it into this format...

( ( ip="firstip" ) OR ( ip="secondip" ) OR....)

...or, you can achieve the exact same thing by putting it with the word "search" inside of square braces, so the following line is the equivalent of the last line...

 [search index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP | table srcIP | rename srcIP as ip ]

...so we can use that, the results of the first search, as a filter on the second search without getting within a mile of the word join.

index=DHCP
[index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP | table srcIP | rename srcIP as ip]
| dedup ip

The last line limits the results to only the first, most recent results for each ip.

Now, this formulation is assuming that the DHCP information is what you are primarily seeking, and that the DHCP information is large in relationship to the firepower information.

If you needed to add back the firepower data under those circumstances, you could add something like this at the end...

| join ip [  search index=firepower AccessControlRuleName="Block Bittorrent" | dedup srcIP| rename srcIP as ip]

Now, if your bittorrent data is significant in relationship to your DHCP data -- one would hope not, but it needs to be considered based on your own use case -- then eliminating the initial filter and just using the join might be appropriate. Test them for performance and see.