Problem with Wazuh Active Response (Windows Server 2019, block login attempts using AbuseIPDB)

[Sergey Protsenko]

Hello Everyone.

I am new with Wazuh, I got it from previous admin, and trying to understand Wazuh deeper.

Regarding my problem. I have several Windwos 2019 servers and previously configured Wazuh’s Active Response feature to block login attempts using AbuseIPDB. And, its look like that AR stopped working.

If I check Security events in the Wazuh web interface for a particular rule id, I see that there are no new events registered after middle of December. I checked C:\Program Files (x86)\ossec-agent\active-response\active-responses.log on the agent side and  /var/ossec/logs/active-responses.log on the Wazuh Manager. But both of this files were changed a couple of months ago and do not contain new information.

I checked /var/ossec/etc/ossec.conf on the server and config files on the agent (all of these configs are identical) and did not find issues. I read Wazuh documentation about AR configuration and find some posts in the blogs with examples with configuration Wazuh’s Active Response to block login attempts using AbuseIPDB but cannot resolve the problem.

I will be grateful for help or advise how to find the cause of the problem.

I use Wazuh Manager v4.3.6, agents v4.3.8 and I can provide my configs.

[Julian Bustamante Narvaez]

Hi, I hope you are well.


Can you send me your ossec.conf (server and agent)?

the operating system for the agents is Windows Server 2019, right? for the server which Linux distribution is it?

You tried with this documentation -> https://wazuh.com/blog/detecting-known-bad-actors-with-wazuh-and-abuseipdb/       ?

Regards.

[Julian Bustamante Narvaez]

Hi, can you answer me the same thing that was sent to me by email here (reply all), for better traceability?

I am reviewing the files that you sent me to email  and as soon as I have an answer I will answer you.

Regards

[Julian Bustamante Narvaez]

Hi i was integrating abuseipdb with wazuh and it was working fine (see attachment).

for the Active response you should do the following:

edit ossec.conf (manager side)

  <active-response>
        <command>netsh</command>
        <location>local</location>
        <rules_id>100003</rules_id>
        <timeout>60</timeout>
    </active-response>

---------------------------------------------------------------------------------------------------------------------------------------------------

edit C:\Program Files (x86)\ossec-agent\ossec.conf (windows agent side)
  <localfile>
    <location>active-response\active-responses.log</location>
    <log_format>syslog</log_format>
  </localfile>

  <localfile>
    <location>C:\Users\vagrant\Documents\test.txt</location>
    <log_format>syslog</log_format>
  </localfile>

save and restart wazuh agent.

write  and save in test.txt file:

Dec 10 01:02:02 host sshd[1234]: Failed none for root from 212.192.241.132 port 1066 ssh2

Dec 10 01:02:02 host sshd[1234]: Accepted none for root from 64.62.197.132 port 1066 ssh2

When the alert is generated you can see that C:\Program Files (x86)\ossec-agent\active-response\active-responses.log file is modified, here you can see that the ip is blocked

If you have any doubts do not hesitate to consult me.

Regards

[Sergey Protsenko]

Hi Julian,

Thank you for the recommendations. I will apply them and check.

Also, I would like to share my configs and some additional information from my environment as you advised.

I attached my configs and rules mentioned in the manager config file.

Also, just in case, I  past below the rules which mentioned in the server ossec.conf file.

<group name="local,windows,windows_security,">
  <rule id="100001" level="10">
    <if_sid>60122</if_sid>
    <match type="pcre2">\b(?!(10)|192\.168|172\.(2[0-9]|1[6-9]|3[0-1])|(25[6-9]|2[6-9][0-9]|[3-9][0-9][0-9]|99[1-9]))[0-9]{1,3}\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)</match>
    <description>Authentication failed from a public IP address $(win.eventdata.ipAddress).</description>
    <mitre>
      <id>T1078</id>
      <id>T1531</id>
    </mitre>   <group>authentication_failed,gdpr_IV_32.2,gdpr_IV_35.7.d,gpg13_7.1,hipaa_164.312.b,nist_800_53_AC.7,nist_800_53_AU.14,pci_dss_10.2.4,pci_dss_10.2.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>

