Snare

Snare is a log collection and management solution, providing Snare Agents to ingest logs from different sources and Snare Central to store and archive log data. Snare Agents output events in tab-delimited records commonly referred to as Snare format and can use syslog over TCP or UDP as the transport. NXLog can integrate with both Snare Agents and Snare Central to receive logs, and output log records in Snare format.

Collecting Snare logs

Snare Agents do not support message rewrite and provide limited custom log processing capabilities. This may pose a challenge when logs need to be forwarded to a third-party SIEM or a log analytics service that does not support the Snare format. NXLog provides log processing flexibility, log enrichment capabilities and can output logs in various formats supported by modern SIEMs, such as JSON and XML. It can receive events from Snare Agents or Snare Central using the im_tcp or im_udp input modules, parse them into structured data, and output events in the required format.

This section provides information and configuration examples on parsing events from the various Snare Agents. The examples below support event records received in Snare syslog (RFC 3164) format, the preferred method when forwarding events from Snare to a third-party solution. See Forwarding logs from Snare to NXLog for how to configure Snare Agents and Snare Central to forward events to NXLog.

Windows Event Log

The Snare Agent for Windows collects events from Windows Event Log. The Snare format for Windows events is as follows:

Snare Linux audit event format

When the agent is configured to forward events with the syslog (RFC 3164) header, event records can be broken down into three components:

  1. Syslog priority and timestamp

  2. Hostname

  3. Event data

Snare Linux audit event format

For more information on the event fields, see Appendix A - Windows Event Output Format of the Snare Windows Agent v5 Documentation.

NXLog can parse both formats by using a regular expression to extract the event data and then parse the data into fields with the xm_csv extension module.

Example 1. Parsing events from Windows Event Log

The following input instance is configured to listen on TCP port 514 using all available IPv4 addresses. It supports both the regular Snare format and Snare format with the syslog header. Event data is parsed into fields using the parse_csv() procedure of the xm_csv module and converted to JSON using the xm_json module. If an event does not match the required format, it is tagged with a $ParseFailure, and the original event text is preserved in the $RawEvent field.

nxlog.conf
<Extension json>
    Module        xm_json
</Extension>

<Extension csv_evt>
    Module        xm_csv
    Fields        $EventLogType, $Criticality, $LogName, $SnareCounter, \
                  $DateTime, $EventID, $SourceName, $UserName, $SIDType, \
                  $EventLogType, $ComputerName, $CategoryString, $DataString, \
                  $ExpandedString, $MD5Checksum
    FieldTypes    string, integer, string, integer, \
                  datetime, integer, string, string, string, \
                  string, string, string, string, string, string
    Delimiter     \t
</Extension>

<Input tcp_listen>
    Module        im_tcp
    ListenAddr    0.0.0.0:514
    <Exec>
        if $raw_event =~ /^(?:.*\s)?(\S+)\s(MSWinEventLog.+)$/
        {
            $Hostname = $1;
            $Message = $2;

            csv_evt->parse_csv($Message);
            delete($Message);
        }
        else
        {
            $ParseFailure = TRUE;
            $RawEvent = $raw_event;
        }

        to_json();
    </Exec>
</Input>
Input sample

The following Windows Event Log record in Snare format has a syslog (RFC 3164) header. This input sample depicts the kind of data and format NXLog will receive from Snare.

<14>Apr 06 15:40:08 server-1 MSWinEventLog	6	Application	8544	Tue Apr 06 15:40:08 2021	41092	MSSQLSERVER	N/A	N/A	Information	server-1	Server		Always On: The availability replica manager is going offline because SQL Server is shutting down. This is an informational message only. No user action is required.	385
Output sample

The following JSON shows the same event after NXLog has parsed and processed it.

