Developing Wazuh Decoders and Rules for Lab Firewall

Date: Aug 8, 2026
Tags: Network Security Threat Detection Log Management Regex SIEM DNS Firewall Wazuh nftables dnsmasq Powershell Nmap Linux

Pasted image 20260803175859.png

I. Project Summary

In my previous lab entries, I configured a network firewall and routed its logs to a Wazuh SIEM. However, raw logs have limited context, making it difficult for detection rules to correlate specific attributes such as DNS query type, source IP, and firewall action.

To solve this, I created custom PCRE2 decoders to extract structured fields from nftables and dnsmasq logs. I then created detection rules mapped to the MITRE ATT&CK framework to identify possible indicators of compromise, such as spikes in NXDOMAIN queries and abnormally long DNS queries. Identifying these attacks early can help defenders investigate and respond before they lead to further impact.
Pasted image 20260822161238.png

II. Key Engineering Decisions
1. Created and Enhanced Telemetry Parsing
  • Developed custom Wazuh decoders for dnsmasq and nftables telemetry using PCRE2 regular expressions. The parsers extract contextual fields such as source IP, DNS query type, requested domain, firewall action, and network interface. This enables more accurate rule matching and improves investigation and threat hunting.
2. Layer 7 DNS Telemetry Analysis
  • Implemented DNS anomaly detection rules in Wazuh to identify characteristics commonly associated with DNS tunneling, such as unusually long query names and excessive TXT/NULL query activity.
3. Basic Behavioral Detection Rule over Hardcoded Signature
  • Implemented behavioral DNS detection by monitoring abnormal NXDOMAIN response frequency from individual hosts. This helps identify potential DGA activity where a malware is looking for the command-and-control server.
4. Reduced Alert Fatigue
  • Designed correlation-based detection rules using frequency and timeframe thresholds to reduce low-confidence alerts. Informational events are retained for visibility, while higher severity alerts require repeated suspicious behavior patterns.
III. Challenges
Challenges Probable Cause Fixes
Existing parent decoder is not valid ERROR: (2101): Parent decoder name invalid: 'kernel'. A custom decoder is accessing a built-in parent decoder I redeclared the parent decoder (kernel) along with the custom nftables decoder.
Inconsistent nftables log fields and different dnsmasq log formats. Developer implementation, multi-line log formats. I used option regex for fields that are sometimes missing on the logs.
I created separate decoders to match multi-line logs where option regex would make decoders difficult to read.
Verifying whether all possible log formats will match the decoders. No official collections of possible logs that will be generated by the software used.
I customized my nftables log structure using the log prefix.		 Observed the actual logs generated and used Gen AI LLMs to hypothesize possible variations based on the available fields.
Balancing parsing precision over CPU compute overhead Wazuh's default os_regex is highly efficient but lacks the ability to match complex patterns. Used pcre2 regex to ensure precise telemetry mapping while using os_regex for parent filters.
Custom decoders are not parsing the firewall logs on wazuh-logtest I used a sample log from wazuh's archive.log which is different from actual log due to rsyslog forwarding and preprocessing. I used the raw log generated directly on the firewall host.
Invalid packets are not arriving to the firewall Invalid packets do not arrive from a lab host to the lab firewall.
Lab router drops invalid packets despite the SPI feature being disabled.		 Disabled rp_filter on the lab firewall.
Used the VPN peer (aws-gateway) to send invalid packets directly to the lab firewall.
IV. Validation and Testing

The test summary below shows that all rules level >= 3 were triggered and displayed* on the Wazuh Dashboard.

Rule Description ID Level Test Result
dnsmasq started 100206 3 passed
dnsmasq stopped 100208 3 passed
Invalid packet ** 100303 3 passed
Txt/null resource record type 100211 4 passed
Repeated Invalid packets ** 100310 5 passed
Repeated packet with blocked IP 100311 6 passed
Extreme packet drop 100331 8 passed
Repeated Nxdomain 100220 7 passed
Repeated uncommon TLD 100223 6 passed
Repeated Txt/null + long domain 100230 9 passed
Repeated Txt/Null 100221 8 passed
Repeated long domain 100222 8 passed
Private IP on WAN interface 100312 8 passed
Packet with blocked IP 100313 7 passed
Repeated packet drop 100330 7 passed
Uncommon TLD 100213 4 passed
Txt/null + long domain 100214 5 passed

*Some rules that were tested and verified to be working are not included in the test cases below.
**Rule 100303 & 100310 (Invalid packet) were tested by using packets with invalid TCP flags.

V. Lessons Learned
  • Defenders have to carefully balance alert fatigue and catching stealthy attacks. While setting a rule for dropped packets with frequency thresholds of 20 queries over 60 seconds reduces false positives, attackers using low and slow tactics such as nmap with -T0 or -T1 flags will completely evade the rule.
  • The ability of attackers to evade detection mechanisms highlights the importance of defense-in-depth which tries to monitor and flag indicators of compromise on multiple layers of the environment.
  • While wazuh-logtest is useful for verifying decoders and individual rules, frequency-based correlation rules are best validated with real log events generated with realistic attack simulations.
VI. Next Steps
  • Implement a host-based detection by deploying Wazuh agents with sysmon or auditd.
  • Explore Wazuh active response and other capabilities.
References