Checking the Filter Node Operation

If everything is configured correctly, Wallarm filters the requests and proxies the filtered requests in accordance with the configuration file settings.

To check the correct operation, you must:

  1. Run the command wallarm-status.
  2. Run a test attack.

1. Run wallarm-status

You can get filter node operation statistics by requesting url /wallarm-status.

You can enable or disable the command in the configuration file nginx.conf.

Run the command:

curl http://127.0.0.8/wallarm-status

The output is similar to:

{ "requests":0,"attacks":0,"blocked":0,"abnormal":0,"tnt_errors":0,"api_errors":0,
"requests_lost":0,"segfaults":0,"memfaults":0, "softmemfaults":0,"time_detect":0,"db_id":46,
"lom_id":16767,"proton_instances": { "total":1,"success":1,"fallback":0,"failed":0 },
"stalled_workers_count":0,"stalled_workers":[] }

where:

  • requests: number of requests that have been processed by the filter node.
  • attacks: number of recorded attacks.
  • blocked: number of blocked requests.
  • abnormal: number of requests abnormal for the application.
  • requests_lost: number of requests that were not analyzed in a post-analytics module and transferred to API. For these requests, blocking parameters were applied (i.e. malicious requests were blocked if the system was operating in blocking mode), however, data on these events is not visible in the UI. This is only used when Wallarm Node works with a local post analytics module.
  • tnt_errors: number of requests not analyzed by a post-analytics module. For these requests, the reasons of blocking are recorded, but the requests themselves are not counted in statistics and behavior checks.
  • api_errors: * The number of requests that were not submitted to the API for further analysis. For these requests, blocking parameters were applied (i.e., malicious requests were blocked if the system was operating in blocking mode), however, data on these events is not visible in the UI. This is only used when Wallarm Node works with a local post analytics module.
  • segfaults: number of issues that led to the emergency termination of the worker process.
  • memfaults: number of issues when the virtual memory limits were reached.
  • time_detect: total time of requests analysis.
  • db_id: proton.db version.
  • lom_id: LOM version.
  • proton_instances: information about proton.db + LOM pairs:
    • total: number of proton.db + LOM pairs.
    • success: number of the successfully uploaded proton.db + LOM pairs.
    • fallback: number of the proton.db + LOM pair loaded from the last saved files.
    • failed: number of the proton.db + LOM pairs that were not initialized and run in the "do not analyze" mode.
  • stalled_workers_count: the quantity of the workers that exceeded the time limit for request processing (the limit is set in the wallarm_process_time_limit directive).
  • stalled_workers: the list of the workers that exceeded the time limit for request processing (the limit is set in the wallarm_process_time_limit directive) and the amount of time spent on request processing.

wallarm-status command output depending on the node version

The wallarm-status command output depends on the installed filter node version. In this document, the command output for the 2.12 node version is presented.

You can see the output of the command for the 2.10 and older versions of node here.

The data on all counters is accumulated from the NGINX start. If Wallarm is integrated into a running NGINX server, NGINX must be restarted to start Wallarm.

Running the wallarm-status command

By default, the wallarm-status command is on the server with the installed filter node. To run the command on other servers, see the wallarm_status directive in Wallarm configuration options.

2. Run a Test Attack

To check if Wallarm correctly detects attacks, send an invalid request to the protected resource.

For example:

http://<resource_URL>/?id='or+1=1--a-<script>prompt(1)</script>

Wallarm must detect in the request the following:

Now the second run of wallarm_status will increase the attack counter. If the operation check is successful, the initial installation and setup is complete. See User guide.

results matching ""

    No results matching ""