One of the functionalities of Wazuh are the alerts. These are messages that allow you to define different cases and highlight a message that defines the situation and realize in a simple way that it is happening in real time. This functionality is very important to properly establish a good SOC team. It also gives the freedom to be able to create our own notices that we will explain in the following document.
To begin with we know that different types of alerts are generated with different degrees. These are created from decoders, whose purpose is to translate the messages sent by the agents or the logs we send into variables to be able to establish limits and states. These are also customizable and strictly necessary to correctly generate the desired alerts.
Creation of rules
As we mentioned above, it is crucial for our work to create custom rules or even modify existing ones so that they only show us the needed information, reducing the number of alerts that the incident team receives and creating a Service of SOC functional.
First of all we will explain how to create new rules from scratch. Wazuh already has a few rules created and the number of defined rules is updated, so it reserves a few ids for these rules created by the user. The id numbers are between the values: 100000 – 120000, and each new rule must have a different id.
Custom rules are defined in XML, in a file called local_rules.xml. The default path of this file is: /var/ossec/etc/rules/local_rules.xml.
Below we can see a complete example of a new rule. We will go into detail on how we can create our own rule and how the previously mentioned variables can be used:
<rule id="100010" level="0">
<program_name>example</program_name>
<description>User logged</description>
</rule>
More concrete information about this rule can be found at: https://documentation.wazuh.com/current/user-manual/ruleset/custom.html
Rules are created with XML tags; as we can see all the information of a rule is defined with a tag called rule, where we already specify the id and the level of severity that this will have. Once we have our first tag created, we can add more as we want to. To know which variables can be used (as tags), you can get more information in the official Wazuh documentation: Rules Syntax – Ruleset XML syntax · Wazuh documentation.
*During the section we find the example that uses «program name» as a label to define what it applies to, but this is an automatically generated variable according to the logs that have a defined structure, «timestamp» «username» «program»: «log». If this does not apply we will not be able to use this tag and we will have to generate the rule by regex.
Modify rules
Once we know how to create new rules, it is very easy to modify existing ones. These new «modified» rules must be created in a specific file (local_rules.xml, the same file as for creating new rules) in order to keep these rules when Wazuh is updated. To modify the existing rules, we will have to overwrite the rule in local_rules.xml. To do this we will have to declare a «rule» tag as we did to create a new rule, but now inside the tag we will have to use the id of the rule we want to modify and we will have to specify that we are overwriting, with the overwrite=»yes» parameter. Then, we will be able to modify all the fields except if_sid, if_group, if_level, since these are unique to the rule and would not have meaning to modify them.
Next, we can see an example of how the overwrite would be specified:
<rule id="5710" level="10" overwrite="yes">
<if_sid>5700</if_sid>
<match>illegal user|invalid user</match>
<description>sshd: Attempt to login using a non-existent user</description>
<mitre>
<id>T1110</id>
</mitre>
<group>invalid_login,authentication_failed,pci_dss_10.2.4,pci_dss_10.2.5,pci_dss_10.6.1,gpg13_7.1,gdpr_IV_35.7.d,gdpr_IV_32.2,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AC.7,nist_800_53_AU.6,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>
Links
by Apolo Analytics