Building a plain risk scoring setup for your homelab

I treat my homelab like a small country with bad border control. It has assets, network edges and services that wander off the reservation. A simple risk scoring setup keeps the noise down and gives me a reason for the changes I make. I use the data I already have, turn it into repeatable scores, then use those scores to tighten VLANs and firewall rules.

Start with an inventory. List every device, its IP, MAC, role, OS, criticality and whether it faces the internet. I keep that in a CSV or a small SQLite database. One source of truth matters more than a clever spreadsheet full of contradictions.

What data to collect

• Network telemetry: DHCP logs, ARP tables, switch port mappings.
• Flow and packet alerts: Suricata, Zeek or a managed IDS feed.
• Vulnerability data: periodic Nmap + OpenVAS scans or Nessus if you prefer.
• Service exposure: open ports, TLS certificate expiry, SSH banners.
• Configuration drift: snapshots of firewall and router configs.
• Authentication anomalies: failed login spikes from services.

Practical collection tips

• Centralise logs. I send firewall, IDS and host logs to one place, whether that is ELK, Grafana Loki, or just flat files on a box that stays on.
• Normalise fields early. Put timestamps in UTC, standardise hostnames and tag VLAN IDs. It makes the later rules much less annoying.
• Automate scans. Run light checks daily for ports and certificate expiry, then deeper vulnerability scans weekly. Keep them off-peak so the lab does not grind to a halt.
• Add metadata. Tag each asset with a trust level such as admin device, server, IoT or guest, and give it an owner field, even if that owner is just you.

Example metrics to track

• Count of critical CVEs per host.
• Number of externally reachable ports per subnet.
• Mean time between failed logins.
• Number of IDS alerts per day, by rule.

That gives me something better than a gut feel when I decide what needs attention.

Turn metrics into risk and put controls where they belong

I keep the scoring simple. Likelihood gets a 1 to 5 score. Impact gets a 1 to 5 score. Risk is likelihood multiplied by impact, which gives a number between 1 and 25 that is easy to sort and threshold.

Scoring examples

• Likelihood 5: Internet-facing service with a known exploit and no patch.
• Impact 5: Backup server or domain controller equivalent.
• Likelihood 2, impact 1: Guest IoT device with no sensitive data.

Policies based on scores

• 16 to 25: Act now. Isolate the host, block inbound access, patch or rebuild.
• 8 to 15: Fix within 72 hours. Restrict access and book a patch window.
• 1 to 7: Monitor. Log it and watch the trend.

How that drives VLAN configuration and firewall rules

• VLAN layout I use:
  • VLAN 10 — Management (switch, hypervisor, monitoring)
  • VLAN 20 — Servers (non-public services)
  • VLAN 30 — IoT (low trust)
  • VLAN 40 — Guest (internet-only)
  • VLAN 50 — Public DMZ (internet-facing web, reverse proxies)
• Microsegmentation rule of thumb: deny east-west by default. Only allow traffic that has a job to do.

Sample firewall rules

• Default deny all between VLANs.
• Allow established and related on the router.
• Management VLAN to Server VLAN: allow TCP 22, 443, 5985 where needed, and only from specific management hosts.
• Server VLAN to Internet: allow HTTPS and whatever else is needed outbound; block SMB to the internet.
• IoT VLAN to Internet: allow outbound HTTP and HTTPS only; block access to Server and Management VLANs.
• Guest VLAN to Internet: allow outbound web ports and DNS; deny access to local subnets.

Automating enforcement

• Turn score changes into rule changes. A host with critical vulns and high exposure can move to a quarantine VLAN through a script that updates switch port assignments or applies a firewall tag.
• Use an orchestration tool or plain SSH scripts to push ACL changes to pfSense, OPNsense or a managed switch.
• Keep firewall rules in Git and tag each change with the score that triggered it.

I had a Raspberry Pi running a self-hosted app on a forwarded port. Daily port scans showed it was exposed. The vulnerability scan came back with a medium CVE. I scored it as likelihood 4 and impact 2, so the risk landed on 8. That put it in the 72-hour bucket. I moved the Pi to the IoT VLAN, removed the port forward, put the app behind a reverse proxy in the DMZ and scheduled an OS patch. The score dropped and the alert count settled back to normal.

Dashboards are only useful if they show trends. A steady rise in IDS alerts over a week means more than one noisy day. I use simple charts: a time series for alerts, a bar chart for critical CVEs by host, and a heat map of risk scores by VLAN.

Routine work I run:

• Weekly: quick port and cert checks, review new high-risk hosts.
• Monthly: full vulnerability scan and config snapshots.
• Quarterly: check the VLAN plan still matches reality and remove stale rules.

Avoid a few traps. Do not treat the score like gospel. Use it to rank work, not to make every decision on its own. Keep one inventory source. Multiple lists just create confusion. Do not hardcode credentials into automation scripts. Use vaulting or environment variables.

The whole thing works best as a pipe: collect, normalise, score, act, verify. Keep the scoring simple enough that you can explain it at a glance. Use VLANs and firewall rules to back it up. Automate the boring bits and keep an eye on the trend lines.