Isolating a machine: what it costs and how you get it back

Isolating a machine means cutting it off the network — no email, no file shares, no internet, no remote support — while leaving it switched on so that evidence survives. It is the most disruptive thing Qorionix can do to your business, and it is the action people ask about first.

This article is for the person who decides, not the person who types. You do not need to know how a firewall works to read it. You do need to know four things before an isolation happens on your estate: who is allowed to start one, exactly what stops working, what isolation does not protect you from, and how you get the machine back.

Who is allowed to start an isolation

Every action that reaches a machine travels as a ticket — a signed instruction naming one command, one machine and how far the action reaches, together with its approval state. Isolation is one of seven commands the ticket system understands.

Four things can create an isolation ticket: Sentinel-Q's automatic response, Sentinel-Q's second-tier automatic response, the playbook engine, and a person running a configured Isolate host action from Response → Response actions. That last path is the one a person controls directly — see Response actions for exactly what running it asks of you: a target host, a required reason, and typing the hostname to confirm before anything is sent. None of that skips the approval step below; it only means a person, rather than only the platform, can be the one who asks for an isolation.

The intention behind the restriction is defensible: an isolation is a decision about which of your machines your business can afford to lose, and the platform holds a proposal until a person answers it. What is not defensible is that the same reasoning left no path for a person who has already made that decision. Treat the current state as a gap we have written down rather than as a considered final answer.

What isolation actually does

The sensor rewrites the machine's own firewall so that it blocks everything in and out, then punches exactly two holes: the machine talking to itself, and the machine talking to Qorionix. Nothing else gets through in either direction.

The second hole is not a convenience — it is a hard requirement, and the sensor refuses to isolate without being told the address range for it:

The reason is stated plainly in our own source: a sensor cut off from the control plane cannot receive the instruction to un-isolate, and turns into an expensive paperweight. So the range is supplied by whoever approves the action rather than by the detection rule that proposed it — a detection rule cannot know how your network is laid out, and a rule that guessed would eventually guess wrong on somebody's estate.

What stops working, in the terms your colleague will use

Everything that needs the network. That is a longer list than most people picture, so here it is concretely.

• Email stops — Outlook cannot reach the server, so nothing arrives and nothing sends. Anything unsent sits in the outbox.
• File shares disappear. Mapped drives go dead. Documents saved to a share are unreachable, and anything currently open from one may not save.
• Cloud sync stops. OneDrive, SharePoint, Dropbox and anything similar stop syncing, so work done during the isolation exists only on that machine until it is reconnected.
• The internet is gone. No browsing, no web applications, no video calls.
• Remote support stops. This is the one that catches people out — your IT provider's remote-access tool cannot reach the machine either, unless it happens to sit inside the control-plane range, which it almost certainly does not.
• Network printing stops. A printer on the network is on the network.
• Anything licensed online may complain, since licence checks are network calls.

What keeps working is everything local. The machine stays on. The person can log in, open local files, and keep using anything that does not need to reach out. That is deliberate: shutting a machine down destroys the evidence held in memory and can make a ransomware situation worse rather than better.

What isolation does not stop

Isolation is a network control. It is not a cure, and reading it as one is the most expensive mistake available here.

• It does not stop anything already running on the machine. Ransomware encrypting local files keeps encrypting local files. What isolation stops is the spread to your file shares and other computers, and the attacker's ability to keep operating the machine remotely. That is a large win and it is not the same as stopping the attack.
• It does not remove the attacker's foothold. Whatever made the machine start it at boot is still there and will start it again the next time.
• It does not undo what already happened. Data already stolen is already gone. Files already encrypted on a share are already encrypted.
• It does not cover any other machine. Isolation applies to exactly one host. If the same attack reached three computers, isolating one contains one.

The right way to think about it is buying time and preserving evidence. It stops the situation getting worse across your business while somebody works out what to do about the machine itself.

The snapshot taken before anything changes

Before the firewall is touched, the sensor exports the machine's existing firewall configuration to a file on the machine. Only then does it apply the isolation rules. That ordering is the whole reason the machine can be restored to precisely what it had before rather than to somebody's best guess.

Three further behaviours are worth knowing, because each of them is the difference between a recoverable situation and a stuck one:

• If applying the isolation goes wrong halfway, the sensor restores from the snapshot and reports a failure, rather than leaving the machine in a half-configured state.
• The snapshot is deleted only after a successful restore. A failed restore leaves behind the one file an administrator needs to fix the machine by hand.
• Un-isolating a machine that was never isolated by us is refused, not attempted. Refused and failed mean different things to whoever reads the ticket, and retrying cannot conjure a snapshot that was never taken.

no pre-isolation firewall snapshot at /var/lib/zentryq/iptables.pre-isolate.v4;
  this host was not isolated by this sensor
no pre-isolation firewall export at C:\ProgramData\ZentryQ\firewall.pre-isolate.wfw;
  this host was not isolated by this sensor

Why it asks you rather than doing it

Isolation sits at recommend by default. That means the platform prepares the action in full — this machine, this range, the undo recorded — and then waits for a person. It does not execute on its own, and no behavioural detection can be configured to make it do so. Attempting to grant that is refused by the server.

The reasoning, in the product's own words, is a single sentence worth reading twice: an isolated domain controller is an outage, not a containment. Cutting off the machine that authenticates everybody in your business stops your business, and no detection is confident enough to make that trade on its own initiative. Getting it right requires knowing which of your machines matter — which is a question about your business that software cannot answer by inspection.

So the platform declines to assume. If nobody has told Qorionix which machines would stop the business if they stopped working, isolation stays a recommendation regardless of how confident the detection is. Answering that question is one of the higher-value ten minutes available to you, and What Sentinel-Q is allowed to do lists the other conditions that would have to hold.

The detections that propose isolation rather than something smaller are the ransomware ones: mass file rewriting with rising randomness, a bulk appearance of a known ransomware file extension, and the destruction of shadow copies or the backup catalogue. All of them are ransomware in progress. All of them are proposals, and all of them wait for you.

Approving one, when one appears

An isolation you have not approved is doing nothing at all. It sits on the Tickets screen showing Awaiting approval, and it has fifteen minutes before it expires and does nothing for ever.

1. 1

   Open Tickets and read the row

   The row names the command, the machine, and how far the action reaches. Approve and Reject are the only two controls offered on a ticket awaiting approval, and both require a reason. That reason is what somebody reads six months later, so a short honest one beats a blank field.

2. 2

   Approve it, then read the status that comes back

   Approval does not mean the machine has been contained. The status moves to Approved, then to Dispatched once the instruction has been handed over, and only to Completed when the machine has reported what it actually did. A ticket sitting at Approved on a sleeping laptop has changed nothing on that laptop.

3. 3

   Telephone whoever is using the machine

   Do this before you expect the network to drop, not after they ring you.

How to get the machine back

This section used to carry a warning that the console could not reverse an isolation at all. That defect is fixed. Both allow-lists that stood between the button and the machine — the one on the server deciding which commands may be created, and the one on the sensor deciding which may be run — now carry unisolate and restore_file, and the per-platform implementations that always worked are reachable from the console.

What is built. On Endpoints, every machine row offers Restore network access. It is confirm-gated, it asks for a reason, and it creates and approves an un-isolate ticket in one step — the person pressing the button is the human in the loop, so what is skipped is the waiting, not the recording. The ticket, the approval naming you, and the signature are written exactly as they would be for any other action.

Restore queued as ticket 4f2c… (approved).

Note the word queued. The same rule applies as above: the ticket has been created and approved, and the machine has not yet answered. Watch it reach Completed on the Tickets screen before you consider the machine back.

When the button will not help. The instruction still has to reach the machine, and the machine is by definition on a very short leash. If the sensor is not checking in — because it was stopped, because the machine is switched off, or because the control-plane range supplied at approval time was wrong — the ticket will sit at Dispatched and nothing will happen. In that case somebody has to be at the machine.

1. 1

   Restore the firewall from the snapshot

   On Linux: iptables-restore < /var/lib/zentryq/iptables.pre-isolate.v4. On Windows: netsh advfirewall import "C:\ProgramData\ZentryQ\firewall.pre-isolate.wfw". On macOS, reload the machine's normal ruleset with pfctl against /etc/pf.conf. The first two are the exact strings the platform records on the ticket as the way to reverse the action, so they are not our reconstruction of what ought to work — they are what the sensor wrote down at the time.

2. 2

   Or run the ticket locally through the sensor

   The sensor can execute a signed ticket from a file — zentryq-sensor live-response --ticket <file> — which reaches the same per-platform code the console does. Ask us for the ticket file. This is the tidier of the two, because the reversal is then recorded as a completed action rather than as something an administrator did by hand.

3. 3

   Record what you did either way

   If you restored the firewall manually, say so on the incident. A machine whose network came back with no corresponding completed ticket looks, from the console, like a machine that is still isolated — and six weeks later nobody will remember which it was.

Deciding, in practice

A short version you can use under pressure.

1. Is this machine spreading? Mass encryption, destroyed shadow copies, or movement to other hosts are the cases where isolation earns its cost. A single suspicious process that has not gone anywhere usually is not.
2. What does this machine do for the business? A domain controller, a file server or the machine that runs your invoicing is an outage. Reject, and contain another way.
3. Who is sitting at it, and can somebody reach it? If the answer is nobody and it is in your office, isolation is cheap. If it is a director's laptop in another country, plan the reversal before you approve.
4. Is there something smaller that would do? Killing one process or quarantining one file has a blast radius of one process or one file, and quarantine is undoable. Response actions lists them.
5. Then approve, telephone the person, wait for Completed, and write down what you did.

What to do next

1. Answer the asset-criticality question for your organisation, so the platform knows which machines it must never touch on its own.
2. Read Response actions for the smaller options and the full undo picture.
3. Read Live response and approval for what an approval records and who is allowed to give it.
4. Read Autonomy tiers: observe, recommend, act if you are considering letting anything run unattended — and note that isolation is not among the things that can.