Lab 14 of 17 · By Michael Stout
In this lab
Use Copy beside a command to copy it exactly.
Scan Metasploitable with OpenVAS
Lab 12 built a private range; Labs 11 and 12 only ever pointed Nmap at it. This lab points a real vulnerability scanner — Greenbone Community Edition, the open-source OpenVAS engine — at Metasploitable instead, and comes back with something Chapter 7 actually asks you to read: a severity-rated, CVE-linked finding, not a service banner.
A port number isn't a finding
Nmap tells you a port is open and probably running vsftpd 2.3.4. That's a clue, not a conclusion. A vulnerability scanner takes the next step Chapter 7 actually tests: matching what's listening against known weaknesses, and handing back a severity, a CVE, and a recommended fix — the shape of every real vulnerability report you'll ever triage. Greenbone Community Edition is the free, open-source edition of the OpenVAS scanning engine that sits behind a lot of commercial vulnerability management products. Reading its report teaches the same structure you'll see in a paid tool.
Greenbone's own documentation is explicit that this container setup is for learning and testing, not production deployment — which is exactly this lab's use case.
What you'll need
Lab 12's range — this lab layers a second stack alongside it, it doesn't replace it. If metasploitable isn't up, start it first.
20 GB minimum, 60 GB recommended per Greenbone's own sizing guidance — most of it the vulnerability feed.
4 GB minimum for the Greenbone stack alone, 8 GB recommended — on top of whatever Lab 12's containers are already using.
45–90 minutes, almost all of it a one-time feed sync that runs in the background after first start. Budget for it; don't watch it.
A second stack, alongside Lab 12's
- Download the official Compose file into its own folder:Use
mkdir C:\labs\greenbone-community-edition cd C:\labs\greenbone-community-edition curl.exe -L -o compose.yaml https://greenbone.github.io/docs/latest/_static/compose.yaml
curl.exespecifically — plaincurlin PowerShell is an alias forInvoke-WebRequestand takes different flags. - Bring it up:First start pulls a stack of containers and kicks off the vulnerability feed sync in the background — that sync is most of this lab's time budget, and there's nothing to click to speed it up.
docker compose up -d
- Set the admin password — this creates the login, there's no default admin/admin on this image:
docker compose exec -u gvmd gvmd gvmd --user=admin --new-password=choose-one
- Open the web interface at
https://127.0.0.1, accept the self-signed certificate warning, and log in as admin with the password you just set.
Two Compose stacks, bridged by hand
- Confirm the network Compose created:Look for
docker network ls
greenbone-community-edition_default— Compose names it after the folder holding the file. - Attach Lab 12's running Metasploitable container to it:This adds a second network to an already-running container — it stays reachable on Lab 12's
docker network connect greenbone-community-edition_default metasploitable
lab_nettoo. - Get its address on the new network — this IP is what you'll scan, not a hostname:
docker inspect metasploitable --format "{{(index .NetworkSettings.Networks \"greenbone-community-edition_default\").IPAddress}}"
From the web interface, not PowerShell
- Create a target. In the GSA web UI: Configuration → Targets → New Target. Name it
metasploitableand enter the IP address from Part 2 as the host. - Create and start a scan task. Scans → Tasks → New Task. Point it at the target you just made, leave the default “Full and fast” scan config, and start it.
- Wait for it to finish. A single, lightly-patched host is a handful of minutes once the feed sync from Part 1 has actually completed — check the feed status first if the scan seems to be finding nothing.
- Open the report and sort by severity. Find the vsftpd finding and open it. Note its CVE, its CVSS score, and the exact wording of the recommended fix — that's what goes in a real report, not just “vulnerable.”
Get more out of the same scan
| Try | What it shows you |
|---|---|
| Scan DVWA's host too | Attach dvwa to Greenbone's network the same way and add it as a second target — compare a web app's findings against a general-purpose Linux box's. |
| Switch the scan config to “Discovery” | A lighter, faster pass that only maps what's there, without the vulnerability tests — the difference between recon and assessment in one dropdown. |
| Export the report as PDF | Reports → your task → Export. This is the artifact an analyst actually hands upward, not the live web view. |
A full vulnerability scan is far more intrusive than the Nmap passes in Labs 11 and 12 — it actively tests for weaknesses, not just what's listening. Never point Greenbone at anything outside this isolated range. The authorization rule from Lab 11 applies here even more strictly.
Greenbone's findings are only as current as its vulnerability feed. A scan run before that first sync finishes will quietly under-report — check feed status under Administration before trusting a result that looks too clean.
Sources. Greenbone Community Documentation, container quickstart and system requirements, greenbone.github.io/docs/latest/22.4/container/index.html. Greenbone, official Docker container announcement, greenbone.net/en/blog/official-docker-container-for-greenbone-community-edition. Docker, docker network connect reference, docs.docker.com/reference/cli/docker/network/connect. Container names, network names, and feed sync behavior are current as of September 2026 — re-verify against Greenbone's own docs before teaching this lab live, since the Community Edition container project has changed shape before.