The nix app should not be used. This is not just my oppinion, it’s a widely held view. The nix app has a range of problems and I strongly suggest you use both the Linux Secure app (https://splunkbase.splunk.com/app/3476/), the sudo app (https://splunkbase.splunk.com/app/3038/) and the Linux Audit app mentioned in the question together. The nix app provides no real interpretation of Auditd logs and therefore adds no value, unlike the Linux Auditd app, which provides a wealth of field extractions properly normalised to the CIM (critical for for ES), lookups, dashboards, etc for understanding and deriving value from the ingestion of that source. ... View more

Always specify the source type in your inputs.conf monitor stanza. In this case, sourcetype=linux_secure P.S. a new version of the app is currently under certification review which will provide greater support for Debian-based distributions and should be released in the coming days. ... View more

I wrote all but the ModSecurity app you listed so naturally those are what I use ;). I'd also recommend two of my other apps: https://splunkbase.splunk.com/app/3506/ and https://splunkbase.splunk.com/app/3446/ The first provides "free" whois lookups and the second provides the ability to pivot on field values such as a domain to VirusTotal. If possible, I suggest investing in sensors to produce application-layer traffic metadata with something like Splunk Stream or bro (both of which have supported apps). For more information about how this is done (and many other great recommendations), please see MITRE's free publication: https://www.mitre.org/publications/all/ten-strategies-of-a-world-class-cybersecurity-operations-center One of the things you can generate in Splunk from that traffic metadata is passive DNS information. DomainTools, Farsight DNSDB, and PassiveTotal are also useful (paid) services that provide a wider ranger of historical passive information, for which there are Splunk apps of varying quality. Now that you've got those pieces in place, I recommend watching my .conf presentation from last year which discusses how to develop detection techniques: https://conf.splunk.com/sessions/2017-sessions.html#search=The%20Art%20of%20Detection%20Using%20Splunk%20Enterprise%20Security& ... View more

The posix_identities lookup shouldn't be manually modified, as it's automatically and periodically updated by a scheduled search that merges the directory_posix_identities and local_posix_identities lookups. The correct place to add the 0,root entry is in the local_posix_identities lookup. Please see the documentation for more information: https://github.com/doksu/splunk_auditd/wiki/Installation-and-Configuration#configuration ... View more

It sounds like the auditd_sourcetypes lookup may have been modified to include 'syslog', which will not work. 'linux:audit' is the sourcetype that should be used, as per the app documentation's requirement list (https://github.com/doksu/splunk_auditd/wiki/Installation-and-Configuration#requirements). A workaround is provided for 'linux_audit' in the documentation (https://github.com/doksu/splunk_auditd/wiki/Installation-and-Configuration#sourcetype), however use of 'syslog' sourcetype is not supported. With respect to some dashboards showing information and others not, please see: https://github.com/doksu/splunk_auditd/wiki/About-Auditd to configure auditd to log those additional event types. This is discussed in the user guide video: https://www.youtube.com/watch?v=M7QZRAHSs5E Regarding the datamodel, please see the documentation here: https://github.com/doksu/splunk_auditd/wiki/Installation-and-Configuration#datamodel ... View more

If using a universal forwarder to collect auditd events, all that is required is to specify the sourcetype 'linux:audit' in the file's inputs.conf monitor stanza. However, in your case I would recommend using a heavy forwarder on the syslog server so you can apply index-time transformations before events are forwarded to Splunk Cloud. The reason I suggest this is that the syslog service is putting events of different sourcetypes into the same file and so index-time transformations are required to sourcetype them correctly on a event-by-event basis. This could be done on the indexers in Splunk Cloud, however you would need to contact support. The 'auditd' eventtype is not provided by the Linux Auditd app (TA_linux-auditd). It is from the Splunk_TA_nix app and is applied to events with the sourcetype 'auditd', indicating that your events may not be being sourcetyped correctly. Furthermore, the sample event provided doesn't appear to actually be an auditd event at all. The 'auditd' sourcetype will not work with the Linux Auditd app, please see: https://github.com/doksu/splunk_auditd/wiki/Installation-and-Configuration#sourcetype Irrespective of the Linux Auditd app being used or not, the best practice is to collect events as close to the source as possible in order to retain fidelity and provide other benefits, such as load-balancing, etc. In practice, this means installing universal forwarders on endpoints (where possible), rather than using syslog or some other means of collection. In this way, I would encourage you to reconsider the use of syslog for collecting auditd events. ... View more