Splunk Enterprise Security

What is the best way to change sourcetype for Linux Audit Events coming from OSSEC?

att35
Builder

Hi,

We have Linux Audit log data coming in Via OSSEC into Splunk. For this data, source is set to /var/ossec/logs/alerts/alerts.log and sourcetype is "ossec_alerts". We are unable to see this data in Linux Audit app, probably because it does not understand "ossec_alerts" sourcetype.

To use this data into the Linux Audit App and Splunk Enterprise Security, what is the best way to manage this sourcetype?

Is there any way to have Splunk look at data coming from source=/var/ossec/logs/alerts/alerts.log and change source type from ossec_alerts to linux:audit?

Or should I add ossec_alerts as another accepted sourcetype under /TA_linux-auditd/default/props.conf.

[source::.../var/log/audit/audit.log(.\d+)?]
sourcetype = linux:audit
sourcetype = ossec_alerts

We would still like to keep rest of OSSEC data in it's original sourcetype, i.e. ossec_alerts. We have Deployed this app on both Indexer and the Search Head.

Many Thanks,

~ Abhi

0 Karma
1 Solution

splunk-support0
Explorer

The best way (assuming OSSEC doesn't modify the format of auditd events), would be to apply an index-time transform at the point your ossec_alerts events are cooked (typically your indexers, but may be heavy forwarders) to sourcetype them correctly. To do this, install the TA_linux-auditd app on your indexers/heavies with this local prop:

[ossec_alerts]
TRANSFORMS-ossec_auditd = linux_audit

View solution in original post

0 Karma

splunk-support0
Explorer

The best way (assuming OSSEC doesn't modify the format of auditd events), would be to apply an index-time transform at the point your ossec_alerts events are cooked (typically your indexers, but may be heavy forwarders) to sourcetype them correctly. To do this, install the TA_linux-auditd app on your indexers/heavies with this local prop:

[ossec_alerts]
TRANSFORMS-ossec_auditd = linux_audit

0 Karma

att35
Builder

This worked. After adding the above mentioned entry into props.conf, sourcetype linux:audit is now getting populated correctly.

Almost all the transforms are working as expected, except one, which is "host". This one still gets the value of the OSSEC server which is sending the data. Because of this, the following search always results in 1 host.
| tstats dc(host) WHERE [|inputlookup auditd_indicies] [|inputlookup auditd_sourcetypes] BY _time span=1d

The original host is definitely part of the OSSEC RAW data coming under linux:audit, but for some reason is not getting picked up by this add-on. Can this be fixed by creating a custom extraction and naming it as "host"?

Following REGEX is used in the OSSEC app to extract "reporting_host" field. Would it work if I add the same transforms for this App, but change field to "host" instead? Since RAW data syntax is same, ideally this should work..

# Timestamp, followed by hostname in parentheses, then IP address, then arrow and rpt source
[ossec-alerts-reportinghost-1]
REGEX = \d{4} \w+ \d+ [\d:]+ \(([^\)]+)\) (\S+)->
FORMAT = reporting_host::$1

# Timestamp, followed by host, then arrow and report source (no reporting IP address provided)
[ossec-alerts-reportinghost-2]
REGEX = \d{4} \w+ \d+ [\d:]+ ([^\(\)]+)->
FORMAT = reporting_host::$1

Many Thanks again,

~ Abhi

0 Karma

att35
Builder

Tried adding the REGEX mentioned above to the Add-on, but that unfortunately did not work. Also added a REPORT attribute under props.conf as REPORT-host = [ Item From transforms] but that did not help either.

It is still setting the host field to same as "splunk_server", and not the actual host that generated the event. How can I find where the "host" is getting the value from and why the above REGEX did not work?

~ Abhi

0 Karma

doksu
SplunkTrust
SplunkTrust

Good to hear the sourcetyping worked. Would you mind accepting the answer and we can then discuss the host field issue in your new question (https://answers.splunk.com/answers/409734/unable-to-override-host-value-using-regex.html)?

0 Karma

att35
Builder

Hi,

REGEX issue is also resolved. I'll update the other question as well.

It was a mistake on my side. Under props.conf, I was adding the TRANSFORMS attribute under [linux:audit] instead of [ossec_alerts] which is the original source for data. It now looks like the following and data is correctly Indexed.

[ossec_alerts]
TRANSFORMS-ossec_auditd = linux_audit
TRANSFORMS-host = hostoverride

Thanks for this wonderful App. 🙂

~ Abhi

0 Karma

att35
Builder

Thanks.

Would this also re-index all OSSEC data with the new sourcetype, or just add this sourcetype along with the original. How would it understand auditd specific events from OSSEC. Do I have to create any corresponding entry under transforms.conf as well?

~ Abhi

0 Karma

doksu
SplunkTrust
SplunkTrust

This won't apply to OSSEC events that have already been indexed. Once Splunk indexes events, they cannot be changed. If you need the historical events to be correctly sourcetyped, you'll need to manually re-index them.

The 'linux_audit' transform being used in the prop above is provided by the TA_linux-auditd app and it has a regex to identify auditd events.

0 Karma

woodcock
Esteemed Legend
0 Karma

splunk-support0
Explorer

Renaming the sourcetype at search time will not work for the Auditd datamodel that powers the SOC and other dashboard panes unless the props are modified. Plus, it would erroneously rename the sourcetype of non-auditd events being ingested from OSSEC.

0 Karma

att35
Builder

Thanks.

Just corrected a typo I made in the question. Apart from the sourcetype, the source itself is getting tagged as "/var/ossec/logs/alerts/alerts.log".

I'll try the rename option you suggested. As per it's documentation, it should only be a search time modification and should not break our existing dashboards based on original sourcetype.

For CIM to start re-recognizing this data(for ES app) and apply to specific datamodels, would the rename still work? or does it need Indexed data ?

~ Abhi

0 Karma

woodcock
Esteemed Legend

You will have to change your dashboards to use _sourcetype.

0 Karma
Get Updates on the Splunk Community!

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 ...

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...