Inbound default-accept is the other Unix inheritance

• 1: A listener will accept a stranger by default
• 2: Observe real traffic, approve a list, seal it
• 3: Where the packet boundary holds — and where it does not
• 4: Walkthrough: observe, approve, seal

1 - A listener will accept a stranger by default

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Two different defaults

Root Lock by HeartSuite starts from one Unix inheritance: a program that can run may open files and make outbound connections as the user who launched it.

Root Lock Firewall starts from the other: a process that is listening will accept a connection from anywhere the routing table can reach, unless a packet filter refuses the packet first.

Those are not the same control. Approving 93.184.216.34 for /usr/bin/curl does not close port 22. Closing port 22 does not stop curl from calling an address you never reviewed.

What inbound default-accept enables

1. Unsolicited reachability

Any service that binds a port is reachable from every address that can route to the host. Installing the service rarely meant “the entire internet.”

Scanners, credential stuffing, and exploit kits treat that reachability as the starting condition.

2. Login and management planes on the filter itself

Campus and branch firewalls accumulated a second job: they became the remote-access concentrator and the administrative website. The packet filter then has to defend its own web VPN, SSO broker, and management GUI.

Incidents in 2024–2026 on Cisco Secure Firewall and FortiOS followed that surface — not a missing “next-gen” blade. See Recent firewall campaigns.

3. Rules nobody can still explain

Stateful policy that is never observed, reviewed, and reduced becomes an any-any rule with exceptions stacked on top. The filter is “on.” The allowlist is not known.

Extra tools then appear to find which rules still matter.

Why another NGFW blade does not close this

Application catalogs, TLS interception, URL clouds, and sandbox subscriptions answer a different question: what is inside a flow you already decided to accept. They do not answer “which inbound sockets on this box did a human approve, and is that set sealed.”

They add policy surface. They also add a management and update plane that has to stay reachable.

Root Lock Firewall addresses the first question and refuses the second as product identity. Inspection stays stateful. Delivery is a closed image. You reach the Dashboard on the console or serial console, not through a public administrative VPN.

What Root Lock already covers — and what it leaves open

Root Lock already blocks outbound connections to destinations that are not on a program’s allowlist, including from processes running as root. That is kernel grant policy. It is not inbound port policy.

Root Lock Lockdown can record a thin inbound permit for SSH scope and named services. That path is accept-only. It is not observation of real traffic, not a reviewed allowlist of this box, and not Root Lock Firewall.

Root Lock Firewall is the product that takes inbound (and this host’s path) as its job.

That is a smaller remote plane, not a claim that an approved port is safe, that a wide seal is minimal, or that the hypervisor console is out of scope. See What Root Lock Firewall does and does not cover.

2 - Observe real traffic, approve a list, seal it

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: A listening service on a general-purpose host accepts inbound packets unless a filter refuses them. That is the Unix default this product closes.

Root Lock Firewall is the host-shaped stateful packet filter on a closed HeartSuite appliance. Root Lock by HeartSuite is the hardened OS under it, not the filter. You receive an image, not a package.

The Dashboard shows traffic as it happens. You approve a finite allowlist for this box’s inbound and outbound path. Firewall Lockdown seals that set.

Packets are judged by connection state on Linux netfilter’s nft path. Execution, file access, and per-program outbound destinations remain Root Lock’s domain.

What you receive

You receive a virtual appliance (QCOW2 or OVA). Hardware follows later, after real deployments, and does not change the inspection class.

The image is closed:

• A custom Root Lock kernel is already the operating system.
• The packet filter is already installed and constrained by that kernel.
• You reach the box on the console or serial console. There is no public administrative SSH by default, and no Docker runtime.
• HeartSuite is the update authority. The sealed image does not fetch rules or reputation from a public CDN.

You do not install Root Lock Firewall onto an existing Ubuntu or Debian kernel. Install scripts that appear in development trees are for laboratory layer installs on a test guest, not the customer model.

What the filter decides

Root Lock Firewall is a host-shaped stateful firewall.