{
  "MessageSourceAddress": "10.0.0.106",
  "EventReceivedTime": "2021-04-06T15:40:08.709880+02:00",
  "SourceModuleName": "tcp_listen",
  "SourceModuleType": "im_tcp",
  "Hostname": "server-1",
  "EventLogType": "Information",
  "Criticality": 6,
  "LogName": "Application",
  "SnareCounter": 8544,
  "DateTime": "2021-04-06T15:40:08.000000+02:00",
  "EventID": 41092,
  "SourceName": "MSSQLSERVER",
  "UserName": "N/A",
  "SIDType": "N/A",
  "ComputerName": "server-1",
  "CategoryString": "Server",
  "ExpandedString": "Always On: The availability replica manager is going offline because SQL Server is shutting down. This is an informational message only. No user action is required.",
  "MD5Checksum": "385"
}

Linux audit events

The Snare Agent for Linux collects Linux audit logs. When configured to forward events with the syslog (RFC 3164) header, event records can be broken down into three components:

  1. Syslog header

  2. Event log type and Snare criticality

  3. Event data consisting of several key-value pairs

Snare Linux audit event format

NXLog can parse the syslog message using the xm_syslog extension module. The event data can be further processed to extract values into fields using regular expressions.

For more information on Linux audit logs, see the Red Hat documentation on Understanding Audit Log Files.

Example 2. Parsing Linux audit events

The following input instance is configured to listen on TCP port 514 using all available IPv4 addresses. It supports parsing Linux audit events in Snare format with the syslog (RFC 3164) header. The xm_syslog module is used to parse the syslog message. Each conditional block uses a specific regular expression to parse four new fields, $Process, $Uid, $ReturnCode, and $Success, respectively, embedded in the $Message field. The enriched event is then converted to JSON using the xm_json module.

nxlog.conf
<Extension json>
    Module        xm_json
</Extension>

<Extension syslog>
    Module        xm_syslog
</Extension>

<Input tcp_listen>
    Module        im_tcp
    ListenAddr    0.0.0.0:514
    <Exec>
        parse_syslog_bsd();

        if $Message =~ /exe="(\S*)".*/
        {
            $Process = $1;
        }

        if $Message =~ /\suid=(\d*)\s.*/
        {
            $Uid = $1;
        }

        if $Message =~ /exit=(\S*)\s.*/
        {
            $ReturnCode = $1;
        }

        if $Message =~ /success=(\S*)\s.*/
        {
            $Success = $1;
        }

        to_json();
    </Exec>
</Input>
Input sample

The following Linux audit event in Snare format has a syslog (RFC 3164) header. This input sample depicts the data and format NXLog will receive from Snare.

<12>Apr 07 11:39:38 server-2 LinuxKAudit	4	audit(1617788378.199:36619): arch=c000003e syscall=87 success=yes exit=0 a0=7ffc46d40ee0 a1=7fec3c3f88e9 a2=7fec8ca5c206 a3=1c50410fda87 items=2 ppid=2171 pid=2843 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm="firefox" exe="/usr/lib64/firefox/firefox" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="obj-2-3" audit(1617788378.199:36619):  cwd="/home/jdoe" audit(1617788378.199:36619): item=0 name="/dev/shm/" inode=7351 dev=00:12 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 objtype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 audit(1617788378.199:36619): item=1 name="/dev/shm/org.mozilla.ipc.2843.1886" inode=98413 dev=00:12 mode=0100600 ouid=1000 ogid=1000 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 objtype=DELETE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 audit(1617788378.199:36619): proctitle="/usr/bin/gnome-shell" audit(1617788378.199:36619):   
Output sample

The following JSON shows the same event after NXLog has parsed and processed it.

