Automatisierung, Sensoren & Integrationen

Worum geht's?

Die Schicht des erweiterten Betriebs der Greenbone Enterprise Appliance: die Appliance programmatisch über das Greenbone Management Protocol (GMP) mit gvm-tools steuern, Scans über eine Master-Sensor-Einrichtung verteilen und Sensoren als Remote-Scanner nutzen, die Scan-Performance sowie die Scan-Queue überwachen und optimieren und die Appliance an externe Systeme anbinden - verinice, Nagios, Cisco Firepower Management Center, Alemba vFire und Splunk.

Quellenumfang

Basiert auf dem Handbuch der Greenbone Enterprise Appliance (GOS 22.04 / OPENVAS SCAN 22.04), Kapitel 15-18, geprüft im Juni 2026. Die GMP-Automatisierung gilt auch für die kostenlose Community Edition; die Master-Sensor-Einrichtung und die aufgeführten Integrationen sind Appliance-orientiert. Nicht jedes Appliance-Modell unterstützt jede Menüoption - prüfe die Modelltabellen in Handbuchkapitel 3, falls eine Funktion fehlt.

---

1. GMP-Automatisierung

Die vollständige Schwachstellen-Management-Funktionalität der Appliance ist auch über das Greenbone Management Protocol (GMP) verfügbar. Die Weboberfläche selbst verwendet GMP lokal. Greenbone liefert die Greenbone Vulnerability Management Tools (gvm-tools), um auf diese Funktionalität zuzugreifen (§15). Die neueste GMP-Version ist auf der Greenbone-API-Seite dokumentiert.

1.1 Änderungen an GMP

GMP wird regelmäßig aktualisiert, um mit dem zugrunde liegenden Dienst Schritt zu halten und eine konsistente, umfassende Schnittstelle zu erhalten. Jedes Update erzeugt eine neue GMP-Version mit einer veröffentlichten Liste hinzugefügter, geänderter und entfernter Protokollelemente wie Befehle oder Attribute (§15.1). Je nach Änderung kann die alte Version für eine Übergangszeit verfügbar bleiben, während der beide Versionen parallel laufen. Die Änderungsliste hilft dir, dich frühzeitig vorzubereiten, sie stellt aber nicht den vollständigen Satz anstehender Änderungen dar.

1.2 GMP aktivieren

GMP muss aktiviert werden, bevor es verwendet werden kann. Die Weboberfläche verwendet GMP lokal, der entfernte GMP-Dienst ist jedoch standardmäßig nicht über das Netzwerk erreichbar. Aktiviere den entfernten Dienst im GOS-Administrationsmenü (§15.2, GOS-Menü §7.2.4.2).

Der Zugriff auf GMP ist authentifiziert und mit SSL/TLS verschlüsselt. GMP verwendet dieselben Benutzerkonten wie die Weboberfläche, mit denselben Einschränkungen und Berechtigungen.

1.3 gvm-tools verwenden

gvm-tools ist eine Sammlung von Werkzeugen, die GMP zugänglich machen. Mit gvm-script ausgeführte Skripte nutzen die API der python-gvm-Bibliothek, die automatisch mit gvm-tools installiert wird (§15.3). Die Werkzeuge werden als Kommandozeilen-Schnittstelle und als Python-Shell ausgeliefert, für Microsoft Windows und jedes Betriebssystem, das Python unterstützt (einschließlich Linux). Python 3.5 oder höher ist erforderlich.

Beachte, dass gvm-tools, python-gvm und GOS unterschiedliche Versionsschemata verwenden, sodass ihre Versionsnummern nicht zwangsläufig übereinstimmen - verwende die neuesten Versionen von gvm-tools und python-gvm. Für Windows sind statisch gelinkte EXE-Builds (gvm-cli.exe, gvm-pyshell.exe) direkt bei Greenbone erhältlich und benötigen kein Python. Links zur Greenbone-Download-Seite unterscheiden zwischen Groß- und Kleinschreibung.

