Analyzing Events¶

You can check events in the Attacks and Incidents sections of Wallarm Console.

Analyze an event¶

You can get information about an event of particular type (attack or incident) by investigating all the table columns described in Checking Attacks and Checking Incidents.

Analyze requests in an event¶

1. Define an attack or incident of your interest.

2. Click the number in the Requests column.

Clicking the number will unfold all requests in the selected event.

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.
  • The Malicious IPs label will appear if the IP address is known for malicious activities. This is based on public records and expert validations.

• Status: The request blocking status (depends on the traffic filtration mode).

• Code: The server's response status code for the request. If the filtering node blocked the request, the code would be 403 or 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.

• Detected by custom rules section is displayed if the attack was detected by a regexp-based customer rule. The section contains the link to the corresponding rule (there can be more than one) - click the link to access the rule details and edit them if necessary.

  

  Learn how to search for such attacks →

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

Analyze requests from denylisted IPs¶

Denylisting proves to be an effective defensive measure against high-volume attacks of different types. This is achieved by blocking requests at the earliest stage of processing. At the same time, it is equally important to gather comprehensive information on all blocked requests for further analysis.

Wallarm offers the ability to collect and display statistics regarding blocked requests from denylisted source IPs. This empowers you to evaluate the potency of attacks originating from denylisted IPs, and conduct precise analysis of the requests from these IPs, exploring various parameters.

In Wallarm, there are several ways for IP to get into the denylist. Depending on the way used, you will need to search for the associated events using different tags/filters:

• You add it manually (in the Attacks section, use blocked_source search or Blocked Source filter)

• It performs a behavioral attack and is automatically denylisted by:

  • API Abuse Prevention module (api_abuse search, API Abuse filter)
  • Brute force trigger (brute, Brute force)
  • Forced browsing trigger (dirbust, Forced browsing)
  • BOLA trigger (bola, BOLA)
  • Number of malicious payloads trigger (multiple_payloads, Multiple payloads)

The listed behavioral attacks can be detected only after accumulating certain statistics the required amount of which depends on the corresponding trigger thresholds. Thus, in the first stage, before denylisting, Wallarm collects this information but all requests are passed and displayed within the Monitoring events.

Once trigger thresholds are exceeded, malicious activity is considered to be detected, and Wallarm places the IP in the denylist, the node starts immediate blocking of all requests originating from them.

As soon as sending of information about requests from denylisted IPs is enabled, you will see Blocked requests from these IPs in the event list. This applies to manually denylisted IPs as well.

Note that search/filters will display both Monitoring and - if sending information is enabled - Blocked events for each attack type. For manually denylisted IPs a Monitoring event never exists.

Within the Blocked events, use tags to switch to the reason of denylisting - BOLA settings, API Abuse Prevention, trigger or causing record in denylist.

Fine-tuning of events¶

Grouping of hits¶

You can optimize the lists of attacks and incidents by grouping hits sent from the same IP address into one attack.

Grouping is enabled by default in Wallarm Console → Triggers with the Hits from the same IP default trigger which activates when a single IP address originates more than 50 hits within 15 minutes.

If grouped hits have different attack types, malicious payloads and URLs, attack parameters will be marked with the [multiple] tag in the attack list.

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

You can temporary disable the default trigger. You can also modify behavior provided by the default trigger - to do so, create your custom triggers of the Hits from the same IP type. Creating any custom trigger deletes the default one, if you delete all your custom triggers, the default is restored.

Sampling of hits¶

Overview¶

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.

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¶

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

• For events from denylisted IPs, sampling is configured on the node side. It uploads only the first 10 identical requests to the Cloud while applying a sampling algorithm to the rest of the hits.

When the sampling algorithm is enabled, in the Attacks 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¶

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 behavioral, Data bomb or Resource overlimiting types. If extreme sampling is disabled for hits of these types, the regular algorithm processes the original hit set.

Extreme sampling

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.

• If hits are of the behavioral, Data bomb or Resource overlimiting types, the algorithm uploads to the Cloud only the first 10% of them detected within an hour.

Regular sampling

The regular sampling algorithm has the following core logic:

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

2. Hit samples are grouped into attacks in the event list.

Grouped hits are displayed in the Attacks or Incidents 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.

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