{
  "MessageSourceAddress": "10.0.0.104",
  "EventReceivedTime": "2021-04-07T11:46:03.641353+02:00",
  "SourceModuleName": "tcp_listen",
  "SourceModuleType": "im_tcp",
  "SyslogFacilityValue": 1,
  "SyslogFacility": "USER",
  "SyslogSeverityValue": 4,
  "SyslogSeverity": "WARNING",
  "SeverityValue": 3,
  "Severity": "WARNING",
  "Hostname": "server-2",
  "EventTime": "2021-04-07T11:39:38.000000+02:00",
  "Message": "LinuxKAudit\t4\taudit(1617788378.199:36619): arch=c000003e syscall=87 success=yes exit=0 a0=7ffc46d40ee0 a1=7fec3c3f88e9 a2=7fec8ca5c206 a3=1c50410fda87 items=2 ppid=2171 pid=2843 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=1 comm=\"firefox\" exe=\"/usr/lib64/firefox/firefox\" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=\"obj-2-3\" audit(1617788378.199:36619):  cwd=\"/home/jdoe\" audit(1617788378.199:36619): item=0 name=\"/dev/shm/\" inode=7351 dev=00:12 mode=041777 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmpfs_t:s0 objtype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 audit(1617788378.199:36619): item=1 name=\"/dev/shm/org.mozilla.ipc.2843.1886\" inode=98413 dev=00:12 mode=0100600 ouid=1000 ogid=1000 rdev=00:00 obj=unconfined_u:object_r:user_tmp_t:s0 objtype=DELETE cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 audit(1617788378.199:36619): proctitle=\"/usr/bin/gnome-shell\" audit(1617788378.199:36619): ",
  "Process": "/usr/lib64/firefox/firefox",
  "Uid": "1000",
  "ReturnCode": "0",
  "Success": "yes"
}

Microsoft SQL Server trace logs

The Snare MSSQL Agent is a Windows-based agent that collects trace logs from Microsoft SQL Server. When configured to forward events with the syslog (RFC 3164) header, event records can be broken down into three components:

  1. Syslog header, event log type, and Snare criticality

  2. A set of key-value pairs containing event data

  3. A set of metadata fields related to the event

Snare MSSQL event format

NXLog can parse key-value pairs into fields using the xm_kvp extension module, while the xm_csv extension module parses the metadata fields.

Example 3. Parsing Microsoft SQL Server events

The following input instance is configured to listen on TCP port 514 using all available IPv4 addresses. It supports parsing Microsoft SQL Server events in Snare format with the syslog (RFC 3164) header. The parse_kvp() procedure of the xm_kvp module parses the key-value pairs from the event data, and the parse_csv() procedure of the xm_csv module parses the event metadata. The event is then converted to JSON using the xm_json module. If an event does not match the required format, it is tagged with a $ParseFailure, and the original event text is preserved in the $RawEvent field.

nxlog.conf
<Extension json>
    Module          xm_json
</Extension>

<Extension csv_mssql>
    Module          xm_csv
    Fields          $DateTime, $MSSQLVersion,  $EventClass, \
                    $EventSubclass, $SPID, $InstanceName, $Username
    FieldTypes      datetime, string, integer, \
                    integer, integer, string, string
    Delimiter       \t
</Extension>

<Extension kvp_mssql>
    Module          xm_kvp
    KVDelimiter     ,
    KVPDelimiter    \t
</Extension>

<Input tcp_listen>
    Module          im_tcp
    ListenAddr      0.0.0.0:514
    <Exec>
        if $raw_event =~ /^.*\t(\d)\t(TextData.*(?:\t.*,[^\t]*))\t(.*)$/
        {
            # Set criticality
            $SnareCriticLevel = $1;

            # Parse event key-value pairs
            kvp_mssql->parse_kvp($2);

            # Parse event metadata
            csv_mssql->parse_csv($3);
        }
        else
        {
            $ParseFailure = TRUE;
            $RawEvent = $raw_event;
        }

        to_json();
    </Exec>
</Input>
Input sample

The following Microsoft SQL Server event in Snare format has a syslog (RFC 3164) header. This input sample depicts the data and format NXLog will receive from Snare.

