Incorrect regex for command_for_linux_audit?

[fatsug]

Hi community

I've been pulling my hair for quite some time regarding field extraction using the Splunk_TA_nix app. One thing that has been annoying me is the absence of a field which contains the full command executed.

My question/comment which I seek to get some feedback on. While trying to figure out why I am not seeing the expected/desired content I noticed something.

Splunk_TA_nix/default/props.conf
  [linux_audit]
  REPORT-command = command_for_linux_audit

Splunk_TA_nix/default/transforms.conf
  [command_for_linux_audit]
  REGEX = exe=.*\/(\S+)\"
  FORMAT = command::$1

This regex only applies to the "type=SYSCALL" audit log entry which is the only one containing "exe=" and it does not work in our environment. There is no trailing quotation mark in our log so this field is not properly extracted with this regex. So to work as intended this would need to be changed to

[command_for_linux_audit]
REGEX = exe=.*\/(\S+)
FORMAT = command::$1

This would generate a field called "command" with the executed command (binary) only.

Is this just in our environment where we have a make-shift solution to generate a second audit log file for collection, or is this a general issue?

And the rant:

It seems that if not defined elsewhere the default field separator is space. This means that most <field>=<value> entries in the audit log are extracted . The sourcetype=linux_audit type= PROCTITLE events actually has a field called "proctitle" which contains the full command executed.

While a field called "proctitle" is extracted the value of this field is cut short after the first space, meaning only the command (binary) is available.

Assuming this is expected behaviour, I suppose that I have to define a field extraction overwriding the "default" behaviour to get a field "proctitle" with the desired content.

[PickleRick]

AFAIR the stock TA_nix extractions aren't great for auditd logs. I'd rather go with https://splunkbase.splunk.com/app/4232

[fatsug]

Thank you @PickleRick, so much to unpack....

I'm not reading that I'm wrong regarding the field extraction, so where do you submit an issue to correct this? Even if it is a single field it should at least work as intended.

I also noticed that both the auditd and linux_audit sourcetypes of the TA_nix app are also in a section following this: # Stanzas in this section are legacy configuration stanzas. So I'm guessing that there is no "current" way to collect audit log. Neither scripted through ausearch or by reading the logfile.

The solution therefore seems straightforward, I need another app to deal with audit logs.

I cannot use any scripted solution relying on ausearch but must read a local audit log file being dumped. To make the suggested app https://splunkbase.splunk.com/app/4232 (which does look good , thank you) "backwards compatible" I'd need to perform "several minor (unsupported) changes". Or I can just "live with it" as it is not working correctly at the moment anyway and switch over to another sourcetype.

This manual entry https://docs.splunk.com/Documentation/AddOns/released/Linux/Configure4 points to the same sourcetype as the documentation for the AuditD TA, "linux:audit". But also indicates the use of yet another app https://splunkbase.splunk.com/app/3412 which I will be unable to use as it relies on changes to auditd on the host and making use of HEC traffic rather than a filewatch.

While I am leaning towards the "minor but unsupported changes", what would be the recommended path forward from someone with a deeper understanding of the issue?

a) Performing the "minor but unsupported changes" to the app, i.e. including the deprecated/legacy linux_audit sourcetype and installing the recommended TA in the SH cluster (as well as HF and IX as per the documentation)?

b) Switch the defined sourcetype (linux_audit) under the audit filewatch stanza in the inputs.conf of the Splunk_TA_nix app deployed to all universal forwarders over to linux:audit and installing the recommended TA in the SH cluster (as well as HF and IX as per the documentation)?

c) Building a new or heavily modifying an existing or merging several TAs to deal with audit logs in a manner closer to what is expected?

I apologize if any cynicism or irritation is not fully tucked away and that this has become a bit of a snowball. I do appreciate all the help, feedback and suggestions.

[PickleRick]

As you probably already noticed, I'm not a big fan of the TA_nix app. But - to be fair - ingesting logs (let's leave aside the scripts for now) from multitude of different sources, usually all writing to the same file in completely unrelated formats is a difficult task and ingesting "general Linux" logs is usually a huge PITA.

Reporting a bug doesn't hurt.

To be honest, I don't remember what TA_nix does with the auditd logs. I remember that the addon I pointed you to had a counterpart in form of an app https://splunkbase.splunk.com/app/2642 That's why I used the addon in the first place.