Fortinet white logo
Fortinet white logo

User Guide

General Parsing Patterns

General Parsing Patterns

Global Built-in Patterns:

Several built-in patterns are defined – see Built-in Patterns. The names begin with "gPat". One example is the month pattern

<pattern name="gPatMon"><![CDATA[Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|\d{1,2}]]></pattern>

You can then use gPatMon directly instead of "Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|\d{1,2}".

Suppose the log is

Nov 28 2007 17:20:48: %ASA-6-302013: Built outbound TCP connection 76118 for outside:192.168.0.1/80 (192.168.0.1/80) to inside:192.168.20.31/3530 (192.168.0.1/5967)

The log is always stored in the temporary variable _rawMsg. To pick up the month from _rawMsg and store into a local variable _mon and the rest of the string into another variable, one can write:

<collectFieldsByRegex src="$_rawmsg">
<regex><![CDATA[<_mon:gPatMon>\s<_body:gPatMesgBody>]]></regex>
</collectFieldsByRegex>

After parsing, _mon is set to Nov and _body is set to "28 2007 17:20:48: %ASA-6-302013: Built outbound TCP connection 76118 for outside:192.168.0.1/80 (192.168.0.1/80) to inside:192.168.20.31/3530 (192.168.0.1/5967)"

The full list of global built-in patterns is here.

Local User defined Patterns:

In addition to the global patterns, you can define your own regular expression patterns for parsing your logs. You can name these patterns, so that they can be re-used later during actual parsing. These can only be used locally within this parser. If you want to reuse this pattern in another parser, then you have to repeat the definition in the other parser.

Each pattern has a name and the regular expression pattern within the CDATA section. This the basic syntax:

<pattern name="patternName"><!\[CDATA\[pattern\]\]></pattern>

This is an example of a pattern definition:

<patternDefinitions>
<pattern name="patIpV4Dot"><!\[CDATA\[\\d{1,3}.\\d{1,3}.\\d{1,3}.\\d{1,3}\]\]></pattern>
<pattern name="patComm"><!\[CDATA\[\[^,\]+\]\]></pattern>
<pattern name="patUpDown"><!\[CDATA\[up|down\]\]></pattern>
<pattern name="patStrEndColon"><!\[CDATA\[\[^:\]*\]\]></pattern>
</patternDefinitions>

You can also write a long pattern definition in multiple lines and indicate their order as shown in this example. The value of the list attribute should be begin in first line and end in last line. If there are more than two lines, the attribute should be set to continue for the other lines.

The general syntax is:

<pattern list="begin" name="myPattern"> <![CDATA[…]]></pattern>
<pattern list="continue" name="myPattern"><![CDATA[…]]></pattern>
<pattern list="continue" name="myPattern"><![CDATA[…]]></pattern>
<pattern list="end" name="myPattern"><![CDATA[…]]></pattern>

As an example:

<pattern name="patSolarisMod" list="begin"><![CDATA[sshd|login|]]></pattern>
<pattern name="patSolarisMod" list="continue"><![CDATA[inetd|lpstat|]]></pattern>
<pattern name="patSolarisMod" list="end"><![CDATA[su|sudo]]></pattern>

General Parsing Patterns

General Parsing Patterns

Global Built-in Patterns:

Several built-in patterns are defined – see Built-in Patterns. The names begin with "gPat". One example is the month pattern

<pattern name="gPatMon"><![CDATA[Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|\d{1,2}]]></pattern>

You can then use gPatMon directly instead of "Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec|\d{1,2}".

Suppose the log is

Nov 28 2007 17:20:48: %ASA-6-302013: Built outbound TCP connection 76118 for outside:192.168.0.1/80 (192.168.0.1/80) to inside:192.168.20.31/3530 (192.168.0.1/5967)

The log is always stored in the temporary variable _rawMsg. To pick up the month from _rawMsg and store into a local variable _mon and the rest of the string into another variable, one can write:

<collectFieldsByRegex src="$_rawmsg">
<regex><![CDATA[<_mon:gPatMon>\s<_body:gPatMesgBody>]]></regex>
</collectFieldsByRegex>

After parsing, _mon is set to Nov and _body is set to "28 2007 17:20:48: %ASA-6-302013: Built outbound TCP connection 76118 for outside:192.168.0.1/80 (192.168.0.1/80) to inside:192.168.20.31/3530 (192.168.0.1/5967)"

The full list of global built-in patterns is here.

Local User defined Patterns:

In addition to the global patterns, you can define your own regular expression patterns for parsing your logs. You can name these patterns, so that they can be re-used later during actual parsing. These can only be used locally within this parser. If you want to reuse this pattern in another parser, then you have to repeat the definition in the other parser.

Each pattern has a name and the regular expression pattern within the CDATA section. This the basic syntax:

<pattern name="patternName"><!\[CDATA\[pattern\]\]></pattern>

This is an example of a pattern definition:

<patternDefinitions>
<pattern name="patIpV4Dot"><!\[CDATA\[\\d{1,3}.\\d{1,3}.\\d{1,3}.\\d{1,3}\]\]></pattern>
<pattern name="patComm"><!\[CDATA\[\[^,\]+\]\]></pattern>
<pattern name="patUpDown"><!\[CDATA\[up|down\]\]></pattern>
<pattern name="patStrEndColon"><!\[CDATA\[\[^:\]*\]\]></pattern>
</patternDefinitions>

You can also write a long pattern definition in multiple lines and indicate their order as shown in this example. The value of the list attribute should be begin in first line and end in last line. If there are more than two lines, the attribute should be set to continue for the other lines.

The general syntax is:

<pattern list="begin" name="myPattern"> <![CDATA[…]]></pattern>
<pattern list="continue" name="myPattern"><![CDATA[…]]></pattern>
<pattern list="continue" name="myPattern"><![CDATA[…]]></pattern>
<pattern list="end" name="myPattern"><![CDATA[…]]></pattern>

As an example:

<pattern name="patSolarisMod" list="begin"><![CDATA[sshd|login|]]></pattern>
<pattern name="patSolarisMod" list="continue"><![CDATA[inetd|lpstat|]]></pattern>
<pattern name="patSolarisMod" list="end"><![CDATA[su|sudo]]></pattern>