Appearance
Containment and Isolation
Containment isolates a sensor during an active incident by restricting its network connections, blocking specific binaries, or stopping heartbeat delivery entirely.
Prerequisites
operatorrole for containment, release, kill process, and block binary actionsadminrole for disable, revoke, and delete actions- Target sensor currently enrolled and visible in Sensors
Controls overview
| Control | What it does | Required role | Reversible |
|---|---|---|---|
| Kill process | Send SIGKILL to a specific PID on the sensor host at the next heartbeat | operator | Not applicable (process already killed) |
| Block binary | Create an enforcement rule that kills any future execution of a specific binary | operator | Yes: delete the rule |
| Network containment | Deploy a network-containment enforcement rule on the sensor | operator | Yes: release the sensor |
| Disable sensor | Mark the sensor as disabled in the fleet | admin | Yes: re-enable |
| Revoke sensor | Permanently revoke the sensor's mTLS identity | admin | No |
| Delete sensor | Permanently delete the sensor record | admin | No |
Kill process
Queues a SIGKILL for a specific PID. The kill is delivered to the sensor in the pending_kill_pids[] array of the next heartbeat response. The sensor calls kill(pid, SIGKILL) immediately on receiving the response.
Constraint: PID must be > 1. PID 1 cannot be killed via this mechanism.
Limitation: The Console stores the kill queue in memory. In multi-Console deployments without a shared backing store, only the Console instance that received the request delivers the kill.
In the Console, go to Sensors > [sensor] > Actions > Kill Process and enter the PID to queue a kill. The action confirms the PID is queued and will execute within 30 seconds on the next heartbeat. The sensor sends no confirmation that the kill succeeded; check sensor logs if you need to verify.
Block binary
Creates a custom enforcement rule targeting a specific absolute binary path on a specific sensor. The rule uses sys_execve with action: Sigkill matching the exact binary path. Future executions of that binary are killed before the process can run.
The policy name follows the pattern telovix-block-binary-{sanitized-path-suffix}.
In the Console, go to Sensors > [sensor] > Actions > Block Binary and enter the absolute binary path. The rule is enabled immediately and takes effect within 30 seconds. The resulting rule appears in Policies > Enforcement with a rule_id that you can use to identify and delete the rule later to remove the block.
To remove the block, go to Policies > Enforcement, find the block-binary rule for this sensor, and delete it.
Network containment
Network containment deploys a network-containment enforcement rule on the sensor. The rule restricts outbound network connections at the eBPF level. The exact restriction is defined by the network-containment enforcement template in the Console.
Containment takes effect within 30 seconds (next heartbeat). The is_contained: true flag appears on the sensor in Sensors. The heartbeat response also includes contained: true, which is informational. The actual enforcement comes from the network-containment enforcement rule delivered in enforcement_policies[].
Contain a sensor
In the Console, go to Sensors > [sensor] > Actions > Contain.
If the sensor is already contained, the action returns a notice that the sensor is already in containment.
Release from containment
Releasing removes the network-containment enforcement rule and clears the is_contained flag. Takes effect within 30 seconds.
In the Console, go to Sensors > [sensor] > Actions > Release.
Both the contain and release actions are recorded in the Console audit log with action types sensor_contained and sensor_released.
Disable sensor
Disabling marks the sensor as disabled without revoking its identity. The sensor continues to run and send heartbeats, but it appears as disabled in Sensors and is excluded from fleet health summaries.
Requires admin role.
In the Console, go to Sensors > [sensor] > Actions > Disable.
To re-enable, go to Sensors > [sensor] > Actions > Enable.
Audit action type: sensor_disabled.
Revoke sensor
Revocation permanently invalidates the sensor's mTLS client certificate. All future heartbeat requests from that sensor are rejected with 401. The sensor process continues running on the host but cannot communicate with the Console until re-enrolled with a new certificate.
Revocation is not automatically reversible. To restore the sensor, generate a re-enrollment token and run the re-enrollment script on the sensor host.
Requires admin role.
In the Console, go to Sensors > [sensor] > Actions > Revoke. Confirm the permanent action in the dialog.
After revocation, the sensor's trust health shows revoked and the sensor health state shows critical. Audit action type: sensor_revoked.
Delete sensor
Permanently deletes the sensor record from the Console database. This removes all fleet entries, trust records, and associated data for that sensor. The sensor process continues running on the host until stopped or replaced.
Requires admin role.
In the Console, go to Sensors > [sensor] > Actions > Delete. Confirm the permanent action in the dialog.
Audit action type: sensor_deleted.
Choose the right control
| Situation | Recommended control |
|---|---|
| Single suspicious process needs to stop immediately | Kill process |
| A specific binary must not run again on this host | Block binary |
| Sensor host may be compromised and should stop making outbound connections | Network containment |
| Sensor is decommissioned or replaced temporarily | Disable sensor |
| Sensor host is confirmed compromised; certificate should be invalidated | Revoke sensor |
| Sensor record should be removed (host retired, cleanup) | Delete sensor |
WARNING
Revocation and deletion are not reversible. Use disable or containment first if there is any chance the sensor will need to resume normal operation. Revocation requires re-enrollment to restore the sensor.
Limitations
- Kill process is not confirmed: The Console queues the SIGKILL and delivers it at the next heartbeat, but receives no confirmation that the kill succeeded. The target process may have already exited. Check sensor logs if you need to verify.
- Kill queue is not persisted: The Console stores the kill queue in memory. If the Console restarts before the next heartbeat, queued kills are lost. In multi-Console deployments without a shared backing store, only the Console instance that received the request delivers the kill.
- Network containment does not block all traffic: The
network-containmenttemplate blocks outbound TCP connections at the eBPF level via a kprobe ontcp_connect. It does not block UDP, ICMP, or connections already established before containment was applied. Existing open TCP connections remain active until they close naturally. - Containment does not prevent local activity: A contained sensor continues collecting events, running policy packs, and sending heartbeats. It only restricts the outbound network connections that monitored processes can initiate. Local process execution, file access, and system calls are unaffected.
- Revocation requires re-enrollment to reverse: Revoking a sensor permanently invalidates its mTLS client certificate. Restoration requires generating a re-enrollment token and running the re-enrollment script on the host.
- Delete is permanent: Deleting a sensor removes all fleet entries, trust records, and associated data. Deletion does not stop the sensor process on the host; stop it separately.
Understand enforcement state and rules
Containment and binary blocking work through the enforcement rule system. Network containment creates an enforcement rule with template network-containment; block-binary creates a custom enforcement rule with a sys_execve kprobe and Sigkill action. These rules are included in the sensor's enforcement_policies[] array on the next heartbeat and applied by the sensor's policy engine.
If a sensor's trust is revoked or it is in critical health state, enforcement transitions are blocked. Resolve trust and health issues before attempting to advance enforcement on that sensor.