Wer im KMU-Umfeld ernsthaft Schwachstellenmanagement betreiben will, stolpert schnell über eine unbequeme Wahrheit: Ein einmaliger Scan löst kein Problem – erst ein wiederholbarer Prozess schafft Sicherheit. Genau diesen Prozess baut diese Anleitung auf: Du richtest Greenbone Community Edition (die Open-Source-Plattform, die früher als OpenVAS bekannt war) per Docker ein, konfigurierst authentifizierte Scans, reduzierst 5000-Finding-Reports auf eine handhabbare Prioritätenliste und exportierst revisionssichere Berichte – als Nachweis gegenüber NIS2-Prüfern und Cyber-Versicherungen.

Voraussetzungen

Linux-Server oder VM (Debian 12 oder Ubuntu 22.04/24.04 LTS empfohlen), mindestens 2 CPU-Kerne, 4 GB RAM, 20 GB freier Disk – empfohlen: 4 Kerne, 8 GB RAM, 60 GB für Feed-Daten
Docker Engine >= 23.x und das docker-compose-plugin (nicht das veraltete docker-compose v1)
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

Installiere zunächst Docker und das Compose-Plugin auf deinem Debian/Ubuntu-Server. Melde dich danach neu an, damit die Gruppenmitgliedschaft greift.

# Docker und docker-compose-plugin installieren (Debian/Ubuntu)
sudo apt-get update && sudo apt-get install -y docker.io docker-compose-plugin
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/docker-compose-22.4.yml \
  -o $DOWNLOAD_DIR/compose.yaml

Die offizielle compose.yaml von Greenbone enthält bereits alle notwendigen Netzwerk-Capabilities (NET_ADMIN, NET_RAW) für den Scanner. Lade sie stets von der offiziellen Dokumentationsseite herunter – eigenhändig geschriebene Compose-Dateien lassen oft Capabilities weg, was zu stillen Scan-Fehlern führt.

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

GCE besteht aus mehreren Microservices: dem OpenVAS Scanner (NVT-Ausführung), dem Notus Scanner (Paketvergleich), dem gvmd-Daemon (PostgreSQL-Datenbank, Scheduling) und der GSA-Weboberfläche. Alle Images werden zunächst gepullt, dann werden die Feed-Container gestartet.

# 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: Die Feed-Erstbefüllung (über 120.000 NVTs plus SCAP- und CERT-Bund-Daten) dauert 30 bis 60 Minuten. Starte keinen Scan, bevor alle Feeds den Status „Current" zeigen – du erhältst sonst kaum Findings, auch wenn bekannte Schwachstellen vorhanden sind.

Schritt 3: Passwort ändern und Netzwerkzugang konfigurieren

Das Standard-Login ist admin / admin. Ändere das Passwort sofort per Kommandozeile, bevor du das Interface ins Netz freigibst:

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

Für Netzwerkzugriff (z. B. vom Admin-PC) musst du das Port-Binding in der compose.yaml anpassen:

# compose.yaml – Port-Binding anpassen (nur über VPN/Jump-Host exponieren!)
# Vorher (nur localhost):
#   ports:
#     - "127.0.0.1:9392:80"
# Nachher (Netzwerkzugriff):
    ports:
      - "9392:80"

Exponiere das Interface niemals direkt ins Internet – nur über VPN oder einen Jump-Host. Setze zusätzlich eine UFW-Regel, die Port 9392 nur für dein Admin-Subnetz freigibt. Wie du UFW richtig konfigurierst, erklärt die Anleitung Linux-Server absichern mit UFW und Fail2ban.

Prüfe vor dem ersten Scan den Feed-Status im Browser unter http://<server-ip>:9392/feedstatus – alle Feeds müssen „Current" anzeigen.

Schritt 4: Authentifizierten Scan einrichten

