Home

SysWarden Wiki

Status: Current Documentation baseline: v4.03.3

SysWarden is a Linux host firewall orchestrator and out-of-band security-log analysis toolkit. It combines authoritative nftables policy with bounded firewalld or UFW compatibility, local threat-intelligence lists, WAAP log analysis, host telemetry, authenticated HA exchange and a native local terminal dashboard.

v4.03.3 is the current stable public release. The version-specific v4.04.0 Minor source candidate is documented only where it is explicitly labelled. This wiki does not authorize a version-specific v4.04.0 tag or public Release.

The historical public v4.03.2 release closed LOT 2, including the LOT 2A Linux-only surface reduction, LOT 2B three-package reproducibility and LOT 2S bounded security remediation. v4.03.3 carried that qualified boundary forward and addressed defects observed after publication. The version-specific v4.04.0 candidate extends the source through separately qualified Minor lots.

Documentation map

• Deployment tutorial covers the supported package matrix, exact release inventory, verified installation, optional image staging, configuration, upgrade safety and command inventory.
• Historical v4.02.8 to v4.03.2 migration provides the Debian 13 first-hop runbook, rollback and interrupted-package recovery boundary.
• Version-specific runbook: v4.03.2 to v4.03.3 migration covers the four dynamic nftables sets, legacy interval handling, pending Ubuntu 26.04 installation gate and the restricted rollback boundary.
• RHEL 9+ image extensions distinguishes the available offline staging extension from the planned runtime-only package integration profile.
• BunkerWeb integration defines the authenticated HA dialect, ownership model and cluster migration fence.
• Bounded use cases provides laboratory procedures with explicit prerequisites, limits, verification and rollback.
• Source repository is the authoritative implementation.
• Public Releases are the only supported source for release packages.

Supported release boundary

The v4.03.3 contract targets three candidate Linux packages:

Package family	Architectures	Package count
DEB	amd64	1
RPM	x86_64	1
APK	x86_64	1

The complete public Release contains exactly ten assets: the three packages, two checksum inventories, one release archive, one SPDX SBOM, one qualification evidence archive, one signed update manifest and its detached Ed25519 signature. No package, updater or qualification route exists outside this AMD64/x86_64 Linux matrix.

Product boundary

• The candidate validates and commits one authoritative nftables ruleset. If exactly one supported firewalld or UFW frontend is already active, it may reconcile only bounded SysWarden-owned trusted-source and HA-port rules.
• Native nftables host and CIDR mutations use complete interval-set start and exclusive end markers. Unterminated starts are repaired before replacement; ambiguous states and intervals containing internal boundaries fail closed. An exclusive end marker left alone after timed-start expiry is treated as functionally absent, and a later re-ban must install and verify a complete pair. Release evidence still requires the isolated real-kernel nftables gate.
• core.firewall_backend = "keep" is the default and changes no firewall service state. It refuses policy mutation while an iptables-services or netfilter-persistent service is active or enabled. nftables validates an operator-prepared active and enabled nftables service without performing a transition and refuses any active or enabled firewalld, UFW, iptables-services or netfilter-persistent frontend.
• Operational policy mutation requires an active, unambiguous supported service manager. Package hooks running with no service-manager runtime defer install and reload instead of invoking host firewall or kernel tools.
• iptables remains parseable for configuration compatibility but is not an operational policy mode in v4.03.3. Operational firewall policy mutation paths reject this choice before changing persistent policy inputs or kernel firewall state. Automatic service migration is outside the qualified candidate contract.
• WireGuard requires the explicit nftables backend. The bounded firewalld and UFW compatibility path does not open the WireGuard UDP port or forwarding rules. Active firewalld and UFW target-host execution remains outside the qualified evidence.
• The optional RHEL-compatible image staging extension is additive and is not called by normal package, update or reload workflows. It installs one local, checksum-bound RPM into a fresh unmounted image root without package scripts or triggers, then defers runtime convergence to a marker-guarded first boot. Offline staging is not runtime-readiness evidence.
• A separate runtime-only Go and package-owned host-integration extension is a planned design boundary only. It has no shipped source or operator procedure in v4.03.3.
• WAAP analyzes configured logs after the application writes them. SysWarden is not an inline HTTP proxy and does not sanitize request traffic.
• The supported multi-origin OSINT path discards syntactically valid private, 6to4 and other non-public or special-use entries before consensus and logs only a bounded origin-and-count warning. Malformed entries, insufficient post-filter sources and custom feed validation failures remain fatal.
• In the version-specific v4.04.0 candidate, Geo deny and strict-allow selections come from one deterministic IPverse country-ip-blocks CC0-1.0 RIR allocation snapshot embedded in the CLI. Only the official signed SysWarden release chain authenticates the reviewed snapshot bytes. Runtime operation performs no country-data download and requires no per-country files. Allocation country is not physical or current operational geolocation. See the version-specific GeoIP boundary for exact provenance, valid empty families and strict-allow behavior.
• syswarden tui runs inside the invoking local console or SSH terminal. It opens no listening socket.
• The current product contains no browser terminal, HTTPS or WebSocket terminal bridge, remote PTY route, token-management command or network terminal service. SysWarden owns no listener or generated firewall permission on TCP 62027.
• The HA API uses TLS 1.3, a bearer token and configurable TCP port 62026 by default. All partner and node-to-node operations remain authenticated.
• The optional BunkerWeb extension is disabled by default. It must never edit SysWarden files or invoke the local CLI remotely.

HA migration boundary

Historical static ownership and provenance-aware temporary ownership are separate stores. The authenticated integrator selects a dialect with one fresh GET /ha/status per peer and serialized cycle. Enriched requests are allowed only when both sync_ttl and sync_provenance are present.

Migration is a cluster campaign. The operator supplies one complete member and external-writer inventory, then distributes one verified activation manifest to every node and to the integrator. The capability native_sync_fence_v1 announces schema support only. Live proof comes from the dynamic, challenge-bound native_sync_fence object.

The integrator compares the manifest epoch, membership_sha256 and legacy_writer_inventory_sha256 with live values as opaque, case-sensitive strings. It does not recalculate either digest. Historical cleanup uses the exact observed X-SysWarden-HA-Fence-Condition; HTTP 428, 400 and 412 reject without mutation. A one-hour all-peer absence window is evidence only, never proof of drain.

The historical v4.03.2 freeze required written partner confirmation against this frozen contract and no unexplained partner-attributable static residue.

Release status

Publication of the version-specific v4.04.0 candidate remains blocked until source, security, native AMD64 package lifecycles, isolated nftables qualification, documentation truth, signed-update verification, partner migration acceptance and the exact ten-asset inventory all pass on one immutable commit.

No statement in this wiki is a regulatory certification, performance guarantee or support claim for an unlisted distribution or incomplete HA topology.

Wiki publication model

Wiki changes are reviewed against the same source revision as the release. A page is not evidence by itself. After publication, local links, external HTTPS links and current-surface terminology must be revalidated against the exact published content.