/opsec/

Went through the whole setup last week to write up what is actually running. Netns kill switch, AppArmor profiles on the two things that touch the network, split DNS, backups that I have restored from twice to check they work. All of it correct. I would defend every piece of it.

Then I looked at what I produced in the six months it took to get there and it is basically this site.

That is the part worth posting about, because it is a real failure and it is not a tooling failure. Tooling cannot tell you it is pointed at nothing. Every check stays green. The backup verifies, the profile denies what it should deny, nothing leaks, and none of it is capable of asking what any of it is in service of. You can run a flawless setup in the wrong direction for years and it will report success the entire time.

So, the other half of it, which I have been worse at.

Health is the substrate, not a category. Sleep, food, moving. Boring and load bearing. Four hours of sleep is not a discipline problem you can schedule around, it is a hardware availability problem. And if a routine only works on your good days, it is not a routine, it is a mood.

Clarity decays. It is not one insight you get once and keep. Leave it a month and your attention drifts to whatever is loudest, which is nearly always somebody else's priority. The check I use: write down what you want to be true in five years, then look at what last week actually contained. Usually it is the week that is lying.

An intention with no slot on a calendar is a wish. Name it in one sentence concrete enough that you can tell when it is done. Guess the hours and multiply by three, because the guess is wrong in a predictable direction. Then put it on a specific day and defend it like a meeting you would be embarrassed to cancel.

Review it weekly or you are guessing. Twenty minutes. What moved, what ate time and returned nothing, what changes next week. Skip it and the loop cannot learn, so you repeat the same losing week for a year while feeling busy throughout.

The uncomfortable one is last. The things quietly taking the time are never dramatic. They are small, they feel like rest, and they restore nothing. You do not have to cut them. You do have to count them, because you cannot price a habit you have never measured.

Six months of hardening was not wasted. It was just the easy half, and I did it first because it is legible and it has a finish line.

>perfect tooling, no threat model >perfect setup, no reason

Ranked on one axis and one axis only: how hard is it for a site, and for whoever is watching the wire, to work out that two visits are the same person. Not speed, not vertical tabs, not how it looks.

The thing the tiers are actually measuring: there are only two working strategies against fingerprinting, and they are incompatible. Be identical to everyone (Tor, Mullvad) or be different every time (Brave). Anything that is neither is just a normal browser with a nicer settings page.

>and none of it survives you logging in

Your tier is capped by your behaviour. S tier browser, signed into the same account you use everywhere, is a D tier session. The browser handles the part where you are a stranger. It cannot help with the part where you introduce yourself.

Three tiers here and people conflate them constantly.

Tier one, the firewall rule. The one from the wg-quick man page:

>PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

Read what that actually says. Reject anything leaving an interface that is not the tunnel, unless it carries WireGuard's own fwmark, which is how the encrypted packets get out, or it is going somewhere local. It works. It is also a rule in a table that something else can flush, reorder or outrank, and it protects the whole host rather than one process.

Tier two, policy routing. wg-quick already does this for AllowedIPs of 0.0.0.0/0. It does not add a default route to the main table, it uses ip rule add not fwmark 51820 table 51820 plus a suppress_prefixlength 0 rule on main, which is what lets your LAN routes keep working while every default-routed packet goes down the tunnel. If you have ever wondered why your wg config has no visible default route, that is why. Look at ip rule, not ip route.

Tier three, and the one worth building. Put the tunnel in its own network namespace. Create the netns, move the wg interface into it, and run the process in there. Now the process has no route to the physical NIC at all. There is nothing to leak through, because the alternative path does not exist in that namespace, and no amount of the app reconfiguring itself changes that.

The trick people miss: create the wg interface in the init namespace and then move it. The encrypted socket stays bound in the namespace where it was created, so the tunnel still talks to the outside world through your real NIC, while everything inside the netns only sees the tunnel. That is the whole design.

>a rule says packets should not go there >a namespace says there is no there

Every few weeks someone posts a leak test screenshot and blames the VPN. It is almost never the VPN.

systemd-resolved keeps a resolver list per link, not one global one. Bringing up a tunnel sets DNS on the wg link. Your ethernet link still has the DHCP resolver on it, and resolved will happily use it for anything not covered by a routing domain on the tunnel. Run resolvectl status and read it per link, not as a blob. Two links with servers means two places queries can go.

