Skip to content

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:

  • api-firewall-out.log: the log of the API specification enforcement.

  • appstructure-out.log (only in the Docker containers): the log of the API Discovery module activity.

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

  • wcli-out.log: logs of most Wallarm services, including brute force detection, attack export to the Cloud, and the status of node synchronization with the Cloud, etc.

  • go-node.log: Native Node logs.

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_request_cpu_time":1
  • "wallarm_request_mono_time":4
wallarm_serialized_size Integer Size of the serialized request in bytes
wallarm_is_input_valid Integer Request validity
0: 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:
  • xss
  • sqli
  • rce
  • xxe
  • ptrav
  • crlf
  • redir
  • nosqli
  • infoleak
  • overlimit_res
  • data_bomb
  • vpatch
  • ldapi
  • scanner
  • mass_assignment
  • ssrf
  • ssi
  • mail_injection
  • ssti
  • invalid_xml
If several attack types are detected in a request, they are listed with the symbol |. 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:
  • 0x00000000: no attack: "0"
  • 0x00000002: xss: "2"
  • 0x00000004: sqli: "4"
  • 0x00000008: rce: "8"
  • 0x00000010: xxe: "16"
  • 0x00000020: ptrav: "32"
  • 0x00000040: crlf: "64"
  • 0x00000080: redir: "128"
  • 0x00000100: nosqli: "256"
  • 0x00000200: infoleak: "512"
  • 0x20000000: overlimit_res: "536870912"
  • 0x40000000: data_bomb: "1073741824"
  • 0x80000000: vpatch: "2147483648"
  • 0x00002000: ldapi: "8192"
  • 0x4000: scanner: "16384"
  • 0x20000: mass_assignment: "131072"
  • 0x80000: ssrf: "524288"
  • 0x02000000: ssi: "33554432"
  • 0x04000000: mail_injection: "67108864"
  • 0x08000000: ssti: "134217728"
  • 0x10000000: invalid_xml: "268435456"
If several attack types are detected in a request, the values are summarized. For example: if XSS and SQLi attacks are detected, the variable value is 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:

  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_cpu_time $wallarm_request_mono_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:

    sudo systemctl restart nginx
    
    sudo service nginx restart
    
    sudo systemctl restart nginx
    
    sudo systemctl restart nginx
    
    sudo systemctl restart nginx
    

Detailed information

To see detailed information about configuring logging in NGINX, proceed to this link.