Skip to content

Detecting attacks

The Wallarm platform continuously analyzes application traffic and mitigates malicious requests in real-time. From this article, you will learn resource types Wallarm protects from attacks, methods of detecting attacks in traffic and how you can track and manage detected threats.

What is attack and what are attack components?

Attack is a single hit or multiple hits grouped by the following characteristics:

  • The same attack type, the parameter with the malicious payload, and the address the hits were sent to. Hits may come from the same or different IP addresses and have different values of the malicious payloads within one attack type.

    This hit grouping method is basic and applied to all hits.

  • The same source IP address if the appropriate trigger is enabled. Other hit parameter values can differ.

    This hit grouping method works for all hits except for the ones of the Brute force, Forced browsing, Resource overlimit, Data bomb and Virtual patch attack types.

    If hits are grouped by this method, the Mark as false positive button and the active verification option are unavailable for the attack.

The listed hit grouping methods do not exclude each other. If hits have characteristics of both methods, they are all grouped into one attack.

Hit is a serialized malicious request (original malicious request and metadata added by the Wallarm node). If Wallarm detects several malicious payloads of different types in one request, Wallarm records several hits with payloads of one type in each.

Malicious payload is a part of an original request containing the following elements:

  • Attack signs detected in a request. If several attack signs characterizing the same attack type are detected in a request, only the first sign will be recorded to a payload.

  • Context of the attack sign. Context is a set of symbols preceding and closing detected attack signs. Since a payload length is limited, the context can be omitted if an attack sign is of full payload length.

    Since attack signs are not used to detect behavioral attacks, requests sent as a part of behavioral attacks have empty payloads.

Attack types

All attacks that can be detected by Wallarm are divided into groups:

  • Input validation attacks

  • Behavioral attacks

Attack detection method depends on the attack group. To detect behavioral attacks, additional Wallarm node configuration is required.

Input validation attacks

Input validation attacks include SQL injection, cross‑site scripting, remote code execution, Path Traversal and other attack types. Each attack type is characterized by specific symbol combinations sent in the requests. To detect input validation attacks, it is required to conduct syntax analysis of the requests - parse requests in order to detect specific symbol combinations.

Input validation attacks are detected by the filtering node using the listed tools.

Detection of input validation attacks is enabled for all clients by default.

Behavioral attacks

Behavioral attacks include classes of brute‑force attacks: passwords and session identifiers brute‑forcing, files and directories forced browsing, credential stuffing. Behavioral attacks can be characterized by a large number of requests with different forced parameter values sent to a typical URL for a limited timeframe.

For example, if an attacker forces password, many similar requests with different password values can be sent to the user authentication URL:

https://example.com/login/?username=admin&password=123456

To detect behavioral attacks, it is required to conduct syntax analysis of requests and correlation analysis of request number and time between requests. Correlation analysis is conducted when the threshold of request number sent to user authentication or resource file directory URL is exceeded. Request number threshold should be set to reduce the risk of legitimate request blocking (for example, when the user inputs incorrect password to his account several times).

  • Correlation analysis is conducted by the Wallarm postanalytics module.

  • Comparison of the received request number and the threshold for the request number, and blocking of requests is conducted in the Wallarm Cloud.

When behavioral attack is detected, request sources are blocked, namely the IP addresses the requests were sent from are added to the denylist.

To protect the resource against behavioral attacks, it is required to set the threshold for correlation analysis and URLs that are vulnerable to behavioral attacks.

Instructions on configuration of brute force protection →

Brute force protection restrictions

When searching for brute‑force attack signs, Wallarm nodes analyze only HTTP requests that do not contain signs of other attack types. For example, the requests are not considered to be a part of brute-force attack in the following cases:

Types of protected resources

Wallarm nodes analyze HTTP and WebSocket traffic sent to the protected resources:

Protected resource API can be designed on the basis of the following technologies:

  • GraphQL

  • gRPC

  • WebSocket

  • REST API

  • SOAP

  • XML-RPC

  • WebDAV

  • JSON-RPC

Attack detection process

To detect attacks, Wallarm uses the following process:

  1. Determine the request format and parse every request part as described in the document about request parsing.

  2. Determine the endpoint the request is addressed to.

  3. Apply custom rules for request analysis configured in Wallarm Console.

  4. Make a decision whether the request is malicious or not based on default and custom detection rules.

Tools for attack detection

To detect malicious requests, Wallarm nodes analyze all requests sent to the protected resource using the following tools:

  • Library libproton

  • Library libdetection

  • Custom rules for request analysis

Library libproton

The libproton library is a primary tool for detecting malicious requests. The library uses the component proton.db which determines different attack type signs as token sequences, for example: union select for the SQL injection attack type. If the request contains a token sequence matching the sequence from proton.db, this request is considered to be an attack of the corresponding type.

Wallarm regularly updates proton.db with token sequences for new attack types and for already described attack types.

Library libdetection

libdetection overview

The libdetection library additionally validates attacks detected by the library libproton as follows:

  • If libdetection confirms the attack signs detected by libproton, the attack is blocked (if the filtering node is working in the block mode) and uploaded to the Wallarm Cloud.

  • If libdetection does not confirm the attack signs detected by libproton, the request is considered legitimate, the attack is not uploaded to the Wallarm Cloud and is not blocked (if the filtering node is working in the block mode).

Using libdetection ensures the double‑detection of attacks and reduces the number of false positives.

Attack types validated by the libdetection library

Currently, the library libdetection only validates SQL Injection attacks.

How libdetection works

