Decoders and Rulers

Define Your Own Rules Based on Threshold

Establishing a baseline and threshold is a critical foundational step in cybersecurity management. Your organization's security policy should articulate the protective measures and protocols to handle information security risks. This policy will guide how Wazuh rules should be configured to effectively monitor and alert on activities within your systems.

You can create your own rules T-guard enables you to configure your own rule based on your organization policy.

Wazuh's default rules and configurations can serve as a starting point. These predefined rules are designed to detect a wide range of common security issues and can be used to immediately enhance your security posture. Over time, as your organization develops its own tailored rules, these rules can be refined and additional custom rules can be created to align with your specific security needs and compliance requirements.

Using Wazuh's basic rule set helps to cover essential security monitoring out of the box, which is particularly useful for organizations just beginning to formalize their cybersecurity processes. This approach provides immediate protection while giving the organization time to develop a more customized security policy.

Decoders & Rules

Decoders are used to parse the log data received from different sources. They work by interpreting the format of the incoming data and breaking it down into fields that can be understood and used by the SIEM system. Decoders are necessary because log data can come in many different formats depending on the source (e.g., operating systems, applications, network devices). They allow the system to normalize the log data, extracting meaningful attributes like timestamps, log levels, user IDs, IP addresses, and error messages from the raw logs.

On the other hand, rules are applied to the data after it has been decoded to determine if the event matches any known patterns of malicious or suspicious activity. They consist of conditions that the parsed log data must meet to trigger an alert. These conditions can be based on the content, frequency, or correlation of events. Rules are often prioritized and organized into levels, where a higher level indicates a higher significance or potential severity of the event. Many SIEM systems, including Wazuh, come with a comprehensive set of predefined rules that cover a wide range of security monitoring use cases, and they can be customized or extended as needed.

To set custom rules, you need to understand the directory structure of Wazuh, as listed below:

/var/ossec/ ├─ etc/ │ ├─ decoders/ | | └─ local_decoder.xml │ └─ rules/ | └─ local_rules.xml └─ ruleset/ ├─ decoders/ └─ rules/

Inside the ruleset/ folder you will find all the common rules and decoders. All files inside this folder will be overwritten or modified in the Wazuh update process, so please do not edit files or add custom files in this folder.

If we need to perform some custom changes, we will use the etc/ folder. You can add here your own decoders/rules files or use the default local_decoder.xml and local_rules.xml files.

For example, there is this honeypot log that is not exists in Wazuh standard log decoders (https://documentation.wazuh.com/current/user-manual/ruleset/getting-started.html)

{ "_id": {"$oid": "63fbb5aedfd8c8470aedcdf1"}, "measurement": "honeypots", "tags": { "honeypot": "cowrie" }, "time": "2023-02-26T19:39:12+0000", "fields": { "analyzer_id": "ASEAN-ID-ORG-Cowrie-1", "source_address": "156.236.75.44", "source_port": 56800, "source_protocol": "tcp", "target_address": "1.2.3.4", "target_port": 2222, "target_protocol": "tcp", "sessionid": "b77971414f5b", "logintime": "2023-02-26 19:39:12", "endtimetime": "2023-02-26 19:39:15", "version": "SSH-2.0-libssh_0.9.6", "login": "Success", "username": "root", "password": "QWer1234", "input": [ "cd ~; chattr -ia .ssh; lockr -ia .ssh", "cd ~ && rm -rf .ssh && mkdir .ssh && echo \"ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEArDp4cun2lhr4KUhBGE7VvAcwdli2a8dbnrTOrbMz1+5O73fcBOx8NVbUT0bUanUV9tJ2/9p7+vD0EpZ3Tz/+0kX34uAx1RV/75GVOmNx+9EuWOnvNoaJe0QXxziIg9eLBHpgLMuakb5+BgTFB+rKJAw9u9FSTDengvS8hX1kNFS4Mjux0hJOK8rvcEmPecjdySYMb66nylAKGwCEE6WEQHmd1mUPgHwGQ0hWCwsQk13yCGPK5w6hYp5zYkFnvlC8hGmd4Ww+u97k6pfTGTUbJk14ujvcD9iUKQTTWYYjIIu5PmUux5bsZ0R4WFwdIe6+i6rBLAsPKgAySVKPRK+oRw== mdrfckr\">>.ssh/authorized_keys && chmod -R go= ~/.ssh && cd ~" ], "hostname": "ubuntu-server" }, "request_": {}, "location": { "lat": -4.5833, "lon": 55.6667 }, "geo_location": { "registered_country": "Seychelles", "country": "Seychelles", "country_code": "SC", "longitude": 55.6667, "latitude": -4.5833 }, }

In this decoder, the <type>json</type> tag specifies that the decoder is for JSON format logs. The <field> tag is used to match the tags.honeypot field within the JSON log. This will capture logs that contain this field, indicating that they are from a honeypot.

Decoder	<decoder name="honeypot-cowrie-decoder"> <type>json</type> <field name="honeypot">tags.honeypot</field> </decoder>
Rule	<rule id="100001" level="7"> <decoded_as>honeypot-cowrie-decoder</decoded_as> <field name="honeypot">cowrie</field> <field name="input">\.+</field> <description>Cowrie honeypot interaction detected</description> <mitre> <id>T1190</id> </mitre> <group>honeypot,cowrie,detected,</group> </rule>

This rule will trigger an alert with a level of 7 when a log that has been decoded by honeypot-cowrie-decoder contains the honeypot field with the value "cowrie" and has any input in the input field. The \.+ is a regex pattern that matches any character one or more times, ensuring that the input field is not empty.

Please note that you will need to replace 100001 with a unique rule ID that fits within your Wazuh ruleset. The level 7 is just an example and can be adjusted based on the severity you wish to assign to this kind of alert. The <mitre> tag with T1190 is an example and should correspond to the actual technique detected. The rule and decoder should be tested to confirm they work with your log structure.