Fenrir runs as a full Docker Compose stack: collection, transport, storage, detection, and response, all on hardware you control.
Ingestion and storage
Vector 0.36 collects logs and hands them to Redpanda, a Kafka-compatible message bus running as a single binary. From there, logs land in ClickHouse 24.2, a columnar store built for sub-second SQL over large log volumes. Postgres 16 holds metadata: cases, rule state, users. Redis handles cache and realtime state. MinIO provides cold storage for data that’s aged out of hot queries.
Detection engine
Detection rules are written in Sigma, a YAML-based rule format, and compiled through pySigma into ClickHouse SQL that runs against the normalized log store. Because rules are plain text files in Git, they’re diffable and reviewable the same way application code is, with no proprietary rule DSL locked behind a vendor console.
Every alert the engine generates carries a non-nullable MITRE ATT&CK TTP field. Cases assemble those TTPs into a kill-chain view, letting an analyst trace technique progression across an incident rather than triage a flat alert queue. When the compiled rule set doesn’t cover a query an analyst wants to run, a built-in ClickHouse SQL console gives direct access to the raw normalized logs.
Vulnerability management and response
Vulnerability management correlates NVD, CISA’s KEV catalog, and EPSS scores, tying known vulnerabilities to what’s actually exploited in the wild and how likely exploitation is. Remediation runs through SOAR playbooks included in the base install, executing inside a WASM sandbox to isolate playbook logic from the host.
Transparency
MTTD/MTTR benchmarks are computed per detection and stored under docs/transparency/, version-controlled alongside the codebase. Benchmarks replay against the OTRF and EVTX-ATTACK-SAMPLES datasets, public attack sample sets, and can be regenerated independently with docker compose run --rm fenrir-bench all. The published numbers are a byproduct of a command anyone running the stack can execute, not a static claim in a doc.
Network anomaly detection: fenrir-netflow
fenrir-netflow is an optional Compose profile, separate from the core install. Zeek monitors network traffic and produces flow records for TCP/UDP sessions. ByteFlow, a byte-level language model, scores each flow’s payload as bits-per-byte using dynamic-T inference. High bits-per-byte indicates high-entropy payload content, the signature of encrypted or compressed data with no learnable structure, which is the pattern covert channels produce: C2 tunnels, exfiltration, encrypted beacons.
It runs without a GPU. CPU-only throughput is roughly 4 flows/s per worker, scaled horizontally with SCORER_WORKERS. On an NVIDIA GPU (measured on an RTX 3060) with BF16 precision and torch.compile:
| Flow size | flows/s | p50 latency |
|---|---|---|
| 64–256 B | 33–34 | 28–30 ms |
| 512 B | 30 | 32 ms |
| 1024–2048 B | 24–25 | 40 ms |
Throughput drops and latency climbs as flow size grows, consistent with a per-byte scoring model doing more inference work per flow.
Stack
| Layer | Tech |
|---|---|
| Log collection | Vector 0.36 |
| Message bus | Redpanda |
| Log storage | ClickHouse 24.2 |
| Metadata | PostgreSQL 16 |
| Cache / realtime | Redis 7 |
| Cold storage | MinIO |
| Core services | Rust (axum / tokio) |
| Detection rules | Sigma / pySigma → ClickHouse SQL |
| Network anomaly detection | Python + PyTorch (ByteFlow) |
| Frontend | React + TypeScript + Vite |
| Reverse proxy | Caddy 2 |
Deployment needs Docker 24+, Compose v2, 16 GB RAM, 40 GB disk. First boot: clone the repo, copy .env.example to .env and set credentials including FENRIR_ADMIN_PASSWORD, run docker compose up -d, wait for services to report healthy, then run scripts/load_rules.sh (or the PowerShell equivalent on Windows) to load the Sigma rule set into the detection engine.