Hi zen1tsu,
Thanks for using Wazuh!
According to the images you shared you can see that the IPs have been added to the firewall rules.
To clarify some doubts, I would like to be able to see the active response logs, these are located in the active-responses.log file of the agent.
Because, with the latest changes in active response, when an AR is executed, the log is written in the active-responses.log file, this log is what causes the alert to be generated based on rule 652, after writing the log the AR verifies if it should continue or abort the execution because it has already been executed previously for that IP and the timeout has not yet expired. Regardless of whether the execution continues or is aborted, the initial log will generate the alert based on rule 652.
I can also see that you configured AR "firewall-drop" to run on agent 002 and it is triggered by group rule alerts authentication_failed | authentication_failures.
Could you verify that the alerts generated by rules of the groups authentication_failed | authentication_failures are generated by agent 002 events and not by another agent?
Because it may be happening, for example, that the IP 165.227.98.205 is trying to authenticate to agent 001 but according to your settings the AR runs in agent 002. Therefore, from IP 165.227.98.205 it could continue trying to authenticate to agent 001.
According to the image you shared, we can see that some of the alerts are generated by events in the agent with id 000, this id corresponds to the manager. I would consider setting the AR's "location" field to "local", this causes the active response to be executed on the agent that originated the event.
Here I share a link with the allowed values and the description of each one.