The fix is one setting: put ~. on the tunnel link as a routing domain. That is the catch-all route, and it makes the tunnel resolver the default for every name that nothing more specific claims. Without it you have split DNS and you configured it by accident.

Things that also bypass the system resolver, in the order people trip over them:

>the browser. DoH is on by default in some builds and goes straight out over 443 to its own resolver >anything statically linked or in Go, which often skips nsswitch entirely and reads resolv.conf itself >containers, which get their own resolv.conf handed to them at start and never see yours >mdns and llmnr answering for short names before unicast DNS is ever consulted

And the part the leak-test sites cannot show you: a query going down the tunnel to the VPN's resolver is not private from the VPN. You moved the observer. That is the whole trade, and it is fine, as long as you know that is what you bought.

Worth writing up because my own box is currently on the wrong side of it. Every container in my media stack publishes on 0.0.0.0 rather than loopback, which means the host firewall is not the thing deciding who reaches them. /selfhost/ >>0740

The shape of the trap: default deny incoming, one allow for ssh, ufw status exactly as expected, and a container admin panel answering on 8080 to anyone who asks.

It is not a ufw bug, it is a chain traversal fact. ufw's rules live in the filter table's INPUT path. A published container port is DNAT'd in nat/PREROUTING and then, because the destination is now a container address rather than the host, the packet is forwarded, not delivered locally. It goes through FORWARD, where Docker jumps to DOCKER-USER before anything else. Your INPUT rules are never consulted, because the packet was never destined for the host once PREROUTING was done with it.

>ufw status is a description of a chain the packet does not enter

Three fixes, in the order I trust them:

Bind to loopback. -p 127.0.0.1:8080:80 and reach it through a reverse proxy or over the tunnel. Fails closed, needs no extra tooling, survives Docker upgrades rewriting its rules.

Put your rules in DOCKER-USER yourself, which is the chain Docker guarantees it will not clobber and jumps to first. That is what ufw-docker automates. Correct, but you are now maintaining rules in two places.

Or set iptables: false in the daemon config and do all the forwarding and NAT yourself. Total control, and you own every networking bug you create from then on. Rarely worth it.

If you run a service and have not run systemd-analyze security against it, do that before you write a single AppArmor profile. It scores every unit on exposure, roughly 0 to 10, and the default for a hand-written unit is somewhere around 9.5 with the word UNSAFE next to it.

The reason this is worth more than it looks: these are kernel-enforced, they compose with MAC rather than competing with it, and they are eight lines in a drop-in file. A reasonable starting set for anything that touches a network:

>NoNewPrivileges=yes >ProtectSystem=strict >ProtectHome=yes >PrivateTmp=yes >PrivateDevices=yes >ProtectKernelTunables=yes >ProtectKernelModules=yes >ProtectControlGroups=yes >RestrictNamespaces=yes >RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX >SystemCallFilter=@system-service >SystemCallArchitectures=native >CapabilityBoundingSet= >MemoryDenyWriteExecute=yes >LockPersonality=yes

Notes from doing this a lot. ProtectSystem=strict makes the entire filesystem read-only except /dev, /proc and /sys, so you pair it with ReadWritePaths= for the two directories the thing genuinely writes to, and that list being short is the audit. Empty CapabilityBoundingSet= means no capabilities at all, which is right far more often than people expect, and if it breaks, the failure names the capability. SystemCallArchitectures=native matters more than it sounds: without it a 64-bit process can make 32-bit compat syscalls, and your filter was written against the 64-bit numbers.

MemoryDenyWriteExecute is the one that will break things, because every JIT needs W^X violations. Anything with a JavaScript engine, a JVM, or LuaJIT in it will not start. That is not a bug in the option.

Skipping the marketing. The four things that make it technically different from the rest of the market, whether or not you end up buying it:

Account numbers. No email, no username, no password. Which means no reset flow, no recovery, and no identifier that correlates to anything else you own. Lose the number and the account is gone, so it goes on paper. This is the only real anonymity property in the product and it is the one people ignore while arguing about jurisdictions.

Post-quantum key exchange. The WireGuard tunnels can negotiate the session key with an ML-KEM and Classic McEliece exchange on top of the normal handshake. The threat is harvest-now-decrypt-later, so the thing it protects is traffic captured today against a machine that does not exist yet. Costs a slower handshake and nothing after that.

