No alerts for http status code 200 #28637
-
|
This is a very similar question to #15910 My goal to to create an alert, when a user accesses a special URL. To test my configuration, I created a custom decoder for my nginx-proxy-manager: I also added some rules for testing: A logtest for the given logentry gives my the following output: So in theory I am happy with the result. But in the threathunting events I can only see http_status_code 400 events, although from the logtest there should be matches for rule 100203: I cannot explain this to myself. So maybe someone can help me with that, as I think adding a filter for the URL, I want to alert on, is the easier part. Thank you for helping me, as I am new to wazuh :-) |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 6 replies
-
|
Hello meimi039, Let me understand your problem. Are you wondering why you don't receive alerts other than the one with ID 100200 and code 400? Having tested your custom rules with "wazuh-logtest" tool successfully. Now you can check if the expected log events are reaching the Wazuh manager in the working environment. To check all data that is collected by the manager you can set the parameter "logall" and "logall_json" to "yes" on the configuration file "ossec.conf" on the wazuh-manager. After setting these parameters, please restart the wazuh-manager. With these parameters set to "yes", the manager will start to log all events received from agents even if they don't trip a rule. At this point, you can verify if the manager is receiving the expected event logs. If not, there is another issue that is not related to the custom decoders or rules you have created. Regards |
Beta Was this translation helpful? Give feedback.
-
|
Hi Matias! Thanks for the reply. I set logall to yes and found lines of the following pattern: So the manager receives the logs of the agent. But still missing the alerts in the webui, even though the logtest states "**Alert to be generated." --- Off-Topic --- I also send traefik-logs from an other agent to wazuh. They look like this in I added a rule like so: Logtest shows in that case: So even though this example is a 404 entry, the 200 OK entries show up in the webui for my traefik logs: --- End-Off-Topic --- So as the traefik logs do work as expected, I cannot figure out, why the NPM logs behave differently except for the difference in the log-formats (json/syslog). Maybe someone has a working example for NPM or a fresh start, as I am in the beginning of configuring wazuh :-) |
Beta Was this translation helpful? Give feedback.
-
|
Hi meimi039, To get the event log information is convenient to use the events found in the "archives.json" file instead of the "archives.log". The log you are looking for will be inside a JSON object in the file "archives.json" in key "full_log": This is because sometimes there are differences between the message of "archives.json" and "archives.log". Once you have the event log from the "archives.json" file, we have to test it again in the wazuh-logtest tool. Regards |
Beta Was this translation helpful? Give feedback.
-
|
Hi matias! Thanks for digging deeper. In the archives.json I found entries, like this one: {
"timestamp": "2025-03-17T16:00:40.556-0400",
"rule": {
"level": 3,
"description": "Successful request (200)",
"id": "100203",
"firedtimes": 32,
"mail": false,
"groups": [
"npm",
"accesslogs",
"success"
]
},
"agent": {
"id": "001",
"name": "webdocker",
"ip": "192.168.311.381"
},
"manager": {
"name": "wazuh"
},
"id": "1742241640.65373154",
"full_log": "[17/Mar/2025:20:00:39 +0000] - 200 200 - GET https blog.my-site.de \"/content/images/thumbnail/photo-1552826580-0d47cf898dee\" [Client 192.9.377.249] [Length 667819] [Gzip -] [Sent-to ghost] \"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36\" \"https://blog.my-site.de/normal_url/\"",
"decoder": {
"name": "npm-accesslogs"
},
"data": {
"url": "blog.my-site.de",
"timestamp": "17/Mar/2025:20:00:39 +0000",
"http_status_code": "200",
"secondary_status_code": "200",
"http_method": "GET",
"request_uri": "\"/content/images/thumbnail/photo-1552826580-0d47cf898dee\"",
"client_ip": "192.9.377.249",
"content_length": "667819",
"gzip": "-",
"sent_to": "ghost",
"http_useragent": "\"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36\"",
"http_referer": "\"https://blog.my-site.de/normal_url/\""
},
"location": "/var/docker/web/nginx-proxy-manager/data/logs/proxy-host-19_access.log"
}In the logtest, I see this after replacing the \" by single ": |
Beta Was this translation helpful? Give feedback.
-
|
Hi, In the records of the file "archive.json", if an event triggers a rule you can see the key "rule" with the data related to the triggered rule. In the case you have shared, both the "rule" and the "decoder" keys are present and have the expected information. Have you tried in the dashboard to only filter using the rule.id = 100203? |
Beta Was this translation helpful? Give feedback.
-
|
Hi matias! That is exaclty what I dont understand. It looks all good in the console, but in the dashboard no alerts match the rule 100203: I cannot figure out what I am missing here. I temporarily set the alert-level to 12 just to make the alert more urgent. But that didnt work out. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, |
Beta Was this translation helpful? Give feedback.
-
|
Hi again, The alert information in the record of the file "archives.json" that you have for the rule id 100203 does not mean that the alert was correctly indexed. One possibility is that there exists indexing issues for these alerts (for example: one invalid field n 8000 ame, etc). First, we can check if these alerts are being indexed. Please share your results. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I could reproduce the problem on my local machine with the information you sent me previously. There are issues indexing these event logs. The problem is the field named "timestamp" in your custom decoder. A workaround for this situation could be:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Matias! You are just awesome! That was the right thing to look at. Thank you so much. I think I can make it from here. Best regards Michael |
Beta Wa 8000 s this translation helpful? Give feedback.
Hi,
I could reproduce the problem on my local machine with the information you sent me previously.
There are issues indexing these event logs. The problem is the field named "timestamp" in your custom decoder.
The format of this field is not the expected, the format used is ISO 8601 (YYYY-MM-DDTHH:MM:SSZ). In future Wazuh version 5.x the timestamp fields format will be configurable.
A workaround for this situation could be: