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 -oX /opt/homelab/discovery/scan_$(date +%Y-%m-%d).xml 172.16.0.0/16

The XML output is converted to JSON for everything downstream. 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.

Update — August 2026

The scripts live at F:\Projects\homelab\scripts\kali\ now, and both schedules changed.

The daily scan stopped being a network sweep and became an identity register. Rewritten on 10 July 2026, it no longer leads with nmap. It pulls DHCP bindings and the ARP table straight off the Juniper core over a read-only SSH session — the core is both the DHCP server and the L3 gateway for every VLAN, so it already knows every device that has ever asked for an address, including the static-IP hosts an ICMP sweep would find but couldn’t name.

The inventory is keyed on MAC address rather than IP, which fixed the thing that made the original pipeline tiring: a phone picking up a different DHCP lease is not a new device, and being told it is, every morning, teaches you to stop reading the alerts. Now a known device changing IP is informational, and only a MAC never seen before raises anything. Randomised, locally-administered MACs — which modern phones generate per network — are treated as soft information rather than alerts, because otherwise every visitor is an incident. The baseline was seeded with 63 devices.

It runs at midday, not 2am. Partly because a lunchtime summary gets read; mostly because the Kali VM’s timezone was set to America/New_York for longer than anyone noticed, which meant “02:00” was not the hour anybody thought it was. Fixed to Australia/Brisbane the same day.

GVM runs monthly, not weekly. First Sunday at 03:00 UTC. Weekly full-and-fast scans across six subnets produced a near-identical report every time and stopped being read, which makes them worse than useless — they manufacture the feeling of coverage. The feed update still runs weekly, because the CVE database going stale is the failure mode that actually matters.

The credentialed scanning this post recommends finally happened, on 10 July 2026, and the results were an argument for doing it much sooner. All four Linux VMs authenticated successfully; at the default confidence threshold the estate came back essentially clean — zero critical, zero high, two medium, ten low, and the lows were all TCP timestamp information disclosure. Below the confidence threshold sat 55 “critical” and 126 “high” findings, every one of them an unconfirmed version guess. That gap is the whole argument for authenticated scanning: unauthenticated tools guess from banners, and their guesses are alarming and mostly wrong.

The core switch got its own credentialed scan the same day, using the read-only key the MCP server already had. Junos 23.4R2-S7.4, no confirmed advisories, and the switch didn’t drop a single ping while being scanned. The four highs it reported were SSH banner false positives — Juniper backports fixes without bumping version strings, so every scanner in the world thinks their switches are vulnerable to things they patched years ago.

The morning briefing moved. Clawdia was retired in June; new-device alerts now go to Telegram, sent by the Kali VM through Homer’s gateway with no model in the loop at all. A never-before-seen MAC is a fact, not something that needs summarising, and running it through an LLM only adds a way for it to arrive wrong.