A Homelab Threat Model: What You're Actually Defending Against

Ask a homelabber what they are defending against and you often get a shrug, or a vague gesture at “hackers”. That vagueness is expensive. It leads people to pour weekends into an elaborate VPN mesh while their backups sit unencrypted on a NAS with the default password, or to obsess over intrusion detection while every service shares one reused credential. Security effort spent against imaginary threats is effort stolen from the real ones. A threat model fixes that by forcing you to write down, plainly, who might come after your setup, what they would want, and what actually stops them.

This is not a corporate compliance exercise with a forty-page template. For a homelab it is an afternoon with a notepad and four honest questions. I will walk through the questions, the answers that most homelabs land on, and how the picture that emerges should reorder your to-do list. The point is to stop guessing and start spending your limited attention where it moves the needle.

The four questions

Every threat model, whether it protects a bank or a Raspberry Pi, comes down to the same enquiry framed four ways:

1. What do I have that’s worth protecting? Your assets. Not just data — availability, identity, and the physical machines too.
2. Who might want to get at it, and how capable are they? Your adversaries, ranked by likelihood and skill.
3. How could they actually get in? Your attack surface and the paths across it.
4. What happens if they succeed, and can I recover? Impact and resilience.

Answer those honestly and the priorities fall out on their own. Skip them and you are decorating, arranging security controls by which ones felt satisfying to install. Let me take each in turn with the answers a typical homelab gives.

What you actually have

Start by listing assets, and resist the urge to only think about data. A homelab holds at least four kinds of thing worth protecting, and people routinely defend one while forgetting the rest.

Data is the obvious one: family photos, documents, the media library that took years to curate, password vaults, and anything you would grieve to lose. Rank these by how much their loss or exposure would hurt. Your photo archive being destroyed is a catastrophe; your photo archive being seen by a stranger is unpleasant but survivable. Those are different threats needing different defences, and conflating them wastes effort.

Availability is the asset people forget until it bites. If your home runs on self-hosted DNS, home automation, and a door lock that phones home to a container on your rack, then an outage becomes a house that stops working, well past mere inconvenience. The thing you are protecting there is uptime, and the adversary is often your own botched upgrade rather than any attacker.

Identity and credentials are the keys to everything else. The SSH keys, the API tokens, the reused password that unlocks your email and therefore every account tied to it. Compromise here is uniquely bad because it cascades.

The hardware itself matters too, both as kit worth stealing and as a foothold. A machine physically in your house is an asset with a different threat profile from a VPS in a datacentre, and if you have both, they need separate thinking.

Write all four down before you go further, because the next questions only make sense against a concrete list.

Who would actually bother

Here is where most homelab anxiety is miscalibrated. People imagine a skilled human adversary studying their setup, and defend against that. The real distribution of attackers looks different, and putting them in order of how likely they are to affect you changes everything.

The automated scanner is, by an enormous margin, the threat you will actually meet. It is a bot with no idea you exist, sweeping the entire IPv4 space for known-vulnerable software, exposed admin panels, default credentials, and unpatched CVEs. It does not care who you are. It will try your services thousands of times a day, and it wins by finding the one machine in a million that forgot to patch. This adversary has near-zero skill and near-infinite patience, and it accounts for the overwhelming majority of real compromises of small setups.

Ransomware and commodity malware are the automated scanner’s payload. Once something gets in — often through a person clicking a thing, not through your firewall — it looks for reachable file shares and backups to encrypt. The scary detail is that it hunts your backups specifically, because a victim with good backups doesn’t pay.

The opportunist with local access covers a flatmate, a visitor, a repair technician, or a thief who grabs the NAS. Low skill, but physical access defeats a lot of clever remote defences, and this adversary is more plausible than the movie hacker.

The targeted human attacker — someone who has picked you specifically and has real skill — is genuine but rare for a hobbyist. If you are a journalist, an activist, hold cryptocurrency of interest, or have made the wrong enemy, move this threat up your list sharply. For most people it belongs near the bottom, and defending against it first is how effort gets wasted.

