What it does
| Action | Mechanism |
|---|---|
| Kill the attributed process | SIGTERM first, so a process with a signal handler gets a chance to close its files cleanly. If it is still alive after a short grace period, SIGKILL follows. Either way the outcome is decided by looking for the process afterward, never by whether the signal call returned — a signal that was delivered to an unkillable process (a zombie, or one stuck in uninterruptible I/O) is reported as attempted, not taken. PID 1, the agent's own process, and the agent's parent are refused outright, whatever the detector concluded. |
| Isolate the host's network | A small, tagged set of iptables rules on the OUTPUT chain: loopback and DNS stay open, everything else is dropped. Every rule carries a comment tag unique to this module, so undoing isolation means deleting exactly those rules and nothing an operator added by hand. Isolation is only reported as taken once the chain is read back and the tagged rules are actually there — the commands returning success is not by itself evidence of anything. |
What triggers it
The only trigger is the host agent's own CRITICAL ransomware alert on that same host — never a finding from another scan family, and never a manual "contain this process" button for a process you simply dislike. CRITICAL is reached by combining several signals that each have an innocent explanation alone (content turning high-entropy, mass renaming, backup files disappearing, a note-like filename, a honeypot file being touched) into named, calibrated conjunctions — see Hosts & ransomware for exactly which signals and how they combine.
Attribution, and its limits
When an alert fires, the agent attributes it to whichever process currently holds files open in the affected directory — attributed to the burst of activity as a whole, since the specific file that triggered the alert is very often already closed by the time the alert is evaluated. This works well against a sustained encryption run, which keeps files open while it works through a directory.
- A process that already opened, wrote, and closed its files before attribution runs is no longer visible — attribution can name the wrong process, or none at all, during a fast-moving burst.
- A kill only ever targets the attributed process. If attribution is wrong, containment can stop a legitimate job instead of the real one — and the real one keeps running.
- No attribution, no kill: without a process to point at, only network isolation is available.
The two conditions to act
Both have to be true at the same time. Either alone does nothing.
- Your arm command. From this host's page, choosing which of the two actions — kill, isolate, or both — you are enabling, with a required acknowledgement that you read this page.
- The host operator's own literal. The agent's process must have
SENTINELLE_CONTAIN_ARMED=ARMED_CONTAINset in its environment, set by whoever administers the host, independently of the dashboard.
The dashboard shows both halves: your arm command as the host's containmentStatus, and, once the agent has reported back, whether it actually found the literal set. If the dashboard says armed but the host reports the literal missing, containment is not live on that host — the agent refuses to act until the operator sets it.
Enrol, install, set the literal, arm
- 1
Enrol the host
The same enrolment used for Site lockdown and ransomware detection — one agent, one host. - 2
Install the agent
Install and configure the host agent as described in Hosts & ransomware, including the directories to watch. - 3
Set the literal
On the host itself, setSENTINELLE_CONTAIN_ARMED=ARMED_CONTAINin the agent's environment. This step is yours alone — nothing in the dashboard can set it for you. - 4
Arm from the dashboard
Choose kill, isolate, or both, acknowledge that you read this page, and arm. The agent picks the armed state up and reports back whether its own literal matches. - 5
Watch the events
Every arm, disarm, and containment attempt is recorded as an event against the host, with its outcome — taken, attempted, or refused.
After an action
A CRITICAL alert captures the available forensic evidence before any containment action is even considered, whether or not containment is armed on that host — see Incidents, forensics & remediation. Network isolation carries an undo record and, by default, a time limit: if nothing renews it, the rules come out on their own, because an isolated host cannot be reached to be un-isolated by hand. Every step — arm request, arm confirmed, disarm, the containment attempt itself and its outcome — is recorded with receipts in the same append-only ledger every other protective action on this platform uses; see the evidence ledger.
A kill or an isolation that is actually taken (not merely attempted) also triggers the customer report flow: a short notice goes out right away, and the full signed report follows after a hold window, with the consent you signed for Host containment attached to it. See Reports sent to you for the notice, the hold, and how an operator can add a note or skip a delivery.
Consent at subscription
Subscribing to Host containment requires signing a consent the first time, the same as Auto-pause and Site lockdown: a typed phrase confirming you read the instructions on this page, recorded against your identity before checkout will proceed. See Plans & billing for what is recorded and where.
Pricing structure
Host containment is billed per host per month, sold as a standalone add-on separate from the Host & ransomware plan and from the general bundle — it can kill a process or cut a host off the network on your behalf, so enrolling it is always an explicit, deliberate choice, independent of whatever else that host already carries. See pricing for current figures.
What it stops short of
- No credential or session-token revocation happens as part of containment — it acts on a process and on network traffic, not on identity.
- Linux only, the same as the rest of the host agent's telemetry — the containment mechanisms are written against Linux-specific process signalling and iptables.
- There is no guarantee the right process was killed — attribution can be wrong or absent, and a kill only ever targets whatever it attributed the alert to.
- Network isolation is a firewall rule, not a hardware kill switch — anyone with root on the host can remove it directly, the same way root can delete a Site lockdown flag file.