Thank you dear. Le mer. 8 juin 2022 à 08:53, Manuel Camona Perez <manuel.carm...@wazuh.com> a écrit :
> 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 > <https://groups.google.com/d/msgid/ossec-list/7b8d32b2-b22c-48b4-9d2a-968460855b9cn%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/CAJ5OZk55Y1tcu6Lttdzo%3DJ63-VomARqOV8uogpNO-kbidvh8pA%40mail.gmail.com.
