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
• 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.

Overview: A process that is listening will accept a connection from anywhere the routing table can reach, unless a packet filter refuses the packet first.

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.

HeartSuite Firewall starts from the other: a listening process accepts connections from any routable address unless a packet filter refuses them first.

Those are independent controls. 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,” yet scanners, credential stuffing, and exploit kits treat that reachability as their 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. 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, so the filter is “on” but nobody knows what it allows.

Extra tools then appear to find which rules still matter.

What another NGFW blade answers

Application catalogs, TLS interception, URL clouds, and sandbox subscriptions answer one question: what is inside a flow you already decided to accept. Each of those blades adds policy surface, plus a management and update plane that has to stay reachable.

HeartSuite Firewall answers a different question: which inbound sockets on this box a human approved, and whether that set is sealed. It leaves payload inspection to those specialist tools, keeps inspection stateful, and ships as a closed image that you administer from the Dashboard on the console or serial console.

What Root Lock already covers

Under Lockdown, Root Lock blocks outbound connections to destinations that are not on a program’s allowlist, including from processes running as root. The kernel enforces that per program; inbound port policy is HeartSuite Firewall’s job.

At Lockdown, Root Lock itself records only minimal inbound rules: SSH scope and accept-only permits for named services. Observing real traffic, reviewing an allowlist for this box, and sealing it with Firewall Lockdown are what HeartSuite Firewall adds.

The result is a smaller remotely reachable surface. A port you approved still accepts the traffic its rule allows, a seal that is too wide stays that wide until you narrow it through Maintenance, and the hypervisor console stays inside the trust boundary. See Protection limits.

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.

HeartSuite Firewall is a host-shaped stateful packet filter delivered as a closed HeartSuite appliance image, with Root Lock by HeartSuite as the hardened OS under it. The Dashboard shows traffic as it happens, you approve a finite allowlist for this box’s inbound and outbound path, and Firewall Lockdown seals that set.

The filter judges packets by connection state on Linux netfilter’s nft path. Execution, file access, and per-program outbound destinations remain with Root Lock, the kernel under the filter.

What you receive

You receive a virtual appliance (QCOW2 or OVA). Hardware follows later, after real deployments, and keeps the same 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, so once the allowlist is sealed the filter fetches no rules or reputation data from a public CDN.

The closed image is the only delivery. Install scripts that appear in development trees layer the prototype onto a test guest for laboratory use only.

What the filter decides

HeartSuite Firewall is a host-shaped stateful firewall.

• Host-shaped. It filters traffic to and from this box. The workload runs on the image.
• Stateful. Allow and deny follow connection state, not a stateless access list alone.
• Literal addresses. Critical rules use IP addresses rather than hostnames, so a DNS answer never decides what the filter allows.

Inspection is limited to connection state against the sealed allowlist. Application payload inspection, TLS termination for classification, and URL or sandbox clouds are outside the product by design; Protection limits names the tools that cover them.

Observation, approval, and Firewall Lockdown

You use the same observe → approve → seal path Root Lock already uses for programs and destinations:

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

Firewall Lockdown and Root Lock Lockdown are paired on the appliance: Firewall Lockdown seals the packet allowlist, and Root Lock Lockdown seals the kernel allowlist (programs, files, outbound destinations). After the seal, changing either one goes through Maintenance.

What stays on Root Lock

See Network and Remote Access for Root Lock’s outbound queue, and Protection limits for what the packet boundary leaves to other tools.

3 - Where the packet boundary holds

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

Overview: A listening service accepts packets from anywhere the routing table can reach, unless a filter refuses them. Under Firewall Lockdown, HeartSuite Firewall refuses traffic to and from this box that is not on the sealed allowlist — including traffic aimed at services running as root.

An attacker who uses a port you approved is limited to what that rule allows, and what they send over that port is for a WAF and Root Lock to constrain.

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 HeartSuite Firewall does. Packets to ports that are not on the sealed allowlist still fail, so scanners probing closed ports get nothing, and a listener the attacker starts on a port outside the allowlist gets no inbound path.

What it does not cover. The filter does not judge application content on a port you approved. A listener that binds one of the ports the image already leaves open to any source is reachable too, because that port is already an 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.

Outbound destinations per program

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

What HeartSuite Firewall does. The connection still has to pass the sealed host filter, which applies to traffic leaving this box independently of per-program outbound policy.

What it does not cover. The host filter has no per-program destination rules. Which program may reach which literal IP stays with Root Lock.

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 HeartSuite Firewall does. v1 filters INPUT and OUTPUT of this image, because the workload is meant to run on the image.

What it does not cover. v1 has no FORWARD or NAT path, so keep the existing edge firewall in front of other hosts. 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 HeartSuite Firewall does. It filters on connection state against the allowlist you sealed.

What it does not cover. App-ID, TLS interception, and URL clouds are outside the product, so keep the specialist tool for that inspection.

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 HeartSuite Firewall does. Under Firewall Lockdown, an attacker who already has remote root cannot rewrite the sealed allowlist. Change goes through Maintenance on the console.

What it does not cover. Whoever holds the serial console, a cloud serial console, or the hypervisor can boot Maintenance and change the allowlist, so restrict console access in the hypervisor or cloud IAM.

A later hardware appliance takes the hypervisor out of that path, while physical presence at the box remains a console path. 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 HeartSuite Firewall does. It enforces exactly the sealed set, including the wide rule and any baseline ports that observation never produced.

What it does not cover. Sealing does not narrow an approval: a broad rule stays in force until you unseal. Inventory advisories can flag breadth, so re-enter Maintenance, reduce the rule, and seal again.

Complementary tools

For how this sits next to campus NGFWs and cloud security groups, see How HeartSuite 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).

HeartSuite Firewall ships as the closed image. You boot it, open the serial or local console, and the Dashboard is the interface.

1. First boot is observation

The System Info Strip reports traffic observation: logging only, rules not fully enforced. In this state the Dashboard shows you what is listening and what is arriving before the allowlist is enforced.

The Suggested Next Step points at pending firewall events.

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, and [s] Skip leaves it for later ([s] is Skip, not Seal). Each approval is a decision you make rather than a confirmation of a choice the Dashboard already made, which is why there is no blind “allow all pending.”

3. Empty the queue before you seal

The Suggested Next Step offers Seal Firewall with [l] only when the queue is empty and the precondition checklist also passes.

Most appliances need several days of representative traffic before that offer appears. An allowlist taught on a development host that never saw production clients will be missing the traffic those clients send.

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). Those ports never appear as review events, and sealing keeps them open, so narrow them through Maintenance once you know what the workload needs.

[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 itself; once the seal is accepted, [r] shows the reboot instructions.

After reboot the strip is quiet when both seals are in place, and the keys that change rules are gone from Firewall Rules and from inventory. Their absence is how you know 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; to narrow that rule, go through Maintenance.

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 the host. Recovery runs on the console or serial console, not over SSH from a laptop.

See HeartSuite Firewall overview for the observe → approve → seal grammar, and Protection limits for the console recovery path.