FENGARDE

Anmelden. Nachweise raus.
Open-Source-Sicherheitspipeline für IT, KI und OT: von Rohlogs zu einem verifizierten Vorfall und einem Entwurf einer NIS2-Meldung.

Projektseite und Live-Demo · Schnellstart · Konsole · Architektur · Status (SSOT)

Badges spiegeln den letzten echten Lauf auf main wider, kein Versprechen. Die verbleibenden Scorecard-Befunde sind akzeptierte, dokumentierte Kompromisse, keine Lücken; siehe SSOT.md §1.

FENGARDE verbindet Sicherheitstelemetrie über IT, KI und OT hinweg, um zu zeigen, was passiert ist, wer oder was gehandelt hat, was betroffen war, wie die Ereignisse zusammenhängen und welche Nachweise die Schlussfolgerung stützen.

Gebaut für den europäischen industriellen Mittelstand: Open Source, selbst gehostet, Apache-2.0, mit einem Entwurfspfad für NIS2-Vorfallmeldungen, einem deterministischen deutsch-/englischsprachigen Report-Generator, optionalem RBAC/MFA/Audit-Log/Multi-Tenancy für MSP-artige Deployments, einem optionalen HA-Profil (live-kill-getestet, nicht nur verdrahtet) und KI-Triage, die Ihr Netzwerk nie verlässt.

Logs werden gesammelt, auf ein einziges Schema normalisiert (OCSF), über Korrelationsregeln in einem gleitenden Fenster verarbeitet, zu Incidents mit einem Kausalitätsgraphen und einem hash-verketteten Evidenzpaket gruppiert und in OpenSearch indiziert. Jeder Dienst ist unabhängig und kommuniziert mit den anderen nur über einen Message Bus, sodass jeder Teil skaliert oder ersetzt werden kann, ohne die anderen umzuschreiben.

Warum FENGARDE

• OCSF-nativ, nicht nachgerüstet. Jede Quelle normalisiert vom ersten Tag an auf dasselbe offene Schema, sodass eine Regel jede Quelle abdeckt, die das Ereignis ausgibt: ein SSH-Login, ein Windows-Login und ein Active-Directory-Login sind eine Brute-Force- Erkennung, nicht drei. Keine Bindung an ein Hersteller-Logformat.
• OT und IT in einer Pipeline. OPC UA und Modbus/TCP normalisieren in dasselbe Schema wie Active Directory, Windows und Ihre Firewall, sodass die Werkshalle durch dieselbe Erkennungs-Engine, Konsole und denselben Report-Pfad läuft wie das Büro- netzwerk, nicht durch eine zweite Toolchain.
• KI-Triage, die Ihr Netzwerk nie verlässt. Lokales Ollama, wenn OLLAMA_URL gesetzt ist; andernfalls ein gelabelter deterministischer Stub. Alarmdaten werden nie durch eine LLM-API eines Drittanbieters geleitet, und die Konsole nennt, welche Engine tatsächlich lief. Die Urteilsqualität ist bei den beiden gemessenen Modellen schlecht (qwen2.5:3b 1 von 54 gelabelten Alarmen korrekt, qwen2.5:7b 7 von 54, überwiegend suspicious-Antworten); siehe eval/llm_triage/RESULTS.md.
• Nachweise, nicht nur Alarme. Incidents tragen einen typisierten Kausalitätsgraphen und ein Merkle-Hash-Chain-Evidenzpaket, das die API vor der Auslieferung verifiziert.
• Ehrlicher Status. Was bewiesen, was behauptet und was gestubbt ist, ist in SSOT.md festgehalten und durch Tests erzwungen; dieses README fasst es nur zusammen.

OpenSearch, nicht Elastic: kein Lizenz-Sternchen auf der Storage-Engine (ADR 003). Wissenswert, aber kein Unterscheidungsmerkmal gegenüber Wazuh (dessen Indexer ebenfalls ein OpenSearch-Fork ist).

Ausprobieren

Schnellstart

git clone https://github.com/supermhel/fengarde.git && cd fengarde
make preflight   # doctor: checks vm.max_map_count, Docker RAM, free ports
make demo        # docker compose up -- a real SSH brute-force alert appears
                 # in the dashboard within ~30-60s, no manual step
# open http://localhost:8080

Kein Docker zur Hand? Die gesamte Erkennungspipeline läuft ohne Infrastruktur:

make e2e         # SSH brute-force -> real alert -> idempotent replay, no Docker/Redis/OpenSearch
bash tools/demo.sh   # same test, narrated (Windows: powershell -File tools\demo.ps1)

Was Sie sehen: 10 fehlgeschlagene Anmeldungen von einer IP innerhalb von 60 Sekunden (SSH Failed password oder Windows EventID 4625 — beide werden auf dasselbe OCSF-Authentication-Event normalisiert) lösen common_bruteforce.yml aus (threshold: 10, window_seconds: 60, gruppiert nach Quell-IP), und der Alarm erscheint in der Alarmliste des Dashboards, idempotent bei erneuter Zustellung.

Voraussetzungen: Docker Desktop oder Docker Engine + Compose v2, ≥4 GB RAM für Docker zugewiesen; Linux, macOS oder Windows über WSL2 (Linux-Container, POSIX-sh-Skripte). Python 3 nur, wenn Sie einen Parser beitragen — dafür ist kein Docker erforderlich (siehe Contributing).

sudo sysctl -w vm.max_map_count=262144
# persist across reboots:
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-fengarde.conf

Weitere Ziele: