active response id

[никита какдела]

Hello, the Wazuh development team. I've been struggling with this problem for over two weeks, and here are the tests I've been able to run. I did the raw_input logging received from active response triggers and what I saw was that the id field is not unique, several events may have a unique id. I'm attaching an example: [notify_universal 2026-06-15 18:13:58] RAW_INPUT: {"version": 1, "origin": {"name": "worker02-node", "module": "wazuh-execd"}, "command": "add", "parameters": {"extra_args": [], "alert": {"timestamp": "2026-06-15T18:13:58.776+0000", "rule": {"level": 7, "description": "Suricata: GPL SCAN PING NMAP", "id": "100500", "firedtimes": 7, "mail": false, "groups": ["ids", "suricata", "suricata_alerts"]}, "agent": {"id": "193", "name": "sensor-fest14", "ip": "10.70.0.153"}, "manager": {"name": "wzhcl2-msk01"}, "id": "1781547238.4438233857", "cluster": {"name": "wazuh", "node": "worker02-node"}, "full_log": "{\"timestamp\":\"2026-06-15T18:13:57.983629+0000\",\"flow_id\":682380392508006,\"in_iface\":\"ens18\",\"event_type\":\"alert\",\"src_ip\":\"10.70.0.153\",\"dest_ip\":\"10.115.21.179\",\"proto\":\"ICMP\",\"ip_v\":4,\"icmp_type\":8,\"icmp_code\":0,\"pkt_src\":\"wire/pcap\",\"alert\":{\"action\":\"allowed\",\"gid\":1,\"signature_id\":2100469,\"rev\":4,\"signature\":\"GPL SCAN PING NMAP\",\"category\":\"Attempted Information Leak\",\"severity\":2,\"metadata\":{\"created_at\":[\"2010_09_23\"],\"signature_severity\":[\"Informational\"],\"updated_at\":[\"2019_07_26\"]}},\"direction\":\"to_server\",\"flow\":{\"pkts_toserver\":2,\"pkts_toclient\":1,\"bytes_toserver\":84,\"bytes_toclient\":60,\"start\":\"2026-06-15T18:09:54.617631+0000\",\"src_ip\":\"10.70.0.153\",\"dest_ip\":\"10.115.21.179\"},\"stream\":0}", "decoder": {"name": "json"}, "data": {"timestamp": "2026-06-15T18:13:57.983629+0000", "flow_id": "682380392508006.000000", "in_iface": "ens18", "event_type": "alert", "src_ip": "10.70.0.153", "dest_ip": "10.115.21.179", "proto": "ICMP", "ip_v": "4", "icmp_type": "8", "icmp_code": "0", "pkt_src": "wire/pcap", "alert": {"action": "allowed", "gid": "1", "signature_id": "2100469", "rev": "4", "signature": "GPL SCAN PING NMAP", "category": "Attempted Information Leak", "severity": "2", "metadata": {"created_at": ["2010_09_23"], "signature_severity": ["Informational"], "updated_at": ["2019_07_26"]}}, "direction": "to_server", "flow": {"pkts_toserver": "2", "pkts_toclient": "1", "bytes_toserver": "84", "bytes_toclient": "60", "start": "2026-06-15T18:09:54.617631+0000", "src_ip": "10.70.0.153", "dest_ip": "10.115.21.179"}, "stream": "0"}, "location": "/home/utpot/tpotce/data/suricata/log/eve.json"}, "program": "active-response/bin/notify_universal.py"}}
[notify_universal 2026-06-15 18:13:58] START rule=100500 channel=suricata agent=sensor-fest14
[notify_universal 2026-06-15 18:14:06] ES suricata found: https://wazuh.ovp.ru/app/discover#/doc/wazuh-alerts-*/wazuh-alerts-4.x-2026.06.15?id=OuZ9zJ4BXECuJ4cklQbi
[notify_universal 2026-06-15 18:14:06] Ingest HTTP 200 incident_id=91c3f43c-2a0e-4bf2-9304-85f2756c093c
[notify_universal 2026-06-15 18:14:06] Webhook HTTP 200
[notify_universal 2026-06-15 18:14:06] DONE rule=100500 channel=suricata bucket=10.70.0.153 incident=https://rsyslogcollector.ovp.ru/incidents/91c3f43c-2a0e-4bf2-9304-85f2756c093c ok=True
[notify_universal 2026-06-15 18:14:06] RAW_INPUT: {"version": 1, "origin": {"name": "worker02-node", "module": "wazuh-execd"}, "command": "add", "parameters": {"extra_args": [], "alert": {"timestamp": "2026-06-15T18:13:58.780+0000", "rule": {"level": 7, "description": "Suricata: ET SCAN NMAP -sS window 1024", "id": "100500", "firedtimes": 9, "mail": false, "groups": ["ids", "suricata", "suricata_alerts"]}, "agent": {"id": "193", "name": "sensor-fest14", "ip": "10.70.0.153"}, "manager": {"name": "wzhcl2-msk01"}, "id": "1781547238.4438233857", "cluster": {"name": "wazuh", "node": "worker02-node"}, "full_log": "{\"timestamp\":\"2026-06-15T18:13:57.983654+0000\",\"flow_id\":1410016081158187,\"in_iface\":\"ens18\",\"event_type\":\"alert\",\"src_ip\":\"10.70.0.153\",\"src_port\":35511,\"dest_ip\":\"10.115.21.179\",\"dest_port\":443,\"proto\":\"TCP\",\"ip_v\":4,\"pkt_src\":\"wire/pcap\",\"alert\":{\"action\":\"allowed\",\"gid\":1,\"signature_id\":2009582,\"rev\":3,\"signature\":\"ET SCAN NMAP -sS window 1024\",\"category\":\"Attempted Information Leak\",\"severity\":2,\"metadata\":{\"confidence\":[\"Low\"],\"created_at\":[\"2010_07_30\"],\"signature_severity\":[\"Informational\"],\"updated_at\":[\"2019_07_26\"]}},\"direction\":\"to_server\",\"flow\":{\"pkts_toserver\":1,\"pkts_toclient\":0,\"bytes_toserver\":58,\"bytes_toclient\":0,\"start\":\"2026-06-15T18:13:57.983654+0000\",\"src_ip\":\"10.70.0.153\",\"dest_ip\":\"10.115.21.179\",\"src_port\":35511,\"dest_port\":443},\"stream\":0}", "decoder": {"name": "json"}, "data": {"timestamp": "2026-06-15T18:13:57.983654+0000", "flow_id": "1410016081158187.000000", "in_iface": "ens18", "event_type": "alert", "src_ip": "10.70.0.153", "src_port": "35511", "dest_ip": "10.115.21.179", "dest_port": "443", "proto": "TCP", "ip_v": "4", "pkt_src": "wire/pcap", "alert": {"action": "allowed", "gid": "1", "signature_id": "2009582", "rev": "3", "signature": "ET SCAN NMAP -sS window 1024", "category": "Attempted Information Leak", "severity": "2", "metadata": {"confidence": ["Low"], "created_at": ["2010_07_30"], "signature_severity": ["Informational"], "updated_at": ["2019_07_26"]}}, "direction": "to_server", "flow": {"pkts_toserver": "1", "pkts_toclient": "0", "bytes_toserver": "58", "bytes_toclient": "0", "start": "2026-06-15T18:13:57.983654+0000", "src_ip": "10.70.0.153", "dest_ip": "10.115.21.179", "src_port": "35511", "dest_port": "443"}, "stream": "0"}, "location": "/home/utpot/tpotce/data/suricata/log/eve.json"}, "program": "active-response/bin/notify_universal.py"}}
[notify_universal 2026-06-15 18:14:06] START rule=100500 channel=suricata agent=sensor-fest14
[notify_universal 2026-06-15 18:14:09] ES suricata found: https://wazuh.ovp.ru/app/discover#/doc/wazuh-alerts-*/wazuh-alerts-4.x-2026.06.15?id=OuZ9zJ4BXECuJ4cklQbi
[notify_universal 2026-06-15 18:14:09] Ingest HTTP 200 incident_id=20285c51-0845-4745-a62a-669640ca3685
[notify_universal 2026-06-15 18:14:09] Webhook HTTP 200
[notify_universal 2026-06-15 18:14:09] DONE rule=100500 channel=suricata bucket=10.70.0.153 incident=https://rsyslogcollector.ovp.ru/incidents/20285c51-0845-4745-a62a-669640ca3685 ok=True

