Skip to content

Attacks are not uploaded to the Wallarm Cloud

If you suspect that attacks from the traffic are not uploaded to the Wallarm Cloud and, as a result, do not appear in the Wallarm Console UI, use this article to debug the issue.

To debug the problem, sequentially perform the following steps:

  1. Generate some malicious traffic to perform further debugging.

  2. Check the filtering node operation mode.

  3. Check that Tarantool has enough resources to process requests.

  4. Capture logs and share them with the Wallarm support team.

1. Generate some malicious traffic

To perform further debugging of the Wallarm modules:

  1. Send the following malicious traffic:

    for i in `seq 100`; do curl "http://<FILTERING_NODE_IP>/?wallarm_test_xxxx=union+select+$i"; sleep 1; done

    Replace <FILTERING_NODE_IP> with a filtering node IP you want to check. If required, add the Host: header to the command.

  2. Wait up to 2 minutes for the attacks to appear in Wallarm Console → Attacks. If all 100 requests appear, the filtering node operates OK.

  3. Connect to the server with the installed filtering node and get node metrics:

    curl http://127.0.0.8/wallarm-status

    Further, we will refer to the wallarm-status output.

2. Check the filtering node operation mode

Check the filtering node operation mode as follows:

  1. Make sure that the filtering node mode is different from off. The node does not process incoming traffic in the off mode.

    The off mode is a common reason for the wallarm-status metrics not to increase.

  2. Restart NGINX to be sure that Wallarm node settings have been applied (if the node has been installed from DEB/RPM packages):

    sudo systemctl restart nginx

    sudo service nginx restart

    sudo systemctl restart nginx

    sudo systemctl restart nginx

    sudo systemctl restart nginx

  3. Generate malicious traffic once again to be sure that attacks are still not uploaded to the Cloud.

3. Check that Tarantool has enough resources to process requests

The following Tarantool's basic metrics point to Tarantool problems connected with attack export:

  • wallarm.stat.export_delay is a delay in uploading attacks to the Wallarm Cloud (in seconds)

  • wallarm.stat.timeframe_size is the time interval Tarantool stores requests (in seconds)

  • wallarm.stat.dropped_before_export is the number of hits that did not have enough time to be uploaded to the Wallarm Cloud

To view the metrics:

  1. Connect to the server with the installed postanalytics module (Tarantool).

  2. Execute the following commands:

    wtarantool
require('console').connect('127.0.0.1:3313')
wallarm.stat.export_delay()
wallarm.stat.timeframe_size()
wallarm.stat.dropped_before_export()

If the wallarm.stat.dropped_before_export value is different from 0:

  • Increase the memory amount allocated for Tarantool (if wallarm.stat.timeframe_size is less than 10 minutes).

    Recommended memory

    It is recommended to adjust the memory allocated for Tarantool so that the wallarm.stat.timeframe_size metric does not drop below 300 seconds during the peak loads.

  • Increase the number of export_attacks handlers in /etc/wallarm/node.yaml → export_attacks (/opt/wallarm/etc/wallarm/node.yaml → export_attacks for Docker NGINX-based image, cloud images and all-in-one installer), e.g.:

    export_attacks:
  threads: 5
  api_chunk: 20

    The export_attacks settings are the following by default:

    • threads: 2
    • api_chunk: 10

4. Capture logs and share them with the Wallarm support team

If the steps above do not help to resolve the issue, please capture the node logs and share them with the Wallarm support team as follows:

  1. Connect to the server with the installed Wallarm node.

  2. Get the wallarm-status output as follows:

    curl http://127.0.0.8/wallarm-status

    Copy an output.

  3. Run the Wallarm diagnostic script:

    sudo /opt/wallarm/usr/share/wallarm-common/collect-info.sh

    sudo /usr/share/wallarm-common/collect-info.sh

    Get the generated file with logs.

  4. Send all collected data to the Wallarm support team for further investigation.