Custom Rule Not Work, But Another Rule In the Same Group Work

[Kesa Adiyaka]

Hallo, I'm still new in wazuh, and this is my first project. I want to configure an active response by integrating suricata alert with wazuh. I have configured the local_rules.xml.  Actually I'm following the guide in this article https://wazuh.com/blog/responding-to-network-attacks-with-suricata-and-wazuh-xdr/

This is my configuration in local_rules.xml :



Strangely rule with Nmap work just fine, and wazuh can drop the firewall to block the attack. But for the Goldeneye Dos Attack it doesn't work.


this is what I get with when I launch the Goldeneye attack. And another strange thing is that I realize my firewall is not blocking the malicious IP address for 3 minutes, like in the rules said. Can anyone help me ? I will be really gratefull, thank you in advance.

[Antonio David Gutiérrez]

Hi,

If you are not getting the alert related to Goldeneye Dos Attack, this could mean a problem with the declaration of the rule or the source of the integration (Suricata) is not generating the expected rule by the Wazuh rule configuration. You should ensure Suricata is emitting the event so the custom Wazuh rule definition matches with it.

Regarding the provided rule related to this attack, this is using 2 matchers: `field` and `match` moreover the rule with ID 86600 should be matched for the same log. I think you should debug this problem:

0. Assuming you configured Wazuh to read the events generated by Suricata as explain on the blog:
1. Launch the Goldeneye attack to the machine that you configured to integrate Suricata with Wazuh (and the Wazuh agent/server is reading the events file of Suricata)
2. Identify the related event with the attack that was generated by Suricata and stored in the file that is collected by the Wazuh agent/server (where you installed Suricata)
3. Ensure the event is matching the condition of the custom rule you did for the attack that you defined with ID 100200 according to the provided information.
You can use the logtest utility of the Wazuh server to test your custom decoders/rules: https://documentation.wazuh.com/4.7/user-manual/ruleset/testing.html#using-the-wazuh-dashboard-and-the-command-line-tool (documentation link for the latest available version, switch the version if you are using another one)
Regarding the rule with ID 100200, it is using the matchers:
  - `field`: event_type filed should be alert
  - `match`: ET DOS Inbound GoldenEye DoS attack . The log related to the attack, should contain this string in some of the props.
  - `if_sid`: the rule with the specified ID 86600 should match to the rule related to this attack can be evaluated.

Reference of Wazuh rule matchers: https://documentation.wazuh.com/4.7/user-manual/ruleset/ruleset-xml-syntax/rules.html#overview

Maybe the rule is not matching the event generated by Suricata this changed the log that is expected by the integration explained on the blog.

In summary, the Wazuh rules are triggered by events/data collected by the Wazuh agents/servers that match with the specifiers matchers. So you should ensure you define a precise Wazuh rule that match with the event/data collection.

Regarding the question about blocking for 3 minutes the IP that is mentioned here: https://wazuh.com/blog/responding-to-network-attacks-with-suricata-and-wazuh-xdr/#attack-emulation-1-nmap-scan, the configuration of the active response of the blog is done here: https://wazuh.com/blog/responding-to-network-attacks-with-suricata-and-wazuh-xdr#active-response-configuration and on its definition: the active response in only configured to run for alerts with ID: 100200 or 100201.  Assuming you configured the active response configuration as explained on the blog, you should ensure you got the alerts with these IDs were generated, else, that active response should not run.