Linux Secure Technology Add-On: Implications using Splunk_TA_nix simultaneously

[thilles]

Hi, 

In the description of the TA-linux_secure app, it states:

It is intended to replace the security-relevant aspects of the Splunk Add-on for Unix and Linux (Splunk_TA_nix) and as such it's strongly recommended that the Splunk_TA_nix app be removed from your search head before installing this app as they may conflict. 

My org is using the Splunk_TA_nix app, and I'm trying to figure out how these two apps might conflict. 
From what I can tell the only thing that might conflict are perhaps some of the configurations in props.conf. But then again, wouldn't that be solved since Splunk would use the Splunk_TA_nix settings over TA-linux_secure settings (because of lexicographical order)?

Perhaps you @doksu have some more insights? 

[FrankVl · Accepted solution]

That depends on your definition of 'solved'. If you need some of the specific configs that Linux Secure Technology Add-On brings, but they get overruled by Splunk_TA_nix, then that would probably qualify as a conflict. Same thing the other way around.

If you have 2 TAs targeting the same sourcetype, with different config, the end result may not be as intended, because you get a mix of both configs and/or one TA overruling the other on some settings.

So yeah, any actual conflicting settings will be 'solved' by Splunk's precedence mechanism, but that doesn't mean the outcome of merging these 2 TAs is what you would want.

[doksu]

Hi @thilles and thanks for the question. I'm the author of the Linux Secure Technology Add-On and just want to echo what @FrankVl has said. Using the nix TA on endpoints for collecting events and the Linux Secure Technology Add-On on the search head won't cause a conflict, however having both the nix TA and the Linux Secure Technology Add-On installed on the same search head isn't advisable.

If what you want is field extraction and normalisation of Linux events to the Authentication data model then I definitely wouldn't use the nix TA because it does a poor job of it. I suggest using standard Splunk file monitor stanzas (i.e. not the nasty scripted things the nix TA uses) in your inputs.conf on endpoints to collect /var/log/secure (and /var/log/audit/audit.log) and the Linux Secure Technology Add-On on your search head/s for field extraction and normalisation to the CIM.

Speaking of /var/log/audit/audit.log - it's a very rich source of information so I highly recommend you ingest it and use https://splunkbase.splunk.com/app/4232/ + https://splunkbase.splunk.com/app/2642/ .

[thilles]

Thanks, appreciate the added input. 

And yes, doing standard file monitoring of /var/log/secure  and/var/log/audit/audit.log, and using your TA-linux_auditd for the audit.log. Very nice work btw 🙂   

[thilles]

'Solved' as in non-breaking for reports, dashboards etc that's already there and using current extractions (Splunk_TA_nix).

But yeah, I see your point. The end goal is to use the logs for CIM Authentication data model.
So I would guess 'solved' for us would mean that the TA-linux_secure settings that CIM normalize aren't overridden by the Splunk_TA_nix ones. 

Thanks for the clarifying input. 

[FrankVl]

Even for existing content it could have impact. Matching settings will be merged in favor of Splunk_TA_nix, but the 2 TAs can vary well have 2 different settings that each affect how for example the src_ip get's extracted and with both TAs active, both REPORT / FIELDALIAS settings get applied in some order (unless they have the exact same name).