GMP ist XML-basiert: Jeder Befehl und jede Antwort ist ein GMP-Objekt. gvm-cli unterstützt SSH-, TLS- und Unix-Domain-Socket-Verbindungen. Alle aktuellen Appliances verwenden SSH zur Verschlüsselung von GMP - TLS ist veraltet, wird nicht offiziell unterstützt und könnte in einer zukünftigen Version entfernt werden. Die Werkzeuge sind am nützlichsten für die Stapelverarbeitung und das Scripting.

Einige minimale gvm-cli-Aufrufe:

gvm-cli --xml "<get_version/>"
gvm-cli --xml "<get_tasks/>"
gvm-cli < file

1.3.1 Den Client konfigurieren

Die Verwendung von gvm-cli erfordert die Anmeldung an der Appliance. Die Anmeldedaten können entweder über Kommandozeilen-Schalter (--gmp-username, --gmp-password) oder über eine Konfigurationsdatei unter ~/.config/gvm-tools.conf angegeben werden (§15.3.1.1). Die Konfigurationsdatei wird standardmäßig nicht gelesen - der Schalter --config (-c) muss hinzugefügt werden, um sie zu lesen.

[Auth]
gmp_username=webadmin
gmp_password=kennwort

1.3.2 Einen Scan mit gvm-cli starten

Ein typischer Anwendungsfall ist der automatische Scan eines neu entdeckten Hosts - zum Beispiel ein Intrusion Detection System in einer DMZ, das einen Scan auslöst, wenn es ein neues System oder einen ungewöhnlichen offenen TCP-Port entdeckt (§15.3.1.2). Ausgehend von der IP-Adresse des verdächtigen Hosts ist der Ablauf: ein Ziel erstellen, eine Aufgabe erstellen, die Aufgabe starten, sie überwachen und dann den Bericht herunterladen.

Erstelle das Ziel (die Antwort liefert die neue Ziel-ID zurück):

gvm-cli --gmp-username webadmin --gmp-password kennwort ssh \
  --hostname 192.168.222.115 \
  --xml "<create_target><name>Suspect Host</name><hosts>$IPADDRESS</hosts></create_target>"

Erstelle die Aufgabe mit Bezug auf die Ziel-ID und eine Scan-Konfigurations-ID (die Antwort liefert die Aufgaben-ID zurück, die zum Starten und Überwachen benötigt wird):

gvm-cli --gmp-username webadmin --gmp-password kennwort ssh \
  --hostname 192.168.222.115 \
  --xml "<create_task><name>Scan Suspect Host</name> \
  <target id=\"4574473f-a5d0-494c-be6f-3205be487793\"></target> \
  <config id=\"daba56c8-73ec-11df-a475-002264764cea\"></config></create_task>"

Die IDs vorhandener Ziele und Scan-Konfigurationen können mit <get_targets/> und <get_configs/> abgerufen werden (die Ausgabe ist XML). Starte und überwache die Aufgabe mit ihrer ID:

gvm-cli --gmp-username webadmin --gmp-password kennwort ssh \
  --hostname 192.168.222.115 \
  --xml '<start_task task_id="ce225181-c836-4ec1-b83f-a6fcba70e17d"/>'

gvm-cli --gmp-username webadmin --gmp-password kennwort ssh \
  --hostname 192.168.222.115 \
  --xml '<get_tasks task_id="ce225181-c836-4ec1-b83f-a6fcba70e17d"/>'

Die Appliance schließt die Verbindung, sobald die Aufgabe startet; die Aufgabe läuft weiter. Wenn der Scan fertig ist, liste die Berichtsformat-IDs mit <get_report_formats/> auf und lade den Bericht mit <get_reports report_id="..." format_id="..."/> herunter. Um die Verarbeitung vollständig zu automatisieren, kombiniere die Aufgabe mit einem Alert, der den Bericht weiterleitet, sobald eine bestimmte Bedingung erfüllt ist.

1.3.3 Einen Scan mit gvm-pyshell starten

