C ompletely ignore / drop a log

[Max Kalachov]

Hi guys,

I have a situation when a Domain Controller sends around 20k garbage logs a day. In my case, the log is regarding Windows Logon Success, but it could be any other spamming log.

Tactics:
Defense Evasion, Initial Access, Persistence, Privilege Escalation
Description:
Windows Logon Success
Level:
3
Rule ID:
60106

How can I filter/block it in a way that it won't be even written into Wazuh system/DB? It's just 20k logs that I don't need, I don't want them to be on the Wazuh server.

Is there a way to prevent a log from being stored or received by the Wazuh server, or maybe something can be done with the Wazuh client?

Thank you,

Regards,

Max

[Juan Nicolás Asselle]

Hi Max!

Default value of log_alert_level(3) indicate Successful/Authorized events (successful login attempts, firewall allow events, etc) according to Wazuh Rules Classification. If these types of events are not of your interest, you could increase the log_alert_level, discarding and not storing logs/alerts for rules under that value.

I hope this helps. If you have any other question, do not hesitate to ask.
Regards,
Nico

​

[Max Kalachov]

Hi Nico,

Thanks for the explanation. I do need another level 3 logs though, at least for now.

Is there a way to discard only a particular rule ID or a particular rule ID coming from a particular host?

Thank you

Regards,

Max

[Juan Nicolás Asselle]

Hi Max!

You could discard multiple rules creating a new custom one that silence, for example, all successfully authentications no matter the mechanism using if_group. An example could be:

<group name="local,">
  <rule id="100001" level="0">
    <if_group>authentication_success</if_group>
    <description>Silencing Logins</description>
  </rule>
</group>

Similar way but using if_sid with specific logins rules (for example 60106, 60118, 60200):

<group name="local,">
<rule id="100001" level="0">
<if_sid>60106, 60118, 60200</if_sid>
<description>Silencing some Windows Logins</description>
</rule>
</group>

Regards,
Nico

​

[Max Kalachov]

Hi Nico,

Thank you very much for the examples, I understand now. So basically changing a rule level to a level below "log_alert_level" makes it to be discarded.

I managed to reduce the number of logs by dozens of thousands.

Btw, can I use <location></location> withing such rules? To determine not only the rule but also a host, for more accurate discarding. I tried it didn't work for me.

Regards,

Max

[Juan Nicolás Asselle]

Hi Max!

You’re very welcome, happy to help :) . The concept of location is related to where the log is obtained within the agent and no the agent itself. For example, if the log comes from /var/log/syslog, that will be it value. The location option in a rule will try to match it with the log location.
Unfortunately and currently there’s no a unified way to filter by agent with rules. If the events to filter are specifics ones and you know beforehand they have an agent information, i.e Window’s events win.system.computer, you could use CDB list as whitelist and silence them.

Other option is to use agent labels and then filter in Kibana.

Please let me know if this information was helpful.

Regards,
Nico

​

[Sandra Ocando]

Hi Max!

I would like to clarify that location includes not only the information about where the log comes from but also the name and the IP of the agent. So it is possible to make custom rules to discard the alerts from a list of agents. For example:

<group name="resistance">
  <var name="excl_agnt">BB8|C3PO|R2D2</var>
  <rule id="100004" level="0">
    <if_sid>503</if_sid>
    <location>$excl_agnt</location>
    <description>These are not the agents you're looking for</description>
  </rule>
</group>

By adding this rule the alerts matching rule 503 will be ignored for agents in the excl_agnt list. You can also use CDB Lists if you plan on maintaining a large list of agents.

I hope you find this information useful for your use case. Please let us know if we can help with anything else.

Best regards,
Sandra.

[Max Kalachov]

Hi Sandra!

Thank you very much for the additional information. This is exactly what I was looking for. I will start implementing discards this way.

Regards,

Max

[Max Kalachov]

Hi Sandra!

One more question if you don't mind. Is there an option to add to the rule you provided "match a string" as an additional parameter?

So the idea is to discard a log only when it matches the rule ID, agent ID, and a particular string in the log.

Let's say I have a log of SSH "authentication success", where a client from a particular IP address logging in every minute to a server. So I want to discard SSH authentication success (rule ID) to the server (agent ID) only when a string matches the client's IP address or username (a string). Or any other unique identifier that could be found in the log.

Thank you

Regards,

Max

[Sandra Ocando]

Hi Max!

Yes, you can add the option <match></match> to match a string as an additional parameter. Here's an example:

<group name="silent">
  <var name="excl_agnt">AGENT_A|AGENT_B|AGENT_C</var>
  <rule id="100003" level="0">
    <if_sid>5715</if_sid>
    <location>$excl_agnt</location>
    <match>192.168.33.1|192.168.33.42</match>
    <description>Ignore these events</description>
  </rule>
</group>

This custom rule will silence alerts for "sshd authentication success" events for agents in the "excl_agnt" list and from IPs in the match list. Please take into account that this string match is a partial match, for example connections from  192.168.33.1x will also be silenced. This is also true for strings in the "excl_agent" so use it with care.

If you want to ignore connections from certain IPs I would recommended using the option <srcip>1.1.1.1</srcip> that will match only information coming from srcip and will do an exact match.

Best regards,
Sandra