[Bug] Syslog export failure: Missing security metadata and attack details

[Esyrokvash]

What happened?

The Syslog module is incorrectly streaming raw Nginx Access Logs instead of the Security/Detection Events promised in the documentation. Even though the WAF successfully identifies and blocks attacks (e.g., SQL Injection), the exported Syslog message is stripped of all security metadata, containing only basic HTTP info (IP, Status 403, User-Agent) and completely omitting critical fields like attack_type, rule_id, and payload

The "sensitive" data is cut out in the logs below
{
"tags": [
"beats_input_codec_plain_applied"
],
"@Version": "1",
"log": {
"offset": 12345678,
"file": {
"device_id": "99999",
"fingerprint": "a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0u1v2w3x4y5z6a7b8c9d0e1f2",
"path": "/data/safeline/logs/nginx/safeline/accesslog_1",
"inode": "111222333"
}
},
"bytes": "10255",
"agent": ""Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"",
"message": "1.2.3.4 | - | 10/Feb/2026:07:24:33 -0500 | "company-target.tld" | "GET /?id=1%27+OR+1=1--+ HTTP/2.0" | 403 | 10255 | "https://company-target.tld/?id=1%27+OR+1=1--+\" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"",
"request": ""GET /?id=1%27+OR+1=1--+ HTTP/2.0"",
"status": "403",
"user": "-",
"event": {
"original": "1.2.3.4 | - | 10/Feb/2026:07:24:33 -0500 | "company-target.tld" | "GET /?id=1%27+OR+1=1--+ HTTP/2.0" | 403 | 10255 | "https://company-target.tld/?id=1%27+OR+1=1--+\" | "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36""
},
"container": {
"id": "safeline"
},
"input": {
"type": "filestream"
},
"ecs": {
"version": "8.0.0"
},
"@timestamp": "2026-02-10T12:24:34.323Z",
"referrer": ""https://company-target.tld/?id=1%27+OR+1=1--+\"",
"time": "10/Feb/2026:07:24:33 -0500",
"domain": "company-target.tld",
"host": {
"os": {
"kernel": "6.12.0-generic",
"platform": "almalinux",
"version": "10.x",
"family": "redhat",
"name": "AlmaLinux",
"type": "linux"
},
"id": "hidden-host-id-0000000000000",
"mac": [
"00-00-00-00-00-01",
"00-00-00-00-00-02"
],
"architecture": "x86_64",
"hostname": "waf-node-01.internal",
"containerized": false,
"name": "waf-node-01.internal",
"ip": [
"10.0.0.100",
"172.17.0.1",
"192.168.0.1"
]
},
"ip": "1.2.3.4"
}

How we reproduce?

1. Configure WAF: Open Settings, scroll down to the Syslog section on the same page, and specify the remote Syslog server IP and port (e.g., 1514).

2. Setup Collector: Configure a remote Logstash instance to listen for incoming messages using the following configuration:
   input {
   tcp {
   port => 1514
   codec => plain
   }
   udp {
   port => 1514
   codec => plain
   }
   }
   output {
   file { path => "/var/log/logstash/waf-secure.log" }
   }

3. Trigger Attack: Execute a clear malicious request, such as a SQL Injection:
   curl -v "https:///?id=1%27+OR+1=1--+"

4. Observe Logs: Check the output in /var/log/logstash/waf-secure.log. You will see that the WAF sends a generic access log entry instead of the expected security event metadata:

Expected behavior

The Syslog output should strictly adhere to the data schema described in the official documentation. Specifically, when a security event occurs (such as a blocked SQL Injection), the WAF must transmit a structured JSON object containing the following security metadata:

attack_type: The classification of the attack (e.g., sqli, xss, backdoor).

rule_id: The specific ID of the detection rule that was triggered.

payload: The malicious part of the request that caused the block.

reason: A detailed explanation of the detection logic.

action: The action taken by the WAF (e.g., deny).

The expected log format should look like this (as per your documentation):
{
"event_id": "...",
"attack_type": "sqli",
"rule_id": "m_rule/...",
"action": "deny",
"payload": "1' OR 1=1--",
"risk_level": "high",
"location": "query_string",
"timestamp_human": "2026-02-10 12:24:33"
}
The WAF should not simply forward a raw Nginx access log, but rather a dedicated security event log generated by the detection engine.

Error log

No response