hack3rs.ca network-security

/learning/tools/openvas-greenbone-ce :: tool-guide-6

defender@hack3rs:~/learning/tools$ open openvas-greenbone-ce

OpenVAS / Greenbone CE

Vulnerability management

OpenVAS and Greenbone Community Edition give defenders a vulnerability management stack for recurring scans, finding triage, and remediation workflows. It is a practical platform for learning how scanning fits into a defense program.

how-to-learn-this-tool-like-a-defender

Work through the stages in order. Each one builds on the previous. Skipping straight to 'run a command' without knowing what the output means is how analysts end up misreading evidence under pressure.

$Name the specific question this tool answers — and one question it cannot answer alone.
$Run the simplest command in a lab against a host you control; read every field in the output before moving on.
$Identify which output fields are direct evidence and which are inferences the tool made on your behalf.
$Pull a second source — a log, a PCAP, a SIEM event — that either confirms or contradicts what the tool reported.
$Write down the exact command you ran, what you expected, what you got, and what you are doing next.

preflight-checklist-before-using-tool

$Confirm in writing: who authorized this, what hosts are in scope, and what the maximum acceptable impact is.
$State the question you are trying to answer — not 'run the tool' but 'confirm whether port 443 is open on 10.10.20.15'.
$Name the second source you will use if the tool output is ambiguous (log, PCAP, CMDB, another tool).
$Record the start time, the host or interface you ran it on, and the exact command — enough for another analyst to reproduce it.
$Know what normal output looks like for this host before you run anything in anger.

how-experts-read-output

$Field recognition: identify the two or three fields that directly answer your question and ignore the rest for now.
$Scope check: confirm the output covers the host, interface, and time window you intended — not a cached or adjacent result.
$Evidence type: is this a direct observation (packet captured, port open) or an inference the tool made (service guessed from banner)?
$Correlation: name the one other source — a log line, a PCAP stream, a CMDB entry — that would confirm or contradict this.
$Decision: close the question, escalate with evidence, refine the scope, or collect another source — pick one and do it.

official-links

open docs Official Greenbone Community Edition documentation user guide Greenbone documentation versions and guides community / project Greenbone project documentation portal

ethical-use-and-defense-scope

Scan only systems you own or are explicitly authorized to assess. Vulnerability scanners generate network load, trigger security alerts, and can sometimes disrupt fragile services — scope and timing both require coordination with owners.

Use scanning to drive remediation and measurable risk reduction, not to generate ticket volume or justify headcount. Good vulnerability management is collaborative, especially in environments with mixed production and legacy systems.

Treat scan credentials and scan results as sensitive data. Credentialed scans expose detailed software inventory and configuration — that is their value, but it is also a risk if the credentials or results are not handled with appropriate access controls.

tool-history-origin-and-purpose

$When created: OpenVAS emerged in 2006 after the Nessus licensing change in 2005; Greenbone later expanded it into a broader vulnerability management stack (now Greenbone Community Edition umbrella since 2022 naming).
$Why it was created: Defenders needed a free/open vulnerability scanning and management path for recurring assessments, remediation planning, and validation without depending only on proprietary tooling.

OpenVAS was created as an open-source continuation of vulnerability scanning after Nessus moved away from open-source licensing. Greenbone and contributors developed it further into a broader vulnerability management ecosystem.

why-defenders-still-use-it

People use OpenVAS / Greenbone CE because it supports recurring vulnerability management workflows, including authenticated and unauthenticated scanning, prioritization, and remediation follow-up for diverse environments.

How the tool evolved

+Started as a scanner-focused open-source fork and matured into a broader vulnerability management framework (GVM / Greenbone ecosystem).
+Greenbone expanded surrounding components for feeds, management, and reporting workflows.
+The Greenbone Community Edition naming helps distinguish open-source/community components and releases.

when-this-tool-is-a-good-fit

+Recurring vulnerability scans for internal and internet-facing assets with tracked remediation.
+Credentialed scan workflows to validate patch compliance and configuration hardening.
+Post-change validation scans to confirm remediation before closing a ticket.
+Evidence-based finding triage with asset criticality and owner assignment.

when-to-use-another-tool-or-source

!When you need host process/user context, pair with endpoint or OS logs.
!When you need ownership and business impact, pair with CMDB/ticketing/asset context.
!When the tool output is ambiguous, validate using a second evidence source before concluding.
!When production risk is high, test in a lab first and use change coordination.

1. What Vulnerability Management Tools Actually Provide

OpenVAS and Greenbone CE surface likely vulnerabilities and misconfigurations through recurring scans and provide a structured way to move from “we should probably scan things” to a repeatable process with triage, ownership, and remediation.

Scanners surface probable issues — they are not authoritative. They lack architecture knowledge, business context, and the ability to distinguish a false positive from a true finding in unusual configurations. That judgment belongs to the analyst.

