Endpoint isolation: what happens when you click "contain"?

Endpoint isolation - sometimes called “containment” or “network quarantine” - is one of the most powerful and disruptive actions you can take during an active incident. Click “contain” on a live endpoint and you sever it from the network within seconds. But what actually happens under the hood, and what does that mean for your investigation?

What isolation does at the network layer

Most EDR agents implement isolation by installing a strict host-based firewall policy that drops all traffic except the agent’s own management channel. The exact mechanism depends on the OS:

• Linux: iptables or nftables rules prepended at the highest-priority chain
• Windows: the Windows Filtering Platform (WFP) callout driver is commonly used
• macOS: pf (packet filter) or a system extension handles the block

The critical invariant across all of them: the management channel - the encrypted connection from the agent back to the control plane - must stay open. Without it, you’ve effectively bricked the endpoint. You can no longer send commands, pull forensic artefacts, or lift the isolation when you’re done.

In LightEDR’s agent, isolation is delivered as a signed command over the existing mTLS WebSocket connection. The agent applies the rules locally and acknowledges back immediately. If the agent loses connectivity mid-apply, the control plane retries on reconnect - the rules are idempotent and applied locally, so the endpoint stays isolated even across a reboot.

The sequence of events when you click “contain”

Here is the rough order of operations:

1. Analyst clicks “Contain” on the endpoint detail page
2. The control plane queues an isolation command against the agent’s persistent connection
3. The agent receives and validates the signed command
4. The agent installs isolation rules - all traffic blocked except the allowlisted management IPs and ports
5. The agent acknowledges success; the dashboard updates endpoint status
6. Telemetry continues flowing back - process events, file events, and failed network connection attempts

Step 6 is worth noting: an isolated endpoint still generates telemetry. Every network connection the malware attempts will fail, but those failures still appear in your event stream. Watching C2 callback attempts pile up after containment is often useful confirmation that the threat was active.

A simplified version of what the isolation rules look like on Linux:

# Allow established management channel, drop everything else inbound
iptables -I INPUT 1 -s <management-ip> -j ACCEPT
iptables -I INPUT 2 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I INPUT 3 -j DROP

# Allow outbound to management plane only
iptables -I OUTPUT 1 -d <management-ip> -j ACCEPT
iptables -I OUTPUT 2 -j DROP

Production implementations are more nuanced - loopback must be preserved, DHCP renewals may need a carve-out, and your DNS policy (allow or block) needs an explicit decision before you need it under pressure.

What stays up and what goes dark

After containment, here is what the machine can and cannot reach:

Traffic type	Blocked?
Internet access	Yes
LAN access to other hosts	Yes
DNS (policy-dependent)	Typically yes
Agent → control plane	No - this stays open
SSH / RDP	Yes
Local loopback	No

The “yes” list stops the spread. The “no” list keeps your investigation alive.

One thing teams discover during their first real isolation: if there is a firewall between your endpoints and the management plane that your isolation rules didn’t account for, you’ve just created a self-induced outage. Test isolation in a staging environment before you need it in production.

When to isolate - and when not to

Isolation is not always the right first move.

Isolate immediately if you have confirmed active exploitation, you can see lateral movement attempts in the telemetry, or the endpoint is actively communicating with known command-and-control infrastructure.

Hold off if you’re still in the detection phase and want to observe attacker behaviour. Some sophisticated actors have “canary” checks - if C2 goes dark, they may wipe evidence or switch to a backup channel. An extra few minutes of observation can reveal more of the attack chain than immediate containment.

Be cautious about isolating critical infrastructure without a plan. Containing a domain controller mid-business-day has consequences that outlast the incident itself. Have a runbook ready before that scenario arrives.

In LightEDR, one-click containment is available from the endpoint detail page and the alert response panel. Every isolation event is logged with the analyst’s identity and timestamp in the hash-chained audit log - so when you’re writing the incident report, the full sequence is already captured automatically.

If you want to talk through containment policies or response runbooks for your environment, reach out via /company/#contact.