Block ip address (active-response)

313 views
Skip to first unread message

zen1tsu

unread,
Mar 15, 2022, 9:32:46 AM3/15/22
to Wazuh mailing list
guys hello!

I've configured an active response on wazzuh , but as u can see on security events they are still trying to get access and I've shared my iptables where all those ip's have to be blocked according ossec.conf config, but they don't, why?

thanks in advance!
3.png
1.png
2.png

Pedro Nicolás Gomez

unread,
Mar 15, 2022, 11:50:16 PM3/15/22
to Wazuh mailing list

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.

zen1tsu

unread,
Mar 16, 2022, 3:37:25 AM3/16/22
to Wazuh mailing list
Hi, thanks for your response!
среда, 16 марта 2022 г. в 09:50:16 UTC+6, pedro.nic...@wazuh.com:
logs.png
agent-id.png

zen1tsu

unread,
Mar 16, 2022, 9:02:26 AM3/16/22
to Wazuh mailing list
Hello again, do you need any more information from me regarding this issue ?

среда, 16 марта 2022 г. в 13:37:25 UTC+6, zen1tsu:

Pedro Nicolás Gomez

unread,
Mar 16, 2022, 11:44:35 PM3/16/22
to Wazuh mailing list
Hi,

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.

https://documentation.wazuh.com/current/user-manual/reference/ossec-conf/active-response.html#location


zen1tsu

unread,
Mar 18, 2022, 3:35:21 AM3/18/22
to Wazuh mailing list
Hi , I've changed the active-response configuration to local, however, the issue does not resolve :(

четверг, 17 марта 2022 г. в 09:44:35 UTC+6, pedro.nic...@wazuh.com:
logs.png
ossec-conf.png

Milton Matamala

unread,
Mar 20, 2022, 11:17:47 PM3/20/22
to Wazuh mailing list

Hello zen1tsu

According to the background you are providing, I recommend the following:

- By default in rule 0095-sshd_rules.xml, ID 5712 will trigger the lock with a frequency of 8 attempts for 120 seconds for 60. Copy the rule and overwrite in local_rules.xml reducing the times. I copy my configuration:

<group name="local,syslog,sshd,">
  <rule id="5712" level="10" frequency="3" timeframe="240" ignore="60" overwrite="yes">
    <if_matched_sid>5710</if_matched_sid>
    <description>sshd: brute force trying to get access to </description>
    <description>the system.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
    <same_source_ip/><group>authentication_failures,pci_dss_11.4,pci_dss_10.2.4,pci_dss_10.2.5,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_SI.4,nist_800_53_AU.14,nist_800_53_AC.7,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>

Then in ossec.conf place the following in ossec.conf:

<active-response>
  <command>firewall-drop</command>  
  <location>local</location>    
  <rules_id>5712</rules_id>
  <timeout>7200</timeout>
  <repeated_offenders>180,240,300</repeated_offenders>
</active-response>

zen1tsu

unread,
Mar 21, 2022, 11:21:15 AM3/21/22
to Wazuh mailing list
Thank you for your advice,

Can WAZUH not just send addresses to timeout, but block them ?
since we just cover the hole in this way for a while and then open it back :(
понедельник, 21 марта 2022 г. в 09:17:47 UTC+6, milton....@gmail.com:

Milton Matamala

unread,
Mar 28, 2022, 12:51:47 AM3/28/22
to Wazuh mailing list
Hi, sorry for the late reply.
Of course you can block the IP address permanently, you just need to change the following parameter in AR:


<active-response>
  <command>firewall-drop</command>  
  <location>local</location>    
  <rules_id>5712</rules_id>
  <timeout>7200</timeout>
  <repeated_offenders>180,240,300</repeated_offenders>
</active-response>

by

<active-response>
  <command>firewall-drop</command>  
  <location>local</location>    
  <rules_id>5712</rules_id>
  <timeout_allowed>no</timeout_allowed>
</active-response>


let me know how it goes. Regards
Reply all
Reply to author
Forward
0 new messages