Ein einmaliger Schwachstellenscan löst kein Problem, erst ein wiederholbarer Prozess schafft Sicherheit. Diese Anleitung baut ihn auf: Sie richten Greenbone Community Edition (GCE, mit dem Scanner OpenVAS) per Docker ein, konfigurieren authentifizierte Scans, reduzieren umfangreiche Reports auf eine Prioritätenliste und exportieren Berichte als Nachweis für NIS2-Prüfungen und Cyber-Versicherungen.

Voraussetzungen

Linux-Server oder VM (Debian 12/13 oder Ubuntu 24.04 LTS, x86_64), mindestens 2 CPU-Kerne, 4 GB RAM, 20 GB Speicher; empfohlen laut Greenbone: 4 Kerne, 8 GB RAM, 60 GB
Docker Engine mit Compose-Plugin v2 (docker compose), installiert aus dem offiziellen Docker-Repository
Internetverbindung für den initialen Feed-Download (mehrere GB) und regelmäßige Updates
Netzwerkzugang des Scanner-Hosts zu allen Zielsystemen (keine Firewall-Blockierung auf Scan-Ports)
Dedizierte Scan-Accounts auf Zielsystemen: Linux-SSH-Account mit sudo-Rechten, Windows-Domänenaccount mit lokalen Administratorrechten
Statische IP-Adresse für den Scanner-Host oder fester DNS-Eintrag
Backup-Konzept für die GCE-Instanz (PostgreSQL-Datenbank enthält alle Scan-Historien)

Schritt 1: Docker installieren und Arbeitsverzeichnis anlegen

Installieren Sie Docker Engine und das Compose-Plugin nach der offiziellen Docker-Anleitung oder nach Docker und Docker Compose auf Linux installieren. Das Paket docker-compose-plugin gibt es nur im Docker-Repository, nicht in den Standardquellen von Debian. Danach fügen Sie Ihren Benutzer der Gruppe docker hinzu und laden die aktuelle compose.yaml von Greenbone:

# Benutzer der Gruppe docker hinzufügen (neue Shell übernimmt die Gruppe)
sudo usermod -aG docker $USER && su $USER

# Arbeitsverzeichnis anlegen und compose.yaml herunterladen
export DOWNLOAD_DIR=~/greenbone-community
mkdir -p $DOWNLOAD_DIR
curl -f -L https://greenbone.github.io/docs/latest/_static/compose.yaml \
  -o $DOWNLOAD_DIR/compose.yaml

Die offizielle compose.yaml enthält die nötigen Capabilities (NET_ADMIN, NET_RAW) für den Scanner. Laden Sie sie immer von der Greenbone-Dokumentation; selbst geschriebene Dateien lassen oft Capabilities weg, was zu Scans ohne Ergebnis führt.

Verifizieren: docker compose version meldet v2.x, docker ps läuft ohne sudo, und grep -c image: $DOWNLOAD_DIR/compose.yaml liefert eine Zahl größer 15.

Schritt 2: Container-Images herunterladen und Feed-Daten laden

GCE besteht aus mehreren Diensten: OpenVAS Scanner (führt NVTs aus), Notus (vergleicht installierte Pakete), gvmd (Verwaltung, PostgreSQL, Zeitpläne) und der Weboberfläche GSA hinter einem Nginx-Container.

# Container-Images herunterladen
docker compose -f $DOWNLOAD_DIR/compose.yaml pull

# Feed-Daten-Container starten (lädt NVT, SCAP, CERT-Bund-Daten)
docker compose -f $DOWNLOAD_DIR/compose.yaml up -d \
  notus-data vulnerability-tests scap-data \
  dfn-cert-data cert-bund-data report-formats data-objects

# Alle Services starten
docker compose -f $DOWNLOAD_DIR/compose.yaml up -d

# Logs verfolgen – warten bis Feed vollständig geladen
docker compose -f $DOWNLOAD_DIR/compose.yaml logs -f

Wichtig: Das erste Laden der Feeds (NVTs, SCAP- und CERT-Bund-Daten) dauert 30 bis 60 Minuten. Starten Sie keinen Scan, bevor alle Feeds „Current“ zeigen, sonst fehlen Befunde.

Verifizieren: docker compose -f $DOWNLOAD_DIR/compose.yaml ps zeigt gvmd, ospd-openvas, gsa und nginx als „Up“; die Feed-Container dürfen den Status „Exited (0)“ haben. Im Log von gvmd erscheinen Meldungen wie „Port list All IANA assigned TCP … has been created“.

Schritt 3: Passwort ändern und Netzwerkzugang konfigurieren

