Ethical Hacking
Nessus & OpenVAS
Nmap scripts are sharp and targeted. But when a client wants their entire infrastructure assessed systematically — every host, every port, every known CVE checked against every detected service — you need a dedicated vulnerability scanner. This lesson covers the two that matter most in professional practice.
Two tools, one job, very different contexts
Nessus and OpenVAS do broadly the same thing — scan a network, identify running services, cross-reference them against a vulnerability database, and produce a prioritised list of findings. The difference is licensing, cost, and where they are typically deployed.
Nessus is produced by Tenable and has been the industry standard for commercial vulnerability scanning since the late 1990s. Its plugin database — the collection of checks it runs — is the most comprehensive available. Large enterprises, managed security providers, and most professional pen testing firms use it. There is a free tier called Nessus Essentials that allows scanning up to 16 IP addresses, which is enough for lab work and small assessments.
OpenVAS — Open Vulnerability Assessment System — is the open-source alternative, maintained by Greenbone Networks. It is free, capable, and ships pre-installed on Kali Linux. The plugin coverage is not quite as deep as Nessus but it is genuinely useful for lab practice and for engagements where budget does not extend to a commercial licence. Most pen testers learn on OpenVAS and work with Nessus professionally.
Starting OpenVAS on Kali — the first run
OpenVAS takes a few minutes to initialise the first time — it downloads and updates its vulnerability database, sets up internal services, and generates SSL certificates for its web interface. Run the setup command once, wait for it to finish, then access the dashboard through your browser. Every subsequent start is much faster.
One thing that catches people out: OpenVAS runs several background services simultaneously. If you start scanning before all of them are ready, scans will fail silently or return incomplete results. The setup command below handles all of that automatically — it checks, starts, and confirms each service is ready before handing control back to you.
# Step 1 — initial setup (run only once, or after a long period of non-use)
# gvm-setup downloads the vulnerability database and configures all services
# This can take 10–30 minutes on first run — the database is large
# It will print the auto-generated admin password at the end — write it down
sudo gvm-setup
# Step 2 — start all OpenVAS services
# gvm-start launches the scanner, manager, and web interface simultaneously
# Wait until all three services report as running before opening the browser
sudo gvm-start
# Step 3 — verify everything is running correctly
# gvm-check-setup confirms each component is properly configured
# If anything failed to start it will tell you which service and why
sudo gvm-check-setupBreaking it down:
NVT stands for Network Vulnerability Test — OpenVAS's term for its individual check scripts. Each one targets a specific vulnerability or configuration issue. 86,000+ means OpenVAS is checking your target against a very large database of known issues. Keeping this database updated with gvm-feed-update before each engagement ensures you are checking against the most recently disclosed vulnerabilities.
The setup generates a random admin password and prints it exactly once. If you miss it or forget it, resetting requires running the setup again which is time-consuming. As soon as setup completes, log in and change the password to something you will remember — or store it in a password manager.
The web interface runs locally on your Kali machine — it is not exposed to the network. Your browser will show a certificate warning because the SSL cert is self-signed. This is expected — click through and proceed. Do not install OpenVAS on a machine with a public IP without securing the web interface behind authentication and a firewall rule.
Configuring and running a scan against Metasploitable
Once inside the dashboard, the scan configuration process takes about two minutes. OpenVAS uses the concept of scan configs — pre-built profiles that define which checks to run and at what depth. The right config depends on what you are trying to achieve.
For lab practice against Metasploitable, "Full and Fast" is the right choice. It will find everything worth finding without running so long that it disrupts your session.
The scenario: You are setting up an OpenVAS scan against Metasploitable — 192.168.56.101 — to get a full vulnerability picture before the exploitation phase. The scan config is "Full and Fast" and the target is configured with no credentials (unauthenticated scan). The command below shows how to launch and monitor the scan from the terminal rather than the GUI — useful when working in an automated pipeline or over SSH.
# OpenVAS can also be controlled via its command line interface (gvm-cli)
# This is useful for scripting scans or running them remotely over SSH
# Active scanning — this sends thousands of probes to the target
# Only run within your authorised scope and testing window
# First update the vulnerability database to get the latest NVT definitions
# Do this before every engagement — new vulnerabilities are added daily
sudo gvm-feed-update
# List available scan configurations to find the Full and Fast config ID
# Each config has a unique UUID that you need to reference when creating a scan
gvm-cli --gmp-username admin --gmp-password YOUR_PASSWORD \
socket --xml "
Metasploitable Lab Target
192.168.56.101
"Breaking it down:
Nearly 500 new vulnerability checks added since the previous feed update. That is not unusual — the security community publishes new vulnerability disclosures daily. An outdated feed means missing recently disclosed issues. Running gvm-feed-update before an engagement is not optional if you want results you can stand behind.
OpenVAS uses UUIDs — long unique identifiers — to reference every object it manages: targets, configs, tasks, reports. They look unwieldy but they are precise. When scripting scans via gvm-cli, you reference the UUID of the scan config and target rather than their human-readable names. Copy them carefully — a single wrong character breaks the reference.
The UUID returned after creating a target is what you use when creating the actual scan task. Think of it as OpenVAS confirming "I have saved this target and here is its reference number." Save this UUID — you will need it in the next step when you create and start the scan task.
Reading an OpenVAS report — separating signal from noise
A full OpenVAS scan against a target like Metasploitable will return dozens of findings — sometimes over a hundred. The immediate temptation is to start at the top and work down. Resist it. Start by looking at the shape of the results first.
If a scanner returns forty critical findings on a single host, one of two things is true: either the host is genuinely in terrible shape (which Metasploitable is, by design), or the scan has a large number of false positives. Learning to tell the difference is something that comes with experience — but two quick checks help immediately. Are multiple findings pointing at the same service with the same version? That is likely one real vulnerability being reported by several different NVTs. Are findings for services you already know are not running on that host? That is a false positive.
The structure below shows what a partial OpenVAS findings summary looks like after a scan completes — and how to read it critically rather than just accepting the numbers at face value.
A few things worth noticing in those results. The Apache version disclosure is medium severity — but we already confirmed from the curl headers in Lesson 16 that the server is also running PHP 5.2.4, which is a much more serious finding than a version string in a header. OpenVAS flagged the header; a manual check found the worse problem underneath it.
The missing security headers finding at CVSS 3.1 is real but low priority. On Metasploitable it gets buried under critical findings. On a hardened production server that has otherwise patched everything else, it might deserve more attention — because it is the kind of thing that gets left unfixed for years precisely because it is never urgent enough to prioritise.
Exporting results for the report
Both Nessus and OpenVAS can export scan results in multiple formats. The formats you will use most often are PDF for executive summaries, XML for importing into other tools like Metasploit's database, and CSV for building custom tables in a client report.
OpenVAS exports are managed through the web interface — navigate to the completed scan, click the download icon, and choose the format. The XML export in particular is useful because Metasploit's db_import command can ingest it directly, adding all discovered hosts and vulnerabilities to the Metasploit database for use during the exploitation phase.
# Import an OpenVAS XML export into the Metasploit database
# This gives Metasploit context about which hosts exist and what is running
# Making the scan data available inside msfconsole speeds up the exploitation phase
# First start the Metasploit database service (PostgreSQL)
sudo systemctl start postgresql
# Launch Metasploit console
msfconsole
# Inside msfconsole — connect to the database
db_connect
# Import the OpenVAS XML export file
# Replace the path with wherever you saved your exported scan file
db_import /root/openvas_scan_metasploitable.xml
# Verify the import worked — list all hosts found in the database
hosts
# List all services discovered across all imported hosts
servicesBreaking it down:
All 41 findings from the OpenVAS scan are now inside the Metasploit database and searchable from within msfconsole. When you search for exploits against specific services in the next phase, Metasploit can automatically match against what is already known about the target from the scan data.
The import connects the scanning phase to the exploitation phase cleanly. Instead of maintaining separate notes about what Nmap found, what OpenVAS reported, and what services exist — it all lives in one database. The exploitation phase picks up exactly where scanning left off, with the full context already in place.
Teacher's Note: Nessus Essentials is free for 16 IPs and worth installing alongside OpenVAS. Running both against the same target and comparing results is one of the best ways to understand what each scanner is good at and where each one's blind spots are. Discrepancies between the two are always worth investigating manually.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 19
Banner Grabbing
A deeper look at manual service interrogation — the techniques professionals use when automated tools are not enough and every byte of the response matters.