cisagov / LME

Logging Made Easy (LME) is a no-cost and open logging and protective monitoring solution serving all organizations.
https://www.cisa.gov/resources-tools/services/logging-made-easy
Other
763 stars 59 forks source link

Research Wazuh Alert Integration #314

Open safiuddinr opened 3 weeks ago

aarz-snl commented 4 days ago

This research is for a solution in configuring wazuh alerts to notify users on ELASTIC alerts which is normally a paid feature from elastic.

If ElastAlert is not an option

Elastic makes you pay for alerts. Especially for detection alerts based on rules we want to be able to alert users to these detections.

There is an API you can call to pull down any detections. So utilizing this EXAMPLE script (change as needed):

#!/bin/bash

KIBANA_HOST="https://localhost:5601"
USERNAME="elastic"
PASSWORD="password"
KBN_VERSION="8.12.2"
KBN_XSRF="kibana"
CONTENT_TYPE="application/json"

# Data payload to get alerts from the last 5 minutes
PAYLOAD='{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "now-5m",
        "lte": "now"
      }
    }
  }
}'

# Path to the log file
SCRIPT_DIR="$(dirname "$0")"
LOG_FILE="$SCRIPT_DIR/elastic-alerts.log"

# Perform the API call and process the output with jq
ALERTS=$(curl -k -u $USERNAME:$PASSWORD --noproxy '*' -X POST "$KIBANA_HOST/api/detection_engine/signals/search" \
-H "kbn-version: $KBN_VERSION" \
-H "kbn-xsrf: kibana" \
-H "Content-Type: $CONTENT_TYPE" \
-d "$PAYLOAD" | jq -c '.hits.hits[] | {
    detect_time: ._source["kibana.alert.last_detected"],
    alert_reason: ._source["kibana.alert.reason"],
    rule_description: ._source["kibana.alert.rule.description"],
    user_name: ._source.user.Ext.real.name,
    hostname: ._source.host.hostname,
    ips: ._source.host.ip
}')

if [ ! -z "$ALERTS" ]; then
    echo "$ALERTS" >> "$LOG_FILE"
fi

We could run this job in systemd or as a cron. This example checks the detections api for any alerts within the last 5 minutes.

One of the big benefits of wazuh is its customizeable to monitor ANY file you want to monitor. So we can configure the ossec to monitor this specific file we are outputting to:


<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/path/to/your/elastic-alerts.log</location>
  </localfile>
</ossec_config>

Then you could create a wazuh rule if it detects anything new in this logfile create an alert. You could then create an active response for when alerts are detected in this logfile. ie. slack message, email, etc.

aarz-snl commented 2 days ago

This is an example of what it would look lik ein ossec.conf for an active response configuration:

<ossec_config>
  <active-response>
    <command>slack-notify</command>
    <location>server</location>
    <rules_id>100050</rules_id>
    <timeout>0</timeout>
  </active-response>

  <command>
    <name>slack-notify</name>
    <executable>slack-notify.sh</executable>
    <expect></expect>
    <extra_args>https://hooks.slack.com/services/YOUR_WEBHOOK_URL_HERE</extra_args>
    <timeout_allowed>no</timeout_allowed>
  </command>
</ossec_config>

Based on a custom rule like so:

<group name="custom_rules,">
  <rule id="100050" level="12">
    <if_sid>5710</if_sid>
    <match>^Failed to authenticate|^Authentication failed</match>
    <description>Multiple failed logins in a short time period.</description>
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>
</group>

So any time our custom rule 100050 triggers --- the slack notify script will trigger. Custom rule would match more along the lines of whatever the script is loading into the log file we are tracking. This is just a generic example. Fill in as needed

We need to provide users the ability to edit the local rules xml file. For more than just this purpose. So, thought should be put into where we mount this volume.