Das Standard-Login ist admin / admin. Ändern Sie das Passwort sofort, bevor Sie die Oberfläche im Netz freigeben:

# Admin-Passwort sofort ändern
docker compose -f $DOWNLOAD_DIR/compose.yaml \
  exec -u gvmd gvmd \
  gvmd --user=admin --new-password='IhrSicheresPasswort'

Der Container nginx veröffentlicht die Oberfläche standardmäßig nur auf 127.0.0.1 (HTTPS auf 443, HTTP auf 9392). Am einfachsten erreichen Sie sie vom Admin-PC per SSH-Tunnel: ssh -L 8443:127.0.0.1:443 benutzer@scanner, dann https://localhost:8443. Für dauerhaften Zugriff binden Sie den Port an die interne IP-Adresse des Scanners statt an alle Schnittstellen:

# compose.yaml, Service nginx: nur an die interne Scanner-IP binden
    ports:
      - "192.168.1.20:443:443"
      - "127.0.0.1:9392:9392"

Stellen Sie die Oberfläche nie direkt ins Internet, nur über VPN oder einen Jump-Host. Beachten Sie: Von Docker veröffentlichte Ports umgehen UFW-Regeln, deshalb ist die Bindung an eine bestimmte IP-Adresse entscheidend. Den Host selbst sichern Sie wie in Linux-Server absichern mit UFW und Fail2ban beschrieben.

Verifizieren: Die Anmeldung mit admin und dem neuen Passwort gelingt, admin / admin wird abgelehnt. Unter Administration → Feed Status zeigen alle Feeds „Current“. ss -tlnp | grep ':443' zeigt nur 127.0.0.1 bzw. die interne IP, nicht 0.0.0.0.

Schritt 4: Authentifizierten Scan einrichten

Authentifizierte Scans finden lokale Schwachstellen wie fehlende Patches und Fehlkonfigurationen, die ein Scan ohne Anmeldung nicht sieht. Die Einrichtung erfolgt in der Weboberfläche GSA.

Scan-Credentials anlegen

Öffnen Sie Configuration → Credentials → New Credential:

Linux-Hosts: Typ „Username + SSH Key“. Legen Sie einen eigenen Account gvmscan an, nur SSH-Key-Authentifizierung, sudo NOPASSWD nur für paketlistende Befehle (dpkg, rpm). Niemals Root-Credentials verwenden.
Windows-Hosts: Typ „Username + Password“ mit SMB, Domänenaccount oder lokaler Admin-Account. Auch hier: dedizierter Account, nicht der Produktions-Admin.

Sicherheitshinweis: GCE speichert Credentials in der PostgreSQL-Datenbank. Bei Kompromittierung der Scanner-Instanz wären alle gespeicherten Zugangsdaten exponiert. Verwenden Sie nur eigene Scan-Accounts mit minimalen Rechten. SSH-Schlüssel richten Sie wie in SSH-Key-Authentifizierung einrichten ein.

Scan-Target erstellen

Öffnen Sie Configuration → Targets → New Target:

Hosts: CIDR-Notation wie 192.168.1.0/24 oder einzelne IPs
Port List: „All IANA assigned TCP“ (mit UDP dauert der Scan deutlich länger)
SSH Credentials / SMB Credentials: zuvor angelegtes Credential zuweisen

Scan-Task erstellen und planen

Öffnen Sie Scans → Tasks → New Task:

Scan Config: „Full and fast“. Sie arbeitet mit aktivierten „safe checks“, die keine absturzgefährdenden Tests ausführen. Deaktivieren Sie „safe checks“ auf Produktivsystemen nicht.
Scanner: „OpenVAS Default“
Schedule: Kritische Systeme wöchentlich (z. B. montags 02:00 Uhr), Standard-Systeme monatlich, nach großen Infrastrukturänderungen anlassbezogen

Verifizieren: Starten Sie den Task einmal manuell. Nach Abschluss steht er auf „Done“; der Report enthält für Linux-Ziele Befunde zu fehlenden Paketupdates (lokale Sicherheitsprüfungen), und der Log-Befund „SSH Login Failed For Authenticated Checks“ fehlt.

Schritt 5: Befunde priorisieren statt im Report ertrinken

Ein Scan eines /24-Netzes kann mehrere tausend Befunde liefern, überwiegend „Log“-Einträge ohne Handlungsbedarf. So gehen Sie vor:

CVSS-Filter anwenden

Öffnen Sie Scans → Reports, wählen Sie den aktuellen Bericht und geben Sie in der Filterzeile ein:

severity>6.9

Dieser Filter zeigt nur High- (CVSS 7,0–8,9) und Critical-Findings (CVSS 9,0–10,0). Die Liste schrumpft dadurch meist auf einen kleinen Teil der Gesamtbefunde.