<14>Apr 06 13:53:32 server-1 MSSQLLog	6	TextData,if not exists (select * from sys.dm_xe_sessions where name = 'telemetry_xevents')	Success,1	SessionLoginName,NT Service\SQLTELEMETRY	NTUserName,SQLTELEMETRY	DBUserName,public	HostName,server-1	ApplicationName,SQLServerCEIP	TransID,98439	2021-04-06 13:53:30.403	15.00.2000	173	11	54	MSSQLSERVER/master	NT SERVICE\SQLTELEMETRY
Output sample

The following JSON shows the same event after NXLog has parsed and processed it.

{
  "MessageSourceAddress": "10.0.0.106",
  "EventReceivedTime": "2021-04-06T13:54:03.432129+02:00",
  "SourceModuleName": "tcp_listen",
  "SourceModuleType": "im_tcp",
  "SnareCriticLevel": "6",
  "TextData": "if not exists (select * from sys.dm_xe_sessions where name = 'telemetry_xevents')",
  "Success": 1,
  "SessionLoginName": "NT Service\\SQLTELEMETRY",
  "NTUserName": "SQLTELEMETRY",
  "DBUserName": "public",
  "HostName": "server-1",
  "ApplicationName": "SQLServerCEIP",
  "TransID": 98439,
  "DateTime": "2021-04-06T13:53:30.403000+02:00",
  "MSSQLVersion": "15.00.2000",
  "EventClass": 173,
  "EventSubclass": 11,
  "SPID": 54,
  "InstanceName": "MSSQLSERVER/master",
  "Username": "NT SERVICE\\SQLTELEMETRY"
}

Custom file-based logs

Snare Agents, including Snare Epilog for Windows, can be configured to collect events from text-based log files. When configured to forward events with the syslog (RFC 3164) header, event records can be broken down into three components:

  1. Syslog header

  2. Event log type and Snare criticality

  3. Event data read from file

Snare custom event format

NXLog can parse the syslog message using the xm_syslog extension module. The event data can be further processed to extract values into fields using regular expressions.

Example 4. Parsing Apache access logs

The following input instance is configured to listen on TCP port 514 using all available IPv4 addresses. It supports parsing Apache access events in Snare format with the syslog (RFC 3164) header. The parse_syslog_bsd() procedure of the xm_syslog module is used to parse the syslog message.

The first conditional block uses a regular expression to parse the three main components from $Message into new fields:

  • $EventLogType

  • $Criticality

  • $Message

If this match cannot be made, no parsing is done and the event record is enriched with a single new field, $ParseFailure, which is assigned a TRUE value.

However, suppose initial parsing was successful and the new $Message field, which no longer contains the other two components ($EventLogType and $Criticality), matches the regular expression in the nested conditional block. In that case, nine additional fields specific to Apache access logs will be parsed, bringing the total field count to 12.

Once all new fields have been parsed, the enriched event is converted to JSON using the xm_json module.

nxlog.conf
<Extension json>
    Module        xm_json
</Extension>

<Extension syslog>
    Module        xm_syslog
</Extension>

<Input tcp_listen>
    Module        im_tcp
    ListenAddr    0.0.0.0:514
    <Exec>
        parse_syslog_bsd();

        if $Message =~ /^(ApacheLog)\s(\w+)\s(.*)$/
        {
            $EventLogType = $1;
            $Criticality = $2;
            $Message = $3;

            if $Message =~ /(?x)^(\S+)\ \S+\ (\S+)\ \[([^\]]+)\]\ \"(\S+)\ (.+)
                          \ HTTP\/\d\.\d\"\ (\S+)\ (\S+)\ \"([^\"]+)\"
                          \ \"([^\"]+)\"/
            {
                $Hostname = $1;
                if $2 != '-' $AccountName = $2;
                $EventTime = parsedate($3);
                $HTTPMethod = $4;
                $HTTPURL = $5;
                $HTTPResponseStatus = $6;
                if $7 != '-' $FileSize = $7;
                if $8 != '-' $HTTPReferer = $8;
                if $9 != '-' $HTTPUserAgent = $9;
            }
        }
        else
        {
            $ParseFailure = TRUE;
        }

        to_json();
    </Exec>
