Does anyone have examples of how to use Splunk to check for brute force access behavior?
In this use case, we'll explore how to use Splunk Enterprise Security to detect excessive number of failed login attempts followed by a successful login which can indicate a successful brute force attack.
This use case depends on authentication data as defined by the Common Information Model (CIM). For simplicity, this example uses authentication data from from Windows and Unix or Linux, but any data properly normalized for the authentication data model works well. It’s a best practice to use the CIM to normalize data at search time, but before you put in effort to create new knowledge objects, check Splunkbase to see if such a CIM-compatible app or add-on already exists.
Best practice: In searches, replace the asterisk in index=
with the name of the index that contains the data. By default, Splunk stores data in the 'main' index. Therefore, index=
becomes
index=main
. Use the OR
operator to specify one or multiple indexes to search.
For example, index=main OR index=security
. See About managing indexes and How indexing works in Splunk docs for details.
Best practice: Use the Splunk Add-on for Microsoft Windows to accelerate time to value time to value with Windows data. For details, see Is it a best practice to use the Splunk Add-on for Microsoft Windows? on Splunk Answers.
[WinEventLog://Security]
input in the add-on to collect Windows security data. For details, see our post How do I collect basic Windows OS Event Log data from my Windows systems? on Splunk Answers.earliest=-1day index=* source=win*security tag=authentication user=* src=* | head 10
Best practice: Use the Splunk Add-on for Unix and Linux to accelerate time to value with Unix and Linux data.
[monitor:///var/log]
input in the add-on to collect the Linux security data. See Enable data and scripted inputs for the Splunk Add-on for Unix and Linux in Splunk docs for the procedure./var/log/secure
file to allow Splunk to monitor the Linux secure data. For details, see Which UNIX permissions are best for monitoring files? on Splunk Answers.earliest=-1day index=* sourcetype=linux_secure tag=authentication user=* src=* | head 10
Best practice: Since Splunk normalizes values from multiple source types regardless of source or format, it’s a best practice to make sure your data is CIM-compliant. For more information about CIM and the Splunk Common Information Model (CIM) add-on see the Splunk Common Information Model Add-on Manual. Run the following search to verify you are searching for normalized authentication data and ready for this use case: earliest=-1day index=* tag=authentication user=* src=* | head 10
This scenario uses the Incident Review dashboard in Splunk Enterprise Security and underlying correlation searches. Use the following procedure to discover incidents:
Review the Overview of Incident Review in Splunk Enterprise Security in Splunk docs for guidance on how to triage and act on resulting incidents. If no results appear, there may not be any notable notable events. However, you may need to enable correlation searches.
If no results appear, you may need to deploy the add-ons to the search heads to use the knowledge objects necessary for simple searching.
In this use case, we'll explore how to use Splunk Enterprise Security to detect excessive number of failed login attempts followed by a successful login which can indicate a successful brute force attack.
This use case depends on authentication data as defined by the Common Information Model (CIM). For simplicity, this example uses authentication data from from Windows and Unix or Linux, but any data properly normalized for the authentication data model works well. It’s a best practice to use the CIM to normalize data at search time, but before you put in effort to create new knowledge objects, check Splunkbase to see if such a CIM-compatible app or add-on already exists.
Best practice: In searches, replace the asterisk in index=
with the name of the index that contains the data. By default, Splunk stores data in the 'main' index. Therefore, index=
becomes
index=main
. Use the OR
operator to specify one or multiple indexes to search.
For example, index=main OR index=security
. See About managing indexes and How indexing works in Splunk docs for details.
Best practice: Use the Splunk Add-on for Microsoft Windows to accelerate time to value time to value with Windows data. For details, see Is it a best practice to use the Splunk Add-on for Microsoft Windows? on Splunk Answers.
[WinEventLog://Security]
input in the add-on to collect Windows security data. For details, see our post How do I collect basic Windows OS Event Log data from my Windows systems? on Splunk Answers.earliest=-1day index=* source=win*security tag=authentication user=* src=* | head 10
Best practice: Use the Splunk Add-on for Unix and Linux to accelerate time to value with Unix and Linux data.
[monitor:///var/log]
input in the add-on to collect the Linux security data. See Enable data and scripted inputs for the Splunk Add-on for Unix and Linux in Splunk docs for the procedure./var/log/secure
file to allow Splunk to monitor the Linux secure data. For details, see Which UNIX permissions are best for monitoring files? on Splunk Answers.earliest=-1day index=* sourcetype=linux_secure tag=authentication user=* src=* | head 10
Best practice: Since Splunk normalizes values from multiple source types regardless of source or format, it’s a best practice to make sure your data is CIM-compliant. For more information about CIM and the Splunk Common Information Model (CIM) add-on see the Splunk Common Information Model Add-on Manual. Run the following search to verify you are searching for normalized authentication data and ready for this use case: earliest=-1day index=* tag=authentication user=* src=* | head 10
This scenario uses the Incident Review dashboard in Splunk Enterprise Security and underlying correlation searches. Use the following procedure to discover incidents:
Review the Overview of Incident Review in Splunk Enterprise Security in Splunk docs for guidance on how to triage and act on resulting incidents. If no results appear, there may not be any notable notable events. However, you may need to enable correlation searches.
If no results appear, you may need to deploy the add-ons to the search heads to use the knowledge objects necessary for simple searching.
Added related video content.