Alerting

I need to create an alert for users logging in through SSH

smcbride27
Explorer

I need to create an alert for people logging in through SSH.

I have a search created that I'd like to compare against a pre-defined list and have Splunk handle the alert. I have a couple of questions, where do I define the list? I'd like it to be outside the alert so I can change it as necessary. Would I use the eval command to compare the return from my search against the list?

Thanks,

Sean

0 Karma
1 Solution

DalJeanis
Legend

There are a number of ways.

The efficiency of a particular solution will depend on how many people are in that list, and whether the user name that you want to search on has been predefined in that kind of event.

For the moment, let's assume that you have a csv file defined as a lookup called mylookupfile.csv, that has user logon names in a field called "user" and their department in a field called "dept". Let's assume that you DO need dept on your alert, and that there is a field named UserID already defined on the individual events you want.

 index=foo ...your other search terms to find the events... 
| lookup mylookupfile.csv  user as UserID OUTPUT dept 
| where isnotnull(dept)

Now let's assume that you do NOT need dept. There's a special trick with a command called format, that allows you to build a search for only the exact UserIDs you need. Run this one

  | inputlookup mylookupfile.csv  | table user | rename user as UserID | format

and it will create a field called search that looks like this

( ( UserID="value1" ) OR ( UserID="value2" ) OR ....)

If you include that whole thing in brackets, it will drop that search field back into your original search, thus returning only the records you want to alert on.

 index=foo ...your other search terms to find the events...  [ | inputlookup mylookupfile.csv  | table user | rename user as UserID]
| lookup mylookupfile.csv  user as UserID OUTPUT dept 
| where isnotnull(dept)

You should not have a pipe between the basic search and those brackets, or it won't work right. In this case, you do not need to type out the format command, because it happens implicitly at the end of the brackets

This second strategy can work exactly the same with either a lookup table (inputlookup) or a csv file (inputcsv) and the syntax is just the same.


Now, there are other ways, such a join, but you aren't likely to need them at this point, so I'm not going to go into them.

View solution in original post

0 Karma

DalJeanis
Legend

There are a number of ways.

The efficiency of a particular solution will depend on how many people are in that list, and whether the user name that you want to search on has been predefined in that kind of event.

For the moment, let's assume that you have a csv file defined as a lookup called mylookupfile.csv, that has user logon names in a field called "user" and their department in a field called "dept". Let's assume that you DO need dept on your alert, and that there is a field named UserID already defined on the individual events you want.

 index=foo ...your other search terms to find the events... 
| lookup mylookupfile.csv  user as UserID OUTPUT dept 
| where isnotnull(dept)

Now let's assume that you do NOT need dept. There's a special trick with a command called format, that allows you to build a search for only the exact UserIDs you need. Run this one

  | inputlookup mylookupfile.csv  | table user | rename user as UserID | format

and it will create a field called search that looks like this

( ( UserID="value1" ) OR ( UserID="value2" ) OR ....)

If you include that whole thing in brackets, it will drop that search field back into your original search, thus returning only the records you want to alert on.

 index=foo ...your other search terms to find the events...  [ | inputlookup mylookupfile.csv  | table user | rename user as UserID]
| lookup mylookupfile.csv  user as UserID OUTPUT dept 
| where isnotnull(dept)

You should not have a pipe between the basic search and those brackets, or it won't work right. In this case, you do not need to type out the format command, because it happens implicitly at the end of the brackets

This second strategy can work exactly the same with either a lookup table (inputlookup) or a csv file (inputcsv) and the syntax is just the same.


Now, there are other ways, such a join, but you aren't likely to need them at this point, so I'm not going to go into them.

0 Karma

smcbride27
Explorer

Thanks for the great suggestions. They changed the requirements on my slightly to only alert for accounts not on the list so I ended up with:

1. index=foo my search | search NOT [| inputlookup myList.csv | fields user ] | deduce user, host
2. | table user,host,_time

somesoni2
Revered Legend

I believe you'll have to maintain the list as lookup table files. (knowledge object saved separately, a csv file with a column header). Then refer the lookup table file content to inputlookup command. Please provide more information (current search, full requirement on when to alert on) for better suggestions.

0 Karma
Get Updates on the Splunk Community!

.conf24 | Day 0

Hello Splunk Community! My name is Chris, and I'm based in Canberra, Australia's capital, and I travelled for ...

Enhance Security Visibility with Splunk Enterprise Security 7.1 through Threat ...

 (view in My Videos)Struggling with alert fatigue, lack of context, and prioritization around security ...

Troubleshooting the OpenTelemetry Collector

  In this tech talk, you’ll learn how to troubleshoot the OpenTelemetry collector - from checking the ...