The real value is the operational rhythm: scan, triage, assign, remediate, validate, repeat. The scanner is the starting point; the program is what happens around it.

2. Credentialed vs Unauthenticated Scans in Practice

Unauthenticated scans answer the question an attacker would ask: what can I see without logging in? They catch externally visible services and protocol-level weaknesses, but version detection based on banners is often imprecise.

Credentialed scans log into the host and inspect installed packages, configuration files, and local state. That depth makes them much more accurate for patch compliance and remediation planning — especially where banners are suppressed or modified.

Use both deliberately. Unauthenticated scans for exposure perspective, credentialed scans for remediation accuracy. Treating them as either/or misses most of the value from each mode.

3. Operationalizing a Vulnerability Program

A scanner produces findings. A program produces remediation. The difference is ownership, SLAs, triage workflows, exception handling, and validation steps — none of which come from the tool.

Group findings by asset criticality and exposure context, not just scanner severity. A critical finding on a decommission-scheduled dev host is a different conversation than the same finding on a customer-facing payment service. Raw severity lists rarely drive good remediation decisions.

Hold recurring reviews with system owners. New findings, overdue tickets, exceptions, and re-opened items should all be discussed together on a cadence — not left to accumulate until someone notices the backlog is unmanageable.

4. Triage, Validation, and False Positives

Scanners produce false positives, especially in environments with reverse proxies, containers, custom builds, or non-standard package management. Before escalating a high-impact remediation to a system owner, verify the finding is real.

Validation options include: checking installed package versions directly, reviewing service banners, reading vendor advisories, or testing the condition manually. The point is not to challenge the scanner — it is to make sure the remediation request is accurate and actionable.

Document confirmed false positives and revisit them quarterly. Environment changes can turn a previously false finding into a real one, and vice versa.

5. Scheduling, Scope, and Safety

Not every target tolerates the same scan intensity. Legacy systems, production databases, OT assets, and devices with limited memory may need tailored scan profiles, reduced parallelism, or coordination with owners before you run anything.

Communicate scan windows to operational teams. Routine scanner traffic that the monitoring team does not know about becomes an avoidable escalation when they see it in SIEM. A simple heads-up prevents confusion.

Build scan profiles for each environment class — internet-facing, internal servers, workstations, test systems. Reusing documented profiles improves consistency and prevents accidental over-scanning when someone runs “the standard scan” against the wrong target range.

6. Integrating Results With Remediation and Reporting

Findings should flow from the scanner into a ticketing system with ownership, severity, and due dates — not sit in an exported report that nobody re-opens. The scanner feeds a workflow; it is not the final destination.

Report on progress and risk reduction, not just finding counts. Time to triage, time to remediation by risk tier, overdue findings on critical assets, and repeat findings after supposed remediation all tell you more about program health than a raw vulnerability total.

Greenbone and OpenVAS work well as a learning platform because the finding and workflow mechanics are visible and configurable, which makes it easier to understand what a mature program does differently than a basic scan-and-export loop.

7. Learning the Tool Ethically and Effectively

Start with a lab and a few hosts you fully control. Run both an unauthenticated and a credentialed scan, compare the results, manually verify at least three findings, and practice writing a remediation note that includes evidence.

Focus on understanding why each finding appears and what would constitute valid remediation. That analytical habit is more valuable than learning to run more scans faster.

As you mature, add asset tags, criticality context, exception tracking, and verification workflows. Building a defensible process takes longer than learning the tool — and delivers the actual security value.

scenario-teaching-playbooks

Work through each scenario step by step. The goal is to practice making decisions with the tool — not just executing commands — so the workflow becomes automatic before you need it under pressure.

1. Recurring vulnerability scans for internal and internet-facing assets with tracked remediation.

Suggested starting block: Service Status And Lab Prep

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

2. Credentialed scan workflows to validate patch compliance and configuration hardening.

Suggested starting block: Credentialed Validation (Post-Scan)

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

3. Post-change validation scans to confirm remediation before closing a ticket.

Suggested starting block: Remediation Tracking Workspace

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

4. Evidence-based finding triage with asset criticality and owner assignment.

Suggested starting block: Service Status And Lab Prep

$Write the question you need to answer and the exact hosts or segments you are authorized to inspect.
$Run the first command from the selected command block; note the timestamp and interface used.
$Read the output field by field — identify what the tool confirmed versus what it inferred.
$Check a second source (host log, SIEM alert, PCAP, ticket, or CMDB record) that covers the same time window.
$Write one sentence stating your finding, your confidence level, and the next action.

cli-workflows

Lab-safe commands for authorized environments. Run each one, read the output, and note what field or value tells you something useful before moving to the next.

cli-walkthroughs-with-expected-output

