Monitoring the filter node

The system status data passes through a locally installed collectd agent.

The agent's unstable or failing operation might cause:

  • Incorrect display of statistical data in the Wallarm interface.
  • Incorrect operation of external monitoring systems.

Methods of obtaining system parameters

  • Starting Nagios compatible scripts. You can get the value of each parameter from collectd via collectd_nagios. You can also get some of the parameters directly: each parameter's description has the information on what script to start in this case.

  • Getting the raw data stream from collectd. You can get the raw data stream from any system that is able to receive raw data from collectd via any of the write-plugins. For example, this can be another collectd, graphite, or logstash.

  • Triggering a notification on reaching a parameter threshold. You can set the notifications in the file /etc/collectd/conf.d/traps.conf or /etc/collectd.d/traps.conf.

    Possible notification methods:

    • NSCA and NSCA-ng
    • SNMP TRAP
    • email
    • custom scripts

Configuring NGINX

The NGINX-Wallarm module's unstable or failing operation might cause a complete or partial denial of service.

For monitoring purposes, NGINX must provide a statistics page for certain types of requests. To set up the process, use the wallarm_status directive in the NGINX configuration file.

If you have a custom setup, you might also need to change the file /etc/collectd/conf.d/nginx-wallarm.conf.

requests

Number of requests that can be analyzed. The requests directive does not count the requests that have already been analyzed. With the wallarm_mode directive set to off, the requests are not analyzed.

collectd:

curl_json-wallarm_nginx/gauge-requests
curl_json-wallarm_nginx/derive-requests

attacks

Number of requests with detected attacks.

collectd:

curl_json-wallarm_nginx/gauge-atacks
curl_json-wallarm_nginx/derive-attacks

abnormal

Number of requests considered abnormal for the application.

collectd:

curl_json-wallarm_nginx/gauge-abnormal
curl_json-wallarm_nginx/derive-abnormal`

blocked

Number of requests blocked by the system.

collectd:

curl_json-wallarm_nginx/gauge-blocked
curl_json-wallarm_nginx/derive-blocked

requests_lost

Number of requests that were not analyzed in the post-analysis module or transferred to the API. For these requests, blocking parameters were applied (i.e. malicious requests were blocked if system was operating in blocking mode), however, data on these events is not visible in the UI and is not taken into consideration for the behavioral/statistical based analytics. This includes tnt_errors and api_errors.

collectd:

curl_json-wallarm_nginx/gauge-requests_lost
curl_json-wallarm_nginx/derive-requests_lost

tnt_errors

Number of requests where the analysis concluded with an error in the post-analysis module. For these requests, blocking parameters were applied (i.e. malicious requests were blocked if system was operating in blocking mode), however, data on these events is not visible in the UI and is not taken into consideration for the behavioral/statistical based analytics.

collectd:

curl_json-wallarm_nginx/gauge-tnt_errors
curl_json-wallarm_nginx/derive-tnt_errors

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 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 without a local post analytics module.

collectd:

curl_json-wallarm_nginx/gauge-api_errors
curl_json-wallarm_nginx/derive-api_errors

segfaults

Number of issues that led to the emergency termination of the worker process. Normally it should be 0.

collectd:

curl_json-wallarm_nginx/gauge-segfaults
curl_json-wallarm_nginx/derive-segfaults

memfaults

Number of cases when the virtual memory limit was reached.

collectd:

curl_json-wallarm_nginx/gauge-memfaults
curl_json-wallarm_nginx/derive-memfaults


### `time_detect`

The total time it took to analyze the requests.

**collectd**:

curl_json-wallarm_nginx/gauge-time_detect

```
curl_json-wallarm_nginx/derive-time_detect

time_tnt

The total time it took to record the requests in the Tarantool memory.

collectd:

curl_json-wallarm_nginx/gauge-time_tnt
curl_json-wallarm_nginx/derive-time_tnt

Configuring Tarantool

Wallarm uses Tarantool to store the results of the requests analysis.

Tarantool's unstable or failing operation might lead to failure of the following functionality:

  • Upload of attack data to the Wallarm cloud. As a result, the Wallarm interface will not display the attacks.
  • Behavioral attack detection; for example, brute-force attacks
  • Application structure learning.

The following functionality is independent and does not fail:

  • Proxying of HTTP requests.
  • Blocking of attacks in the blocking and aggressive modes.

When using a custom address and port of Tarantool, you must change the file /etc/collectd/conf.d/wallarm-tarantool.conf.

fibers

Tarantool has two background processes:

  • wallarm.cleanup thread
  • wallarm.cleanup guardian

These processes are responsible for the cleanup of old requests on reaching the memory usage threshold. These processes' unstable or failing operation might cause reaching the upper limit of the allocated memory and inability to save new requests.

Nagios: /usr/lib/nagios/plugins/check_wallarm_tarantool_fibers

collectd: no

timeframe_size

The time frame to keep the requests in Tarantool. The time frame size depends on the amount of memory allocated to Tarantool and on the size and nature of the HTTP requests. The smaller time frame size negatively affects the detection algorithms that need access to historical data. As a result, the attacker may execute the brute-force attacks faster and remain undetected. This will record a smaller amount of historical data on the attacker's behavior.

Nagios: /usr/lib/nagios/plugins/check_wallarm_tarantool_timeframe

collectd:

wallarm-tarantool/gauge-timeframe_size

export_delay

The delay between the time the request is saved in Tarantool and the time the detected attacks are uploaded to the Wallarm cloud.

Nagios: /usr/lib/nagios/plugins/check_wallarm_export_delay

collectd:

wallarm-tarantool/gauge-export_delay

export_drops

The number of requests deleted before they were analyzed by the scripts that upload the attacks. The export_drops directive counts all requests, regardless of whether the requests have attacks or not. Since the time frame for the requests deletion and the time frame for the requests count can be different, you are recommended to use wallarm-tarantool/gauge-export_drops_flag for TRAP.

collectd:

wallarm-tarantool/gauge-export_drops
wallarm-tarantool/derive-export_drops

export_drops_flag

The flag indicates that the last iteration deleted the requests that were not analyzed by the scripts that upload the attacks.

collectd:

wallarm-tarantool/gauge-export_drops_flag

results matching ""

    No results matching ""