DAITA. Defence Against AI-guided Traffic Analysis. WireGuard leaks packet sizes and timing, and those patterns are enough to fingerprint which site you loaded even though the payload is opaque. DAITA pads packets to constant sizes and injects cover traffic to blur the shape. It costs you throughput and it is the only feature in any consumer VPN aimed at traffic analysis rather than at the IP address.

Diskless infrastructure. The servers run from RAM with no persistent storage, provisioned at boot. The argument is that a seized machine has nothing on it, which is a stronger claim than a no-logs policy because it is structural rather than a promise.

Things it does not do: port forwarding, removed years ago over abuse. And it does not make you anonymous to any service you log into over it, which is most of them.

Exec transitions. This is the part that decides whether a profile means anything, and it is one letter wide.

When a confined process execs something, the mode on that rule says what happens to confinement:

>ix inherit, child keeps running under this same profile >px transition to the child's own profile, fail the exec if it has none >cx transition to a child profile defined inside this one >ux execute unconfined

That last one means the child runs with no profile at all. A profile that carefully restricts a daemon to three directories and then grants /bin/sh ux restricts nothing, because the first thing worth exploiting is a shell and it comes out the other side unconfined. If you see ux in a profile, that is where the audit ends.

The uppercase forms, Px and Ux, scrub the environment across the transition. Use them. Lowercase leaves LD_PRELOAD and friends intact, which is a way to carry influence into the new domain.

Other things worth knowing before you trust a profile:

It is path-based. Rules attach to paths, so a bind mount or a hard link exposing the same inode under a path the profile does not name is, to AppArmor, a different object. SELinux labels the inode, which is why it is stricter and why it makes people give up.

Network mediation is coarse. You are granting things at the level of network inet stream, an address family and socket type. Fine-grained port rules are not the historical model, so do not assume the profile is doing your firewall's job.

And complain mode is not a weaker enforcement, it is no enforcement with logging. A profile left in complain because it was noisy is decoration. Check aa-status for what is actually in enforce, because that number is usually smaller than people think.

X11 has no isolation between clients. That is not a bug, it is the protocol working as designed in 1987, when the threat model was other people on the same VAX being colleagues.

Any client connected to your X server can register for input on the root window and see every keystroke you type into any other window. Any client can screenshot any other window. Any client can inject synthetic input through XTEST, which is how your automation tools work and equally how anything else would. There is no permission check on any of it, because there is no concept of one.

So when you put a browser in a container, or a firejail profile, or an AppArmor profile, and hand it your X socket, you have confined its filesystem access and left the keylogging channel wide open. It can read your password manager's window. The confinement is real for one class of attack and absent for another, and people generalise from the first to the second.

Wayland fixes this by construction: clients cannot see each other's input or buffers, and screen capture goes through a portal that asks you. Which moves the question to the portals, and to Xwayland, where anything running under it is back in the shared X world with everything else under it.

>confinement is not a property of the sandbox >it is a property of the sandbox plus every socket you passed into it

The general version of this: enumerate what you handed through. The X socket, the session bus, /dev/dri, the pulse socket, an ssh agent. Each one is a channel out, and a sandbox is exactly as strong as the most powerful thing you passed in.

A key on disk is a file. Read the file, be you. Passphrases help until the moment your agent has it unlocked, which on a workstation is all day.

FIDO2 keys have been in OpenSSH for years now and nobody uses them:

>ssh-keygen -t ed25519-sk -O resident -O verify-required

The private key never leaves the token. What lands on disk is a handle that is useless without the hardware. verify-required adds a PIN on top of the touch, so lifting the token off a desk is not enough either. resident stores it on the token itself, so you can walk to a new machine and pull the handle back out of the key rather than needing a backup of a file.

The property that actually matters is the touch. Every authentication needs a physical press, so malware sitting on your machine with your agent unlocked cannot quietly use the key a thousand times while you are at lunch. It can use it exactly when you press the button, and you notice a light blinking that you did not expect.

Buy two. Enrol both everywhere at the same time. Put the second one somewhere that is not your desk, because the failure mode of hardware keys is losing the hardware, and that failure is total.