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

[att35]

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

[splunk-support0 · Accepted solution]

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

[att35]

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

[att35]

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

[doksu]

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)?

[att35]

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

[att35]

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

[doksu]

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.

[woodcock]

I would try the rename option first:

http://docs.splunk.com/Documentation/Splunk/6.4.1/Data/Renamesourcetypes

[splunk-support0]

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.

[att35]

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

[woodcock]

You will have to change your dashboards to use _sourcetype.