Skip to content

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 behavioral attacks by the number of requests sent to the certain API endpoints.

  • 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.

Section to configure triggers

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:

Available conditions

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, Forced browsing and BOLA): 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.

Available filters

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:

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

Choosing an integration

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.

  • Detect weak JWTs

    JSON Web Token (JWT) is a popular authentication standard used to exchange data between resources like APIs securely. JWT compromisation is a common aim of attackers as breaking authentication mechanisms provides them full access to web applications and APIs. The weaker JWTs, the higher chance for it to be compromised.

    This trigger enables Wallarm to automatically detect weak JWTs in incoming requests and record corresponding vulnerabilities.

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.