Skip to content

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: know the set of tools and how they interact when used simultaneously.

  2. Find request that Wallarm did something to (marked as attack or blocked).

  3. Locate the tool that performed the action.

  4. Tune the tool.

Attack handling process

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

  1. Checks IP lists and Session lists to understand whether to process the request at all. Denylist blocks the request and allowlist allows it - both without further analysis.

  2. Determines the request format and parse every request part to apply basic detectors.

  3. Determines the endpoint the request is addressed to apply custom rules/mitigation controls and specific module settings and understand the filtration mode.

  4. Makes a decision whether the request is a part of attack or not based on basic detectors, custom rules and specific module settings.

  5. Handles request in accordance with decision and filtration mode.

Attack handling process - diagram

Note that rules, mitigation controls, settings and filtration mode can be inherited from the parent endpoint or application. More specific has priority.

Detailed approach

  1. Requests are in API Sessions (all: legitimate and ones that are the part of malicious activity, presented as logical sequence) or Attacks (only malicious).

  2. Get Allowlist clear - no requests from it will appear in Attacks even if malicious. API Sessions is the chance to catch malicious from Allowlist.

  3. Blocked by Denylist? 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.

  4. Blocked as part of blocked session? 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.

  5. Input validation attack? Normally found by basic detectors.

    • If false, mark as false - it is safe.
    • Not satisfied with applied action? Adjust filtration mode.
    • Want to fine-tune or check what fine-tuning is already in use? In Rules, click Add rule and check the Fine-tuning attack detection section, search for this rules in Rules by filter.
    • Found by custom detector? A request will contain link to it - follow the link and adjust.

  6. Behavioral attack? Bot? You will easily identify malicious bot attacks both in Attacks and Sessions. Navigate to API Abuse Prevention and modify profiles or exceptions.

  7. Other behavioral attacks? They will continue link to the control - follow the link and adjust.

  8. API specification violation? 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. 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.

  • Use disabling instead of deleting - later you may wand to re-activate adjusted version.

  • Wallarm provides default controls (only monitoring) - do not forget to adjust them.

  • Filtration modes other than off affect only input validation attacks, but off turns off everything for the selected scope.