Dev.to Security πŸ” Cybersecurity πŸ‘ 0 πŸ“– 3 min read

Wazuh snort decoder cuts the last octet off srcip and dstip (4.14.x)

If a snort alert has no source port, Wazuh 4.14.x stores srcip without its last octet: 10.4.12.26 becomes 10.4.12. When the destination has a port, the port stays glued to dstip. Anything keyed on those fields, such as a

If a snort alert has no source port, Wazuh 4.14.x stores srcip without its last octet: 10.4.12.26 becomes 10.4.12. When the destination has a port, the port stays glued to dstip. Anything keyed on those fields, such as active response, CDB lists or correlation by IP, then works on the wrong value.

Everything below was measured with wazuh-logtest on wazuh-manager 4.14.9, syslog snort: form only. The problem is tracked upstream as #39989, with a fix in #40521 for 4.14.11.

Check it in one minute

Paste a snort line into wazuh-logtest and read the decoding phase. Take the samples below, without the syslog prefix, starting at the priority. For the first one, {ICMP} 10.4.12.26 -> 10.4.10.231, stock 4.14.9 gives srcip 10.4.12; with the merged fix from #40521, srcip is right but dstip becomes 10.4.10. (with a trailing dot).

Why it happens

Stock is ruleset/decoders/0285-snort_decoders.xml as shipped in 4.14.9. Its snort2 decoder has three regex lines that capture the source and destination addresses, and those are the lines the fix below changes.

We ran eight samples through three decoders: the stock file, the three regex lines from PR #40521 (merged for 4.14.11, not released), and the same lines with one more change, shown below.

Sample (after the priority) Stock 4.14.9 Merged fix With the change below
{ICMP} 10.4.12.26 -> 10.4.10.231 srcip 10.4.12 dstip 10.4.10. both correct
{TCP} 10.4.12.26:37020 -> 10.4.10.231:162 dstip 10.4.10.231:162 correct correct
{UDP} 192.168.20.32 -> 192.168.20.2 srcip 192.168.20 correct correct
{TCP} 10.4.12.26:5000 -> 10.4.10.7 correct correct correct
{UDP} 10.4.12.26 -> 10.4.10.7:53 srcip 10.4.12, dstip 10.4.10.7:53 correct correct
{ICMP} 203.113.100.250 -> 198.51.100.200 srcip 203.113.100 dstip 198.51.100. correct
{TCP} 203.113.100.250:44321 -> 198.51.100.200:443 dstip 198.51.100.200:443 correct correct
[**] multi-line form from the file header no fields no fields no fields

The merged fix still loses the last octet of dstip when there is no destination port and that octet has three digits. We reported that measurement on the PR before 4.14.11 ships: https://github.com/wazuh/wazuh/pull/40521#issuecomment-6343969794 The [**] form is assembled by the snort-full reader across several lines, which a single logtest line does not reproduce, so it is out of scope here.

Fix on 4.14.x today

Copy the stock file and change its three regex lines in the snort2 decoder to:

<regex>^[**] [(\d+:\d+:\d+)] \.+ (\d+.\d+.\d+.\d+)\p*\d* -> </regex>
<regex>(\d+.\d+.\d+.\d+)\p*\d*|^[(\d+:\d+:\d+)] \.+ </regex>
<regex>(\d+.\d+.\d+.\d+)\p*\d* -> (\d+.\d+.\d+.\d+)</regex>

Save it as /var/ossec/etc/decoders/0285-snort_decoders-fixed.xml, owner wazuh:wazuh.

Then, in /var/ossec/etc/ossec.conf, inside the ruleset block, stop the stock file from loading so the two copies do not compete:

<decoder_exclude>ruleset/decoders/0285-snort_decoders.xml</decoder_exclude>

Restart the manager. A new wazuh-logtest session picks the change up without a restart, so you can check first; live analysis needs the restart.

Confirm it worked

Run the same eight lines again and compare with the last column of the table: srcip and dstip should be whole addresses, with the port gone from dstip.

After upgrading to 4.14.11 or later, remove both the local file and the exclude line, and re-run your samples. The shipped decoder may or may not include the dstip change above.

Limits of what we measured

Measured with the logtest engine on 4.14.9, syslog snort: form only. Your snort output may differ (unified2 via barnyard, alert_fast, IPv6), so run your own lines before you rely on it.

Full write-up with the lab output: https://atkvn.com/fix-wazuh-snort-srcip-truncated-last-octet.html

πŸ“° Read the original article on Dev.to Security

Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β€” full credit and traffic to the original publisher.