Next, only one document (the last one) gets into opensearch by this id and gets its own unique _id:

{ "_index": "wazuh-alerts-4.x-2026.06.15", "_id": "OuZ9zJ4BXECuJ4cklQbi", "_version": 1, "_score": null, "_source": { "cluster": { "node": "worker02-node", "name": "wazuh" }, "input": { "type": "log" }, "agent": { "ip": "10.70.0.153", "name": "host1", "id": "193" }, "manager": { "name": "worker02" }, "data": { "ip_v": "4", "in_iface": "ens18", "src_ip": "1.1.1.1", "src_port": "35511", "event_type": "alert", "alert": { "severity": "2", "signature_id": "2009582", "rev": "3", "metadata": { "updated_at": [ "2019_07_26" ], "confidence": [ "Low" ], "created_at": [ "2010_07_30" ], "signature_severity": [ "Informational" ] }, "gid": "1", "signature": "ET SCAN NMAP -sS window 1024", "action": "allowed", "category": "Attempted Information Leak" }, "stream": "0", "flow_id": "1410016081158187.000000", "dest_ip": "2.2.2.2", "proto": "TCP", "dest_port": "443", "pkt_src": "wire/pcap", "flow": { "src_ip": "1.1.1.1", "src_port": "35511", "pkts_toserver": "1", "dest_ip": "2.2.2.2", "start": "2026-06-15T18:13:57.983654+0000", "bytes_toclient": "0", "bytes_toserver": "58", "pkts_toclient": "0", "dest_port": "443" }, "timestamp": "2026-06-15T18:13:57.983654+0000", "direction": "to_server" }, "rule": { "firedtimes": 9, "mail": false, "level": 7, "description": "Suricata: ET SCAN NMAP -sS window 1024", "groups": [ "ids", "suricata", "suricata_alerts" ], "id": "100500" }, "location": "", "decoder": { "name": "json" }, "id": "1781547238.4438233857", "full_log": "{\"timestamp\":\"2026-06-15T18:13:57.983654+0000\",\"flow_id\":1410016081158187,\"in_iface\":\"ens18\",\"event_type\":\"alert\",\"src_ip\":\"1.1.1.1\",\"src_port\":35511,\"dest_ip\":\"10.115.21.179\",\"dest_port\":443,\"proto\":\"TCP\",\"ip_v\":4,\"pkt_src\":\"wire/pcap\",\"alert\":{\"action\":\"allowed\",\"gid\":1,\"signature_id\":2009582,\"rev\":3,\"signature\":\"ET SCAN NMAP -sS window 1024\",\"category\":\"Attempted Information Leak\",\"severity\":2,\"metadata\":{\"confidence\":[\"Low\"],\"created_at\":[\"2010_07_30\"],\"signature_severity\":[\"Informational\"],\"updated_at\":[\"2019_07_26\"]}},\"direction\":\"to_server\",\"flow\":{\"pkts_toserver\":1,\"pkts_toclient\":0,\"bytes_toserver\":58,\"bytes_toclient\":0,\"start\":\"2026-06-15T18:13:57.983654+0000\",\"src_ip\":\"10.70.0.153\",\"dest_ip\":\"10.115.21.179\",\"src_port\":35511,\"dest_port\":443},\"stream\":0}", "timestamp": "2026-06-15T18:13:58.780+0000" }, "fields": { "timestamp": [ "2026-06-15T18:13:58.780Z" ], "data.timestamp": [ "2026-06-15T18:13:57.983Z" ] }, "highlight": { "id": [ "@opensearch-dashboar...@1781547238.4438233857@/opensearch-dashboards-highlighted-field@" ] }, "sort": [ 1781547238780 ] }  
And the problem is that I can't get the _id (to generate a link to the document) by the id received in active-response. The field is not unique. Can you tell me if this is a bug/feature? Or am I misunderstanding the mechanism of operation? What's the matter?

