Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Network Security & Firewalling

InterGenOS treats the network as the most exposed surface a machine has. The posture is default-deny: nothing listens on a public interface, nothing reaches out on its own, and no data leaves the machine unless you make it leave.

This page describes how that posture is enforced today and what it means for you as an operator of a machine you understand, can modify, and can trust.

The Default Posture: Deny

Two principles govern every networked component InterGenOS ships:

  • Nothing listens publicly. Any server package shipped by InterGenOS binds exclusively to localhost (127.0.0.1) by default. A database, a web server, or any other daemon you install is reachable only from the machine itself. It will not listen on a routable interface unless you deliberately edit its configuration to allow it.
  • Nothing phones home. InterGenOS collects zero analytics, crash reports, or usage statistics. There is no auto-update that contacts a server behind your back, and there is no opt-out toggle to hunt for in a settings menu. No usage or analytics data is produced, so none leaves to begin with.

A freshly installed system has no attack surface facing the network that you did not explicitly create. Opening a port is a decision you make, not a default you have to discover and undo.

Inbound: Why Nothing Is Reachable

The localhost-bind default is the primary control for inbound traffic. Because services do not listen on public interfaces, an unconfigured InterGenOS machine presents nothing for a remote scanner to connect to. This is enforced at the package level rather than left to a separately configured packet filter, so the protection holds even before any host firewall rules are evaluated.

When you choose to expose a service, the act of changing its bind address is the explicit step that takes you off the default-deny path. At that point the service’s own configuration, and the host firewall, govern who can reach it.

InterGenOS uses nftables (nft) as its host firewall, enabled by default with a default-deny posture. There is no firewalld or ufw; nftables is the single packet-filtering layer, and it mirrors the system’s overall stance of refusing inbound traffic you have not explicitly allowed.

Outbound: No Silent Egress

InterGenOS does not generate background network traffic on your behalf:

  • No telemetry or analytics. Nothing in the base system reports usage, crashes, or metrics to any server.
  • No auto-updates. Your system will not fetch or install software in the background. Updates happen only when you explicitly run them.
  • No opt-out privacy. You do not flip toggles to stop the OS from sending usage data to the cloud, because it collects and sends none. (Network use that you initiate — package syncs, the one-time model download, services you start — is covered just below.)

When you observe outbound connections from an InterGenOS machine, they correspond to actions you took: syncing packages, running a browser, or starting a service yourself.

The local AI assistant follows the same rule. InterGen runs offline-first and local by default with zero telemetry; it does not transmit your prompts or data off the machine. The optional security scanner, InterGen Sentinel, defaults to local rules and a local model. Its cloud providers and the Phone-A-Friend (Frontier/Cloud Escalation) path are strictly opt-in, so no off-machine call to a frontier provider happens unless you turn it on.

Service Confinement Limits the Blast Radius

Even a service that does talk to the network runs inside tight confinement, so a compromise of one daemon does not become a compromise of the system:

  • AppArmor in enforce mode. System daemons ship with AppArmor profiles in enforce mode by default, not complain mode and not disabled.
  • Systemd sandboxing. System services are sandboxed with extensive isolation directives. Among the network-relevant ones, RestrictAddressFamilies limits services to AF_UNIX, AF_INET, and AF_INET6, denying access to lower-level or exotic socket families a service has no reason to use. These run alongside broader hardening such as NoNewPrivileges, ProtectSystem=strict, PrivateTmp, RestrictNamespaces, and a @system-service system-call filter.

A network-facing service is confined to the narrow set of capabilities it actually needs. If it is breached, the sandbox limits where the attacker can go next.

The Package Mirror Is Signed End-to-End

The one network operation every InterGenOS machine performs routinely is talking to the package mirror, so that channel is verified cryptographically rather than trusted by transport alone.

Every time you sync with pkm, your machine verifies the package index signature against a release-signing subkey held on a hardware token and certified by the offline InterGenOS master key. When a package is downloaded, its SHA-256 hash is validated locally before installation. InterGenOS uses an index-only signature trust model for the 1.0 release, giving you a centralized, verifiable source of truth instead of relying on the network path being honest.

Credentials Are Never Default

No service shipped by InterGenOS comes with a blank or default admin password. Initial credentials are randomly generated or require manual setup during installation. A service that does become reachable on your network cannot be entered with a guessed factory password.

What This Means For You

  • A new install exposes nothing to the network you did not ask it to expose.
  • Making a service reachable is an explicit, auditable change to that service’s configuration.
  • Even reachable services run confined, so a single breach stays contained.
  • Local assistance stays local; any cloud escalation is opt-in.
  • The package mirror, the one routine outbound dependency, is cryptographically verified rather than implicitly trusted.

Further Reading