Hi again and sorry for the late response, As I said, if the appropriate events (wrong password attempts) are not being generated, no AR script will be executed.
Before troubleshooting the possible AR issues, check that the wrong password attempt events are being generated. This is how the active response use cases work: *Wrong password attempts in the agent -> Event generated -> Rule generates an alert in the manager -> Alert matches the AR configuration -> Active response script executed * Right now we are in step 2 or 3, "Event generated" or "Rule generates an alert in the manager". If the event is not generated, the rules will not generate the specific alert needed for active response. And if no rule is matching the events generated, no alert is generated for the AR script execution. Could you enable the logall <https://documentation.wazuh.com/3.13/user-manual/reference/ossec-conf/global.html#logall> option in the manager's *ossec.conf* file? This will make your logs appear in */var/ossec/logs/archives/archives.log*. With the logs corresponding to the wrong password attempts we could see why the rules are not generating the alerts and therefore, executing active response (it could be a lack of rules for these logs). On Sunday, June 5, 2022 at 1:26:11 PM UTC+2 annie...@gmail.com wrote: > Hi, I enabled execd.debug = 2. In ossec logs *Read 0 lines from > active-response\active-response.log, *these logs are seen several times. > Also I checked */var/ossec/logs/alerts/alerts.log *file, basic logs for > windows are getting generated but logs for wrong password events are not > generated. > > On Mon, May 23, 2022 at 1:01 PM Manuel Camona Perez <manuel....@wazuh.com> > wrote: > >> Hi again, could you have a look at the events generated when you are >> reproducing the use case? Note that if the appropriate events (wrong >> password attempts) are not being generated, no AR script will be executed. >> These events can be found at */var/ossec/logs/alerts/alerts.log*. >> >> In order to troubleshoot, you could also enable debug mode for the execd >> daemon of your Wazuh agent. To do this, add the following line: >> >> >> *execd.debug=2* >> >> to the agent's *local_internal_options.conf* file. >> >> Also, have a look at >> https://documentation.wazuh.com/3.13/learning-wazuh/shellshock.html#ar-scenario-3-make-windows-null-route-the-attacker, >> >> this documentation page will help you troubleshoot the possible errors as >> it explains a very similar use case. >> >> >> >> On Sunday, May 22, 2022 at 9:21:37 AM UTC+2 annie...@gmail.com wrote: >> >>> Hi Manuel, >>> In my use case , Centos is the manager. I have only one wazuh agent i.e >>> my windows machine, it is my victim. I have another Windows machine as the >>> attacker. I am trying to RDP the machine with wrong password attempts. So >>> in that case AR should get generated along with scrip field , but it is >>> not. Also I tried using <location>local</location> but no success. >>> >>> >>> >>> On Tue, May 10, 2022 at 1:00 PM Manuel Camona Perez < >>> manuel....@wazuh.com> wrote: >>> >>>> Hi Annie, >>>> >>>> As I can see in the command configuration, you used the *expect* >>>> option with *srcip*. This means that the alert generated that >>>> triggered active response must have a *srcip* field as the *srcip* >>>> value will be used in the script. >>>> >>>> In the active response configuration, you used the *level* option with >>>> value *5*. This means that all the alerts with level equal or higher >>>> than 5 will trigger the active response script. >>>> >>>> Taking these 2 statements into account, the following could be >>>> happening: an event with level>=5 but without srcip field is being >>>> generated, and therefore, the active response script is not being >>>> executed. >>>> Could you check this? >>>> >>>> Also, note that you are using *all* in the *location* option. This >>>> means that the active response script will be executed for all agents when >>>> AR is triggered. The *all* option should be used with caution because >>>> maybe this is not the use case you are looking for. If you use *local*, >>>> the AR script is executed on the agent that generated the event. If you >>>> use >>>> *server*, the AR script is run on the manager the agent is reporting >>>> to. You can find more information about this option here >>>> <https://documentation.wazuh.com/3.13/user-manual/reference/ossec-conf/active-response.html#location> >>>> . >>>> >>>> On Sunday, May 1, 2022 at 2:20:01 PM UTC+2 annie...@gmail.com wrote: >>>> >>>>> Hi all, >>>>> This is my active response configuration on centos server: >>>>> >>>>> <command> >>>>> <name>win_nullroute</name> >>>>> <executable>route-null.cmd</executable> >>>>> <expect>srcip</expect> >>>>> <timeout_allowed>yes</timeout_allowed> >>>>> </command> >>>>> >>>>> <active-response> >>>>> <disabled>no</disabled> >>>>> <command>win_nullroute</command> >>>>> <location>all</location> >>>>> <level>5</level> >>>>> <timeout>60</timeout> >>>>> </active-response> >>>>> >>>>> I have enabled AR on windows agent, but it is not executed when an >>>>> event of level>=5 is fired. >>>>> I am using wazuh 3.13 version, windows 10 >>>>> >>>> -- >>>> >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "ossec-list" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to ossec-list+...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/ossec-list/4833a5ab-2fce-49e3-9f00-0b2d2755d937n%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/ossec-list/4833a5ab-2fce-49e3-9f00-0b2d2755d937n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "ossec-list" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to ossec-list+...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/ossec-list/37ce5346-5191-40d9-813c-ffe25bd03f49n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/ossec-list/37ce5346-5191-40d9-813c-ffe25bd03f49n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/7b8d32b2-b22c-48b4-9d2a-968460855b9cn%40googlegroups.com.