Yourself is the adversary nobody writes down and everybody meets. The fat-fingered rm -rf, the migration that ate the database, the certificate that expired and took a service down, the “quick change” at midnight that broke the firewall. Self-inflicted outages and data loss are, for most homelabs, more frequent and more damaging than any external attacker. Take that personally, because it is meant kindly.

How they get in

Now map the paths. Your attack surface is every point where the outside world can touch your setup, and the automated scanner is testing all of it constantly.

The big one is anything exposed to the internet: a port forwarded on your router, a service published through a reverse proxy, a VPS with a public IP. Every exposed service is a door the scanner rattles. The single most effective thing most homelabs can do is simply expose less — reach services over a VPN instead of publishing them, so the scanner finds nothing to test. What must stay exposed wants active defence at the edge, which is exactly where tools like CrowdSec and Fail2ban earn their place, turning down the volume of the automated hammering.

The second path is credentials and identity. Reused passwords, weak SSH configuration, and secrets checked into a git repo are all doors that no firewall guards. This is why hardening the front door and moving keys into hardware repay the effort so well.

The third is the supply chain and the software you run. Every container image, every unattended package, every curl | sh install script is trust you extended to someone else’s code. An unpatched service with a public CVE is the automated scanner’s favourite way in, which makes disciplined patching one of the highest-value habits you have.

The fourth is physical and local: someone at the keyboard, a stolen disk, a lab that anyone on your home Wi-Fi can reach because you never segmented the network. A guest device and your NAS living on the same flat network means one compromised phone can see everything.

What happens when they win

The last question is the one that separates a threat model from a wish. Assume a control fails. What is the blast radius, and can you recover?

This is where backups stop being a chore and reveal themselves as the most important security control you own, because they are what makes almost every attack survivable. Ransomware encrypts your data? You restore. A bad upgrade eats a database? You restore. You rm -rf the wrong directory? You restore. A backup only counts if it is tested, versioned (so you can go back to before the malware ran), and offline or immutable (so the ransomware that hunts backups can’t reach it). One offline copy you have actually restored from beats ten automated jobs nobody has ever verified.

Segmentation is the other resilience lever: if a compromised guest device can only see the guest network, the blast radius of that compromise is tiny. Isolation limits how far any single failure spreads, which is why it belongs in the plan even for a home network.

Turning the model into a to-do list

Put the pieces together and a priority order emerges that looks nothing like the average “homelab security” checklist. For the typical setup it runs roughly:

• Backups first — tested, versioned, with one offline copy. This defends against the widest range of threats including yourself, and it is the difference between an incident and a catastrophe.
• Reduce exposure — put services behind a VPN, close the ports you don’t truly need public, and patch what remains promptly, because unpatched exposed software is the scanner’s way in.
• Fix identity — a password manager, unique credentials, SSH keys, and a hardware token for the accounts that unlock everything else.
• Segment the network — keep guest devices, untrusted IoT, and your trusted infrastructure apart, so one compromise doesn’t become total.
• Defend the edge and watch it — active blocking on what stays exposed, plus enough logging that you would notice a break-in.
• Physical and targeted defences last — real, but lower probability for most people; spend here after the basics hold.

Notice what dropped down the list. The elaborate detection stack, the fancy segmentation of segmentation, the defences against a skilled human who was never coming — all real, all lower priority than a tested backup and a closed port.

Is threat modelling worth an afternoon?

Yes, and it is close to free. The exercise costs you a notepad and a couple of hours of honesty, and it repays that by stopping you from spending the next fifty weekends on the wrong things. Nearly everyone who does this discovers the same two truths: their backups are worse than they thought, and they are exposing more to the internet than they need to. Fixing those two beats any amount of exotic tooling.

Redo the model whenever your setup changes shape — a new public service, a move to a datacentre, a change in what you are storing — because the answers drift as the lab grows. And keep it honest about the adversary you actually face. The automated scanner and your own tired-fingered mistakes are the threats that will visit; build for them first, and build for the movie hacker only once you are the sort of person a movie hacker would target. Once you know what you are defending, the specific controls — signed commits and hardware keys, edge blocking, an audit trail — stop being a shopping list and start being answers to questions you have actually asked.