Der entscheidende Qualitätssprung: Authentifizierte Scans finden lokale Schwachstellen wie fehlende Patches und Fehlkonfigurationen, die unauthentifizierte Scans komplett übersehen. Die Einrichtung erfolgt vollständig im GSA-Webinterface.

Scan-Credentials anlegen

Navigiere zu Configuration → Credentials → New Credential:

Linux-Hosts: Typ „Username + SSH Key" – lege einen dedizierten System-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. Verwende ausschließlich dedizierte, minimal-privilegierte Scan-Accounts. Wie du SSH-Key-Authentifizierung sicher einrichtest, zeigt die Anleitung SSH-Key-Authentifizierung einrichten.

Scan-Target erstellen

Navigiere zu Configuration → Targets → New Target:

Hosts: CIDR-Notation wie 192.168.1.0/24 oder einzelne IPs
Port List: „All IANA assigned TCP and UDP"
SSH Credentials / SMB Credentials: zuvor angelegtes Credential zuweisen

Scan-Task erstellen und planen

Navigiere zu Scans → Tasks → New Task:

Scan Config: „Full and Fast" – für Produktivsysteme immer diese Variante. Nie „Full and Fast Ultimate" auf produktiven Systemen – diese Konfiguration kann Dienste zum Absturz bringen.
Scanner: „OpenVAS Default"
Schedule: Kritische Systeme wöchentlich (z. B. montags 02:00 Uhr), Standard-Systeme monatlich, nach großen Infrastrukturänderungen anlassbezogen

Schritt 5: Befunde priorisieren statt im Report ertrinken

Ein vollständiger Scan eines Klasse-C-Netzes kann 5000+ Findings liefern. Die meisten davon sind „Informational"-Einträge ohne echten Handlungsbedarf. So arbeitest du systematisch:

CVSS-Filter anwenden

Navigiere zu Scans → Reports, wähle den aktuellen Bericht und gib 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). Typischerweise reduziert das die sichtbare Liste auf 5–20 % 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. Priorisiere nach diesem Schema: Internet-exponierte Systeme → interne Server → Workstations. Ergänze CVSS durch den EPSS-Score (Exploit Prediction Scoring System), der die tatsächliche Ausnutzungswahrscheinlichkeit abbildet.

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-View: Download-Icon → "PDF" oder "XML"
# 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

Für den Nachweis nach NIS2 Artikel 21 (technische Maßnahmen) reicht folgendes Minimalset: Exportierte PDF-Reports nach jedem Scan mit Datum archivieren, Remediation-Status dokumentieren (welche Findings wurden bis wann behoben, welche als akzeptiertes Risiko eingestuft), Scan-Frequenz und Scope schriftlich in einer Betriebsanweisung festhalten. Dieses Vorgehen genügt auch für Cyber-Versicherungsaudits.

Feed automatisch aktualisieren

Die NVT-Daten veralten sonst – neue CVEs werden nicht erkannt. Richte einen 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
docker compose -f ~/greenbone-community/compose.yaml up -d \
  notus-data vulnerability-tests scap-data \
  dfn-cert-data cert-bund-data

GCE vs. Nessus: Entscheidungsmatrix

