Lock the box

The personal computer is the highest-value target on a sustained-targeting subject's perimeter. Email, documents, financial access, location history, contacts, photographs, draft writing, and the keys to every other system the subject uses are concentrated on a single device that is, by default, online twenty-four hours a day. Reducing the attack surface that device presents is one of the highest-leverage operational moves available.

This entry is the lockdown configuration I converged on after measurable improvement in targeting pressure correlated with each move. The empirical signal — fewer acute incidents after these specific changes — is one data point, not proof. But the threat model the configuration defends against is well-understood enough that the moves are worth making whether the signal generalizes or not.

Off when you're not using it.

The first move is the cheapest and the most effective: do not leave computing devices online unattended. Laptop closed and powered off (not sleeping) when you are not at it. Desktop powered off when you walk away from it for more than a brief interval. Phone in airplane mode overnight and during periods you are not actively using it. The default consumer posture of always-on, always-connected, always-available is convenient and is exactly the posture a remote attacker needs to do their work.

A powered-off device has no listening sockets, no running agents, no responsive RPC endpoints, no exploitable kernel surface, no exposed memory, no live filesystem to copy from. Most of the attack literature against endpoint devices assumes the device is on. Off undoes most of it for the duration. The same applies to network connectivity: a device that is on but unplugged from network is much harder to reach.

The discipline is operational. Build the habit. Standing up to put a laptop in a drawer for a few hours produces more security than every dollar spent on endpoint software.

Zero inbound, surgical outbound on the local firewall.

The local firewall on the device — not the router; the device's own firewall — should be configured as follows:

• No inbound connections from anywhere. Every port, every protocol, every interface. There is no good reason for a personal computer to accept inbound traffic. File sharing, remote desktop, screen sharing, printer sharing, network discovery, AirDrop, AirPlay, mDNS responder — all of it off. If you need to push a file to another machine, push it from the source side; do not require the destination to listen.
• Outbound allowed only for specifically-needed applications. A browser, an email client, a code editor with cloud sync if needed — each on the list explicitly. The default for unfamiliar processes is deny. macOS Little Snitch, Windows Defender Firewall with outbound rules, Linux nftables with output filtering all support this configuration. Apps that misbehave (call out to dozens of unfamiliar hosts on startup) become visible to you when they try; you can decide whether the behavior is acceptable.
• No exceptions for the local subnet. Many default firewall configurations treat the local network as trusted and apply restrictive rules only to the WAN side. This is the wrong threat model for sustained-targeting subjects. The local subnet is hostile by default.

The reason the LAN is hostile-by-default is that it usually contains other devices you do not control — smart TVs, IoT cameras, voice assistants, family members' phones, guest devices, neighbors' equipment within WiFi range, the router itself. Any of these can be compromised through vectors the personal computer has no defense against, and once compromised they sit on the same subnet as the personal computer. The firewall posture must assume that every other device on the LAN may be hostile, and the only device you communicate with locally is the upstream gateway (the router) — and that, only to reach the internet.

No cloud-managed security agents.

This is the move that produced the most measurable change in my own targeting-pressure observations. It is also the most counterintuitive, because the consumer narrative around "advanced security" treats cloud-managed endpoint protection — CrowdStrike, SentinelOne, Carbon Black, Microsoft Defender for Endpoint, the enterprise-tier consumer equivalents, the various "advanced threat protection" suites — as strictly defensive. They are not strictly defensive. They are dual-use.

The structural problem: every cloud-managed security agent installs a kernel-level process on the endpoint that

• runs with full system privileges,
• maintains persistent outbound connections to the vendor's cloud infrastructure,
• receives policy and configuration updates from the vendor,
• accepts remote instructions from the vendor's cloud,
• can be remotely instructed to scan, collect, exfiltrate, or modify any data on the endpoint,
• often includes a remote-shell or remote-response capability for "incident response,"
• is typically excluded from user-controllable removal by the same elevated privileges that make it powerful.

The agent is, by design, a vendor-controlled remote-administration channel into your computer with kernel-level access. As a defense against criminal commodity malware, that is acceptable and useful. As a component of a threat model that includes the vendor itself being compelled to push configuration that benefits a state actor, it is a complete defensive failure.

The compulsion vector. Under FISA Section 702, National Security Letters, Section 215 orders, and the broader stack of legal instruments the U.S. government can use against U.S. corporations, a vendor can be compelled to take specific actions against specific customers. The vendor is typically gagged from notifying the customer. The customer has no notice, no representation in the proceeding, no opportunity to object, and no path to verify the integrity of their endpoint after the order is executed. The vendor pushing a configuration to your machine — which is the agent's normal operating mode — is the vector. No exploit is required. The compulsion is the exploit. The same legal framework that misuse-of-FISA discussions cover at the data-collection layer applies at the endpoint-management layer with much less public attention.

The defensive move is to not install agents of this class. Operating-system-native protections (Defender on Windows, XProtect/Gatekeeper on macOS, AppArmor/SELinux on Linux) are not as feature-rich, but they are also not a remote-management channel into your machine controlled by a vendor that can be compelled. The trade is real and worth making.

If you must use endpoint protection for compliance or workplace reasons, segregate that machine from anything personal — it is, for the duration of the agent's installation, not yours.

What you give up.

This configuration breaks a number of things you have come to expect from modern computing.

• AirDrop, AirPlay, screen sharing, printer sharing, file sharing over the LAN. Use cables. Use external drives. Push files to a cloud destination from the source side rather than pulling them across the LAN. Print over USB or to a printer with a wired ethernet connection routed through the firewall like any other application.
• Smart-home automation. The smart home talks to a cloud, which talks to your phone, which talks to the devices on your LAN. All three legs of that triangle are blocked by this configuration. Replace smart devices with dumb equivalents wherever feasible, per no-wireless.
• Remote access to your own machine. You cannot SSH home from a coffee shop. If you need this, use a hardened bastion (separate machine, separate threat model, restricted access).
• Software auto-update telemetry. Many vendors phone home for update checks, license validation, and analytics. Most of these can be disabled with persistence; the rest can be allowed through the outbound rules selectively if you decide the convenience is worth it.

The cost is real. The defender's job is to be honest about the trade rather than pretend it does not exist.

The empirical signal I noted.

After locking the firewall to zero inbound and removing the cloud-managed security agent from my primary working machine, the frequency of certain categories of incident — apparent fresh-information leakage, contextually-improbable suggestions appearing in adjacent channels, the "they seem to know what I just wrote" pattern — dropped noticeably. The correlation is suggestive, not conclusive, and other variables changed in the same period. But the threat-model argument stands independent of the empirical signal: a vendor-controlled kernel agent with compelled-cooperation legal exposure is, structurally, an ingress vector, and removing it removes that vector.

Compounding with other techniques.

This entry stacks with:

• No wireless — the radio-side ingress vector. Lock the wired side with this technique; eliminate the wireless side with that one.
• Data poisoning — the surveillance-channel side. Lock the box's network; contaminate the channels that bypass the box entirely.
• Salt and sand — the physical-access side. Lock the box's network; detect attempts to install agents during your absence. The principle each shares is deny the adversary the easier path. The easier path to a target's data, almost always, is the one the target has left open in the name of convenience.