Log-Management10. Juli 2026 · 6 Min. Lesezeit

Where to Log: Zentrales Logging ohne teure SIEM-Lizenz

Einleitung

Logs auf einzelnen Endpoints sind so nützlich wie ein Tagebuch im brennenden Haus. Bei einem Incident sind die Endpoints oft schon kompromittiert, die lokalen Logs gelöscht oder die Maschine ist vom Netz. Zentrales Logging ist deshalb keine Komfortfunktion, sondern Basis für Detection, Forensik und Compliance. Dieser Artikel zeigt dir, wie du das ohne fünfstelliges Splunk-Budget umsetzt.

Warum das Thema wichtig ist

Drei Dinge können nur zentrales Logging leisten: Korrelation (Auth-Versuch von Host A → Lateral Move auf Host B → Datenabfluss von Host C), Beweissicherung (Logs sind nach Kompromittierung des Endpoints noch greifbar) und Skalierung (du willst nicht 200 Endpoints einzeln durchwühlen). NIS2, BSI IT-Grundschutz und ISO 27001 verlangen alle implizit oder explizit zentralisierte, schreibgeschützte Log-Speicherung. Und auch ohne Compliance-Druck: ein zentraler Log-Speicher mit 90 Tagen Retention ist im Incident-Fall mehr wert als jedes EDR-Tool.

Die Optionen im Überblick

Stack Stärke Aufwand Ressourcenbedarf
Wazuh (ELK + HIDS + SIEM) All-in-one, MITRE-Integration mittel 16 GB RAM, 200 GB Disk Start
Graylog Open UI / Dashboards / Alerting mittel 8 GB RAM, 100 GB Start
ELK / OpenSearch flexibel, große Community hoch 16 GB RAM+, vielen Tuning-Bedarf
Loki + Grafana leichtgewichtig, log-as-stream niedrig 4 GB RAM, sehr platzsparend
Rsyslog + SQLite/PostgreSQL + grep minimal, ohne UI sehr niedrig <2 GB RAM

Empfehlung für KMU: Wazuh, wenn du Detection mit Logs verbinden willst (siehe Wazuh-Artikel). Graylog oder Loki+Grafana, wenn du nur Logs sammeln und durchsuchen willst, ohne den vollen SIEM-Overhead.

Architektur: Was wohin?

Eine vernünftige Mindest-Architektur für ein KMU:

              ┌─────────────────────────────┐
              │   Endpoints / Server / FW   │
              └──────────────┬──────────────┘
                             │  Syslog/Beats/HEC
                             ▼
              ┌─────────────────────────────┐
              │   Log-Forwarder (zentral)   │   ← rsyslog / Vector / Filebeat
              │   - Parsing / Enrichment    │
              │   - Routing                 │
              └──────────────┬──────────────┘
                             │
                ┌────────────┴───────────┐
                ▼                        ▼
       ┌─────────────────┐      ┌────────────────┐
       │ Hot-Storage     │      │ Cold-Storage   │
       │ (durchsuchbar,  │      │ (S3/Object,    │
       │  30 Tage)       │      │  90+ Tage)     │
       └─────────────────┘      └────────────────┘
                │
                ▼
       ┌─────────────────┐
       │ Detection /     │
       │ Dashboards /    │
       │ Alerting        │
       └─────────────────┘

Der Forwarder ist die wichtigste Komponente: er normalisiert Formate (Syslog ↔ JSON ↔ CEF), reichert IPs mit Geo/ASN an, und routet nach Pflicht (Auth-Logs → SIEM-Hot-Store, Application-Debug → Cold-Store). Vector und Fluent-Bit sind hier Open-Source-Standard.

Welche Logs? (Priorisierung)

Nicht alles muss zentralisiert werden. Priorisiere nach Detection-Wert:

Pflicht (täglich auswerten):

Sollte (Korrelation / Analyse):

Optional:

Forwarder: Beispiele

Windows: NXLog Community Edition

Robuste Windows-Eventlog-Forwarder-Konfiguration. Beispiel nxlog.conf für Security/Sysmon-Forward an Syslog-TCP:

<Input EventLog>
    Module      im_msvistalog
    Query       <QueryList>\
                    <Query Id="0">\
                        <Select Path="Security">*</Select>\
                        <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>\
                        <Select Path="System">*[System[(Level=1 or Level=2 or Level=3)]]</Select>\
                    </Query>\
                </QueryList>
</Input>

<Output Syslog>
    Module      om_tcp
    Host        siem.intern.local
    Port        514
    Exec        to_syslog_ietf();
</Output>

<Route 1>
    Path        EventLog => Syslog
</Route>

Alternativ: Winlogbeat (Elastic), Wazuh-Agent (für Wazuh-Stack), Vector (für Loki/Graylog).

Linux: rsyslog

# /etc/rsyslog.d/50-forward.conf
# Forward alle Logs an SIEM via TCP, mit Disk-Queue für Resilience
*.* action(type="omfwd"
    target="siem.intern.local"
    port="514"
    protocol="tcp"
    queue.type="LinkedList"
    queue.filename="forwardq"
    queue.maxdiskspace="1g"
    queue.saveonshutdown="on"
    action.resumeRetryCount="-1")

Bei vielen Hosts und unzuverlässigen Verbindungen ist die Disk-Queue Pflicht – sonst verlierst du Logs bei jedem Netz-Hick.

Firewalls / Switches

Fast alle Enterprise-Firewalls (Sophos, Fortinet, pfSense, OPNsense, Cisco ASA / FTD) sprechen Syslog. Konfiguration üblicherweise in der Web-UI: Syslog-Server-IP eintragen, Severity-Level und Facility wählen, fertig. Empfehlung: mind. „informational“ Level, nicht nur „warning“ – wir brauchen die Connections.

Speicher-Sizing (faustformel)

Die mit Abstand wichtigste Frage vor dem Setup: wieviel Storage brauchst du? Faustformel pro Endpoint:

Quelle Volumen pro Endpoint/Tag
Windows Security-Eventlog 50–200 MB
Sysmon (Standard-Config) 100–500 MB
Sysmon (Verbose / Network) 1–3 GB
Linux audit (Default-Regeln) 20–100 MB
Firewall (per Connection) je nach Traffic, 100 MB–10 GB
DNS (per Endpoint) 5–50 MB

Für 100 Endpoints + 1 Firewall + DNS landest du grob bei 20–80 GB/Tag. Mal 30 Tage Hot + 90 Tage Cold (komprimiert): rechne mit ~3 TB. Compression (Zstd, Snappy) bringt Faktor 5–10. Plane Headroom – Logs wachsen, nicht schrumpfen.

Schreibschutz und Manipulationsschutz

Ein Angreifer mit Domain-Admin-Rechten löscht zuerst die Logs. Drei Maßnahmen:

  1. Immutable Storage für Cold-Store: S3 mit Object-Lock, MinIO mit Versioning, oder Backups auf Tape / Read-Only-NAS
  2. Separates Auth-Domain: Log-Server nicht im selben AD wie der Rest. Lokale Admin-Accounts oder separate FreeIPA-Domain
  3. Forwarding-Only: Endpoints schreiben, lesen aber nicht. Wer am Endpoint Logs leeren will, beeinflusst die Kopie auf dem Log-Server nicht

Wazuh und Graylog haben Audit-Trails für ihre eigenen Aktionen – nutze sie.

Detection und Korrelation

Ein zentraler Log-Speicher allein ist nicht aktiv. Du brauchst:

Der zweite Punkt ist oft der wichtigste: 80 % der IR-Arbeit ist nach „wer hat wann was?“ googeln in deinen Logs. Wenn du das schnell beantworten kannst, ist die Plattform schon viel wert – auch ohne ausgereifte Detection.

Stolperfallen

Praxis-Checkliste

Fazit

„Where to Log“ ist keine Tool-Frage, sondern eine Architektur-Frage: Wo landen deine Logs, wer kommt dran, wie lange bleiben sie? Wer das mit Wazuh, Graylog oder Loki + Grafana sauber löst, hat ein zentrales Log-System auf Niveau einer Enterprise-SIEM-Lösung – ohne Lizenzkosten. Die eigentliche Investition ist Zeit: 2–3 Wochen für Aufbau, dann pro Quartal ein Tag für Pflege und Tuning. Das sollte jedes KMU schaffen.

Wenn du tiefer einsteigen willst: Im Newsletter zeige ich jeden Monat konkrete Logging-Setups, Forwarder-Configs und Cost-Sizing-Tabellen. Trag dich ein.

← Zurück zur Übersicht