Log Management & SIEM

1. Einführung – Warum zentrales Logging?

In modernen IT-Infrastrukturen erzeugen Dutzende oder Hunderte von Systemen kontinuierlich Log-Daten: Webserver, Firewalls, Datenbanken, Applikationen, Betriebssystemdienste und Netzwerkgeräte schreiben sekündlich Ereignisse in ihre jeweiligen Logdateien. Solange eine Infrastruktur aus wenigen Maschinen besteht und alles reibungslos läuft, ist das händische Durchsuchen einzelner Logs noch praktikabel. Sobald jedoch ein Sicherheitsvorfall eintritt, ein Dienst unerwartet ausfällt oder Compliance-Anforderungen erfüllt werden müssen, zeigt sich die Schwäche dezentraler Logs schnell.

Das zentrale Problem: Logs auf einzelnen Servern sind isoliert. Ein Angreifer, der sich lateral durch ein Netzwerk bewegt, hinterlässt Spuren auf mehreren Systemen gleichzeitig – auf dem Firewall-Log, im SSH-Auth-Log des Jump-Hosts, im Applikationslog des Webservers und in den Datenbankprotokollen. Diese Ereignisse zeitlich zu korrelieren und kausal in Beziehung zu setzen ist nur möglich, wenn alle Logs an einem zentralen Ort zusammenlaufen und gemeinsam ausgewertet werden können.

Darüber hinaus spielen Compliance-Anforderungen eine wachsende Rolle. Regulierungen wie die DSGVO, ISO 27001, PCI DSS oder der BSI IT-Grundschutz verlangen nachweisbare Log-Aufbewahrung, Audit-Trails und die Fähigkeit, Sicherheitsvorfälle rekonstruieren zu können. Ein zentrales Log-Management-System ist in solchen Kontexten keine Option, sondern eine Pflicht.

Auch im Homelab-Kontext lohnt sich der Aufwand: Wer mehrere VMs, Container und Netzwerkgeräte betreibt, profitiert von zentraler Übersicht, schneller Fehlersuche und der Möglichkeit, verdächtige Aktivitäten automatisiert zu erkennen – bevor sie zu echten Problemen werden.

2. Log-Quellen und -Formate

Bevor man ein Log-Management-System aufbaut, ist es wichtig zu verstehen, welche Arten von Logs typischerweise anfallen und in welchen Formaten sie vorliegen. Die Heterogenität ist dabei eine der größten Herausforderungen.

2.1 Klassische Syslog-Logs

Das Syslog-Protokoll (RFC 5424) ist der älteste und am weitesten verbreitete Standard für System-Logs unter Unix/Linux. Log-Einträge bestehen aus einem Timestamp, einem Hostnamen, einem Applikationsnamen, einer Prozess-ID und der eigentlichen Nachricht. Syslog-Daten können lokal in Dateien wie /var/log/syslog oder /var/log/messages geschrieben oder über UDP/TCP an einen zentralen Syslog-Server weitergeleitet werden. Das Protokoll kennt acht Schweregrade (Emergency bis Debug) und bis zu 24 Facilities, die die Art des erzeugenden Systems beschreiben.

2.2 systemd Journal (journald)

Moderne Linux-Distributionen verwenden systemd-journald als primären Log-Aggregator. Journald speichert Logs in einem binären Format mit strukturierten Feldern. Mit dem Befehl journalctl lassen sich Logs filtern, durchsuchen und exportieren. Für die Weiterleitung an externe Systeme bietet sich entweder das klassische Syslog-Forwarding über ForwardToSyslog=yes in der journald.conf oder Tools wie Promtail an, die direkt den Journal-Socket lesen können.

2.3 Webserver-Access-Logs

Nginx und Apache schreiben Access-Logs in einem konfigurierbaren Format. Das Combined Log Format enthält Client-IP, Timestamp, HTTP-Methode, angefragte URL, HTTP-Statuscode, Antwortgröße, Referer und User-Agent. Für strukturierte Auswertungen empfiehlt sich die Konfiguration eines JSON-basierten Log-Formats, das direkt maschinenlesbar ist:

