Working with Filter Node Logs¶
This article guides you on how to find the log files of a Wallarm filtering node.
Log files are located within the /opt/wallarm/var/log/wallarm
directory. Here is a breakdown of the log files you will encounter and the type of information each contains:
-
brute-detect-out.log
: the log of fetching the brute force attack-related counters in the filter node cluster. -
export-attacks-out.log
: the log of exporting the attacks' data from the postanalytics module to the Wallarm cloud. -
export-counters-out.log
: the log of exporting the counters' data (see “Monitoring the Filter Node”). -
export-environment-out.log
: the log of collecting the installed Wallarm package versions and uploading this data to the Wallarm Cloud to be displayed in the filtering node details in Wallarm Console. These processes are run once per hour. -
syncnode-out.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-out.log
: the log of the postanalytics module operations. -
sync-ip-lists-out.log
(named assync-blacklist-out.log
in the previous node versions): the log of syncing the filtering node with IP addresses added to IP lists as single objects or subnets. -
sync-ip-lists-source-out.log
(named assync-mmdb-out.log
in the previous node versions): the log of syncing the filtering node with IP addresses registered in countries, regions and data centers from IP lists. -
appstructure-out.log
(only in the Docker containers): the log of the API Discovery module activity. -
registernode_loop-out.log
(only in the Docker containers): the log of activity of the wrapper script running theregister-node
script while it is succeeded. -
weak-jwt-detect-out.log
: the log of the JWT vulnerability detection. -
detect-cred-stuffing-out.log
: the log of the credential stuffing detection. -
api-firewall-out.log
: the log of the API specification enforcement.
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:
Name | Type | Value |
---|---|---|
request_id | String | Request identifier Has the following value form: a79199bcea606040cc79f913325401fb |
wallarm_request_cpu_time | Float | Time in seconds the CPU of the machine with the filtering node spent processing the request. |
wallarm_request_mono_time | Float | Time in seconds the CPU spent processing the request + time in the queue. For example, if the request was in the queue for 3 seconds and processed by CPU for 1 second, then:
|
wallarm_serialized_size | Integer | Size of the serialized request in bytes |
wallarm_is_input_valid | Integer | Request validity0 : request is valid. The request has been checked by filter node and matches LOM rules.1 : request is invalid. The request has been checked by filter node and does not match LOM rules. |
wallarm_attack_type_list | String | Attack types detected in the request with the library libproton. Types are presented in text format:
| . For example: if XSS and SQLi attacks are detected, the variable value is xss|sqli . |
wallarm_attack_type | Integer | Attack types detected in the request with the library libproton. Types are presented in bit string format:
6 . |
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:
-
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_cpu_time $wallarm_request_mono_time $wallarm_serialized_size $wallarm_is_input_valid $wallarm_attack_type $wallarm_attack_type_list';
-
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.
-
Restart NGINX by running one of the following commands depending on the OS you are using:
Detailed information
To see detailed information about configuring logging in NGINX, proceed to this link.