Discovering the CrowdSec and Wazuh Integration

This is an adaptation of the original article published in French on the Aukfood Blog.

---

The CrowdSec integrations ecosystem expands constantly to cover more tools and use cases to better fit the needs of the community. One of the most interesting and handy integrations to date is the one with Wazuh. 

Wazuh is an open source security platform providing XDR and SIEM solutions to protect your endpoints and cloud workloads. The integration with CrowdSec aims to centralize CrowdSec alerts into the Wazuh SIEM. 

Let’s jump right into this tutorial and discover the power of two open source projects coming together! 

The CrowdSec x Wazuh integration

Before we get started with the tutorial, you will need a few things to follow this walkthrough:

• An installed Crowdsec Security Engine version 1.6.3 or above. 
• Wazuh SIEM version 4.9.0 or above. 

Configuring the CrowdSec Security Engine

Let’s start by creating the wazuh.yaml file, a file that will contain the notification for sending CrowdSec alerts to the temporary file crowdsec_alerts.json. Choosing a JSON file allows for better interpretation by Wazuh, which eliminates the need to create a decoder.

/etc/crowdsec/notifications/file.yaml

# Do not change
type: file

name: wazuh # Name of the plugin to register in profiles.yaml
log_level: info

# This template renders all events in ndjson format
format: |
  {{range . -}}
   { "crowdsec": { "time": "", "program": "crowdsec", "alert": {{. | toJson }} }}
  {{ end -}}

# group_wait:
# group_threshold:

log_path: "/tmp/crowdsec_alerts.json" # or %TEMP%\crowdsec_alerts.json
rotate:
  enabled: true 
  max_size: 500 # in MB
  max_files: 5
  max_age: 5
  compress: true

All that’s left is to add the plugin to the profiles.yaml file, then restart the Security Engine configuration.

/etc/crowdsec/profiles.yaml

name: default_ip_remediation
#debug: true
filters:
 - Alert.Remediation == true && Alert.GetScope() == "Ip"
decisions:
 - type: ban
   duration: 4h
#duration_expr: Sprintf('%dh', (GetDecisionsCount(Alert.GetValue()) + 1) * 4)
notifications:
 - wazuh # <- /etc/crowdsec/notifications/wazuh.yaml or /etc/crowdsec/notifications/file.yaml
#   - slack_default  # Set the webhook in /etc/crowdsec/notifications/slack.yaml before enabling this.
#   - splunk_default # Set the splunk url and token in /etc/crowdsec/notifications/splunk.yaml before enabling this.
#   - http_default   # Set the required http parameters in /etc/crowdsec/notifications/http.yaml before enabling this.
#   - email_default  # Set the required email parameters in /etc/crowdsec/notifications/email.yaml before enabling this.
on_success: break

sudo systemctl reload crowdsec

Now that the CrowdSec part is complete, all that's left is to configure Wazuh.

Configuring the Wazuh SIEM

For this part, it is preferable to use centralized management rather than a local configuration. Therefore, creating a group in Wazuh is necessary, and the name will be Crowdsec. Then, you need to edit the group's configuration to be able to read the /tmp/crowdsec_alerts.json file on your clients.

/var/ossec/etc/shared/Crowdsec/agent.conf

    
        /tmp/crowdsec_alerts.json
        json
        no
    

Next, you need to create a rules file in order to trigger Wazuh alerts, otherwise, the CrowdSec alerts will be useless. Two rules will be created: one for level 12 alerts and another for test alerts.

/var/ossec/etc/rules/crowdsec-rules.xml

    
    
        json
        crowdsec
        CrowdSec alert: $(crowdsec.alert.message)
    

    
        100002
        test alert
        Test alert for CrowdSec.
    

You can also add the rules from this GitHub repo. These are more advanced and customized rules, including filtering for MITRE.

Time for testing

The configuration is now complete. All that's left is to test it. You can start by testing the level 3 rule, which corresponds to the test rule. You can use the following command directly on the client machine: cscli notifications test file_default.

You can see that the test rule is triggered correctly, including the various information from data.crowdsec.alert.

You can now try the level 12 rule. For this example, I tested this on my Proxmox server, but it works with any type of server and CrowdSec alerts.

The CrowdSec alert fulljackz/proxmox-bf appears in Wazuh, and thus the level 12 rule is triggered.

To conclude

Was this the fastest setup you’ve ever done, or what? The integration is simple and very effective and strengthens the centralized management of CrowdSec alerts in a SIEM.

Hope you enjoy your new security layer and don’t hesitate to hit us up with any questions or feedback on the CrowdSec Discourse or Discord.