</Input>
Input sample

The following Apache access log event in Snare format has a syslog (RFC 3164) header. This input sample depicts the data and format NXLog will receive from Snare.

<14>Apr 07 15:08:29 server-2 ApacheLog	6	83.149.9.216 - - [07/Apr/2021:05:13:42 +0000] "GET /presentations/nxlog/images/icon.png HTTP/1.1" 200 430406 "http://example.com/presentations/nxlog/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36"
Output sample

The following JSON shows the same event after NXLog has parsed and processed it.

{
  "MessageSourceAddress": "10.0.0.104",
  "EventReceivedTime": "2021-04-07T15:09:00.524911+02:00",
  "SourceModuleName": "tcp_listen",
  "SourceModuleType": "im_tcp",
  "SyslogFacilityValue": 1,
  "SyslogFacility": "USER",
  "SyslogSeverityValue": 6,
  "SyslogSeverity": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "Hostname": "83.149.9.216",
  "EventTime": "2021-04-07T05:13:42.000000+02:00",
  "Message": "83.149.9.216 - - [07/Apr/2021:05:13:42 +0000] \"GET /presentations/nxlog/images/icon.png HTTP/1.1\" 200 430406 \"http://example.com/presentations/nxlog/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36\"",
  "EventLogType": "ApacheLog",
  "Criticality": "6",
  "HTTPMethod": "GET",
  "HTTPURL": "/presentations/nxlog/images/icon.png",
  "HTTPResponseStatus": "200",
  "FileSize": "430406",
  "HTTPReferer": "http://example.com/presentations/nxlog/",
  "HTTPUserAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36"
}
NXLog can parse log records in any format through its extension modules, built-in regular expressions support, or various string manipulation functions. Refer to the documentation on Parsing various log formats for more information and examples.

Generating Snare logs

NXLog can generate logs in the Snare format and provides all the necessary functionality to replace Snare Agents. NXLog also supports a wider range of log sources through its extensive input and extension modules collection. This includes the Event Tracing for Windows (im_etw) module, which supports collecting events from ETW-specific log channels that the Snare Agent for Windows cannot collect. The NXLog vs. Snare feature comparison provides an in-depth analysis of how NXLog compares to Snare Enterprise Agents.

For converting Windows Event Log records to Snare format, the xm_syslog module provides native support. For all other log sources, the xm_csv module can be used. This section provides configuration examples for generating Windows Event Log, Linux audit logs, and custom logs in Snare format.

Example 5. Sending Windows Event Log in Snare syslog format

The configuration below collects System events from Windows Event Log using the im_msvistalog input module. Events are converted to Snare format with the syslog (RFC 3164) header using the to_syslog_snare() procedure of the xm_syslog module.

nxlog.conf
<Extension syslog>
    Module    xm_syslog
</Extension>

<Input eventlog>
    Module    im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id='0'>
                <Select Path="System">*</Select>
            </Query>
        </QueryList>
    </QueryXML>
    <Exec>
        # Replace any tabs or newline with a space
        $Message =~ s/(\t|\R)/ /g;

        to_syslog_snare();
    </Exec>
</Input>
Input sample

This System event sample was collected by NXLog.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
    <EventID Qualifiers="16384">7036</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8080000000000000</Keywords>
    <TimeCreated SystemTime="2021-10-01T07:22:32.423385000Z" />
    <EventRecordID>11801</EventRecordID>
    <Correlation />
    <Execution ProcessID="536" ThreadID="1696" />
    <Channel>System</Channel>
    <Computer>SERVER-1</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">nxlog</Data>
    <Data Name="param2">running</Data>
    <Binary>6E0078006C006F0067002F0034000000</Binary>
  </EventData>
</Event>
Output sample

