Audit Reports and Compliance

Audit Reports and Compliance

Type: Operator / Auditor Reference · Last reviewed for terminology: v1.220.1 Terminology: Glossary & Vocabulary · Access model: Security Architecture

NFTBan produces operator- and auditor-facing reports. This page inventories them, documents the auditor access model (group + Polkit, not sudo), and states what each report does and does not prove.

Report inventory

Report	Supported command	Output	Location	Privilege	Audience
Four-axis health	nftban health / nftban health --json	text / JSON	stdout + health_status.cache	read	operator/auditor
Kernel/schema validation	nftban validate / nftban validate --json (impl: /usr/lib/nftban/bin/nftban-validate)	text / JSON	stdout	read	operator/auditor
FHS compliance	nftban fhs report	text / HTML	/var/lib/nftban/reports/fhs_report/	read	auditor
Permissions/ownership audit	(permissions subsystem)	text	/var/lib/nftban/permissions_audit.log	read (root-owned)	auditor
Module / stats report	nftban report	HTML / text	/var/lib/nftban/reports/{daily,monthly}/	read	operator/auditor
Feed / GeoIP freshness	nftban feeds … / nftban status	text	stdout	read	operator
RBL report	nftban rbl status / nftban rbl server check	text	stdout	read (observe-only)	operator
Watchdog / resource	nftban health + /var/lib/nftban/reports/watchdog/	json	reports/watchdog	read	operator
Metrics / export	nftban stats / Prometheus textfile	text / prom	/var/lib/nftban/metrics/	read	operator
Support bundle	nftban support …	archive	operator-chosen path	root (collects system state)	maintainer

Command/path rule: the supported nftban … command is primary; the internal binary (/usr/lib/nftban/bin/nftban-validate) is shown only as the implementation, never as the normal command.

Auditor workflow (group + Polkit — not sudo)

An auditor uses NFTBan directly from their own login session. The account must belong to the nftban-auditor group.

id
groups                       # expect: nftban-auditor

nftban status
nftban health
nftban validate
nftban report

NFTBan's authorization layer recognizes the nftban-auditor group and limits the account to approved read-only operations. Where an approved command requires a privileged backend action, Polkit mediates that specific action. Auditors do not require blanket sudo access.

Role model:

• nftban → operator/admin role
• nftban-auditor → read-only role
• Polkit authorizes specific privileged backend operations; sudo is not the normal NFTBan authorization path.

Administrators may simulate the auditor identity during validation — this is a root-run role-simulation test, not the normal auditor workflow:

# Administrative role-simulation test (run by root)
runuser -u <auditor-user> -- nftban status      # preferred (no sudo implication)
sudo -u <auditor-user> -- nftban health         # equivalent

Negative tests (validate the boundary)

Confirm the real auditor account can read:

nftban status
nftban health
nftban validate

and cannot mutate — each must produce a clean authorization denial through NFTBan/Polkit policy (not merely because the user lacks sudo):

nftban ban 192.0.2.10
nftban unban 192.0.2.10
nftban firewall rebuild
nftban config set ...
nftban fhs repair

Do not test auditor access as root and infer that the auditor role works — validate as the auditor identity (login session or runuser).

Report evidence boundaries (what each proves / does not prove)

• FHS report proves path/owner/mode consistency vs the FHS spec — not absence of compromise.
• Validator report proves observed kernel structure + health interpretation — not historical attack effectiveness.
• RBL report proves queried DNSBL results — not mail deliverability.
• Communication report (delivery log) proves attempted delivery / accepted transport handoff — not inbox placement.
• Permissions/audit log proves recorded actions/state — not complete host integrity.

Retention & integrity

Reports live under /var/lib/nftban/reports/ (nftban:nftban, 0750), with auditors/ writable by the auditor role for audit output. Retention: reports rotate monthly ×3 via logrotate; the permissions audit log weekly ×12. Records carry host identity, timestamp, and (for update/forensic paths) a run ID. Support bundles apply redaction (nftban_redact.sh).

No tamper-evidence claim. NFTBan does not currently ship checksums, signatures, or immutable attributes on report files, so integrity/tamper evidence is not asserted — reports are operator-modifiable. Auditors have read access; root-owned forensic records stay root-only.

See Logging, Rotation & Retention and Security Architecture (auditor access + report integrity).