gvm-pyshell sendet und empfängt dieselben XML-Befehle und -Antworten über Python-Befehle - das Werkzeug erzeugt und parst das XML für dich, was die Verarbeitung der Ausgabe einfacher macht als in der Shell (§15.3.2). Es unterstützt TLS-, SSH- und Socket-Verbindungen; das Format der Authentifizierungsdatei ist dasselbe wie bei gvm-cli. Die Python-Implementierung folgt der GMP-API, wobei optionale Argumente mit einem ? markiert sind.

gvm-pyshell --gmp-username webadmin --gmp-password kennwort ssh --hostname 192.168.222.115

Innerhalb der interaktiven Konsole können verpflichtende Argumente positionell oder über ihren Bezeichner übergeben werden:

res = gmp.create_target("Suspect Host", make_unique=True, hosts=['192.168.255.254'])
target_id = res.xpath('@id')[0]

res = gmp.create_task(name="Scan Suspect Host",
                      config_id="daba56c8-73ec-11df-a475-002264764cea",
                      scanner_id="08b69003-5fc2-4037-a479-93b440211c73",
                      target_id=target_id)
task_id = res.xpath('@id')[0]
gmp.start_task(task_id)

Die Erstellung einer Aufgabe benötigt eine target_id, config_id, scanner_id, einen Aufgabennamen und einen Aufgabenkommentar. Vorhandene Scan-Konfigurationen und Scanner können mit gmp.get_configs() aufgelistet werden; werden nur die eingebauten Scanner verwendet, sind ihre IDs fest:

• OpenVAS-Scanner: 08b69003-5fc2-4037-a479-93b440211c73
• CVE-Scanner: 6acd0832-df90-11e4-b9d5-28d24461215b

1.3.4 Beispielskripte

gvm-tools liefert eine Sammlung von Beispielskripten, die mit gvm-script laufen (§15.3.3). Sie sind ein guter Ausgangspunkt für eigene Skripte. Der Satz für gvm-tools 2.0.0 umfasst unter anderem:

Skript	Zweck
application-detection.gmp.py	Zeigt alle Hosts an, auf denen die gesuchte Anwendung läuft.
cfg-gen-for-certs.gmp.py	Erstellt eine Scan-Konfiguration aus VTs auf Basis eines bestimmten CERT-Bund-Advisory.
clean-sensor.gmp.py	Entfernt alle Ressourcen von einem Sensor außer aktiven Aufgaben.
nvt-scan.gmp.py	Erstellt eine Aufgabe für einen bestimmten Host und VT aus einer fest hinterlegten Basiskonfiguration.
startNVTScan.gmp.py	Erstellt eine Aufgabe für einen bestimmten Host und VT interaktiv.
SyncAssets.gmp.py	Lädt Assets in die Asset-Datenbank hoch.
SyncReports.gmp.py	Ruft Berichte ab und lädt sie über Container-Aufgaben auf eine zweite Appliance hoch.
monthly-report.gmp.py / monthly-report2.gmp.py	Listet alle Schwachstellen aus den Berichten eines bestimmten Monats auf (GOS 3.1 / 4.x).

1.3.5 Statuscodes

GMP verwendet Statuscodes nach dem Vorbild der HTTP-Statuscodes (§15.4):

Code	Bedeutung
200	OK
201	Ressource erstellt
202	Anfrage übermittelt
400	Syntaxfehler - fehlende oder falsche Elemente/Attribute; wird derzeit auch bei fehlender oder falscher Authentifizierung verwendet
401	Zuerst authentifizieren (fehlende oder falsche Authentifizierung; in der Praxis wird weiterhin 400 verwendet)
403	Zugriff auf Ressource verboten - unzureichende Berechtigungen (oft als 400 Permission denied angezeigt)
404	Ressource fehlt - die Ressourcen-ID war leer oder falsch
409	Ressource belegt - z. B. eine Feed-Synchronisation wurde gestartet, während bereits eine läuft
500	Interner Fehler - z. B. Einträge, die eine interne Puffergröße überschreiten
503	Scanner lädt NVTs / Dienst vorübergehend ausgefallen (oft abgelaufene Zertifikate) / Dienst nicht verfügbar (GMP-Befehl blockiert)

---

2. Master-Sensor-Einrichtung

