# Detection Tools Troubleshooting

Wallarm is a set of protection tools. If they work not as expected, you can always tune them under your specific needs and situation. This article describes how to do that.

## Generic approach

1. **Understand** Wallarm's [attack handling process](#attack-handling-process): know the set of tools and how they interact when used simultaneously.
1. **Find the desired request** that Wallarm processed (e.g., marked as attack or blocked).
1. **Identify the tool** that performed the action.
1. **Tune** the tool.

## Attack handling process

To detect and handle attacks, Wallarm uses the following process:

1. Checks [IP lists](https://docs.wallarm.com/user-guides/ip-lists/overview.md) and [Session lists](https://docs.wallarm.com/api-sessions/blocking.md#blocking-sessions) to understand whether to process the request at all. Denylist blocks the request and allowlist allows it - both without further analysis.
1. Determines the request format and [parse](https://docs.wallarm.com/user-guides/rules/request-processing.md) every request part to apply [basic detectors](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#basic-set-of-detectors).
1. Determines the endpoint the request is addressed to apply [custom rules](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#custom-rules)/[mitigation controls](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#mitigation-controls) and [specific module settings](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#specific-module-settings) and understand the [filtration mode](https://docs.wallarm.com/admin-en/configure-wallarm-mode.md).
1. Makes a decision whether the request is a part of attack or not based on basic detectors, custom rules and specific module settings.
1. Handles request in accordance with decision and filtration mode.

![Attack handling process - diagram](https://docs.wallarm.com/images/about-wallarm-waf/overview/attack-handling-diagram.png)

Note that rules, mitigation controls, settings and filtration mode can be inherited from the parent endpoint or [application](https://docs.wallarm.com/user-guides/settings/applications.md). More specific has priority.
## Detailed approach

1. Requests are in [API Sessions](https://docs.wallarm.com/api-sessions/exploring.md) (all: legitimate and ones that are the part of malicious activity, presented as logical sequence) or [Attacks](https://docs.wallarm.com/user-guides/events/check-attack.md#attack-analysis_1) (only malicious).
1. Get [Allowlist](https://docs.wallarm.com/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](https://docs.wallarm.com/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 blocked source, check **Reason**, if it was some automated tool, go to it and modify.

    * In **Denylist**, do not forget to play with dates if necessary: adding to Denylist is usually not forever, so source may have been blocked in past, not now.
    * If some specific violation was the reason of adding to Denylist, from Sessions you will be able to immediately go to control that caused the action using **Open mitigation control**.
    * You can manually edit the list, but remember automated tool is still in action and may edit the list again in future.

1. Blocked as part of [blocked session](https://docs.wallarm.com/api-sessions/blocking.md#blocking-sessions)? In Sessions, check **Status** (may be "Blocked" now). A session may also have been blocked for some time in past. Switch to **IP & Session Lists** → **Session lists** → **Denylist** and check **Reason** and **Added by**, if it was some automated tool, go to it and modify.

    * Do not forget to play with dates if necessary: adding to Session Denylist is usually not forever, so a session may have been blocked in past, not now.
    * You can manually remove session from the list, but remember automated tool is still in action and may block session again in future.

1. [Input validation attack](https://docs.wallarm.com/attacks-vulns-list.md#attack-types)? Normally found by [basic detectors](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#basic-set-of-detectors).

    * If false, [mark as false](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#false-positives) - it is [safe](https://docs.wallarm.com/about-wallarm/protecting-against-attacks.md#false-positive-safe).
    * Not satisfied with applied action? Adjust [filtration mode](https://docs.wallarm.com/admin-en/configure-wallarm-mode.md).
    * Want to fine-tune or check what fine-tuning is already in use? In **Rules WAF**, click **Add rule** and check the **Fine-tuning attack detection** section, search for this rules in **Rules WAF** by filter.
    * Found by [custom detector](https://docs.wallarm.com/user-guides/rules/regex-rule.md)? A request will contain link to it - follow the link and adjust.

1. [Behavioral attack](https://docs.wallarm.com/attacks-vulns-list.md#attack-types)? Bot? You will easily identify [malicious bot attacks](https://docs.wallarm.com/api-abuse-prevention/overview.md#automated-threats-blocked-by-api-abuse-prevention) both in Attacks and Sessions. Navigate to API Abuse Prevention and modify [profiles](https://docs.wallarm.com/api-abuse-prevention/setup.md#creating-profiles) or [exceptions](https://docs.wallarm.com/api-abuse-prevention/exceptions.md).
1. Other [behavioral attacks](https://docs.wallarm.com/attacks-vulns-list.md#attack-types)? They will continue link to the control - follow the link and adjust.
1. [API specification violation](https://docs.wallarm.com/api-specification-enforcement/overview.md#how-it-works)? Requests will contain link to the specification and checking settings - follow the link and adjust.

## Things to consider

Note that:

* Rules/mitigation controls of the same type obey [inheritance](#attack-handling-process). Sometimes you do not need to edit the main rule, just create its modification for some child branch. And vise versa - it makes sense to create more generic rules sometimes to cover more or all branches:

    * Inheritance does not work for rules with **In this part of request** part specified.
    * Besides inheritance, use [variability](https://docs.wallarm.com/user-guides/rules/rules.md#using-wildcards) with wildcards or regular expressions, but remember your should use **wildcards** in URI field only.

        ??? info "Show where to use wildcards"
            ![Wildcards - correct/incorrect usage](https://docs.wallarm.com/images/user-guides/rules/wildcards-correct-incorrect.png)

* Disable rules instead of deleting them. You can adjust and re-activate them later if you want.
* Wallarm provides [default controls](https://docs.wallarm.com/about-wallarm/mitigation-controls-overview.md#default-controls) in monitoring mode. Make sure to adjust them.
* [Filtration modes](https://docs.wallarm.com/admin-en/configure-wallarm-mode.md) other than `off` affect only input validation attacks, but `off` turns off **everything** for the selected scope.