Zero-Trust OPSEC for a Fresh Kali Install: What You Must Do and What You Should

Most Kali hardening guides fall into one of two traps. Either they hand you a paranoid checklist of forty things that make the machine miserable to actually use, or they give you a bare list of commands with no sense of what matters and what's theatre. This is my attempt at the middle: a practical, tiered setup I run on every fresh install, organized by what actually moves your risk.

The framing is zero trust, and I mean that literally — not the enterprise marketing version. The premise is simple: assume every layer can fail. Assume the network is hostile, the disk will eventually be lost or seized, a tool will leak, and you will, at some point, make a mistake. Good OPSEC isn't one perfect wall. It's layers that each fail independently, so no single mistake unmasks you.

One reframe before the commands, because it's the thing most people get wrong: OPSEC is not about becoming a ghost. You are not going to be invisible, and chasing invisibility usually creates a false sense of security while the real leaks happen elsewhere. The goal is compartmentalization and hygiene — keeping your contexts separate and never being the one who builds the bridge between them. Everything below serves that goal.

Part 1 — The Must-Haves (non-negotiable)

If you skip these, nothing else matters. These are the load-bearing walls.

1. Full-disk encryption (LUKS), set at install time

This is the one thing worth reinstalling for if you don't already have it. You cannot meaningfully bolt FDE on afterward. At the partitioning step of the Kali installer, choose "Guided — use entire disk and set up encrypted LVM."

Use a real passphrase — a five-to-six-word diceware phrase beats a short complex string every time. This key protects everything. Make it good, and don't lose it.

LUKS covers exactly one threat, but an important one: the powered-off, lost, or seized machine. Understand its limit — once you've booted and unlocked, the disk is open. Which is why the list continues.

2. A VPN with a real kill switch

Your VPN hides your traffic from your ISP and gives you an exit IP that isn't your home connection. But the setting that matters isn't connected — it's the kill switch. Without it, if the tunnel drops for a half-second, your real IP leaks and you never notice. With it, traffic simply stops rather than falling back to your raw connection.

On the provider question, I run Mullvad, and for a privacy-focused setup it's the pick I keep coming back to. The reason isn't speed or server count — it's the account model. Mullvad doesn't ask for an email, a name, or any personal details. You get a random 16-digit account number, and that number is your login. You can pay with cash or Monero, which means the subscription was never tied to your real identity in the first place. That's a stronger position than paying with a card and trying to wall the account off afterward — an account that was never linked beats one you have to keep separated.

One honest caveat, because I got asked this and it's a real trap, paying via the Google Play in-app purchase keeps your account anonymous to Mullvad, but the payment runs through your Google identity. If anonymity is why you picked Mullvad, fund it with Monero or cash, not Play Store billing. And because anonymous payment means there's no email to recover with, write your account number into your password manager the moment you create it.

On Kali, grab the official .deb directly rather than adding their apt repo — Kali reports as kali-rolling, which their repo doesn't target, so the repo route tends to fail. Install, log in with the account number, and turn on lockdown mode, auto-connect, and launch on startup. Then verify — connected is not the same as leak-free:

curl https://am.i.mullvad.net/connected

curl https://am.i.mullvad.net/connected

Then open mullvad.net/check in a browser to catch DNS and WebRTC leaks. Confirm your real IP appears nowhere.

3. Firewall, default-deny inbound

Your attack box should not be quietly listening for anything you didn't start.

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

sudo apt install ufw -y
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

Ten seconds, and it closes the whole class of something on this machine is accepting connections I didn't know about.

4. A password manager — with an encrypted, backed-up vault

Use KeePassXC. Strong, unique master passphrase. Unique credentials per context.

But the part people botch is storage, and it's the one failure mode with no recovery: your vault must exist in at least two places, both encrypted. A single copy of your password database is a single point of catastrophic failure — if that drive dies, every credential is gone at once. I keep mine on a LUKS-encrypted USB and a backup on the encrypted system disk. For extra separation, KeePassXC supports a key file as a second factor: keep the .kdbx on disk and the key file on a USB, and neither piece unlocks anything alone.

