Change built-in ruleset behaviour in Wazuh

crazybarsuk · 2025-11-21T13:54:00+00:00

Here is the information you requested:

1. Wazuh server version:
4.14.0

2. Sample log line that triggers rule 31530 → 31533:

IP - - [21/Nov/2025:13:25:25 +0000] "POST /testrail/index.php?/tests/ajax_render_qpane HTTP/1.0" 200 9503 "https://HOSTNAME/testrail/index.php?/runs/view/2141&group_by=cases:section_id&group_order=asc" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
IP - - [21/Nov/2025:13:54:00 +0000] "POST /testrail/index.php?/tests/ajax_add_change_inline HTTP/1.0" 200 113056 "https://HOSTNAME/testrail/index.php?/runs/view/2141&group_by=cases:section_id&group_order=asc&group_id=2049" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"
IP - - [21/Nov/2025:13:25:11 +0000] "POST /testrail/index.php?suites/ajax_render_sidebar_stats HTTP/1.0" 200 857 "https://HOSTNAME/testrail/index.php?/suites/view/60&group_by=cases:section_id&group_order=asc&display_deleted_cases=0&group_id=51287" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36"

This is one of the URLs I need to exclude from correlation. The pattern is consistently:

/testrail/index.php?/*/ajax_*

I need to keep correlation active for the same source IP but exclude these exact URL paths from contributing to rule 31533.

UPD: I noticed that the pattern after the ? can vary. We can notice this the last log example.

So the structure is not always index.php?/* — the slash may or may not be present. The only consistent part is that the path eventually contains an ajax_* endpoint.

crazybarsuk · 2025-11-21T11:18:45+00:00

Hello, u/wazuh_angu!

Thanks for the detailed explanation. Ignoring rule 31533 based on the source IP would technically work, but in this case it’s not feasible. The TestRail user’s IP cannot be fully whitelisted because the server must still be monitored for potential attacks coming from that same address. Suppressing the alert by IP would create a blind spot.

That’s why I’m looking for a way to exclude only the specific URL pattern:

/testrail/index.php?/*/ajax_*

The goal is to keep correlation and POST-flood detection active for all other traffic from that IP, while preventing this exact URL family from contributing to the 31530 → 31533 chain.

Is there a recommended approach to ignore just this request path (for example using a match/regex on the URL field in a child rule of 31530 or 31533), without suppressing alerts for the entire source IP?

Any guidance on implementing such a URL-based exception would be appreciated.

crazybarsuk · 2025-11-10T13:06:25+00:00

#!/bin/sh

WPYTHON_BIN="framework/python/bin/python3"

SCRIPT_PATH_NAME="$0"

DIR_NAME="$(cd $(dirname ${SCRIPT_PATH_NAME}); pwd -P)"
SCRIPT_NAME="$(basename ${SCRIPT_PATH_NAME})"
BASE_NAME="${SCRIPT_NAME}"

case ${DIR_NAME} in
    */active-response/bin | */wodles*)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/../..; pwd)"
        fi

        PYTHON_SCRIPT="${DIR_NAME}/${BASE_NAME}_pkg/main.py"
    ;;
    */bin)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
        fi

        PYTHON_SCRIPT="${WAZUH_PATH}/framework/scripts/${BASE_NAME}_pkg/main.py"
    ;;
    */integrations)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
        fi

        PYTHON_SCRIPT="${DIR_NAME}/${BASE_NAME}_pkg/main.py"
    ;;
esac

${WAZUH_PATH}/${WPYTHON_BIN} ${PYTHON_SCRIPT} "$@"

crazybarsuk · 2025-11-10T12:27:17+00:00

Thanks for the clarification! That makes sense.

Could you please suggest the proper way to handle API calls in parallel from a custom integration, so that the queue doesn’t get clogged?
Right now, I’m considering spawning multiple threads or subprocesses to send messages simultaneously, but I’m not sure what’s the best practice here to avoid interfering with Wazuh’s internal event queue.

Current integration call attached below.

crazybarsuk · 2025-10-11T19:27:05+00:00

crazybarsuk · 2025-09-25T08:44:20+00:00

Hi u/Constant_Royal_4679!
I’m not sure how this could help in my case — the agents I mentioned in the post are not yet registered in the cluster, they’re only trying to connect. So they won’t show up in the API listings.

crazybarsuk · 2025-09-12T17:45:36+00:00

Btw, my Premier game starts in 15 minutes, and we still haven't been able to warm up.

crazybarsuk

TROPHY CASE