Project 1

SIEM Dashboard for Failed Login Attempts

Build a SIEM dashboard to monitor failed login attempts using Wazuh custom rules and alerts.

Detection EngineeringWazuhAuthentication Monitoring

Project objective

Build a focused Wazuh workflow that turns raw SSH authentication logs into a tuned detection rule and a reviewable stream of failed-login alerts — the smallest end-to-end pipeline a SOC analyst would rely on to catch brute-force and password-spray attempts against a monitored host.

Core work

The pipeline has three parts: get the right log source into Wazuh, write a custom rule that fires on repeated failures rather than every single one, then verify the alert end-to-end.

# 1. Ensure the agent ships SSH auth events to the manager
sudo nano /var/ossec/etc/ossec.conf
  <localfile>
    <log_format>syslog</log_format>
    <location>/var/log/auth.log</location>
  </localfile>
sudo systemctl restart wazuh-agent

# 2. Custom manager-side rule: 5 failures from the same source within 2 minutes
sudo nano /var/ossec/etc/rules/local_rules.xml
  <group name="authentication_failed,">
    <rule id="100010" level="10" frequency="5" timeframe="120">
      <if_matched_sid>5716</if_matched_sid>
      <same_source_ip />
      <description>Multiple failed SSH logins from the same source</description>
      <mitre><id>T1110</id></mitre>
    </rule>
  </group>

# 3. Validate rule syntax before trusting it in production
sudo /var/ossec/bin/wazuh-logtest

# 4. Apply and confirm the rule is actually firing
sudo systemctl restart wazuh-manager
sudo tail -f /var/ossec/logs/alerts/alerts.json | jq 'select(.rule.id=="100010")'

With the rule confirmed, the Wazuh dashboard's Security Events view was filtered to rule.id: 100010 and pinned as a saved search, giving a single pane showing every account under active brute-force pressure rather than every individual failed login.

00–04h

04–08h

08–12h

12–16h

16–20h

20–24h

Rule 100010 firings by hour over a 24h test window — the 16–20h spike corresponds to a scripted brute-force run used to validate the rule.

What to document

The write-up captures the custom rule XML, a wazuh-logtest validation run, a dashboard screenshot of the filtered alert stream, and a short trace of one alert from raw syslog line → Wazuh decoder → rule match → dashboard entry, so the whole pipeline is auditable rather than a black box.