Security Monitoring Platform in My Home Lab — Series 1 ~Building a Multi-Source Threat Detection Engine~

Disclaimer: All content in this article is based on experiments conducted in my personal home lab and test environment. This work is not affiliated with, endorsed by, or related to any company I currently work for or have worked for. All opinions are my own.

In this series, you will learn how to build comprehensive security monitoring platform that combines multiple open-source tools for threat detection. After spending many hours testing different approaches in my home lab, I created integrated system that processes data from vulnerability scanners, network monitors, and file watchers.

The Challenge

Many security teams struggle with alert fatigue from disconnected monitoring tools. Each tool generates its own alerts format, making it difficult to correlate threats across different data sources. In my home lab environment, I faced same challenges:

• Trivy generates vulnerability reports in JSON format
• Nuclei outputs findings in different schema
• Gitleaks detects secrets with unique alert structure
• Wazuh provides comprehensive SIEM but needs integration layer

I decided to build centralized platform that normalizes all these data sources and creates unified threat detection engine.

Architecture Overview

The monitoring platform consists of four main components:

1. Data Collection Layer

• Trivy: Container and filesystem vulnerability scanning
• Nuclei: Web application and network vulnerability assessment
• Gitleaks: Secret detection in code repositories
• System logs: OS-level monitoring via rsyslog

2. Data Processing Engine

• Wazuh Manager: Central processing and rule engine
• Custom decoders: Normalize different data formats
• Correlation rules: Link events across data sources
• Alert enrichment: Add context and threat intelligence

3. Storage & Indexing

• Elasticsearch: Event storage and fast searching
• File archiving: Long-term log retention
• Metrics storage: Performance and health data

4. Alerting & Visualization

• Wazuh Dashboard: Real-time monitoring interface
• Custom alerts: Email, Slack, webhook notifications
• Reporting: Automated daily/weekly summaries

Installation and Configuration

Setting Up Wazuh Manager

First, I installed Wazuh manager as the central hub:

# Download Wazuh installer
curl -sO https://packages.wazuh.com/4.7/wazuh-install.sh
sudo bash ./wazuh-install.sh -a

# Configure Wazuh manager for custom log processing
sudo vim /var/ossec/etc/ossec.conf

Integrating Trivy Scanner

I configured Trivy to send vulnerability reports to Wazuh:

# trivy-config.yaml
format: json
output: /var/log/trivy/scan-results.json
severity: 
  - CRITICAL
  - HIGH
  - MEDIUM
cache:
  ttl: 24h

# Automated scanning script
#!/bin/bash
SCAN_TIME=$(date +%Y%m%d_%H%M%S)
trivy filesystem --config trivy-config.yaml /home/user/projects/ 
trivy image --config trivy-config.yaml nginx:latest
logger "Trivy scan completed: $SCAN_TIME"

Nuclei Integration

For web application monitoring, I set up Nuclei with custom output format:

# nuclei-runner.sh
#!/bin/bash
nuclei -l /etc/nuclei/targets.txt \
       -severity critical,high,medium \
       -json-export /var/log/nuclei/findings.json \
       -rate-limit 10 \
       -retries 2

# Send results to Wazuh
cat /var/log/nuclei/findings.json | logger -p local7.info -t "NUCLEI"

Gitleaks Secret Detection

I configured Gitleaks to monitor code repositories:

# .gitleaks.toml
title = "Home Lab Gitleaks Config"

[extend]
useDefault = true

[[rules]]
id = "custom-api-key"
description = "Custom API key pattern"
regex = '''(?i)(api[_-]?key|apikey)\s*[:=]\s*['"][a-z0-9]{32,}['"]'''
keywords = ["apikey", "api_key"]

# Monitor git repositories
gitleaks detect --source=/home/user/repos \
                --config=.gitleaks.toml \
                --report-format=json \
                --report-path=/var/log/gitleaks/secrets.json

Custom Wazuh Decoders

To normalize different data formats, I created custom decoders:

<!-- /var/ossec/etc/decoders/local_decoders.xml -->

<!-- Trivy vulnerability decoder -->
<decoder name="trivy-vuln">
    <parent>json</parent>
    <program_name>trivy</program_name>
    <regex>"VulnerabilityID":"(CVE-\d+-\d+)"</regex>
    <order>vulnerability_id</order>
</decoder>

<!-- Nuclei finding decoder -->
<decoder name="nuclei-finding">
    <parent>json</parent>
    <program_name>NUCLEI</program_name>
    <regex>"template-id":"(\w+)"</regex>
    <order>template_id</order>