Aus Sicherheitsgründen können manche Netzwerksegmente nicht direkt gescannt werden. Die Appliance unterstützt ein verteiltes Scan-System, bei dem zwei oder mehr Appliances in unterschiedlichen Netzwerksegmenten sicher miteinander verbunden sind (§16). Eine Appliance (der Master) steuert eine oder mehrere andere (Sensoren).

• Alle Appliance-Modelle ab Greenbone Enterprise 400/DECA können als Master fungieren.
• Alle Modelle außer Greenbone Enterprise ONE können als Sensor fungieren; die Greenbone Enterprise 35 und 25V können nur Sensoren sein und werden immer von einem Master gesteuert.
• Ein Sensor benötigt Netzwerkverbindung nur zum Master und zu den Scan-Zielen, speichert keine Informationen dauerhaft (außer VTs) und benötigt nach der Ersteinrichtung keine weitere Administration.
• Der Master kann Sensoren direkt verwalten, einschließlich automatischer oder manueller Feed-Updates und GOS-Upgrades.

Die Master-Sensor-Verbindung wird über SSH (Port 22/TCP) eingerichtet. Es ist wichtig, zwei Funktionen zu unterscheiden (§16):

• Sensoren - die im GOS-Administrationsmenü beider Appliances konfigurierte Master-Sensor-Verbindung. Sie unterstützt die entfernte Feed-Synchronisation und das Upgrade-Management des Sensors.
• Remote-Scanner - in der Weboberfläche auf dem Master konfiguriert. Damit lassen sich Scans über den Sensor ausführen. Eine Remote-Scanner-Verbindung verwendet das Open Scanner Protocol (OSP) über SSH.

2.1 Die Verbindung konfigurieren

Master und Sensor werden gekoppelt, indem ein öffentlicher Schlüssel ausgetauscht und sein Fingerabdruck verifiziert wird (§16.1). Im Überblick:

1. Auf dem Master: Setup > Master > Master Identifier > Download, dann die angezeigte URL öffnen und die PUB-Datei herunterladen. Den Fingerabdruck noch nicht bestätigen.
2. Auf dem Sensor: Setup > Sensor > Configure Master > Upload, die angezeigte URL öffnen, zur PUB-Datei navigieren und sie hochladen.
3. Vergleiche die auf beiden Appliances angezeigten Fingerabdrücke. Stimmen sie überein, bestätige auf beiden, dann Save auf dem Sensor.
4. Aktiviere auf dem Sensor SSH (Services > SSH > SSH State) und aktiviere OSP (Services > OSP); speichere jede Änderung.
5. Auf dem Master: Setup > Master > Sensors > Add a new sensor, gib die Sensor-IP oder den Hostnamen ein und wähle dann Auto, damit der Master den Sensor-Identifier abruft.
6. Verifiziere den Fingerabdruck des Sensor-Identifiers gegen Setup > Sensor > Sensor Identifier > Fingerprint auf dem Sensor, Save, führe dann Test aus.

Nach erfolgreicher Konfiguration können Sensoren direkt auf dem Master im GOS-Administrationsmenü verwaltet werden (GOS-Menüs §7.3.5 und §7.3.7).

2.2 Konfigurierte Sensoren verwalten

Setup > Master > Sensors auf dem Master listet Aktionen für alle konfigurierten Sensoren auf (§16.2): alle Sensorverbindungen testen, alle Sensorprotokolle aktualisieren, einen neuen Sensor hinzufügen und Edit/Delete the sensor... für einen bestimmten. Zu den Einstellungen je Sensor gehören die Sensoradresse, der Remote-Port, der Proxy, der Sensor-Identifier, das Aktivieren oder Deaktivieren automatischer Feed-Updates, wenn der Feed des Masters aktualisiert wird, das automatische Setzen von Port und Identifier, das Testen der Konfiguration und das Löschen des Sensors.

2.3 Sensoren in sicheren Netzwerken einsetzen

