Snare Agents, Snare Central and Splunk

Starting from v5.5.0, Snare Agents support a new Syslog JSON format, comprising of a Syslog 5424 header and JSON event payload. This format provides more detailed event content compared to standard Syslog formats.

Customers that use Snare Agents to collect and forward events directly to Splunk, can take advantage of this capability by configuring the Snare Agents to send events in “Syslog JSON” format, and then adding a simple event recogniser in Splunk, as described below.

Before v5.5.0, customers using Splunk in conjunction with Snare Agent had the following options:

For Windows agents, Splunk provides native Snare format support
For other platforms, customers would be required to send using the Syslog 3164 format, or redirect via Snare Central

Examples of both are shown below.

Syslog 3164 Event:

<10>May 03 09:39:06 vmwin2019demo.demo.ia MSWinEventLog	2	Security	5358377	Mon May 03 09:39:01 2021	4673	Microsoft-Windows-Security-Auditing	SNARE\demo	N/A	Failure Audit	vmwin2019demo.demo.ia	Sensitive Privilege Use		A privileged service was called.    Subject:   Security ID:  S-1-5-21-3312608775-1817375343-330975633-21763   Account Name:  demo   Account Domain:  SNARE   Logon ID:  0x33B83D    Service:   Server: Security   Service Name: -    Process:   Process ID: 0xe60   Process Name: C:\Program Files (x86)\Google\Chrome\Application\chrome.exe    Service Request Information:   Privileges:  SeProfileSingleProcessPrivilege	0

Syslog JSON Event:

<10>1 2021-05-03T09:39:06.317317+09:30 vmwin2019demo.demo.ia Snare_Enterprise_Agent_for_Windows - MSWinEventLog	 - 2	{"Event":{"xmlns":"http:\/\/schemas.microsoft.com\/win\/2004\/08\/events\/event","System":{"Provider":{"Name":"Microsoft-Windows-Security-Auditing","Guid":"{54849625-5478-4994-a5ba-3e3b0328c30d}"},"EventID":"4673","Version":"0","Level":"0","Task":"13056","Opcode":"0","Keywords":"0x8010000000000000","TimeCreated":{"SystemTime":"2021-05-03T00:09:01.167677800Z","LocalTime":"2021-05-03T09:39:01.167677+09:30"},"EventRecordID":"186735806","Execution":{"ProcessID":"4","ThreadID":"16808"},"Channel":"Security","Computer":"vmwin2019demo.demo.ia"},"Data":{"SubjectUserSid":"S-1-5-21-3312608775-1817375343-330975633-21763","SubjectUserName":"demo","SubjectDomainName":"SNARE","SubjectLogonId":"0x33b83d","ObjectServer":"Security","Service":"-","PrivilegeList":"SeProfileSingleProcessPrivilege","ProcessId":"0xe60","ProcessName":"C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe"}}}

Due to limitations in the Splunk event ingest process; in particular the inability to handle or process Syslog 5424 messages, the header of the Syslog JSON format does not get recognized by default. This results in Splunk failing to perform field extraction.

As a result, an additional event type needs to be added into the Splunk configuration by adding a props.conf file into $SPLUNK_HOME/etc/system/local. The file contains the configuration required to enable Splunk to extract fields from the incoming data appropriately.

$SPLUNK_HOME by default is /opt/splunk on Linux systems.

The following snippet can be pasted as-is to perform this function. It works by generating a JSON object from the Syslog 5424 header natively in the event and splices it into the JSON payload forming a JSON object which Splunk can then use to extract appropriate fields.

[snare_syslog_json]
SEDCMD-strip-prefix = s/^<([0-9]+)>([0-9]+)\s+([^T]+)T([^\+Z]+)(\S+)?\s+(\S+)\s+(\S+|-)\s+-\s+(\S+|-)\s+-(\s+([0-9]+))?[^{]*{"Event":{/\9{"Event":{"Header":{"Pri":\1,"Version":\2,"DateTime":{"Date":"\3","Time":"\4","TimeZone":"\5"},"Hostname":"\6","AppID":"\7","LogType":"\8"},/g s/^\s*([0-9]+)(.*)"LogType":"([^\"]+)"}/\2"LogType":"\3","Criticality":\1}/g
pulldown_type = true
category = Network & Security
description = Used from Snare agents using syslog json format.

If agent logs are reflecting via Snare Central, an additional transforms.conf file alongside props.conf will be needed. The following configuration will enable Splunk to detect the correct “host” field of the originating event client.

Also, the following line will need to be added to the props.conf file, to enable the transformation defined in transforms.conf to be activated.

The `SEDCMD` function within this file performs a Perl-compatible regular expression replacement at index time in the form of a space-separated list of sed commands. The options provided to this function are limited to substitution via the `s` flag and replacement by the `y` flag. This function also takes a class used to identify the object and interoperate with other configuration files uniquely. This particular functionality is not required for this use case.

As the agent generates an event header compatible with Syslog 5424, the initial matching regular expression (regex) appropriately matches the specification in RFC 5424. Snare uses additional fields in the event's header to convey the Snare log type and event criticality. To ensure compatibility with all Snare products, two replacements are done. The main matching expression used to match the general RFC format is shown below. Names have been added for the particular captures as `SEDCMD` does not support named capture back-references. For consistency, in this example, all fields other than the log type and criticality are named per the RFC 5424 naming scheme.

Since the criticality may not exist for all incoming sources, we use the first replacement below to put the event into an intermediate format that will be the final output if this field does not exist. However, if it does, then the criticality will be placed at the start of the JSON payload so that a second pass can appropriately format that data.

If required, the second pass match expression below is run against the data to pull out the criticality value.

If criticality is captured, then a second substitution will splice the criticality into the newly generated JSON header object.

This substitution generates a JSON object for the header, matching one of two structures (with and without criticality).

Without Criticality:

With Criticality:

After this, it splices this data into the payload in a format capable of using field extraction techniques.

The `pulldown_type` flag within this file toggles the visibility of this log type in the Splunk “Source Type” dropdown. The drop-down specifies the sourcetype of events from a particular connection or port. With this value set to true, snare_syslog_json will appear in that dropdown.

In the same screen, you can configure a specific Splunk listener port. For this example, we have used TCP port 515, but you can use a port of your choosing depending on what else has been configured. Please ensure that your agent configuration uses the same destination port. When Splunk is configured as above in the props.conf file, it will show up as a log format as shown below:

Once the new TCP source has been configured, it will show up in the system as follows.