# Nginx JSON-Log-Format (nginx.conf)
log_format json_combined escape=json
  '{'
    '"time":"$time_iso8601",'
    '"remote_addr":"$remote_addr",'
    '"method":"$request_method",'
    '"uri":"$request_uri",'
    '"status":$status,'
    '"bytes_sent":$bytes_sent,'
    '"http_referer":"$http_referer",'
    '"http_user_agent":"$http_user_agent"'
  '}';

access_log /var/log/nginx/access.log json_combined;

2.4 Firewall-Logs

Linux-basierte Firewalls (iptables, nftables) können Verbindungsversuche, DROP- und REJECT-Aktionen in den Syslog schreiben. pfSense, OPNsense und andere Firewall-Appliances bieten Remote-Syslog-Forwarding an. Diese Logs sind besonders wertvoll für die Sicherheitsanalyse, da sie alle Netzwerkverbindungen dokumentieren, die die Perimeter-Grenze passieren – einschließlich blockierter Verbindungsversuche von außen und ungewöhnlicher Verbindungen von innen nach außen.

2.5 Strukturierte Logs und Common Event Format (CEF)

Strukturierte Log-Formate wie JSON sind für maschinelle Verarbeitung deutlich besser geeignet als freitext-basierte Logs. Das Common Event Format (CEF) ist ein von ArcSight entwickelter Standard, der sich vor allem im Enterprise-Umfeld bei Security-Produkten findet. Ein CEF-Log besteht aus einem Syslog-Header gefolgt von einem strukturierten CEF-Body mit definierten Schlüssel-Wert-Paaren für Felder wie Quelle, Ziel, Schweregrad und Ereignistyp. Das Format sieht so aus:

# CEF-Format: Syslog-Header | CEF-Version | Gerätehersteller | Geräteprodukt |
#             Geräteversion | Ereignis-ID | Ereignisname | Schweregrad | Erweiterungen
CEF:0|Palo Alto Networks|PAN-OS|10.1|threat|URL Filtering|3|
  src=192.168.1.100 dst=93.184.216.34 spt=54321 dpt=443 cs1=blocked cs1Label=URLCategory

3. Loki + Promtail

Grafana Loki ist ein von Grafana Labs entwickeltes Log-Aggregationssystem, das sich stark an den Designprinzipien von Prometheus orientiert. Im Gegensatz zum ELK-Stack indiziert Loki den Inhalt der Log-Nachrichten nicht vollständig – stattdessen werden nur Metadaten in Form von Labels indiziert. Die eigentlichen Log-Zeilen werden komprimiert in Objekt-Storage (lokal oder S3-kompatibel) abgelegt. Dieser Ansatz reduziert den Ressourcenverbrauch erheblich und macht Loki besonders für Homelab-Umgebungen und kleinere Deployments attraktiv.

3.1 Label-basiertes Modell ohne Volltext-Index

Loki speichert Logs in sogenannten Streams. Ein Stream ist eine Kombination aus Labels, zum Beispiel {job="nginx", host="webserver-01", env="prod"}. Alle Log-Zeilen, die zu einem bestimmten Stream gehören, werden gemeinsam als komprimierte Chunks gespeichert. Labels sollten sparsam gewählt werden, da eine hohe Kardinalität (viele unterschiedliche Label-Werte) die Performance negativ beeinflusst. Geeignete Labels sind Hostnamen, Job-Namen, Umgebungen oder Log-Typen – nicht aber dynamische Werte wie IPs einzelner Clients oder Session-IDs.

3.2 Promtail als Log-Shipper

Promtail ist der offizielle Log-Shipper für Loki. Er wird auf jedem System installiert, das Logs an Loki senden soll, liest Logdateien und den systemd-Journal aus und schickt die Einträge mit konfigurierten Labels an den Loki-Push-Endpunkt. Die Konfiguration erfolgt über eine YAML-Datei:

# /etc/promtail/config.yml (Auszug)
server:
  http_listen_port: 9080

clients:
  - url: http://loki:3100/loki/api/v1/push

