Working with Filter Node Logs¶

A filter node stores the following log files in the /var/log/wallarm directory:

• brute-detect.log and sync-brute-clusters.log: the log of fetching the brute force attack-related counters in the filter node cluster.

• export-attacks.log: the log of exporting the attacks' data from the postanalytics module to the Wallarm cloud.

• export-clusterization-data.log: the log of exporting the filter node cluster's data.

• export-counters.log: the log of exporting the counters' data (see “Monitoring the Filter Node”).

• syncnode.log: the log of syncing the filter node with the Wallarm cloud (this includes fetching the LOM and proton.db files from the cloud).

• tarantool.log: the log of the postanalytics module operations.

Configuring Extended Logging for the NGINX‑Based Filter Node¶

NGINX writes logs of the processed requests (access logs) into a separate log file, using the predefined combined logging format by default.

log_format combined '$remote_addr - $remote_user [$time_local] '
                    '"$request" $request_id $status $body_bytes_sent '
                    '"$http_referer" "$http_user_agent" ';

You can define and use a custom logging format by including one or several filter node variables (as well as other NGINX variables if needed). The NGINX log file will allow for much faster filter node diagnostics.

Filter Node Variables¶

You may use the following filter node variables when defining the NGINX logging format:

Configuration Example¶

Let us assume that you need to specify the extended logging format named wallarm_combined that includes the following variables:

• all variables used in the combined format

• all filter node variables

To do this, perform the following actions:

1. The lines below describe the desired logging format. Add them into the http block of the NGINX configuration file.

   log_format wallarm_combined '$remote_addr - $remote_user [$time_local] '
                               '"$request" $request_id $status $body_bytes_sent '
                               '"$http_referer" "$http_user_agent" '
                               '$wallarm_request_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list';
   

2. Enable the extended logging format by adding the following directive into the same block as in the first step:

   access_log /var/log/nginx/access.log wallarm_combined;

   Processed request logs will be written in the wallarm_combined format into the /var/log/nginx/access.log file.

   Conditional Logging

   With the directive listed above, all processed requests will be logged to a log file, including these that are not related to an attack.

   You can configure conditional logging to write logs only for the requests that are part of an attack (the wallarm_attack_type variable value is not zero for these requests). To do so, add a condition to the aforementioned directive: access_log /var/log/nginx/access.log wallarm_combined if=$wallarm_attack_type;

   This may be useful if you want to reduce a log file size, or if you integrate a filter node with one of SIEM solutions.

3. Restart NGINX by running one of the following commands depending on the OS you are using:

   DebianUbuntuCentOS or Amazon Linux 2.0.2021x and lower

   sudo systemctl restart nginx
   

   sudo service nginx restart
   

   sudo systemctl restart nginx
   

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send