CVSS-Schwellenwerte im Überblick

Schweregrad	CVSS v3.1	Empfohlene Reaktionszeit
Critical	9,0 – 10,0	Sofort (24–72 Stunden)
High	7,0 – 8,9	Innerhalb 7–14 Tage
Medium	4,0 – 6,9	Nächster Patch-Zyklus
Low	0,1 – 3,9	Risikoakzeptanz prüfen
Informational	0,0	Aus Arbeits-Report filtern

Kontext vor CVSS-Score

Ein CVSS 9,8 auf einem nicht erreichbaren internen System ist oft weniger dringend als ein CVSS 7,5 auf einem internet-exponierten Webserver. Priorisieren Sie nach diesem Schema: Internet-exponierte Systeme → interne Server → Workstations. Ergänzen Sie CVSS durch den EPSS-Score (Exploit Prediction Scoring System, Wahrscheinlichkeit einer Ausnutzung) und den CISA-KEV-Katalog bereits aktiv ausgenutzter Lücken.

Verifizieren: Mit gesetztem Filter zeigt der Report nur Befunde mit Severity ab 7,0. Jeder dieser Befunde hat in Ihrer Prioritätenliste einen Verantwortlichen und ein Zieldatum gemäß Tabelle.

Schritt 6: Remediation-Workflow und revisionssichere Dokumentation

Der Scan-Prozess ist erst vollständig, wenn Befunde nachverfolgt und dokumentiert werden.

Befunde in GCE verwalten

Overrides: Schweregrad anpassen, wenn der Kontext einen niedrigeren Rang rechtfertigt (z. B. Vulnerability existiert, ist aber durch Netzwerksegmentierung nicht ausnutzbar)
Suppress/False Positive: Bekannte False Positives markieren, damit sie nicht bei jedem Scan wieder auftauchen
Notes: Remediation-Status und Verantwortlichen dokumentieren

Reports exportieren

# Im Report: Download-Symbol, Format PDF oder XML wählen
# Dateinamen-Konvention für Archivierung:
scan_intern_2026-06-01.pdf
scan_intern_2026-06-01.xml

PDF: Für Geschäftsführung, NIS2-Prüfer und Versicherungsaudits – enthält Zeitstempel, CVSS-Scores und Zusammenfassung
XML: Für technische Weiterverarbeitung, Import in Ticketsysteme oder SIEM

NIS2-konforme Dokumentation

Als Minimalset für den Nachweis nach NIS2 Artikel 21: PDF-Reports nach jedem Scan mit Datum archivieren, Behebungsstatus dokumentieren (was bis wann behoben, was als Risiko akzeptiert) und Scan-Frequenz sowie Umfang in einer Betriebsanweisung festhalten. Welche Nachweise Ihr Versicherer verlangt, klären Sie mit ihm direkt.

Feed automatisch aktualisieren

Ohne Update erkennt der Scanner neue CVEs nicht. Richten Sie einen wöchentlichen Cron-Job ein:

# Feed-Container wöchentlich aktualisieren (z. B. sonntags 01:00 Uhr)
docker compose -f ~/greenbone-community/compose.yaml pull \
  notus-data vulnerability-tests scap-data \
  dfn-cert-data cert-bund-data report-formats data-objects
docker compose -f ~/greenbone-community/compose.yaml up -d \
  notus-data vulnerability-tests scap-data \
  dfn-cert-data cert-bund-data report-formats data-objects

Verifizieren: Im Ablageordner liegen PDF und XML des letzten Scans mit Datum im Dateinamen; nach dem ersten Cron-Lauf zeigt Administration → Feed Status ein aktuelles Datum.

GCE vs. Nessus: Entscheidungsmatrix

Kriterium	Greenbone CE	Nessus Essentials	Nessus Professional
Lizenz	Open Source	kostenlos, max. 16 IP-Adressen	kommerzielles Jahresabo
NVT-Umfang	>120.000 NVTs	eingeschränkt	sehr umfangreich
Authentifizierte Scans	SSH, SMB, ESXi	SSH, SMB	30+ Credential-Typen
BSI-Bezug	Entwicklung vom BSI gefördert	Nein	Nein
Setup-Aufwand	Mittel (Docker/Linux)	Gering	Gering
Compliance-Policies	Nur Enterprise Feed	Nein	PCI-DSS, CIS u. a.
Zielgruppe	KMU mit Linux-Know-how	Kleinstumgebungen	Mittlere Unternehmen+

Troubleshooting / Typische Fehler

