Hey Yassin, thank you for watching! Sure, I will make a part two to the active response feature. Stay tuned!

Hey Yassin, check out the new video which covers blocking user accounts with active response! kzfaq.info/get/bejne/sLmGf5p52LKrhJs.html&ab_channel=OpenSecure Thanks for watching and let me know what you think!

@@taylorwalton_socfortress thanks you , really helpful 👍

Hi Mehrdad, saw your comment and had the same question but then at the same time is saw in the video at 25:07 that the same script runs an unblock command triggred by rule.id 602. Maybe you can configure the blocked time in this rule.

Hi Mehrdad. About how Wazuh keeps the state of the AR that is configured with a timeout, I'll proceed to explain this. When configuring an AR in the manager, it shares this configuration with all the agents connected to it. This includes the AR names, the executable files and the timeout for each one. When an AR is received in the agent, it checks this information: verifies if the executable file exist and if it has a timeout (in seconds) configured. When it has configured a timeout, the agent executes the AR and stores in memory a reminder that this AR has to be reverted after the timeout configured. When the timeout expires, the agent executes the AR with the reverse action. I hope this information helps to clarify your doubts.

Check out the documentation about custom stateful active responses. It describes how the script should handle the timeouts. documentation.wazuh.com/current/user-manual/capabilities/active-response/custom-active-response.html#stateful-active-responses

Hey Chris! Check out this APT simulator: github.com/NextronSystems/APTSimulator I like to use this tool to simulate a wide range of attacks. Hope this helps and thanks for watching :)

@@taylorwalton_socfortress thanks brother you are the best

Hey Elia, thanks for taking the time to watch this video! Active response can be enabled for Windows agents as well. Instead of using the firewall-drop.sh script we will use the netsh.cmd command. win_route-null route-null.cmd srcip yes Notice we are still expecting the "srcip" We then set the active response tag win_route-null local 8 900 This example would drop traffic from any source ip that triggered a level 8 or above alert. Of course we can sub the tag out for a tag like we do in the video. You can find more details here: documentation.wazuh.com/current/user-manual/capabilities/active-response/remediation-configuration.html Hope this helps and let me know if you still have some questions and I'd be happy to help!

@@taylorwalton_socfortress Thank you very much for the answer. I have already tried this yesterday, but it doesn't work. Basically beacuse there is no "srcip" field generated by the rule. Let me explain: I have a VirtualBox machine with Kali for doing some ssh bruteforce test, the target is a Windows PC (the agent) where OpenSSH is installed. I set the "ossec.conf" file of the Windows Agent like this: OpenSSH/Admin eventchannel And in this way the agent can send logs about OpenSSH (Event Viewer) to Wazuh Manager. Get to the point, when the attack begins, on Wazuh Manager only this rules are triggered: 60014 and 60011 of the "0575-win-base_rules.xml" file and none of this cointain "srcip". I hope I have explained the situation well. Probably I'm doing something wrong because I'm new to Wazuh. Any advice or solution to get the goal is welcome! Thanks

Hey Elia, I am running into a similar issue on my end. Let me keep testing and I will get back to you. May call for another video :)

Hey Elia, Thank you for your patience. Unfortunately, since Window's Event logs do not bring in a srcip, the active response feature for Windows servers is currently broken. However, the Wazuh team has been working on a feature that will allow us to add our own fields, we will no longer be limited to srcip, and this has been already merged with their 4.2 release: github.com/wazuh/wazuh/pull/7317. Once that is released, I will make a video on the update process and a tutorial using this new feature. Stay tuned! :)

Hey Arod, correct. The "command" and "active-response" blocks are made on the ossec.conf of the Wazuh-Manager under /var/ossec/etc/ossec.conf. Through Kibana, we are able to interact with the wazuh-api (which only runs on the wazuh-manager) and make changes to the ossec.conf file without having to manually logon to the wazuh-manager server and opening the ossec.conf file with a text editor. The active response workflow would be as followed: 1. Log is sent from the wazuh-agent to the wazuh-manager 2. The wazuh-manager compares the log it received to its rulesets. 3. The wazuh-manager determines the log matches a rule (rule id) and marks it as so 4. The wazuh-manager sees that the rule id that the log matches is configured within the active response block of the ossec.conf file on the wazuh-manager. 5. The wazuh-manager sends a message to the wazuh-agent (it finds this by the agent.id field within the log) to run the active response script detailed in the "active response" block of the ossec.conf. Firewalld-drop.sh in our example. 6. The wazuh-agent receives this message and runs the script. The script is stored on the wazuh-agent locally under "/var/ossec/active-response/bin/firewalld-drop.sh". You have the ability to create custom scripts, whether that be bash, python, powershell, etc. and have them be called during the active response workflow. You would have to make sure that the wazuh-manager and wazuh-agent have the script locally so that each server could run it. Otherwise it will complain saying that the script you are trying to run does not exist. When remotely copying scripts, files, etc. I like to use the "scp" command. Let me know if this helps, or any other questions you may have. Thanks for watching!

Hey Rahul, apologies for the late response. Could you clarify alittle more as to what you are having trouble viewing? Is it the rule ids 601, and 602 that are shown around the 28:07 timestamp of this video? Thanks for watching and I am looking forward to your response!

@@taylorwalton_socfortress Not sure if this is a bit too late, but I'm having the same issue, with the rule ids 601 and 602 missing. I can see it from the active-responses.log file from the agent though.

Hey Doza, active response will trigger for any source ip that triggers the rule. In the example in the video that rule id was: 5712. So any time rule 5712 is triggered, whatever source ip that triggered the rule will be read by active response and active response will create an iptables rule with that source ip. Hope that helps and thanks for watching!

Hi Marcio I hope you are doing fine!! To check firewall drop IP´s into Linux, run: iptables -L INPUT -v -n | grep When Wazuh Active response netsh.c block an IP, you can check banned ip running following command on windows box. netsh advfirewall firewall show rule name="WAZUH ACTIVE RESPONSE BLOCKED IP" It should show the Rule Name and a description like: Enable: Yes Direction Profiles Grouping LocalIP RemoteIP Protocol Edge traversal Action if it´s disable will show: No rules match the specified criteria. Let me know if that info is useful! regards!

Lol tomato-tomato :)

I've watched the videos from the official Wazuh channel and heard them pronounce it the right way (presumably) but almost everywhere else, I hear it pronounced WAH-ZOO. I think this a great lesson in any marketing effort. That is, think about how your company name will be pronounced by the general public, irrespective of how obvious it is to you. If I need to pronounce this correctly, I think of it as WAZ and then add in the Uh, as in uh-oh. But it's a pickle nonetheless.