</decoder>

<!-- Gitleaks secret decoder -->
<decoder name="gitleaks-secret">
    <parent>json</parent>
    <program_name>gitleaks</program_name>
    <regex>"RuleID":"(\w+)"</regex>
    <order>rule_id</order>
</decoder>

Correlation Rules

I created correlation rules to detect attack patterns across multiple data sources:

<!-- /var/ossec/etc/rules/local_rules.xml -->

<group name="vulnerability_correlation">

  <!-- High severity vulnerability detected -->
  <rule id="100001" level="10">
    <decoded_as>trivy-vuln</decoded_as>
    <regex>"Severity":"CRITICAL"</regex>
    <description>Critical vulnerability detected by Trivy</description>
  </rule>

  <!-- Active exploitation attempt -->
  <rule id="100002" level="12">
    <decoded_as>nuclei-finding</decoded_as>
    <regex>"severity":"critical"</regex>
    <description>Critical security issue found by Nuclei</description>
  </rule>

  <!-- Correlation: vulnerability + exploitation -->
  <rule id="100010" level="15">
    <if_matched_sid>100001</if_matched_sid>
    <same_source_ip/>
    <if_matched_sid>100002</if_matched_sid>
    <timeframe>300</timeframe>
    <description>Possible exploitation of known vulnerability</description>
  </rule>

</group>

What Went Wrong - Troubleshooting Common Issues

During the setup, I encountered several challenges that took me quite some time to resolve:

Issue 1: Wazuh Log Parsing Failures

Symptoms: Custom logs weren't being parsed correctly, showing up as "unknown" events in dashboard.

Cause: I made syntax error in custom decoder XML and also the regex patterns were too strict.

Solution:

# Test decoder syntax
sudo /var/ossec/bin/wazuh-logtest
# Input your sample log and check if decoder matches

# Debug log processing
sudo tail -f /var/ossec/logs/ossec.log | grep "decoder"

The key was testing each decoder with actual log samples before deploying to production.

Issue 2: Performance Bottlenecks

Symptoms: Wazuh manager CPU usage spiked to 90%+ when processing Nuclei scans with many findings.

Cause: I configured too aggressive scanning frequency (every 5 minutes) and didn't set rate limits properly.

Solution:

# Optimized scanning frequency
*/30 * * * * /opt/nuclei/nuclei-runner.sh  # Every 30 minutes instead of 5

# Added rate limiting
nuclei -rate-limit 5 -bulk-size 10

Also moved heavy scanning to off-peak hours (2 AM - 6 AM).

Issue 3: False Positive Explosion

Symptoms: Getting hundreds of alerts daily, mostly false positives from development environments.

Cause: Rules were too broad and didn't exclude development/testing contexts.

Solution: Created whitelist rules and improved context detection:

<!-- Whitelist development environments -->
<rule id="100050" level="1">
  <regex>localhost|127.0.0.1|dev\.local|test\.local</regex>
  <description>Development environment - reduced priority</description>
</rule>

<!-- Suppress low-priority findings in dev -->
<rule id="100051" level="0">
  <if_matched_sid>100002</if_matched_sid>
  <regex>localhost|dev\.local</regex>
  <description>Low priority: development environment finding</description>
</rule>

Performance Metrics

After running the platform for two weeks, here are performance results:

• Daily events processed: ~15,000 security events
• Alert reduction: 89% fewer false positives compared to individual tools
• Detection time: Average 3.2 minutes from event to alert
• Storage efficiency: 60% reduction in log storage through deduplication
• Resource usage: 2 GB RAM, 15% CPU average

Next Steps

In the upcoming articles, I will cover:

1. Advanced correlation rules - Building behavioral detection patterns
2. Threat intelligence integration - Adding IOC feeds and reputation data
3. Automated response - SOAR capabilities with webhook integrations
4. Mobile alerting - Push notifications for critical findings
5. Compliance reporting - Automated audit reports

This multi-source monitoring approach has significantly improved my home lab security visibility. The unified dashboard makes it much easier to spot patterns and respond to threats quickly.

References

• Wazuh Documentation
• Trivy Documentation
• Nuclei Documentation
• Gitleaks Documentation
• MITRE ATT&CK Framework
• NIST Cybersecurity Framework

---

🔗 Full configuration files and automation scripts available on my GitHub repository: https://github.com/choshuoyaji/home-lab-security-stack

---

Tags: security, monitoring, SIEM, cybersecurity, homelab, wazuh, trivy, nuclei, threat-detection, automation