Kaum oder keine Findings trotz bekannter Schwachstellen: Feed noch nicht vollständig geladen. Administration → Feed Status prüfen, alle Feeds müssen „Current“ zeigen.
Scan läuft, aber ohne Anmeldung am Ziel: Credentials falsch konfiguriert oder Scan-Account hat unzureichende Rechte. Im Report die Host-Details prüfen, SSH-Verbindung manuell testen: ssh gvmscan@zielhost.
Scanner startet nicht / leere Ergebnisse ohne Fehlermeldung: Fehlende Netzwerk-Capabilities. Prüfen Sie in der compose.yaml, ob cap_add: [NET_ADMIN, NET_RAW] für den ospd-openvas-Service vorhanden ist.
Weboberfläche vom Admin-PC nicht erreichbar: Port ist weiterhin nur an 127.0.0.1 gebunden. SSH-Tunnel nutzen oder Port an die interne IP binden (Schritt 3) und docker compose up -d ausführen.
Feed veraltet / Status „Outdated“: Feed-Container wurden nicht aktualisiert. docker compose pull für die Feed-Container ausführen und anschließend neu starten.
Dienst nach Scan abgestürzt: „safe checks“ deaktiviert oder empfindliches Altsystem. „Full and fast“ mit safe checks verwenden, empfindliche Systeme außerhalb der Geschäftszeit scannen.

Häufige Fragen

Was ist der Unterschied zwischen einem Vulnerability Scan und einem Pentest?

Ein Vulnerability Scan ist automatisiert, nicht-destruktiv und prüft Systeme auf bekannte Schwachstellen-Signaturen. Er erkennt konfigurierte Lücken, versucht aber keine Exploitation. Ein Pentest beinhaltet manuelle Angriffstechniken, das Verketten von Schwachstellen und tatsächliche Exploitation ; er beantwortet nicht „Was ist anfällig?“, sondern „Was ist tatsächlich ausnutzbar?“. Regelmäßiges Scannen ist die Basis, ein Pentest ergänzt es.

Wie gehe ich mit 5000 Findings im Report um?

Filter severity>6.9 setzen und nach Erreichbarkeit priorisieren (siehe Schritt 5): Systeme mit Internetzugang zuerst, dann interne Server, dann Arbeitsplätze.

Welche Credentials benötigt ein authentifizierter Scan auf Linux-Hosts?

Einen eigenen Account gvmscan mit SSH-Schlüssel, ohne Root. sudo NOPASSWD nur für paketlistende Befehle (dpkg -l, rpm -qa).

Benötigt ein KMU ohne eigenes SOC einen eigenen Scanner oder genügt SaaS?

Für rein internet-exponierte Assets genügen SaaS-Lösungen wie der Greenbone Cloud Service. Für interne Netzwerke und authentifizierte Scans ist ein lokaler Scanner erforderlich, da SaaS-Dienste keinen Zugriff auf das interne Netz haben. Greenbone CE per Docker eignet sich für KMU mit Linux-Kenntnissen.

Wie lässt sich der Scan-Prozess NIS2-konform dokumentieren?

Reports als PDF und XML mit Datum archivieren, Behebungsstatus und akzeptierte Risiken (Overrides) dokumentieren, Frequenz und Umfang in einer Betriebsanweisung festhalten (siehe Schritt 6).

OpenVAS/GCE oder Nessus – was ist besser für ein KMU?

Für Teams mit Linux-Kenntnissen ist GCE eine solide Wahl: Open Source, über 120.000 NVTs, Entwicklung vom BSI gefördert. Nessus Professional bietet mehr Credential-Typen und Berichtsvorlagen für die Geschäftsführung. Nessus Essentials ist für bis zu 16 IP-Adressen kostenlos und eignet sich für erste Tests.

Fazit

Greenbone Community Edition ist ein praxistauglicher Einstieg ins Schwachstellenmanagement für KMU. Der Nutzen entsteht durch den Prozess: authentifizierte Scans, CVSS-Filter für die Priorisierung, archivierte Exporte für NIS2 und Versicherer und ein Cron-Job für aktuelle Feeds. So belegen Sie bei der nächsten Prüfung, dass Schwachstellen systematisch erkannt und behoben werden.

Den Scanner-Host härten Sie mit Linux-Server härten nach CIS-Benchmark ; für aktuelle Patches auf den Zielsystemen sorgt Unattended Upgrades: automatische Sicherheitsupdates unter Debian/Ubuntu.

Weiterführende Anleitungen und Quellen

Quellen: Greenbone Community Containers – Offizielle Dokumentation | Greenbone Community Workflows | BSI – OpenVAS-Empfehlung | OpenVAS vs. Nessus – Beagle Security 2025