Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Extension Document Template

The example of an extension document provides information about how to parse one particular type of Cisco FWSM so that events are not sent with an incorrect event name.

For example, if you want to resolve the word session, which is embedded in the middle of the event name:

This condition causes the DSM to not recognize any events and all the events are unparsed and associated with the generic logger.

Although only a portion of the text string (302015) is used for the QID search, the entire text string (%FWSM-session-0-302015) identifies the event as coming from a Cisco FWSM. Since the entire text string is not valid, the DSM assumes that the event is not valid.

Extension Document Example for Parsing One Event Type

An FWSM device has many event types and many with unique formats. The following extension document example indicates how to parse one event type.

Note:

The pattern IDs do not have to match the field names that they are parsing. Although the following example duplicates the pattern, the SourceIp field and the SourceIpPreNAT field cab use the exact same pattern in this case. This situation might not be true in all FWSM events.

Parsing Basics

The preceding extension document example demonstrates some of the basic aspects of parsing:

  • IP addresses

  • Ports

  • Protocol

  • Multiple fields that use the same pattern with different groups

This example parses all FWSM events that follow the specified pattern. The fields that are parsed might not be present in those events when the events include different content.

The information that was necessary to create this configuration that was not available from the event:

  • The event name is only the last 6 digits (302015) of the %FWSM-session-0-302015 portion of the event.

  • The FWSM has a hardcoded device event category of Cisco Firewall.

  • The FWSM DSM uses the Cisco Pix QIDmap and therefore includes the device-type-id-override="6" parameter in the match group. The Pix firewall log source type ID is 6.

Note:

If the QID information is not specified or is unavailable, you can modify the event mapping. For more information, see the Modifying Event Mapping section in the Juniper Secure Analytics Users Guide.

Event Name and Device Event Category

An event name and a device event category are required when the QIDmap is searched. This device event category is a grouping parameter within the database that helps define like events within a device. The event-match-multiple at the end of the match group includes hardcoding of the category. The event-match-multiple uses the EventNameId pattern on the parsed event name to match up to 6 digits. This pattern is not run against the full payload, just that portion parsed as the EventName field.

The EventName pattern references the %FWSM portion of the events; all Cisco FWSM events contain the %FWSM portion. The pattern in the example matches %FWSM followed by any number (zero or more) of letters and dashes. This pattern match resolves the word session that is embedded in the middle of the event name that needs to be removed. The event severity (according to Cisco), followed by a dash and then the true event name as expected by JSA. The (\d{6}) string is the only string within the EventNameFWSM pattern that has a capture group.

The IP addresses and ports for the event all follow the same basic pattern: an IP address followed by a colon followed by the port number. This pattern parses two pieces of data (the IP address and the port), and specifies different capture groups in the matcher section.

IP Address and Port Patterns

The IP address and port patterns are four sets of one to three digits, separated by periods followed by a colon and the port number. The IP address section is in a group, as is the port number, but not the colon. The matcher sections for these fields reference the same pattern name, but a different capture group (the IP address is group 1 and the port is group 2).

The protocol is a common pattern that searches the payload for the first instance of TCP, UDP, ICMP, or GRE. The pattern is marked with the case-insensitive parameter so that any occurrence matches.

Although a second protocol pattern does not occur in the event that is used in the example, there is a second protocol pattern that is defined with an order of two. If the lowest-ordered protocol pattern does not match, the next one is attempted, and so on. The second protocol pattern also demonstrates direct substitution; there are no match groups in the pattern, but with the enable-substitutions parameter enabled, the text TCP can be used in place of protocol=6.

Related Documentation