Snare
Snare is a log collection and management solution. It provided 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 Agent 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 Agent 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 Agent for how to configure Snare Agents and Snare Central to forward events to NXLog Agent.
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 Agent 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.
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.
<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>
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 Agent 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
The following JSON shows the same event after NXLog Agent 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:
-
Syslog header
-
Event log type and Snare criticality
-
Event data consisting of several key-value pairs
NXLog Agent 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.
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.
<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>
The following Linux audit event in Snare format has a syslog (RFC 3164) header. This input sample depicts the data and format NXLog Agent 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):
The following JSON shows the same event after NXLog Agent 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:
-
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 Agent can parse key-value pairs into fields using the xm_kvp extension module, while the xm_csv extension module parses the metadata fields.
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.
<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>
The following Microsoft SQL Server event in Snare format has a syslog (RFC 3164) header. This input sample depicts the data and format NXLog Agent 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
The following JSON shows the same event after NXLog Agent 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:
-
Syslog header
-
Event log type and Snare criticality
-
Event data read from file
NXLog Agent 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.
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.
<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>
The following Apache access log event in Snare format has a syslog (RFC 3164) header. This input sample depicts the data and format NXLog Agent 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"
The following JSON shows the same event after NXLog Agent 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 Agent can parse log records in any format through its extension modules, built-in regular expressions support, or various string manipulation functions. Refer to Parse unstructured logs and Parse standard log formats for more information and examples. |
Generating Snare logs
NXLog Agent can generate logs in the Snare format and provides all the necessary functionality to replace Snare Agents. NXLog Agent 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 Agent vs. Snare feature comparison provides an in-depth analysis of how NXLog Agent 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.
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.
<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>
This System event sample was collected by NXLog Agent.
<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>
Here is the same event after NXLog Agent 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
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.
<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>
This System event sample was collected by NXLog Agent.
<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>
Here is the same event after NXLog Agent 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
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.
<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>
The following is a Linux audit event that NXLog Agent 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\"
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.
<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>
This Apache access log sample was collected by NXLog Agent.
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"
Here is the same event after NXLog Agent 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 Agent
To configure a Snare Agent to forward logs to NXLog Agent:
-
Open the Snare Agent web interface.
-
From the left menu, click Destination Configuration.
-
In the Network Destinations section, enter the NXLog Agent 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 Agent:
-
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 Agent 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.
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. |