NFTBan enforces security through a kernel-first validation model and automated CI/CD pipelines.
→ Full audit surface: Integrity & Build Status (STATUS.md)
This includes:
- CI pipeline results (build, security, compliance)
- Contract gate enforcement
- Supply chain verification (SLSA Level 3)
- Runtime verification commands
This page describes vulnerability reporting and security policy. STATUS.md provides machine-verifiable system integrity.
NFTBan is an open-source Linux Intrusion Prevention System (IPS) and firewall manager built on nftables. Security is foundational to the architecture, featuring capability-based privilege separation, systemd sandboxing, Unix socket IPC, and strict input validation at all layers.
| Version | Support Status |
|---|---|
| 1.61.x | Current - Full support (security fixes, bug fixes, features) |
| 1.60.x | Security fixes only |
| < 1.59 | Not supported - upgrade immediately |
Recommendation: Always run the latest stable release (currently v1.61.0) for optimal security and performance.
Security fixes are prioritized for Tier 0 platforms first.
| Tier | Platforms | Support Level |
|---|---|---|
| Tier 0 | Ubuntu 24.04 LTS, Debian 12, Rocky Linux 9.x | Fully supported |
| Tier 1 | Rocky Linux 10.x, Debian 13, Ubuntu 26.04 LTS | Planned |
| Tier 2 | Rocky/RHEL 8.x, Ubuntu 22.04 LTS, Debian 11 | Best-effort (legacy) |
We take security seriously and follow responsible disclosure practices. If you discover a security vulnerability in NFTBan, please report it responsibly.
DO NOT report security vulnerabilities through public GitHub issues.
Report security vulnerabilities via:
- Email: security@nftban.com
- Subject Line: Include
[SECURITY]prefix - Required Information:
- Description of the vulnerability
- Steps to reproduce
- Potential impact assessment
- Affected versions
- Suggested fix (if available)
- Your contact information for follow-up
| Phase | Timeline |
|---|---|
| Acknowledgment | Within 48 hours |
| Initial Assessment | Within 7 days |
| Status Updates | Every 7-14 days until resolution |
| Patch Development | Based on severity (Critical: 7 days, High: 14 days, Medium: 30 days) |
NFTBan follows a 90-day coordinated disclosure policy:
- Day 0: Vulnerability reported
- Day 1-7: Initial assessment and severity classification
- Day 7-60: Patch development and testing
- Day 60-75: Private disclosure to affected users (for critical infrastructure)
- Day 75-90: Public release preparation
- Day 90: Public disclosure with security advisory
Exceptions:
- Actively exploited vulnerabilities may be disclosed sooner
- Complex issues may require timeline extension (with reporter agreement)
- Reporters will be kept informed throughout the process
We publicly acknowledge security researchers who responsibly disclose vulnerabilities:
- Credit in release notes and security advisories
- Listed in our Security Hall of Fame (with permission)
- CVE acknowledgment where applicable
To opt out of public credit: Indicate your preference when reporting.
- Verification: We confirm and reproduce the vulnerability
- Severity Assessment: CVSS scoring and impact analysis
- Patch Development: Create, review, and test fix
- Private Disclosure: Notify enterprise users before public release
- Public Release: Publish patched version with security advisory
- CVE Assignment: Request CVE identifier if applicable
- Post-Incident Review: Document lessons learned
NFTBan implements a capability-based privilege model following the principle of least privilege:
| Component | User | Capabilities | Purpose |
|---|---|---|---|
nftband (daemon) |
root |
CAP_NET_ADMIN, CAP_DAC_OVERRIDE |
nftables rule management, stats writing |
nftban-health |
nftban |
CAP_NET_ADMIN |
Health monitoring |
nftban-unified-exporter |
nftban |
CAP_NET_ADMIN |
Metrics collection |
nftban-ui |
nftban |
CAP_NET_ADMIN |
Web interface |
Key Points:
- Root required for nftables:
CAP_NET_ADMINcapability is essential for firewall rule management - Dedicated system user: Services run as
nftbanuser where possible - No privilege escalation:
NoNewPrivileges=trueenforced for all services - Ambient capabilities: Used instead of setuid/setgid for cleaner security boundaries
The nftband daemon uses Unix socket IPC for CLI communication:
| Property | Value |
|---|---|
| Socket Path | /run/nftban/nftband.sock |
| Permissions | 0660 (owner + group read/write) |
| Ownership | root:nftban |
| Authentication | SO_PEERCRED credential verification |
Security Properties:
- No network listeners: The daemon does not bind to any network interface
- Local-only access: Communication restricted to local Unix socket
- Group-based ACL: Only
nftbangroup members can communicate with daemon - Credential verification: Client UID/GID verified via socket peer credentials
NFTBan is designed for fail-secure operation:
| Scenario | Behavior |
|---|---|
| Daemon crash | nftables rules persist in kernel; firewall remains active |
| Daemon restart | systemd automatically restarts daemon (Restart=on-failure) |
| Config error | Daemon refuses to start; existing rules remain in place |
| Socket failure | CLI operations fail gracefully; firewall unaffected |
Key Guarantees:
- Rules persist: nftables rules are loaded into kernel memory and survive daemon restarts
- Atomic restarts: systemd manages service lifecycle with proper dependency ordering
- No rule gaps: Firewall protection never drops during daemon restart
All nftables rule changes are atomic via nftables transactions:
# Conceptual transaction flow
1. Build complete ruleset in memory
2. Validate ruleset syntax
3. Submit to nftables as single transaction
4. Kernel applies atomically (all-or-nothing)
Guarantees:
- No partial updates: Rules are never half-applied
- Automatic rollback: Failed transactions leave previous rules intact
- Consistent state: System always has a valid, complete ruleset
- Performance: Bulk operations are batched into single kernel transaction
All NFTBan services implement comprehensive systemd sandboxing:
# Applied to all services
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictNamespaces=true
LockPersonality=true
RestrictSUIDSGID=true
RestrictRealtime=true
SystemCallFilter=@system-service
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
ReadWritePaths=/var/lib/nftban /var/log/nftban /var/cache/nftban /run/nftbanStatus: Intentionally DISABLED for Go-based services
Affected Services: nftban-ui, nftban-ui-auth
Reason: Go runtime requires writable-executable memory for JIT compilation, which conflicts with MemoryDenyWriteExecute=true on Ubuntu 24.04+ (AppArmor + Landlock LSM interaction).
Risk Level: LOW
Mitigations:
- Go's memory-safe runtime prevents most memory corruption vulnerabilities
- Defense-in-depth via other systemd sandboxing directives
- ASLR, stack canaries, and compiler protections remain active
| Path | Ownership | Permissions | Purpose |
|---|---|---|---|
/etc/nftban |
root:root |
0755 |
Configuration (read-only by daemon) |
/var/lib/nftban |
root:nftban |
0750 |
State data (security boundary) |
/var/lib/nftban/* |
nftban:nftban |
Varies | Daemon-writable subdirectories |
/var/log/nftban |
nftban:nftban |
0750 |
Log files |
/run/nftban |
root:nftban |
0750 |
Runtime data, sockets |
NFTBan installations produce /var/lib/nftban/install-receipt.json:
- Defines expected system state (files, permissions, units)
- Used for drift detection and security validation
- Drift (unexpected files, wrong permissions) treated as security risk
Polkit rules provide least-privilege service management:
| Distro Family | Rules Path |
|---|---|
| Debian/Ubuntu | /usr/share/polkit-1/rules.d |
| RHEL/Rocky | /etc/polkit-1/rules.d |
Rules are:
- Least-privilege and profile-gated
- Installed via distro-specific paths resolved at install time
- Recorded in installation receipt
All input is validated before processing:
- IP addresses: Validated against RFC-compliant regex, normalized
- Usernames: Allowlist-based validation (alphanumeric + limited special chars)
- Configuration: Schema-validated at load time
- Shell commands: Parameterized; no string interpolation in commands
- JSON IPC: Strict schema validation; unknown fields rejected
| Field | Value |
|---|---|
| Advisory ID | NFTBan-SA-2024-001 |
| Severity | HIGH |
| Affected | v0.32.5 and earlier |
| Fixed in | v0.32.6 (2024-11-05) |
| Status | Patched in v1.0+ |
| CVE | Not assigned (internal advisory) |
Issue: Blacklist checks ran after port allow rules, allowing blacklisted IPs to bypass firewall.
Action Required:
- Upgrade to v1.61.x (recommended)
- Verify fix:
nftban firewall check
- Keep Updated - Run the latest stable version
- Monitor Logs - Review
/var/log/nftban/security events daily - Enable Health Checks - Automated system validation catches issues early
- Use Threat Feeds - Automated malicious IP blocking
- Harden SSH - Disable password authentication, use key-based only
- Backup Regularly - Use
nftban backupfor automated daily backups - Test Restores - Verify backup integrity quarterly
- Review Permissions - Run
nftban health --check permissionsperiodically
Changes to these areas require extra security review:
- systemd unit files, timers, sockets
- Polkit rules and helpers
- nftables rule generation logic
- Installer and maintainer scripts (deb/rpm)
- Receipt schema and validation logic
- Code paths modifying
/etc/nftbanor firewall state - Unix socket authentication and authorization
- NFTBan core system and daemon
- NFTBan CLI tools
- NFTBan Go binaries
- Official installation packages (RPM, DEB)
- Official documentation and scripts
- Unix socket IPC protocol
- Third-party dependencies (report to upstream maintainers)
- User misconfigurations
- Physical server security
- Social engineering attacks
- Theoretical vulnerabilities without proof of concept
- Issues in EOL versions (< 1.14)
We recognize security researchers who responsibly disclose vulnerabilities:
| Researcher | Vulnerability | Date |
|---|---|---|
| Your name here | Be the first to report a v1.15+ vulnerability | - |
| Channel | Address | Use For |
|---|---|---|
| Security Email | security@nftban.com | Vulnerability reports |
| GitHub Issues | github.com/nftban/nftban/issues | Non-security bugs only |
| Discussions | github.com/nftban/nftban/discussions | General questions |
NFTBan employs 16 GitHub Actions workflows with 12 dedicated security tools running on every commit and PR.
| Certification | Level | Verification |
|---|---|---|
| OpenSSF Scorecard | 7+ / 10 | View Score |
| OpenSSF Best Practices | Passing | View Badge |
| SLSA Provenance | Level 3 | Hermetic builds, non-forgeable provenance |
| SBOM | SPDX-JSON | Attached to every release |
| Tool | Workflow | Purpose |
|---|---|---|
| CodeQL | codeql.yml |
Semantic code analysis for Go |
| Semgrep | semgrep.yml |
Pattern-based security rules (Go + Shell) |
| gosec | secure-go.yml |
Go-specific security linting |
| ShellCheck | shellcheck.yml |
Shell script security analysis |
| Tool | Workflow | Purpose |
|---|---|---|
| govulncheck | secure-go.yml |
Go module vulnerability scanning |
| OSV-Scanner | osv-scanner.yml |
Google OSV database scanning |
| Trivy | secure-go.yml |
Container & dependency CVE scanning |
| Dependency Review | dependency-review.yml |
PR-level dependency diff analysis |
| Tool | Workflow | Purpose |
|---|---|---|
| gitleaks | gitleaks.yml |
Secret detection in commits |
| GitHub Secret Scanning | Native | Known secret pattern detection |
| Tool | Workflow | Purpose |
|---|---|---|
| SLSA Provenance | slsa-go-releaser.yml |
Cryptographic build attestation |
| OpenSSF Scorecard | scorecard.yml |
Security health assessment |
| Syft SBOM | release.yml |
Software Bill of Materials generation |
| Socket.dev | GitHub App | Typosquatting and malware detection |
| Tool | Workflow | Purpose |
|---|---|---|
| go-licenses | ossra-remediation.yml |
License compliance (blocks copyleft) |
| SPDX Validation | ossra-remediation.yml |
License header enforcement |
| Libyear | ossra-remediation.yml |
Dependency freshness metrics |
| Lychee | ossra-remediation.yml |
URL validation (anti-hallucination) |
| Tool | Workflow | Purpose |
|---|---|---|
| go-fuzz | fuzz.yml |
Automated fuzz testing |
| Go Test | ci.yml |
Unit and integration tests |
All security tools upload findings to GitHub Security tab in SARIF format for unified vulnerability tracking and remediation workflow.
| Severity | Detection → Fix SLA |
|---|---|
| Critical | 24-48 hours |
| High | 7 days |
| Medium | 30 days |
| Low | Next release |
- Security Architecture - Detailed security model
- Security Operations Guide - Hardening procedures
- Groups and Permissions - Access control details
- OpenSSF Scorecard - Live security score
Thank you for helping keep NFTBan secure.