5. MAC randomization

Your MAC address is visible to every network you touch — the AP, the switch, other devices on the LAN. It doesn't travel past the first hop, so this is about local-network privacy and not being trackable across the networks you join. Let NetworkManager handle it automatically so discipline isn't required. Create /etc/NetworkManager/conf.d/00-macrandomize.conf:

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=random
ethernet.cloned-mac-address=random

[device]
wifi.scan-rand-mac-address=yes

[connection]
wifi.cloned-mac-address=random
ethernet.cloned-mac-address=random

The scan-rand-mac-address line matters most — it randomizes the MAC used while scanning, so you don't leak your real one just looking for networks. Restart NetworkManager and you're done.

Part 2 — Recommended for Every New Install

None of these are load-bearing on their own, but together they close the gaps the must-haves leave open. This is the difference between "encrypted" and "actually hard to work against."

Set a boring hostname

A box announcing itself as kali over DHCP is louder than any MAC address. Set something generic at install (or sudo hostnamectl set-hostname laptop). Don't put your handle in it.

Screen auto-lock — the gap LUKS doesn't cover

This is the one people forget. Full-disk encryption protects a powered-off laptop. The moment you've booted and unlocked, the disk is wide open to anyone who sits down at it. A short idle-timeout screen lock, plus the habit of locking when you walk away, covers the walk-away threat that encryption simply doesn't. Given how much sensitive material lives on a working attack box, this is worth the two minutes.

Separate your identity lanes at the browser level

If you do research under a handle and also live a real-name life on the same machine, keep them in separate browsers — not just separate tabs. What deanonymizes people is never I logged in as myself. It's cross-contamination: logging a real-name account and a research handle into the same profile, so cookies and sessions and fingerprint tie the two together. Use one browser for the research lane, a visually distinct one for the real-name lane, and never let them share state.

Put your dotfiles in a private git repo

You will reinstall again. Capture your .zshrc, aliases, and tool configs in a private repo so next time is a git clone, not a from-memory rebuild. Scrub secrets before committing — dotfiles are a classic place API keys leak.

An encrypted folder for working loot

Beyond FDE, an encrypted folder (gocryptfs) or a LUKS container gives you a second wall that stays locked even while the machine is running and unlocked — exactly the window LUKS leaves open. Keep it locked by default, unlock only when you need what's inside. Especially useful for engagement data you carry on external drives, where the encryption travels with the files.

History hygiene

For sessions handling tokens and keys, use a shell that doesn't persist them:

unset HISTFILE

unset HISTFILE

Your shell history is exactly where secrets and target details quietly accumulate. A dedicated terminal profile for sensitive work keeps them out of ~/.zsh_history.

Update discipline

Kali rolling moves fast, and an outdated attack box is its own liability. Either a standing weekly sudo apt update && sudo apt full-upgrade, or set up unattended-upgrades for security patches.

What This Deliberately Isn't

Notice what's not on either list: no elaborate scheme to be anonymous to your VPN provider, no Tor-over-VPN-over-proxy tower, no attempt to be a ghost. That stuff is mostly theatre. Stacking anonymity tools you don't fully understand leaks worse than one clean, well-configured layer — misconfiguration is the enemy, not insufficient paranoia.

The zero-trust mindset that actually protects you is boring and behavioral: assume each layer fails, so build several that fail independently. Assume you'll make a mistake, so structure things (separate lanes, locked-by-default vaults, backed-up keys) so that one mistake doesn't cascade. The wall is never a single tool. It's the discipline of never being the person who carries data across your own boundaries.

Set the must-haves first — they're the walls holding the roof up. Then work through the recommended list as you rebuild. By the time your tools are back, you have a machine that's genuinely hard to work against, and still pleasant to actually use.

Stay in scope, keep your lanes clean, and back up your keys.