You finished piece 01. You know host from guest. You still have a problem: the floor under the hypervisor is a normal laptop full of browser logins, unencrypted sleep, crash reports, and a password manager extension that syncs secrets into every machine you open. When a case guest dies, that is fine. When the host is wrong, every case you ever ran is standing on soft ground.

This piece is only about the Linux host: the real computer that will run your investigation guests. Think of it as a vault and a power plant, not as a place you browse targets. If your only machine is Windows or Mac today, keep the hypervisor map from piece 01 and treat what follows as the target build when you can dedicate bare metal or a dual-boot. A Linux host running Linux guests still produces the fewest software fights for most OSINT labs.

Four-layer host baseline stack

Field note

People optimize the wrong layer. They spend a weekend on browser plugins inside a dirty host, or they install a password manager inside the investigation VM so logins are fast. Then the VM is deleted, exported, or compromised, and the secrets go with it. Or they believe a VPN makes them anonymous. A VPN encrypts traffic to a provider and changes the IP the target site sees. That is privacy of path, not anonymity. The provider still sits in the middle; correlation still exists. Use a reputable VPN on the host path (and often again inside guests for case separation). Do not treat it like Tor-class cover.

The system

If you have never installed Linux on bare metal, read this as a build manual. You need a spare USB drive (fast SSD preferred), a second machine or phone to read steps if the install reboots, and a passphrase you will not lose: full-disk encryption without a backup of that passphrase is a brick.

Step 1: Deployment media (Ventoy)

Ventoy turns a USB drive into a multi-boot stick. You install Ventoy onto the drive once, then copy ISO files onto it like normal files. You do not reflash the stick every time you want a different installer.

  1. Download the current Ventoy release for your helper OS from the official Ventoy site (version numbers change; do not chase a tutorial’s old filename).
  2. Run the installer against the USB device (double-check the device letter; this wipes the stick).
  3. Copy a current Debian or Ubuntu desktop ISO onto the Ventoy data partition.
  4. Boot the target laptop from that USB (firmware boot menu; disable Secure Boot only if your chosen ISO requires it and you understand the trade).

Why Ventoy over a single-ISO flash tool: rebuild speed. You can carry host installers, live rescue ISOs, and utility images on one stick and swap by choosing a file at boot.

Step 2: Install with full-disk encryption

During the Ubuntu (or similar) installer:

  1. Choose the option path that offers advanced or LVM features.
  2. Enable encrypt the installation (LUKS under the hood on modern Ubuntu/Debian installers).
  3. Set a long disk passphrase. Write it into your offline process, not a sticky note on the bezel.
  4. Finish install, remove USB, boot the new host, complete first-user setup.

Host FDE is mandatory for this baseline. Guest VM encryption is optional and case-dependent; the host holds the vault and every exported case file you keep. Stolen laptop at rest should present a locked disk, not a browser profile.

Step 3: Kill telemetry and crash phoning home (Ubuntu-family)

On first update cycle, open Terminal. Package names vary slightly by release; this set is the durable Ubuntu-family pattern:

sudo apt update
sudo apt purge -y apport apport-symptoms ubuntu-report whoopsie popularity-contest
sudo apt autoremove -y

On pure Debian the list is often shorter; still remove anything you did not ask to report. Also decline optional “send stats” prompts at install when you see them. Telemetry is not usually a spy novel. It is avoidable beaconing and crash metadata you do not need on an investigation host.

Step 4: ClamAV (process defense, not magic armor)

Linux hosts are hit less by commodity Windows malware. You still install ClamAV so you can update definitions and run scans you can describe under scrutiny: opposing counsel, oversight, a client security questionnaire, a partner who only understands “antivirus.”

sudo apt install -y clamav clamav-daemon clamav-freshclam
sudo systemctl stop clamav-freshclam
sudo freshclam
sudo systemctl start clamav-freshclam
# infected files only under your home (full-root scans are slow; schedule them)
clamscan -r -i "$HOME"

If freshclam complains the service is already writing the database, stop the service first (as above), update, restart. Doctrinal point: the scan is as much demonstrable process as it is detection. Skipping it because “Linux does not get viruses” is how a non-technical room decides your method was careless.

Step 5: Weekly cleaner (BleachBit)

sudo apt install -y bleachbit

Run BleachBit as root on a schedule (weekly is the common rhythm). Clean package caches, thumbnails, and trash you do not need. Do not enable the option that overwrites free disk space as routine maintenance: it is slow, hard on SSDs, and not the same thing as “I wiped my secrets.” Secrets live in files you still have; free-space wipe is a special tool, not a weekly habit.

Step 6: Credential vault on the host only

sudo apt install -y keepassxc
  1. Create a new database file (.kdbx) on the host disk.
  2. Master password: long and unique. This one password protects the rest.
  3. Groups by platform or program (example: a group for each sock ecosystem), not one recycled password everywhere.
  4. Generate long random passwords (40+ characters is a common bar for generated secrets in this tradition).
  5. Backup: copy the .kdbx to an encrypted USB or other offline store. Test that you can open the backup on a clean machine.
  6. When a guest needs a login: unlock KeePassXC on the host, copy the password, paste into the guest browser, clear clipboard when done.

Do not install the KeePass browser extension inside investigation guests. Do not copy the database into the guest for convenience. The guest is expendable; the vault is not. Manual paste is slower. That is the point.

Credential vault stays on host; paste only into guests

Step 7: Hypervisor and VPN, then piece 01

Install your hypervisor (KVM/virt-manager or VirtualBox on Linux hosts). Install a reputable VPN client from the vendor’s current Linux instructions (do not pin a single brand as doctrine; pick one you can pay for and verify). Confirm VPN connects before you treat the host as ready. Then build the golden master guest and clone lifecycle from piece 01.

Host build sequence from Ventoy to vault

Common newbie traps

  • Encrypt skip “to finish faster” (you will not retrofit easily).
  • Putting KeePassXC inside every VM so logins feel smooth.
  • Believing VPN equals anonymity.
  • Running BleachBit free-space wipe every Sunday and calling the host “clean” while browser logins still hold true-name sessions.
  • Browsing targets on the host “only to download an ISO.”
  • No offline backup of the .kdbx until the disk dies.

What ClamAV and VPN are really for

ToolNaive storyWorking story
ClamAVLinux antivirus stops all malwareUpdated scanner + logs you can cite; reduces “no security software” attacks on your method
VPNI am invisibleEncrypted path and shifted IP; privacy, not anonymity
BleachBitMakes the disk forensically blankReduces routine residue; not a substitute for encryption and vault discipline
VentoyFancy USBFast rebuild and multi-ISO deploy under time pressure
KeePassXC on hostInconvenient passwordsSurvives guest death; limits blast radius of one compromised case

Defense close

Offense against a soft host is boring and effective: seize the laptop, image an unencrypted disk, recover browser vaults, scoop a .kdbx left inside a guest export, or watch an operator reuse one password after a public breach. Close it with encryption at install, telemetry purge, demonstrable AV process, boring weekly hygiene, host-only credentials, and honest VPN expectations. Then run the same standard on yourself: if your daily driver holds every sock password in a cloud browser and you research from that profile, you are not running this baseline yet.

One action

Tonight, pick one:

  1. Already on Linux: run the purge and ClamAV install block above, install KeePassXC, move three investigation passwords out of the browser into an offline DB, copy that DB to an encrypted USB.
  2. Not on Linux yet: build a Ventoy USB with a current Debian or Ubuntu ISO and write your disk passphrase process before you click Install.

Next piece stays in the lab stack only until the floor is hard. This is OPEN SOURCE 02: harden the host, then stand up the guest.