scrape_configs:
  - job_name: system
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          host: webserver-01
          __path__: /var/log/*.log

  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
        host: webserver-01
    relabel_configs:
      - source_labels: [__journal__systemd_unit]
        target_label: unit

3.3 LogQL – Die Abfragesprache

LogQL ist die Abfragesprache von Loki, die stark an PromQL (Prometheus Query Language) angelehnt ist. Eine LogQL-Abfrage besteht aus einem Log-Stream-Selektor in geschweiften Klammern, optional gefolgt von Pipeline-Filtern und Metriken-Aggregationen. Es gibt zwei Typen: Log-Abfragen, die Zeilen zurückgeben, und Metrik-Abfragen, die numerische Zeitreihen produzieren.

# Alle Logs des Nginx-Jobs
{job="nginx"}

# Nur Fehler-Zeilen filtern (case-sensitive Substring)
{job="nginx"} |= "error"

# Regulärer Ausdruck für HTTP-5xx-Fehler
{job="nginx"} |~ "HTTP/[0-9.]+ 5[0-9]{2}"

# JSON-Parser und Feldfilter
{job="nginx"} | json | status >= 500

# Rate der Fehlermeldungen pro Minute (Metriken-Abfrage)
rate({job="nginx"} |= "error" [1m])

# Fehlgeschlagene SSH-Logins zählen in 5-Minuten-Fenstern
sum by (host) (count_over_time({job="varlogs"} |= "Failed password" [5m]))

3.4 Integration mit Grafana

Loki wird in Grafana als Datenquelle eingebunden. In Grafana-Dashboards lassen sich Log-Panels (der sogenannte Explore-View), Zeitreihen-Graphen aus LogQL-Metriken und Alerting-Regeln auf Basis von Log-Mustern kombinieren. Besonders nützlich ist die Möglichkeit, in einem Dashboard sowohl Metriken (aus Prometheus) als auch die zugehörigen Logs (aus Loki) zeitlich korreliert darzustellen – ein Fehlerspitzen-Graph und die dazugehörigen Logzeilen nebeneinander.

4. Graylog

Graylog ist eine vollwertige Log-Management-Plattform, die seit 2012 als Open-Source-Projekt entwickelt wird. Im Gegensatz zu Loki verfolgt Graylog einen vollständig indizierten Ansatz: Jede Log-Nachricht wird vollständig durchsuchbar gemacht, was mächtigere Ad-hoc-Suchen ermöglicht, aber mehr Ressourcen erfordert.

4.1 Architektur

Eine Graylog-Installation besteht aus drei Komponenten: Dem Graylog-Server selbst, der die Verarbeitung, das Routing und die Web-UI bereitstellt; OpenSearch (oder Elasticsearch) als Such- und Speicher-Backend für die indizierten Log-Daten; und MongoDB für die Konfigurationsdaten (Streams, Pipelines, Dashboards, Benutzer). Ab Graylog 5.x wird OpenSearch als bevorzugtes Backend empfohlen, da Elasticsearch die Lizenz von Apache 2.0 auf SSPL geändert hat. Für einen Testbetrieb im Homelab reicht ein einziger Server mit 8 GB RAM, für produktiven Dauerbetrieb mit höherem Log-Aufkommen sind 16 GB oder mehr empfohlen.

4.2 GELF – Graylog Extended Log Format

GELF (Graylog Extended Log Format) ist ein JSON-basiertes Log-Format, das speziell für Graylog entwickelt wurde. Es überwindet die Zeichenbegrenzung von klassischem Syslog (1024 Bytes), unterstützt strukturierte Felder und kann über UDP, TCP oder HTTP übertragen werden. Viele Applikationen und Logging-Bibliotheken (Java, Python, Go, PHP) bieten native GELF-Unterstützung.

# Beispiel: GELF-Nachricht als JSON
{
  "version": "1.1",
  "host": "webserver-01",
  "short_message": "Failed password for invalid user admin",
  "full_message": "Failed password for invalid user admin from 192.168.1.100 port 54321 ssh2",
  "timestamp": 1742556000.123,
  "level": 3,
  "_source_ip": "192.168.1.100",
  "_service": "sshd",
  "_environment": "prod"
}

4.3 Streams und Pipelines

Streams sind das zentrale Routing-Konzept in Graylog. Jede eingehende Nachricht kann anhand von Regeln (z. B. Feldwert enthält bestimmten String, regulärer Ausdruck, Schweregrad-Level) einem oder mehreren Streams zugeordnet werden. Typische Streams sind "SSH Authentication Events", "Nginx Errors", "Firewall Drops" oder "Critical Alerts". Pipelines erlauben die Transformation von Nachrichten: Felder können mit Grok-Patterns extrahiert, normalisiert, angereichert oder entfernt werden. Zum Beispiel lässt sich aus einem rohen Nginx-Access-Log-Eintrag ein strukturiertes Dokument mit Feldern wie http_status, client_ip, response_time_ms und request_path erstellen.

4.4 Alerting

Graylog unterstützt Event Definitions und Benachrichtigungen. Ein Event kann ausgelöst werden, wenn innerhalb eines definierten Zeitfensters eine bestimmte Anzahl von Nachrichten in einem Stream auftritt, die einem Suchfilter entsprechen. Aggregationsregeln erlauben es, zum Beispiel auf "mehr als 20 fehlgeschlagene Logins von derselben IP in 5 Minuten" zu alarmieren. Benachrichtigungen können per E-Mail, HTTP-Webhook (Slack, Teams, PagerDuty) oder direkt über Plugins verschickt werden.

5. ELK Stack

Der ELK Stack – bestehend aus Elasticsearch, Logstash und Kibana – ist die bekannteste Open-Source-Lösung für Log-Management und Datenanalyse. Entwickelt von Elastic, bildet er die Basis vieler kommerzieller SIEM-Produkte und ist seit Jahren der de-facto-Standard im Enterprise-Umfeld.

5.1 Komponenten im Überblick

Elasticsearch ist eine auf Apache Lucene basierende Such- und Analysemaschine. Sie speichert Logs als JSON-Dokumente in Indizes, die vollständig und in Echtzeit durchsucht werden können. Elasticsearch ist horizontal skalierbar (Cluster aus mehreren Nodes) und eignet sich für sehr große Log-Volumina. Logstash ist eine flexible Log-Verarbeitungs-Pipeline, die Logs aus verschiedenen Quellen einliest, transformiert (Grok, Mutate, GeoIP, User-Agent-Parsing) und in verschiedene Ziele schreibt. Kibana ist das Visualisierungs- und Management-Frontend für Elasticsearch. Es bietet interaktive Dashboards, die Discover-Oberfläche für Ad-hoc-Volltextsuchen, Alerting und mit dem Security-Modul auch SIEM-Funktionalität inklusive Detection Rules auf Basis des MITRE ATT&CK-Frameworks.

5.2 Filebeat als leichtgewichtiger Shipper

Filebeat ist ein schlanker Log-Shipper aus der Elastic-Beats-Familie, der auf den zu überwachenden Systemen installiert wird und Logs an Elasticsearch oder Logstash weiterleitet. Im Gegensatz zu Logstash verbraucht Filebeat minimal RAM und CPU. Für viele Anwendungsfälle reicht Filebeat direkt ohne Logstash aus, da Elasticsearch mit Ingest Pipelines selbst Log-Transformationen via Grok-Prozessor durchführen kann.

5.3 Vergleich: ELK vs. Loki-Stack

Der wesentliche Unterschied liegt im Indexierungsansatz: Elasticsearch indiziert jeden Term in jeder Log-Nachricht, was schnelle Volltextsuchen ermöglicht, aber erhebliche Ressourcen (RAM, CPU, Disk I/O) erfordert. Ein minimales Elasticsearch-Cluster für produktiven Einsatz benötigt realistisch mindestens 8–16 GB RAM allein für den Heap. Loki hingegen indiziert nur Labels und speichert Log-Zeilen komprimiert, was den Ressourcenverbrauch auf einen Bruchteil reduziert. Dafür sind komplexe Suchen in Loki langsamer, da der gesamte Log-Inhalt zur Laufzeit durchsucht werden muss. Für ein Homelab oder eine kleine Infrastruktur mit begrenzten Ressourcen ist Loki oft die bessere Wahl; für Enterprise-Deployments mit umfassenden Compliance- und SIEM-Anforderungen ist der ELK Stack die ausgereifte Alternative.

6. SIEM-Konzepte

SIEM steht für Security Information and Event Management. Ein SIEM-System sammelt Logs und Ereignisse aus der gesamten Infrastruktur, korreliert sie nach definierten Regeln und alarmiert bei verdächtigen Mustern. Ziel ist die Erkennung von Sicherheitsvorfällen in Echtzeit sowie die nachträgliche Forensik und die Dokumentation für Compliance-Zwecke.

6.1 Correlation Rules

Correlation Rules (Korrelationsregeln) sind das Herzstück eines SIEM. Sie definieren, welche Kombination von Ereignissen als sicherheitsrelevant gilt. Eine einfache Regel könnte lauten: "Wenn innerhalb von 5 Minuten mehr als 10 fehlgeschlagene SSH-Logins von derselben IP-Adresse registriert werden, erzeuge einen Alert vom Typ Brute-Force-Angriff." Komplexere Regeln korrelieren Ereignisse systemübergreifend: Eine erfolgreiche Anmeldung direkt nach 50 Fehlversuchen ist deutlich verdächtiger als die Fehlversuche allein und sollte eine Untersuchung auslösen.

6.2 Typische Use Cases im Homelab und kleinen Umgebungen

SSH-Brute-Force: Erkennung von Brute-Force-Angriffen durch Zählung von "Failed password"- und "Invalid user"-Einträgen im Auth-Log innerhalb eines kurzen Zeitfensters. Typische Gegenmaßnahmen: automatische IP-Sperrung via fail2ban, Alert an den Administrator, Überprüfung ob anschließend ein erfolgreicher Login stattgefunden hat.

Unbekannte Outbound-Verbindungen: Firewall-Logs können auf Verbindungen zu unbekannten oder verdächtigen IP-Adressen hinweisen, die von internen Systemen initiiert werden. Dies kann auf Malware, Command-and-Control-Kommunikation oder kompromittierte Dienste hindeuten. Eine Alert-Regel könnte alle Outbound-Verbindungen zu nicht-whitegelisteten externen IPs auf ungewöhnlichen Ports (nicht 80, 443, 25, 53) flaggen.

Privilege Escalation: Die Nutzung von sudo oder su durch unbekannte Accounts oder zu ungewöhnlichen Uhrzeiten (nachts, am Wochenende) ist ein typischer Indikator für einen laufenden Angriff. Logs aus /var/log/auth.log oder dem systemd-Journal erfassen diese Ereignisse zuverlässig.

Anomalie-Erkennung bei Web-Traffic: Ein plötzlicher Anstieg von HTTP-4xx- oder 5xx-Fehlern, ungewöhnlich große Request-Bodies oder Zugriffe auf bekannte Angriffspfade (z. B. /wp-admin, /.env, /etc/passwd, SQL-Injection-Muster in Query-Parametern) können frühzeitig erkannt werden, bevor ein tatsächliches Eindringen erfolgt.

6.3 Alerting-Integration

Alerts sollten in bestehende Kommunikationskanäle integriert werden. Gängige Ziele sind E-Mail, Slack/Teams-Webhooks, PagerDuty oder selbst gehostete Lösungen wie ntfy.sh oder Gotify. Grafana bietet mit seinem Alerting-System eine flexible Möglichkeit, LogQL-basierte Alerting-Regeln zu definieren und an sogenannte Contact Points weiterzuleiten. Wichtig ist dabei, Alert-Fatigue zu vermeiden: Zu viele False Positives führen dazu, dass Alerts ignoriert werden. Regeln sollten daher mit Schwellenwerten und Zeitfenstern sorgfältig kalibriert werden.

7. Praxisbeispiel: Loki + Promtail + Grafana mit Docker Compose

Im Folgenden wird ein vollständiges Setup beschrieben, das Loki, Promtail und Grafana in einem Homelab-Netzwerk mit Docker Compose betreibt. Ziel ist es, die Systemlogs aller Linux-Server zentral in Loki zu sammeln und in Grafana auswertbar zu machen. Das Setup ist bewusst einfach gehalten und auf einem einzelnen Server mit 2–4 GB RAM lauffähig.

7.1 Docker Compose Konfiguration (Log-Server)

Die folgende docker-compose.yml startet Loki und Grafana auf einem zentralen Log-Server. Promtail wird separat auf jedem zu überwachenden Host als systemd-Dienst installiert.

# docker-compose.yml (Log-Server)
version: "3.8"

networks:
  logging:
    driver: bridge

volumes:
  loki_data:
  grafana_data:

services:
  loki:
    image: grafana/loki:2.9.4
    container_name: loki
    ports:
      - "3100:3100"
    volumes:
      - loki_data:/loki
      - ./loki-config.yml:/etc/loki/local-config.yaml:ro
    command: -config.file=/etc/loki/local-config.yaml
    networks:
      - logging
    restart: unless-stopped

  grafana:
    image: grafana/grafana:10.3.3
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana-provisioning:/etc/grafana/provisioning:ro
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme
      - GF_USERS_ALLOW_SIGN_UP=false
    networks:
      - logging
    depends_on:
      - loki
    restart: unless-stopped

7.2 Loki-Konfiguration

# loki-config.yml
auth_enabled: false

server:
  http_listen_port: 3100
  grpc_listen_port: 9096

common:
  instance_addr: 127.0.0.1
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: 2020-10-24
      store: tsdb
      object_store: filesystem
      schema: v12
      index:
        prefix: index_
        period: 24h

limits_config:
  retention_period: 744h   # 31 Tage Log-Aufbewahrung

compactor:
  working_directory: /loki/compactor
  retention_enabled: true

7.3 Promtail auf den Linux-Hosts installieren

Promtail wird auf jedem Linux-Host als systemd-Service betrieben. Das Binary kann direkt von den GitHub-Releases des Loki-Projekts heruntergeladen werden. Wichtig ist, dass Promtail die IP-Adresse oder den Hostnamen des Loki-Servers im Netzwerk erreichen kann (Port 3100/TCP).

# Promtail Binary herunterladen und installieren (Beispiel: amd64)
curl -LO https://github.com/grafana/loki/releases/download/v2.9.4/promtail-linux-amd64.zip
unzip promtail-linux-amd64.zip
chmod +x promtail-linux-amd64
sudo mv promtail-linux-amd64 /usr/local/bin/promtail

# Konfigurationsverzeichnis anlegen
sudo mkdir -p /etc/promtail

# Konfigurationsdatei schreiben (IP des Log-Servers anpassen)
sudo tee /etc/promtail/config.yml <<'EOF'
server:
  http_listen_port: 9080
  grpc_listen_port: 0

positions:
  filename: /var/lib/promtail/positions.yaml

clients:
  - url: http://192.168.1.50:3100/loki/api/v1/push

scrape_configs:
  - job_name: system_logs
    static_configs:
      - targets:
          - localhost
        labels:
          job: varlogs
          host: HOSTNAME_PLACEHOLDER
          __path__: /var/log/{syslog,auth.log,kern.log,dpkg.log}

  - job_name: journal
    journal:
      max_age: 12h
      labels:
        job: systemd-journal
        host: HOSTNAME_PLACEHOLDER
    relabel_configs:
      - source_labels: [__journal__systemd_unit]
        target_label: unit
      - source_labels: [__journal_priority_keyword]
        target_label: level
EOF

# Platzhalter durch tatsächlichen Hostnamen ersetzen
sudo sed -i "s/HOSTNAME_PLACEHOLDER/$(hostname)/g" /etc/promtail/config.yml
sudo mkdir -p /var/lib/promtail

# systemd-Unit anlegen
sudo tee /etc/systemd/system/promtail.service <<'EOF'
[Unit]
Description=Promtail Log Shipper
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/promtail -config.file=/etc/promtail/config.yml
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now promtail
sudo systemctl status promtail

7.4 Grafana Loki-Datenquelle provisionieren

Über Grafanas Provisioning-Mechanismus lässt sich die Loki-Datenquelle automatisch beim Start einrichten, ohne die Web-UI manuell bedienen zu müssen. Die Datei wird im Verzeichnis grafana-provisioning/datasources/ abgelegt:

# grafana-provisioning/datasources/loki.yml
apiVersion: 1
datasources:
  - name: Loki
    type: loki
    access: proxy
    url: http://loki:3100
    isDefault: true
    editable: false

7.5 Nützliche LogQL-Abfragen für das Dashboard

Mit den folgenden LogQL-Abfragen lassen sich in Grafana aussagekräftige Panels für ein Homelab-Übersichts-Dashboard erstellen:

# Fehlgeschlagene SSH-Logins pro Host (letzten 24 Stunden)
sum by (host) (count_over_time({job="varlogs"} |= "Failed password" [24h]))

# Sudo-Nutzung aus dem systemd-Journal
{job="systemd-journal"} |= "sudo"

# Kernel-Fehler (OOM-Killer, I/O-Fehler, Hardware-Warnungen)
{job="varlogs"} |~ "(Out of memory|I/O error|Hardware Error|kernel BUG)"

# Nginx HTTP-5xx-Fehlerrate pro Minute
rate({job="nginx"} |~ " 5[0-9]{2} " [1m])

# Alle Logs eines bestimmten Hosts der letzten 15 Minuten
{host="fileserver-01"}

# systemd-Units die als "failed" markiert sind
{job="systemd-journal"} |= "entered failed state"

# Neue SSH-Verbindungen (erfolgreiche Logins)
{job="varlogs"} |= "Accepted publickey" or {job="varlogs"} |= "Accepted password"

7.6 Grafana Alert für SSH-Brute-Force

In Grafana lässt sich direkt eine Alerting-Regel auf Basis einer LogQL-Metriken-Abfrage erstellen. Unter Alerting → Alert Rules wird eine neue Regel mit der folgenden Abfrage angelegt. Wenn der Schwellenwert überschritten wird, sendet Grafana eine Benachrichtigung an den konfigurierten Contact Point (z. B. einen Webhook zu ntfy oder Gotify).

# LogQL-Metriken-Abfrage für den Grafana Alert
# Zählt fehlgeschlagene SSH-Logins pro Host in 5-Minuten-Fenstern
sum by (host) (
  count_over_time(
    {job="varlogs"} |= "Failed password" [5m]
  )
)

# Alert-Bedingung:
#   WHEN last() OF query IS ABOVE 10
#   FOR 0m  (sofort auslösen, nicht warten)
#
# Dies löst einen Alert aus, sobald mehr als 10 fehlgeschlagene
# SSH-Logins in einem 5-Minuten-Fenster von einem Host gemeldet werden.

7.7 Fazit und nächste Schritte

Mit diesem Setup läuft innerhalb weniger Stunden eine vollständige Log-Aggregation für ein Homelab. Loki ist ressourcenschonend genug, um auf einem kleinen Server oder einer leistungsfähigen NAS betrieben zu werden. Als nächste Schritte bieten sich an: das Hinzufügen von Docker-Container-Logs (Promtail kann den Docker-Socket oder den Container-Log-Pfad lesen), das Einsammeln von OPNsense-Firewall-Logs via Syslog-Input in Graylog oder direkt als Syslog-Datei für Promtail, die Einrichtung von Grafana Unified Alerting mit Benachrichtigung via ntfy oder Gotify sowie die Konfiguration von Log-Retention-Policies über den Loki-Compactor, um Speicherplatz zu kontrollieren. Wer mehr Suchflexibilität und ausgereifte SIEM-Funktionalität benötigt, sollte einen Blick auf Graylog werfen – das Setup ist aufwendiger und ressourcenhungriger, bietet aber vollständige Indizierung, mächtigere Korrelationsregeln und eine ausgefeiltere Web-UI für die Incident-Analyse.