Alarming and Capture

Alarming

This function is available in flow rules only. This method fires an alarm in the NetMon Web Management interface, and also in the Syslog feed. Any custom fields set are included in the alarm Syslog feed.

The AppFieldsToSiemFlag parameter did not exist in NetMon version prior to 2.7.2. The default behavior is to set this flag to false so that no application-specific fields are sent to the SIEM.

--- Trigger User alarm, returns 0 upon success

--- Note: ruleSeverity must be one of the following: "low", "medium", "high"

--- Note: AppFieldsToSiemFlag is not a required parameter. By default this

--- flag is set to false, and none of the application specific fields will be

--- sent to the SIEM for EVT:010 syslog message. Set this flag to true if

--- the application specific fields such as url, process, command, etc fields

--- should be sent to the SIEM along with the Lua Rule specific fields.

--- Default behavior: TriggerUserAlarm(dpiMessage, ruleEngine, 'medium')

--- Application Specific fields sent to SIEM: TriggerUserAlarm(dpiMessage,

--- ruleEngine, 'medium', true)

void TriggerUserAlarm(dpiMessage, ruleEngine, ruleSeverity, AppFieldsToSiemFlag)

For a code example, see Trigger User Alarms.

Packet Capture

Packet capture voting functions are available in packet rules only.

There are two packet-level functions in Deep Packet Analytics Rules that can determine capture priorities for sessions:

VoteForPacketCapture(dpiMsg) = "yes" vote
VoteAgainstPacketCapture(dpiMsg) = "no" vote

Across multiple packet capture rules, a single "yes" vote by any rule marks the session for capture. If all rules vote "no," a session is not captured.

Votes for capture work in conjunction with the PCAP Flush Trigger Time Limit (milliseconds) setting—packets are captured or dropped according to the current vote at the time of the flush interval. The default interval is 10 seconds. Depending on when voting occurs relative to the flush interval, you may see some captures written to disk that you were not expecting, and you may see some captures discarded that you expected to be saved.

The following examples illustrate how voting works:

If the vote is "yes" during the flush interval but "no" after the interval passes, the beginning of the flow is captured, but the portion captured after the interval is discarded.
If the vote is "yes" at the beginning of the flush interval but "no" within the same interval, no part of the flow is saved to disk.

Under Select Applications for Packet Capture, Capture All must be turned OFF for voting to have any impact. If Capture All is enabled, all packets are captured, regardless of voting.

--- Vote yes for packet capture. This is typically used to enable capture of

--- sessions in spite of capture settings in the UI. One vote, by any packet

--- rule for a given DpiMsg is enough to trigger capturing of the packets in

--- that flow. Each "vote" is unique per rule. See also VoteAgainstPacketCapture()

void VoteForPacketCapture(dpiMessage)

For a code example, see Capture Traffic from Specific IPs.

--- Vote no for packet capture. This can be used to clear the rule's previous "yes"

--- vote made by calling VoteForPacketCapture(). Each vote is unique per rule.

void VoteAgainstPacketCapture(dpiMessage)