The particular characteristic of libdetection is that it analyzes requests not only for token sequences specific for attack types, but also for context in which the token sequence was sent.

The library contains the character strings of different attack type syntaxes (SQL Injection for now). The string is named as the context. Example of the context for the SQL injection attack type:

SELECT example FROM table WHERE id=

The library conducts the attack syntax analysis for matching the contexts. If the attack does not match the contexts, then the request will not be defined as a malicious one and will not be blocked (if the filtering node is working in the block mode).

Enabling libdetection

Analyzing requests with the libdetection library is disabled by default. To reduce the number of false positives, we recommend enabling analysis.

To enable the analysis:

  1. Set the value of the directive wallarm_enable_libdetection to on. The directive can be set inside the http, server, or location block of the NGINX configuration file.

  2. Set the value of the directive proxy_request_buffering to on to allow analyzing the request body. The directive can be set inside the http, server, or location block of the NGINX configuration file.

Memory consumption increase

When analyzing attacks using the libdetection library, the amount of memory consumed by NGINX and Wallarm processes may increase by about 10%.

Testing libdetection

To check the operation of libdetection, you can send the following legitimate request to the protected resource:

curl "http://localhost/?id=1' UNION SELECT"

  • The library libproton will detect UNION SELECT as the SQL Injection attack sign. Since UNION SELECT without other commands is not a sign of the SQL Injection attack, libproton detects a false positive.

  • If analyzing of requests with the libdetection library is enabled, the SQL Injection attack sign will not be confirmed in the request. The request will be considered legitimate, the attack will not be uploaded to the Wallarm Cloud and will not be blocked (if the filtering node is working in the block mode).

Custom rules for request analysis

To adjust default Wallarm request analysis to protected application specificities, Wallarm clients can use custom rules of the following types:

Compiled custom ruleset is applied along with the standard rules from proton.db when analyzing requests.

Monitoring and blocking attacks

Wallarm can process attacks in the following modes:

  • Monitoring mode: detects attacks and displays information about them in Wallarm Console.

  • Blocking mode: detects and blocks attacks and displays information about them in Wallarm Console.

Wallarm ensures quality request analysis and low level of false positives. However each protected application has its own specificities, so we recommend analyzing the work of the Wallarm in the monitoring mode before enabling the blocking mode.

To control the filtration mode, the directive wallarm_mode is used. More detailed information about filtration mode configuration is available within the link.

The filtration mode for behavioral attacks is configured separately via the particular trigger.

False positives

False positive occurs when attack signs are detected in the legitimate request or when legitimate entity is qualified as a vulnerability. More details on false positives in vulnerability scanning →

When analyzing requests for attacks, Wallarm uses the standard ruleset that provides optimal application protection with ultra‑low false positives. Due to protected application specificities, standard rules may mistakenly recognize attack signs in legitimate requests. For example: SQL injection attack may be detected in the request adding a post with malicious SQL query description to the Database Administrator Forum.

In such cases, standard rules need to be adjusted to accommodate protected application specificities by using the following methods:

Identifying and handling false positives is a part of Wallarm fine‑tuning to protect your applications. We recommend to deploy the first Wallarm node in the monitoring mode and analyze detected attacks. If some attacks are mistakenly recognized as attacks, mark them as false positives and switch the filtering node to blocking mode.

Managing detected attacks

All detected attacks are displayed in the Wallarm Console → Events section by the filter attacks. You can manage attacks through the interface as follows:

  • View and analyze attacks

  • Increase the priority of an attack in the recheck queue

  • Mark attacks or separate hits as false positives

  • Create the rules for custom processing of separate hits

For more information on managing attacks, see the instructions on working with attacks.

Attacks view

Notifications about detected attacks, hits and malicious payloads

Wallarm can send you notifications on detected attacks, hits and malicious payloads. It allows you to be aware of attempts to attack your system and analyze detected malicious traffic promptly. Analyzing malicious traffic includes reporting false positives, allowlisting IPs originating legitimate requests and denylisting IPs of attack sources.

To configure notifications:

  1. Configure native integrations with the systems to send notifications (e.g. PagerDuty, Opsgenie, Splunk, Slack, Telegram).

  2. Set the conditions for sending notifications:

    • To get notifications on each detected hit, select the appropriate option in the integration settings.

      See the example of the notification about detected hit in the JSON format
      [
    {
        "summary": "[Wallarm] New hit detected",
        "details": {
        "client_name": "TestCompany",
        "cloud": "EU",
        "notification_type": "new_hits",
        "hit": {
            "domain": "www.example.com",
            "heur_distance": 0.01111,
            "method": "POST",
            "parameter": "SOME_value",
            "path": "/news/some_path",
            "payloads": [
                "say ni"
            ],
            "point": [
                "post"
            ],
            "probability": 0.01,
            "remote_country": "PL",
            "remote_port": 0,
            "remote_addr4": "8.8.8.8",
            "remote_addr6": "",
            "tor": "none",
            "request_time": 1603834606,
            "create_time": 1603834608,
            "response_len": 14,
            "response_status": 200,
            "response_time": 5,
            "stamps": [
                1111
            ],
            "regex": [],
            "stamps_hash": -22222,
            "regex_hash": -33333,
            "type": "sqli",
            "block_status": "monitored",
            "id": [
                "hits_production_999_202010_v_1",
                "c2dd33831a13be0d_AC9"
            ],
            "object_type": "hit",
            "anomaly": 0
            }
        }
    }
]

    • To set the threshold of attack, hit or malicious payload number and get notifications when the threshold is exceeded, configure appropriate triggers.

      See the example of configured trigger and notification →

Demo videos