Threat model¶

Honest answer to "what does Fenrir actually protect against, and what doesn't it?". We write this down because every security tool has a scope, and pretending otherwise is what gives security tools a bad name.

What Fenrir protects against¶

Sustained automated attacks¶

The 90% case for an internet-facing Linux server: bot scanners hitting /wp-admin, SSH brute-forcers, exploitation kits looking for known CVEs. Fenrir reliably detects and bans these. The combination of honeypot_monitor + auth_monitor + fail2ban_monitor plus the AI analyst is enough that you can stop reading SSH logs.

Persistence after compromise¶

If an attacker does breach a service, what they typically do next is one of:

Add a new user account
Drop a setuid binary
Open a new listening port for a reverse shell
Add a cron job
Install a package (cryptominer, persistence agent)

The baseline_monitor + package_monitor together catch all of these within minutes (10 minutes worst case for baseline, real-time for package). Severity is CRITICAL by default.

Operator mistakes¶

Engineers do dumb things at 2am: enable an unused service, install a package that opens a port, leave debug mode on. These all surface in the baseline diff. Not as "attacks" — as drift you can review and acknowledge or revert.

Vulnerability staleness¶

cve_monitor ensures you know when security patches are pending, with severity weighted by package criticality. Combined with the daily Telegram digest, you can't claim "we didn't know" about a 3-week-old openssl CVE.

Compliance evidence collection¶

For the GDPR / NIS2 / ISO 27001 controls Fenrir touches, the daily audit produces dated, machine-readable evidence. An auditor's "show me last quarter's breach handling" goes from a multi-day spelunk to a 30-second filter.

What Fenrir does NOT protect against¶

Compromised humans¶

If a legitimate user clicks a phishing link and types their SSO password into a fake page, Fenrir on your server doesn't see anything. The successful login from that user's account looks legit because it is legit (just on the wrong side of the human attacker). This is what an EDR + DLP + browser security stack is for.

Application-level vulnerabilities¶

A SQL injection in your custom Flask app that exfiltrates data via legitimate HTTP responses doesn't trip any Fenrir alert. Web application firewalls (Cloudflare WAF, ModSecurity), SAST (Snyk, Bandit), DAST (Burp), and bug bounties are the layers for that.

Insider threats¶

A privileged user who's actively malicious can disable Fenrir, edit logs, or bypass it. Defense-in-depth (separate audit log shipping, immutable backup, four-eyes for production access) is your answer there. Fenrir is one layer, not the only layer.

Sophisticated targeted attacks¶

Fenrir's web/auth detection is rate-based on short windows. Patient adversaries that work below those thresholds — slow, distributed, sub-rate — fall outside what we catch today. Closing this gap requires behavioural analytics over hours/days of event history, with cross-host correlation; that is a different product class (XDR / UEBA) and is intentionally out of our scope. Pair Fenrir with one of those upstream if you face determined APTs.

Zero-day exploits¶

If an attacker uses a vuln that nobody has patched yet, no cve_monitor alert exists. The attacker compromises a service. After compromise, Fenrir sees the persistence behaviors (new user, port, etc.) — so we catch the post-exploitation phase. But we don't prevent the initial exploitation.

Endpoint compromise¶

Laptops, phones, BYOD devices — Fenrir watches servers, not endpoints. EDR (CrowdStrike, SentinelOne, Defender for Endpoint) is the answer for endpoints.

Supply-chain compromise¶

If pip install p3guardian ships a malicious dependency that backdoors itself, Fenrir is compromised at install time. Not a Fenrir-specific problem; affects every Python service. Mitigations: pin versions, audit deps, run dependency scanning (pip-audit, Snyk, safety).

Network-level attacks below the host¶

L2/L3 attacks (ARP poisoning, BGP hijack, DNS hijack) happen below the host's visibility. Fenrir sees the symptoms (sudden traffic from unexpected IPs) but not the cause.

Physical attacks (mostly)¶

Disk extraction, cold boot, supply-chain hardware tampering. The one thing Fenrir does see: someone plugging a USB into the server (kernel_monitor USB events). That's it.

Where Fenrir fits in your security stack¶

┌─────────────────────────────────────────────────────┐
│  HUMAN LAYER                                         │
│  Training, NDA, background checks  (you)             │
├─────────────────────────────────────────────────────┤
│  ENDPOINT                                            │
│  EDR, MDM, browser security  (Crowdstrike etc.)      │
├─────────────────────────────────────────────────────┤
│  IDENTITY                                            │
│  SSO, MFA, JIT  (Okta / Authentik / Keycloak)        │
├─────────────────────────────────────────────────────┤
│  APPLICATION                                         │
│  WAF, SAST, DAST, bug bounty  (Cloudflare, Snyk)     │
├─────────────────────────────────────────────────────┤
│  ★ HOST / SERVER ★                                   │
│  ★ FENRIR ★                                          │
├─────────────────────────────────────────────────────┤
│  NETWORK                                             │
│  Firewall, segmentation, DDoS  (UFW, Cloudflare)     │
├─────────────────────────────────────────────────────┤
│  PHYSICAL                                            │
│  DC access, disposal  (your facility)                │
└─────────────────────────────────────────────────────┘

Fenrir owns one layer. Don't try to make it own others — the result will be worse than separate dedicated tools.

What you can do with Fenrir to extend coverage¶

Pair Fenrir with Cloudflare (WAF + Tunnel) for app-layer + network-layer.
Pair with Wazuh agents on your endpoints (it's a complement, not a competitor — Wazuh covers Win/Mac endpoints; Fenrir covers your Linux servers more tightly).
Send Fenrir's events to a central SIEM (Elastic Security, Loki + Grafana, Splunk) for cross-host correlation. Use the /api/ingest endpoint or stream from PostgreSQL.
Hook Fenrir alerts into incident runbooks that involve your team — Telegram is fast but isn't an IR platform. PagerDuty / Opsgenie integration is a few lines of code in responders/.

The honest summary¶

Fenrir is a good Tier-1 SOC for one Linux server, with autonomous AI analysis, audit-ready evidence, and a price point that fits SMBs. It is not a complete security program. If you're not honest with yourself about that, the inevitable gap will hurt the day a real incident hits.