Vulnerability Management for People Who Enjoy Finding Their Own Problems

securitygvmgreenbonenmapkaliscanning

There is a particular flavour of anxiety unique to home lab operators: the creeping suspicion that something on your network is doing something you didn’t intend. Not because of active threats (probably), but because you have 62 hosts across six VLANs and you genuinely cannot remember what all of them are.

The solution is automated network discovery and vulnerability scanning. The side effect is discovering several services you forgot you’d enabled, two devices you don’t recognise, and an NTP misconfiguration that has apparently been there since 2023.

KaliLinux as the Security VM

The KaliLinux VM at 172.16.50.4 exists for one reason: it came with everything needed for security tooling pre-installed, and spending an afternoon configuring security tools on a vanilla Debian VM felt like building a workbench before you could do woodworking. Kali is the workbench.

The VM runs:

  • Greenbone Vulnerability Manager (GVM) — full enterprise-grade vulnerability scanner, web UI at https://172.16.50.4:9392
  • Nmap — network discovery and port scanning
  • A cron-scheduled automation pipeline that runs both without human intervention

Greenbone GVM: The Heavy Scanner

GVM (the open-source version of what Greenbone sells commercially) is a vulnerability scanner that maintains a database of CVEs and tests hosts against them. The setup is not trivial — it involves PostgreSQL, Redis, the OpenVAS scanner daemon, the GVM daemon, and the Greenbone Security Assistant web interface — but the result is a scanner with the same capability as tools that cost significant money in enterprise licensing.

The lab configuration:

  • Scan target: All 6 VLANs (172.16.10.0/24 through 172.16.250.0/24)
  • Schedule: Weekly, Sundays at 03:00 UTC
  • Scan config: “Full and Fast” (comprehensive but bounded)
  • Credentials: SNMP community strings and SSH keys for authenticated scanning

Authenticated scanning matters. An unauthenticated scan tells you which ports are open. An authenticated scan can check the actual package versions installed on a Linux VM and tell you that your PostgreSQL version has a specific CVE that was patched three releases ago. This is the difference between knowing a door exists and knowing whether it’s locked.

Nmap Discovery: The Daily Pulse

Where GVM runs weekly and runs deep, Nmap runs daily and runs wide. The discovery pipeline:

# Runs daily at 02:00 UTC via cron
nmap -sn -oJ /opt/homelab/discovery/scan_$(date +%Y-%m-%d).json 172.16.0.0/16

The output is a JSON file of discovered hosts. A Python enrichment step adds MAC address resolution via the Juniper core switch SSH connection — the switch’s ARP table knows what MAC addresses correspond to which IPs, and the MAC OUI tells you the manufacturer. A Raspberry Pi shows up as a Raspberry Pi Trading Ltd MAC. An IoT device shows up as whatever Chinese ODM manufactured its WiFi chip.

The results are stored in /opt/homelab/discovery/ and served via a lightweight HTTP server on port 8080. This HTTP endpoint is what Clawdia (the AI assistant) calls every morning to generate the daily network summary.

The Automation Scripts

Four shell scripts live in F:\Projects\lab-automation\scripts\:

01-install-greenbone.sh — Idempotent GVM installation. Can be run on a fresh Kali VM and will produce a working GVM installation. This matters because VMs get rebuilt, and “I remember how I set this up” is not a recovery plan.

02-nmap-discovery.sh — Sets up the daily Nmap pipeline including the HTTP results server. Also configures ARP enrichment via the Juniper switch integration.

03-setup-cron.sh — Configures the cron schedule: daily Nmap at 02:00 UTC, weekly GVM feed update at Sunday 02:00 UTC (feed before scan), weekly scan at Sunday 03:00 UTC.

04-configure-gvm.sh — Creates the GVM scan target (all VLANs), configures scan credentials, and schedules the weekly scan. Outputs the task ID and target ID for reference as UUIDs. Write these down. You will search for them later.

The Use Case: Knowing What’s Running Before You Forget

The practical output of this stack is a morning ritual that has replaced a different, worse ritual: manually SSHing into the router to check the DHCP leases and wondering whether that unknown 192.168.x.x address is a new device or something concerning.

Now, at 12:15 AEST, Clawdia sends a WhatsApp voice note summarising overnight Nmap results. New hosts are flagged. Disappeared hosts are noted. The message is generated by a local LLM comparing yesterday’s scan JSON to today’s and producing a human-readable summary. It sounds like a weather report for your network.

“Two new hosts appeared on the IoT VLAN overnight: one Espressif device (likely ESP32) and one device with an unknown OUI. Three hosts from yesterday are no longer responding. Your Synology NAS is healthy. No significant changes to the VM estate.”

This is exactly the kind of thing you don’t think you need until you have it, and then you can’t imagine going back.

What GVM Actually Finds

In a well-maintained home lab running current software, GVM finds fewer critical CVEs than you’d expect. What it consistently finds:

  • Weak cipher suites on older infrastructure (the Synology NAS had TLS 1.0 enabled for legacy compatibility — disabled)
  • Default SNMP community strings on managed switches (fixed, now uses custom community string stored in VaultWarden)
  • Outdated firmware on access points and switches (Aruba APs had a 14-month-old firmware — updated)
  • Missing security headers on internal web services (added via Traefik middleware)

None of these are exciting. None of them made the news. All of them represent real attack surface that existed silently until GVM found them.

That’s the point. The threats to a home lab are not sophisticated nation-state actors. They’re misconfigured defaults, forgotten services, and the slow drift of infrastructure that nobody maintained because nobody was watching. Automated scanning is watching.