116. Snare

Table of Contents

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, as well as output log records in Snare format.

116.1. 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, which is the preferred method when forwarding events from Snare to a third-party solution. See Forwarding logs from Snare for how to configure Snare Agents and Snare Central to forward events to NXLog.

116.1.1. Windows Event Log

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

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

Syslog priority and timestamp
Hostname
Event data

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 parsing the data into fields with the xm_csv extension module.

Example 553. 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

  <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"
}

116.1.2. 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:

Syslog header
Event log type and Snare criticality
Event data consisting of several key-value pairs

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 554. 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 of the conditional blocks uses a specific regular expression to parse four new fields, $Process, $Uid, $ReturnCode, and $Success respectively, that are embedded in the $Message field. The enriched event is then converted to JSON using the xm_json module.

nxlog.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

  <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 kind of 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"
}

116.1.3. 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:

Syslog header, event log type, and Snare criticality
A set of key-value pairs containing event data
A set of metadata fields related to the event

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

Example 555. 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 is used to parse the key-value pairs from the event data, and the parse_csv() procedure of the xm_csv module is used to parse 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

  <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 kind of 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"
}

116.1.4. 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:

Syslog header
Event log type and Snare criticality
Event data read from file

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 556. 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, and $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 value of TRUE.

However, if 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, 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 then converted to JSON using the xm_json module.

nxlog.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

  <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 kind of 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"
}

Note	NXLog can parse log records in any format by means of its extension modules, built-in regular expressions support, or its various string manipulation functions. Refer to the documentation on Parsing Various Formats for more information and examples.

116.2. 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 collection of input and extension modules. This includes the Event Tracing for Windows (im_etw) module, which supports the collection of events from ETW-specific log channels that cannot be collected by the Snare Agent for Windows. 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 on generating Windows Event Log, Linux audit logs, and custom logs in Snare format.

Example 557. Sending Windows Event Log in Snare format

The configuration below collects Application 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.

Note	To further improve Snare interoperability, the upcoming version of NXLog will also support generating Windows events in Snare format without the syslog header.

nxlog.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

  <Extension syslog>
    Module    xm_syslog
</Extension>

<Input eventlog>
    Module    im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id='0'>
                <Select Path="Application">*</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 Application event sample was collected by NXLog.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="HPSupportSolutionsFrameworkService" />
    <EventID Qualifiers="0">0</EventID>
    <Level>4</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2021-04-07T15:00:20.637301300Z" />
    <EventRecordID>2905955</EventRecordID>
    <Channel>Application</Channel>
    <Computer>pc1</Computer>
    <Security />
  </System>
  <EventData>
    <Data>PowerEvent handled successfully by the service.</Data>
  </EventData>
</Event>

Output sample

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

<14>Apr  7 15:00:20 pc1 MSWinEventLog⇥1⇥Application⇥27156⇥Wed Apr 07 15:00:20 2021⇥0⇥HPSupportSolutionsFrameworkService⇥N/A⇥N/A⇥Information⇥pc1⇥N/A⇥⇥PowerEvent handled successfully by the service.⇥2878702

Example 558. Sending Linux audit events in Snare 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

  <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 559. Sending custom logs in Snare 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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

  <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\"

116.3. Forwarding logs from Snare to NXLog

To configure a Snare Agent to forward logs to NXLog:

Open the Snare Agent web interface.
From the left menu, click Destination Configuration.
In the Network Destinations section, enter the NXLog IP, port, and protocol.
Choose the log format. The examples in this guide are compatible with the SYSLOG (RFC3164) format.
Scroll to the bottom of the page and click the Update Destinations button.
From the left menu, click Apply Configuration & Restart Service.

To configure Snare Central to forward logs to NXLog:

Open the Snare Central web interface.
From the navigation pane, navigate to System > Administrative Tools > Configure Collector/Reflector.
Click Configure.
On the Destinations tab, click the Add Destination button.
Enter the NXLog IP, port, and protocol.
Choose the log format. The examples in this guide are compatible with the SYSLOG RFC 3164 format.
Click the Set button.
Restart the Snare Central service to apply the changes.

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

Note

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.2.6388
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: 12 April 2021

You are here

116. Snare | Log Collection Solutions

NXLog User Guide

116. Snare

116.1. Collecting Snare logs

116.1.1. Windows Event Log

116.1.2. Linux audit events

116.1.3. Microsoft SQL Server trace logs

116.1.4. Custom file-based logs

116.2. Generating Snare logs

116.3. Forwarding logs from Snare to NXLog