Firewall and backends

What minsec creates

The nft backend owns table inet minsec and touches nothing outside it:

Priority -10 puts the chains ahead of firewalld and iptables-nft without modifying a single rule of theirs, so minsec composes with an existing firewall instead of fighting it. Allow entries are matched before bans; crowd entries are enforced after your allowlist and your local bans.

sudo nft list table inet minsec
sudo nft list set inet minsec ban4

Why bans live in the kernel

Each set element has an nftables timeout. That has three consequences worth knowing:

• Bans expire on their own, with no daemon involvement.
• Bans survive a restart or a crash of the daemon — there is no userspace ban list to lose or to resynchronise.
• minsec list asks the kernel for truth rather than reporting its own opinion.

Other backends

[defaults]
backend = "nft"     # nft | null | exec

null runs the full engine and logs what it would ban. This is the right way to try a configuration on a production server:

sudo minsec daemon --backend null

exec runs a script for each action, for platforms nftables does not cover:

<cmd> ban <net> <ttl>
<cmd> unban <net>

The exec backend cannot enumerate bans, so minsec list answers from the daemon's in-memory mirror and only covers bans issued since it started. ipset and pf backends are on the roadmap.

IPv6

IPv6 is tracked and banned per /64 by default (ipv6_prefix = 64), because an attacker holding a /64 has effectively unlimited single addresses. Reports to the crowd are aggregated the same way.

Interaction with firewalld

None required. minsec's chains run first at priority -10; firewalld's rules are untouched and still apply to everything minsec does not drop. You do not need to add a firewalld service, zone, or direct rule.