You can check attacks in the Events tab of the Wallarm interface.
Wallarm automatically groups associated malicious requests into one entity — an attack.
Analyze an Attack¶
You can get information about an attack by investigating all the table columns described in “Checking Attacks and Incidents.”
Analyze Requests in an Attack¶
Select an attack.
Click the number in the Requests column.
Clicking the number will unfold all requests in the selected attack.
Each request displays the associated information in the following columns:
Date: Date and time of the request.
Payload: malicious payload. Clicking the value in the payload column displays reference information on the attack type.
Source: The IP address from which the request originated. Clicking the IP address adds the IP address value into the search field. The following information is also displayed if it was found in the IP2Location or similar database:
- The country/region in which the IP address is registered.
- The source type, e.g. Proxy, Tor or the cloud platform the IP registered in, etc.
Code: The server's response status code from the request. If the filtering node blocked the request, the code would be
403or another custom value.
Size: The server's response size.
Time: The server's response time.
If the attack is happening at the current moment, the “now” label is shown under the request graph.
Request view provides the following options for Wallarm behavior fine-tuning:
Mark as false positive and False to report legitimate requests flagged as attacks.
Disable base64 to indicate the base64 parser incorrectly applied to the request element.
The button opens a pre-filled form for setting up the rule disabling the parser.
Rule to create any individual rule to handle certain requests.
The button opens a rule setup form pre-filled with the request data.
Analyze a Request in Raw Format¶
The raw format of a request is the maximum possible level of detail. Raw format view in Wallarm Console also enables copying of a request in a cURL format.
To view a request in a raw format, expand a required attack and then the request within it.
Sampling of hits¶
Malicious traffic often consists of comparable and identical hits. Storing all hits results in duplicate entries in the event list that increases both the time for event analysis and the load on the Wallarm Cloud.
Hit sampling optimizes the data storage and analysis by dropping non-unique hits from being uploaded to the Wallarm Cloud.
Dropped hits in the number of RPS
Since dropped requests are still requests processed by the Wallarm node, the RPS value increases with each dropped request. Accordingly, the RPS limit in the subscription is the number of all requests processed by the node including the dropped ones.
The number of requests and hits on the dashboard also includes the number of dropped hits.
Hit sampling does not affect the quality of attack detection and only helps to avoid its slowdown. Wallarm node continues attack detection and blocking even with hit sampling enabled.
Enabling the sampling algorithm¶
For input validation attacks, hit sampling is disabled by default. If the percentage of attacks in your traffic is high, hit sampling is performed in two sequential stages: extreme and regular.
For behavioral attacks, attacks of the Data bomb and Resource overlimiting: the regular sampling algorithm is enabled by default. Extreme sampling starts only if the percentage of attacks in your traffic is high.
When the sampling algorithm is enabled, in the Events section, the Hits sampling is enabled notification is displayed.
Sampling will be automatically disabled once the percentage of attacks in the traffic decreases.
Core logic of hit sampling¶
Hit sampling is performed in two sequential stages: extreme and regular.
Regular algorithm processes only hits saved after the extreme stage, unless hits are of the brute force, forced browsing, Data bomb or Resource overlimiting types. If extreme sampling is disabled for hits of these types, the regular algorithm processes the original hit set.
The extreme sampling algorithm has the following core logic:
If hits are of the input validation type, the algorithm uploads to the Cloud only those with unique malicious payloads. If several hits with the same payload are detected within an hour, only the first of them is uploaded to the Cloud and the others are dropped.
The regular sampling algorithm has the following core logic:
The first 5 identical hits for each hour are saved in the sample in the Wallarm Cloud. The rest of the hits are not saved in the sample, but their number is recorded in a separate parameter.
The hits are identical if all of the following parameters have the same values:
- Attack type
- Parameter with the malicious payload
- Target address
- Request method
- Response code
- Originating IP address
Hit samples are grouped into attacks in the event list.
Grouped hits are displayed in the Events section of Wallarm Console as follows:
To filter the list of events so that it only displays the sampled hits, click the Hits sampling is enabled notification. The
sampled attribute will be added to the search field, and the list of events will display only the sampled hits.
Displaying dropped hits in the event list
Since dropped hits are not uploaded to the Wallarm Cloud, certain hits or whole attacks can be absent in the list of events.