13.5 Your first network scan

You have a scanner. Now you point it at your own lab and find out what a stranger on your network could learn about it.

First, decide what you are allowed to scan

This is not a formality, and I want you to do it in the right order at least once, because in a job the order is the whole thing.

Your lab is 10.10.10.0/24. Every machine in it is yours. Nothing else on your home network is in scope, and your internet provider's equipment certainly is not.

Write the range down before you open the tool, because the moment you are in a wizard clicking Next, a typo like 10.10.0.0/16 looks almost identical to the right answer and covers 65,536 addresses instead of 254. A scanner does what you tell it, fast, and it does not ask whether you meant it.

In a real engagement this step is a document with signatures on it, called a scope or a rules of engagement. It says which addresses, which dates, which techniques, and who to phone when something falls over. Module 14 makes you write one properly. Today it is one line in your journal, and the habit is what matters.

Set up the scan

Working in the Greenbone web interface at https://10.10.10.20:9392.

The vocabulary is worth learning because it is nearly universal across scanners of this kind:

• Target is what you are scanning: a name plus a list of addresses.
• Task is what you are going to do to it: a target plus a scan configuration plus a schedule.
• Report is the result of one run of a task.

That separation exists so you can scan the same target monthly and compare reports, which is the "how long has this been open" question from lesson 13.1.

Create a target covering your lab. Under Configuration > Targets, create a new one:

• Name: Lab network
• Hosts: 10.10.10.0/24
• Leave everything else at its defaults for now. Credentials come in 13.6.

Create a task. Under Scans > Tasks, create a new task:

• Name: Lab full scan
• Scan Targets: the Lab network target you just made
• Scan Config: Full and fast. This is the sensible default and the name is honest: it runs a lot of tests and skips the slowest ones.

Then start it.

What to expect while it runs

This takes a while, in the tens of minutes for a small lab, and the progress percentage moves unevenly. That is normal; some hosts have far more to test than others.

Two things you should watch for, because they are the interesting part:

Your monitoring stack should be lighting up. You built detections in Module 12 and this is a scanner sweeping your entire network. If your Wazuh dashboard is quiet during a full-network vulnerability scan, that is worth knowing about, and it is a finding about your detection rather than about your hosts.

Things may briefly break. A vulnerability scanner tests for weaknesses by poking at services in ways they do not expect. Occasionally something falls over. On your lab that is a free lesson. In production this is why scans run in maintenance windows and why "we scanned it and the payment system restarted" is a conversation people have had.

Read the report

When the task finishes, open the report. You will see findings grouped by host, each with a severity and a description.

Before you read a single finding, ask the question from lesson 13.1: what kind of scan was this? Network surface, unauthenticated. It saw what a stranger on your LAN sees. That is a genuinely useful viewpoint, and it is also the least complete of the three.

Two consequences you should look for in your own report:

Findings based on version banners. Many will say something like "the remote service reports version X, which is affected by...". The scanner did not verify the flaw. It read a version string and looked it up. That is why this class of scan produces false positives: a distribution that backports security fixes keeps the old version number while fixing the bug, and the scanner has no way to see that.

A suspiciously clean host. A machine with almost nothing listening looks healthy in this report and might be full of vulnerable software that simply is not exposed to the network. Absence of findings here is absence of exposure, not absence of vulnerability.

That gap is precisely what lesson 13.6 closes.

Get it out of the tool

A report you can only read in a web interface is a report you cannot ask questions of. Export it and put it next to your image findings from 13.3.

Use the report's export function to download it as CSV. Greenbone offers several formats; CSV is the one that goes into a database without a fight.

Then, on UBNT01:

# Look at what the columns actually are, because they vary by
# format version and guessing wastes time.
head -1 ~/lab-scan.csv

Load it alongside your existing tables. The column list below is from the export I used; check yours against that head -1 output and adjust the CREATE TABLE to match, because a mismatch is how you get every value in the wrong column.

sqlite3 ~/vuln.db <<'SQL'
CREATE TABLE IF NOT EXISTS netfindings(
  ip TEXT, hostname TEXT, port TEXT, severity TEXT,
  cve TEXT, name TEXT
);
.mode csv
.import /home/sam/lab-scan.csv netfindings
SQL

How you know it worked:

# Rows, and a per-host count so you can sanity-check against
# the number of machines you actually have.
sqlite3 -header -column ~/vuln.db \
  "SELECT ip, COUNT(*) AS findings FROM netfindings GROUP BY ip ORDER BY findings DESC;"

If every row landed in one column, the CSV had a different shape than the table. DROP TABLE netfindings; and rebuild it to match your head -1.

Now ask the question that matters

Same question as lesson 13.3, now about whole machines rather than one image:

sqlite3 -header -column ~/vuln.db \
  "SELECT DISTINCT n.ip, n.cve, n.name
   FROM netfindings n
   JOIN kev k ON n.cve = k.cve
   ORDER BY n.ip;"

An empty result is a good result and a real one. Your lab is built from current software that you installed a few modules ago, so there may genuinely be nothing in the KEV catalog on it. That is what a healthy environment looks like, and seeing it once is useful: you now know the query works and returns nothing when there is nothing to return, which is the property lesson 13.1's "a check must be able to fail" depends on.

If you did get rows, those are the most important findings in your lab, and lesson 13.7 is about fixing them.

Make it yours

1. Compare the two viewpoints. Your image scan in 13.3 found hundreds of package vulnerabilities. Did this network scan find any of the same CVEs? Almost certainly not, and the reason is the whole of lesson 13.1.
2. Scan one host with the scanner running against itself. Add 10.10.10.20 alone as a target. UBNT01 is the machine running the scanner, which is a slightly odd thing to do and a good way to see how much more a scanner sees when there is no network in the way.

What you take from this

A full network scan of your own lab, a report you exported and questioned rather than admired, and a clear sense of what an unauthenticated scan can and cannot see.

Next lesson you give it credentials, and the picture changes completely.