<group name="web,accesslog,">
  <rule id="100200" level="5">
  <if_sid>31108, 31100</if_sid>
    <id>^2|^3</id>
    <compiled_rule>is_simple_http_request</compiled_rule>
    <description>Simple URLs queries</description>
  </rule>
</group>

<group name="local,windows,windows_security,">
  <rule id="100009" level="10" frequency="10" timeframe="120">
     <if_matched_sid>100001</if_matched_sid>
     <description>Multiple Windows logon failures from a public IP address $(win.eventdata.ipAddress).</description>
     <options>no_full_log</options>
     <mitre>
      <id>T1110</id>
    </mitre>
     <group>authentication_failures,gdpr_IV_32.2,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AC.7,nist_800_53_AU.14,nist_800_53_SI.4,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_11.4,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>
</group>

[Sergey Protsenko]

Hi Julian, could you share the rule id 100003 configuration from your side? I have a rule with such id, and it looks like that it configured for another case.

My rule below:

  <rule id="100003" level="5">
    <decoded_as>Mikrotik_login</decoded_as>
    <description>Mikrotik: authentication</description>
    <group>pci_dss_10.2.4,pci_dss_10.2.5,</group>
  </rule>
 
Also, I have the second question. Can you advice me how to check my rule id="100002"?

  <rule id="100002" level="10">
    <field name="abuseipdb.abuse_confidence_score" type="pcre2" negate="yes">^0$</field>
    <description>IP with $(abuseipdb.abuse_confidence_score)% confidence of abuse connected to your network.</description>
    <group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>
  </rule>

[Julian Bustamante Narvaez]

Hi, I was using the  post, rules, if you follow the step by step in the article, it works fine.

<group name="local,syslog,sshd,">

<rule id="100002" level="5">

<if_sid>5716</if_sid>

<match type="pcre2">\b(?!(10)|192\.168|172\.(2[0-9]|1[6-9]|3[0-1])|(25[6-9]|2[6-9][0-9]|[3-9][0-9][0-9]|99[1-9]))[0-9]{1,3}\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)</match>

<description>sshd: Authentication failed from a public IP address $(srcip).</description>

<group>authentication_failed,authentication_success,pci_dss_10.2.4,pci_dss_10.2.5,</group>

</rule>

<rule id="100003" level="5">

<if_sid>5715</if_sid>

<match type="pcre2">\b(?!(10)|192\.168|172\.(2[0-9]|1[6-9]|3[0-1])|(25[6-9]|2[6-9][0-9]|[3-9][0-9][0-9]|99[1-9]))[0-9]{1,3}\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)</match>

<description>sshd: Authentication succeeded from a public IP address $(srcip).</description>

<group>authentication_failed,authentication_success,pci_dss_10.2.4,pci_dss_10.2.5,</group>

</rule>

</group>

<rule id="100004" level="10">

<field name="abuseipdb.source.rule" type="pcre2">^100002$</field>

<field name="abuseipdb.abuse_confidence_score" type="pcre2" negate="yes">^0$</field>

<description>AbuseIPDB: SSH Authentication failed from a public IP address $(srcip) with $(abuseipdb.abuse_confidence_score)% confidence of abuse.</description>

<group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>

</rule>

<rule id="100005" level="14">

<field name="abuseipdb.source.rule" type="pcre2">^100003$</field>

<field name="abuseipdb.abuse_confidence_score" type="pcre2" negate="yes">^0$</field>

<description>AbuseIPDB: SSH Authentication succeeded from a public IP address $(srcip) with $(abuseipdb.abuse_confidence_score)% confidence of abuse.</description>

<group>authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,</group>

</rule>

Regards.

[Sergey Protsenko]

Thank you, Julian. I will chek.

[Sergey Protsenko]

Hi Julian,

Sorry for late response. Thanks to your explanation, I got more understanding about question I asked. And will continue my experiments.

I have another tasks with the configuration of collecting SES logs to Wazuh and making querries to IIS logs collected from Wazuh agents. And, it looks like, I will come again to guru with new questions.

Thank you.