I will also attach a custom script file.

среда, 3 июня 2026 г. в 19:13:04 UTC+3, Eli Josue Rodriguez:

[Olamilekan Abdullateef Ajani]

Hello,

Thank you for the breakdown.

A little clarification here is that the Wazuh alert ID and the OpenSearch document _id are different fields. The _id is generated by OpenSearch during indexing, so it is not expected to match the Wazuh id.

One other thing, could you check whether the duplicate ID is already present in the manager logs before indexing?

/var/ossec/logs/alerts/alerts.json
/var/ossec/logs/archives/archives.json (if enabled)

If those files show two different alerts with the same id, then the issue originates before the events reach the indexer.

Regarding the script, to locate the indexed document, can you use a combination of fields that uniquely identify the event to search, for example:

agent.id
rule.id
timestamp
data.flow_id (for Suricata events)

Once you retrieve the matching document, you can use the returned OpenSearch _id to build the Discover URL.

Can you also share the following:

Your exact Wazuh version.
Whether this only happens with Suricata alerts or with other log sources as well.
Whether the duplicate id is already present in alerts.json.

That will help determine whether this is an issue with alert generation or just with how the document is being looked up.

Please let me know what you find

[никита какдела]

Hello, team. I'll try to explain again: I understand perfectly well that OpenSearch _id and Wazuh Alert ID are completely different fields. Now, I'm saying that Suricata or Windows Event Channel events (and many others) can have the same Wazuh Alert ID if they are triggered simultaneously or quickly. This is the issue that prevents accurate identification of OpenSearch _ID using Wazuh Alert ID. If two events have the same Wazuh Alert ID, only the last one will be included in alerts.json. The second point is that I'm currently using various combinations, such as agent.id, rule.id, and timestamp. However, this should not be the case. If a document has a Wazuh Alert ID, I should be able to retrieve the same document in OpenSearch. However, I'm getting a completely different document in OpenSearch with the same Wazuh Alert ID, which is simply triggered nearby. When you have 200 to 300 agents, there are many events, and each event should have a "UNIQUE" wazuh alert id. Wazuh version v 4.14.5.

понедельник, 29 июня 2026 г. в 17:22:56 UTC+3, Olamilekan Abdullateef Ajani:

[Olamilekan Abdullateef Ajani]

Hello,

Thank you for the detailed explanation and for taking the time to collect all the evidence. It makes your concern much clearer.

Looking through the RAW_INPUT logs again, I understand your point now. This isn't about the difference between the Wazuh alert id and the OpenSearch _id. The thing is that two different events, only a few milliseconds apart, were assigned the same Wazuh alert ID (1781547238.4438233857).

I think the next step would be to reproduce this behavior in another environment to confirm whether it is expected or whether there is an issue with how the alert ID is being generated or handled before indexing.

In the meantime, give me some time, and I will reproduce this and confirm the behavior, then let you know if we need to escalate this internally.

Thank you again for clarifying the scenario and the report. It helped explain what you are seeing much better.