• Host-shaped. It filters traffic to and from this box. The workload runs on the image. You do not place the appliance in front of another server in v1.
• Stateful. Allow and deny follow connection state, not a stateless access list alone.
• Literal addresses. Critical rules use IP addresses, not hostnames. DNS is not the enforcement mechanism.

The product does not inspect application payloads, terminate TLS in order to classify applications, or subscribe to a URL or sandbox cloud. That refusal is the design, not a missing license.

Observation, approval, and Firewall Lockdown

The human act is the same one Root Lock already uses for programs and destinations:

observe what is real → approve what is necessary → seal what was earned.

Silence on the strip means Firewall Lockdown and Root Lock Lockdown are both in place. It does not mean an NGFW somewhere else is healthy.

Firewall Lockdown and Root Lock Lockdown are paired on the appliance and are not the same act. Firewall Lockdown seals the packet allowlist. Root Lock Lockdown seals the kernel allowlist (programs, files, outbound destinations).

Changing either after seal requires the maintenance path.

What stays on Root Lock

See Network and Remote Access for Root Lock’s outbound queue, and What Root Lock Firewall does and does not cover for residuals.

Status

Root Lock Firewall is a prototype. Capabilities, configuration, and deployment details are subject to change. Root Lock remains the shipped kernel product.

3 - Where the packet boundary holds — and where it does not

Prototype: Content on this page reflects current design intent and will be updated as the product matures.

Overview: Root Lock Firewall enforces one thing: inbound and this-host path traffic that is not on the sealed allowlist is refused — including traffic aimed at services running as root.

An attacker who uses a port you approved is constrained by that rule, not stopped at the application.

An attacker uses a service you already approved

The scenario. You approved inbound HTTPS to the workload on this image. An attacker exploits a bug in that web application over the allowed port.

What Root Lock Firewall enforces. Packets to ports that are not on the allowlist still fail. Scanners probing closed ports still fail. A listener on a port that is not already in the sealed allowlist is not an approved path.

What Root Lock Firewall does not cover. Content on an allowed port is outside a stateful packet filter. A listener that binds a port the image already left open (including baseline ports open to any source) is still that approved path.

A WAF, application hardening, and Root Lock by HeartSuite (what that process may execute, read, write, and call outbound) address the blast radius inside the approved service. This is a deliberate division of layers, not a gap.

Outbound destinations per program

The scenario. A compromised approved program opens an outbound connection to an address you never reviewed.

What Root Lock Firewall enforces. The host path is still subject to the sealed host filter. That is not the same as per-program outbound policy.

What Root Lock Firewall does not cover. Which program may reach which literal IP is Root Lock’s domain. See Network and Remote Access.

Traffic through this box to another server

The scenario. You want to place the appliance in front of a backup server or a subnet and publish NAT or forwarded ports.

What Root Lock Firewall enforces. v1 filters INPUT and OUTPUT of this image. The workload is meant to run on the image.

What Root Lock Firewall does not cover. Sitting in front of other hosts (FORWARD, NAT as a product surface) is not v1. An edge SKU would change placement. Until then, do not treat this box as a campus or DC inline firewall. See Deployment scenarios.

Application identification, TLS interception, and URL clouds

The scenario. A buyer expects App-ID, TLS man-in-the-middle, URL categories, sandbox detonation, or SD-WAN on the same appliance.

What Root Lock Firewall enforces. Connection state and the allowlist you sealed.

What Root Lock Firewall does not cover. Those blades are refused as product identity. They are the policy surface Root Lock Firewall is designed not to become. If you need them, keep the specialist tool and do not expect this image to replace it.

Physical access and the console

The scenario. Someone who can reach the serial console or the hypervisor console boots Maintenance and removes the seal.

What Root Lock Firewall enforces. Under Firewall Lockdown, an attacker who already has remote root cannot rewrite the sealed allowlist. Change goes through Maintenance on the console.

