Change level to rule id only for agent id
1,238 views
Skip to first unread message
Daniel Hinojo
Feb 17, 2021, 4:50:43 PM2/17/21
to Wazuh mailing list
Good morning Dear, I would like to ask you a question, I currently have several false positives such as the following rule id 31530 that I would like to lower from level to 3 or 4 since in that agent with ID number 002 it is a false positive, look in the wazuh documentation and I found how to change it but I can't find how I can specify that this rule only applies to that agent ID since for other agents it is necessary for the rule to remain as is by default. please if you could help me.
I attach the rule id that I would like to change only for that agent ID:
<rule id="100002" level="11" timeframe="20" frequency="8">
<if_matched_sid>31530</if_matched_sid>
<same_source_ip />
<description>High amount of POST requests in a small period of time (likely bot).</description>
<group>pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11,nist_800_53_SI.4,tsc_CC6.6,tsc_CC7.1,tsc_CC8.1,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
jeremias...@wazuh.com
Feb 17, 2021, 10:07:03 PM2/17/21
to Wazuh mailing list
Hi Daniel,
Thank you for using Wazuh!
You can make use of the <location> tag for this.
Location identifies the origin of the input. If the event comes from an agent, its name and registered IP (as it was added) are appended to the location.
Below there is an example of these fields, where dbserver is the agent name and any is the registration IP.
Thank you for using Wazuh!
You can make use of the <location> tag for this.
Location identifies the origin of the input. If the event comes from an agent, its name and registered IP (as it was added) are appended to the location.
Below there is an example of these fields, where dbserver is the agent name and any is the registration IP.
(dbserver) any->/var/log/syslog
You can use it to filter one specific user or any other source of the log.
Please let me know if this helps.
Best regards.
You can use it to filter one specific user or any other source of the log.
Please let me know if this helps.
Best regards.
Daniel Hinojo
Feb 18, 2021, 9:43:42 AM2/18/21
to Wazuh mailing list
Good morning, Thanks for your answer, but I still can't understand how to do it, I was guided by the following link where it indicates how to change rules, but I don't know what field should be placed in that context so that the ID 31530 rule drops to a level but Only the agent ID I specify for example the ID 002 with name "AD20".
Now what I understand is that to the context I must add the path "(dbserver) any -> / var / log / syslog" and if it is agent 002 would I add "(dbserver) 002 -> / var / log / syslog" or something like that?
Please if you could help me. Thanks
jeremias...@wazuh.com
Feb 18, 2021, 8:20:27 PM2/18/21
to Wazuh mailing list
Hi Daniel,
Sorry for not giving you enough information to resolve this. I think we should improve this section of the documentation to explain this feature better.
I understand that you were already able to create a different rule that will trigger with the expected level. But you need a way to only match this rule if the event comes from one specific Agent.
To do this I suggest you to add <location>^(AGENT_NAME) AGENT_IP</location> to your rule. In this way, you will only trigger this rule if the location of the event starts with this string (where AGENT_NAME is the registration name of your agent and AGENT_IP is the registration ip of the agent (can be any)).
i.e.: The below example will only trigger your rule if it comes from an agent registered as ubuntu_agent with IP any
On the other hand, you can avoid triggering a rule at all with the same location logic using the negated option. The below example will trigger the same rule for every agent except for the one that matches ubuntu_agent name and any IP. This can be useful if you want to competely ignore a rule for an the agent.
Sorry for not giving you enough information to resolve this. I think we should improve this section of the documentation to explain this feature better.
I understand that you were already able to create a different rule that will trigger with the expected level. But you need a way to only match this rule if the event comes from one specific Agent.
To do this I suggest you to add <location>^(AGENT_NAME) AGENT_IP</location> to your rule. In this way, you will only trigger this rule if the location of the event starts with this string (where AGENT_NAME is the registration name of your agent and AGENT_IP is the registration ip of the agent (can be any)).
i.e.: The below example will only trigger your rule if it comes from an agent registered as ubuntu_agent with IP any
<rule id="100002" level="11" timeframe="20" frequency="8">
<if_matched_sid>31530</if_matched_sid>
<location>^(ubuntu_agent) any</location>
<same_source_ip />
<description>High amount of POST requests in a small period of time (likely bot).</description>
<group>pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11,nist_800_53_SI.4,tsc_CC6.6,tsc_CC7.1,tsc_CC8.1,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
On the other hand, you can avoid triggering a rule at all with the same location logic using the negated option. The below example will trigger the same rule for every agent except for the one that matches ubuntu_agent name and any IP. This can be useful if you want to competely ignore a rule for an the agent.
<rule id="100002" level="11" timeframe="20" frequency="8">
<if_matched_sid>31530</if_matched_sid>
<location negate="yes">^(ubuntu_agent) any</location>
<same_source_ip />
<description>High amount of POST requests in a small period of time (likely bot).</description>
<group>pci_dss_6.5,pci_dss_11.4,gdpr_IV_35.7.d,nist_800_53_SA.11,nist_800_53_SI.4,tsc_CC6.6,tsc_CC7.1,tsc_CC8.1,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
Please let me know if this helps. If you have further doubts, please don't hesitate to ask.
Best regards.
Best regards.
Daniel Hinojo
Feb 22, 2021, 1:05:49 PM2/22/21
to Wazuh mailing list
Thank you very much Jeremias seems to have worked and I am testing it with other rules.
I would like to make one more query, I currently have the ID 20007 Windows Logon Success rule that shows me the users who were able to log in to the computer successfully and from which computer I have an IP address, for example if I have 3 users (user1, user2, user3) and only user1 must log in to that computer as I can create a rule to alert me at level 10 if a user other than user1 successfully logs in to the TEST01 agent. Please if you could help me. Thanks I attach the rule <rule id = "20007" level = "3"> <if_sid> 20004 </if_sid> <field name = "win.system.eventID"> ^ 528 $ | ^ 540 $ | ^ 673 $ | ^ 4624 $ | ^ 4769 $ </field> <description> Windows Logon Success </description> <options> no_full_log </options> <group> authentication_success, pci_dss_10.2.5, gpg13_7.1, gpg13_7.2, gdpr_IV_32.2, </group> </rule>
Daniel Hinojo
Feb 23, 2021, 1:42:43 PM2/23/21
to Wazuh mailing list
Hi Jeremias, I tried the way you tell me <location negate = "yes"> ^ (ubuntu_agent) any </location> and it doesn't work, keep reporting the alerts please if you could help me.
Also if I wanted for example 2 agents how would the context be?
I attach the rule id model that I use.
NOTE: Regarding the <location> ^ (ubuntu_agent) any </location> if it is working correctly.
<rule id="100002" level="9">
<if_sid>60103</if_sid>
<location negate="yes">^(Agente01) xx.xx.xx.xx</location>
<field name="win.system.eventID">^528$|^540$|^673$|^4624$|^4769$</field>
<description>Windows Logon Success</description>
<options>no_full_log</options>
<mitre>
<id>T1078</id>
</mitre>
<group>authentication_success,pci_dss_10.2.5,gpg13_7.1,gpg13_7.2,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
jeremias...@wazuh.com
Feb 24, 2021, 10:37:05 AM2/24/21
to Wazuh mailing list
Hi Daniel.
Glad to hear the other rule worked fine.
Regarding this login rule:
The first thing we should do is check if the event is truly being received by the manager. To do this, we need to enable logall option on the manager ossec.conf and check into /var/ossec/logs/archives/archives.log if the logon event is being received. (Remember to disable it after the test to avoid unnecessary disk usage)
After that, using the log on archives.log, I suggest you test the rule with /var/ossec/bin/wazuh-logtest (/var/ossec/bin/ossec-logtest in older Wazuh versions) link. At the moment, <location> tag isn't supported but we are working to include it. Thus, the only way to test the rule is to remove the <location> tag and check if the rule works as expected, after that test it in a normal scenario with the tag included again.
It's very probable that your rule isn't working as expected because rule 60106 is triggering first.
Once you have enabled the logall option, if the event is being received, can you share with me the event log (as it is in archives.log) so I can perform some tests based on this event?
Let me know how this test goes and if you have the event.
If you have any doubt please don't hesitate to ask.
Best regards.
Glad to hear the other rule worked fine.
Regarding this login rule:
The first thing we should do is check if the event is truly being received by the manager. To do this, we need to enable logall option on the manager ossec.conf and check into /var/ossec/logs/archives/archives.log if the logon event is being received. (Remember to disable it after the test to avoid unnecessary disk usage)
After that, using the log on archives.log, I suggest you test the rule with /var/ossec/bin/wazuh-logtest (/var/ossec/bin/ossec-logtest in older Wazuh versions) link. At the moment, <location> tag isn't supported but we are working to include it. Thus, the only way to test the rule is to remove the <location> tag and check if the rule works as expected, after that test it in a normal scenario with the tag included again.
It's very probable that your rule isn't working as expected because rule 60106 is triggering first.
Once you have enabled the logall option, if the event is being received, can you share with me the event log (as it is in archives.log) so I can perform some tests based on this event?
Let me know how this test goes and if you have the event.
If you have any doubt please don't hesitate to ask.
Best regards.
Daniel Hinojo
Feb 24, 2021, 3:22:38 PM2/24/21
to Wazuh mailing list
Good afternoon Jeremias, I already lost it, sorry lol, I don't know which of the 2 doubts I have is referring to, I detail the following:
1) Hi Jeremias, I tried the way you tell me <location negate = "yes"> ^ (ubuntu_agent) any </location> and it doesn't work, keep reporting the alerts please if you could help me. Also if I wanted for example 2 agents how would the context be? I attach the rule id model that I use.
2) I would like to make one more query, I currently have the ID 20007 Windows Logon Success rule that shows me the users who were able to log in to the computer successfully and from which computer I have an IP address, for example if I have 3 users (user1, user2, user3) and only user1 must log in to that computer as I can create a rule to alert me at level 10 if a user other than user1 successfully logs in to the TEST01 agent. Please if you could help me. Thanks I attach the rule <rule id = "20007" level = "3"> <if_sid> 20004 </if_sid> <field name = "win.system.eventID"> ^ 528 $ | ^ 540 $ | ^ 673 $ | ^ 4624 $ | ^ 4769 $ </field> <description> Windows Logon Success </description> <options> no_full_log </options> <group> authentication_success, pci_dss_10.2.5, gpg13_7.1, gpg13_7.2, gdpr_IV_32.2, </group> </rule>
jeremias...@wazuh.com
Feb 24, 2021, 8:25:41 PM2/24/21
to Wazuh mailing list
Hi Daniel,
As you said "Thank you very much Jeremias seems to have worked and I am testing it with other rules." I understood that your first query was solved. Sorry.
-Regarding your doubt #1) You were able to create a rule using the <location> tag and trigger it as expected, but now you have problems with the negate="yes" option. Is this correct?
I think we should work with the events collected in /var/ossec/logs/archives/archives.log enabling logall config to know why is this rule not working now. Can you enable this option and share with me the exact event that you expect to trigger the rule?
If you want this rule to match multiple agents you can use a regular expression that matches both cases, i.e.:
<location negate = "yes"> ^ (ubuntu_agent1) any| ^ (ubuntu_agent2) any </location>
-Regarding your doubt#2) Your rule 20007 is a copy of 60106, but <field name = "win.system.eventID"> content has extra white spaces, is this intentional? This probably will lead to problems.
Besides this, Your approach of using the authentication_success group is correct. And you can use a rule like
<rule id="140101" level="12">
<if_group>authentication_success</if_group>
Please let me know if this helps.
As you said "Thank you very much Jeremias seems to have worked and I am testing it with other rules." I understood that your first query was solved. Sorry.
-Regarding your doubt #1) You were able to create a rule using the <location> tag and trigger it as expected, but now you have problems with the negate="yes" option. Is this correct?
I think we should work with the events collected in /var/ossec/logs/archives/archives.log enabling logall config to know why is this rule not working now. Can you enable this option and share with me the exact event that you expect to trigger the rule?
If you want this rule to match multiple agents you can use a regular expression that matches both cases, i.e.:
<location negate = "yes"> ^ (ubuntu_agent1) any| ^ (ubuntu_agent2) any </location>
-Regarding your doubt#2) Your rule 20007 is a copy of 60106, but <field name = "win.system.eventID"> content has extra white spaces, is this intentional? This probably will lead to problems.
Besides this, Your approach of using the authentication_success group is correct. And you can use a rule like
<rule id="140101" level="12">
<if_group>authentication_success</if_group>
<user negate="yes">test_user</user>
<description>Unexpected user successfully logged to the system.</description>
</rule>
To trigger each time an user different than test_user log into this computer. This is an example from the documentation page. Observe that the negate option is used the same as in our previous examples.
Another more specific option is to use the field sections to match specific windows events. Check this example explained in this link
<rule id="100098" level="12">
Another more specific option is to use the field sections to match specific windows events. Check this example explained in this link
<rule id="100098" level="12">
<if_sid>60118</if_sid>
<field name="win.eventdata.targetUserName" negate="yes">^test_user$</field>
<description>test_user log in</description>
</rule>
Observe that the original example doesn't have the negate option, you can check which options are valid in this section of the documentation
If you have problems with these rules, I suggest you enable the logall option to check if the event is being received and see exactly how the events are written. If you provide us with the event you want to match, it will let us investigate any possible problem with the rule to help you develop it.
On the other hand, you can test the rules using /var/ossec/bin/wazuh-logtest (/var/ossec/bin/ossec-logtest in older Wazuh versions) link.
Observe that the original example doesn't have the negate option, you can check which options are valid in this section of the documentation
If you have problems with these rules, I suggest you enable the logall option to check if the event is being received and see exactly how the events are written. If you provide us with the event you want to match, it will let us investigate any possible problem with the rule to help you develop it.
On the other hand, you can test the rules using /var/ossec/bin/wazuh-logtest (/var/ossec/bin/ossec-logtest in older Wazuh versions) link.
Please let me know if this helps.
If you have further doubts please don't hesitate to ask.
Daniel Hinojo
Feb 28, 2021, 6:02:04 PM2/28/21
to Wazuh mailing list
Good evening Jeremiah thank you very much for your support, I was able to solve this problem by updating my Wazuh to version 4.1 and the agents as well.
Also try other commands like <hostname> </hostname> and it works wonders too.
jeremias...@wazuh.com
Mar 1, 2021, 7:31:10 AM3/1/21
to Wazuh mailing list
Hi Daniel.
Glad to hear it worked!
Best regards.
Glad to hear it worked!
Best regards.
Daniel Hinojo
Mar 2, 2021, 7:52:34 PM3/2/21
to Wazuh mailing list
Good morning Jeremias,
I was testing what I do with other Rule IDs and it doesn't work, for example, I have multiple false positives of rule id 61061 from an agent and I wanted to change its level only from that agent using <location> and it doesn't work, it keeps showing multiple alerts from That type, what I have noticed is that possibly this rule id is associated with others since it does not make reference to any eventid and possibly I would have to place other things in the rule or not. Please if you could help me. Below I detail what is done and I also attach the json of the event
Rule ID 61061 :
<rule id="61061" level="10" frequency="$MS_FREQ" timeframe="240">
<if_matched_sid>60602</if_matched_sid>
<description>Multiple Windows error Application events</description>
<options>no_full_log</options>
</rule>
Rule change in local_rules.xml:
<rule id="100006" level="1" frequency="8" timeframe="240">
<if_matched_sid>60602</if_matched_sid>
<location>^(agente1) any</location>
<description>Multiple Windows error Application events</description>
<options>no_full_log</options>
</rule>
JSON:
{
"agent": {
"ip": "xxxxxxxxx",
"name": "agente1",
"id": "044"
},
"previous_output": "{\"win\":{\"system\":{\"providerName\":\"Application Error\",\"eventID\":\"1000\",\"level\":\"2\",\"task\":\"100\",\"keywords\":\"0x80000000000000\",\"systemTime\":\"2021-03-03T00:43:29.144146100Z\",\"eventRecordID\":\"27569\",\"channel\":\"Application\",\"computer\":\"agente1\",\"severityValue\":\"ERROR\",\"message\":\"\\\"Faulting application name: SolarWinds.Orion.LogMgmt.TrapService.exe, version: 2.2.0.14784, time stamp: 0x5da00feb\\r\\nFaulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6\\r\\nException code: 0xe0434352\\r\\nFault offset: 0x0000000000033c58\\r\\nFaulting process id: 0x924\\r\\nFaulting application start time: 0x01d70fc62cd169e5\\r\\nFaulting application path: C:\\\\Program Files (x86)\\\\SolarWinds\\\\Orion\\\\OLM\\\\SolarWinds.Orion.LogMgmt.TrapService.exe\\r\\nFaulting module path: C:\\\\Windows\\\\System32\\\\KERNELBASE.dll\\r\\nReport Id: b7a0aaa4-3129-4d81-ad2e-609a3a69f117\\r\\nFaulting package full name: \\r\\nFaulting package-relative application ID: \\\"\"},\"eventdata\":{\"data\":\"SolarWinds.Orion.LogMgmt.TrapService.exe, 2.2.0.14784, 5da00feb, KERNELBASE.dll, 10.0.14393.1770, 59bf2ba6, e0434352, 0000000000033c58, 924, 01d70fc62cd169e5, C:\\\\\\\\Program Files (x86)\\\\\\\\SolarWinds\\\\\\\\Orion\\\\\\\\OLM\\\\\\\\SolarWinds.Orion.LogMgmt.TrapService.exe, C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\KERNELBASE.dll, b7a0aaa4-3129-4d81-ad2e-609a3a69f117\"}}}\n{\"win\":{\"system\":{\"providerName\":\"Application Error\",\"eventID\":\"1000\",\"level\":\"2\",\"task\":\"100\",\"keywords\":\"0x80000000000000\",\"systemTime\":\"2021-03-03T00:43:28.706626300Z\",\"eventRecordID\":\"27567\",\"channel\":\"Application\",\"computer\":\"agente1\",\"severityValue\":\"ERROR\",\"message\":\"\\\"Faulting application name: SolarWinds.Orion.LogMgmt.PollingService.exe, version: 2.2.0.14784, time stamp: 0xf87793b1\\r\\nFaulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6\\r\\nException code: 0xe0434352\\r\\nFault offset: 0x0000000000033c58\\r\\nFaulting process id: 0x14e4\\r\\nFaulting application start time: 0x01d70fc62cd63669\\r\\nFaulting application path: C:\\\\Program Files (x86)\\\\SolarWinds\\\\Orion\\\\OLM\\\\SolarWinds.Orion.LogMgmt.PollingService.exe\\r\\nFaulting module path: C:\\\\Windows\\\\System32\\\\KERNELBASE.dll\\r\\nReport Id: 7e1e5b0b-1af0-451a-b0d7-3884a4463834\\r\\nFaulting package full name: \\r\\nFaulting package-relative application ID: \\\"\"},\"eventdata\":{\"data\":\"SolarWinds.Orion.LogMgmt.PollingService.exe, 2.2.0.14784, f87793b1, KERNELBASE.dll, 10.0.14393.1770, 59bf2ba6, e0434352, 0000000000033c58, 14e4, 01d70fc62cd63669, C:\\\\\\\\Program Files (x86)\\\\\\\\SolarWinds\\\\\\\\Orion\\\\\\\\OLM\\\\\\\\SolarWinds.Orion.LogMgmt.PollingService.exe, C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\KERNELBASE.dll, 7e1e5b0b-1af0-451a-b0d7-3884a4463834\"}}}\n{\"win\":{\"system\":{\"providerName\":\"Application Error\",\"eventID\":\"1000\",\"level\":\"2\",\"task\":\"100\",\"keywords\":\"0x80000000000000\",\"systemTime\":\"2021-03-03T00:43:24.831613400Z\",\"eventRecordID\":\"27564\",\"channel\":\"Application\",\"computer\":\"agente1\",\"severityValue\":\"ERROR\",\"message\":\"\\\"Faulting application name: SolarWinds.Orion.LogMgmt.SyslogService.exe, version: 2.2.0.14784, time stamp: 0x5da00ff2\\r\\nFaulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6\\r\\nException code: 0xe0434352\\r\\nFault offset: 0x0000000000033c58\\r\\nFaulting process id: 0x109c\\r\\nFaulting application start time: 0x01d70fc62aaf6b14\\r\\nFaulting application path: C:\\\\Program Files (x86)\\\\SolarWinds\\\\Orion\\\\OLM\\\\SolarWinds.Orion.LogMgmt.SyslogService.exe\\r\\nFaulting module path: C:\\\\Windows\\\\System32\\\\KERNELBASE.dll\\r\\nReport Id: 98a90798-aea0-4e47-a7c8-8b86ae4cd445\\r\\nFaulting package full name: \\r\\nFaulting package-relative application ID: \\\"\"},\"eventdata\":{\"data\":\"SolarWinds.Orion.LogMgmt.SyslogService.exe, 2.2.0.14784, 5da00ff2, KERNELBASE.dll, 10.0.14393.1770, 59bf2ba6, e0434352, 0000000000033c58, 109c, 01d70fc62aaf6b14, C:\\\\\\\\Program Files (x86)\\\\\\\\SolarWinds\\\\\\\\Orion\\\\\\\\OLM\\\\\\\\SolarWinds.Orion.LogMgmt.SyslogService.exe, C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\KERNELBASE.dll, 98a90798-aea0-4e47-a7c8-8b86ae4cd445\"}}}\n{\"win\":{\"system\":{\"providerName\":\"Application Error\",\"eventID\":\"1000\",\"level\":\"2\",\"task\":\"100\",\"keywords\":\"0x80000000000000\",\"systemTime\":\"2021-03-03T00:42:04.955359800Z\",\"eventRecordID\":\"27560\",\"channel\":\"Application\",\"computer\":\"agente1\",\"severityValue\":\"ERROR\",\"message\":\"\\\"Faulting application name: SolarWinds.Orion.LogMgmt.PollingService.exe, version: 2.2.0.14784, time stamp: 0xf87793b1\\r\\nFaulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6\\r\\nException code: 0xe0434352\\r\\nFault offset: 0x0000000000033c58\\r\\nFaulting process id: 0xb3c\\r\\nFaulting application start time: 0x01d70fc5faa40d88\\r\\nFaulting application path: C:\\\\Program Files (x86)\\\\SolarWinds\\\\Orion\\\\OLM\\\\SolarWinds.Orion.LogMgmt.PollingService.exe\\r\\nFaulting module path: C:\\\\Windows\\\\System32\\\\KERNELBASE.dll\\r\\nReport Id: 4b7cf482-f838-408e-9d46-cf74b425c752\\r\\nFaulting package full name: \\r\\nFaulting package-relative application ID: \\\"\"},\"eventdata\":{\"data\":\"SolarWinds.Orion.LogMgmt.PollingService.exe, 2.2.0.14784, f87793b1, KERNELBASE.dll, 10.0.14393.1770, 59bf2ba6, e0434352, 0000000000033c58, b3c, 01d70fc5faa40d88, C:\\\\\\\\Program Files (x86)\\\\\\\\SolarWinds\\\\\\\\Orion\\\\\\\\OLM\\\\\\\\SolarWinds.Orion.LogMgmt.PollingService.exe, C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\KERNELBASE.dll, 4b7cf482-f838-408e-9d46-cf74b425c752\"}}}\n{\"win\":{\"system\":{\"providerName\":\"Application Error\",\"eventID\":\"1000\",\"level\":\"2\",\"task\":\"100\",\"keywords\":\"0x80000000000000\",\"systemTime\":\"2021-03-03T00:42:04.861609300Z\",\"eventRecordID\":\"27559\",\"channel\":\"Application\",\"computer\":\"agente1\",\"severityValue\":\"ERROR\",\"message\":\"\\\"Faulting application name: SolarWinds.Orion.LogMgmt.TrapService.exe, version: 2.2.0.14784, time stamp: 0x5da00feb\\r\\nFaulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6\\r\\nException code: 0xe0434352\\r\\nFault offset: 0x0000000000033c58\\r\\nFaulting process id: 0x1968\\r\\nFaulting application start time: 0x01d70fc5faa40bea\\r\\nFaulting application path: C:\\\\Program Files (x86)\\\\SolarWinds\\\\Orion\\\\OLM\\\\SolarWinds.Orion.LogMgmt.TrapService.exe\\r\\nFaulting module path: C:\\\\Windows\\\\System32\\\\KERNELBASE.dll\\r\\nReport Id: e41dd320-26cf-476e-9644-26427dae9293\\r\\nFaulting package full name: \\r\\nFaulting package-relative application ID: \\\"\"},\"eventdata\":{\"data\":\"SolarWinds.Orion.LogMgmt.TrapService.exe, 2.2.0.14784, 5da00feb, KERNELBASE.dll, 10.0.14393.1770, 59bf2ba6, e0434352, 0000000000033c58, 1968, 01d70fc5faa40bea, C:\\\\\\\\Program Files (x86)\\\\\\\\SolarWinds\\\\\\\\Orion\\\\\\\\OLM\\\\\\\\SolarWinds.Orion.LogMgmt.TrapService.exe, C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\KERNELBASE.dll, e41dd320-26cf-476e-9644-26427dae9293\"}}}\n{\"win\":{\"system\":{\"providerName\":\"Application Error\",\"eventID\":\"1000\",\"level\":\"2\",\"task\":\"100\",\"keywords\":\"0x80000000000000\",\"systemTime\":\"2021-03-03T00:42:01.874322700Z\",\"eventRecordID\":\"27555\",\"channel\":\"Application\",\"computer\":\"agente1\",\"severityValue\":\"ERROR\",\"message\":\"\\\"Faulting application name: SolarWinds.Orion.LogMgmt.SyslogService.exe, version: 2.2.0.14784, time stamp: 0x5da00ff2\\r\\nFaulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6\\r\\nException code: 0xe0434352\\r\\nFault offset: 0x0000000000033c58\\r\\nFaulting process id: 0x1290\\r\\nFaulting application start time: 0x01d70fc5fa1c13e4\\r\\nFaulting application path: C:\\\\Program Files (x86)\\\\SolarWinds\\\\Orion\\\\OLM\\\\SolarWinds.Orion.LogMgmt.SyslogService.exe\\r\\nFaulting module path: C:\\\\Windows\\\\System32\\\\KERNELBASE.dll\\r\\nReport Id: b8cb8839-fbc6-4992-9ded-117bca245d14\\r\\nFaulting package full name: \\r\\nFaulting package-relative application ID: \\\"\"},\"eventdata\":{\"data\":\"SolarWinds.Orion.LogMgmt.SyslogService.exe, 2.2.0.14784, 5da00ff2, KERNELBASE.dll, 10.0.14393.1770, 59bf2ba6, e0434352, 0000000000033c58, 1290, 01d70fc5fa1c13e4, C:\\\\\\\\Program Files (x86)\\\\\\\\SolarWinds\\\\\\\\Orion\\\\\\\\OLM\\\\\\\\SolarWinds.Orion.LogMgmt.SyslogService.exe, C:\\\\\\\\Windows\\\\\\\\System32\\\\\\\\KERNELBASE.dll, b8cb8839-fbc6-4992-9ded-117bca245d14\"}}}\n{\"win\":{\"system\":{\"providerName\":\"Microsoft-Windows-PerfNet\",\"providerGuid\":\"{CAB2B8A5-49B9-4EEC-B1B0-FAC21DA05A3B}\",\"eventSourceName\":\"PerfNet\",\"eventID\":\"2006\",\"version\":\"0\",\"level\":\"2\",\"task\":\"0\",\"opcode\":\"0\",\"keywords\":\"0x80000000000000\",\"systemTime\":\"2021-03-03T00:40:56.714993200Z\",\"eventRecordID\":\"27549\",\"processID\":\"0\",\"threadID\":\"0\",\"channel\":\"Application\",\"computer\":\"agente1\",\"severityValue\":\"ERROR\",\"message\":\"\\\"Unable to read Server Queue performance data from the Server service. The first four bytes (DWORD) of the Data section contains the status code, the second four bytes contains the IOSB.Status and the next four bytes contains the IOSB.Information.\\\"\"},\"eventdata\":{\"binary\":\"230000C00000000000000000\"}}}",
"manager": {
"name": "srvwazuh"
},
"data": {
"win": {
"eventdata": {
"data": "SolarWinds.Orion.LogMgmt.SyslogService.exe, 2.2.0.14784, 5da00ff2, KERNELBASE.dll, 10.0.14393.1770, 59bf2ba6, e0434352, 0000000000033c58, 11d0, 01d70fc65c078919, C:\\\\Program Files (x86)\\\\SolarWinds\\\\Orion\\\\OLM\\\\SolarWinds.Orion.LogMgmt.SyslogService.exe, C:\\\\Windows\\\\System32\\\\KERNELBASE.dll, 9c346fd6-9807-4f58-b895-91c0e732b593"
},
"system": {
"eventRecordID": "27574",
"eventID": "1000",
"computer": "agente1",
"task": "100",
"keywords": "0x80000000000000",
"level": "2",
"severityValue": "ERROR",
"channel": "Application",
"message": "\"Faulting application name: SolarWinds.Orion.LogMgmt.SyslogService.exe, version: 2.2.0.14784, time stamp: 0x5da00ff2\r\nFaulting module name: KERNELBASE.dll, version: 10.0.14393.1770, time stamp: 0x59bf2ba6\r\nException code: 0xe0434352\r\nFault offset: 0x0000000000033c58\r\nFaulting process id: 0x11d0\r\nFaulting application start time: 0x01d70fc65c078919\r\nFaulting application path: C:\\Program Files (x86)\\SolarWinds\\Orion\\OLM\\SolarWinds.Orion.LogMgmt.SyslogService.exe\r\nFaulting module path: C:\\Windows\\System32\\KERNELBASE.dll\r\nReport Id: 9c346fd6-9807-4f58-b895-91c0e732b593\r\nFaulting package full name: \r\nFaulting package-relative application ID: \"",
"systemTime": "2021-03-03T00:44:47.917792800Z",
"providerName": "Application Error"
}
}
},
"rule": {
"firedtimes": 4,
"mail": true,
"level": 10,
"description": "Multiple Windows error Application events",
"groups": [
"windows",
"windows_application"
],
"id": "61061",
"frequency": 8
},
"decoder": {
"name": "windows_eventchannel"
},
"input": {
"type": "log"
},
"@timestamp": "2021-03-03T00:44:47.941Z",
"location": "EventChannel",
"id": "1614732287.762376582",
"timestamp": "2021-03-02T19:44:47.941-0500",
"_id": "M-aL9XcBgHToKSV3Z237"
}
jeremias...@wazuh.com
Mar 4, 2021, 5:48:56 PM3/4/21
to Wazuh mailing list
Hi Daniel,
I investigated the rule 61061 and isn't referenced by other rules, so it isn't designed for triggering other rules. What it makes is trigger an alert if the rule 60602 has been triggered in a specific period of time.
Can you enable the logall option and search in /var/ossec/logs/archives/archives.log for the log that is triggering this alert in the same format as it is written?
I suspect that this agent can be reporting with a different IP than any. This will generate that the rule 100006 wouldn't trigger.
Having the log exactly as it is logged in archives.log I can investigate what other can be the problem.
Best regards.
I investigated the rule 61061 and isn't referenced by other rules, so it isn't designed for triggering other rules. What it makes is trigger an alert if the rule 60602 has been triggered in a specific period of time.
Can you enable the logall option and search in /var/ossec/logs/archives/archives.log for the log that is triggering this alert in the same format as it is written?
I suspect that this agent can be reporting with a different IP than any. This will generate that the rule 100006 wouldn't trigger.
Having the log exactly as it is logged in archives.log I can investigate what other can be the problem.
Best regards.
Reply all
Reply to author
Forward
0 new messages