Here is the same event after NXLog converted it to Snare format with the syslog (RFC 3164) header.

<14>Oct  1 09:22:32 SERVER-1 MSWinEventLog	1	System	11801	Fri Oct 01 09:22:32 2021	7036	Service Control Manager	N/A	N/A	Information	SERVER-1	N/A		The nxlog service entered the running state.	11801
Example 6. Sending Windows Event Log in Snare format

The configuration below collects System events from Windows Event Log using the im_msvistalog input module. Events are converted to Snare format using the to_snare() procedure of the xm_syslog module.

The to_snare() procedure was introduced in NXLog Enterprise Edition version 5.4. For older versions, see the Sending Windows Event Log in Snare syslog format example above.
nxlog.conf
<Extension syslog>
    Module    xm_syslog
</Extension>

<Input eventlog>
    Module    im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id='0'>
                <Select Path="System">*</Select>
            </Query>
        </QueryList>
    </QueryXML>
    <Exec>
        # Replace any tabs or newline with a space
        $Message =~ s/(\t|\R)/ /g;

        to_snare();
    </Exec>
</Input>
Input sample

This System event sample was collected by NXLog.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Service Control Manager" Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service Control Manager" />
    <EventID Qualifiers="16384">7036</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>0</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8080000000000000</Keywords>
    <TimeCreated SystemTime="2021-10-01T07:22:32.423385000Z" />
    <EventRecordID>11801</EventRecordID>
    <Correlation />
    <Execution ProcessID="536" ThreadID="1696" />
    <Channel>System</Channel>
    <Computer>SERVER-1</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="param1">nxlog</Data>
    <Data Name="param2">running</Data>
    <Binary>6E0078006C006F0067002F0034000000</Binary>
  </EventData>
</Event>
Output sample

Here is the same event after NXLog converted it to Snare format.

SERVER-1	MSWinEventLog	1	System	11801	Fri Oct 01 09:22:32 2021	7036	Service Control Manager	N/A	N/A	Information	SERVER-1	N/A		The nxlog service entered the running state.	11801
Example 7. Sending Linux audit events in Snare syslog format

The configuration below uses the im_linuxaudit input module to monitor modifications to a file. It sets the required $EventType, $Criticality, and $EventMessage fields and uses the xm_csv module to output the fields as tab-delimited strings. The to_syslog_bsd() procedure of the xm_syslog module is then used to output the event with the syslog (RFC 3164) header.

nxlog.conf
<Extension syslog>
    Module           xm_syslog
</Extension>

<Extension snare_linux>
    Module           xm_csv
    Fields           $EventType, $Criticality, $EventMessage
    Delimiter        \t
    QuoteMethod      None
</Extension>

<Input linux_audit>
    Module           im_linuxaudit
    FlowControl      FALSE
    ResolveValues    TRUE
    <Rules>
        # Watch /etc/passwd for modifications and tag with 'passwd'
        -w /etc/passwd -p war -k passwd
    </Rules>
    <Exec>
        $EventType = "LinuxKAudit";
        $Criticality = "1";
        $EventMessage = $raw_event;

        # Remove the NXLog event header
        $EventMessage =~ s/^(?:[^\s]*\s){4}//;

        snare_linux->to_csv();

        to_syslog_bsd();
    </Exec>
</Input>
Output sample

The following is a Linux audit event that NXLog captured and converted to Snare format.

<13>Apr  9 09:57:51 server-2 LinuxKAudit	1	type=\"SYSCALL\" time=\"2021-04-09 09:57:51\" seq=\"313\" arch=\"x86_64\" syscall=\"openat\" success=\"yes\" exit=\"15\" a0=\"ffffff9c\" a1=\"7f24d401f650\" a2=\"40000\" a3=\"0\" items=\"1\" ppid=\"1285\" pid=\"3556\" auid=\"jdoe\" uid=\"root\" gid=\"root\" euid=\"root\" suid=\"root\" fsuid=\"root\" egid=\"root\" sgid=\"root\" fsgid=\"root\" tty=\"(none)\" ses=\"3\" comm=\"pool-gedit\" exe=\"/usr/bin/gedit\" subj=\"unconfined\" key=\"passwd\"
Example 8. Sending custom logs in Snare syslog format