Kriterium	Greenbone CE	Nessus Essentials	Nessus Professional
Kosten	Kostenfrei	Kostenfrei (max. 16 Hosts)	ca. 3.390 USD/Jahr
NVT-Umfang	>120.000 NVTs	eingeschränkt	sehr umfangreich
Authentifizierte Scans	SSH, SMB, ESXi	SSH, SMB	30+ Credential-Typen
BSI-Empfehlung	Ja	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 synchronisiert. Prüfe /feedstatus im Browser – alle Feeds müssen „Current" zeigen. Warte 30–60 Minuten nach dem ersten Start.
Scan läuft, aber „Authenticated Scan: no" im Report: Credentials falsch konfiguriert oder Scan-Account hat unzureichende Rechte. Im Report unter „Host Details" den Authentifizierungsstatus prüfen. SSH-Verbindung manuell testen: ssh gvmscan@zielhost.
Scanner startet nicht / leere Ergebnisse ohne Fehlermeldung: Fehlende Netzwerk-Capabilities. Prüfe in der compose.yaml, ob cap_add: [NET_ADMIN, NET_RAW] für den ospd-openvas-Service vorhanden ist.
Webinterface nach Port-Änderung nicht erreichbar: Firewall blockiert Port 9392. UFW-Regel prüfen: sudo ufw status. Nur das Admin-Subnetz freigeben: sudo ufw allow from 192.168.1.0/24 to any port 9392.
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: „Full and Fast Ultimate" auf Produktivsystem verwendet. Auf Produktivsystemen ausschließlich „Full and Fast" verwenden.

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?". Für NIS2 und Basis-Sicherheit ist regelmäßiges Scanning Pflicht; ein Pentest ist eine ergänzende Vertiefungsmaßnahme.

Wie gehe ich mit 5000 Findings im Report um?

CVSS-Filter auf severity>6.9 setzen – das reduziert die Liste typischerweise auf 5–20 % der Findings. Danach nach tatsächlicher Erreichbarkeit und Exponierung priorisieren: Internet-exponierte Systeme zuerst, dann interne Server, dann Workstations. Informational-Findings (CVSS 0,0) grundsätzlich aus dem Arbeits-Report herausfiltern.

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

Ein SSH-Account mit sudo-Rechten ist notwendig. Best Practice: Dedizierten Systemaccount gvmscan anlegen, nur SSH-Key-Authentifizierung verwenden, sudo NOPASSWD nur für paketlistende Befehle (dpkg -l, rpm -qa). Der Account muss kein Root sein, aber sudo-Zugriff auf diese Befehle ist für vollständige Patch-Erkennung wichtig.

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 via Docker ist die kostengünstige Option für KMU mit technischem Know-how.

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

Reports nach jedem Scan als PDF und XML exportieren und mit Datum archivieren (z. B. scan_intern_2026-06-01.pdf). Den Remediation-Status dokumentieren: welche Findings wurden bis wann behoben, welche als akzeptiertes Risiko eingestuft (Override/Suppress in GCE setzen). Scan-Frequenz und Scope schriftlich in einer Betriebsanweisung festhalten. Dies genügt als Nachweis für NIS2 Artikel 21 und Cyber-Versicherungsaudits.

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

Für technische Teams mit Linux-Know-how und engem Budget ist GCE die richtige Wahl: kostenlos, BSI-empfohlen, über 120.000 NVTs. Nessus Professional (ca. 3.390 USD/Jahr) bietet höhere Scan-Genauigkeit out-of-the-box, mehr Credential-Typen und bessere Reporting-Templates für nicht-technische Stakeholder. Nessus Essentials ist für bis zu 16 Hosts kostenlos – gut für erste Tests oder sehr kleine Umgebungen.

Fazit

Greenbone Community Edition ist der pragmatischste Einstieg ins strukturierte Schwachstellenmanagement für KMU: BSI-empfohlen, kostenlos, mit über 120.000 NVTs und in unter zwei Stunden per Docker produktionsreif. Der eigentliche Mehrwert liegt aber nicht im einmaligen Scan, sondern im Prozess: authentifizierte Scans für vollständige Abdeckung, CVSS-Filter für fokussierte Triage, revisionssichere Exports für NIS2 und Versicherungsaudits, und ein Cron-Job, der die Feeds aktuell hält. Wer diesen Rhythmus einmal etabliert hat, kann bei der nächsten Prüfung mit konkreten Zahlen belegen, dass Schwachstellen systematisch erkannt und behoben werden.

Für eine sichere Grundlage des Scanner-Hosts empfiehlt sich außerdem die Anleitung Linux-Server härten nach CIS-Benchmark sowie – für den automatisierten Patch-Stand auf den Zielsystemen – 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