Hi Splunkers. We are having an issue whereby a TAXII feed has stopped being incorporated into the Enterprise Security Threat Intelligence module. The feed has been working o.k. (i.e. downloading and importing indicators) for some time but in recent times only the download is working. - Threat Intelligence Audit in ES the download shows no errors (exit_status of 0) - We can see the downloaded .xml file with TAXII indicators in the  SA-ThreatIntelligence/local/data/threat_intel directory. - threatlist.log also shows a successful download I don't see anything specific in the logs showing an issue processing the download files. In Security Intelligence --> Threat Intelligence --> Threat Artifacts we see where earlier files. Any other suggestions for where to look to diagnose/resolve this issue. Cheers! ... View more

Hi Splunkers. I'm trying to troubleshoot an issue with field aliases based on a particular sourcetype. 1) Field alias was configured in SplunkWeb as the follows (modified for privacy reasons): Name_Mode:Type_of_access:SECURED : FIELDALIAS-Mode_extract_for_web ( Name_Mode:Type_of_access:SECURED  is the sourcetype.) uri = uri_path. 2) If I run the following, it lists the alias definition correctly: | rest /services/data/props/fieldaliases | rename title as Name, value as "Field aliases", eai:acl.app as App, eai:acl.owner as Owner | table Name "Field aliases" App Owner 3) When searching specifically for that sourcetype, the events are returned but without the field alias. The sourcetype has multiple colons in the name.  I can't see that causing the alias to fail as there are other field aliases used against similarly-named sourcetypes (in other apps) that are working without issue. It is running on a SH cluster.  Splunk is v8.02 Permissions for alias is "All apps" with read for Everyone. "uri" field is an inline field extraction. Search-time operation order puts inline field extraction (1st) ahead of  field aliasing operations (4th). (https://docs.splunk.com/Documentation/Splunk/8.2.1/Knowledge/Searchtimeoperationssequence) ... so I don't see this being a Search-time operation issue .  Any ideas where else to check? Apologies if the above is not clear due to the obfuscation. Let me know if you need clarification. Thanks, ... View more

Hi Splunkers. I'm wondering how people out there are deploying the UF to Mac fleets We are trying to deploy the Splunk UF to MacOS machines in an automated fashion. i.e. Scripted so that it requires no input from the user. If we try the install by extracting the .tgz, Big Sur complains that it cannot confirm the Splunk executables are legitimate and blocks the install. Accordingly, when we deploy via the .dmg (scripted), partway through the install Splunk's Little Helper pops up.  Although we can click through this, this breaks the unattended workflow we are trying to use for the installation  Note that we are performing any configuration items needed from the command line such as: - Setting admin credentials using the user-seed file. - Starting Splunk up for the first ime with the -- accept-license option. - Setting Splunk to start on boot up. This means we don't need (or want) Splunk's Little Helper to run. We just need the install to finish without any interaction with the user. Is there any way of running the install without the helper popping up? Alternatively, is there an alternative way people doing scripted UF installs on Macs that requires no user interaction/click-throughs or Splunks Little helper popping up during install? I've not found any special options to prevent this from popping up. Version of Splunk UF being installed is 7.2.5.1.  Macos is BigSur. Thanks in advance. ... View more

Hi Splunkers. I've manually uploaded a STIX file into ES. The file has uploaded successfully (file can be seen in /opt/splunk/etc/apps/DA-ESS-ThreatIntelligence/lookups) but I am unable to verify that the artifacts from the file have been integrated into ES Threat Intel. In ES, Security Intelligence -> Threat Artifacts, I don't see artifacts from the file showing up when a search is done. i.e. files, domains etc. Additionally, these artifacts do not appear in relative consolidated lookup files i.e. threatintel_by_(domain|process|cidr) etc., Items from existing configured threat intel downloads do show up in ES threat artifacts as well as the lookup files. **Am I assuming correctly that artifacts from ad-hoc uploads show up alongside those from scheduled intel downloads and do not get processed differently? Unless I'm missing something, this indicates the integration of the artifacts from the STIX file into the consolidated has not taken place. **Are there any other places to look to debug why the STIXX file integration into the threat intel lookup files is not happening? Thanks. ... View more

Hi Splunkers. We have an application which roles over logs and renames them to have a .bak extension. I've been having problems getting Splunk to ingest these. After some digging, it seems Splunk defaults to ignoring .bak files in a system props.conf file: [source::...((.(bak|old))|,v|~|#)] sourcetype = ignored_type .... which corresponds to the following in the log: 08-23-2019 15:35:01.171 +1000 INFO TailReader - Ignoring file '[path_redacted]\my_filename-01-etc.bak' due to: ignored_type 08-23-2019 15:35:01.171 +1000 DEBUG TailReader - Classifier said to not read item=[path_redacted]\my_filename-01-etc.bak, hence ignoring. I've tried using a props.conf local to the app with the corresponding monitor stanza to reclassify the sourcetype to something other than ignored_type. i.e.: [source::...(.(bak)] sourcetype = my_sourcetype Unfortunately Splunk still assigns it a sourcetype of ignored_type. Generally this wouldn't be an issue as Splunk would ingest the original file before the system rolls the file over and renaming the file. In this case however, we are trying to pull logs from systems which may already have created the .bak file. Cheers. ... View more

Hi Splunkers. What approach are people using to send events from a TA to different indexes depending on what the hostname? For example: We have the Splunk_TA_nix addon deployed out to our Linux machines. We want the same source events pulled in for all of our Linux machines but need the events going to different indexes depending on the host name. For reasons of access/security we need the hosts sending to an index specific that hosts environment i.e. for a given source: - host1a, host1b and host1c sends events to "normal_index" - host2a, host2b and host2c sends events to "secure_index" Our goal here is to avoid having to maintain multiple Linux TAs, with the only difference being the "index = " line in the inputs.conf. I realise this could be done by copying the TA to a different directory name and updating the index.conf in one of them to use a different index name but code inside the TA seems to expect the TA to sit in a directory of "TA_Splunk_nix" and would break if running inside a differently-named directory. I don't want to manually change the directory name in the code as this makes upgrading the TA a nightmare. I've seen something similar to this done using whitelists to detect a hostname in the directory of "monitor" stanzas but this doesn't look to be available for "script" stanzas. What I am asking: What method are people using to send events from a TA to different indexes depending on the hostname? To clarify: I am not wanting to send an event to multiple indexes from the same host. Thanks. ... View more

Hi Splunkers. Is there a way to prevent the extraction of KPV in a specific field/fields? To explain further, a set of firewall logs contains a number of key=value pairs. These are being extracted automatically by Splunk. There is also (depending on the site) what appears to be key-values within the URL field. These aren't values I am interested in extracting as they are simply part of the page served from the remote web server. Is there any way to NOT extract these (perceived) key-values on a per field basis (for URL and other fields) as once extracted, some end up with field names matching CIM field names. The only setting relating to this seems to be for disabling key-values extraction for an entire sourcetype, not individual fields. Thanks. ... View more