Scanning with Nessus

Vulnerability scanning is a market, and Tenable Nessus owns most of it. It is the most widely used commercial vulnerability scanner in the world, the tool whose output shows up in audit packets and board slides, and the name people mean when they say "run a Nessus scan" the way they say "google it." If OpenVAS is the open-source workhorse from the previous lesson, Nessus is its commercial twin: the same fundamental job — probe a target, match what it finds against a database of known weaknesses, rank the results — wrapped in a more polished interface and fed by a continuously curated plugin feed.

You do not need a corporate budget to learn it. Nessus Essentials is free for scanning up to 16 IP addresses, which makes it the way most people get hands-on with the tool for the first time. Sixteen hosts is plenty to learn on — a small lab, a home network, a handful of servers — and the interface and plugin engine are the same ones the paid tiers use, so what you learn here transfers directly to the professional product.

Nessus does not "know" vulnerabilities in the abstract. Every check it runs is a plugin — a small, self-contained module that tests for exactly one issue. There are tens of thousands of them, and Tenable updates the feed continuously as new vulnerabilities are disclosed, so a scanner that pulled its feed yesterday already knows about things that did not exist last week. Plugins are the direct equivalent of OpenVAS's NVTs (Network Vulnerability Tests): the same idea — one downloadable check per known weakness — under a different name.

Each plugin carries more than a yes/no answer. When a plugin fires, it reports the severity of what it found, the CVE identifiers that tie the finding to the public vulnerability record, and a remediation — the patch, configuration change, or upgrade that closes the hole. That bundling is what turns a raw detection into something a defender can act on: not just "this host is vulnerable," but "this host is vulnerable to this CVE, at this severity, and here is how to fix it."

Plugins are grouped into families — Windows, Web Servers, Databases, SCADA, and dozens more — which matters later when you tune a scan. Disabling a family you know is irrelevant to the target (no databases? skip the database family) makes scans faster and quieter without losing coverage that mattered.

You almost never start a Nessus scan from a blank page. Instead you pick a template — a preconfigured starting point that decides which plugins run and how the scan behaves. The ones you reach for constantly:

• Basic Network Scan — the general-purpose default. Discovers live hosts, enumerates open ports and services, and runs a broad sweep of safe checks against whatever it finds. Where most people start.
• Advanced Scan — the same engine with every dial exposed. No baked-in assumptions; you choose ports, plugin families, timing, and depth by hand. The template you graduate to when the defaults are not specific enough.
• Web Application Tests — focused on web-layer issues: injection points, outdated components, misconfigurations, and exposed admin interfaces on HTTP and HTTPS services.
• Compliance / audit templates — instead of asking "is this exploitable?" they ask "does this match the required configuration?" against a benchmark, producing pass/fail evidence for a standard rather than a vulnerability list.

Choosing the template is half the decision; the other half is tuning the policy — the saved set of settings the scan actually runs with. A policy is where you narrow the port range (scan the full range only when you have reason to), enable or disable plugin families to match the target, and set performance controls — how many hosts and checks run in parallel, and how aggressively the scanner pushes. Turn performance up and the scan finishes faster but hits the network and the hosts harder; turn it down and you trade time for a gentler footprint. The right setting depends entirely on what you are scanning and how fragile it is.

Of every setting in Nessus, one decides the quality of your results more than all the others combined: does the scan log in, or not? This is the same fork you met with OpenVAS, and it is worth reinforcing because people get it wrong constantly.

An uncredentialed scan stays outside. It pokes at the target over the network — open ports, exposed services, banners, anything reachable without authenticating — and infers vulnerabilities from what it can see from the curb. It is the attacker's-eye view, and it is genuinely useful, but it is also guessing from the outside. A patched and an unpatched server can look identical from the network, so an uncredentialed scan misses a great deal and reports more uncertainly.

A credentialed (authenticated) scan is handed valid login credentials and goes inside. It logs in over SSH, SMB, or a similar channel and reads the host directly: exactly which software is installed, which versions, which patches are present and which are missing, and how the system is configured. Because it reads ground truth instead of inferring it, a credentialed scan is dramatically more accurate and complete — it catches the missing patch that an outside scan could only have guessed at, and it catches far less of the network noise as false alarms.

The practical rule: if you can get credentials, use them. An authenticated scan turns a vague external sketch into a precise inventory of what is actually wrong, and the gap between the two is not small — it is often the difference between a handful of guessed findings and a complete, defensible list.

A finished scan hands you a sorted list, and Nessus ranks every finding into one of five severity tiers: Critical, High, Medium, Low, and Info. Critical and High are where you start — the issues most likely to get a host owned — while Info findings are not vulnerabilities at all but facts the scan gathered (a detected service, a software version) that are still useful context. Triage from the top down; a hundred Lows rarely matter as much as one Critical.

Severity tells you how bad; the plugin output tells you why the scanner believes it. Expanding a finding shows the evidence the plugin collected — the version string it read, the banner it saw, the response that revealed the flaw. That evidence is what separates a real finding from a guess, and it is the first thing you check before you put a finding in a report. A scanner result you cannot explain is a scanner result you cannot defend.

Nessus also scores findings with Tenable's VPR (Vulnerability Priority Rating), and it is worth understanding why it exists. The familiar CVSS score rates a vulnerability's theoretical severity in isolation. VPR is exploit-aware: it layers in real-world threat data — whether exploit code exists, whether the flaw is being attacked in the wild right now, how the threat is trending — so a vulnerability with a moderate CVSS but active exploitation can rank above one with a scarier raw score that nobody is actually using. When VPR and CVSS disagree, VPR is usually the better answer to "what should I fix first?"

When the analysis is done, Nessus exports: PDF for a human-readable deliverable, CSV for slicing the data or feeding a tracking system, and HTML for sharing in a browser. The export is the raw material for the report — but it is raw material, not the report itself, because the scanner does not know which findings are real, which are false alarms, and which actually matter to this organization. That judgment is yours.