diff --git a/.doc-agent/glossary.md b/.doc-agent/glossary.md index 2ca0f710f3..9e8a7eb280 100644 --- a/.doc-agent/glossary.md +++ b/.doc-agent/glossary.md @@ -39,7 +39,8 @@ | hit | Serialized malicious request (original request + metadata from Node) | | | | malicious request | Request with attack signs detected by Node | | invalid request | | legitimate request | Request without attack signs | | | -| malicious payload | Part of request containing attack stamps (identifier + context) | payload | attack vector | +| malicious payload | Part of request containing attack stamps (identifier + context) | payload | | +| attack vector | Record of attack evidence for one grouped set of malicious requests, as returned by the Attacks API and shown as a row in the **Attacks** section | | malicious payload | | false positive | Mistaken detection of attack or vulnerability | | false attack, false vulnerability | | security issue | Error in application that can be exploited by attacker. Detected via: Passive detection, Threat Replay Testing, Schema-Based Testing, API Attack Surface Management | vulnerability, issue | | | vulnerability | See **security issue** | security issue, issue | | diff --git a/docs/5.0/updating-migrating/older-versions/what-is-new.md b/docs/5.0/updating-migrating/older-versions/what-is-new.md index 674a4eaff9..a923d0bf5b 100644 --- a/docs/5.0/updating-migrating/older-versions/what-is-new.md +++ b/docs/5.0/updating-migrating/older-versions/what-is-new.md @@ -269,7 +269,7 @@ The Wallarm NGINX‑based filtering nodes now collect statistics on requests tha When using automatic IP blocking (e.g., with the brute force trigger configured), now you can analyze both the initial triggering requests and the samples of subsequent blocked requests. For requests blocked due to manual denylisting of their sources, the new functionality enhances visibility into blocked source actions. -We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) within the **Attacks** section to effortlessly access the newly introduced data: +We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#filters) within the **Attacks** section to effortlessly access the newly introduced data: * Utilize the `blocked_source` search to identify requests that were blocked due to manual denylisting of IP addresses, subnets, countries, VPNs, and more. * Employ the `multiple_payloads` search to pinpoint requests blocked by the **Number of malicious payloads** trigger. This trigger is designed to denylist sources that originate malicious requests containing multiple payloads, a common characteristic of multi-attack perpetrators. diff --git a/docs/6.x/updating-migrating/older-versions/what-is-new.md b/docs/6.x/updating-migrating/older-versions/what-is-new.md index 68d16d5374..37e2dd8936 100644 --- a/docs/6.x/updating-migrating/older-versions/what-is-new.md +++ b/docs/6.x/updating-migrating/older-versions/what-is-new.md @@ -423,7 +423,7 @@ The Wallarm NGINX‑based filtering nodes now collect statistics on requests tha When using automatic IP blocking (e.g., with the brute force trigger configured), now you can analyze both the initial triggering requests and the samples of subsequent blocked requests. For requests blocked due to manual denylisting of their sources, the new functionality enhances visibility into blocked source actions. -We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) within the **Attacks** section to effortlessly access the newly introduced data: +We have introduced new [search tags and filters](../../user-guides/search-and-filters/use-search.md#filters) within the **Attacks** section to effortlessly access the newly introduced data: * Utilize the `blocked_source` search to identify requests that were blocked due to manual denylisting of IP addresses, subnets, countries, VPNs, and more. * Employ the `multiple_payloads` search to pinpoint requests blocked by the **Number of malicious payloads** trigger. This trigger is designed to denylist sources that originate malicious requests containing multiple payloads, a common characteristic of multi-attack perpetrators. diff --git a/docs/6.x/user-guides/search-and-filters/attack-filters.md b/docs/6.x/user-guides/search-and-filters/attack-filters.md new file mode 100644 index 0000000000..7a8c32ade5 --- /dev/null +++ b/docs/6.x/user-guides/search-and-filters/attack-filters.md @@ -0,0 +1 @@ +--8<-- "latest/user-guides/search-and-filters/attack-filters.md" \ No newline at end of file diff --git a/docs/7.x/user-guides/search-and-filters/attack-filters.md b/docs/7.x/user-guides/search-and-filters/attack-filters.md new file mode 100644 index 0000000000..7a8c32ade5 --- /dev/null +++ b/docs/7.x/user-guides/search-and-filters/attack-filters.md @@ -0,0 +1 @@ +--8<-- "latest/user-guides/search-and-filters/attack-filters.md" \ No newline at end of file diff --git a/docs/latest/about-wallarm/credential-stuffing.md b/docs/latest/about-wallarm/credential-stuffing.md index 214b36ca6f..f6efb17cde 100644 --- a/docs/latest/about-wallarm/credential-stuffing.md +++ b/docs/latest/about-wallarm/credential-stuffing.md @@ -86,7 +86,7 @@ On adding the new rule, it is turned on automatically. Use **on/off** switcher t ## Viewing compromised credentials usage attempts -The number of attempts to use compromised credentials in the last 7 days is displayed in the **Credential Stuffing** section. Click the counter and you will be redirected to the **Attacks** section that will display all [`credential_stuffing`](../user-guides/search-and-filters/use-search.md#search-by-attack-type) attacks for the last 7 days. +The number of attempts to use compromised credentials in the last 7 days is displayed in the **Credential Stuffing** section. Click the counter and you will be redirected to the **Attacks** section that will display all [credential stuffing](../user-guides/search-and-filters/attack-filters.md#filter) attacks for the last 7 days. Expand any of the attacks to see the list of logins which passwords were compromised. diff --git a/docs/latest/about-wallarm/protecting-against-attacks.md b/docs/latest/about-wallarm/protecting-against-attacks.md index e5225ff886..f60c096444 100644 --- a/docs/latest/about-wallarm/protecting-against-attacks.md +++ b/docs/latest/about-wallarm/protecting-against-attacks.md @@ -1,4 +1,4 @@ -[rule-creation-options]: ../user-guides/events/check-attack.md#attack-analysis_1 +[rule-creation-options]: ../user-guides/events/check-attack.md#responding-to-attacks [request-processing]: ../user-guides/rules/request-processing.md [api-discovery-enable-link]: ../api-discovery/setup.md [ip-lists-link]: ../user-guides/ip-lists/overview.md @@ -35,7 +35,7 @@ The Wallarm platform continuously analyzes API traffic and mitigates malicious r This hit grouping method works for all hits except for the ones of the Brute force, Forced browsing, BOLA (IDOR), Resource overlimit, Data bomb and Virtual patch attack types. - If hits are grouped by this method, the [**Mark as false positive**](../user-guides/events/check-attack.md#false-positives) button is unavailable for the attack. + If hits are grouped by this method, [marking the whole attack as a false positive](../user-guides/events/check-attack.md#false-positives) is unavailable. The listed hit grouping methods do not exclude each other. If hits have characteristics of both methods, they are all grouped into one attack. @@ -214,7 +214,7 @@ When analyzing requests for attacks, Wallarm uses the standard ruleset that prov In such cases, standard rules need to be adjusted to accommodate protected API specificities by using the following methods: -* Analyze potential false positives (by filtering all attacks by the [tag `!known`](../user-guides/search-and-filters/use-search.md#search-by-known-attacks-cve-and-wellknown-exploits)) and if confirming false positives, [mark](../user-guides/events/check-attack.md#false-positives) particular attacks or hits appropriately. Wallarm will automatically create the rules disabling analysis of the same requests for detected attack signs. +* Analyze potential false positives and, if confirming them, [mark](../user-guides/events/check-attack.md#false-positives) particular attacks or requests appropriately. Wallarm will automatically create the rules disabling analysis of the same requests for detected attack signs. * [Disable detection of certain attack types](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types) in particular requests. * [Disable detection of certain attack signs in binary data](../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-signs-in-the-binary-data). * [Disable parsers mistakenly applied to the requests](../user-guides/rules/request-processing.md#managing-parsers). @@ -248,7 +248,7 @@ Wallarm provides you with the comprehensive user interface displaying all detect See details in the [Attack Analysis](../user-guides/events/check-attack.md) article. -![Attacks view](../images/user-guides/events/check-attack.png) +![Attacks view](../images/user-guides/events/attacks-page.png) diff --git a/docs/latest/api-sessions/attacks-api.md b/docs/latest/api-sessions/attacks-api.md index 92e0c90d4b..4bc52a9f13 100644 --- a/docs/latest/api-sessions/attacks-api.md +++ b/docs/latest/api-sessions/attacks-api.md @@ -574,5 +574,7 @@ Display columns (aggregated value lists, not sortable metrics): `attack_types`, ## Related -* [Exploring API Sessions][link-exploring-attacks] — the Console UI backed by this API. -* [Wallarm API overview][api-overview] — authentication, tokens, and the API Console. +* [Attack Analysis](../user-guides/events/check-attack.md): the Console UI backed by this API. +* [Attack Search and Filters](../user-guides/search-and-filters/attack-filters.md): filtering, grouping, and saved views in the UI. +* [Exploring API Sessions][link-exploring-attacks]: the session view of the same traffic. +* [Wallarm API overview][api-overview]: authentication, tokens, and the API Console. diff --git a/docs/latest/api-specification-enforcement/viewing-events.md b/docs/latest/api-specification-enforcement/viewing-events.md index 55e6324d14..d980aafc41 100644 --- a/docs/latest/api-specification-enforcement/viewing-events.md +++ b/docs/latest/api-specification-enforcement/viewing-events.md @@ -10,7 +10,7 @@ You can click this number to see details in the **Attacks** section. ## Analysis of requests that violate policies -In the **Attacks** section, to find events related to specification-based policy violations, use the [appropriate search keys](../user-guides/search-and-filters/use-search.md#spec-violation-tags) or corresponding filters. +In the **Attacks** section, to find events related to specification-based policy violations, set the [**Attack Type** filter](../user-guides/search-and-filters/attack-filters.md#filter) to the corresponding violation. Blocked and monitored events may be presented depending on the configured policy violation actions. In the event details, the violation type and link to the causing specification are displayed. @@ -20,4 +20,4 @@ Blocked and monitored events may be presented depending on the configured policy When viewing events related to your specification policies, you may encounter the **Specification processing overlimit** type of event related to the limits applied for API Specification Enforcement while it processes the requests. See details and the description of your possible actions [here](overview.md#how-it-works). -In the **Attacks** section, the overlimit events can be found using the `processing_overlimit` search key or **Processing overlimit** filter. +In the **Attacks** section, the overlimit events can be found with the [**Attack Type** filter](../user-guides/search-and-filters/attack-filters.md#filter) set to **Processing overlimit**. diff --git a/docs/latest/api/request-examples.md b/docs/latest/api/request-examples.md index 1551dc5c02..aa7d4d72f0 100644 --- a/docs/latest/api/request-examples.md +++ b/docs/latest/api/request-examples.md @@ -43,145 +43,19 @@ This returns your user information including the client_id field. For instance, Once you have the client ID (in this example, 5), you can use it to fetch discovered APIs with endpoints like `/v4/clients/{client_id}/rules/endpoints`. The client ID is essential because Wallarm's API is multi-tenant, and this identifier tells the system which account's data you want to access. -## Get the first 50 attacks detected in the last 24 hours +## Get attacks -Please replace `TIMESTAMP` with the date 24 hours ago converted to the [Unix Timestamp](https://www.unixtimestamp.com/) format. - ---8<-- "../include/api-request-examples/get-attacks-en.md" - -## Get a large number of attacks (100 and more) - -For attack and hit sets containing 100 or more records, it is best to retrieve them in smaller pieces rather than fetching large datasets all at once, in order to optimize performance. The corresponding Wallarm API endpoints support cursor-based pagination with 100 records per page. - -This technique involves returning a pointer to a specific item in the dataset and then on subsequent requests, the server returns results after the given pointer. To enable cursor pagination, include `"paging": true` in the request parameters. - -The following are examples of API calls for retrieving all attacks detected since `` using the cursor pagination: - -=== "EU Cloud" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Cloud" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -This request returns information on the latest 100 attacks detected, arranged from the most recent to the earliest. In addition, the response includes a `cursor` parameter that contains a pointer to the next set of 100 attacks. +Besides the **Attacks** section of Wallarm Console, you can read attacks programmatically through the [Attacks API](../api-sessions/attacks-api.md) — an aggregation-first API that runs grouped queries over your attack data, drills into any group down to the raw requests, and also builds dashboard widgets, marks analyst verdicts, exports results, and manages saved views. -To retrieve the next 100 attacks, use the same request as before but include the `cursor` parameter with the pointer value copied from the response of the previous request. This allows the API to know where to start returning the next set of 100 attacks from, e.g.: +For example, to return individual (ungrouped) attacks from the last 24 hours: -=== "EU Cloud" - ```bash - curl -k 'https://api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` -=== "US Cloud" - ```bash - curl -k 'https://us1.api.wallarm.com/v2/objects/attack' \ - -X POST \ - -H 'X-WallarmApi-Token: ' \ - -H 'Content-Type: application/json' \ - -d '{"cursor":"", "paging": true, "filter": {"clientid": [], "vulnid": null, "time": [[, null]], "!state": "falsepositive"}}' - ``` - -To retrieve further pages of results, execute requests including the `cursor` parameter with the value copied from the previous response. - -Below is the Python code example for retrieving attacks using cursor paging: - -=== "EU Cloud" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX time - - url = "https://api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` -=== "US Cloud" - ```python - import json - from pprint import pprint as pp - - import requests - - - client_id = - ts = # UNIX time - - url = "https://us1.api.wallarm.com/v2/objects/attack" - headers = { - "X-WallarmApi-Token": "", - "X-WallarmAPI-Secret": "", - "Content-Type": "application/json", - } - payload = { - "paging": True, - "filter": { - "clientid": [client_id], - "vulnid": None, - "time": [[ts, None]], - "!state": "falsepositive", - }, - } - - - while True: - response = requests.post(url, headers=headers, json=payload) - data = response.json() - - cursor = data.get("cursor") - if not cursor: - break - - pp(data) - payload["cursor"] = cursor - ``` +--8<-- "../include/api-request-examples/get-attacks-en.md" -## Get the first 50 incidents confirmed in the last 24 hours +For the full endpoint reference, authentication, filtering, pagination, and migration from the legacy `/v1/objects/attack` and `/v1/objects/hit` endpoints, see the [Attacks API guide](../api-sessions/attacks-api.md). -The request is very similar to the previous example for a list of attacks; the `"!vulnid": null` term is added to this request. This term instructs the API to ignore all attacks without specified vulnerability ID, and this is how the system distinguishes between attacks and incidents. +## Get the first 50 incidents detected in the last 24 hours -Please replace `TIMESTAMP` with the date 24 hours ago converted to the [Unix Timestamp](https://www.unixtimestamp.com/) format. +Incidents are attacks that exploited a [security issue](../user-guides/vulnerabilities.md). Retrieve them from the `/v1/objects/attack` endpoint with the `"!vulnid": null` term, which keeps only attacks that have a vulnerability ID. Replace `TIMESTAMP` with the date 24 hours ago in [Unix time](https://www.unixtimestamp.com/) format. --8<-- "../include/api-request-examples/get-incidents-en.md" diff --git a/docs/latest/glossary-en.md b/docs/latest/glossary-en.md index 491749ed87..70e2f8c408 100644 --- a/docs/latest/glossary-en.md +++ b/docs/latest/glossary-en.md @@ -6,21 +6,21 @@ The glossary covers the core Wallarm entities to provide you with a better under A hit is a serialized malicious request (original malicious request and metadata added by the filtering node), e.g.: -![Hit example](images/user-guides/events/analyze-attack-raw.png) +![Hit example](images/user-guides/events/attack-request-details.png) -[Details on hit parameters](user-guides/events/check-attack.md#attack-analysis_1) +[Details on hit parameters](user-guides/events/check-attack.md#requests) ## Attack An attack is a single hit or multiple hits [grouped](user-guides/events/grouping-sampling.md#grouping-of-hits). -An example of an attack including a single hit: +An example of the attack list: -![Attack with one hit](images/glossary/attack-with-one-hit-example.png) +![Attack list](images/glossary/attack-list-example.png) An example of an attack including many hits: -![Attack with several hits](images/glossary/attack-with-several-hits-example.png) +![Attack with several hits](images/user-guides/events/attack-drawer-requests.png) See [details](user-guides/events/check-attack.md) on how to understand and analyze attacks. diff --git a/docs/latest/platform-management/overview.md b/docs/latest/platform-management/overview.md index 83308114b8..a46b8acf4c 100644 --- a/docs/latest/platform-management/overview.md +++ b/docs/latest/platform-management/overview.md @@ -20,6 +20,6 @@ * **[Triggers & Alerts](../user-guides/triggers/triggers.md)** — automated triggers and alert notifications. -* **[Search & Reports](../user-guides/search-and-filters/use-search.md)** — search events and generate custom reports. +* **[Search & Reports](../user-guides/search-and-filters/attack-filters.md)** — search events and generate custom reports. * **[Account Settings](../user-guides/settings/account.md)** — your account, applications, subscriptions, and audit logs. diff --git a/docs/latest/troubleshooting/detection-and-blocking.md b/docs/latest/troubleshooting/detection-and-blocking.md index 9616a718bd..2f28b4bb6d 100644 --- a/docs/latest/troubleshooting/detection-and-blocking.md +++ b/docs/latest/troubleshooting/detection-and-blocking.md @@ -117,7 +117,7 @@ To resolve the issue of a legitimate request being blocked by Wallarm, follow th * Copy of user's client request and response. Browser page source code or terminal client textual input and output suits well. -1. In Wallarm Console → [**Attacks**](../user-guides/events/check-attack.md) or [**Incidents**](../user-guides/events/check-incident.md) section, [search](../user-guides/search-and-filters/use-search.md) for the event related to the blocked request. For example, [search by request ID](../user-guides/search-and-filters/use-search.md#search-by-request-identifier): +1. In Wallarm Console → [**Attacks**](../user-guides/events/check-attack.md) section, [filter](../user-guides/search-and-filters/attack-filters.md) the list down to the event related to the blocked request. For example, filter by **Request ID**: ``` attacks incidents request_id: diff --git a/docs/latest/troubleshooting/detection-tools-tuning.md b/docs/latest/troubleshooting/detection-tools-tuning.md index 234856153b..cf9e60306f 100644 --- a/docs/latest/troubleshooting/detection-tools-tuning.md +++ b/docs/latest/troubleshooting/detection-tools-tuning.md @@ -26,7 +26,7 @@ Wallarm is a set of protection tools. If they do not work as expected, you can a ## Detailed approach -1. Requests are in [API Sessions](../api-sessions/exploring.md) (all: legitimate and ones that are part of malicious activity, presented as logical sequence) or [Attacks](../user-guides/events/check-attack.md#attack-analysis_1) (only malicious). +1. Requests are in [API Sessions](../api-sessions/exploring.md) (all: legitimate and ones that are part of malicious activity, presented as logical sequence) or [Attacks](../user-guides/events/check-attack.md#attacks-page) (only malicious). 1. Get [Allowlist](../user-guides/ip-lists/overview.md) clear - no requests from it will appear in **Attacks** even if malicious. **API Sessions** is the chance to catch malicious from Allowlist. 1. Blocked by [Denylist](../user-guides/ip-lists/overview.md)? In Attacks, use **Type** → "Blocked sources"; in Sessions, expand the session, check for presence of "Blocked sources" attack, filter by it. Switch to **IP & Session Lists** → **IP lists** → **Denylist** and find the blocked source, check **Reason**, if it was some automated tool, go to it and modify. diff --git a/docs/latest/user-guides/events/check-attack.md b/docs/latest/user-guides/events/check-attack.md index 7d4cd2812f..7af21efd40 100644 --- a/docs/latest/user-guides/events/check-attack.md +++ b/docs/latest/user-guides/events/check-attack.md @@ -1,133 +1,150 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[img-verify-attack]: ../../images/user-guides/events/verify-attack.png -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[link-analyzing-attacks]: analyze-attack.md -[img-false-attack]: ../../images/user-guides/events/false-attack.png -[img-removed-attack-info]: ../../images/user-guides/events/removed-attack-info.png -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload -[link-attacks]: ../../user-guides/events/check-attack.md -[link-incidents]: ../../user-guides/events/check-incident.md [link-sessions]: ../../api-sessions/overview.md # Attack Analysis -This article describes how you can analyze attacks detected by the Wallarm node and take actions regarding them. +This article explains how to analyze attacks detected by Wallarm and respond to them. -!!! info "Attacks or API Sessions" - Note that while usually attacks are displayed both in **Attacks** and **API Sessions**, so far [some of the attacks](#attacks-displayed-exclusively-in-api-sessions) can be found only in **API Sessions**. +Wallarm displays detected [attacks](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) in the **Attacks** section of Wallarm Console. There, Wallarm groups malicious requests into attacks and summarizes them with statistics, and you can open any attack to inspect its individual requests and respond to them. -### Attack analysis +In Wallarm: -The [attacks](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) detected by the Wallarm platform are displayed in the **Attacks** or **API Sessions** section of the Wallarm Console. You can [filter](../../user-guides/search-and-filters/use-search.md) the list by attack date, type and other criteria, expand any attack and its included requests for detailed analysis. +* **Attack** is a group of malicious requests that share the grouping attributes you selected +* **Request** is an original malicious request plus metadata added by the node +* **Malicious payload** is a part of the request with an attack sign -If a detected attack turns out to be a [false positive](#false-positives), you can immediately mark it as one to prevent similar false positives in the future. Also, on the basis of the detected attacks, you can create rules and perform other Wallarm configurations to mitigate further similar threats. +Read details [here](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components). -
- -
- -
-
+## Attacks page -In Wallarm: +![Attacks section](../../images/user-guides/events/attacks-page.png) -* **Attack** is a [group](grouping-sampling.md#grouping-of-hits) of hits -* **Hit** is a malicious request plus metadata added by node -* **Malicious payload** is a part of request with attack sign +The page presents attacks for the selected period and lets you shape what you see: -Read details [here](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components). +* **Views** are tabs above the filter. Each view stores a filter, a grouping, a time range, and a column layout, so you can switch between saved perspectives on your attack data in one click. See [Attack Search and Filters](../search-and-filters/attack-filters.md#views). +* The time range selector limits the data to a period of up to 6 months. +* **Group by** controls how requests are combined into attacks: by attack type (the default), by source IP, not at all, or by a custom combination of up to 4 attributes. See [Attack Search and Filters](../search-and-filters/attack-filters.md#grouping). +* The filter field narrows the list down to the attacks you are interested in. See [Attack Search and Filters](../search-and-filters/attack-filters.md). +* **Statistic** is a collapsible panel with charts summarizing the filtered data: requests with attacks over time, top source IPs, status code breakdown, top attacked endpoints and hosts, top attack types and subtypes. Clicking an element of a chart drills into the corresponding attacks. -Each attack's details contain all necessary information for analysis, such as the attack's hits and malicious payload summary. To simplify analysis, only unique hits are stored in the attack details. Repeated malicious requests are dropped from uploading to the Wallarm Cloud and not displayed. This process is called [hit sampling](grouping-sampling.md#sampling-of-hits). +The table below the panel lists the attacks themselves. Use **Table settings** to choose, reorder, resize, and pin columns; the column set is stored in the view. To get the data outside of Wallarm Console, use [**Export attacks as CSV**](../search-and-filters/custom-report.md#attacks). -Hit sampling does not affect the quality of attack detection and Wallarm node continues to protect your applications and APIs even with hit sampling enabled. +## Attack details -## Full context of threat actor activities +Clicking an attack opens a resizable drawer with the attack details. The drawer stays open while you click through the table, so you can compare attacks without losing your place. + +### Overview + +The **Overview** tab summarizes the attack: its status, type, when it was first and last seen, the sessions, users, and source IPs involved, a timeline of its requests, and the distribution of its top hosts and response status codes. + +![Attack details - Overview](../../images/user-guides/events/attack-drawer-overview.png) + +The **Status** field shows what the [node did with the attack](../../admin-en/configure-wallarm-mode.md): + +* **Blocked** - all requests of the attack were blocked by the filtering node. +* **Partially Blocked** - some requests of the attack were blocked and others were only registered. +* **Monitoring** - all requests of the attack were registered but not blocked. + +### Requests + +The **Requests** tab lists the individual malicious requests of the attack and shows the details of the selected one. + +![Attack details - Requests](../../images/user-guides/events/attack-drawer-requests.png) + +Request details include the source IP, user, host, URI, request and session identifiers, and, for each detected attack sign, the malicious payload, the request point it was found in, and the [CWE, OWASP, and CAPEC classifications](../../attacks-vulns-list.md). **Full request** shows the complete HTTP request, which you can copy as raw HTTP or as a cURL command. + +Only unique requests are stored in the attack details. Repeated malicious requests are dropped from uploading to the Wallarm Cloud and not displayed. This process is called [hit sampling](grouping-sampling.md#sampling-of-hits). Hit sampling does not affect the quality of attack detection and Wallarm node continues to protect your applications and APIs even with hit sampling enabled. + +Use the checkboxes to select several requests and apply an action to all of them at once. The filter field above the list narrows the requests down within the open attack. ---8<-- "../include/request-full-context.md" +## Responding to attacks + +It is important to understand if your applications and APIs are properly protected from the attacks to have the possibility to adjust the protection measures if necessary. You can use information from the **Attacks** section to get this understanding and respond correspondingly. + +### Actions on an attack sign -## Attacks displayed exclusively in API Sessions +These response actions are available at the request level. Open an attack, switch to the **Requests** tab, and select a request: each detected attack sign in its details carries an action bar with the measures available for it. Wallarm decides which actions apply and shows only those: -Some of Wallarm's [mitigation controls](../../about-wallarm/mitigation-controls-overview.md) base their traffic analysis and corresponding actions entirely on API sessions which significantly improve their work: if previously you had several nodes and, for example, a brute force [rule](../../user-guides/rules/rules.md), your network load balancer could separate attack requests into different nodes and for each node the brute force counter worked separately. This could lead to missing some brute force attacks. The improved approach of mitigation control in this example is that it relies on session, no matter which node the traffic went through. +| Action | Purpose | +| -- | -- | +| **Mark as** → **TP** / **FP** | Confirm the detection as a true positive, or mark it as a [false positive](#false-positives). | +| **FP rule** | Create a [rule](#false-positives) that skips detection of this attack sign in similar requests. | +| **Add to IP list** | Add the source IP to the [denylist or allowlist](../ip-lists/overview.md). | +| **Open Mitigation control** | Open the [mitigation control](../../about-wallarm/mitigation-controls-overview.md) that reacted to the request and adjust it. | +| **View API Abuse profile** | Open the [API Abuse Prevention](../../api-abuse-prevention/overview.md) profile that detected the bot. | +| **API Abuse exception list** | Add the source IP to the [API Abuse Prevention exception list](../../api-abuse-prevention/exceptions.md). | +| **Open Spec Enforcement Policy** | Open the violated [API specification](../../api-specification-enforcement/overview.md) and adjust its settings. | -Because of that, the attacks found by such mitigation controls are displayed exclusively in [**API Sessions**](../../api-sessions/overview.md) (and not displayed in **Attacks**): +### Adjusting protection by attack type -* [Enumeration attack protection](../../api-protection/enumeration-attack-protection.md) (by mitigation control) -* [Brute force protection](../../api-protection/enumeration-attack-protection.md) (by mitigation control) -* [BOLA protection](../../api-protection/enumeration-attack-protection.md) (by mitigation control) -* [Forced browsing protection](../../api-protection/enumeration-attack-protection.md) (by mitigation control) -* [DoS protection](../../api-protection/dos-protection.md) (by mitigation control) +To respond to an attack, identify what type of attack took place, understand which Wallarm mechanism reacted to it, and adjust that mechanism if necessary. The table below maps attack types to the mechanism behind them and to the place where you tune it. -Attacks of the same types found by old tools like [rules](../../user-guides/rules/rules.md) can be found both in **Attacks** and **API Sessions**. +| Attack type | Detected by | Where to adjust | +| -- | -- | -- | +| **SQL Injection**, **Cross-site Scripting**, **Remote Code Execution**, **Path traversal**, **CRLF Injection**, **NoSQL Injection** and other [input validation attacks](../../attacks-vulns-list.md#attack-types) | [Standard detectors](../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection) | [Rules](../rules/rules.md) and the [filtration mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) of the application, host, or endpoint | +| Attacks detected by a regexp-based rule | [Custom attack detector](../rules/regex-rule.md) | The [regexp-based rule](../rules/regex-rule.md) that matched, which you can also [partially disable](../rules/regex-rule.md#partial-disabling) | +| **Virtual patch** | [Virtual patch](../rules/vpatch-rule.md) | The virtual patch rule. Virtual patches work regardless of the filtration mode | +| **Brute force**, **Forced browsing**, **Broken Object Level Authorization**, **Enumeration**, **Custom logic abuse**, **File upload violation** | [Mitigation control](../../about-wallarm/mitigation-controls-overview.md) or [trigger](../triggers/triggers.md) | **Open Mitigation control**, or the trigger in **Triggers**. If the source was denylisted, the [IP list](../ip-lists/overview.md#requests-from-denylisted-ips) entry | +| **Blocked source** | [IP lists](../ip-lists/overview.md#requests-from-denylisted-ips) | The denylist entry for the source IP | +| **Suspicious API activity**, **Account takeover**, **Security crawlers**, **Scraping**, **Unrestricted resource consumption** ([details](../../attacks-vulns-list.md#api-abuse)) | [API Abuse Prevention](../../api-abuse-prevention/overview.md) | **View API Abuse profile** to review the [detection confidence](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works) and [change the profile](../../api-abuse-prevention/setup.md#creating-profiles), or **API Abuse exception list** to [exempt the source IP](../../api-abuse-prevention/exceptions.md) | +| **Undefined endpoint**, **Undefined parameter**, **Invalid parameter**, **Missing parameter**, **Missing authentication**, **Invalid request** ([details](../../attacks-vulns-list.md#api-specification)) | [API Specification Enforcement](../../api-specification-enforcement/overview.md) | **Open Spec Enforcement Policy** | +| **GraphQL query size**, **GraphQL value size**, **GraphQL query depth**, **GraphQL aliases**, **GraphQL batching**, **GraphQL introspection**, **GraphQL debug** ([details](../../attacks-vulns-list.md#graphql-attacks)) | [GraphQL API Protection](../../api-protection/graphql-rule.md) | The **Detect GraphQL attacks** rule | +| **Credential stuffing** | [Credential Stuffing Detection](../../about-wallarm/credential-stuffing.md) | The [Credential Stuffing configuration](../../about-wallarm/credential-stuffing.md#configuring), specifically the monitored authentication endpoints | +| **System prompt retrieval**, **Prompt injection**, **Custom AI payload inspection** | [AI Payload Inspection](../../agentic-ai/ai-payload-inspection.md) mitigation control | **Open Mitigation control** | +| **ACL violation**, **MCP request verification failure**, **Invalid tool call** | [MCP mitigation controls](../../agentic-ai/mcp-mitigation-controls.md) | **Open Mitigation control** | + +Before adjusting, it is worth [investigating the full context](#full-context-of-threat-actor-activities) of the attack's requests: the session they belong to and the full sequence of requests in it. This shows all activity of the threat actor and what resources can be compromised. ## False positives -A false positive occurs when [attack signs](../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) are detected in a legitimate request. +A [false positive](../../about-wallarm/protecting-against-attacks.md#false-positives) occurs when [attack signs](../../about-wallarm/protecting-against-attacks.md#basic-set-of-detectors) are detected in a legitimate request. -To prevent the filtering node from recognizing such requests as attacks in future, **you can mark all or specific requests of the attack as false positives**. This automatically creates a rule to skip similar attack sign detection in similar requests, though it does not appear in the Wallarm Console. +You can handle it in two ways, depending on whether you only want to correct the data or also change what the node detects. -You can undo a false positive mark only within a few seconds after the mark was applied. If you decide to undo it later, this can be done only by sending a request to [Wallarm technical support](mailto: support@wallarm.com). +### Mark as false positive -The default view of the attack list presents only actual attacks (without false positives) - to change that, under **All attacks** switch from **Default view** to **With false positives** or **Only false positives**. +Marking removes the request from the attack statistics and hides it from the attack list, so your data reflects that the detection was not real. It does **not** change detection — the node still flags identical requests in future. -![False positive filter](../../images/user-guides/events/filter-for-falsepositive.png) +In the request details, use **Mark as false positive (FP)** (select several requests first to mark them at once). The same action reverts a mark. -See details on false positives [here](../../about-wallarm/protecting-against-attacks.md#false-positives). +Wallarm hides false positives by default — to review them, filter by **Verification Status**. -## Responding to attacks +### Create a false-positive rule -It is important to understand if your applications and APIs are properly protected from the attacks to have the possibility to adjust the protection measures if necessary. You can use information from the **Attacks** section to get this understanding and respond correspondingly. +To stop the node from **detecting** such requests in future, use **FP rule** — a prefilled [rule](../../about-wallarm/protecting-against-attacks.md#ignoring-certain-attack-types) where you choose how broadly to skip detection for the attacked parameter, from narrowest to broadest: + +* **Ignore this stamp for this parameter** — this exact attack sign (stamp) in the parameter. +* **Ignore this attack subtype for this parameter** — this attack subtype in the parameter. +* **Ignore this attack for this parameter** — this attack type in the parameter regardless of a malicious payload. +* **Ignore all attacks for this parameter** — all attacks in the parameter. +* **Create a custom rule** — open the rule editor to define the conditions and action yourself. -When dealing with this task, you will need to identify what type of attack took place, this will give you an understanding of what Wallarm's mechanisms provided protection and then adjust these mechanisms if necessary: +![Create a false-positive rule for an attack](../../images/user-guides/events/attack-false-positive-rule.png) -1. **Identify** - in the **Payload** field context menu, select **Show only**, then pay attention to the **Type** filter and search field content. -1. Check what was done for protection - note the **Status** column: +## Full context of threat actor activities - * `Blocked` - all hits of the attack were blocked by the filtering node. - * `Partially blocked` - some hits of the attack were blocked and others were only registered. - * `Monitoring` - all hits of the attack were registered but not blocked. - * `Bot detected` - this is a bot, check action within the attack. +Once the malicious request is detected by Wallarm and displayed in the **Attacks** section as the part of some attack, you can see the full context of this request: to which user session it belongs and what the full sequence of requests in this session is. This allows you to investigate all activity of the threat actor to understand attack vectors and what resources can be compromised. -1. Optionally (recommended), [investigate the full context](#full-context-of-threat-actor-activities) of the attack's malicious requests: to which [user session](../../api-sessions/overview.md) they belong and what the full sequence of requests in this session is. +To perform this analysis, open the attack, switch to the **Requests** tab, and select a request. In the request details, open the **Session ID** field menu and select **Investigate this attack in API Sessions**. Wallarm opens the [**API Sessions**][link-sessions] section filtered: the session that the initial request belongs to is displayed; only the initial request is displayed within this session. - This allows seeing all activity and logic of the threat actor and understanding attack vectors and what resources can be compromised. +![Investigating an attack request in API Sessions](../../images/user-guides/events/attack-open-request-in-sessions.png) -1. If you think it was not an actual attack, mark it [false positive](#false-positives). -1. **Understand** - become aware of the Wallarm mechanism that detected and reacted to attack. -1. **Adjust** - tune Wallarm's behavior ("how" depends on the mechanism). +Remove the filter by request ID to see all other requests in the session: now you have the full picture of what was going on within the session the malicious request belongs to. -| Identify | Understand | Adjust | -| -- | -- | -- | -| `sqli`, `xss`, `rce`, `ptrav`, `crlf`, `nosqli`, `ssi` [etc.](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) | [Standard tools for attack detection](../../about-wallarm/protecting-against-attacks.md#tools-for-attack-detection) (libproton, libdetection and rules) | Expand an attack and explore [CVEs](../../demo-videos/events-inspection.md) summary for the attack and CVEs for separate requests. Pay your attention to the node mode (`final_wallarm_mode` tag), visit **Rules WAF** ([US](https://us1.my.wallarm.com/rules) or [EU](https://my.wallarm.com/rules)), analyze them by application name from the attack. If necessary, adjust the rules or [filtration mode](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) for applications or their specific hosts or endpoints. | -| [`custom_rule`](../../user-guides/search-and-filters/use-search.md#search-by-regexp-based-customer-rule) | [Custom attack detector](../../user-guides/rules/regex-rule.md) | Expand an attack and follow the **Detected by custom rules** link(s) - if necessary, [modify](../../user-guides/rules/regex-rule.md) the rule(s) including [partial disabling](../../user-guides/rules/regex-rule.md#partial-disabling) it for particular branches. | -| `vpatch` | [Virtual patch](../../user-guides/rules/vpatch-rule.md) | Visit the **Rules WAF** section ([US](https://us1.my.wallarm.com/rules) or [EU](https://my.wallarm.com/rules)), search for "Create virtual patch" rules, if necessary, adjust the rule related to your attack. Have in mind that virtual patches work regardless of the filtration mode. | -| `brute`,
`dirbust`,
`bola`,
`multiple_payloads` | [Trigger](../../user-guides/triggers/triggers.md) and IP lists: [requests from denylisted IPs](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | Expand an attack and after analyzing the requests, click the displayed trigger name (if presented) and modify its parameters. Also note trigger tags, then go to **Triggers** ([US](https://us1.my.wallarm.com/triggers) or [EU](https://my.wallarm.com/triggers)) and find trigger by name, if necessary - adjust it.
If action is [`Blocked`](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips), this is done via denylist - go to **IP Lists** ([US](https://us1.my.wallarm.com/ip-lists) or [EU](https://my.wallarm.com/ip-lists)) and search by IP: if necessary, adjust time period for IP staying in denylist. | -| `blocked_source` | IP lists: [requests from denylisted IPs](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | Expand an attack and analyze requests from denylisted IP; after that, click the displayed trigger name and - if necessary - modify trigger settings. For manually denylisted IPs (`blocked_source`), go to **IP Lists** ([US](https://us1.my.wallarm.com/ip-lists) or [EU](https://my.wallarm.com/ip-lists)) and search by IP: if necessary, adjust time period for IP staying in denylist. | -| **Specific module or function:** | -| `api_abuse`, `account_takeover`, `security_crawlers`, `scraping`, `resource_consumption` ([details](../../attacks-vulns-list.md#api-abuse))
- note the **Bot detected** status for all | [API Abuse Prevention](../../api-abuse-prevention/overview.md) and IP lists: [requests from denylisted IPs](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) | Expand an attack and analyze the [heatmaps](../../api-abuse-prevention/exploring-bots.md#attacks) proving the [confidence](../../api-abuse-prevention/overview.md#how-api-abuse-prevention-works) that it is a bot, note the date of the attack and source IP.
If action is [`Blocked`](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips), this is done via denylist - go to **IP lists**, filter by date and IP, click **Reason** column to see IP address details, explore these details, click **Triggered profile**, explore it and [change](../../api-abuse-prevention/setup.md#creating-profiles) if necessary.

**Also, you can**:
  • [Add source IP to exception list](../../api-abuse-prevention/exceptions.md) for this IP never to be blocked. Also, you can remove IP from exception list (navigate to **API Abuse Prevention** → **Exception list**)
  • Add source IP to denylist, even if API abuse configuration is not supposed to do it automatically.
**Additionally you can**: In **IP Lists**, click the IP address itself to go back to **Events** and see all related attacks.| -| `bola` | [BOLA protection by either the trigger or mitigation control](../../admin-en/configuration-guides/protecting-against-bola-trigger.md) | Expand an attack and after analyzing the requests, click the displayed trigger name (if presented) and modify its parameters. Also note trigger tags, then go to **Triggers** ([US](https://us1.my.wallarm.com/triggers) or [EU](https://my.wallarm.com/triggers)) and find trigger by name, if necessary - adjust it.
If action is [`Blocked`](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips), this is done via denylist - go to **IP Lists** ([US](https://us1.my.wallarm.com/ip-lists) or [EU](https://my.wallarm.com/ip-lists)) and search by IP: if necessary, adjust time period for IP staying in denylist. | -| `undefined_endpoint`, `undefined_parameter`, `invalid_parameter_value`, `missing_parameter`, `missing_auth`, `invalid_request` (`api_specification` to search for all of them, [details](../../attacks-vulns-list.md#api-specification)) | [API Specification Enforcement](../../api-specification-enforcement/overview.md) | Expand an attack and follow the link to the violated specification. At the specification dialog, use the **API specification enforcement** tab to adjust settings, consider uploading the latest version of specification via the **Specification upload** tab. | -| `gql_doc_size`, `gql_value_size`, `gql_depth`, `gql_aliases`, `gql_docs_per_batch`, `gql_introspection`, `gql_debug` (`graphql_attacks` to search for all of them, [details](../../attacks-vulns-list.md#graphql-attacks)) | [GraphQL API Protection](../../api-protection/graphql-rule.md) | Expand an attack and follow the **GraphQL security policies** link - if necessary, modify existing **Detect GraphQL attacks** rule(s) or create additional ones for particular branches. | -| `credential_stuffing` | [Credential Stuffing Detection](../../about-wallarm/credential-stuffing.md) | Expand an attack and check the list of compromised credentials that were tried to be used, navigate to the Credential Stuffing ([US](https://us1.my.wallarm.com/credential-stuffing) or [EU](https://my.wallarm.com/credential-stuffing) Cloud) section and check [configuration](../../about-wallarm/credential-stuffing.md#configuring), specifically, the list of monitored authentication endpoints and recommendations for that list, and configured notifications about compromised credentials. | +## Sharing an attack or request + +To pass an attack to a colleague, use the share button in the attack details. Wallarm generates a link that opens the same attack with the same filter and time range applied, so the recipient sees exactly what you see. + +You can also share an individual request. In the **Requests** tab, open the request and use its share button. Wallarm generates a link that opens the same request within its attack. ## Dashboards Wallarm provides comprehensive dashboards to help you analyze detected attacks. -Wallarm's [Threat Prevention](../../user-guides/dashboards/threat-prevention.md) dashboard provides general metrics on your system's security posture, including multi-aspect information about attacks: their sources, targets, types and protocols. +Wallarm's [Threat Prevention](../dashboards/threat-prevention.md) dashboard provides general metrics on your system's security posture, including multi-aspect information about attacks: their sources, targets, types and protocols. ![Threat Prevention dashboard](../../images/user-guides/dashboard/threat-prevention.png) -The [OWASP API Security Top 10](../../user-guides/dashboards/owasp-api-top-ten.md) dashboard provides detailed visibility into your system's security posture against the OWASP API Top 10 threats, including attack information. +The [OWASP API Security Top 10](../dashboards/owasp-api-top-ten.md) dashboard provides detailed visibility into your system's security posture against the OWASP API Top 10 threats, including attack information. ![OWASP API Top 10](../../images/user-guides/dashboard/owasp-api-top-ten-2023-dash.png) @@ -137,7 +154,7 @@ Wallarm can send you notifications on detected attacks, hits and malicious paylo To configure notifications: -1. Configure [native integrations](../../user-guides/settings/integrations/integrations-intro.md) with the systems to send notifications (e.g. PagerDuty, Opsgenie, Splunk, Slack, Telegram). +1. Configure [native integrations](../settings/integrations/integrations-intro.md) 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. @@ -193,16 +210,9 @@ To configure notifications: } ] ``` - - * To set the threshold of attack, hit or malicious payload number and get notifications when the threshold is exceeded, configure appropriate [triggers](../../user-guides/triggers/triggers.md). -## API calls - -To get the attack details, you can [call the Wallarm API directly](../../api/overview.md) besides using the Wallarm Console UI. Below is an example of the API call for **getting the first 50 attacks detected in the last 24 hours**. + * To set the threshold of attack, hit or malicious payload number and get notifications when the threshold is exceeded, configure appropriate [triggers](../triggers/triggers.md). -Please replace `TIMESTAMP` with the date 24 hours ago converted to the [Unix Timestamp](https://www.unixtimestamp.com/) format. - ---8<-- "../include/api-request-examples/get-attacks-en.md" +## API calls -!!! warning "Getting 100 or more attacks" - For attack and hit sets containing 100 or more records, it is best to retrieve them in smaller pieces rather than fetching large datasets all at once, in order to optimize performance. [Explore the corresponding request example](../../api/request-examples.md#get-a-large-number-of-attacks-100-and-more) +To get the attack details, you can call the Wallarm API directly besides using the Wallarm Console UI. The **Attacks** section is backed by the [Attacks API](../../api-sessions/attacks-api.md), which lets you run the same aggregation queries, drill into groups, compute widgets, mark verdicts, export results, and manage saved views from your own client. diff --git a/docs/latest/user-guides/events/check-incident.md b/docs/latest/user-guides/events/check-incident.md index b9704348d2..44d60df66b 100644 --- a/docs/latest/user-guides/events/check-incident.md +++ b/docs/latest/user-guides/events/check-incident.md @@ -1,9 +1,7 @@ [link-using-search]: ../search-and-filters/use-search.md -[img-attacks-tab]: ../../images/user-guides/events/check-attack.png [img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png [img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png [use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action [link-attacks]: ../../user-guides/events/check-attack.md [link-incidents]: ../../user-guides/events/check-incident.md [link-sessions]: ../../api-sessions/overview.md @@ -91,7 +89,7 @@ Once an incident appears in the **Incidents** section: **Fix the security issue (vulnerability)** and then mark it closed in Wallarm. For detailed information, refer to [Managing Security Issues](../vulnerabilities.md) article. -1. Go back to the incident in the list, investigate what mechanism caused the system reaction (note the `Blocked`, `Partially blocked` and `Monitoring` [statuses](check-attack.md#attack-analysis) of the attacks), how the system will behave in future to alike requests and how to adjust (if necessary) this future behavior. +1. Go back to the incident in the list, investigate what mechanism caused the system reaction (note the `Blocked`, `Partially blocked` and `Monitoring` [statuses](check-attack.md#attack-details) of the attacks), how the system will behave in future to alike requests and how to adjust (if necessary) this future behavior. For incidents, this investigation and adjusting is performed [in the same way](check-attack.md#responding-to-attacks) as for all other attacks. diff --git a/docs/latest/user-guides/events/grouping-sampling.md b/docs/latest/user-guides/events/grouping-sampling.md index f72fbf7adb..a0512c5a76 100644 --- a/docs/latest/user-guides/events/grouping-sampling.md +++ b/docs/latest/user-guides/events/grouping-sampling.md @@ -1,70 +1,21 @@ -[link-using-search]: ../search-and-filters/use-search.md -[img-current-attacks]: ../../images/glossary/attack-with-one-hit-example.png -[img-incidents-tab]: ../../images/user-guides/events/incident-vuln.png -[img-show-falsepositive]: ../../images/user-guides/events/filter-for-falsepositive.png -[use-search]: ../search-and-filters/use-search.md -[search-by-attack-status]: ../search-and-filters/use-search.md#search-attacks-by-the-action -[img-verify-attack]: ../../images/user-guides/events/verify-attack.png -[al-brute-force-attack]: ../../attacks-vulns-list.md#brute-force-attack -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-bola]: ../../attacks-vulns-list.md#broken-object-level-authorization-bola -[link-analyzing-attacks]: analyze-attack.md -[img-false-attack]: ../../images/user-guides/events/false-attack.png -[img-removed-attack-info]: ../../images/user-guides/events/removed-attack-info.png -[link-check-attack]: check-attack.md -[link-false-attack]: false-attack.md -[img-current-attack]: ../../images/user-guides/events/analyze-current-attack.png -[glossary-attack-vector]: ../../glossary-en.md#malicious-payload +# Hit Sampling -# Grouping and Sampling of Hits +When [analyzing attacks](check-attack.md), it is important to understand how malicious requests are presented. To simplify the attack list, Wallarm samples hits before uploading them to the Wallarm Cloud. -When [analyzing attacks](check-attack.md), it is important to understand how malicious requests are presented. Wallarm uses hit grouping and sampling techniques to simplify the attack list. These techniques are explained in this article. +A **hit** is a single malicious request together with the metadata the Wallarm node adds. A request is not always a single attack of one type: when Wallarm detects several malicious payloads of different [attack types](../../attacks-vulns-list.md#attack-types) in one request, it records a separate hit for each type. Sampling therefore applies to hits, not to raw requests. -## Grouping of hits - -Wallarm groups [hits](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) into one attack using two grouping methods: - -* Basic grouping -* Grouping of hits by source IP - -These methods do not exclude each other. If hits have characteristics of both methods, they are all grouped into one attack. - -### Basic grouping - -The hits are grouped if they have 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, applied to all hits and cannot be disabled or modified. - -### Grouping of hits by source IP - -The hits are grouped if they have the same source IP address. If grouped hits have different attack types, malicious payloads and URLs, attack parameters will be marked with the `[multiple]` tag in the attack list. - -This hit grouping method works for all hits except for the ones of the Brute force, Forced browsing, BOLA (IDOR), Resource overlimit, Data bomb and Virtual patch attack types. - -If hits are grouped by this method, the [**Mark as false positive**](check-attack.md#false-positives) button and the [active verification](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing-trt) option are unavailable for the attack. - -Grouping by source IP is by default enabled 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. - -![Example of a trigger for hit grouping](../../images/user-guides/triggers/trigger-example-group-hits.png) - -You can adjust grouping by source IP to your needs: do this by creating 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. You can also pause grouping by temporarily disabling the default trigger. - -## Sampling of hits +## Overview When forming the attack details, Wallarm automatically makes information about the attack easier to analyze by displaying only unique [hits](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components) - non-unique (comparable and identical) hits are dropped from uploading to the Wallarm Cloud and not displayed. This process is called hit **sampling**. Hit sampling does not affect the quality of attack detection but helps to avoid its slowdown. Wallarm node continues attack detection and [blocking](../../admin-en/configure-wallarm-mode.md#available-filtration-modes) even with hit sampling enabled. -The **Hits sampling is enabled** notification shows that sampling works now. You can click this notification or add [`sampled`](../search-and-filters/use-search.md#search-for-sampled-hits) to the search field to see only attacks that sampling was applied to. In the attack details you will see how many similar hits were detected but not displayed: - -![Dropped hits](../../images/user-guides/events/bruteforce-dropped-hits.png) - !!! info "Displaying dropped hits in the attack list" Since dropped hits are not uploaded to the Wallarm Cloud, certain hits or whole attacks can be absent in the list of attacks. Since dropped requests are still requests processed by the Wallarm node, the RPS value in the node details UI increases with each dropped request. The number of requests and hits on the [Threat Prevention dashboard](../dashboards/threat-prevention.md) also includes the number of dropped hits. -**When hit sampling is enabled** +## When hit sampling is enabled * For [input validation attacks](../../attacks-vulns-list.md#attack-types), 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-vulns-list.md#attack-types), attacks of the [Data bomb](../../attacks-vulns-list.md#data-bomb) and [Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit): the **regular** sampling algorithm is enabled by default. **Extreme** sampling starts only if the percentage of attacks in your traffic is high. @@ -72,14 +23,14 @@ Since dropped requests are still requests processed by the Wallarm node, the RPS Sampling will be automatically disabled once the percentage of attacks in the traffic decreases. -### Extreme sampling +## Extreme sampling The extreme sampling algorithm has the following core logic: * If hits are of the [input validation](../../attacks-vulns-list.md#attack-types) type, the algorithm uploads to the Cloud only those with unique [malicious payloads](../../about-wallarm/protecting-against-attacks.md#what-is-attack-and-what-are-attack-components). 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](../../attacks-vulns-list.md#attack-types), [Data bomb](../../attacks-vulns-list.md#data-bomb) or [Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit) types, the algorithm uploads to the Cloud only the first 10% of them detected within an hour. -### Regular sampling +## Regular sampling Regular algorithm processes only hits saved after the extreme stage, unless hits are of the [behavioral](../../attacks-vulns-list.md#attack-types), [Data bomb](../../attacks-vulns-list.md#data-bomb) or [Resource overlimiting](../../attacks-vulns-list.md#resource-overlimit) types. If extreme sampling is disabled for hits of these types, the regular algorithm processes the original hit set. diff --git a/docs/latest/user-guides/events/overview.md b/docs/latest/user-guides/events/overview.md index dcf1d92755..effc64fa2f 100644 --- a/docs/latest/user-guides/events/overview.md +++ b/docs/latest/user-guides/events/overview.md @@ -15,7 +15,7 @@ Threat Management provides a full picture of what is happening: ![Threat Management](../../images/user-guides/events/tm-diagram.png) -All Threat Management components include advanced search and filtering capabilities. You can also make PDF and CSV reports for attacks and incidents with the filtered content of your choice. Wallarm uses sophisticated grouping mechanisms to logically combine requests into attacks and sessions and provides you with the ability to modify how Sessions are detected to make a full match to your application logic. +All Threat Management components include advanced search and filtering capabilities. You can also export attacks to CSV and make PDF and CSV reports for incidents with the filtered content of your choice. Wallarm uses sophisticated grouping mechanisms to logically combine requests into attacks and sessions and provides you with the ability to modify how Sessions are detected to make a full match to your application logic. ## Dashboards @@ -39,21 +39,17 @@ In addition to built-in dashboards, you can collect, present, and share the secu Wallarm continuously analyzes application traffic, detects and mitigates attacks in real-time. The [**Attacks**](check-attack.md) section of the Wallarm Console is the central hub for analyzing current attempts to penetrate your security perimeter and its staying protected from them as well as the tool for configuring additional security measures. -![Threat Management - Attacks](../../images/user-guides/events/filter-for-falsepositive.png) +![Threat Management - Attacks](../../images/user-guides/events/attacks-page.png) With **Attacks** section you can: -* See current attacks and Wallarm's taken measures and limit what you see to: - - * Attacks of specific types - * From specific IPs or geographical locations - * Occurred in specific time - * To specific applications or domains - * Etc. - -* See the same info for different periods - up to last 3 months +* See current attacks and Wallarm's taken measures, and [filter](../search-and-filters/attack-filters.md) what you see by attack type, source IP or country, target application, host or endpoint, response status code, user, and other criteria +* See the same info for different periods - up to last 6 months +* Change how requests are [grouped](../search-and-filters/attack-filters.md#grouping) into attacks, and save the filter, grouping, and column layout as a reusable [view](../search-and-filters/attack-filters.md#views) +* Review the summary charts for the filtered data and drill into any of them * Create or modify [rules](../../user-guides/rules/rules.md#what-you-can-do-with-rules) for treating similar attacks in the future * Correct Wallarm's decision making by highlighting [false positives](check-attack.md#false-positives) +* Export the filtered attacks to CSV ## Incidents @@ -72,6 +68,6 @@ The primary challenge the [**API Sessions**](../../api-sessions/overview.md) add ## Reports -For attacks, incidents or vulnerabilities, generate PDF or CSV [reports](../../user-guides/search-and-filters/custom-report.md). Do you want selected data? Apply filters and only filtered data will become part of the report. +For incidents or vulnerabilities, generate PDF or CSV [reports](../../user-guides/search-and-filters/custom-report.md). Do you want selected data? Apply filters and only filtered data will become part of the report. -![Attacks - creating report](../../images/user-guides/search-and-filters/custom-report.png) +For attacks, use [CSV export](../search-and-filters/custom-report.md#attacks): Wallarm exports the attacks matching your filter and emails you a download link. diff --git a/docs/latest/user-guides/ip-lists/overview.md b/docs/latest/user-guides/ip-lists/overview.md index 7ae8bd1b5e..06cb36bb2a 100644 --- a/docs/latest/user-guides/ip-lists/overview.md +++ b/docs/latest/user-guides/ip-lists/overview.md @@ -131,11 +131,9 @@ Such information is available for: 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 as the attacks with the `Monitoring` status. -Once trigger thresholds are exceeded, Wallarm adds the IP to the denylist and blocks further requests. You will see `Blocked` requests from this IP in the attack list. This applies to manually denylisted IPs as well. +Once trigger thresholds are exceeded, Wallarm adds the IP to the denylist and blocks further requests. You will see `Blocked` requests from this IP in the attack list. This applies to manually denylisted IPs as well. To tell the two apart, add the **Blocking Status** column to the attack table or filter by it. -![Events related to denylisted IPs - sending data enabled](../../images/user-guides/events/events-denylisted-export-enabled.png) - -Use [search tags of filters](../../user-guides/search-and-filters/use-search.md#search-by-attack-type) to find requests from denylisted IPs: [API abuse related](../../attacks-vulns-list.md#api-abuse), `brute`, `dirbust`, `bola`, `multiple_payloads` for automatically listed, `blocked_source` - for manual ones. +Use the [**Attack Type** filter](../../user-guides/search-and-filters/attack-filters.md#filter) to find requests from denylisted IPs: [API abuse related](../../attacks-vulns-list.md#api-abuse) types, **Brute force**, **Forced browsing**, **Broken Object Level Authorization** for automatically listed IPs, and **Blocked source** for manual ones. Note that search/filters will display both attacks in the `Monitoring` status and - if sending information is enabled - with the `Blocked` status for each attack type. For manually denylisted IPs an attack with the `Monitoring` status never exists. diff --git a/docs/latest/user-guides/rules/request-processing.md b/docs/latest/user-guides/rules/request-processing.md index 5be4e9fd6e..611a3fbc49 100644 --- a/docs/latest/user-guides/rules/request-processing.md +++ b/docs/latest/user-guides/rules/request-processing.md @@ -1,4 +1,4 @@ -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 +[rule-creation-options]: ../../user-guides/events/check-attack.md#responding-to-attacks [request-processing]: ../../user-guides/rules/request-processing.md [api-discovery-enable-link]: ../../api-discovery/setup.md diff --git a/docs/latest/user-guides/rules/sensitive-data-rule.md b/docs/latest/user-guides/rules/sensitive-data-rule.md index dd3e11bac8..a3378d782c 100644 --- a/docs/latest/user-guides/rules/sensitive-data-rule.md +++ b/docs/latest/user-guides/rules/sensitive-data-rule.md @@ -1,5 +1,5 @@ [img-masking]: ../../images/user-guides/rules/sensitive-data-rule.png -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 +[rule-creation-options]: ../../user-guides/events/check-attack.md#responding-to-attacks [request-processing]: ../../user-guides/rules/request-processing.md [api-discovery-enable-link]: ../../api-discovery/setup.md diff --git a/docs/latest/user-guides/rules/vpatch-rule.md b/docs/latest/user-guides/rules/vpatch-rule.md index 512ccb61ac..0c05746a32 100644 --- a/docs/latest/user-guides/rules/vpatch-rule.md +++ b/docs/latest/user-guides/rules/vpatch-rule.md @@ -1,7 +1,7 @@ [img-vpatch-example1]: ../../images/user-guides/rules/vpatch-rule-1.png [img-vpatch-example2]: ../../images/user-guides/rules/vpatch-rule-2.png [img-regex-example1]: ../../images/user-guides/rules/regex-rule-1.png -[rule-creation-options]: ../../user-guides/events/check-attack.md#attack-analysis_1 +[rule-creation-options]: ../../user-guides/events/check-attack.md#responding-to-attacks [request-processing]: ../../user-guides/rules/request-processing.md [api-discovery-enable-link]: ../../api-discovery/setup.md diff --git a/docs/latest/user-guides/search-and-filters/attack-filters.md b/docs/latest/user-guides/search-and-filters/attack-filters.md new file mode 100644 index 0000000000..b3bc0f9fef --- /dev/null +++ b/docs/latest/user-guides/search-and-filters/attack-filters.md @@ -0,0 +1,99 @@ +# Attack Search and Filters + +The **Attacks** section of Wallarm Console lets you narrow detected attacks down to the ones you are interested in, change how they are grouped, and save the result as a reusable view. This article describes these capabilities. + +To search detected incidents, see [Incident Search and Filters](use-search.md). + +## Filter + +The filter field above the attack list builds a filter from conditions. Each condition consists of a field, an operator, and one or more values. Start typing a field name, and Wallarm suggests the fields available for your account and, where the set of values is known, the values as well. + +![Attack filter - operators](../../images/user-guides/search-and-filters/attack-filter-operators.png) + +You can filter by the attack attributes, including attack type and subtype, host, path, source IP and its country, HTTP method and response status code, attacked parameter location, user and user role, session, application, API and authentication protocol, CVE, CWE, and OWASP category. Numeric conditions on aggregated metrics, such as the number of requests or unique IPs in an attack, are supported as well. + +Several fields are worth knowing about: + +* **Attack Type** and **Attack Subtype** offer the [attack types](../../attacks-vulns-list.md) Wallarm detects as ready values, from **SQL Injection** and **Brute force** to **GraphQL query depth** and **Prompt injection**. +* [**Blocking Status**](../../admin-en/configure-wallarm-mode.md) narrows the list to **Blocked**, **Partially Blocked**, or **Monitoring** attacks. +* **Verification Status** narrows the list to **True Positive**, [**False Positive**](../events/check-attack.md#false-positives), or **Unmarked** attacks. Wallarm hides false positives by default, so use this field to review them. +* **Attack Payload Content** and **Parameter Search** perform a full-text search in the malicious payload and in the attacked parameter. They support **is** (contains) and **is not** (does not contain) only. + +### Operators + +| Operator | Meaning | +| -- | -- | +| **is** | The field equals the value | +| **is not** | The field does not equal the value | +| **in** | The field equals any of the listed values | + +To match a value partially, type `*` or `?` wildcards into it: + +* `*.example.com` matches any subdomain +* `*login*` matches any path containing `login` + +A value without wildcards is an exact match. + +Matching with wildcards is case-insensitive, while an exact match is case-sensitive. + +The **HTTP Method** field does not support wildcards. + +### Combining conditions + +Conditions can be combined with the `AND` and `OR` operators and nested into groups, which allows expressing requirements like "SQL injections or cross-site scripting, coming from outside the corporate network". + +Conditions combined with `AND` must all be met; conditions combined with `OR` require any one of them. + +### Filtering from the table and charts + +Besides typing conditions, you can build the filter from the data you are already looking at: + +* In a table cell, use the context menu to add the cell value to the filter with **Show only** or **Exclude**. +* In the request details, the **Source IP**, **Host**, **URI**, **User**, and **Session ID** fields offer **Investigate attacks** actions that open the attacks matching or excluding that value. +* In the **Statistic** panel, click a bar, a pie segment, or a point on the chart to drill into the attacks behind it. + +Drilling down adds a breadcrumb trail above the list. The condition you drilled into is displayed as a locked chip in the filter field; click a breadcrumb to step back. + +## Time range + +The time range selector limits the data to a period. Choose one of the relative periods (last hour, 6 hours, 12 hours, 24 hours, 7 days, 30 days, or 90 days), or set an absolute period in the calendar. The [maximum period](../../about-wallarm/data-retention-policy.md) is 6 months. + +## Grouping + +**Group by** controls how malicious requests are combined into the attacks you see in the list: + +* **Type** groups by attack type, payload location, and host. This is the default. +* **IP** groups by source IP across all hosts, which answers which IPs are attacking you. +* **None** applies no grouping and shows individual requests. +* **Custom** builds a grouping from up to 4 attributes of your choice. + +Grouping changes the rows and the metrics computed for them, not the underlying requests. Statistics and the filter apply to the grouped data. + +## Views + +A view stores a filter, a grouping, a time range, sorting, and a column layout under a name. Views are displayed as tabs above the filter field, which lets you switch between saved perspectives on your attack data in one click. + +**All attacks** is a built-in view that cannot be modified. To build on it, duplicate it first. + +Once you change anything in a view, Wallarm offers to save it: + +* **Save view** stores the changes in the current view. +* **Save as new** creates a new view and leaves the original one intact. +* **Reset changes** discards the changes. + +The menu of a view provides **Rename view**, **Duplicate view**, **Set as default**, **Copy link**, and **Delete view**. The default view is the one that opens when you enter the **Attacks** section. + +When creating a view, choose its visibility: + +* **This tenant only**: the view is available in the current tenant. +* **Organization**: the view is available to everyone in your organization, across all its tenants. + +Visibility is set at creation and cannot be changed afterwards. + +## Export + +**Export attacks as CSV** exports the attacks matching the current filter, time range, and grouping, with the columns of the current view. See [Creating Reports](custom-report.md#attacks) for the procedure. + +## API calls + +The filtering, grouping, and view capabilities described here are available in the [Attacks API](../../api-sessions/attacks-api.md), which lets you run the same queries from your own client. diff --git a/docs/latest/user-guides/search-and-filters/custom-report.md b/docs/latest/user-guides/search-and-filters/custom-report.md index c0f3a94555..ca040b7fe3 100644 --- a/docs/latest/user-guides/search-and-filters/custom-report.md +++ b/docs/latest/user-guides/search-and-filters/custom-report.md @@ -1,26 +1,50 @@ [img-custom-report]: ../../images/user-guides/search-and-filters/custom-report.png +[img-attack-export]: ../../images/user-guides/search-and-filters/attack-export.png [link-using-search]: use-search.md +[link-attack-filters]: attack-filters.md # Creating Reports -You can filter events and then export the results into a PDF or CSV report. Wallarm will email the created report to the specified address. +You can filter events and then get the results as a file that Wallarm emails to you. How you do this depends on the event type: -PDF is a visually rich report, good for data analysis and presenting. This report includes: +* For [attacks](#attacks), export the attack list to CSV from the **Attacks** section. +* For [incidents and vulnerabilities](#incidents-and-vulnerabilities), generate a PDF or CSV report from the **Incidents** or **Vulnerabilities** section. -* Summaries for attacks, vulnerabilities and incidents -* Detailed information on the events +## Attacks -CSV includes details on each event matching the filter and is good for technical purposes. You can use it for creating dashboards, getting unique attacker IPs, producing a list of attacked API hosts/applications, etc. +In the **Attacks** section, **Export attacks as CSV** exports the attacks you currently see. The export reproduces the [filter][link-attack-filters], the time range, the grouping, and the columns of the active view, so the file matches the list on the screen. -CSV report may include several CSV files, one for each type of event - attack, incident, vulnerability. Each CSV has a maximum of 10,000 events, sorted by the events with the most hits. +To export attacks: -## Generating +1. In Wallarm Console, go to the **Attacks** section and narrow the list down to the attacks you need. +1. Click **Export attacks as CSV**. +1. Set the **Email** to send the download link to. -In Wallarm Console, reports can be generated from the **Attacks**, **Incidents** or **Vulnerabilities** section. Whichever section you use, the report will contain all types of events - attacks, incidents, and vulnerabilities. Report content depends on the current filters. Filters applied for the attacks are automatically applied also for the incidents and vice versa. For vulnerabilities, the report will always contain the list of currently active vulnerabilities. + ![Exporting attacks as CSV][img-attack-export] +1. Click **Export**. + +Wallarm prepares the file in the background and emails you a link to download it. The link stays valid for one week. + +## Incidents and vulnerabilities + +For incidents and vulnerabilities, Wallarm generates a report in one of two formats: + +* PDF is a visually rich report, good for data analysis and presenting. This report includes: + + * Summaries for attacks, vulnerabilities and incidents + * Detailed information on the events + +* CSV includes details on each event matching the filter and is good for technical purposes. You can use it for creating dashboards, getting unique attacker IPs, producing a list of attacked API hosts/applications, etc. + + CSV report may include several CSV files, one for each type of event - attack, incident, vulnerability. Each CSV has a maximum of 10,000 events, sorted by the events with the most hits. + +### Generating + +In Wallarm Console, reports can be generated from the **Incidents** or **Vulnerabilities** section. Whichever section you use, the report will contain all types of events - attacks, incidents, and vulnerabilities. Report content depends on the current filters. For vulnerabilities, the report will always contain the list of currently active vulnerabilities. To generate a report: -1. In Wallarm Console, go to **Attacks**, **Incidents** or **Vulnerabilities** section. +1. In Wallarm Console, go to **Incidents** or **Vulnerabilities** section. 1. [Filter][link-using-search] the events. 1. Click **Report** (or **PDF/CSV** for **Vulnerabilities**) and select PDF or CSV. 1. Set the **Send to** email. @@ -28,13 +52,13 @@ To generate a report: ![Report creation window][img-custom-report] 1. Click **Export**. Wallarm will generate the report and email it. -## Downloading previous reports +### Downloading previous reports The last 3 PDF reports including those [generated for vulnerabilities](../vulnerabilities.md#security-issue-reports) are saved for 6 months from the date of generation. If necessary, download them from the export window. -## Getting regular reports via email +### Getting regular reports via email You can get a PDF report regularly - daily, weekly or monthly - via email. This report will contain data about attacks, incidents for the corresponding period and active vulnerabilities. diff --git a/docs/latest/user-guides/search-and-filters/use-search.md b/docs/latest/user-guides/search-and-filters/use-search.md index f7283dfa3d..6fab25fd9c 100644 --- a/docs/latest/user-guides/search-and-filters/use-search.md +++ b/docs/latest/user-guides/search-and-filters/use-search.md @@ -1,437 +1,98 @@ [al-sqli]: ../../attacks-vulns-list.md#sql-injection [al-xss]: ../../attacks-vulns-list.md#crosssite-scripting-xss [al-rce]: ../../attacks-vulns-list.md#remote-code-execution-rce -[al-brute-force]: ../../attacks-vulns-list.md#brute-force-attack [al-path-traversal]: ../../attacks-vulns-list.md#path-traversal -[al-crlf]: ../../attacks-vulns-list.md#crlf-injection -[al-open-redirect]: ../../attacks-vulns-list.md#open-redirect -[al-nosqli]: ../../attacks-vulns-list.md#nosql-injection -[al-logic-bomb]: ../../attacks-vulns-list.md#data-bomb -[al-xxe]: ../../attacks-vulns-list.md#attack-on-xml-external-entity-xxe -[al-virtual-patch]: ../../attacks-vulns-list.md#virtual-patch -[al-forced-browsing]: ../../attacks-vulns-list.md#forced-browsing -[al-ldapi]: ../../attacks-vulns-list.md#ldap-injection -[al-port-scanner]: ../../attacks-vulns-list.md#resource-scanning -[al-vuln-component]: ../../attacks-vulns-list.md#vulnerable-component -[al-overlimit]: ../../attacks-vulns-list.md#resource-overlimit -[email-injection]: ../../attacks-vulns-list.md#email-injection -[ssi-injection]: ../../attacks-vulns-list.md#ssi-injection -[invalid-xml]: ../../attacks-vulns-list.md#invalid-xml -[ssti-injection]: ../../attacks-vulns-list.md#serverside-template-injection-ssti -[overlimit-res]: ../../attacks-vulns-list.md#resource-overlimit -# Event Search and Filters +# Incident Search and Filters -Wallarm provides convenient methods for searching detected events (attacks and incidents). In the **Attacks** and **Incidents** sections of Wallarm Console, the following search methods are available: +The **Incidents** section of Wallarm Console lets you narrow the incident list down to the incidents you are interested in. You can select values in the filters, or type a query in the search field. This article describes both. -* **Filters** to select filtering criteria -* **Search field** to input search queries with attributes and modifiers similar to human language - -The values set in the filters are automatically duplicated in the search field, and vice versa. - -Any search query or a filter combination can be saved by clicking **Save a query**. +To search detected attack, see [Attack Search and Filters](attack-filters.md). ## Filters -Available filters are presented in Wallarm Console in multiple forms: - -* Filters panel that is expanded and collapsed using the **Filter** button -* Quick filters for excluding or showing only events with the specific parameter values - -![Filters in the UI](../../images/user-guides/search-and-filters/filters.png) - -When values of different filters are selected, the results will meet all those conditions. When different values for the same filter are specified, the results will meet any of those conditions. - -## Search field - -The search field accepts queries with attributes and modifiers similar to human language which makes submitting queries intuitive. For example: - -* `attacks xss`: to search for all [XSS-attacks][al-xss] -* `attacks today`: to search for all attacks that happened today -* `xss 12/14/2020`: to search for all suspicions, attacks, and incidents of [cross‑site scripting][al-xss] on 14 December 2020 -* `p:xss 12/14/2020`: to search for all suspicions, attacks, and incidents of all types within the xss HTTP request parameter (i.e. `http://localhost/?xss=attack-here`) as of 14 December 2020 -* `attacks 9-12/2020`: to search for all attacks from September to December 2020 -* `rce /catalog/import.php`: to search for all [RCE][al-rce] attacks and incidents on `/catalog/import.php` path since yesterday - -When values of different parameters are specified, the results will meet all those conditions. When different values for the same parameter are specified, the results will meet any of those conditions. - -!!! info "Setting the attribute value to NOT" - To negate the attribute value, please use `!` before the attribute or modifier name. For example: `attacks !ip:111.111.111.111` to show all attacks originated from any IP address excluding `111.111.111.111`. - -Below you will find the list of attributes and modifiers available for use in search queries. - -### Search by object type - -Specify in the search string: - -* `attack`, `attacks`: to search only for the attacks that are *not* aimed at known vulnerabilities. -* `incident`, `incidents`: to search only for incidents (attacks exploiting a known vulnerability). - -### Search by attack type - -Specify in the search string: - -* `sqli`: to search for [SQL injection][al-sqli] attacks. -* `xss`: to search for [Cross Site Scripting][al-xss] attacks. -* `rce`: to search for [OS Commanding][al-rce] attacks. -* `brute`: to search for [brute-force][al-brute-force] attacks and blocked requests from IPs [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) because of the attacks of this type. -* `ptrav`: to search for [path traversal][al-path-traversal] attacks. -* `crlf`: to search for [CRLF injection][al-crlf] attacks. -* `redir`: to search for [open redirect][al-open-redirect] attacks. -* `nosqli`: to search for [NoSQL injection][al-nosqli] attacks. -* `data_bomb`: to search for [logic bomb][al-logic-bomb] attacks. -* `ssti`: to search for [Server‑Side Template Injections][ssti-injection]. -* `invalid_xml`: to search for [usage of unsafe XML header][invalid-xml]. -* `overlimit_res`: to search for attacks aimed at [overlimiting of computational resources][al-overlimit]. -* `xxe`: to search for [XML External Entity][al-xxe] attacks. -* `vpatch`: to search for [virtual patches][al-virtual-patch]. -* `dirbust`: to search for [forced browsing][al-forced-browsing] attacks and blocked requests from IPs [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) because of the attacks of this type. -* `ldapi`: to search for [LDAP injection][al-ldapi] attacks. -* `scanner`: to search for [port scanner][al-port-scanner] attacks. -* `mail_injection`: to search for [Email Injections][email-injection]. -* `ssi`: to search for [SSI Injections][ssi-injection]. -* `overlimit_res`: to search for attacks of the [resource overlimiting][overlimit-res] type. -* `experimental`: to search for experimental attacks detected based on [custom regular expression](../rules/regex-rule.md). -* `bola`: to search for attacks exploiting the [BOLA (IDOR) vulnerability](../../attacks-vulns-list.md#broken-object-level-authorization-bola) and blocked requests from IPs [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) because of the attacks of this type. -* `mass_assignment`: to search for [Mass Assignment](../../attacks-vulns-list.md#mass-assignment) attack attempts. -* `api_abuse`: to search for [suspicious bot activity](../../attacks-vulns-list.md#suspicious-api-activity). -* `account_takeover` (`api_abuse` before 4.10.6): to search for [account takeover attempts](../../attacks-vulns-list.md#account-takeover). -* `scraping` (`api_abuse` before 4.10.6): to search for [scraping attempts](../../attacks-vulns-list.md#scraping). -* `security_crawlers` (`api_abuse` before 4.10.6): to search for [scanning attempts performed by security crawlers](../../attacks-vulns-list.md#security-crawlers). -* `resource_consumption`: to search for bot attempts of [unrestricted resource consumption](../../attacks-vulns-list.md#unrestricted-resource-consumption) -* `ssrf`: to search for [Server‑side Request Forgery (SSRF) and attacks](../../attacks-vulns-list.md#serverside-request-forgery-ssrf). -* `blocked_source`: to search for attacks from **manually** [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) IPs. -* `multiple_payloads`: to search for attacks detected by the [Number of malicious payloads](../../admin-en/configuration-guides/protecting-with-thresholds.md) trigger and blocked requests from IPs [denylisted](../../user-guides/ip-lists/overview.md#requests-from-denylisted-ips) because of the attacks of this type. -* `credential_stuffing`: to search for attempts to use stolen authentication credentials ([credential stuffing](../../about-wallarm/credential-stuffing.md)). -* `ebpf`: to search for attacks detected by the [Wallarm eBPF-based solution](../../installation/oob/ebpf/deployment.md). -* `file_upload_violation`: to search for violations of [file upload restriction policies](../../api-protection/file-upload-restriction.md). -* `graphql_attacks`: to search for all violations of the [organization's GraphQL policy](../../api-protection/graphql-rule.md). Also, specific violations can be searched by: - * `gql_doc_size`: violation of maximum allowed total query size - * `gql_value_size`: violation of maximum allowed value size - * `gql_depth`: violation of maximum allowed query depth - * `gql_aliases`: violation of maximum allowed number of aliases - * `gql_docs_per_batch`: violation of maximum allowed number of batched queries - * `gql_introspection`: forbidden introspection query - * `gql_debug`: forbidden debug mode query -* `api_specification`: to search for all [specification-based](../../api-specification-enforcement/overview.md) violations. Also, specific violations can be searched by: - * `undefined_endpoint`: attempt to request the endpoint not presented in your specification - * `undefined_parameter`: requests marked as attacks because they include parameters not presented for this endpoint in your specification - * `missing_parameter`: requests marked as attacks because they do not include the parameter or its value that are marked as required in your specification - * `invalid_parameter_value`: requests marked as attacks because some of their parameter's value is not in correspondence with its type/format defined by your specification - * `missing_auth`: requests marked as attacks because they do not contain the required information about the authentication method - * `invalid_request`: requests marked as attacks because they contain an invalid JSON - * auxiliary search tag - `processing_overlimit`: API Specification Enforcement has limits applied to comparing requests against specifications - when exceeding these limits, it stops processing the request and creates the event informing about that - * see also: `spec:''` [here](#search-by-specification) - -An attack name can be specified in both uppercase and lowercase letters: `SQLI`, `sqli`, and `SQLi` are equally correct. - -### Search attacks associated with the OWASP top threats - -You can find attacks associated with the OWASP top threats by using the OWASP threat tags. The format to search for these attacks is `owasp_api1_2023`. - -These tags correspond to the original numbering of threats as defined by OWASP. Wallarm associates attacks with the OWASP API Top threats of the 2023 version. - -### Search by known attacks (CVE and well‑known exploits) - -* `known`: to search for requests that precisely attack since they exploit CVE vulnerabilities or other well‑known vulnerability types. - - To filter attacks by certain CVE or another well‑known vulnerability type, you can pass the appropriate tag in addition to the tag `known` or separate from it. For example: `known:CVE-2004-2402 CVE-2018-6008` or `CVE-2004-2402 CVE-2018-6008` to search for attacks exploiting the [CVE-2004-2402](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-2402) and [CVE-2018-6008](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6008) vulnerabilities. -* `!known`: potential false positives. These requests may contain little‑known exploits or the context turning the exploits into legitimate parameter values. - -To filter attacks by CVE and well‑known exploits, quick filters by event types and **CVE and exploits** can be used. - -### Search hits by API protocols - -To filter hits by API protocols, use the `proto:` or `protocol:` tag. - -This tag allows the following values: - -* `proto:graphql` -* `proto:grpc` -* `proto:websocket` -* `proto:rest` -* `proto:soap` -* `proto:xml-rpc` -* `proto:web-form` -* `proto:webdav` -* `proto:json-rpc` - -### Search hits by authentication protocols - -To filter hits by authentication protocols attackers have used, use the `auth:` tag. - -This tag allows the following values: - -* `auth:none` -* `auth:api-key` -* `auth:aws` -* `auth:basic` -* `auth:bearer` -* `auth:cookie` -* `auth:digest` -* `auth:hawk` -* `auth:jwt` -* `auth:ntlm` -* `auth:oauth1` -* `auth:oauth2` -* `auth:scram` - -### Search by the attack target - -Specify in the search string: - -* `client`: to search for clients' data attacks. -* `database`: to search for database attacks. -* `server`: to search for app server attacks. - -### Search by risk level - -Specify the risk level in the search string: - -* `low`: low risk level. -* `medium`: medium risk level. -* `high`: high risk level. - -### Search by event time - -Specify time period in the search string. If the period is not specified, the search is conducted within the events that occurred during the last 24 hours. - -There are the following methods to specify the period: - -* By date: `11/10/2020-11/14/2020` -* By date and time (seconds are disregarded): `11/10/2020 11:11`, `11:30-12:22`, `11/10/2020 11:12-01/14/2020 12:14` -* With relation to a certain moment of time: `>11/10/20` -* Using string aliases: - * `yesterday` equal to yesterday's date - * `today` equal to today's date - * `last ` equal to the period from the entire past unit start to current date and time - - `week`, `month`, `year` or the number of these units can be used as ``. For example: `last week`, `last 3 month` or `last 3 months`. - - * `this ` equal to current unit - - `week`, `month`, `year` can be used as ``. For example: `this week` will return events detected on Monday, Tuesday and Wednesday this week if today is Wednesday. - -Date and time format depends on the settings specified in your [profile](../settings/account.md): - -* MM/DD/YYYY if **MDY** is selected -* DD/MM/YYYY if **DMY** is selected -* `13:00` if **24‑hour** is ticked -* `1pm` if **24‑hour** is unticked - -The month can be specified as both number and name: `01`, `1`, `January`, `Jan` for January. The year can be specified in both full form (`2020`) and shortened form (`20`). If the year is not specified in the date, then the current year is used. - -### Search by IP address - -To search by IP address, use the `ip:` prefix, after which you can specify -* A specific IP address, for example `192.168.0.1`—in this case, all attacks and incidents will be found for which the source address of the attack corresponds to this IP address. -* An expression describing a range of IP addresses. -* A total number of IP addresses related to an attack or incident. - -#### Search by IP address range - -To set a required range of IP addresses, you can use -* An explicit IP address range: - * `192.168.0.0-192.168.63.255` - * `10.0.0.0-10.255.255.255` -* A part of an IP address: - * `192.168.`—equivalent to `192.168.0.0-192.168.255.255`. Redundant format with the `*` modifier is allowed—`192.168.*` - * `192.168.0.`—equivalent to `192.168.0.0-192.168.0.255` -* An IP address or part of it with a range of values inside the last octet in the expression: - * `192.168.1.0-255`—equivalent to `192.168.1.0-192.168.1.255` - * `192.168.0-255`—equivalent to `192.168.0.0-192.168.255.255` - - !!! warning "Important" - When using a range of values within an octet, a dot is not set at the end. - -* Subnet prefixes ([CIDR notation](https://tools.ietf.org/html/rfc4632)): - * `192.168.1.0/24`—equivalent to `192.168.1.0-192.168.1.255` - * `192.168.0.0/17`—equivalent to `192.168.0.1-192.168.127.255` - -!!! note - You can combine the above methods for defining IP address ranges. To do this, list all the necessary ranges with the ip: prefix separately. - - **Example**: `ip:192.168.0.0/24 ip:10.10. ip:10.0.10.0-128` +The **Filter** button expands and collapses the filter panel. Selecting a value in a filter applies it to the list immediately, and the selected values also appear in the search field. -#### Search by number of IP addresses +![Filters in the Incidents section](../../images/user-guides/search-and-filters/incident-filters.png) -It is possible to search by the total number of IP addresses that are related to an attack or an incident (only for attacks and incidents): -* `ip:1000+ last month`—search for attacks and incidents over the past month for which the number of unique IP addresses is more than 1000 (equivalent to `attacks incidents ip:1000+ last month`). -* `xss ip:100+`—search for all cross‑site scripting attacks and incidents. The search result will be empty if the number of attacking IP addresses (with the XSS attack type) is less than 100. -* `xss p:id ip:100+`—search for all XSS attacks and incidents related to the id parameter (`?id=aaa`). This will return results only if the number of different IP addresses exceeds 100. +When you select values in different filters, the list shows the incidents matching all of them. When you select several values in one filter, the list shows the incidents matching any of them. -### Search by the data center the IP address belongs to +| Filter | Narrows the list by | +| -- | -- | +| **Type** | Attack type, such as **SQLi**, **XSS**, **RCE**, **Path traversal**, or **Mass assignment**. See the [full list of attack types](../../attacks-vulns-list.md#attack-types). | +| Date range | Period the incident was detected in. See [Date range](#date-range). | +| **Application** | Your [applications](../settings/applications.md) targeted by an incident. | +| **IP** | Source IP address, or a range of addresses. | +| **Domain** | Domain the attack was sent to. | +| **Response code** | Response status code group: **100**, **200**, **300**, **400**, or **500**. | +| **Source type** | What the source IP belongs to: a cloud provider such as **AWS**, **Azure**, or **GCP**, or **Tor**, **VPN**, **Proxy**, **Search Engine Spiders**, or **Malicious IPs**. | +| **Locations** | Country the source IP is registered in. | +| **CVE and exploits** | Known CVE the incident exploits. | +| **API protocols** | **REST API**, **GraphQL**, **gRPC**, **SOAP**, **JSON-RPC**, **XML-RPC**, **WebSocket**, **WebDAV**, or **Legacy Web Form**. | +| **Authentication** | Authentication method used in the request, such as **JWT authentication**, **Bearer token**, **API key**, **OAuth 2.0**, **Basic authentication**, or **None authentication**. | +| **Compare to...** | One of your uploaded [API specifications](../../api-specification-enforcement/overview.md). | -To search by the data center to which the IP address that originated the attacks belongs, use the `source:` prefix. +!!! info "Malicious IPs" + The **Malicious IPs** source type covers addresses that public threat intelligence resources widely associate with malicious activity and that Wallarm has validated. The same source type is available in the denylist for blocking by source type. -This attribute value can be: +### Date range -* `tor` for the Tor network -* `proxy` for the public or web proxy server -* `vpn` for VPN -* `aws` for Amazon -* `azure` for Microsoft Azure -* `gce` for Google Cloud Platform -* `ibm` for IBM Cloud -* `alibaba` for Alibaba Cloud -* `huawei` for Huawei Cloud -* `rackspace` for Rackspace Cloud -* `plusserver` for PlusServer -* `hetzner` for Hetzner -* `oracle` for Oracle Cloud -* `ovh` for OVHcloud -* `tencent` for Tencent -* `linode` for Linode -* `docean` for Digital Ocean +The date filter displays the currently selected period. Open it to change the period: -### Search by the country or region in which the IP address is registered +* Select one of the shortcuts: **Today**, **Last week**, **Last 2 weeks**, the current month, **Last month**, or **Last 3 months**. +* Or set the start and end dates in the two date fields, or by clicking the dates in the calendar. -To search by the country or region in which the IP address that originated the attacks is registered, use the `country:` prefix. +![Date range filter in the Incidents section](../../images/user-guides/search-and-filters/incident-date-range.png) -The country/region name should be passed to the attribute in the format corresponding to the standard [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1) in uppercase or lowercase letters. For example: `country:CN` or `country:cn` for attacks originating from China. +By default, the list shows incidents for the last month. -### Search for events originating from well-known malicious IPs +### Quick filters -Wallarm scans public resources for IP addresses that are widely recognized as being associated with malicious activities. We then validate this information to ensure its accuracy, making it easier for you to take necessary actions, such as denylisting these IPs. +Besides the filter panel, values in the incident list offer quick filters that show only the incidents with the specific value or exclude them. -To search for events originating from these malicious IP addresses, use the `source:malicious` tag. This stands for **Malicious IPs** and is named accordingly in the denylist, in the section for blocking by source type. - -We pull the data for this object from a combination of the following resources: - -* [Collective Intelligence Network Security](http://cinsscore.com/list/ci-badguys.txt) -* [Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/blockrules/compromised-ips.txt) -* [DigitalSide Threat-Intel Repository](http://osint.digitalside.it/Threat-Intel/lists/latestips.txt) -* [GreenSnow](https://blocklist.greensnow.co/greensnow.txt) -* [www.blocklist.de](https://www.blocklist.de/en/export.html) -* [NGINX ultimate bad bot blocker](https://github.com/mitchellkrogza/nginx-ultimate-bad-bot-blocker/blob/master/_generator_lists/bad-ip-addresses.list) -* [IPsum](https://github.com/stamparm/ipsum) - -### Search by server response status - -To search by server response status, specify `statuscode:` prefix. - -Response status can be specified as: -* a number from 100 to 999. -* «N–M» range, where N and M are figures from 100 to 999. -* «N+» and «N-» ranges, where N is a number from 100 to 999. - -### Search by server response size - -To search by the server response size, use the `s:` or `size:` prefix. - -You can search for any integer value. Figures above 999 can be specified without a prefix. The «N–M», «N+» and «N-» ranges can be specified, where figures above 999 can also be specified without a prefix. - -### Search by HTTP request method - -To search by HTTP request method, specify the `method:` prefix. - -To search for `GET`, `POST`, `PUT`, `DELETE`, `OPTIONS`: if upper-case is used, then the search string can be specified without a prefix. For all other values, a prefix should be specified. - -### Search by a number of hits within attack/incident - -To search attacks and incidents by a number of hits, specify the `N:` prefix. - -For example, you can search for attacks that have more than 100 hits: `attacks N:>100`. Or search for attacks with less than 10 hits with `attacks N:<10`. - -### Search by domain - -To search by domain, use the `d:` or `domain:` prefix. - -Any string that may be a domain of the second or a higher level can be specified without a prefix. Any string can be specified with a prefix. - -You may use masks within a domain. The symbol `*` replaces any number of characters; the symbol `?` replaces any single character. - -### Search by path - -To search by path, either: - -* Use the `u:` or `url:` prefix and specify the path in quotes starting with `/`, e.g.: `url:"/api/users"`, or -* Start the input with `/` without any prefix, e.g.: `/api/users` - -### Search by application - -To search by the application to which the attack was sent, use the `application:` or `app:` prefix (the former `pool:` prefix is still supported but not recommended). - -The attribute value is the application name set on the **Applications** tab in the **Settings** section. For example: `application:'Example application'`. - -### Search by parameter or parser - -To search by parameter or parser, use the `p:`, `param:`, or `parameter:` prefix, or the `=` suffix. If using the suffix, a string that does not start with `/` is considered to be a parameter (wherein the ending `=` character is not included in the value). - -Possible attribute values: - -* Name of the aimed parameter. - - For example, if you need to find attacks aimed at the `xss` parameter but not at XSS-attacks (for instance, SQL-injection attack having `xss` in the GET-parameter), then specify `attacks sqli p:xss` in the search string. -* Name of the [parser](../rules/request-processing.md) used by the Wallarm node to read the parameter value. The name must be in uppercase. - - For example, `attacks p:*BASE64` to find attacks aimed at any parameter parsed by the base64 parser. -* Sequence of parameters and parsers. - - For example: `attacks p:"POST_JSON_DOC_HASH_from"` to find attacks sent in the `from` parameter in the JSON body of a request. - -You may use masks within a value. The symbol `*` replaces any number of characters, the symbol `?` replaces any single character. - -### Search for anomalies in events - -To search for anomalies in events, use the `a:` or `anomaly:` prefix. - -To refine an anomaly search, use the following parameters: - -* `size` -* `statuscode` -* `time` -* `stamps` -* `impression` -* `vector` - -Example: - -`attacks sqli a:size` will search for all SQL-injection attacks that have response size anomalies in their requests. - -### Search by request identifier - -To search for attacks and incidents by request identifier, specify the `request_id` prefix. -The `request_id` parameter has the following value form: `a79199bcea606040cc79f913325401fb`. In order to make it easier to read, this parameter has been replaced by the placeholder abbreviation `` in the examples below. - -Examples: -* `attacks incidents request_id:`: to search for an attack or an incident with the `request_id` equal to ``. -* `attacks incidents !request_id:`: to search for attacks and incidents with the `request_id` not equal to ``. -* `attacks incidents request_id`: to search for attacks and incidents with any `request_id`. -* `attacks incidents !request_id`: to search for attacks and incidents without any `request_id`. - -### Search for sampled hits - -To search for the [sampled hits](../events/grouping-sampling.md#sampling-of-hits), add `sampled` to the search string. - -### Search by node UUID - -To search for attacks detected by specific node, specify the `node_uuid` prefix, followed by the node UUID. - -Examples: - -* `attacks incidents today node_uuid:`: to search for all attacks and incidents for today found by the node with this ``. -* `attacks today !node_uuid:`: to search for all attacks for today found by any node except the node with this ``. - -!!! info "Search only for new attacks" - Only attacks detected after May 31, 2023 will be displayed when searching by node UUID. - -You can find the node UUID in the **Nodes** section, [node details](../../user-guides/nodes/nodes.md#viewing-node-details). Click UUID to copy it or click **View events from this node for the day** (switches to the **Attacks** section). - -### Search by specification - -To get the list of events related to specific [specification policy violations](../../api-specification-enforcement/overview.md), in the search field specify `spec:''`. To get ``, in **API Specifications**, open your specification for editing - `specid` will be displayed in your browser address field. - -![Specification - use for applying security policies](../../images/api-specification-enforcement/api-specification-enforcement-events.png) - -Blocked and monitored events may be presented depending on the configured policy violation actions. In the event details, the violation type and link to the causing specification are displayed. +## Search field -### Search by regexp-based customer rule +The search field accepts queries with attributes and modifiers similar to human language, which makes it a quicker option once you know the attribute names. The values you select in the filters appear in the search field, and the attributes you type appear in the filters. -To get the list of attacks detected by [regexp-based customer rules](../../user-guides/rules/regex-rule.md), in the search field specify `custom_rule`. +For example: -For any of such attacks, in its details, the links to the corresponding rules are presented (there can be more than one). Click the link to access the rule details and edit them if necessary. +* `incidents today`: incidents that happened today +* `xss /catalog/import.php`: [cross‑site scripting][al-xss] incidents on the `/catalog/import.php` path +* `sqli p:id ip:100+`: [SQL injection][al-sqli] incidents in the `id` parameter, with more than 100 source IP addresses -![Attack detected by regexp-based customer rule - editing rule](../../images/user-guides/search-and-filters/detected-by-custom-rule.png) +When values of different attributes are specified, the results meet all those conditions. When different values for the same attribute are specified, the results meet any of those conditions. -You can use `!custom_rule` to get the list of attacks not related to any regexp-based customer rules. +!!! info "Setting the attribute value to NOT" + To negate the attribute value, use `!` before the attribute or modifier name. For example: `incidents !ip:1.1.1.1` shows all incidents originated from any IP address excluding `1.1.1.1`. + +### Attribute reference + +| Attribute | Purpose | Example | +| -- | -- | -- | +| *(no prefix)* | [Attack type](../../attacks-vulns-list.md), in uppercase or lowercase | `sqli`, `xss`, `rce`, `ptrav` | +| `owasp_api_2023` | Attacks associated with an OWASP API Top 10 2023 threat | `owasp_api1_2023` | +| `known` | Attacks exploiting CVEs or other well‑known vulnerability types. `!known` returns potential false positives | `known:CVE-2018-6008` | +| `proto:` | API protocol | `proto:graphql`, `proto:rest`, `proto:grpc` | +| `auth:` | Authentication method | `auth:jwt`, `auth:oauth2`, `auth:none` | +| *(no prefix)* | Attack target | `client`, `database`, `server` | +| *(no prefix)* | Risk level | `low`, `medium`, `high` | +| *(no prefix)* | Time period. Dates follow the format set in your [profile](../settings/account.md) | `yesterday`, `last 3 months`, `11/10/2020-11/14/2020`, `>11/10/20` | +| `ip:` | Source IP address, a range, a [CIDR](https://tools.ietf.org/html/rfc4632) prefix, or the number of source addresses | `ip:1.1.1.1`, `ip:192.168.1.0/24`, `ip:192.168.`, `ip:1000+` | +| `source:` | Data center or network the source IP belongs to | `source:aws`, `source:tor`, `source:vpn`, `source:malicious` | +| `country:` | Country the source IP is registered in, in the [ISO 3166-1](https://en.wikipedia.org/wiki/ISO_3166-1) format | `country:CN` | +| `statuscode:` | Response status code, a range, or an open range | `statuscode:404`, `statuscode:400-499`, `statuscode:500+` | +| `s:`, `size:` | Response size, a range, or an open range | `size:1000+` | +| `method:` | HTTP method. Uppercase common methods work without the prefix | `method:PATCH`, `POST` | +| `N:` | Number of hits in the incident | `N:>100`, `N:<10` | +| `d:`, `domain:` | Domain. Supports the `*` and `?` masks | `d:example.com`, `d:*.example.com` | +| `u:`, `url:` | Path. A value starting with `/` works without the prefix | `url:"/api/users"`, `/api/users` | +| `application:`, `app:` | Application name set on the **Applications** tab of the **Settings** section | `app:'Example application'` | +| `p:`, `param:`, `parameter:` | Attacked parameter, the [parser](../rules/request-processing.md) that read it, or a sequence of both. Supports the `*` and `?` masks | `p:id`, `p:*BASE64`, `p:"POST_JSON_DOC_HASH_from"` | +| `a:`, `anomaly:` | Anomalies in the event. Accepts `size`, `statuscode`, `time`, `stamps`, `impression`, `vector` | `a:size` | +| `request_id:` | Request identifier. Without a value, matches events that have any identifier | `request_id:a79199bcea606040cc79f913325401fb` | +| `sampled` | [Sampled hits](../events/grouping-sampling.md#sampling-of-hits) | `sampled` | +| `node_uuid:` | Node that detected the event. Only events detected after May 31, 2023 are returned. Find the UUID in [node details](../../user-guides/nodes/nodes.md#viewing-node-details) | `node_uuid:` | +| `spec:` | [Specification policy violations](../../api-specification-enforcement/overview.md). Get the identifier from the browser address bar when editing the specification | `spec:''` | +| `custom_rule` | Attacks detected by [regexp-based rules](../../user-guides/rules/regex-rule.md). The event details link to the rules that matched | `custom_rule` | + +Attack type names are case-insensitive: `SQLI`, `sqli`, and `SQLi` are equally correct. diff --git a/docs/latest/user-guides/triggers/triggers.md b/docs/latest/user-guides/triggers/triggers.md index 75be271c25..a89bc330fc 100644 --- a/docs/latest/user-guides/triggers/triggers.md +++ b/docs/latest/user-guides/triggers/triggers.md @@ -35,8 +35,6 @@ Using triggers, you can: Notifications can be delivered through configured [integrations](../../user-guides/settings/integrations/integrations-intro.md), including SIEM systems, messengers, and other external tools. -* Optimize attack and incident representation by [grouping hits](../../user-guides/events/grouping-sampling.md#grouping-of-hits). - ## Understanding filters Filters are used for [condition](#how-it-works) detailing. For example, you can set up reactions to attacks of certain types, such as brute-force attacks, SQL injections and others. You can add one or more filters in the Wallarm Console interface and set values for them. @@ -60,17 +58,9 @@ The following filters are available: New company accounts come with the following default (pre-configured) triggers: -* Group hits originating from the same IP into one attack - - The trigger groups all [hits](../../glossary-en.md#hit) 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. +!!! info "Hits from the same IP trigger no longer works" + Starting in September 2026, the **Hits from the same IP** trigger — which grouped hits from one source IP into a single attack — no longer works. Group attacks by source IP on demand instead: in the **Attacks** section, set **Group by** to source IP (see [Attack Search and Filters](../search-and-filters/attack-filters.md#grouping)). The trigger may still appear in this section for some time, but it has no effect. - 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](../events/check-attack.md#false-positives) 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](../../about-wallarm/detecting-vulnerabilities.md#threat-replay-testing-trt) 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](../../glossary-en.md#malicious-payload) within 1 hour [Graylist](../ip-lists/overview.md) 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](../ip-lists/overview.md) 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](../../about-wallarm/protecting-against-attacks.md#false-positives). @@ -81,7 +71,7 @@ New company accounts come with the following default (pre-configured) triggers: 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 temporarily disable any default trigger. You can also modify behavior provided by the default trigger - to do so, create your custom triggers of the same type. Creating any custom trigger deletes the default one; if you delete all your custom triggers, the default is restored. +You can temporarily disable a default trigger. You can also modify behavior provided by the default trigger - to do so, create your custom triggers of the same type. Creating any custom trigger deletes the default one; if you delete all your custom triggers, the default is restored. ## Trigger processing priorities diff --git a/images/glossary/attack-list-example.png b/images/glossary/attack-list-example.png new file mode 100644 index 0000000000..36f2aea867 Binary files /dev/null and b/images/glossary/attack-list-example.png differ diff --git a/images/user-guides/events/attack-drawer-overview.png b/images/user-guides/events/attack-drawer-overview.png new file mode 100644 index 0000000000..269361e1a9 Binary files /dev/null and b/images/user-guides/events/attack-drawer-overview.png differ diff --git a/images/user-guides/events/attack-drawer-requests.png b/images/user-guides/events/attack-drawer-requests.png new file mode 100644 index 0000000000..e8a8ca7485 Binary files /dev/null and b/images/user-guides/events/attack-drawer-requests.png differ diff --git a/images/user-guides/events/attack-false-positive-rule.png b/images/user-guides/events/attack-false-positive-rule.png new file mode 100644 index 0000000000..fa5958f309 Binary files /dev/null and b/images/user-guides/events/attack-false-positive-rule.png differ diff --git a/images/user-guides/events/attack-open-request-in-sessions.png b/images/user-guides/events/attack-open-request-in-sessions.png new file mode 100644 index 0000000000..b24055d45b Binary files /dev/null and b/images/user-guides/events/attack-open-request-in-sessions.png differ diff --git a/images/user-guides/events/attack-request-details.png b/images/user-guides/events/attack-request-details.png new file mode 100644 index 0000000000..0b15bbc40d Binary files /dev/null and b/images/user-guides/events/attack-request-details.png differ diff --git a/images/user-guides/events/attacks-page.png b/images/user-guides/events/attacks-page.png new file mode 100644 index 0000000000..b75bdd63d3 Binary files /dev/null and b/images/user-guides/events/attacks-page.png differ diff --git a/images/user-guides/search-and-filters/attack-export.png b/images/user-guides/search-and-filters/attack-export.png new file mode 100644 index 0000000000..c52cc3a904 Binary files /dev/null and b/images/user-guides/search-and-filters/attack-export.png differ diff --git a/images/user-guides/search-and-filters/attack-filter-operators.png b/images/user-guides/search-and-filters/attack-filter-operators.png new file mode 100644 index 0000000000..2e9843b590 Binary files /dev/null and b/images/user-guides/search-and-filters/attack-filter-operators.png differ diff --git a/images/user-guides/search-and-filters/custom-report.png b/images/user-guides/search-and-filters/custom-report.png index af0d83d643..eb717b2a58 100644 Binary files a/images/user-guides/search-and-filters/custom-report.png and b/images/user-guides/search-and-filters/custom-report.png differ diff --git a/images/user-guides/search-and-filters/incident-date-range.png b/images/user-guides/search-and-filters/incident-date-range.png new file mode 100644 index 0000000000..70a2ff9ed1 Binary files /dev/null and b/images/user-guides/search-and-filters/incident-date-range.png differ diff --git a/images/user-guides/search-and-filters/incident-filters.png b/images/user-guides/search-and-filters/incident-filters.png new file mode 100644 index 0000000000..f490f4c069 Binary files /dev/null and b/images/user-guides/search-and-filters/incident-filters.png differ diff --git a/include/api-request-examples/get-attacks-en.md b/include/api-request-examples/get-attacks-en.md index df782f4a56..09933448fe 100644 --- a/include/api-request-examples/get-attacks-en.md +++ b/include/api-request-examples/get-attacks-en.md @@ -1,8 +1,8 @@ === "US cloud" ```{.bash .wrapped-code} - curl -v -X POST "https://us1.api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" + curl -X POST "https://us1.api.wallarm.com/v1/client/YOUR_CLIENT_ID/attack-vectors/security-agg/query" -H "X-WallarmAPI-Token: YOUR_API_TOKEN" -H "Content-Type: application/json" -d '{"preset": "none", "select": ["attack_name", "attack_types", "hosts", "paths", "min_request_time", "status"], "time_range": "-24h", "limit": 50}' ``` === "EU cloud" ```{.bash .wrapped-code} - curl -v -X POST "https://api.wallarm.com/v1/objects/attack" -H "X-WallarmApi-Token: " -H "accept: application/json" -H "Content-Type: application/json" -d "{ \"filter\": { \"clientid\": [YOUR_CLIENT_ID], \"time\": [[TIMESTAMP, null]] }, \"offset\": 0, \"limit\": 50, \"order_by\": \"last_time\", \"order_desc\": true}" + curl -X POST "https://api.wallarm.com/v1/client/YOUR_CLIENT_ID/attack-vectors/security-agg/query" -H "X-WallarmAPI-Token: YOUR_API_TOKEN" -H "Content-Type: application/json" -d '{"preset": "none", "select": ["attack_name", "attack_types", "hosts", "paths", "min_request_time", "status"], "time_range": "-24h", "limit": 50}' ``` diff --git a/include/bot-attack-full-context.md b/include/bot-attack-full-context.md index c03c717cb1..b357b8a6e9 100644 --- a/include/bot-attack-full-context.md +++ b/include/bot-attack-full-context.md @@ -1,5 +1,5 @@ Once the malicious bot activity is detected by Wallarm's [API Abuse Prevention][link-api-abuse-prevention] and displayed in the [**Attacks**][link-attacks] section, you can see the full context of this attack's requests: to which user session they belong and what the full sequence of requests in this session is. This allows you to investigate all activity of the actor to verify whether the decision to mark this actor as a malicious bot was correct. -To perform this analysis, in Wallarm Console → **Attacks**, access the bot attack details, then click **Explore in API Sessions**. Wallarm will open the [**API Session**][link-sessions] section filtered: the session(s) related to these bot activities will be displayed. +To perform this analysis, in Wallarm Console → [**Attacks**][link-attacks], open the bot attack, switch to the **Requests** tab, and select a request. In the request details, open the **Session ID** field menu and select **Investigate this attack in API Sessions**. Wallarm opens the [**API Sessions**][link-sessions] section filtered: the session or sessions related to these bot activities are displayed. ![!API Sessions section - monitored sessions][img-api-sessions-api-abuse] \ No newline at end of file diff --git a/include/request-full-context.md b/include/request-full-context.md index 59b700a691..b67bb7b7d2 100644 --- a/include/request-full-context.md +++ b/include/request-full-context.md @@ -1,12 +1,9 @@ Once the malicious request is detected by Wallarm and displayed in the [**Attacks**][link-attacks] or [**Incidents**][link-incidents] section as the part of some attack, you can see the full context of this request: to which user session it belongs and what the full sequence of requests in this session is. This allows you to investigate all activity of the threat actor to understand attack vectors and what resources can be compromised. -To perform this analysis, in Wallarm Console → **Attacks** or **Incidents**, access the attack, and then specific request details. In request details, click **Explore in API Sessions**. Wallarm will open the [**API Session**][link-sessions] section filtered: the session that the initial request belongs to is displayed; only the initial request is displayed within this session. - -
- -
- -
-
+To perform this analysis, in Wallarm Console → [**Attacks**][link-attacks], open the attack, switch to the **Requests** tab, and select a request. In the request details, open the **Session ID** field menu and select **Investigate this attack in API Sessions**. + +In [**Incidents**][link-incidents], access the incident and then the request details, and click **Explore in API Sessions**. + +Wallarm opens the [**API Sessions**][link-sessions] section filtered: the session that the initial request belongs to is displayed; only the initial request is displayed within this session. Remove the filter by request ID to see all other requests in the session: now you have the full picture of what was going on within the session the malicious request belongs to. \ No newline at end of file diff --git a/mkdocs-6.x.yml b/mkdocs-6.x.yml index 73d3ca5d30..425885c0cf 100644 --- a/mkdocs-6.x.yml +++ b/mkdocs-6.x.yml @@ -381,18 +381,19 @@ nav: - Monitoring & Events: - Event Overview: user-guides/events/overview.md - - Analyzing Attacks: user-guides/events/check-attack.md - - Analyzing Incidents: user-guides/events/check-incident.md - - Grouping & Sampling: user-guides/events/grouping-sampling.md + - Attack Analysis: user-guides/events/check-attack.md + - Incident Analysis: user-guides/events/check-incident.md + - Hit Sampling: user-guides/events/grouping-sampling.md - Security Issues: user-guides/vulnerabilities.md + - Search & Reports: + - Attack Search & Filters: user-guides/search-and-filters/attack-filters.md + - Incident Search & Filters: user-guides/search-and-filters/use-search.md + - Security Reports: user-guides/search-and-filters/custom-report.md + - Triggers & Alerts: - Trigger Configuration: user-guides/triggers/triggers.md - - Search & Reports: - - Search & Filters: user-guides/search-and-filters/use-search.md - - Custom Reports: user-guides/search-and-filters/custom-report.md - - Account Settings: - Account: user-guides/settings/account.md # - General Settings: user-guides/settings/general.md diff --git a/mkdocs-7.x.yml b/mkdocs-7.x.yml index 1a883dbd7c..3de64d42dc 100644 --- a/mkdocs-7.x.yml +++ b/mkdocs-7.x.yml @@ -375,18 +375,19 @@ nav: - Monitoring & Events: - Event Overview: user-guides/events/overview.md - - Analyzing Attacks: user-guides/events/check-attack.md - - Analyzing Incidents: user-guides/events/check-incident.md - - Grouping & Sampling: user-guides/events/grouping-sampling.md + - Attack Analysis: user-guides/events/check-attack.md + - Incident Analysis: user-guides/events/check-incident.md + - Hit Sampling: user-guides/events/grouping-sampling.md - Security Issues: user-guides/vulnerabilities.md + - Search & Reports: + - Attack Search & Filters: user-guides/search-and-filters/attack-filters.md + - Incident Search & Filters: user-guides/search-and-filters/use-search.md + - Security Reports: user-guides/search-and-filters/custom-report.md + - Triggers & Alerts: - Trigger Configuration: user-guides/triggers/triggers.md - - Search & Reports: - - Search & Filters: user-guides/search-and-filters/use-search.md - - Custom Reports: user-guides/search-and-filters/custom-report.md - - Account Settings: - Account: user-guides/settings/account.md # - General Settings: user-guides/settings/general.md