Skip to content

Trigger examples

Blacklist IP if 4 or more attack vectors were detected in 1 hour (default trigger)

The trigger Block IPs with high count of attack vectors is created for all clients by default. If 4 or more different attack vectors were sent to the protected resource from one IP address, this IP address will be blacklisted for 1 hour.

Default trigger

You can perform all available trigger actions: edit, disable, delete, or copy the trigger.

To test the trigger:

  1. Send the following requests to the protected resource:

    curl http://localhost/instructions.php/etc/passwd
    curl http://localhost/?id='or+1=1--a-<script>prompt(1)</script>'
    

    There are 3 attack vectors in these requests: SQLi, XSS, and Path Traversal.

  2. Open the Wallarm Console → Blacklist and check that IP address from which the requests were originated is blocked for 1 hour.

  3. Open the section Events and check that requests are displayed in the list as the SQLi, XSS, and Path Traversal attacks.

    Three attack vectors in UI

    To search for attacks, you can use the filters, for example: sqli for the SQLi attacks, xss for the XSS attacks, ptrav for the Path Traversal attacks. All filters are described in the instructions on search using.

Mark requests as a brute‑force or dirbust attack if 31 or more requests were sent to the protected resource

With the filter by the counter name

If 31 or more requests were sent to https://example.com/api/frontend/login in 30 seconds, these requests will be marked as brute‑force attack and the IP address from which requests were originated will be added to the blacklist.

The request URL https://example.com/api/frontend/login is specified in the rule Tag requests as a brute-force attack.

Brute force trigger with counter

To mark requests as the dirbust (forced browsing) attack, it is required to use the rule Tag requests as a forced browsing attack.

Details on configuration of brute force protection and trigger testing →

With the filter by URL

If 31 or more requests were sent to example.com:8888/api/frontend/login in 30 seconds:

  • These requests will be marked as brute‑force attack and the IP address from which requests were originated will be added to the blacklist.

  • If the code 404 was returned in the response to all requests, these requests will be marked as dirbust (forced browsing) attack and the IP address from which requests were originated will be added to the blacklist.

URL value format

The format of the URL filter value is host:port/path. The scheme should be omitted. The port value must contain a non‑standard port (to specify 80 or 443 port, please configure the URL via the Counter name filter).

Brute force / dirbust trigger

Details on configuration of brute force protection and trigger testing →

Slack notification if 2 or more SQLi hits were detected in one minute

If 2 or more SQLi hits were sent to the protected resource, then a notification about this event will be sent to the Slack channel.

Example of a trigger sending the notification to Slack

To test the trigger:

  1. Send the following requests to the protected resource:

    curl http://localhost/data/UNION%20SELECT
    curl http://localhost/?id=or+1=1--a-
    
  2. Open the Wallarm Console → Events and check that 3 SQLi attacks are displayed in the list of events. The attack was detected in the second request twice, before and after the parser percent was applied.

    3 SQLi hits in the Wallarm Console

  3. Open the Slack channel and check that the following notification from the user wallarm received:

    [Wallarm] Trigger: The number of detected hits exceeded the threshold
    
    Notification type: attacks_exceeded
    
    The number of detected hits exceeded 1 in 1 minute.
    This notification was triggered by the "Notification about SQLi hits" trigger.
    
    Additional trigger’s clauses:
    Attack type: SQLi.
    
    View events:
    https://my.wallarm.com/search?q=attacks&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX
    
    Client: TestCompany
    Cloud: EU
    
    • Notification about SQLi hits is the trigger name
    • TestCompany is the name of your company account in the Wallarm Console
    • EU is the Wallarm Cloud where your company account is registered

Slack and email notification if new user is added to the account

If a new user with the Administrator or Analyst role is added to the company account in the Wallarm Console, notification about this event will be sent to the email address specified in the integration and to the Slack channel.

Example of a trigger sending the notification to Slack and by email

To test the trigger:

  1. Open the Wallarm Console → SettingsUsers and add a new user. For example:

    Added user

  2. Open your email Inbox and check that the following message received:

    Email about new user added

  3. Open the Slack channel and check that the following notification from the user wallarm received:

    [Wallarm] Trigger: New user was added to the company account
    
    Notification type: create_user
    
    A new user John Smith <johnsmith@example.com> with the role Analyst was added to the company account by John Doe <johndoe@example.com>.
    This notification was triggered by the "Added user" trigger.
    
    Client: TestCompany
    Cloud: EU
    
    • John Smith and johnsmith@example.com is information about the added user
    • Analyst is the role of the added user
    • John Doe and johndoe@example.com is information about the user who added a new user
    • Added user is the trigger name
    • TestCompany is the name of your company account in the Wallarm Console
    • EU is the Wallarm Cloud where your company account is registered

Opsgenie notification if 2 or more incidents were detected in one second

If 2 or more incidents with the application server or database were detected in one second, the notification about this event will be sent to Opsgenie.

Example of a trigger sending the data to Splunk

To test the trigger, it is required to send the attack exploiting an active vulnerability to the protected resource. The Wallarm Console → Vulnerabilities section displays active vulnerabilities detected in your applications and the examples of attacks that exploit these vulnerabilities.

If the attack example is sent to the protected resource, Wallarm will record the incident. Two or more recorded incidents will trigger sending the following notification to Opsgenie:

[Wallarm] Trigger: The number of incidents exceeded the threshold

Notification type: incidents_exceeded

The number of detected incidents exceeded 1 in 1 second.
This notification was triggered by the "Notification about incidents" trigger.

Additional trigger’s clauses:
Target: server, database.

View events:
https://my.wallarm.com/search?q=incidents&time_from=XXXXXXXXXX&time_to=XXXXXXXXXX

Client: TestCompany
Cloud: EU
  • Notification about incidents is the trigger name

  • TestCompany is the name of your company account in the Wallarm Console

  • EU is the Wallarm Cloud where your company account is registered

Protecting the resource from active vulnerability exploitation

To protect the resource from active vulnerability exploitation, we recommend to patch the vulnerability in a timely manner. If the vulnerability cannot be patched on the application side, please configure a virtual patch to block attacks exploiting this vulnerability.

Notification to Webhook URL if IP address was added to the blacklist

If an IP address was added to the blacklist, the webhook about this event will be sent to Webhook URL.

Example of trigger for blacklisted IP

To test the trigger:

  1. Open the Wallarm Console → Blacklist and add the IP address to the blacklist. For example:

    Adding IP to the blacklist

  2. Check that the following webhook was sent to the Webhook URL:

    [
        {
            "summary": "[Wallarm] Trigger: New IP address was blacklisted",
            "description": "Notification type: ip_blocked\n\nIP address 1.1.1.1 was blacklisted until 2021-06-10 02:27:15 +0300. You can review blocked IP addresses in the \"Blacklist\" section of Wallarm Console.\nThis notification was triggered by the \"Notification about blacklisted IP\" trigger.\n\nClient: TestCompany\nCloud: EU\n",
            "details": {
            "client_name": "TestCompany",
            "cloud": "EU",
            "notification_type": "ip_blocked",
            "trigger_name": "Notification about blacklisted IP",
            "expire_at": "2021-06-10 02:27:15 +0300",
            "ip": "1.1.1.1"
            }
        }
    ]
    
    • Notification about blacklisted IP is the trigger name
    • TestCompany is the name of your company account in the Wallarm Console
    • EU is the Wallarm Cloud where your company account is registered