Why fail2zig
A daemon that reads attacker-influenced logs and changes firewall rules deserves a deliberately small runtime. fail2zig rebuilds host intrusion prevention around that requirement: constrained parsing, bounded tracking, and direct kernel enforcement.
Explore the design decisionsBuilt on a good idea. fail2ban established the jail model operators know and trust. fail2zig keeps that vocabulary and takes a different implementation path.
jailfiltermaxretryfindtimebantimeignoreip The architectural difference
Each choice removes a runtime dependency, constrains input handling, or limits resource growth.
fail2zig ships a static executable with Zig application code, embedded SQLite C and musl. Daemon, administration and migration share that artifact, with no Python runtime or database server required.
One compiled artifact to deploy, inventory, and replace.
Examine the trust surfaceBuilt-in filters become specialized matching functions at compile time. Custom jails use bounded native JSON rules, with offline rule testing. Arbitrary regexes, Python extensions and shell actions are not executed.
A constrained parser for input an attacker can influence.
Inspect the parserNative receipts, retries, source checkpoints and protection owners persist in SQLite. Explicit resource limits bound admission; storage failure pauses affected ingestion while retaining protection and reporting degraded health.
Critical protection state stays durable under resource pressure.
Understand the memory bound
The default nftables backend sends structured netlink messages directly to Linux and
confirms installed protection by owned-kernel readback. It needs neither a
shell-action template nor the nft executable to install bans.
No command-string interpretation in the nftables ban path.
Follow a kernel operationfail2ban’s shell actions use the system shell; Python actions are also supported. Its filter guidance explicitly addresses hostile log input. fail2zig’s distinction is the constrained runtime it chooses to ship.
Operational confidence
Knowing that a process is running is only the beginning. Operators also need to see what each jail reads, whether that source is healthy, and whether the jail enforces.
status · jails · /metrics The resolved file, journal, or internal feed, with its reported read health.
Log-only decisions stay separate from firewall operations, including after restart.
No usable backend means exit by default. Explicit observe-only fallback reports DEGRADED.
Status describes the daemon’s operating state. Verifying packet drops still requires checking enforcement on the host. Verification steps
This distinction shaped development: real-system checks exposed gaps in filter wiring, log rotation, and restart enforcement. Fixes gained regression coverage alongside the deployment tests.
Threat modeling with STRIDE
The published model maps adversaries and trust boundaries to six STRIDE categories. Each threat names its controls and the risk that remains, so you can judge the design against your own environment.
Read the full threat modelSix perspectives on the same system
Published design analysis. Independent security audit remains planned.
The tradeoffs are deliberate
journalctl, and the ipset/iptables backends execute their tools with
discrete arguments.
Evaluate it on your host
Import your jails, review the differences, and verify enforcement before you switch.