block alerts from a certain src ip

93 views
Skip to first unread message

Giacomazzi Gabriele Antonio

unread,
Jun 3, 2024, 8:48:55 AM6/3/24
to Wazuh | Mailing List
Hi everyone,

i am writing here 'cause i did not find anything related to this in the official documentation and on the internet.
I use a server which is running greenbone, a tool used for scheduled vulnerability assessments, with ip '192.168.0.3'. The problem occurs when the scheduled VAs generate a log of alerts from all the machines registered on my wazuh server.
My question is, is it possible to block/prevent the alerts from being generated or not shown at all if the src ip is '192.168.0.3'?

Regards,
Gabriele

Francisco Tuduri

unread,
Jun 3, 2024, 9:27:14 AM6/3/24
to Wazuh | Mailing List
Hello Gabrielle!

It is possible to silence rules based on some field of the alert, like the source ip.
You need to create a child rule of the rule that you want to silence, set the level of this new rule to 0 and add the extra checks needed to match the events that you want to silence.

For example, let's say that the rule that is generating some noise is rule 5716 (this is an ssh authentication failure), and you don't want to generate an alert when the source ip is 192.168.0.3. Then you can create the following rule in /var/ossec/etc/rules/local_rules.xml

<group name="syslog,sshd,">
<rule id="100050" level="0">
      <if_sid>5716</if_sid>
      <srcip>192.168.0.3</srcip>
      <description>Ignoring failed authentication from 192.168.0.3</description>
</rule>
</group>


Every event that matches the rule id 5716 will be tested against this new rule, and if the srcip is 192.168.0.3 it will trigger this rule (100050), but since the alert level is 0 it will not generate an alert.

You can find more info about the rules syntax here and about custom rules here.
And rememeR to restart the manager after making any changes to the ruleset.

Of course, the new rule (or rules) must be tuned for your specific use case.
If you need further assistance with this please share some log event samples of the alerts that you want to prevent (remember to obfuscate any sensitive data).

Regards!

Giacomazzi Gabriele Antonio

unread,
Jun 3, 2024, 10:21:33 AM6/3/24
to Wazuh | Mailing List
Hi, thanks for replying.
I know that there is the possibility of doing like you suggested. The fact that made me not do it is that the amount of rules triggered is very high.
That is what made me discard that possibility. My question was if it's possible to prevent every rule from being triggered if the src ip is '192.168.0.3'.

Regards,
Gabriele

Francisco Tuduri

unread,
Jun 4, 2024, 8:08:53 AM6/4/24
to Wazuh | Mailing List
Hello Gabriele!

I'm afraid that there is no functionality to silence every alert for an specific ip across all the ruleset.

However, consider the following options that might make this task a little easier.

  • The if_sid field allows multiple values, so you can use the same custom rule to 'capture' many other rules ids.
<group name="syslog,sshd,">
<rule id="100050" level="0">
      <if_sid>5716, 5718, 5719</if_sid>
      <srcip>192.168.0.3</srcip>
      <description>Ignoring alerts from 192.168.0.3</description>
</rule>
</group>



  • Another option is to use if_group, instead of if_sid. This will 'capture' all the alerts that match a certain group.

For example, to silence alerts from the authentication_success group for ip 192.168.0.3 you could have a rule like:

<group name="syslog,">

<rule id="100050" level="0">
      <if_group>authentication_success</if_group>
      <srcip>192.168.0.3</srcip>
      <description>Ignoring authentication success from 192.168.0.3</description>
</rule>
</group>


Regards!

Giacomazzi Gabriele Antonio

unread,
Jun 5, 2024, 7:37:59 AM6/5/24
to Wazuh | Mailing List
Hi,
yesterday i applied what you suggested.
Today greenbone had a couple of VAs scheduled, and no more alerts.

Thanks for the help.

Regards,
Gabriele

Francisco Tuduri

unread,
Jun 5, 2024, 7:39:29 AM6/5/24
to Wazuh | Mailing List

Good to hear that!
Have a nice day!
Reply all
Reply to author
Forward
0 new messages