NXLog User Guide
- OS Support
- Enterprise Edition Reference Manual
- 146. Man Pages
- 147. Configuration
- 148. Language
- 149. Extension Modules
- 149.1. Remote Management (xm_admin)
- 149.2. AIX Auditing (xm_aixaudit)
- 149.3. Apple System Logs (xm_asl)
- 149.4. Basic Security Module Auditing (xm_bsm)
- 149.5. Common Event Format (xm_cef)
- 149.6. Character set conversion (xm_charconv)
- 149.7. Encryption (xm_crypto)
- 149.8. Delimiter-Separated Values (xm_csv)
- 149.9. External programs (xm_exec)
- 149.10. File lists (xm_filelist)
- 149.11. File operations (xm_fileop)
- 149.12. GELF (xm_gelf)
- 149.13. Go (xm_go)
- 149.14. Grok (xm_grok)
- 149.15. Java (xm_java)
- 149.16. JSON (xm_json)
- 149.17. Key-value pairs (xm_kvp)
- 149.18. LEEF (xm_leef)
- 149.19. Microsoft DNS Server (xm_msdns)
- 149.20. Multiline parser (xm_multiline)
- 149.21. NetFlow (xm_netflow)
- 149.22. Microsoft Network Policy Server (xm_nps)
- 149.23. Pattern matcher (xm_pattern)
- 149.24. Perl (xm_perl)
- 149.25. Python (xm_python)
- 149.26. Resolver (xm_resolver)
- 149.27. Rewrite (xm_rewrite)
- 149.28. Ruby (xm_ruby)
- 149.29. SNMP traps (xm_snmp)
- 149.30. Remote Management (xm_soapadmin)
- 149.31. Syslog (xm_syslog)
- 149.32. W3C (xm_w3c)
- 149.33. WTMP (xm_wtmp)
- 149.34. XML (xm_xml)
- 149.35. Compression (xm_zlib)
- 150. Input Modules
- 151. Processor Modules
- 152. Output Modules
- NXLog Manager
- NXLog Add-Ons
This module makes it possible to execute pattern matching with a pattern database file in XML format. Using xm_pattern is more efficient than having NXLog regular expression rules listed in Exec directives, because it was designed in such a way that patterns do not need to be matched linearly. Regular expression sub-capturing can be used to set additional fields in the event record and arbitrary fields can be added under the scope of a pattern match for message classification. In addition, the module does an automatic on-the-fly pattern reordering internally for further speed improvements.
|To examine the supported platforms, see the list of installer packages in the Available Modules chapter.|
There are other techniques such as the radix tree which solve the linearity problem; the drawback is that usually these require the user to learn a special syntax for specifying patterns. If the log message is already parsed and is not treated as single line of message, then it is possible to process only a subset of the patterns which partially solves the linearity problem. With other performance improvements employed within the xm_pattern module, its speed can compare to the other techniques. Yet the xm_pattern module uses regular expressions which are familiar to users and can easily be migrated from other tools.
Traditionally, pattern matching on log messages has employed a technique where the log message was one string and the pattern (regular expression or radix tree based pattern) was executed against it. To match patterns against logs which contain structured data (such as the Windows Event Log), this structured data (the fields of the log) must be converted to a single string. This is a simple but inefficient method used by many tools.
The NXLog patterns defined in the XML pattern database file can contain more than one field. This allows multi-dimensional pattern matching. Thus with NXLog’s xm_pattern module there is no need to convert all fields into a single string as it can work with multiple fields.
Patterns can be grouped together under pattern groups. Pattern groups
serve an optimization purpose. The group can have an optional
matchfield block which can check a condition. If the condition (such
sshd) is satisfied, the xm_pattern module
will descend into the group and check each pattern against the log. If
the pattern group’s condition did not match (
$SourceName was not
sshd), the module can skip all patterns in the group without having
to check each pattern individually.
When the xm_pattern module finds a matching pattern, the
$PatternName fields are set on the log message. These can be
used later in conditional processing and correlation rules of the
pm_evcorr module, for example.
The xm_pattern module does not process all patterns. It exits after the
first matching pattern is found. This means that at most one pattern can
match a log message. Multiple patterns that can match the same subset of
logs should be avoided. For example, with two regular expression
The XML Schema Definition (XSD) for the pattern database file is available in the nxlog-public/contrib repository.
The xm_pattern module accepts the following directives in addition to the common module directives.
This mandatory directive specifies the name of the pattern database file.
The following functions are exported by xm_pattern.
The following procedures are exported by xm_pattern.
The following fields are used by xm_pattern.
The ID of the pattern that matched the event.
The name of the pattern that matched the event.
This configuration reads Syslog messages from file and parses them with
parse_syslog(). The events are then further
processed with a pattern file and the corresponding
match_pattern() procedure to add additional
fields to SSH authentication success or failure events. The matching is done
$Message fields, so the Syslog parsing must be
performed before the pattern matching will work.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <Extension _syslog> Module xm_syslog </Extension> <Extension pattern> Module xm_pattern PatternFile 'modules/extension/pattern/patterndb2-3.xml' </Extension> <Input in> Module im_file File 'test2.log' <Exec> parse_syslog(); match_pattern(); </Exec> </Input>
The following pattern database contains two patterns to match SSH
authentication messages. The patterns are under a group named ssh which
checks whether the
$SourceName field is
sshd and only tries to match the
patterns if the logs are indeed from sshd. The patterns both extract
$SourceIP4Address fields from the log
message when the pattern matches the log. Additionally
$TaxonomyAction are set. The second pattern shows an
Exec block example, which is evaluated when the pattern
<?xml version='1.0' encoding='UTF-8'?> <patterndb> <created>2018-01-01 01:02:03</created> <version>4</version> <group> <name>ssh</name> <id>1</id> <matchfield> <name>SourceName</name> <type>exact</type> <value>sshd</value> </matchfield> <pattern> <id>1</id> <name>ssh auth success</name> <matchfield> <name>Message</name> <type>regexp</type> <value>^Accepted (\S+) for (\S+) from (\S+) port \d+ ssh2</value> <capturedfield> <name>AuthMethod</name> <type>string</type> </capturedfield> <capturedfield> <name>AccountName</name> <type>string</type> </capturedfield> <capturedfield> <name>SourceIP4Address</name> <type>ipaddr</type> </capturedfield> </matchfield> <set> <field> <name>TaxonomyStatus</name> <value>success</value> <type>string</type> </field> <field> <name>TaxonomyAction</name> <value>authenticate</value> <type>string</type> </field> </set> </pattern> <pattern> <id>2</id> <name>ssh auth failure</name> <matchfield> <name>Message</name> <type>regexp</type> <value>^Failed (\S+) for invalid user (\S+) from (\S+) port \d+ ssh2</value> <capturedfield> <name>AuthMethod</name> <type>string</type> </capturedfield> <capturedfield> <name>AccountName</name> <type>string</type> </capturedfield> <capturedfield> <name>SourceIP4Address</name> <type>ipaddr</type> </capturedfield> </matchfield> <set> <field> <name>TaxonomyStatus</name> <value>failure</value> <type>string</type> </field> <field> <name>TaxonomyAction</name> <value>authenticate</value> <type>string</type> </field> </set> <exec> $TestField = 'test'; $TestField = $Testfield + 'value'; </exec> </pattern> </group> </patterndb>
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 <Extension _syslog> Module xm_syslog </Extension> <Extension pattern> Module xm_pattern PatternFile modules/extension/pattern/patterndb2-3.xml </Extension> <Input in> Module im_file File 'test2.log' <Exec> parse_syslog(); if not match_pattern() drop(); </Exec> </Input>