Working with triggers¶

Triggers are tools that are used to set up custom notifications and reactions to events. Using triggers, you can:

• Receive alerts on major events via the tools you use for your day-to-day workflow, for example via corporate messengers or incident management systems.

• Block IP addresses from which a certain number of requests or attack vectors were sent.

• Identify brute‑force and forced browsing attacks by the number of requests sent to the application addresses.

• Optimize the event list by grouping hits originating from the same IP address into one attack

You can configure all the trigger components:

• Condition: system event to be notified about. For example: getting a certain amount of attacks, denylisted IP address, and new user added to the account.

• Filters: condition details. For example: attack types.

• Reaction: action that should be performed if the specified condition and filters are met. For example: sending the notification to Slack or another system configured as the integration, blocking IP address, or marking requests as the brute‑force attack.

Triggers are configured in the Triggers section of Wallarm Console. The section is available only for users with the Administrator role.

Creating triggers¶

1. Click the Create trigger button.

2. Choose conditions.

3. Add filters.

4. Add reactions.

5. Save the trigger.

Step 1: Choosing a condition¶

A condition is a system event to be notified about. The following conditions are available for notification:

• Brute force

• Forced browsing

• BOLA that is supported starting from Wallarm node 4.2

• Number of attack vectors (malicious payloads) (experimental payloads based on custom regular expressions are not counted)

• Number of attacks (experimental attacks based on custom regular expressions are not counted)

• Number of hits except for:

  • Experimental hits detected based on the custom regular expression. Non-experimental hits are counted.
  • Hits not saved in the sample.

• Number of incidents

• Denylisted IP

• Hits from the same IP, except for the ones of the Brute force, Forced browsing, Resource overlimit, Data bomb and Virtual patch attack types

• User added

Choose a condition in the Wallarm Console interface and set the lower threshold for the reaction, if the setting is available.

Step 2: Adding filters¶

Filters are used for condition detailing. For example, you can set up reactions to attacks of certain types, such as brute-force attacks, SQL injections and others.

The following filters are available:

• URI (only for the conditions Brute force and Forced browsing): full URI to which the request was sent. URI can be configured via the URI constructor or advanced edit form.

• Type is a type of attack detected in the request or a type of vulnerability the request is directed to.

• Application is the application that receives the request or in which an incident is detected.

• IP is an IP address from which the request is sent.

  The filter expects only single IPs, it does not allow subnets, locations and source types.

• Domain is the domain that receives the request or in which an incident is detected.

• Response status is the response code returned to the request.

• Target is an application architecture part that the attack is directed at or in which the incident is detected. It can take the following values: Server, Client, Database.

• User's role is the role of the added user. It can take the following values: Deploy, Analyst, Admin.

Choose one or more filters in the Wallarm Console interface and set values for them.

Step 3: Adding reactions¶

A reaction is an action that should be performed if the specified condition and filters are met. The set of available reactions depends on the selected condition. Reactions can be of the following types:

• Mark the requests as brute‑force or forced browsing attack. Requests will be marked as attacks in the events list but will not be blocked. To block requests, you can add an additional reaction: denylist IP address.

• Add IP to the denylist.

• Add IP to the graylist.

• Send a notification to the SIEM system or Webhook URL configured in the integrations.

• Send a notification to the messenger configured in the integrations.

  Notifying about denylisted IPs via the messengers

  Triggers allow sending notifications on denylisted IPs only to the SIEM systems or Webhook URL. Messengers are not available for the Denylisted IP trigger condition.

• Group next hits into one attack if the trigger condition is Hits from the same IP.

  The Mark as false positive button and the active verification option will be unavailable for these attacks.

Choose one or more reactions in the Wallarm Console interface. Reactions available for the condition are located at Number of attacks:

Step 4: Saving the trigger¶

1. Click the Create button in the trigger creation modal dialog.

2. Specify the trigger's name and description (if required) and click the Done button.

If the trigger name and description are not specified, then the trigger is created with the name New trigger by <username>, <creation_date> and an empty description.

Pre-configured triggers (default triggers)¶

New company accounts are featured by the following pre-configured triggers (default triggers):

• Group hits originating from the same IP into one attack

  The trigger groups all hits sent from the same IP address into one attack in the event list. This optimizes the event list and enables faster attack analysis.

  This trigger is released when a single IP address originates more than 50 hits within 15 minutes. Only hits sent after exceeding the threshold are grouped into the attack.

  Hits can have different attack types, malicious payloads and URLs. These attack parameters will be marked with the [multiple] tag in the event list.

  Due to different parameter values of grouped hits, the Mark as false positive button will be unavailable for the whole attack, but you still will be able to mark certain hits as false positives. Active verification of the attack will also be unavailable.

  The hits with the Brute force, Forced browsing, Resource overlimit, Data bomb, or Virtual patch attack types are not considered in this trigger.

• Graylist IP for 1 hour when it originates more than 3 different malicious payloads within 1 hour

  Graylist is a list of suspicious IP addresses processed by the node as follows: if graylisted IP originates malicious requests, the node blocks them while allowing legitimate requests. In contrast to graylist, denylist points to IP addresses that are not allowed to reach your applications at all - the node blocks even legitimate traffic produced by denylisted sources. IP graylisting is one of the options aimed at the reduction of false positives.

  The trigger is released in any node filtration mode, so that it will graylist IPs regardless of the node mode.

  However, the node analyzes the graylist only in the safe blocking mode. To block malicious requests originating from graylisted IPs, switch the node mode to safe blocking learning its features first.

Triggers work on all traffic within a company account by default but you can change any trigger settings.

Disabling and deleting triggers¶

• To temporarily stop sending notifications and reactions to events, you can disable the trigger. A disabled trigger will be displayed in the lists with All and Disabled triggers. To re‑enable sending notifications and reactions to events, the Enable option is used.

• To permanently stop sending notifications and reactions to events, you can delete the trigger. Deleting a trigger cannot be undone. The trigger will be permanently removed from the trigger list.

To disable or delete the trigger, please select an appropriate option from the trigger menu and confirm the action if required.

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send