This is probably a very basic Splunk question, but as I move beyond basic searches, these are the kinds of use cases I'm needing help with:
Here's the scenario:
field sc_status contains the HTTP response code (either 401 or 200 in this case)
A successful Kerberos authentication is going to show a 401 response (auth challenge) followed by a corresponding 200 response when the auth occurs successfully.
An error condition exists if multiple 401 responses exist in the logs (lets say 20 or more) without a corresponding 200 response.
So - to show these in a search (or an alert), I need to be able to: find a 401 response, lookahead to the subsequent 20 events, and return results if there's not a corresponding 200 message.
transaction command works great at grouping events into 401/200 login events, but is there a way to show 401s that AREN'T captured by the transaction?
Thanks in advance...
Have you tried transaction command with option maxevents?? There are options in transaction command to keep events which do not form transaction.
Assuming you already have your events in an appropriate order, i.e. sorted by time and an ip adress or something like that, this should do it:
... | eval 200_event=if(sc_status=="200",1,0) | streamstats sum(200_event) as id | streamstats count as attempts by id | where attempts>=20
* | stats count | fields - count | eval sc_status="401,200,401,401,401,401,401,200,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,401,404,200" | makemv delim="," sc_status | mvexpand sc_status | eval 200_event=if(sc_status=="200",1,0) | streamstats sum(200_event) as id | streamstats count as attempts by id
There may be better approaches though, this is just straightforward what you described.
Thanks for the help!
Though it looks like your evaluation looks for 20 200 events rather than 401s? Perhaps you can explain in plain language what you're doing with this query?
Ah! You're right, I switched the two cases in the if statement around. Sorry for that, I just edited the original post. It should now work as intended, which is in plain language this: You eval a field "200_event" to contain a 1 each time a successfull login takes place, and then you keep a running total (the "id" field) of these events. This is useful because each time you have one of those 200 events, you can conclude that the last 401 has successfully been answered. This in turn means that a running count of the same attempt without a successful 200 answer (i.e. no change in the "id" field) can help you track down someone with multiple unsuccessful attempts.
If that didn't clear things up enough, feel free to ask further 🙂