What Root Lock Firewall does not cover. Physical presence, a cloud serial console, or control of the hypervisor under a virtual appliance returns the box to whoever holds that path. Restrict console access in the hypervisor or cloud IAM.

A later hardware appliance removes the hypervisor residual; it does not remove physical presence. See Architecture and compatibility.

An allowlist that is too wide

The scenario. Observation ran on a noisy network, a broad rule was approved to “make it work,” or the image already opened ports to any source, and then that set was sealed.

What Root Lock Firewall enforces. The sealed set, including the wide rule and any baseline ports that were never a discovery product. Critical rules use IP addresses, not hostnames. DNS is not the enforcement mechanism.

What Root Lock Firewall does not cover. Seal makes a chosen ruleset immutable. It does not prove the ruleset is minimal.

Inventory advisories can flag breadth. They cannot unsay an approval. Re-enter Maintenance, reduce, and seal again.

Complementary tools

For how this sits next to campus NGFWs and cloud security groups, see How Root Lock Firewall compares.

4 - Walkthrough: observe, approve, seal

Prototype: Keys, strip text, and ceremony steps shown here are the intended appliance path and may change. The screenshots are docs mock-ups of that path, not a capture of the shipping Root Lock TUI ([f] is still File Access there).

This walkthrough is the intended console path on a Root Lock Firewall appliance image. There is no package to install on a foreign kernel. You boot the image, open the serial or local console, and the Dashboard is the interface.

1. First boot is observation

The merged system strip reports traffic observation: logging only, rules not fully enforced. That is the honest state: the box is teaching you what is listening and what is arriving.

The Suggested Next Step points at pending firewall events, not at a catalog of blades.

2. Open Firewall Rules

From the Dashboard, open Firewall Rules with [f].

Each pending event is something that already happened on this box during observation: a listener, an inbound attempt, a repeated source.

Firewall Rules groups related events when they share a service or origin so you are not paging through identical lines. View samples with [v] before approving a group.

[a] Approve creates an allowlist entry for that traffic. [s] Skip leaves it for later. [s] is Skip, not Seal. There is no blind “allow all pending.”

An approval is a decision you make. The Dashboard does not confirm a suggestion it already chose.

3. Empty the queue before you seal

An empty queue is required. It is not enough. The Suggested Next Step offers Seal Firewall with [l] only when the precondition checklist also passes.

Most appliances need several days of representative traffic before that offer is earned. A development host that never saw production clients will under-teach the allowlist.

The image already leaves a small set of ports open to any source (workload ports, and the SSH port even when no administrative SSH listener is running). Observation does not produce those. Seal keeps them. Narrow them through Maintenance after you know the workload.

[l] opens Firewall Lockdown. Advance with [y] to see the review: rule counts, samples, and what the box already has for logging. Logging and SIEM destinations are not configured on this path.

4. Type YES, then reboot the host

The confirmation word is YES — uppercase, case-sensitive.

After you confirm, reboot from the console or hypervisor so Firewall Lockdown is applied with Root Lock Lockdown. The Dashboard does not reboot the host. [r] shows reboot instructions after the seal is accepted.

After reboot the strip is quiet when both seals are in place. Mutate keys are absent from Firewall Rules and from inventory. Absence is the signal that the set is sealed.

5. Inventory is read-only

After reboot, [l] opens the same Firewall Lockdown surface as inventory. It shows the allowlist that is in effect, and whether Root Lock Lockdown is present.

Advisories can flag a rule that is broader than the traffic that earned it. They are not editable here.

6. Change only through Maintenance

To change a sealed rule, open Maintenance with [m]. Enter reduced posture with [e], then type YES.

Edit or re-observe on Firewall Rules, then seal again with [l], YES, and a host reboot. Unsealing does not reboot. SSH from a laptop is not the recovery path. Console or serial is.

What this demonstrates

• Observation is a state, not a hidden log.
• Approval is per event, with consequence, matching the Root Lock review grammar. See Root Lock Firewall overview.
• Firewall Lockdown is earned and reversible only through Maintenance. See What Root Lock Firewall does and does not cover.