Da der Master alle Schwachstelleninformationen und Anmeldedaten vorhält, während ein Sensor nichts dauerhaft speichert (außer VTs), gehört der Master in die höchste Sicherheitszone, und jegliche Kommunikation wird vom Master hinunter zum Sensor initiiert (§16.3). Eine Firewall, die die Zonen trennt, muss nur Verbindungen vom Master zum Sensor zulassen - es sind keine Verbindungen in die höhere Sicherheitszone erforderlich.

Master und Sensor kommunizieren standardmäßig über SSH auf Port 22/TCP; aus Gründen der Abwärtskompatibilität kann auf dem Sensor Port 9390/TCP aktiviert werden (Setup > Sensor > Port 9390 > Save). Feed-Updates und GOS-Upgrades des Sensors können entweder direkt von den Greenbone-Servern oder über den Master kommen; werden sie über den Master geleitet, kontaktiert nur der Master Greenbone. Um zu verhindern, dass ein Sensor Greenbone kontaktiert, deaktiviere die automatische Synchronisation (Setup > Feed > Synchronisation > Save). Als zusätzliche Schicht können Source- und Destination-NAT-Regeln auf einer Firewall mit Stateful Packet Inspection die Notwendigkeit von Default-Routen auf den Appliances vermeiden.

2.4 Einen Sensor als Remote-Scanner konfigurieren

Die Master-Sensor-Verbindung (Abschnitt 2.1) muss zuerst vollständig sein. Ein Sensor kann dann als entfernte Scan-Engine neben den Standard-Scannern OpenVAS und CVE verwendet werden, konfiguriert in der Weboberfläche des Masters (§16.4):

1. Melde dich an der Weboberfläche des Masters an und wähle Configuration > Scanners.
2. Erstelle einen neuen Scanner und gib seinen Name ein.
3. Wähle im Drop-down Type den Eintrag Greenbone Sensor. Es ist zwingend erforderlich, Greenbone Sensor zu wählen; OSP Scanner darf nicht verwendet werden.
4. Gib die Sensor-IP oder den Hostnamen unter Host ein und Save.
5. Verifiziere den neuen Scanner in seiner Zeile. Eine korrekte Einrichtung verifiziert erfolgreich.

Scanner werden pro Benutzer konfiguriert; erstelle sie pro Benutzer oder vergib Nutzungsrechte über Berechtigungen (§9.4).

2.5 Einen Remote-Scanner verwenden

Sobald ein Sensor als Remote-Scanner konfiguriert ist, kann er beim Erstellen einer neuen Scan-Aufgabe oder eines Audits als Scanner ausgewählt werden (§16.5; siehe auch Ein System scannen und die Audit-Kapitel). Für eine vorhandene Aufgabe oder ein vorhandenes Audit gibt es zwei Möglichkeiten: Ist sie als veränderbar markiert, ändere ihren Scanner direkt; andernfalls klone die Aufgabe/das Audit und ändere den Scanner am Klon.

---

3. Performance

Der Betrieb der Appliance bewegt erhebliche Datenmengen zwischen der Appliance, den Scan-Zielen und etwaigen Sensoren, und die Ergebnisse müssen anschließend noch analysiert, gefiltert und verarbeitet werden - oft viele Prozesse gleichzeitig, abhängig von Modell, Benutzeranzahl und Aufgabenkonfiguration (§17).

3.1 Appliance-Performance überwachen

Administration > Performance zeigt die Ressourcenauslastung für die letzte Stunde, den letzten Tag, die letzte Woche, den letzten Monat oder das letzte Jahr (§17.1). Die Performance eines konfigurierten Sensors kann ebenfalls auf dem Master angezeigt werden. Wichtige Abschnitte zum Auslesen:

Abschnitt	Worauf zu achten ist
Processes	Eine hohe Anzahl ist nicht kritisch; überwiegend sollten schlafende und laufende Prozesse angezeigt werden.
System Load	Anhaltend hohe Auslastung ist kritisch. Eine Last von 4 auf einem 4-Kern-System ist akzeptabel.
CPU Usage	Ein hoher Wait-IO ist besonders kritisch.
Memory Usage	Die Appliance cacht aggressiv; der größte Teil des als Cache genutzten Speichers ist akzeptabel.
Swap Usage	Swap-Nutzung weist auf eine mögliche Systemüberlastung hin.