One command per block, with sample output. Study the output before you run the command yourself — you should recognize what you are looking at when it appears on your screen.

Service Status And Lab Prep

Beginner

Command

sudo systemctl status ospd-openvas || true

Example Output

● gvmd.service - Greenbone Vulnerability Manager daemon
   Active: active (running)

$ how to read it: Read the key fields — host, port, protocol, state — then ask whether the output answers the question you started with. If it raises a new question instead, collect a second source before drawing a conclusion.

Credentialed Validation (Post-Scan)

Intermediate

Command

ssh admin@target "uname -a"

Example Output

Linux target-host 6.1.0-kali7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1kali1 x86_64 GNU/Linux

Remediation Tracking Workspace

Advanced

Command

mkdir -p vuln-ops/{exports,validation,notes}

Example Output

# no output — directory created successfully

command-anatomy-and-expert-usage

Each card explains what the command is for, what can go wrong, and what the output means. Syntax is easy to look up; knowing which command to reach for — and what to ignore in the output — is the skill worth building.

Service Status And Lab Prep

Beginner

Command

sudo systemctl status ospd-openvas || true

Command Anatomy

$Base command: sudo
$Primary arguments/options: systemctl status ospd-openvas || true
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Service health verification for a required component.

$ risk: Medium-High: may affect services/platform state depending on command and environment.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

● gvmd.service - Greenbone Vulnerability Manager daemon
   Active: active (running)

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service Status And Lab Prep

Beginner

Command

sudo systemctl status gvmd || true

Command Anatomy

$Base command: sudo
$Primary arguments/options: systemctl status gvmd || true
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Service health verification for a required component.

$ risk: Medium-High: may affect services/platform state depending on command and environment.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

● gvmd.service - Greenbone Vulnerability Manager daemon
   Active: active (running)

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service Status And Lab Prep

Beginner

Command

sudo systemctl status gsad || true

Command Anatomy

$Base command: sudo
$Primary arguments/options: systemctl status gsad || true
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Service health verification for a required component.

$ risk: Medium-High: may affect services/platform state depending on command and environment.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

● gvmd.service - Greenbone Vulnerability Manager daemon
   Active: active (running)

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service Status And Lab Prep

Beginner

Command

ss -tulpn | grep -E "9392|9390" || true

Command Anatomy

$Base command: ss
$Primary arguments/options: -tulpn | grep -E "9392|9390"
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

Netid  State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
tcp    LISTEN  0       128     0.0.0.0:9390        0.0.0.0:*          users:(("gvmd",pid=1234))
tcp    LISTEN  0       128     0.0.0.0:9392        0.0.0.0:*          users:(("gsad",pid=1235))
tcp    LISTEN  0       128     0.0.0.0:5432        0.0.0.0:*          users:(("postgres",pid=1100))

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Credentialed Validation (Post-Scan)

Intermediate

Command

ssh admin@target "uname -a"

Command Anatomy

$Base command: ssh
$Primary arguments/options: admin@target "uname -a"
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Collect, validate, or document evidence in a defensive workflow.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

Linux target-host 6.1.0-kali7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1kali1 x86_64 GNU/Linux

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Credentialed Validation (Post-Scan)

Intermediate

Command

ssh admin@target "cat /etc/os-release"

Command Anatomy

$Base command: ssh
$Primary arguments/options: admin@target "cat /etc/os-release"
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Collect, validate, or document evidence in a defensive workflow.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
ID=debian
HOME_URL="https://www.debian.org/"

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Credentialed Validation (Post-Scan)

Intermediate

Command

ssh admin@target "dpkg -l | grep -i openssl"   # Debian/Ubuntu example

Command Anatomy

$Base command: ssh
$Primary arguments/options: admin@target "dpkg -l | grep
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

Desired=Unknown/Install/Remove/Purge/Hold
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name             Version       Architecture  Description
ii  apache2          2.4.57-2      amd64         Apache HTTP Server
ii  openssh-server   1:9.2p1-2     amd64         secure shell (SSH) server
ii  openssl          3.0.11-1      amd64         Secure Socket Layer toolkit

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Credentialed Validation (Post-Scan)

Intermediate

Command

ssh admin@target "rpm -qa | grep -i openssl"   # RHEL-family example

Command Anatomy

$Base command: ssh
$Primary arguments/options: admin@target "rpm -qa | grep
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Quick evidence extraction from logs or command output.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

openssh-server-9.3p1-1.el9.x86_64
httpd-2.4.57-5.el9.x86_64
openssl-3.1.1-3.el9.x86_64
bind-utils-9.16.23-11.el9.x86_64
# rpm output — compare against authorized package baseline

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Remediation Tracking Workspace

Advanced

Command

mkdir -p vuln-ops/{exports,validation,notes}