The configuration below uses the im_file input module to collect Apache access logs. It sets the required $EventType, $Criticality, and $EventMessage fields and uses the xm_csv module to output the fields as tab-delimited strings. The to_syslog_bsd() procedure of the xm_syslog module is then used to output the event with the syslog (RFC 3164) header.

nxlog.conf
<Extension syslog>
    Module         xm_syslog
</Extension>

<Extension snare_custom>
    Module         xm_csv
    Fields         $EventType, $Criticality, $EventMessage
    Delimiter      \t
    QuoteMethod    None
</Extension>

<Input apache_access>
    Module         im_file
    File           '/path/to/log/file'
    <Exec>
        $EventType = "ApacheLog";
        $Criticality = "1";
        $EventMessage = $raw_event;

        snare_custom->to_csv();

        to_syslog_bsd();
    </Exec>
</Input>
Input sample

This Apache access log sample was collected by NXLog.

83.149.9.216 - - [07/Apr/2021:05:13:42 +0000] "GET /presentations/nxlog/images/icon.png HTTP/1.1" 200 430406 "http://example.com/presentations/nxlog/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36"
Output sample

Here is the same event after NXLog converted it to Snare format.

<13>Apr  7 16:30:58 server-2 ApacheLog	1	83.149.9.216 - - [07/Apr/2021:05:13:42 +0000] \"GET /presentations/nxlog/images/icon.png HTTP/1.1\" 200 430406 \"http://example.com/presentations/nxlog/\" \"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.77 Safari/537.36\"

Forwarding logs from Snare to NXLog

To configure a Snare Agent to forward logs to NXLog:

  1. Open the Snare Agent web interface.

  2. From the left menu, click Destination Configuration.

  3. In the Network Destinations section, enter the NXLog IP, port, and protocol.

  4. Choose the log format. The examples in this guide are compatible with the SYSLOG (RFC3164) format.

    Snare agent destination configuration
  5. Scroll to the bottom of the page and click the Update Destinations button.

  6. From the left menu, click Apply Configuration & Restart Service.

To configure Snare Central to forward logs to NXLog:

  1. Open the Snare Central web interface.

  2. From the navigation pane, navigate to System > Administrative Tools > Configure Collector/Reflector.

    Snare Central menu
  3. Click Configure.

  4. On the Destinations tab, click the Add Destination button.

  5. Enter the NXLog IP, port, and protocol.

  6. Choose the log format. The examples in this guide are compatible with the SYSLOG RFC 3164 format.

    Snare Central destination configuration
  7. Click the Set button.

  8. Restart the Snare Central service to apply the changes.

More information on the destination settings can be found in the Snare Central documentation.

Although it is possible to forward logs in Snare format without the syslog header, this format is designed to work primarily with Snare Central. When logs are forwarded in the regular Snare format, they may include undocumented fields, which will require different processing from the examples in this documentation. The format may also change with different versions of the Snare Agent. For this reason, we recommended that you forward logs from Snare with the syslog (RFC 3164) header.
Disclaimer

While we endeavor to keep the information in this topic up to date and correct, NXLog makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability, or availability of the content represented here.

The accurateness of the content was tested and proved to be working in our lab environment at the time of the last revision with the following software versions:

NXLog version 5.4.7313
Snare Central version 8.1.0
Snare Enterprise Agent for Windows version 5.4.1
Snare Enterprise Epilog for Windows 5.4.1
Snare Enterprise MSSQL version 5.4.1
Snare Enterprise Agent for Linux RHEL 7 version 5.4.0

Last revision: 3 May 2022