3.2 Scan-Performance optimieren

Die Scan-Geschwindigkeit hängt hauptsächlich von drei Stellschrauben ab (§17.2):

Stellschraube	Wirkung
Port-Liste (§17.2.1)	Die auf einem Ziel konfigurierte Port-Liste bestimmt die Dauer sowohl des Alive-Tests als auch des Schwachstellen-Scans. Es gibt 65535 TCP- und 65535 UDP-Ports pro System; TCP-Scans sind in der Regel schnell, UDP langsamer, weil Antworten nicht zwangsläufig bestätigt werden. Vordefinierte Listen reichen von All IANA assigned TCP (üblicherweise wenige Minuten) bis hin zu All TCP und Kombinationen mit den Nmap-Top-UDP-Ports. Dienste auf Ports, die nicht in der Liste enthalten sind, werden nicht getestet. Das Scannen aller TCP- und UDP-Ports kann bei Drosselung 24 Stunden oder mehr pro Host dauern. Zusätzliche Port-Listen können erstellt werden (§10.7).
Scan-Konfiguration (§17.2.2)	Es gibt vier Konfigurationen: Full and fast, Full and fast ultimate, Full and very deep, Full and very deep ultimate. Die beiden fast-Konfigurationen verwenden zuvor gefundene Informationen wieder und führen nur nützliche VTs aus, was die Dauer reduziert; die beiden very deep-Konfigurationen ignorieren frühere Erkenntnisse und führen ausnahmslos alle verfügbaren VTs aus.
Scan-Reihenfolge der Ziele (§17.2.3)	Der Fortschrittsbalken ist eine grobe Schätzung. Bei der sequenziellen Standardreihenfolge führen große leere IP-Bereiche dazu, dass der Fortschritt schnell auf ~95 % springt und sich dann von 95 % auf 100 % über die wenigen aktiven Hosts schleppt. Das Setzen von Order for target hosts auf Random beim Erstellen der Aufgabe verbessert die Fortschrittsschätzung.

3.3 Scan-Queuing

Wenn eine Aufgabe oder ein Audit gestartet wird, wird sie/es mit dem Status Queued in eine Warteschlange eingereiht; der Scanner beginnt erst, wenn ausreichend Systemressourcen frei sind, und in der Warteschlange befindliche Scans starten in Abständen von 1 Minute, um eine Überlastung des Systems zu vermeiden (§17.3). Die relevanteste Ressource ist RAM - jeder Scan benötigt eine Mindestmenge, weil ein Scan-Prozess nicht mehrere Scans bewältigen kann und RAM nicht zufriedenstellend geteilt werden kann. CPU, Netzwerk und Disk-I/O spielen ebenfalls eine Rolle, können aber auf Kosten einer langsameren Ausführung geteilt werden; die Performance-Diagramme zeigen den RAM-Verlauf über die Zeit (Abschnitt 3.1).

Aufgaben bleiben in der Warteschlange, wenn zu viele Scans gleichzeitig laufen und RAM knapp ist, oder solange die Appliance während eines Feed-Updates oder kurz nach dem Start neue VTs lädt. Wenn RAM frei wird oder das VT-Laden abgeschlossen ist, starten in der Warteschlange befindliche Scans nach dem First-in-First-out-Prinzip. Das Workload-Management wird vom Scanner übernommen; in einer Master-Sensor-Einrichtung verwaltet jeder Sensor seine eigenen Ressourcen, und Sensor-Scans beeinträchtigen die Scan-Kapazität des Masters nur minimal.

---

4. Integrationen

Die Appliance kann über mehrere Schnittstellen mit anderen Systemen verbunden werden (§18): GMP für die vollständige Fernsteuerung, konfigurierbare Berichtsformate, Alerts (Syslog, E-Mail, SNMP-Trap, HTTP), von Greenbone gebaute Connectoren zur Ergebnisweiterleitung und SNMP-Monitoring über die veröffentlichte MIB-Datei. Mehrere Systeme sind direkt integriert:

System	Zweck
verinice (§18.1)	Kostenloses Open-Source-ISMS von SerNet. Die Appliance speist Scan-Daten in verinice ein, um den Workflow zur Schwachstellenbehebung, die Risikoanalyse (ISO 27005) und den ISMS-Betrieb (ISO 27001) anzutreiben.
Nagios (§18.2)	Monitoring-System, das Scan-Ergebnisse als zusätzlichen Test integriert und gescannte Systeme mit überwachten Systemen abgleicht, sodass die Ergebnisse für Nagios-Alert-Regeln verfügbar werden.
Cisco Firepower Management Center (§18.3)	NIDS/IPS, dessen Asset-Datenbank mit Appliance-Daten angereichert wird, um Angriffe besser zu erkennen; es kann zudem Scans auf verdächtigen Hochrisikosystemen auslösen.
Alemba vFire (§18.4)	Enterprise-Service-Management-Anwendung; die Appliance erstellt in vFire Tickets („Calls") auf Basis von Ereignissen wie abgeschlossenen Scans.
Splunk (§18.5)	Leitet Scan-Ergebnisse an eine Splunk-Enterprise-On-Premise-Installation zur weiteren Analyse und Korrelation weiter.

4.1 verinice

Greenbone stellt über den Greenbone Enterprise Feed zwei Berichtsformate bereit - Verinice ISM und Verinice ISM all results -, um Appliance-Daten nach verinice zu exportieren (§18.1). Mit Verinice ISM werden nur Ergebnisse übertragen, die eine Notiz tragen (plus die Assets und der vollständige Schwachstellenbericht); mit Verinice ISM all results werden alle Ergebnisse übertragen, ohne dass Notizen erforderlich sind. Der Export erzeugt eine VNA-Datei (ein ZIP der Scan-Daten), die in die Perspektive Information Security Management von verinice importiert wird. Daten können auch vollautomatisch an verinice.PRO, die Servererweiterung, übertragen werden. Nach dem Import läuft der Behebungs-Workflow über verinice-Aufgaben (zum Beispiel Remediate Vulnerabilities), die einer verantwortlichen Person zugewiesen werden; für Connector-Unterstützung wende dich an SerNet oder den Greenbone Enterprise Support.

4.2 Nagios

Bei Anbindung übernimmt Nagios die steuernde Rolle und ruft regelmäßig die neuesten Scan-Ergebnisse von der Appliance ab, indem es mit gvm-script das Skript check-gmp.gmp.py aufruft (§18.2). Kompatible Produkte wie Open Monitoring Distribution, Icinga oder Centreon sollten generell mit kleinen Anpassungen funktionieren. Einrichtung im Überblick:

• Konfiguriere einen Appliance-Benutzer für Nagios, der die relevanten Scan-Ziele besitzt (oder uneingeschränkten Lesezugriff hat), und führe diese Aufgaben als geplante Scans aus. Der GMP-Zugriff muss aktiviert sein (Abschnitt 1.2).
• Kopiere das Plug-in check-gmp.gmp.py in das Nagios-Verzeichnis libexec/ und prüfe die Verbindung:

gvm-script --gmp-username="user name" --gmp-password="password" \
  ssh --hostname 192.168.10.169 /.../libexec/check-gmp.gmp.py --ping

• Definiere in der Nagios-Konfiguration den überwachten Host, einen Service, der den Befehl check_gmp_status aufruft, und den Befehl selbst (der den Aufgabennamen als Argument übergibt), und starte dann den Nagios-Dienst neu.

Das Plug-in unterstützt Caching: Neue Berichte werden in einer SQLite-Datenbank zwischengespeichert (Standard /tmp/check_gmp/reports.db, überschreibbar mit --cache), sodass nachfolgende Aufrufe einen Bericht nur dann von der Appliance abrufen, wenn sich die Scan-Endzeit geändert hat (§18.2.3). Es kann zudem die Anzahl gleichzeitiger Instanzen begrenzen (MAX_RUNNING_INSTANCES, Standard 10, überschreibbar mit -I), um die Last zu begrenzen.

4.3 Cisco Firepower Management Center

Das Firepower Management Center (früher Sourcefire IPS) reichert seine eigene Asset-Datenbank mit Appliance-Daten an und kann Scans auf verdächtigen Systemen auslösen (§18.3). Zwei Verbindungsmethoden sind verfügbar: die automatische Datenübertragung von der Appliance an das NIDS/IPS als Alert nach Abschluss eines Scans (ein wöchentlich geplanter Scan ergibt eine vollständig automatisierte Alerting- und Optimierungsschleife) und die aktive Steuerung der Appliance durch das NIDS/IPS, um ein Hochrisikosystem zu prüfen. Die empfangende Option muss im Firepower Management Center aktiviert werden.

Einrichtung im Überblick: Erstelle im Firepower Management Center einen Host Input Client (System > Integration > Host Input Client) mit der Appliance-IP als Hostname und einem Passwort; das Speichern erzeugt ein TLS-verschlüsseltes PKCS#12-Client-Zertifikat und einen Schlüssel, die an diese IP gebunden sind. Erstelle auf der Appliance einen Alert (Configuration > Alerts) über die Methode Sourcefire Connector, gib die IP und den Port des Management Centers, die PKCS#12-Datei und - falls die Datei passwortgeschützt ist - ein PKCS12-Credential an.

4.4 Alemba vFire

Die Appliance kann in einer vFire-Instanz bei Ereignissen wie abgeschlossenen Scans Tickets („Calls") erstellen (§18.4). Voraussetzungen auf vFire-Seite: vFire 9.7 oder höher mit aktivierter RESTful Alemba API (die Legacy-API wird nicht unterstützt), ein Alemba-API-Client mit dem korrekten Session-Typ und aktiviertem Passwort-Login sowie ein Benutzerkonto, das zur Nutzung der Alemba API berechtigt ist. Die Integration ist ein Alert (Configuration > Alerts) mit der Methode Alemba vFire. Zu den konfigurierbaren Details gehören Berichtsformate für Anhänge, die Basis-URL der Alemba-Instanz, das Login-Credential, der Session-Typ (analyst oder user), die Alemba-Client-ID, die Partition, die Vorlage für die Call-Beschreibung, die Call-Vorlage, der Call-Typ, der Impact und die Urgency.

4.5 Splunk

Die Anbindung an Splunk ist ein Add-on statt einer Kernfunktionalität: Greenbone stellt eine Greenbone-Splunk-App für Splunk Enterprise On-Premise bereit (§18.5). Splunk Light und Splunk Cloud werden nicht unterstützt. Die Links zur Greenbone-Download-Seite unterscheiden zwischen Groß- und Kleinschreibung. Einrichtung im Überblick:

• Installiere die App in Splunk Enterprise aus der heruntergeladenen TAR-Datei. Sie richtet standardmäßig einen TCP-Dateneingang auf Port 7680 ein, kennzeichnet eingehende Daten als Greenbone Scan Results und legt sie im Standard-Index ab; Feldnamen-Aliase können zur besseren Lesbarkeit bearbeitet werden.
• Erstelle auf der Appliance einen Alert (Configuration > Alerts) über die Methode Send to host, der auf die IP des Splunk-Servers auf Port 7680 mit dem Berichtsformat XML zeigt, und füge den Alert dann einer Aufgabe hinzu (oder löse ihn an einem vorhandenen Bericht aus, um zu testen).

In Splunk zeigt das Greenbone Dashboard Ergebnisse aus Berichten, die weniger als 7 Tage alt sind (ältere Berichte landen weiterhin im Haupt-Index), und die Search-Ansicht kann indizierte Felder wie host, VulnerabilityResultNvtCVE, VulnerabilityResultSeverity und VulnerabilityResultThreat abfragen. Aus diesen Feldern lassen sich eigene Dashboards bauen (zum Beispiel die Top 5 betroffenen Hosts und eingehende Berichte).

---

Verwandt

• Greenbone / OpenVAS Guide
• Ein System scannen
• GOS-Administration