Ziel: Cribl Edge auf einer Windows-Workstation und dem Ubuntu NUC-HA installieren,
sicherheitsrelevante Log-Quellen aktivieren und an den Cribl Stream Leader (10.10.0.100:4200) anbinden.
Alle Events fliessen durch die ollama_classifier Pipeline zur Klassifikation (SIEM vs. Operational).
1. Architekturuebersicht
Windows Workstation Ubuntu NUC-HA
+-----------------------+ +-----------------------+
| Cribl Edge | | Cribl Edge |
| - WinEventLog | | - Journal/Syslog |
| - Sysmon | | - auditd |
| - PowerShell Logs | | - auth.log |
| - Firewall Logs | | - UFW Logs |
| - DNS Client Logs | | - Docker Logs |
+----------+------------+ +----------+------------+
| tcp://10.10.0.100:4200 |
+----------------+-----------------+
|
+---------v----------+
| Cribl Stream Leader |
| (10.10.0.100) |
| ollama_classifier |
+--+-------+------+--+
| | |
SIEM | Ops | | Ops
+---v----+ +-v------v-+ +--v----------+
| Splunk | | ES/ | | MinIO S3 |
| HEC | | Kibana | | (Archiv) |
| :8088 | | :9200 | | :9100 |
+--------+ +----------+ +-------------+
10.10.0.66 10.10.0.100 10.10.0.100
Routing-Logik:
classification == 'siem' → Splunk HEC (10.10.0.66:8088) — Sicherheitsanalyse, SIEM-Dashboards, Alerting
classification == 'operational' → Elasticsearch (Kibana) + MinIO S3 — Betriebsmonitoring + Langzeitarchiv
| Komponente | IP / Port | Funktion |
| Cribl Stream Leader | 10.10.0.100:4200 | Fleet Management, Pipeline Processing |
| Cribl Stream API/UI | 10.10.0.100:9000 | Administration, API |
| Splunk Enterprise | 10.10.0.66:8000 / :8088 | SIEM-Ziel: Security-Events via HEC |
| Windows Workstation | (DHCP / manuell) | Cribl Edge + Security Logging |
| NUC-HA (Ubuntu) | 10.10.0.100 | Cribl Edge + auditd + Docker |
| Elasticsearch + Kibana | 10.10.0.100:9200 / :5601 | Operational Logs + Dashboard |
| MinIO S3 | 10.10.0.100:9100 | Langzeit-Archiv (operational) |
2. Windows Cribl Edge Installation
2.1 Voraussetzungen
- Windows 10/11 Pro oder Server 2019+
- Administratorrechte
- Netzwerkverbindung zum Stream Leader (10.10.0.100:4200)
- Min. 512 MB RAM, 1 GB Disk fuer Edge
2.2 MSI-Download & Installation
Wichtig: Die CDN-Download-URLs fuer Cribl Edge enthalten einen Build-Hash, der sich pro Release aendert.
Direkte URL-Konstruktion funktioniert nicht (404-Fehler).
Nutze eine der folgenden Methoden:
Option A: Download ueber Cribl Stream UI (empfohlen)
- Cribl Stream UI oeffnen: http://10.10.0.100:9000
- In der linken Sidebar auf Fleets klicken (oder oben Products → Edge)
- Die default_fleet oeffnen (Free-Lizenz: 1 Fleet fuer alle Edge Nodes)
- Klicke Add/Update Edge Node
- Tab Windows waehlen → Add klicken
- Felder ausfuellen:
- Fleet:
default_fleet
- Leader hostname/IP:
10.10.0.100
- Die UI generiert ein PowerShell-Installationsskript mit korrekter CDN-URL und Auth-Token
- Kopiere das Skript und fuehre es auf der Windows-Workstation als Administrator aus
Free-Lizenz: Erlaubt max. 1 Edge Fleet und 1 Worker Group.
Alle Edge Nodes (Windows + Linux) kommen in die default_fleet.
Fuer separate Fleets pro OS ist eine Enterprise-Lizenz erforderlich.
Option B: Manueller Download von cribl.io
- Oeffne https://cribl.io/download/
- Waehle Software: Cribl Edge, Platform: Windows
- Lade die MSI-Datei herunter (ca. 120 MB)
# PowerShell (als Administrator)
# Die heruntergeladene MSI installieren:
# Variante 1: Interaktive Installation
msiexec /i "C:\Users\DEINUSER\Downloads\cribl-edge-4.16.1-XXXXXXXX-msi-x64.msi"
# Variante 2: Silent Installation mit Fleet-Anbindung
msiexec /qn /i "C:\Users\DEINUSER\Downloads\cribl-edge-4.16.1-XXXXXXXX-msi-x64.msi" `
MODE=mode-managed-edge `
HOSTNAME=10.10.0.100 `
PORT=4200 `
FLEET=default_fleet
# 2. Service pruefen
Get-Service -Name "CriblEdge" | Format-Table Name, Status, StartType
# 3. Konnektivitaet testen
Test-NetConnection -ComputerName 10.10.0.100 -Port 4200
Installierte Version: Cribl Stream Leader laeuft in Version 4.16.1.
Die Edge-Version sollte identisch oder kompatibel sein.
Firewall-Regel: Falls der Edge-Dienst keine Verbindung herstellen kann:
# Windows Firewall: Outbound erlauben
New-NetFirewallRule -DisplayName "Cribl Edge to Stream" `
-Direction Outbound -RemotePort 4200 -Protocol TCP -Action Allow
2.3 Installation verifizieren
# Service-Status
Get-Service -Name "CriblEdge" | Format-Table Name, Status, StartType
# Edge-Logs pruefen (Verbindung zum Leader)
Get-Content "C:\Program Files\Cribl\Edge\log\cribl.log" -Tail 20 | Select-String "connected|master|error"
# In Cribl Stream UI pruefen:
# http://10.10.0.100:9000 -> Sidebar: Fleets -> default_fleet -> Nodes
# Der Windows-Host sollte als verbundener Edge Node erscheinen
# Direkt-Link: http://10.10.0.100:9000/edge/fleets
2.4 Komplett-Skript: Edge + Sysmon in einem Schritt
All-in-One: Dieses Skript installiert Sysmon direkt nach der Edge-Installation,
damit Security-Events sofort gesammelt werden koennen. Als Administrator in PowerShell ausfuehren.
# ============================================================
# IceDataEmphasise: Windows Edge + Sysmon Quick Setup
# PowerShell als Administrator ausfuehren
# ============================================================
Write-Host "=== Phase 1: Sysmon installieren ===" -ForegroundColor Cyan
# 1. Sysmon herunterladen
$sysmonDir = "$env:TEMP\Sysmon"
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" `
-OutFile "$env:TEMP\Sysmon.zip"
Expand-Archive "$env:TEMP\Sysmon.zip" -DestinationPath $sysmonDir -Force
# 2. SwiftOnSecurity Sysmon-Konfiguration herunterladen
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" `
-OutFile "$sysmonDir\sysmonconfig.xml"
# 3. Sysmon installieren
& "$sysmonDir\Sysmon64.exe" -accepteula -i "$sysmonDir\sysmonconfig.xml"
# 4. Pruefen
Get-Service Sysmon64 | Format-Table Name, Status, StartType
Write-Host "Sysmon Events:" -ForegroundColor Green
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 3 | `
Format-Table TimeCreated, Id, Message -Wrap
Write-Host ""
Write-Host "=== Phase 2: Audit Policies setzen ===" -ForegroundColor Cyan
# Erweiterte Audit-Policies fuer Security-Monitoring
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Computer Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
Write-Host ""
Write-Host "=== Phase 3: PowerShell Script Block Logging ===" -ForegroundColor Cyan
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
New-Item -Path $regPath -Force | Out-Null
Set-ItemProperty -Path $regPath -Name "EnableScriptBlockLogging" -Value 1 -Type DWord
Write-Host ""
Write-Host "=== Phase 4: Cribl Edge pruefen ===" -ForegroundColor Cyan
$edgeSvc = Get-Service -Name "CriblEdge" -ErrorAction SilentlyContinue
if ($edgeSvc) {
Write-Host "Cribl Edge Status: $($edgeSvc.Status)" -ForegroundColor Green
Get-Content "C:\Program Files\Cribl\Edge\log\cribl.log" -Tail 5 | `
Select-String "connected|master"
} else {
Write-Host "Cribl Edge nicht installiert!" -ForegroundColor Red
Write-Host "Bitte zuerst Edge ueber Stream UI installieren:" -ForegroundColor Yellow
Write-Host " http://10.10.0.100:9000 -> Sidebar: Fleets -> default_fleet" -ForegroundColor Yellow
Write-Host " -> Add/Update Edge Node -> Windows -> Add" -ForegroundColor Yellow
}
Write-Host ""
Write-Host "=== Setup abgeschlossen ===" -ForegroundColor Green
Write-Host "Pruefen: http://10.10.0.100:9000/edge/fleets" -ForegroundColor Cyan
3. Windows OS Security Logging aktivieren
Warum? Windows generiert standardmaessig nur minimale Security-Logs.
Fuer SIEM-relevante Daten muessen erweiterte Audit-Policies, Sysmon und PowerShell-Logging aktiviert werden.
3.1 Erweiterte Audit-Policies (GPO)
Die wichtigsten Audit-Kategorien fuer Security-Monitoring:
# PowerShell (als Administrator) - Erweiterte Audit-Policies setzen
# Account Logon - Erkennung von Brute-Force und Credential-Angriffen
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
# Account Management - User/Gruppen-Aenderungen erkennen
auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable
auditpol /set /subcategory:"Computer Account Management" /success:enable /failure:enable
# Logon/Logoff - Anmeldevorgaenge ueberwachen
auditpol /set /subcategory:"Logon" /success:enable /failure:enable
auditpol /set /subcategory:"Logoff" /success:enable
auditpol /set /subcategory:"Special Logon" /success:enable
auditpol /set /subcategory:"Other Logon/Logoff Events" /success:enable /failure:enable
# Object Access - Dateizugriffe und Registry
auditpol /set /subcategory:"File System" /success:enable /failure:enable
auditpol /set /subcategory:"Registry" /failure:enable
auditpol /set /subcategory:"Removable Storage" /success:enable /failure:enable
# Policy Change - Sicherheitsrichtlinien-Aenderungen
auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable
auditpol /set /subcategory:"Authentication Policy Change" /success:enable
# Privilege Use - Privilegierte Aktionen
auditpol /set /subcategory:"Sensitive Privilege Use" /success:enable /failure:enable
# Process Tracking - Prozesserstellung (wichtig fuer Malware-Erkennung)
auditpol /set /subcategory:"Process Creation" /success:enable
auditpol /set /subcategory:"Process Termination" /success:enable
# Ergebnis pruefen
auditpol /get /category:*
3.2 Sysmon installieren (Microsoft Sysinternals)
Sysmon ist das wichtigste Werkzeug fuer Endpoint Detection.
Es protokolliert Prozesserstellung, Netzwerkverbindungen, Datei-Hashes, DLL-Loads, Registry-Aenderungen und mehr.
MITRE ATT&CK Mapping: T1059 (Command Execution), T1053 (Scheduled Tasks), T1055 (Process Injection), T1547 (Boot Persistence).
# PowerShell (als Administrator)
# 1. Sysmon herunterladen
Invoke-WebRequest -Uri "https://download.sysinternals.com/files/Sysmon.zip" `
-OutFile "$env:TEMP\Sysmon.zip"
Expand-Archive "$env:TEMP\Sysmon.zip" -DestinationPath "$env:TEMP\Sysmon" -Force
# 2. Sysmon-Konfiguration herunterladen (SwiftOnSecurity - Community Standard)
Invoke-WebRequest -Uri "https://raw.githubusercontent.com/SwiftOnSecurity/sysmon-config/master/sysmonconfig-export.xml" `
-OutFile "$env:TEMP\Sysmon\sysmonconfig.xml"
# 3. Sysmon installieren mit Konfiguration
& "$env:TEMP\Sysmon\Sysmon64.exe" -accepteula -i "$env:TEMP\Sysmon\sysmonconfig.xml"
# 4. Pruefen
Get-Service Sysmon64 | Format-Table Name, Status
Get-WinEvent -LogName "Microsoft-Windows-Sysmon/Operational" -MaxEvents 5 | Format-Table TimeCreated, Id, Message -Wrap
Sysmon generiert Events in folgenden Kategorien:
| Event ID | Beschreibung | SIEM-Relevanz |
| 1 | Process Create | Malware-Erkennung, LOLBins |
| 3 | Network Connection | C2-Kommunikation, Lateral Movement |
| 7 | Image Loaded (DLL) | DLL Hijacking, Injection |
| 8 | CreateRemoteThread | Process Injection (T1055) |
| 10 | Process Access | Credential Dumping (Mimikatz) |
| 11 | File Create | Malware-Drops, Ransomware |
| 12/13/14 | Registry Events | Persistence (T1547) |
| 22 | DNS Query | DNS Tunneling, C2 Beaconing |
| 23 | File Delete (archived) | Anti-Forensics |
| 25 | Process Tampering | Process Hollowing |
3.3 PowerShell Script Block Logging
# Registry-Keys setzen (PowerShell als Administrator)
# Script Block Logging aktivieren - protokolliert ALLE ausgefuehrten PowerShell-Befehle
$regPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging"
New-Item -Path $regPath -Force | Out-Null
Set-ItemProperty -Path $regPath -Name "EnableScriptBlockLogging" -Value 1
# Module Logging aktivieren - protokolliert Modul-Aufruf-Details
$regPath2 = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ModuleLogging"
New-Item -Path $regPath2 -Force | Out-Null
Set-ItemProperty -Path $regPath2 -Name "EnableModuleLogging" -Value 1
New-Item -Path "$regPath2\ModuleNames" -Force | Out-Null
Set-ItemProperty -Path "$regPath2\ModuleNames" -Name "*" -Value "*"
# Transcription Logging (optional - schreibt alle PS-Sessions in Dateien)
$regPath3 = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\Transcription"
New-Item -Path $regPath3 -Force | Out-Null
Set-ItemProperty -Path $regPath3 -Name "EnableTranscripting" -Value 1
Set-ItemProperty -Path $regPath3 -Name "OutputDirectory" -Value "C:\PSTranscripts"
New-Item -Path "C:\PSTranscripts" -ItemType Directory -Force | Out-Null
# Pruefen - Event Log "Microsoft-Windows-PowerShell/Operational" Event ID 4104
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 3 | Format-Table TimeCreated, Id
3.4 Windows Firewall Logging
# PowerShell (als Administrator)
# Firewall-Logging fuer alle Profile aktivieren
Set-NetFirewallProfile -Profile Domain,Private,Public `
-LogAllowed True -LogBlocked True `
-LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log" `
-LogMaxSizeKilobytes 32768
# Pruefen
Get-NetFirewallProfile | Format-Table Name, LogAllowed, LogBlocked, LogFileName
3.5 Windows DNS Client Logging
# DNS Client ETW Logging aktivieren (ab Windows 10 1903+)
# Generiert Events in "Microsoft-Windows-DNS-Client/Operational"
wevtutil sl "Microsoft-Windows-DNS-Client/Operational" /e:true
# Alternativ: DNS Analytic Log (verbose)
wevtutil sl "Microsoft-Windows-DNS-Client/Operational" /e:true /rt:true
3.6 Event Log Groessen anpassen
# Standardmaessig sind Security-Logs nur 20 MB - viel zu klein
wevtutil sl Security /ms:1073741824 # 1 GB
wevtutil sl "Microsoft-Windows-Sysmon/Operational" /ms:1073741824
wevtutil sl "Microsoft-Windows-PowerShell/Operational" /ms:524288000 # 500 MB
wevtutil sl System /ms:524288000
wevtutil sl Application /ms:268435456 # 256 MB
Ergebnis: Nach diesen Einstellungen generiert Windows Security-relevante Events in:
Security - Logins, Account-Aenderungen, Privilege Use (~Event IDs 4624-4634, 4720-4738, 4672)
Microsoft-Windows-Sysmon/Operational - Prozesse, Netzwerk, Dateien, Registry
Microsoft-Windows-PowerShell/Operational - Script Block Logs (Event ID 4104)
Windows PowerShell - Klassische Engine-Logs (Event ID 400, 800)
System - Service-Aenderungen, Treiber-Loads
4. Windows Edge Quellen konfigurieren
Konfiguration ueber Cribl Stream UI:
Sidebar → Fleets →
default_fleet oeffnen →
More → Sources
Alternativ per API auf dem Edge oder ueber die Fleet-Konfiguration.
4.1 Windows Event Log Collector (WinEventLog)
In der Cribl Stream UI unter Sources → Windows Event Logs folgende Channels anlegen:
| Channel Name | Event Log | SIEM-Relevanz |
| security_events | Security | Logins, Failed Auth, Account Changes |
| sysmon_events | Microsoft-Windows-Sysmon/Operational | Process, Network, File, Registry |
| powershell_events | Microsoft-Windows-PowerShell/Operational | Script Block Logging |
| powershell_classic | Windows PowerShell | Engine Start/Stop |
| system_events | System | Service Changes, Driver Loads |
| defender_events | Microsoft-Windows-Windows Defender/Operational | Malware-Erkennungen |
| firewall_events | Microsoft-Windows-Windows Firewall With Advanced Security/Firewall | Firewall Rule Changes |
| dns_client | Microsoft-Windows-DNS-Client/Operational | DNS Queries (C2 Detection) |
| task_scheduler | Microsoft-Windows-TaskScheduler/Operational | Persistence via Scheduled Tasks |
4.2 Beispiel: Edge Source Konfiguration (JSON)
{
"id": "win_event_logs",
"type": "wineventlog",
"disabled": false,
"conf": {
"channels": [
{ "name": "Security", "filterXPath": "*" },
{ "name": "Microsoft-Windows-Sysmon/Operational", "filterXPath": "*" },
{ "name": "Microsoft-Windows-PowerShell/Operational",
"filterXPath": "*[System[(EventID=4104 or EventID=4103)]]" },
{ "name": "System",
"filterXPath": "*[System[(Level=1 or Level=2 or Level=3)]]" },
{ "name": "Microsoft-Windows-Windows Defender/Operational",
"filterXPath": "*[System[(EventID=1006 or EventID=1007 or EventID=1008 or EventID=1009 or EventID=1116 or EventID=1117)]]" },
{ "name": "Microsoft-Windows-TaskScheduler/Operational",
"filterXPath": "*[System[(EventID=106 or EventID=140 or EventID=141)]]" }
],
"bookmarkFrequency": 10,
"batchSize": 100
},
"description": "Windows Security Event Collection"
}
4.3 Erwartete Event-IDs fuer SIEM
| Event ID | Log | Beschreibung | MITRE ATT&CK |
| 4624 | Security | Erfolgreiche Anmeldung | T1078 Valid Accounts |
| 4625 | Security | Fehlgeschlagene Anmeldung | T1110 Brute Force |
| 4648 | Security | Anmeldung mit expliziten Credentials | T1550 Use Alternate Auth |
| 4672 | Security | Spezielle Privilegien zugewiesen | T1078.002 Domain Accounts |
| 4720 | Security | Benutzerkonto erstellt | T1136 Create Account |
| 4732 | Security | Mitglied zu Gruppe hinzugefuegt | T1098 Account Manipulation |
| 4688 | Security | Neuer Prozess erstellt | T1059 Command Execution |
| 7045 | System | Neuer Service installiert | T1543 Create or Modify Service |
| 1 | Sysmon | Process Create (mit Hash + Parent) | T1059, T1204 |
| 3 | Sysmon | Network Connection | T1071 Application Layer Protocol |
| 11 | Sysmon | File Create | T1105 Ingress Tool Transfer |
| 4104 | PowerShell | Script Block (voller Befehlstext) | T1059.001 PowerShell |
| 1116/1117 | Defender | Malware erkannt / Aktion ausgefuehrt | Multiple |
5. Ubuntu Cribl Edge Installation
5.1 Voraussetzungen
- Ubuntu 20.04+ / Debian 11+ (NUC-HA: Debian 13 bookworm/trixie)
- Root- oder sudo-Zugang
- Netzwerkverbindung zum Stream Leader (10.10.0.100:4200)
Hinweis: Da der NUC-HA (10.10.0.100) gleichzeitig Cribl Stream Leader ist,
verbindet sich Edge lokal ueber tcp://127.0.0.1:4200.
5.2 Installation
#!/bin/bash
# Als root oder mit sudo ausfuehren
# 1. Variablen
CRIBL_VERSION="4.16.1"
EDGE_HOME="/opt/cribl-edge"
MASTER_URL="tcp://127.0.0.1:4200" # Lokal, da Stream auf gleichem Host
# 2. Download und Installation
curl -Lso /tmp/cribl-edge.tgz \
"https://cdn.cribl.io/dl/${CRIBL_VERSION}/cribl-edge-${CRIBL_VERSION}-linux-x64.tgz"
mkdir -p "${EDGE_HOME}"
tar xzf /tmp/cribl-edge.tgz -C /opt/ --transform='s/^cribl/cribl-edge/'
# 3. Service-User (falls nicht vorhanden)
id cribl &>/dev/null || useradd -r -s /bin/false -d ${EDGE_HOME} cribl
# 4. Konfiguration
cat > ${EDGE_HOME}/local/cribl/cribl.yml <<'YAML'
distributed:
mode: managed-edge
master:
url: tcp://127.0.0.1:4200
tls:
disabled: true
YAML
chown -R cribl:cribl ${EDGE_HOME}
# 5. Systemd Service
cat > /etc/systemd/system/cribl-edge.service <<'SVC'
[Unit]
Description=Cribl Edge
After=network-online.target cribl.service
Wants=network-online.target
[Service]
Type=simple
User=cribl
Group=cribl
ExecStart=/opt/cribl-edge/bin/cribl server
Restart=always
RestartSec=5
LimitNOFILE=65536
Environment=CRIBL_DIST_MODE=managed-edge
[Install]
WantedBy=multi-user.target
SVC
systemctl daemon-reload
systemctl enable --now cribl-edge.service
# 6. Pruefen
sleep 5
systemctl status cribl-edge --no-pager
journalctl -u cribl-edge --no-pager -n 10 | grep -i "connected\|master\|error"
6. Ubuntu OS Security Logging aktivieren
6.1 auditd installieren & konfigurieren
auditd ist das Linux-Aequivalent zu Sysmon. Es protokolliert Syscalls, Dateizugriffe,
Prozesserstellung, Netzwerk-Sockets und Benutzeraktionen auf Kernel-Ebene.
# 1. Installation
sudo apt update && sudo apt install -y auditd audispd-plugins
# 2. Audit-Daemon aktivieren
sudo systemctl enable --now auditd
6.1.1 Audit-Regeln (SIEM-optimiert)
# Datei: /etc/audit/rules.d/siem-security.rules
# ================================================
# IceDataEmphasise - Security Audit Rules
# Basierend auf CIS Benchmark + MITRE ATT&CK
# ================================================
# Buffer und Fehlerbehandlung
-b 8192
-f 1
--backlog_wait_time 0
# --- Authentifizierung & Autorisierung ---
# Logins und Authentifizierungsdateien ueberwachen
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity
# sudoers-Aenderungen
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers
# SSH-Konfiguration
-w /etc/ssh/sshd_config -p wa -k sshd_config
-w /etc/ssh/sshd_config.d/ -p wa -k sshd_config
# PAM-Konfiguration
-w /etc/pam.d/ -p wa -k pam
# --- Prozesse & Ausfuehrung ---
# Prozesserstellung (execve) - Aequivalent zu Sysmon Event ID 1
-a always,exit -F arch=b64 -S execve -k exec
-a always,exit -F arch=b32 -S execve -k exec
# Privilegierte Befehle (setuid/setgid)
-a always,exit -F path=/usr/bin/sudo -F perm=x -k priv_cmd
-a always,exit -F path=/usr/bin/su -F perm=x -k priv_cmd
-a always,exit -F path=/usr/bin/chsh -F perm=x -k priv_cmd
-a always,exit -F path=/usr/bin/passwd -F perm=x -k priv_cmd
-a always,exit -F path=/usr/bin/crontab -F perm=x -k priv_cmd
-a always,exit -F path=/usr/sbin/useradd -F perm=x -k priv_cmd
-a always,exit -F path=/usr/sbin/userdel -F perm=x -k priv_cmd
-a always,exit -F path=/usr/sbin/usermod -F perm=x -k priv_cmd
-a always,exit -F path=/usr/sbin/groupadd -F perm=x -k priv_cmd
# --- Netzwerk ---
# Socket-Erstellung (C2 Detection)
-a always,exit -F arch=b64 -S socket -F a0=2 -k network_connect
-a always,exit -F arch=b64 -S connect -k network_connect
# Netzwerkkonfiguration geaendert
-w /etc/hosts -p wa -k network_config
-w /etc/hostname -p wa -k network_config
-w /etc/resolv.conf -p wa -k network_config
-w /etc/network/ -p wa -k network_config
-w /etc/netplan/ -p wa -k network_config
# --- Persistence-Mechanismen ---
# Cronjobs
-w /etc/crontab -p wa -k cron
-w /etc/cron.d/ -p wa -k cron
-w /etc/cron.daily/ -p wa -k cron
-w /etc/cron.hourly/ -p wa -k cron
-w /var/spool/cron/ -p wa -k cron
# Systemd Services (Persistence T1543)
-w /etc/systemd/system/ -p wa -k systemd_persist
-w /usr/lib/systemd/system/ -p wa -k systemd_persist
-w /run/systemd/system/ -p wa -k systemd_persist
# Autostart
-w /etc/init.d/ -p wa -k init_persist
-w /etc/rc.local -p wa -k init_persist
# --- Kernel & Module ---
-w /sbin/insmod -p x -k kernel_module
-w /sbin/rmmod -p x -k kernel_module
-w /sbin/modprobe -p x -k kernel_module
-a always,exit -F arch=b64 -S init_module -S finit_module -k kernel_module
-a always,exit -F arch=b64 -S delete_module -k kernel_module
# --- Docker-spezifisch ---
-w /usr/bin/docker -p x -k docker_cmd
-w /var/lib/docker/ -p wa -k docker_data
-w /etc/docker/ -p wa -k docker_config
-w /usr/lib/systemd/system/docker.service -p wa -k docker_service
# --- Log-Manipulation erkennen ---
-w /var/log/ -p wa -k log_tampering
-w /etc/rsyslog.conf -p wa -k log_config
-w /etc/rsyslog.d/ -p wa -k log_config
# Regeln immutable machen (erst nach dem Testen aktivieren!)
# -e 2
# Regeln laden
sudo cp siem-security.rules /etc/audit/rules.d/siem-security.rules
sudo augenrules --load
sudo auditctl -l | head -20 # Geladene Regeln pruefen
sudo auditctl -s # Status pruefen
6.2 rsyslog: Auth-Logs sicherstellen
# Pruefen ob auth.log geschrieben wird
ls -la /var/log/auth.log
# Falls nicht vorhanden, rsyslog-Regel sicherstellen:
sudo grep -r "auth\." /etc/rsyslog.d/ /etc/rsyslog.conf
# Falls fehlend, hinzufuegen:
echo 'auth,authpriv.* /var/log/auth.log' | sudo tee /etc/rsyslog.d/50-auth.conf
sudo systemctl restart rsyslog
6.3 UFW Firewall Logging
# UFW aktivieren (falls nicht bereits aktiv)
sudo ufw status
# Logging auf medium setzen (blockierte UND erlaubte Verbindungen)
sudo ufw logging medium
# Regeln fuer bekannte Services (Cribl, SSH, etc.)
sudo ufw allow 22/tcp comment "SSH"
sudo ufw allow from 10.10.0.0/24 to any port 4200 proto tcp comment "Cribl Fleet"
sudo ufw allow from 10.10.0.0/24 to any port 9000 proto tcp comment "Cribl UI"
sudo ufw allow from 10.10.0.0/24 to any port 9200 proto tcp comment "Elasticsearch"
sudo ufw allow from 10.10.0.0/24 to any port 5601 proto tcp comment "Kibana"
sudo ufw allow from 10.10.0.0/24 to any port 8080 proto tcp comment "Docs"
# UFW aktivieren
sudo ufw --force enable
# Logs landen in /var/log/ufw.log und /var/log/kern.log
tail -5 /var/log/ufw.log 2>/dev/null || echo "UFW-Logs in kern.log/syslog"
6.4 fail2ban installieren (SSH Brute-Force Protection + Logs)
# Installation
sudo apt install -y fail2ban
# Konfiguration
sudo cat > /etc/fail2ban/jail.local <<'JAIL'
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
backend = systemd
[sshd]
enabled = true
port = ssh
filter = sshd
maxretry = 3
JAIL
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd
6.5 journald-Speicher erhoehen
# Standardmaessig rotiert journald nach 4GB oder bei wenig Platz
sudo mkdir -p /etc/systemd/journald.conf.d/
cat | sudo tee /etc/systemd/journald.conf.d/retention.conf <<'CONF'
[Journal]
SystemMaxUse=2G
MaxRetentionSec=30day
Compress=yes
CONF
sudo systemctl restart systemd-journald
Ergebnis: Nach diesen Einstellungen generiert Ubuntu Security-relevante Events in:
/var/log/audit/audit.log - auditd: Syscalls, Dateizugriffe, Prozesse, Netzwerk
/var/log/auth.log - SSH-Logins, sudo, PAM-Events
journald - systemd-Services, Docker-Container, Kernel-Messages
/var/log/ufw.log - Firewall-Events (blockiert/erlaubt)
/var/log/fail2ban.log - Brute-Force-Erkennungen
7. Ubuntu Edge Quellen konfigurieren
7.1 Cribl Edge Berechtigungen
# Der cribl-User muss die Log-Dateien lesen koennen
sudo usermod -aG adm cribl # /var/log/auth.log, syslog
sudo usermod -aG systemd-journal cribl # journald
sudo setfacl -R -m u:cribl:r /var/log/audit/ # auditd logs
sudo setfacl -d -m u:cribl:r /var/log/audit/ # fuer neue Dateien
# Neustart fuer Gruppeneffekt
sudo systemctl restart cribl-edge
7.2 Edge Sources
| Source | Typ | Pfad / Config | SIEM-Inhalt |
| audit_log | File Monitor | /var/log/audit/audit.log | Syscalls, execve, Dateizugriffe, Netzwerk |
| auth_log | File Monitor | /var/log/auth.log | SSH, sudo, PAM, Login/Logout |
| syslog | File Monitor | /var/log/syslog | System-Events, Kernel, Services |
| ufw_log | File Monitor | /var/log/ufw.log | Firewall Allow/Block |
| fail2ban_log | File Monitor | /var/log/fail2ban.log | Ban/Unban Events |
| journal_docker | Journald | Filter: _SYSTEMD_UNIT=docker.service | Docker-Daemon + Container-Logs |
| journal_ssh | Journald | Filter: SYSLOG_IDENTIFIER=sshd | SSH-Sessions im Detail |
7.3 Beispiel: File Monitor Source (JSON)
{
"id": "linux_security_files",
"type": "file_monitor",
"disabled": false,
"conf": {
"paths": [
"/var/log/audit/audit.log",
"/var/log/auth.log",
"/var/log/syslog",
"/var/log/ufw.log",
"/var/log/fail2ban.log"
],
"sendRawData": true,
"preprocess": {
"disabled": true
},
"tailOnly": false
},
"description": "Linux Security Log Files"
}
8. Cribl Stream: Fleet & Routing
8.1 Fleet konfigurieren
Free-Lizenz-Limit: Maximal 1 Edge Fleet erlaubt.
Alle Edge Nodes (Windows + Linux) nutzen die default_fleet.
In Cribl Stream UI (http://10.10.0.100:9000/edge/fleets):
- In der linken Sidebar auf Fleets klicken
- Die
default_fleet oeffnen
- Add/Update Edge Node → Windows/Linux Tab → Bootstrap-Skript kopieren
- Sources konfigurieren: Fleet oeffnen → More → Sources
Tipp: Mit Enterprise-Lizenz koennen separate Fleets angelegt werden
(windows-security, linux-security) fuer getrennte Konfigurationen pro OS.
8.2 Pipeline-Erweiterung: Security Keywords
Der bestehende ollama_classifier erkennt bereits Security-Keywords.
Fuer die neuen Quellen sollten zusaetzliche Regeln hinzugefuegt werden:
// Neue Regel fuer auditd-Events
filter: log_message && /^type=(EXECVE|SYSCALL|USER_AUTH|USER_LOGIN|USER_CMD|ANOM_|CRYPTO_KEY)/i.test(log_message)
classification = 'siem'
classification_reason = 'auditd_security_event'
// Neue Regel fuer Windows Security Event IDs
filter: log_message && /EventID["\s:=]+(4625|4648|4672|4720|4732|4738|7045|1102)/i.test(log_message)
classification = 'siem'
classification_reason = 'windows_security_event_id'
// Neue Regel fuer Sysmon
filter: log_message && /Microsoft-Windows-Sysmon.*(EventID["\s:=]+(1|3|7|8|10|11|12|13|22|23|25))/i.test(log_message)
classification = 'siem'
classification_reason = 'sysmon_detection'
// Neue Regel fuer fail2ban
filter: log_message && /fail2ban.*(Ban|Found)/i.test(log_message)
classification = 'siem'
classification_reason = 'fail2ban_alert'
8.3 Routing (SIEM → Splunk, Operational → ES/S3)
Routing-Prinzip: Alle Events durchlaufen die ollama_classifier Pipeline.
SIEM-klassifizierte Events gehen an Splunk fuer Security-Analyse und Alerting.
Operational Events gehen an Elasticsearch/Kibana + MinIO S3.
| Route | Filter | Pipeline | Destination | Final |
| route_siem_to_splunk | classification=='siem' | passthru | splunk_hec (10.10.0.66:8088) | Ja |
| route_ops_to_s3 | classification=='operational' | passthru | minio_s3 | Nein |
| route_ops_to_es | classification=='operational' | passthru | elasticsearch_ops | Ja |
| route_classify_all | true | ollama_classifier | default (re-routes) | Nein |
# Route-Reihenfolge in Cribl Stream:
# 1. ollama_classifier Pipeline (klassifiziert alle Events)
# 2. SIEM-Events -> Splunk HEC (Security-Analyse)
# 3. Operational -> MinIO S3 (Langzeitarchiv) + Elasticsearch (Kibana)
# 4. Catch-all -> Splunk HEC (Sicherheitsnetz)
9. Splunk Enterprise: HEC & CriblVision Setup (10.10.0.66)
Ziel: Splunk Enterprise auf 10.10.0.66 so konfigurieren, dass es SIEM-Events von Cribl Stream
via HTTP Event Collector (HEC) empfaengt. Zusaetzlich wird CriblVision installiert fuer Cribl-Monitoring-Dashboards.
9.1 Splunk: Index fuer SIEM-Events anlegen
# Splunk CLI (auf 10.10.0.66 als root/splunk-user):
/opt/splunk/bin/splunk add index cribl_siem \
-homePath '$SPLUNK_DB/cribl_siem/db' \
-coldPath '$SPLUNK_DB/cribl_siem/colddb' \
-thawedPath '$SPLUNK_DB/cribl_siem/thaweddb' \
-frozenTimePeriodInSecs 7776000 \
-auth admin:SPLUNK_PASSWORT
# Oder ueber Splunk Web UI:
# Settings -> Indexes -> New Index
# Name: cribl_siem
# Max Size of Entire Index: 50 GB
# Retention: 90 Tage
Optional: Weitere Indexes fuer Quellen-Trennung:
# indexes.conf ($SPLUNK_HOME/etc/system/local/indexes.conf)
[cribl_siem]
homePath = $SPLUNK_DB/cribl_siem/db
coldPath = $SPLUNK_DB/cribl_siem/colddb
thawedPath = $SPLUNK_DB/cribl_siem/thaweddb
frozenTimePeriodInSecs = 7776000
[cribl_siem_windows]
homePath = $SPLUNK_DB/cribl_siem_windows/db
coldPath = $SPLUNK_DB/cribl_siem_windows/colddb
thawedPath = $SPLUNK_DB/cribl_siem_windows/thaweddb
frozenTimePeriodInSecs = 7776000
[cribl_siem_linux]
homePath = $SPLUNK_DB/cribl_siem_linux/db
coldPath = $SPLUNK_DB/cribl_siem_linux/colddb
thawedPath = $SPLUNK_DB/cribl_siem_linux/thaweddb
frozenTimePeriodInSecs = 7776000
9.2 Splunk: HEC (HTTP Event Collector) aktivieren
# 1. HEC global aktivieren (Splunk CLI)
/opt/splunk/bin/splunk http-event-collector enable -uri https://localhost:8089 \
-auth admin:SPLUNK_PASSWORT
# 2. HEC-Token erstellen
/opt/splunk/bin/splunk http-event-collector create cribl-stream-hec \
-uri https://localhost:8089 \
-description "Cribl Stream SIEM Events" \
-index cribl_siem \
-indexes "cribl_siem,cribl_siem_windows,cribl_siem_linux" \
-auth admin:SPLUNK_PASSWORT
# 3. Token-Wert anzeigen
/opt/splunk/bin/splunk http-event-collector list \
-uri https://localhost:8089 \
-auth admin:SPLUNK_PASSWORT
Oder ueber Splunk Web UI:
- http://10.10.0.66:8000 → Settings → Data Inputs → HTTP Event Collector
- Global Settings → "All Tokens" auf Enabled, HTTP Port:
8088
- New Token:
- Name:
cribl-stream-hec
- Source type:
_json (Cribl sendet JSON)
- Default Index:
cribl_siem
- Allowed Indexes:
cribl_siem, cribl_siem_windows, cribl_siem_linux
- Token-GUID kopieren (z.B.
12345678-abcd-efgh-ijkl-123456789012)
Wichtig: Indexer Acknowledgement auf dem Token NICHT aktivieren!
Dies verursacht Channel-Validation-Fehler mit Cribl.
inputs.conf fuer HEC (auf Splunk 10.10.0.66)
# $SPLUNK_HOME/etc/system/local/inputs.conf
[http]
disabled = 0
port = 8088
enableSSL = 0
[http://cribl-stream-hec]
disabled = 0
token = HIER_DEN_GENERIERTEN_TOKEN_EINFUEGEN
index = cribl_siem
9.3 Splunk: props.conf & transforms.conf fuer Cribl-Daten
# $SPLUNK_HOME/etc/system/local/props.conf
# Cribl SIEM Events (allgemein)
[cribl:siem]
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%Z
TIME_PREFIX = "(?:@timestamp|SYSLOG_TIMESTAMP)"\s*:\s*"
MAX_TIMESTAMP_LOOKAHEAD = 40
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
KV_MODE = json
TRUNCATE = 100000
TRANSFORMS-classification = cribl_classification_extract
TRANSFORMS-container = cribl_container_extract
# Windows Security Events (via Cribl Edge)
[cribl:siem:winsecurity]
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%Z
SHOULD_LINEMERGE = false
KV_MODE = json
TRANSFORMS-eventid = cribl_win_eventid_extract
# Sysmon Events
[cribl:siem:sysmon]
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%Z
SHOULD_LINEMERGE = false
KV_MODE = json
# Linux auditd Events
[cribl:siem:auditd]
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%Z
SHOULD_LINEMERGE = false
KV_MODE = json
# Linux auth.log
[cribl:siem:linux_auth]
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%3N%Z
SHOULD_LINEMERGE = false
KV_MODE = json
# $SPLUNK_HOME/etc/system/local/transforms.conf
[cribl_classification_extract]
REGEX = "classification"\s*:\s*"([^"]+)"
FORMAT = classification::$1
WRITE_META = true
[cribl_container_extract]
REGEX = "CONTAINER_NAME"\s*:\s*"([^"]+)"
FORMAT = container_name::$1
WRITE_META = true
[cribl_win_eventid_extract]
REGEX = EventID["\s:=]+(\d+)
FORMAT = EventCode::$1
WRITE_META = true
9.4 Splunk: CIM-Datenmodelle & Tags
# $SPLUNK_HOME/etc/system/local/eventtypes.conf
# Authentication events
[cribl_authentication]
search = index=cribl_siem* (classification_reason="security_keyword_match" OR classification_reason="access_control_keyword_match" OR classification_reason="windows_security_event_id") ("failed password" OR "authentication failure" OR "invalid user" OR EventID=4624 OR EventID=4625 OR EventID=4648)
# Endpoint events (Sysmon + auditd)
[cribl_endpoint_process]
search = index=cribl_siem* (classification_reason="sysmon_detection" OR classification_reason="auditd_security_event") (EventID=1 OR "type=EXECVE")
# Network events
[cribl_network_traffic]
search = index=cribl_siem* (EventID=3 OR "type=SOCKADDR" OR "type=CONNECT" OR classification_reason="access_control_keyword_match" AND ("blocked" OR "denied" OR "firewall"))
# Change events
[cribl_change_events]
search = index=cribl_siem* (EventID=4720 OR EventID=4732 OR EventID=7045 OR "type=USER_ACCT" OR "type=ADD_USER" OR "type=DEL_USER" OR classification_reason="auditd_security_event" AND ("useradd" OR "usermod" OR "groupadd"))
# $SPLUNK_HOME/etc/system/local/tags.conf
[eventtype=cribl_authentication]
authentication = enabled
default = enabled
[eventtype=cribl_endpoint_process]
endpoint = enabled
process = enabled
[eventtype=cribl_network_traffic]
network = enabled
communicate = enabled
[eventtype=cribl_change_events]
change = enabled
audit = enabled
CIM-Mapping: Nach Konfiguration der Tags werden die Daten automatisch in folgenden
Splunk CIM-Datenmodellen verfuegbar:
- Authentication — Login-Versuche, fehlgeschlagene Anmeldungen
- Endpoint.Processes — Prozesserstellung (Sysmon/auditd)
- Network_Traffic — Netzwerkverbindungen, Firewall-Events
- Change — Account-/Gruppen-/Service-Aenderungen
9.5 CriblVision for Splunk installieren
CriblVision ist das offizielle Cribl-Monitoring-Dashboard fuer Splunk.
Es zeigt Pipeline-Throughput, Worker-Health, Queue-Status und Fehler.
Download von GitHub (nicht auf Splunkbase).
# Auf dem Splunk-Server (10.10.0.66):
# 1. CriblVision herunterladen
cd /tmp
git clone https://github.com/criblio/criblvision.git
# 2. Als Splunk-App installieren
cp -r /tmp/criblvision/criblvision "$SPLUNK_HOME/etc/apps/"
chown -R splunk:splunk "$SPLUNK_HOME/etc/apps/criblvision"
# 3. Splunk neu starten
/opt/splunk/bin/splunk restart
# Alternativ: Ueber Splunk Web UI
# Apps -> Manage Apps -> Install app from file
# Datei: criblvision-v4.6.1.tar.gz (von GitHub Releases)
CriblVision konfigurieren
- Splunk Web:
http://10.10.0.66:8000/app/criblvision
- Unter Configuration:
- Cribl Stream URL:
http://10.10.0.100:9000
- Cribl Monitoring Index:
_internal oder einen dedizierten Index
- Optional: Cribl Stream so konfigurieren, dass interne Metriken an Splunk gesendet werden:
- In Cribl Stream: Settings → System → Monitoring → Export to Splunk
- HEC-URL:
http://10.10.0.66:8088
- Token: den erstellten HEC-Token verwenden
9.6 Cribl Stream: Splunk HEC Destination konfigurieren
In Cribl Stream UI unter Data → Destinations → Splunk HEC
(http://10.10.0.100:9000/outputs):
| Parameter | Wert |
| Output ID | splunk_hec |
| URL | http://10.10.0.66:8088/services/collector |
| HEC Auth Token | DEIN_GENERIERTER_TOKEN |
| Default Index | cribl_siem |
| Default Sourcetype | cribl:siem |
| Compression | Enabled |
| Indexer Acknowledgement | Disabled |
| Request Timeout | 30s |
| Concurrency | 5 |
Verbindung testen
# Vom Cribl-Server (10.10.0.100) testen:
curl -k "http://10.10.0.66:8088/services/collector/event" \
-H "Authorization: Splunk DEIN_HEC_TOKEN" \
-H "Content-Type: application/json" \
-d '{"event":"IceDataEmphasise HEC Test","host":"cribl-stream","index":"cribl_siem","sourcetype":"cribl:siem"}'
# Erwartete Antwort: {"text":"Success","code":0}
# In Splunk verifizieren:
# http://10.10.0.66:8000 -> Search: index=cribl_siem earliest=-5m
10. Verifikation & Checkliste
10.1 Windows-Verifikation
# 1. Edge-Verbindung pruefen
Get-Service CriblEdge | Format-Table Status
Test-NetConnection 10.10.0.100 -Port 4200
# 2. Security-Events generieren (Test)
# Fehlgeschlagener Login-Versuch erzeugen:
runas /user:FakeUser cmd
# -> Event ID 4625 in Security Log
# Sysmon-Test: notepad.exe starten
Start-Process notepad.exe
# -> Sysmon Event ID 1 (Process Create)
# PowerShell Script Block Test:
Invoke-Expression "Write-Host 'Test Script Block Logging'"
# -> PowerShell Event ID 4104
# 3. In Kibana pruefen:
# http://10.10.0.100:5601 -> Discover -> cribl-ops*
# Filter: host.name = "<WINDOWS-HOSTNAME>"
10.2 Ubuntu-Verifikation
# 1. Edge-Verbindung
sudo systemctl status cribl-edge | head -5
curl -sf http://localhost:9000/api/v1/edge/nodes -u admin:PASSWORD | python3 -m json.tool
# 2. auditd Events generieren (Test)
sudo cat /etc/shadow # -> audit FILE_ACCESS event
sudo useradd -M testuser # -> audit ACCT event
sudo userdel testuser
# 3. Auth-Events generieren
ssh invalid_user@localhost # -> auth.log: Failed password
# 4. fail2ban pruefen
sudo fail2ban-client status sshd
# 5. Audit-Log pruefen (Events sollten fliessen)
sudo ausearch -k exec --start recent | head -20
sudo ausearch -k identity --start recent | head -20
# 6. In ES pruefen:
curl -s 'http://localhost:9200/cribl-ops/_search' \
-H 'Content-Type: application/json' \
-d '{"size":5,"sort":[{"@timestamp":"desc"}],"query":{"match":{"classification":"siem"}}}' \
| python3 -m json.tool | head -40
10.3 Gesamtcheckliste
Windows
- Cribl Edge MSI installiert
- Edge-Service laeuft und verbunden
- Edge Node in Stream UI sichtbar
- Erweiterte Audit-Policies gesetzt
- Sysmon installiert + konfiguriert
- PowerShell Script Block Logging aktiv
- Windows Firewall Logging aktiv
- Event Log Groessen angepasst
- WinEventLog Sources konfiguriert
- SIEM-Events in Splunk sichtbar
- Ops-Events in Kibana/ES sichtbar
Ubuntu
- Cribl Edge installiert
- Edge-Service laeuft und verbunden
- Edge Node in Stream UI sichtbar
- auditd installiert + Regeln geladen
- rsyslog auth.log aktiv
- UFW Firewall Logging medium
- fail2ban installiert + sshd-Jail aktiv
- cribl-User hat Leserechte auf Logs
- File Monitor Sources konfiguriert
- SIEM-Events in Splunk sichtbar
- Ops-Events in Kibana/ES sichtbar
Splunk (10.10.0.66)
- Splunk-Indizes cribl_siem, cribl_siem_windows, cribl_siem_linux angelegt
- HEC aktiviert + Token erstellt (Port 8088)
- props.conf & transforms.conf deployed (5 Sourcetypes)
- CIM-Datenmodelle beschleunigt (Authentication, Endpoint, Network, Change)
- eventtypes.conf & tags.conf deployed
- CriblVision App installiert
- Cribl Stream HEC-Destination konfiguriert + Test erfolgreich
- SIEM-Route in Stream aktiv (filter: classification==siem → splunk_hec)
index=cribl_siem | stats count by sourcetype zeigt Daten
Erwartetes Ergebnis: Nach vollstaendiger Einrichtung beider Systeme sollte die SIEM-Event-Rate
deutlich steigen. Typische Raten:
- Windows mit Sysmon: 500-5.000 Events/Stunde (je nach Aktivitaet)
- Ubuntu mit auditd: 200-2.000 Events/Stunde (je nach execve-Haeufigkeit)
- Davon SIEM-klassifiziert: ca. 5-15% (Security-Events, Login-Failures, Privileged Ops)
- SIEM → Splunk: Alle klassifizierten Security-Events in Splunk-Indizes
- Operational → S3 + Kibana: Nicht-SIEM-Daten in MinIO und Elasticsearch
11. Netzwerkgeraete & IoT Onboarding
Reale Infrastruktur: Basierend auf der aktuellen Cribl-Instanz (10.10.0.100) werden hier
alle vorhandenen und geplanten Netzwerkgeraete dokumentiert. Die Sophos Firewall sendet bereits Syslog-Daten
auf Port 9514 (in_syslog_sophos) mit eigenem Pipeline (pipeline_sophos_fw).
11.0 Aktuelle Datenverteilung (Live-Werte)
| Klassifikation | Methode | Events | Anteil |
| Operational | rule_based | ~9.4 Mio | ~84% |
| SIEM | rule_based | ~1.8 Mio | ~16% |
| Fallback (unklassifiziert) | fallback | ~571k | ~5.1% |
Fallback-Hotspots: 571k Events landen im Fallback und werden als
operational behandelt,
ohne dass eine Regel sie explizit zuordnet. Top-Verursacher:
homeassistant: ~457k Events (SNMP-Timeouts, command_line-Fehler, MQTT-Dekodierung)
oa-tika: ~98k Events (Apache Tika OCR-Prozessor)
oa-postgres: ~13k Events (PostgreSQL DB-Fehler)
Diese sollten durch explizite Regeln im
universal_classifier abgedeckt werden.
| Top Klassifikations-Gruende | Events | Ziel |
sophos_fw_allowed | ~7.1 Mio | Elasticsearch (Ops) |
sophos_fw_denied_or_drop | ~1.68 Mio | Splunk (SIEM) |
rule_container_homeassistant | ~1.56 Mio | Elasticsearch (Ops) |
default_safe_fallback | ~571k | Elasticsearch (Ops, unklassifiziert!) |
normal_operation_pattern | ~138k | Elasticsearch (Ops) |
sophos_default_siem | ~114k | Splunk (SIEM) |
11.1 Sophos SFOS Firewall
Status: AKTIV — Die Sophos Firewall sendet bereits ~8.9 Mio Events via Syslog an Cribl.
Input: in_syslog_sophos (UDP/TCP Port 9514). Pipeline: pipeline_sophos_fw.
Route: route_sophos_fw mit dynamischem Output (SIEM→Splunk, Ops→ES).
Aktuelle Cribl-Konfiguration (Live-Werte)
| Parameter | Wert |
| Cribl Input | in_syslog_sophos (Typ: syslog) |
| Syslog-Port | UDP/TCP 9514 (nicht Standard 514, Kollision vermieden) |
| Pipeline | pipeline_sophos_fw (KVP-Parser + SIEM-Klassifikation + CIM-Normalisierung) |
| Route | route_sophos_fw mit outputExpression: SIEM→splunk_hec, Ops→elasticsearch_ops |
| Events total | ~8.9 Mio (davon Firewall: 8.78 Mio, Events: 31k, Content Filtering: 19k, System Health: 19k) |
| FW-Regeln aktiv | Rule 9: 6.1 Mio, Rule 8: 1.0 Mio, Rule 12: 3.3k |
Sophos SFOS: Syslog konfigurieren
# Auf der Sophos SFOS Web-Konsole:
# 1. System Services → Log Settings → Syslog Servers
# 2. "Add" klicken:
# - Name: Cribl-Stream
# - IP Address: 10.10.0.100
# - Port: 9514
# - Protocol: UDP (oder TCP fuer zuverlaessigere Zustellung)
# - Facility: LOCAL0 (oder DAEMON)
# - Severity Level: Information (alle Severity Levels)
# - Format: Device Standard Format
#
# 3. Log-Typen aktivieren (alle ankreuzen):
# [x] Firewall - Allow/Deny/Drop (Hauptvolumen ~8.8 Mio Events)
# [x] IDP - Intrusion Detection/Prevention
# [x] ATP - Advanced Threat Protection (Sandboxing)
# [x] WAF - Web Application Firewall
# [x] Event - Authentication, Admin, VPN
# [x] System Health - CPU, Memory, Disk, SSL, Interface
# [x] Content Filtering - Web-Filter, URL-Kategorien
# [x] Anti-Spam - E-Mail-Filterung
#
# 4. "Save" klicken
Pipeline-Details: pipeline_sophos_fw
Die bestehende Pipeline verarbeitet Sophos-Logs in 3 Stufen:
| Stage | Funktion | Details |
| 1 | KVP-Extraktion | serde: Sophos Key=Value Paare parsen (src_ip, dst_ip, protocol, log_type, log_subtype, fw_rule_id) |
| 2 | SIEM-Klassifikation | Denied/Drop → SIEM, IDP/ATP/WAF → SIEM, Auth/Admin/VPN → SIEM, Allowed → Operational |
| 3 | CIM-Normalisierung | src, dest, src_port_num, dest_port_num, protocol, action, rule, severity |
SIEM-relevante Sophos Event-Typen:
Firewall Denied/Drop → ~1.69 Mio Events → Splunk (Network_Traffic CIM)
IDP (1 Event), WAF (5 Events), ATP (0) → Splunk (Intrusion_Detection CIM)
Event: Authentication/Admin/VPN → ~31k Events → Splunk (Authentication CIM)
Content Filtering: HTTP (9.6k), SSL (2.3k) → Splunk (Web CIM)
sophos_default_siem → ~114k unklassifizierte Events → Splunk (zur manuellen Pruefung)
Verifikation Sophos-Datenfluss
# 1. Syslog-Empfang pruefen (auf 10.10.0.100)
ss -ulnp | grep 9514
# Erwartung: udp 0 0 0.0.0.0:9514 0.0.0.0:* users:(("cribl",pid=...,fd=...))
# 2. Live-Daten pruefen
curl -sf 'http://10.10.0.100:9200/cribl-ops*/_search' \
-H 'Content-Type: application/json' \
-d '{"size":3,"query":{"term":{"source_type.keyword":"sophos_firewall"}},"sort":[{"@timestamp":"desc"}],"_source":["src_ip","dst_ip","protocol","log_type","log_subtype","classification"]}' \
| python3 -m json.tool
# 3. Sophos-Statistik
curl -sf 'http://10.10.0.100:9200/cribl-ops*/_search' \
-H 'Content-Type: application/json' \
-d '{"size":0,"query":{"term":{"source_type.keyword":"sophos_firewall"}},"aggs":{"by_subtype":{"terms":{"field":"log_subtype.keyword","size":10}}}}' \
| python3 -c "import sys,json; [print(f' {b[\"key\"]}: {b[\"doc_count\"]:,}') for b in json.load(sys.stdin).get('aggregations',{}).get('by_subtype',{}).get('buckets',[])]"
11.2 Proxmox VE
Status: GEPLANT — Proxmox VE (Virtualisierungs-Host) kann Syslog-Events senden.
Security-relevant: VM-Start/Stop, Backup-Jobs, Cluster-Events, API-Zugriffe, Firewall-Regeln.
Proxmox Syslog nach Cribl senden
# Auf dem Proxmox-Host (als root):
# 1. rsyslog-Forwarding konfigurieren
cat > /etc/rsyslog.d/60-cribl.conf <<'RSYSLOG'
# IceDataEmphasise: Forward Proxmox logs to Cribl Stream
# Alle Logs ab severity "info" weiterleiten
*.* @10.10.0.100:514
# Alternativ: Nur Security-relevante Logs
auth,authpriv.* @10.10.0.100:514
kern.* @10.10.0.100:514
daemon.* @10.10.0.100:514
RSYSLOG
# 2. rsyslog neu laden
systemctl restart rsyslog
# 3. pve-firewall Logging aktivieren (falls PVE Firewall aktiv)
# In /etc/pve/firewall/cluster.fw:
# [OPTIONS]
# enable: 1
# log_level_in: info
# log_level_out: info
# 4. Pruefen
logger -t proxmox-test "IceDataEmphasise: Proxmox syslog test"
# In Cribl/ES verifizieren
Proxmox API-Audit-Log (optional)
# Proxmox protokolliert API-Zugriffe in /var/log/pveproxy/access.log
# Diese koennen per Cribl Edge File Monitor erfasst werden
# Edge File Monitor Source:
{
"id": "proxmox_audit",
"type": "file_monitor",
"disabled": false,
"conf": {
"paths": [
"/var/log/pveproxy/access.log",
"/var/log/pve-firewall.log",
"/var/log/auth.log"
],
"sendRawData": true
},
"description": "Proxmox VE Audit and Security Logs"
}
SIEM-relevante Proxmox Events
| Quelle | Event-Typ | SIEM-Relevanz |
| /var/log/auth.log | SSH Login, PAM | Brute-Force, Unauthorisierter Zugriff |
| /var/log/pveproxy/access.log | API-Aufrufe (POST, DELETE) | VM-Erstellung, Loesch-Aktionen, Config-Changes |
| /var/log/pve-firewall.log | Firewall-Drops | Netzwerk-Angriffe auf VMs |
| syslog | qm start/stop/migrate | VM-Lifecycle, Cluster-Events |
| syslog | vzdump | Backup-Erfolg/Fehler |
Vorgeschlagene Pipeline-Regel fuer universal_classifier
// Proxmox SIEM-Events (im universal_classifier einfuegen)
filter: log_message && /(pvedaemon|pveproxy|pveceph|qm (start|stop|destroy|migrate|clone)|vzdump.*(error|fail)|pve-firewall.*(DROP|REJECT))/i.test(log_message)
classification = 'siem'
classification_method = 'rule_based'
classification_reason = 'proxmox_security_event'
11.3 UniFi WiFi Console
Status: GEPLANT — Ubiquiti UniFi Controller/Console kann Syslog-Events an Cribl senden.
Relevant: Client-Authentifizierung, Rogue AP Detection, Wireless IDS, Client (Dis)Connects.
UniFi Syslog konfigurieren
# In der UniFi Network Console (Web-UI):
# 1. Settings → System → Advanced
# 2. "Remote Syslog Server" aktivieren:
# - Syslog Host: 10.10.0.100
# - Syslog Port: 514
# - Log Level: Informational (6)
#
# Die UniFi Console sendet dann Events im Format:
# <facility><severity> timestamp hostname UniFi: ...
#
# Event-Typen:
# - STA connected/disconnected (Client WiFi-Verbindungen)
# - AP adopted/disconnected (Access Point Management)
# - Rogue AP detected (Security!)
# - WPA authentication failure (Brute-Force!)
# - DPI category blocked (Content Filter)
# - IDS/IPS alerts (Threat Management)
Cribl-Empfang
UniFi-Syslog kommt auf dem bestehenden in_syslog Input (Port 514) an.
Der universal_classifier kann diese per Keyword-Matching klassifizieren.
SIEM-relevante UniFi Events
| Event | Beschreibung | SIEM-Aktion |
| EVT_WU_Connected | Client mit WiFi verbunden | Authentifizierung tracken |
| EVT_WU_Disconnected | Client WiFi getrennt | Anomalie-Erkennung |
| EVT_AP_DetectedRogueAP | Unbekannter Access Point erkannt | SIEM-Alarm! |
| EVT_WU_WPA_AuthFail | WPA-Authentifizierung fehlgeschlagen | Brute-Force-Erkennung |
| EVT_IDS_Alert | IDS/IPS-Erkennung | SIEM-Alarm! |
| EVT_AP_Lost | Access Point nicht erreichbar | Infrastruktur-Monitoring |
| EVT_GW_WANTransition | WAN-Verbindung gewechselt | Netzwerk-Availability |
Vorgeschlagene Pipeline-Regel
// UniFi SIEM-Events
filter: log_message && /(RogueAP|WPA.*[Ff]ail|IDS.*[Aa]lert|EVT_IDS|EVT_WU_WPA_AuthFail|EVT_AP_DetectedRogue)/i.test(log_message)
classification = 'siem'
classification_method = 'rule_based'
classification_reason = 'unifi_security_event'
// UniFi Operational Events
filter: log_message && /(EVT_WU_Connected|EVT_WU_Disconnected|EVT_AP_Adopted|EVT_AP_Lost|EVT_GW_WAN)/i.test(log_message)
classification = 'operational'
classification_method = 'rule_based'
classification_reason = 'unifi_network_event'
11.4 Tasmota ESP32 Devices
Status: TEILWEISE AKTIV — Tasmota-Geraete sind in HomeAssistant integriert (MQTT via Mosquitto).
Logs erscheinen aktuell im homeassistant Container als MQTT-StatusSTS-Nachrichten.
~457k HomeAssistant-Events landen im Fallback — darunter Tasmota-MQTT-Dekodierungsfehler.
Tasmota Log-Architektur
Tasmota ESP32 Mosquitto MQTT HomeAssistant
+---------------+ +---------------+ +-------------------+
| Sensor/Aktor |--MQTT--| Broker |--MQTT--| HA Integration |
| StatusSTS | | (addon) | | tasmota.* |
| Telemetry | | Port 1883 | | Logs in Container |
+---------------+ +---------------+ +--------+----------+
|
Docker JSON Logs
|
Cribl File Monitor
(docker_all_containers)
Tasmota Syslog-Modus aktivieren (direkt an Cribl)
# In der Tasmota Web-Konsole jedes Geraets:
# 1. Configuration → Configure Logging
# 2. Syslog host: 10.10.0.100
# 3. Syslog port: 514
# 4. Syslog level: 2 (LOG_LEVEL_INFO)
#
# Oder per MQTT-Befehl (fuer alle Geraete gleichzeitig):
# Topic: cmnd/tasmotas/SyslogHost
# Payload: 10.10.0.100
#
# Topic: cmnd/tasmotas/SyslogPort
# Payload: 514
#
# Topic: cmnd/tasmotas/SyslogLevel
# Payload: 2
#
# Tasmota-Syslog sendet im Format:
# <PRI> timestamp hostname ESP-XXXXXX: {"StatusSTS":{"Time":"...","Uptime":"..."}}
Vorgeschlagene Pipeline-Regel
// Tasmota/ESP32 Events (alle operational)
filter: log_message && /(StatusSTS|RESULT|tasmota|ESP-[A-F0-9]{6,}|Uptime.*SleepMode)/i.test(log_message)
classification = 'operational'
classification_method = 'rule_based'
classification_reason = 'tasmota_iot_telemetry'
// Tasmota Security (seltene Events)
filter: log_message && /tasmota.*(WebServer.*Auth|MQTT.*[Dd]isconnect.*Reason|OTA.*[Ff]ail|CFG.*[Ee]rror)/i.test(log_message)
classification = 'siem'
classification_method = 'rule_based'
classification_reason = 'tasmota_security_event'
11.5 HomeAssistant
Status: AKTIV — HomeAssistant laeuft als Docker-Container auf dem NUC-HA.
Aktuell ~2.1 Mio Events, davon ~1.56 Mio per Regel als operational klassifiziert,
aber ~457k fallen in den Fallback (SNMP-Timeouts, command_line-Fehler, MQTT-Dekodierung).
Aktuelle Datenverteilung (HomeAssistant)
| Klassifikation | Events | Typische Log-Meldungen |
| rule_container_homeassistant | ~1.56 Mio | Normale HA-Operationen (Setup, State Changes) |
| default_safe_fallback | ~457k | SNMP Timeouts, MQTT-Dekodierungsfehler, command_line Errors |
| normal_operation_pattern | (enthalten) | INFO/DEBUG/WARNING-Level Logs |
Fallback-Problem: Die 457k Fallback-Events enthalten viele ERROR und FATAL
Meldungen von HA-Integrationen (SNMP-Sensor-Timeouts, MQTT-Dekodierungsfehler).
Diese sind operational (keine Security-Events), werden aber vom stderr_error_pattern
nicht erfasst, weil sie nicht ueber Docker stderr kommen, sondern im HA-eigenen Log-Format.
Vorgeschlagene Pipeline-Regeln (Fallback reduzieren)
// HomeAssistant: Alle HA-internen Logs → operational
// Erfasst ERROR/WARNING/INFO aus HA-Komponenten die aktuell im Fallback landen
filter: CONTAINER_NAME === 'homeassistant' && classification === 'unknown' && log_message && /\[(homeassistant|custom_components|hass)\./i.test(log_message)
classification = 'operational'
classification_method = 'rule_based'
classification_reason = 'homeassistant_internal_log'
// HomeAssistant Supervisor/Add-ons → operational
filter: CONTAINER_NAME && /^(hassio_|addon_)/i.test(CONTAINER_NAME) && classification === 'unknown'
classification = 'operational'
classification_method = 'rule_based'
classification_reason = 'homeassistant_addon_log'
// HomeAssistant Security-Events → SIEM
filter: CONTAINER_NAME === 'homeassistant' && log_message && /(login_attempt|auth.*fail|unauthorized|invalid_auth|blocked.*ip|banned)/i.test(log_message)
classification = 'siem'
classification_method = 'rule_based'
classification_reason = 'homeassistant_auth_event'
HA Logger Konfiguration (optional)
# In HomeAssistant configuration.yaml:
# Logger-Level anpassen fuer weniger Noise
logger:
default: warning
logs:
homeassistant.components.snmp: error # SNMP-Timeouts reduzieren
homeassistant.components.command_line: error
homeassistant.components.mqtt: warning # MQTT-Dekodierung
homeassistant.core: info
homeassistant.components.automation: info # Automationen tracken
# Alternativ: HA Syslog-Integration
# In HA → Settings → Integrations → Syslog
# Destination: 10.10.0.100:514
# Facility: local7
11.6 Synology NAS DS1821+
Status: GEPLANT — Synology DSM unterstuetzt Syslog-Weiterleitung nativ.
SIEM-relevant: Login-Versuche, Datei-Zugriffe, Freigabe-Aenderungen, Paket-Updates, Hyper Backup Status.
Synology DSM: Syslog konfigurieren
# In DSM Web-UI (https://<NAS-IP>:5001):
# 1. Hauptmenue → Protokollcenter (Log Center)
# 2. Tab "Protokollversand" (Log Sending)
# 3. "Erstellen" → Syslog-Regel:
# - Server: 10.10.0.100
# - Port: 514
# - Protokoll: UDP (oder TCP fuer zuverlaessigere Zustellung)
# - Format: BSD (Syslog RFC 3164)
# - Logs:
# [x] System - DSM-Kern, Hardware, Services
# [x] Connection - Login/Logout, IP-Blocks, 2FA
# [x] File Transfer - SMB/NFS/AFP Zugriffe
# [x] Backup - Hyper Backup Erfolg/Fehler
# [x] Drive - Synology Drive Sync-Events
# [x] Surveillance - Surveillance Station (falls vorhanden)
#
# 4. "OK" klicken → Syslog-Versand startet sofort
SIEM-relevante Synology Events
| Quelle | Event | SIEM-Relevanz |
| Connection | Failed login (DSM, SSH, SMB) | Brute-Force-Erkennung |
| Connection | IP auto-blocked | SIEM-Alarm: Angreifer geblockt |
| Connection | 2FA verification failed | Account-Kompromittierung |
| System | User created/deleted/modified | Account Management |
| System | Shared folder permission change | Rechteaenderung |
| System | DSM update installed | Patch Management |
| File Transfer | File deleted (SMB/NFS) | Ransomware-Erkennung (Massenloeschung) |
| Backup | Hyper Backup failed | Datenintegritaet |
| System | Disk S.M.A.R.T. warning | Hardware-Failure-Prediction |
| System | Volume degraded/crashed | SIEM-Alarm: Storage-Ausfall |
Vorgeschlagene Pipeline-Regel
// Synology SIEM-Events
filter: log_message && /(synology|dsm|DiskStation).*([Ff]ailed.*login|auto.*block|ip.*block|2FA.*fail|permission.*chang|volume.*(degrad|crash)|SMART.*(warn|error))/i.test(log_message)
classification = 'siem'
classification_method = 'rule_based'
classification_reason = 'synology_security_event'
// Synology Operational
filter: log_message && /(synology|dsm|DiskStation).*(backup.*complet|update.*success|Hyper Backup.*finish|disk.*normal)/i.test(log_message)
classification = 'operational'
classification_method = 'rule_based'
classification_reason = 'synology_operational_event'
11.7 Erweitertes Netzwerk-Diagramm (alle Geraete)
Internet
|
+--------v--------+
| Sophos SFOS | Syslog UDP 9514
| Firewall |---------------------------+
| (Gateway) | |
+--------+--------+ |
| |
+---------------+---------------+ |
| 10.10.0.0/24 | |
| | |
+---------v---------+ +--------+--------v---------+ |
| UniFi WiFi | | NUC-HA (10.10.0.100) | |
| Console | | Cribl Stream Leader |<--------+
| Syslog → :514 |--→| Syslog :514 / :9514 |
+-------------------+ | Docker Containers: |
| - HomeAssistant (HA) |
+---------+----------+ | - Ollama (ki01) |
| Proxmox VE | | - Elasticsearch + Kibana |
| (Virtualisierung) | | - MinIO S3 |
| Syslog → :514 |--→| - Cribl-Docs |
+--------------------+ +---+-----------+---+---------+
| | |
+---------+----------+ | | +--→ MinIO S3 (:9100)
| Synology DS1821+ | | |
| NAS / Storage | | +------→ ES/Kibana (:9200/:5601)
| Syslog → :514 |------+
+--------------------+ |
+--→ Splunk HEC (10.10.0.66:8088)
+---------+----------+
| Tasmota ESP32 |
| IoT Devices |
| MQTT → Mosquitto |--→ HomeAssistant --→ Docker Logs --→ Cribl
| (oder Syslog :514) |
+--------------------+
IPs aus Sophos FW-Daten:
10.10.0.100 = NUC-HA (Cribl, HA, ES, Kibana, MinIO)
10.10.0.66 = Splunk Enterprise
10.10.0.210 = ki01 (Ollama AI, 11434)
10.10.0.111 = Workstation (hoechster Traffic: 1.6 Mio Events)
10.10.0.50 = Zweites Geraet (826k Events)
10.10.0.186 = Drittes Geraet (784k Events)
11.8 Gesamtcheckliste Netzwerkgeraete
Sophos SFOS
- Syslog-Server 10.10.0.100:9514 konfiguriert
- Alle Log-Typen aktiviert (FW, IDP, ATP, WAF, Event)
- Cribl Input
in_syslog_sophos aktiv
- Pipeline
pipeline_sophos_fw deployed
- Route
route_sophos_fw mit outputExpression
- ~8.9 Mio Events in ES sichtbar
- SIEM-Events (Denied/Drop) in Splunk
Proxmox VE
- rsyslog-Forwarding an 10.10.0.100:514
- PVE-Firewall-Logging aktiviert
- Pipeline-Regel fuer Proxmox-Events
UniFi WiFi
- Remote Syslog 10.10.0.100:514 konfiguriert
- Pipeline-Regel fuer UniFi SIEM/Ops Events
- Rogue AP Detection in Splunk sichtbar
Tasmota / HA / Synology
- Tasmota: Syslog oder MQTT→HA→Docker-Logs
- HA: Fallback-Regeln implementiert (~457k Events)
- HA Supervisor/Add-on Container-Regel aktiv
- Synology: Syslog an 10.10.0.100:514
- Synology: Login-Failure Alerting in Splunk
12. Gesamtablauf – Ende-zu-Ende Datenpipeline
Uebersicht: Dieser Abschnitt beschreibt den vollstaendigen Datenfluss von allen Quellen
durch die Ollama-gestuetzte Klassifikation bis zu den Ziel-Systemen.
ES-First Architektur: ALLE Events → Elasticsearch (primaerer Data Lake). SIEM-Events → ZUSAETZLICH an Splunk (Dual-Write). Operational → S3 Archiv.
12.1 Erweitertes Datenfluss-Diagramm
Windows Workstation Ubuntu NUC-HA (ki01) Docker Container
+-------------------+ +-------------------+ +-------------------+
| Cribl Edge | | Cribl Edge | | File Monitor |
| WinEventLog: | | Journal: | | /var/lib/docker/ |
| - Security | | - systemd | | containers/ |
| - Sysmon | | - docker.service | | *-json.log |
| - PowerShell | | File Monitor: | +--------+----------+
| - Defender | | - audit.log | |
| - System | | - auth.log | |
+--------+----------+ | - ufw.log | |
| | - fail2ban.log | |
| +--------+----------+ |
| tcp://10.10.0.100:4200 | |
+------------+---------------+ |
| |
+---------v--------------------------------------------v---------+
| Cribl Stream Leader (10.10.0.100) |
| |
| Route 1: route_classify_all (filter: true, final: false) |
| Pipeline: universal_classifier |
| |
| +----------------------------------------------------------+ |
| | Stage 0: source_type Erkennung (__inputId) | |
| | Stage 0b: Docker JSON Parse (nur docker) | |
| | Stage 0c: Edge-Felder (EventID, LogName, Message) | |
| | Stage 1: Rule-based (Windows/Sysmon/auditd/SSH/Keywords) | |
| | Stage 2: Ollama AI (qwen2.5:14b, 5s Timeout) | |
| | Fallback: operational (sicherer Default) | |
| +----------------------------------------------------------+ |
| | |
| Route 2: route_all_to_es (filter: true, final: false) |
| ==> ALLE Events nach Elasticsearch (ES-First Data Lake) |
| | |
| Route 3: route_siem_to_splunk (classification=='siem') |
| ==> SIEM-Events ZUSAETZLICH nach Splunk (Dual-Write) |
| Route 4: route_ops_to_s3 (classification=='operational') |
| ==> Operational nach S3 Archiv |
| Route 5: route_default (Catch-All) |
+--------------------/-----------|----------\---------------------+
/ | \
+------------v--+ +------v------+ +-v--------------+
| Splunk HEC | | Elasticsearch| | MinIO S3 |
| 10.10.0.66 | | :9200 | | :9100 |
| :8088 | | + Kibana | | cribl-logs/ |
| SIEM-Events | | :5601 | | (Langzeit) |
| (zusaetzlich) | | ALLE Events | | |
+---------------+ +--------------+ +---------------+
SOC-Analyse Data Lake (ALL) Langzeit-Archiv
CIM-Datenmodelle KQL-Suche S3-Lifecycle
Alerting SIEM-Discovery Compliance
12.2 Ollama-Integrationspunkte
Die KI (Ollama auf ki01, Port 11434) wird an 6 Stellen im System eingesetzt:
| # | Integrationspunkt | Funktion | Modell | Trigger |
| 1 | Pipeline: Stage 2 | Klassifikation unbekannter Events (SIEM/Ops) | qwen2.5:14b | Echtzeit (pro Event, 5s Timeout) |
| 2 | AI Panel: KI-Vorschlaege | Analyse von Fallback-Events, Regelvorschlaege | Waehlbar | Manuell / Auto-Refresh (30s) |
| 3 | AI Panel: Reklassifikation | Stichproben-Analyse operational Events auf SIEM-Relevanz | Waehlbar | Manuell / Auto (30 Min) |
| 4 | AI Panel: Splunk Konfigurator | Generierung von props.conf, transforms.conf, CIM-Tags | Waehlbar | Manuell |
| 5 | AI Panel: Kibana Konfigurator | Generierung von Index Patterns, Saved Searches, Dashboards | Waehlbar | Manuell |
| 6 | AI Panel: Log-Analyzer | Analyse beliebiger Logs, Cribl-Konfig-Vorschlaege | Waehlbar | Manuell (Paste) |
12.3 Reklassifikations-Zyklus (Continuous Improvement)
+-------------------+
| 1. Events fliessen|
| durch Pipeline |
+--------+----------+
|
+--------v----------+
| 2. Rule-based + |
| Ollama AI |
| klassifiziert |
+--------+----------+
|
+--------v----------+ +---------------------+
| 3. Events landen | ----> | 4. AI Panel zeigt |
| in ES/Splunk/S3 | | Statistiken + |
+--------------------+ | KI-Vorschlaege |
+--------+------------+
|
+--------v------------+
| 5. Reklassifikation |
| prueft Ops-Events|
| auf SIEM-Relevanz|
+--------+------------+
|
+--------v------------+
| 6. Neue Regeln |
| werden per API |
| aktiviert |
+--------+------------+
|
+--------v------------+
| 7. Pipeline wird |
| committed + |
| deployed |
+--------+------------+
|
(zurueck zu Schritt 1)
Ergebnis: Die Erkennungsrate verbessert sich kontinuierlich.
Neue Regeln reduzieren die Fallback-Rate und die Ollama-AI-Last.
Typisch: Nach 2-3 Reklassifikations-Zyklen sinkt die Fallback-Rate von ~20% auf unter 5%.
12.4 Setup-Verlauf (Schritte 1-12)
| Schritt | Skript / Aktion | Ergebnis |
| 1 | scripts/10-deploy-phase2-infra.sh | MinIO, Elasticsearch, Kibana laufen |
| 2 | scripts/11-configure-docker-sources.sh | Docker File Monitor in Cribl konfiguriert |
| 3 | scripts/12-configure-phase2-destinations.sh | ES + S3 Destinations konfiguriert |
| 4 | scripts/13-configure-ollama-pipeline.sh | ollama_classifier Pipeline deployed |
| 5 | scripts/14-verify-phase2.sh | 17 Tests verifizieren Phase 2 |
| 6 | Windows Edge: MSI installieren (Abschnitt 2) | Windows Edge verbunden mit Fleet |
| 7 | Windows: Sysmon + Audit-Policies (Abschnitt 3) | Security-Events werden generiert |
| 8 | Linux Edge: Installation (Abschnitt 5) | Linux Edge verbunden mit Fleet |
| 9 | Linux: auditd + fail2ban (Abschnitt 6) | Linux Security-Events aktiv |
| 10 | Splunk: HEC + CIM (Abschnitt 9) | Splunk empfaengt SIEM-Events |
| 11 | scripts/15-deploy-universal-classifier.sh | Universal Classifier + neue Routes deployed |
| 12 | AI Panel: Reklassifikation + Konfig-Generierung | Continuous Improvement aktiv |
12.5 Verifikation Gesamtablauf
# === 1. Pipeline pruefen ===
curl -s -u admin:PASSWORD http://10.10.0.100:9000/api/v1/pipelines/universal_classifier \
| jq '.items[0].conf.functions | length'
# Erwartung: >= 30 Funktionen
# === 2. Routes pruefen ===
curl -s -u admin:PASSWORD http://10.10.0.100:9000/api/v1/routes \
| jq '.items[] | {id, filter, pipeline, output, final}'
# Erwartung: route_classify_all, route_all_to_es, route_siem_to_splunk, route_ops_to_s3, route_default
# === 3. Edge Nodes pruefen ===
curl -s -u admin:PASSWORD http://10.10.0.100:9000/api/v1/edge/nodes \
| jq '.items[] | {id, hostname, os, status}'
# Erwartung: Windows + Linux Nodes mit status "connected"
# === 4. ES: Events mit classification Feld ===
curl -s 'http://localhost:9200/cribl-ops*/_search' \
-H 'Content-Type: application/json' \
-d '{"size":5,"sort":[{"@timestamp":"desc"}],"query":{"exists":{"field":"source_type"}}}' \
| jq '.hits.hits[]._source | {source_type, classification, classification_method}'
# Erwartung: source_type=docker/edge/journal, classification=siem/operational
# === 5. ES: Aggregation nach source_type ===
curl -s 'http://localhost:9200/cribl-ops*/_search' \
-H 'Content-Type: application/json' \
-d '{"size":0,"aggs":{"by_type":{"terms":{"field":"source_type.keyword"}}}}' \
| jq '.aggregations.by_type.buckets'
# Erwartung: docker, edge, journal Buckets mit doc_count > 0
# === 6. Splunk: SIEM-Events vorhanden ===
# Auf 10.10.0.66: index=cribl_siem | stats count by classification_reason
# Oder: curl http://10.10.0.66:8088/services/collector/health
# === 7. AI Panel aufrufen ===
# http://10.10.0.100:8080/docs/16-ai-status-panel.html
# -> Datenfluss-Monitor zeigt alle Quellen
# -> Reklassifikation laeuft erfolgreich
# -> Splunk/Kibana Konfigurator generiert Configs
Ende-zu-Ende Verifikation bestanden wenn:
- Universal Classifier Pipeline hat ≥ 30 Funktionen (inkl. Windows/Linux/Edge Regeln)
- 5 Routes konfiguriert (classify_all, all_to_es, siem_to_splunk, ops_to_s3, default) - ES-First Architektur
- Edge Nodes in Cribl UI sichtbar und verbunden
- ES zeigt Events mit
source_type und classification Feldern
- Splunk empfaengt SIEM-Events via HEC
- AI Panel: Datenfluss-Monitor zeigt gruene Status-Dots