Host Network Isolation — Containing a Compromised Linux Server in Seconds

When an attacker gains a foothold on a Linux server, they immediately attempt to move laterally, exfiltrate data, or establish persistence. Every minute they remain connected to the network is a minute of damage. The standard incident response playbook says: isolate the host. The reality is that doing so traditionally requires SSH access, firewall rule changes, or a call to a cloud provider's console — all of which take time and carry risk.

SecureExec now lets you isolate a compromised host with a single click.

What host network isolation does

When you isolate an endpoint through SecureExec, all inbound and outbound network traffic on that host is blocked at the kernel level — except for connections you explicitly allow. By default, only the agent's connection to the SecureExec backend is preserved, so monitoring, alerting, and command delivery continue uninterrupted. You stay in control even while the host is cut off from the rest of the network.

Everything else is dropped: outbound C2 connections, lateral movement attempts, data exfiltration, inbound attacker callbacks — all cut off instantly.

How it works under the hood

Isolation is implemented as a Linux kernel module (secureexec_kmod) that registers Netfilter hooks at the highest priority (NF_IP_PRI_FIRST) for both LOCAL_IN and LOCAL_OUT traffic. When the firewall mode is set to ISOLATED, the module enforces a whitelist: only packets matching the configured allow-rules are passed; everything else is dropped at the kernel level before any userspace process sees the traffic.

The kernel module uses RCU (Read-Copy-Update) for the packet filtering hot path — each packet check is lock-free, adding negligible latency to normal operation. Rule changes from the agent are applied via a clone-and-swap approach, ensuring the running hook always sees a consistent rule set.

Communication between the SecureExec agent and the kernel module happens over a character device (/dev/secureexec_kmod), and the kernel enforces that only the agent binary at the configured path can open the device. This prevents any other process from manipulating the firewall rules even if running as root.

The agent itself receives the isolate or release command from the SecureExec server via a lightweight polling channel, applies it to the kernel module, and reports back the current isolation status in every heartbeat — so if a host somehow drifts out of sync, the server detects it and reissues the command automatically.

When to use it

From an alert. When a detection fires — a reverse shell, a process injection, a credential dump — you will see an "Isolate Host" button directly on the alert detail page. One confirmation click, and the host is contained before the attacker can react.

From the devices page. The Endpoints page shows all your registered hosts with their current isolation status. You can isolate or release any host at any time, with an "Isolated" badge showing current state. This is useful for planned maintenance windows or when you want to contain a host proactively during a wider incident.

Automated response. Because isolation is driven by a command API, it can be triggered from your SOAR or incident management tooling via the SecureExec REST API — no UI required.

Customising isolation rules

Not every environment is the same. During an investigation you often still need certain services on the isolated host to remain reachable — your team needs SSH to log in and collect forensic artefacts, your configuration management system needs to push a patch, or a SIEM collector needs to keep pulling logs. Cutting all of that off creates operational friction that slows down the response.

SecureExec solves this with global isolation rules — a persistent whitelist you configure once and that is automatically applied to every endpoint the moment it enters isolation mode.

You manage rules on the Isolation Rules page in the sidebar (requires the agents:manage permission). Each rule specifies:

• IP address — a specific source or destination IPv4 address, or leave empty to match any IP.
• Port — a specific port number, or leave empty to match any port.
• Direction — Inbound, Outbound, or Any.

Some common examples of what you might add:

Rule	IP	Port	Direction	Use case
Allow SSH	(any)	22	Inbound	Your team can still log in via SSH to investigate and collect forensics
Allow Salt master	10.0.1.5	4505–4506	Outbound	SaltStack or Ansible keeps managing the host; you can push remediation commands
Allow SIEM collector	10.0.2.20	514	Outbound	Syslog or Beats continues shipping logs to your SIEM during the incident
Allow jump box	10.0.0.10	(any)	Inbound	Only your designated jump box can reach the host, not the broader network
Allow monitoring	10.0.3.1	9100	Inbound	Prometheus or Zabbix agent keeps reporting metrics so you can observe the host's behaviour

Rules are global — they apply equally to all endpoints in your organisation that enter isolation. The agent-to-server connection is always preserved regardless of the rule list, so the agent can never be accidentally locked out.

Live updates during isolation

If you change isolation rules while an agent is already isolated, the update reaches the agent automatically. The agent periodically polls the server for the current rule set and reprograms the kernel module on the fly — no re-isolation required, no manual intervention. The host continues to be isolated and the new rules take effect within seconds.

Releasing a host

Once investigation is complete and the threat is remediated, releasing the host is equally straightforward: click "Release" on the devices page, or issue a release command through the API. The kernel module immediately returns to normal mode, all traffic is restored, and the "Isolated" badge disappears.

Why kernel-level containment matters

Firewall rules set via iptables or nftables from userspace can be overwritten by any process with sufficient privileges — including the attacker if they have root. A kernel module that enforces isolation at NF_IP_PRI_FIRST runs before any userspace packet processing and before any userspace-managed firewall. Even a root process cannot bypass it without unloading the module, and the module protects its own control channel by verifying the opener's executable path.

This is not a soft control. It is a hard network boundary enforced by the kernel.

What is preserved during isolation

Traffic	Status in isolation
Agent → SecureExec backend	Always allowed
Loopback (127.0.0.0/8)	Always allowed
Rules configured in Isolation Rules page	Allowed
All other inbound traffic	Blocked
All other outbound traffic	Blocked

Try it now

Host network isolation is included in all SecureExec plans. Install the agent on your Linux servers, configure your isolation rules once, and get one-click containment the next time a threat fires — without losing access to the tools your team needs to investigate.

Get started with SecureExec