Hello Splunkers,
I need some help in understanding the difference between Auditd logging on Linux and the traditional way of capturing the log files under the var/log/* , what is it that Auditd provides which we cannot get that from var/log/*
Secondly, I'm already collecting the basic Audit files that are under /var/log/ using the standard TA_Nix , if i want to go with Auditd , is there a different Add-on for this , What are the available options.
Appreciate some insight on this from experienced techies.
Thank you,
Moh...!
Thanks Rick for checking my request and for your response,
I'm after understanding Auditd , As per my understanding Auditd provides more advanced logging and it actually give you much more data insight in audit log than the standard logging which is enabled by default on the linux systems, not sure if my understand is correct here though?
When we are pulling the data from a simple RHEL server using Splunk, we basically install a Splunk UF and push the TA_NIX app , which we use to basically collect everything under /var/log/* , now my understanding here is these logs that are under /var/log/* are the default logging setting on the linux which does not provides much of context on the log . for example who logged in , the username, the source IP address and the outcome which can only be achieved using Auditd rules. is it true ?
Hope I was able to explain well this time, Appreciate if anyone can provide more insight on this.
Auditd is a separate mechanism from the "normal" logging used in linux systems (formerly based on a syslog daemon, recently using journald part of systemd package).
Auditd is a userspace component interacting with kernel auditing subsystem. And that subsystem is meant for auditing.
Normal syslog/journald logging is meant for "general logging", which might also include security related events from various parts of the operating system.
What is getting logged (and ingested by UF's inputs) can vary depending on:
1) Settings of various system components - for example, sshd might or might not report unsuccessful connection attempts depending on the log verbosity settings in config file
2) How you are storing the events and ingesting them (if you don't forward your logs from journald to syslog but only ingest with UF from /var/log/* files, you'll miss a lot of events that the system generates).
Wait a second. Are you talking about auditd or journald? Because these are two different things. While journald can be viewed as a replacement for a syslog daemon (yes, I know it's a bit of an oversimplification) and needs to be configured to forward data to syslog (or you have to use syslog daemon which can read journald socket), auditd is a different subsystem meant strictly for logging the auditing stuff.