Command Anatomy

$Base command: mkdir
$Primary arguments/options: -p vuln-ops/{exports,validation,notes}
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Collect, validate, or document evidence in a defensive workflow.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Baseline command: learn what normal output looks like.

Show sample output and interpretation notes

# no output — directory created successfully

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Remediation Tracking Workspace

Advanced

Command

printf "asset,finding,severity,owner,status,due
" > vuln-ops/tracker.csv

Command Anatomy

$Base command: printf
$Primary arguments/options: "asset,finding,severity,owner,status,due " > vuln-ops/tracker.csv
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Collect, validate, or document evidence in a defensive workflow.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Intermediate step: refine scope or extract more useful evidence.

Show sample output and interpretation notes

asset  finding  severity  owner  status  due
" > vuln-ops/tracker.csv

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Remediation Tracking Workspace

Advanced

Command

column -s, -t vuln-ops/tracker.csv

Command Anatomy

$Base command: column
$Primary arguments/options: -s, -t vuln-ops/tracker.csv
$Operator goal: know what answer you expect before you run it; if the output surprises you, investigate before concluding.

Use And Risk

$ intent: Collect, validate, or document evidence in a defensive workflow.

$ risk: Review command impact before running; validate in lab first if uncertain.

$ learning focus: Advanced step: use after baseline and validation are understood.

Show sample output and interpretation notes

finding  owner  action  status

$ expert reading pattern: Check that the scope matches what you intended, pick out the two or three fields that answer your question, then find one other source that confirms before you act.

Service Status And Lab Prep

sudo systemctl status ospd-openvas || true
sudo systemctl status gvmd || true
sudo systemctl status gsad || true
ss -tulpn | grep -E "9392|9390" || true

Credentialed Validation (Post-Scan)

ssh admin@target "uname -a"
ssh admin@target "cat /etc/os-release"
ssh admin@target "dpkg -l | grep -i openssl"   # Debian/Ubuntu example
ssh admin@target "rpm -qa | grep -i openssl"   # RHEL-family example

Remediation Tracking Workspace

mkdir -p vuln-ops/{exports,validation,notes}
printf "asset,finding,severity,owner,status,due
" > vuln-ops/tracker.csv
column -s, -t vuln-ops/tracker.csv

defensive-use-cases

$Recurring vulnerability scans for internal and internet-facing assets with tracked remediation.
$Credentialed scan workflows to validate patch compliance and configuration hardening.
$Post-change validation scans to confirm remediation before closing a ticket.
$Evidence-based finding triage with asset criticality and owner assignment.

common-mistakes

$Using scanner severity as the only prioritization input and ignoring asset context.
$Running scans without scheduling communication or owner coordination.
$Skipping finding validation and sending false positives to operations teams who then stop trusting the program.
$Accumulating results without a ticketing system, SLA, or owner accountability.

expert-habits-for-free-self-study

Free teaching resource. The loop that makes analysts better: ask a precise question, collect evidence, read it carefully, validate against a second source, document what you found, and repeat with a harder question.

$Pick the least disruptive command that can still answer the question — then run that one first.
$Before you look at output, write one sentence stating what you expect to see.
$Mark each output field as 'observed' or 'inferred by tool' before acting on it.
$Save the exact command with flags and target — not a paraphrase — so another analyst can run the same thing.
$During a quiet period, capture what normal output looks like from key hosts; store those samples where you can find them during an incident.
$When you escalate, include the command output, the timestamp, and one sentence on why it matters — not just 'looks suspicious'.

knowledge-check

?What question is this tool best suited to answer first?
?What permissions or scope approvals are needed before using it?
?Which second evidence source should you pair with it for higher confidence?
?What does normal output look like for your environment?

teaching-answer-guide

Show teaching hints

#Start from the tool’s role and the scenario you are investigating.
#Never rely on one tool alone for high-confidence incident decisions.
#Document normal output patterns during calm periods so anomalies are easier to spot.
#Prefer lab validation for new commands, rules, or scans before production use.

practice-plan

# Run an unauthenticated scan and a credentialed scan against the same lab host and compare the difference in findings.
# Manually validate three findings — check the installed package version or run the test yourself — and note the result.
# Build a simple tracker: asset, finding, severity, owner, due date, status.
# Define what counts as "remediated" and what validation step you will run before closing a finding.

related-learning-modules

Study the core concepts and workflows behind this tool so your usage stays evidence-driven and repeatable.

open /learning/openvas-greenbone-credentialed-vs-unauthenticated-scans OpenVAS / Greenbone Scanning: Credentialed vs Unauthenticated Scans open /learning/exploit-informed-remediation-and-asset-criticality-tagging Exploit-Informed Remediation and Asset Criticality Tagging

<- previous tool Security Onion -> next tool Hashcat