Architektur, FAQ & Glossar

Worum geht's?

Diese Seite ist Referenzmaterial aus den Kapiteln 19–21 des Handbuchs der Greenbone Enterprise Appliance: die Architektur des Greenbone Operating System (GOS), die von der Appliance genutzten Netzwerkprotokolle, Überlegungen zu Security Gateways, eine getreue Wiedergabe der häufig gestellten Fragen und ein Glossar der durchgängig im System verwendeten Terminologie.

Quellenstand

Basierend auf dem Handbuch der Greenbone Enterprise Appliance (GOS 22.04 / OPENVAS SCAN 22.04), Kapitel 19–21. Verifiziert im Juni 2026. Kapitelverweise in Klammern verweisen auf die jeweiligen Handbuchabschnitte.

1. Architektur

GOS-Architektur

Das Greenbone Operating System (GOS) ist das Betriebssystem der Greenbone Enterprise Appliance (Handbuchabschnitt 19.1).

Die GOS-Steuerungsschicht ermöglicht den Zugriff auf die Administration von GOS. Es wird nur ein einziges Systemadministrator-Konto unterstützt. Der Systemadministrator kann Systemdateien nicht direkt ändern, kann das System aber anweisen, Konfigurationen zu ändern.

GOS wird über eine menübasierte grafische Oberfläche verwaltet (das GOS-Administrationsmenü). Der Systemadministrator muss für Konfigurations- oder Wartungsaufgaben nicht die Kommandozeile (Shell) verwenden. Der Shell-Zugriff wird ausschließlich für Support- und Fehlerbehebungszwecke bereitgestellt.

Der Zugriff auf die Systemebene erfordert entweder einen Console-Zugriff (seriell, Hypervisor oder Monitor/Tastatur) oder eine Verbindung über SSH.

GOS ermöglicht es Benutzern, alle Dienste der Greenbone Community Edition zu konfigurieren, zu starten und zu stoppen.

Greenbone Community Edition

Die Greenbone Community Edition besteht aus einem Framework mit mehreren Diensten. Sie wird als Teil der Greenbone-Enterprise-Produkte entwickelt. Ursprünglich wurde sie als Community-Projekt namens "OpenVAS" aufgebaut und wird primär von Greenbone entwickelt und vorangetrieben. Sie besteht aus dem Greenbone Vulnerability Management Daemon (gvmd), dem Greenbone Security Assistant (GSA) mit dem Greenbone Security Assistant Daemon (gsad) und der ausführbaren Scan-Anwendung, die Schwachstellentests (VTs) gegen Zielsysteme ausführt.

Die Greenbone Community Edition wird unter Open-Source-Lizenzen veröffentlicht. Durch ihre Nutzung können Linux-Distributionen die Softwarekomponenten in Form von Installationspaketen erstellen und bereitstellen.

Greenbone Vulnerability Management Daemon (gvmd)

Der Greenbone Vulnerability Management Daemon (gvmd) — auch Greenbone Vulnerability Manager genannt — ist der zentrale Dienst, der reines Schwachstellen-Scanning zu einer vollständigen Vulnerability-Management-Lösung konsolidiert.

• gvmd steuert den OpenVAS Scanner über das Open Scanner Protocol (OSP). OSP ist XML-basiert, zustandslos und benötigt für die Kommunikation keine permanente Verbindung.
• Der Dienst selbst bietet das XML-basierte Greenbone Management Protocol (GMP).
• gvmd steuert eine SQL-Datenbank (PostgreSQL), in der alle Konfigurations- und Scan-Ergebnisdaten zentral gespeichert werden.
• gvmd übernimmt die Benutzerverwaltung, einschließlich Berechtigungssteuerung mit Gruppen und Rollen.
• Der Dienst verfügt über ein internes Laufzeitsystem für geplante Aufgaben und andere Ereignisse.

Greenbone Security Assistant (GSA)

Der Greenbone Security Assistant (GSA) ist das Web-Interface, mit dem ein Benutzer Scans steuert und auf Schwachstelleninformationen zugreift. Er ist der wichtigste Kontaktpunkt eines Benutzers mit der Appliance. Er verbindet sich über den Webserver Greenbone Security Assistant Daemon (gsad) mit gvmd, um eine vollwertige Webanwendung für Vulnerability Management bereitzustellen. Die Kommunikation erfolgt über das Greenbone Management Protocol (GMP), mit dem der Benutzer auch direkt über verschiedene Tools kommunizieren kann.

OpenVAS Scanner

Der Haupt-Scanner, der OpenVAS Scanner, ist eine vollwertige Scan-Engine, die Schwachstellentests (VTs) gegen Zielsysteme ausführt. Dazu nutzt er die täglich aktualisierten und umfangreichen Feeds: den vollwertigen, umfangreichen, kommerziellen Greenbone Enterprise Feed oder den frei verfügbaren Greenbone Community Feed.

Der Scanner besteht aus den Komponenten ospd-openvas und openvas-scanner. Der OpenVAS Scanner wird über OSP gesteuert. Der OSP Daemon für den OpenVAS Scanner (ospd-openvas) kommuniziert über OSP mit gvmd: VT-Daten werden gesammelt, Scans werden gestartet und gestoppt, und Scan-Ergebnisse werden über ospd an gvmd übertragen.

Notus Scanner

Der Notus Scanner scannt bei jedem regulären Scan mit, sodass keine Benutzerinteraktion nötig ist. Er bietet bessere Performance durch geringeren Verbrauch von Systemressourcen und damit schnelleres Scannen.

Der Notus Scanner ersetzt die Logik potenziell aller NASL-basierten lokalen Sicherheitsprüfungen (LSCs). Statt für jede LSC ein VT-Skript auszuführen, erfolgt ein Abgleich der auf einem Host installierten Software mit einer Liste bekannter verwundbarer Software.

Der reguläre OpenVAS Scanner lädt jede NASL-LSC einzeln und führt sie für jeden Host nacheinander aus; eine einzelne bekannte Schwachstelle wird dann mit der installierten Software verglichen, wiederholt für alle LSCs. Mit dem Notus Scanner wird die Liste der installierten Software auf dieselbe Weise geladen, aber direkt mit aller bekannten verwundbaren Software für das Betriebssystem des gescannten Hosts verglichen. Dadurch entfällt die Notwendigkeit, die LSCs auszuführen, da die Informationen über die bekannte verwundbare Software in einer einzigen Liste gesammelt sind und nicht über einzelne NASL-Skripte verteilt.

GMP-Clients

Die Greenbone Vulnerability Management Tools (gvm-tools) sind eine Sammlung von Tools, die bei der Fernsteuerung einer Greenbone Enterprise Appliance und ihres zugrundeliegenden Greenbone Vulnerability Management Daemon (gvmd) helfen. Die Tools unterstützen den Zugriff auf die Kommunikationsprotokolle GMP (Greenbone Management Protocol) und OSP (Open Scanner Protocol).

Dieses Modul umfasst interaktive und nicht-interaktive Clients. Die Programmiersprache Python wird direkt für interaktives Scripting unterstützt, es ist aber auch möglich, GMP-/OSP-Befehle aus der Ferne abzusetzen, ohne in Python zu programmieren.

Protokolle

Es gibt obligatorische und optionale Protokolle; einige Protokolle werden nur in bestimmten Setups verwendet (Handbuchabschnitt 19.2). Die Appliance benötigt mehrere Protokolle, um voll funktionsfähig zu sein. Diese Protokolle stellen die Feed-Updates, die Domain-Name-System-Auflösung (DNS), die Zeit und so weiter bereit.

Appliance als Client

Die folgenden Protokolle werden von einem Stand-Alone-System oder einer Master-Appliance verwendet, um Verbindungen als Client zu initiieren (Handbuchabschnitt 19.2.1):

Protokoll	Port(s)	Obligatorisch	Verschlüsselung / Authentifizierung
DNS — Namensauflösung	53/udp, 53/tcp	Obligatorisch	Nicht verschlüsselt; kann internen DNS-Server nutzen
NTP — Zeitsynchronisation	123/udp	Obligatorisch	Nicht verschlüsselt; kann internen NTP-Server nutzen
Feeds (direkt)	24/tcp oder 443/tcp	Obligatorisch auf Stand-Alone- und Master-Appliances	SSH; verschlüsselt und bidirektional authentifiziert (Server: Public Key; Client: Public Key); direkter Internetzugang erforderlich
Feeds (über Proxy)	interner HTTP-Proxy, der die CONNECT-Methode auf einem konfigurierbaren Port unterstützt	Obligatorisch auf Stand-Alone- und Master-Appliances	SSH; verschlüsselt und bidirektional authentifiziert
DHCP	67/udp, 68/udp	Optional	Nicht verschlüsselt
LDAPS — Benutzerauthentifizierung	636/tcp	Optional	Verschlüsselt und authentifiziert über SSL/TLS (Server: Zertifikat; Client: Benutzername/Passwort)
Syslog — Remote-Logging und Alarme	512/udp oder 512/tcp	Optional	Nicht verschlüsselt
SNMP-Traps für Alarme	162/udp	Optional	Nur SNMPv1; nicht verschlüsselt
SMTP(S) für E-Mail-Alarme	465/tcp (SMTPS), 25/tcp (SMTP), alternativ 587/tcp	Optional	SMTPS kann erzwungen werden; andernfalls verschlüsselt über STARTTLS, oder nicht verschlüsselt, falls STARTTLS nicht möglich ist
SSH für Backup	22/tcp	Optional	Verschlüsselt und bidirektional authentifiziert über SSH (Server: Public Key; Client: Public Key)
Cisco Firepower (Sourcefire) für IPS-Integration	8307/tcp	Optional	Verschlüsselt und bidirektional authentifiziert über SSL/TLS (Server: Zertifikat; Client: Zertifikat)
verinice.PRO	443/tcp	Optional	Verschlüsselt über SSL/TLS (Server: optional über Zertifikat; Client: Benutzername/Passwort)
TippingPoint SMS	443/tcp	Optional	Verschlüsselt über SSL/TLS (Server: Zertifikat; Client: Zertifikat, Benutzername/Passwort)

Verbindungen für Feeds werden zu apt.greenbone.net und feed.greenbone.net aufgebaut.

Appliance als Server

Die folgenden Verbindungen werden von einer als Server agierenden Appliance unterstützt (Handbuchabschnitt 19.2.2):

Protokoll	Port	Obligatorisch	Verschlüsselung / Authentifizierung
HTTPS — Web-Interface	443/tcp	Obligatorisch auf Stand-Alone- und Master-Appliances	Verschlüsselt und authentifiziert über SSL/TLS (Server: optional über Zertifikat; Client: Benutzername/Passwort)
SSH — CLI-Zugriff und GMP	22/tcp	Optional	Verschlüsselt und authentifiziert über SSH (Server: Public Key; Client: Benutzername/Passwort)
SNMP	161/udp	Optional	Optional verschlüsselt bei Verwendung von SNMPv3

Master-Sensor-Setup

In einem Master-Sensor-Setup gilt die folgende zusätzliche Anforderung. Der Master (Server) initiiert bis zu drei zusätzliche Verbindungen zum Sensor (Client) (Handbuchabschnitt 19.2.3):

Protokoll	Port	Obligatorisch	Verschlüsselung / Authentifizierung
SSH für GOS-Upgrades, Feed-Updates, GMP und OSP	22/tcp	Obligatorisch	Verschlüsselt und bidirektional authentifiziert über SSH (Server: Public Key; Client: Public Key)

Überlegungen zu Security Gateways

Viele Unternehmen setzen Security Gateways ein, um den Internetzugang einzuschränken. Diese Security Gateways können als Paketfilter oder als Application Layer Gateways arbeiten (Handbuchabschnitt 19.3). Einige Produkte unterstützen Deep Inspection und versuchen, das in den Kommunikationskanälen tatsächlich verwendete Protokoll zu bestimmen. Sie können sogar versuchen, jegliche verschlüsselte Kommunikation zu entschlüsseln und zu analysieren.

Stand-Alone- / Master-Appliance

Während viele von der Appliance verwendete Protokolle nur intern genutzt werden, benötigen einige Zugriff auf das Internet und können von einem solchen Security Gateway gefiltert werden (Handbuchabschnitt 19.3.1).

Beim Einsatz der Appliance als Stand-Alone-Appliance oder als Master muss die Appliance auf den Greenbone Enterprise Feed zugreifen können. Der Greenbone Enterprise Feed kann direkt über Port 24/tcp oder 443/tcp oder über einen Proxy erreicht werden.

hinweis

In allen Fällen ist das verwendete Protokoll SSH, auch bei Verwendung von Port 443/tcp oder eines HTTP-Proxys.

Eine Deep-Inspection-Firewall kann die Verwendung des SSH-Protokolls auf Port 443/tcp erkennen und den Datenverkehr verwerfen oder blockieren. Wenn das Security Gateway versucht, den Datenverkehr mit Man-in-the-Middle-Techniken zu entschlüsseln, schlägt die Kommunikation zwischen der Appliance und dem Feed-Server fehl. Das SSH-Protokoll verhindert durch bidirektionale Authentifizierung auf Basis von Public Keys jegliche Man-in-the-Middle-Ansätze, indem es die Kommunikation beendet.

Zusätzliche Protokolle, die Internetzugang benötigen, sind DNS und NTP. Sowohl DNS als auch NTP können so konfiguriert werden, dass sie interne DNS- und NTP-Server nutzen.

Sensor-Appliance

Wenn Security Gateways zwischen dem Master und dem Sensor eingesetzt werden, muss das Security Gateway SSH-Verbindungen (22/tcp) vom Master zum Sensor zulassen (Handbuchabschnitt 19.3.2).

2. Häufig gestellte Fragen

Warum ist der Scan-Vorgang so langsam?

Die Performance eines Scans hängt von verschiedenen Aspekten ab (Handbuchabschnitt 20.1):

• Mehrere Port-Scanner wurden gleichzeitig aktiviert. Wenn eine individuelle Scan-Konfiguration verwendet wird, wähle nur einen einzigen Port-Scanner in der VT-Familie Port scanners aus. Der VT Ping Host kann dennoch aktiviert bleiben.
• Das Scannen ungenutzter IP-Adressen ist sehr zeitaufwendig. In einem ersten Schritt wird für jede IP-Adresse erkannt, ob ein aktives System vorhanden ist. Falls nicht, wird diese IP-Adresse nicht gescannt. Firewalls und andere Systeme können eine erfolgreiche Erkennung verhindern. Der VT Ping Host (1.3.6.1.4.1.25623.1.0.100315) in der VT-Familie Port scanners bietet eine Feinabstimmung der Erkennung.
• Die zu scannenden Ports führten zu Port-Throttling, oder es wurde UDP-Port-Scanning gewählt.

Was beeinflusst die Scan-Kapazität?

Die Scan-Kapazität — die scanbare Anzahl von IP-Adressen pro 24 Stunden — hängt vom Appliance-Modell ab. Die angegebenen Werte für die geschätzte Scan-Kapazität können nur als Richtwerte verstanden werden, da die Scan-Kapazität von vielen Faktoren beeinflusst wird (Handbuchabschnitt 20.2):

• Komplexität der verwendeten Scan-Konfiguration. In derselben Zeitspanne können weitaus mehr Discovery-Scans als Schwachstellen-Scans durchgeführt werden.
• Nutzung der Appliance außerhalb ihrer Spezifikationen. Das Starten zu vieler Scans oder das gleichzeitige Scannen zu vieler Ziele kann zu Performance-Problemen führen.
• Performance der Netzwerkinfrastruktur und des/der Zielsystem(e). Wenn Systeme langsam auf Netzwerkanfragen reagieren, verläuft der Scan-Vorgang langsamer.
• Typ des/der gescannten Zielsystem(e). Der Typ bestimmt, welche und wie viele Schwachstellentests während eines Scans ausgeführt werden; mehr Schwachstellentests bedeuten meist langsamere Scans. Einige Szenarien erhöhen den Ressourcenverbrauch und können die Performance beeinträchtigen, z. B. das Scannen virtueller Hosts (vhosts) und das Scannen von Webservern mit aktiviertem CGI-Caching.
• Parallele Nutzung der Appliance während des Scannens. Wenn andere ressourcenintensive Operationen laufen (z. B. Feed-Updates, Erzeugung großer Berichte), stehen weniger Systemressourcen für Scans zur Verfügung.
• Verwendung von Sensoren. Die Verwendung von Sensoren kann die scanbaren IP-Adressen pro 24 Stunden erhöhen.

Warum wird ein Dienst/Produkt nicht erkannt?

Es gelten die folgenden Ursachen und Lösungen (Handbuchabschnitt 20.3):

• Das Ziel wird nicht als online/erreichbar erkannt. Lösungen: Netzwerk-Setup/Routing zum Ziel korrigieren; die Kriterien/Test-Konfiguration aktualisieren, um das Ziel als aktiv zu erkennen; sicherstellen, dass die Scan-Konfiguration die VTs Nmap (NASL wrapper) (OID 1.3.6.1.4.1.25623.1.0.14259) und Ping Host (OID 1.3.6.1.4.1.25623.1.0.100315) aus der VT-Familie Port scanners enthält; jegliches Netzwerkgerät (Firewall, IDS/IPS, WAF usw.) zwischen Scanner und Ziel oder jegliche Sicherheitsmechanismen auf dem Ziel selbst überprüfen und entfernen und die IP-Adresse des Scanners auf die Whitelist setzen.
• Der Dienst/das Produkt läuft auf einem bestimmten Port, der nicht in der Portliste enthalten ist. Lösung: eine passende Portliste erstellen. Dies ist besonders bei UDP-Ports wichtig.
• Es ist ein Erkennungs-VT für einen Dienst/ein Produkt verfügbar, aber der Dienst/das Produkt wird während eines Scans nicht gefunden. Lösungen: Netzwerk-Setup/Routing zum Ziel korrigieren; die Kriterien/Test-Konfiguration aktualisieren, um das Ziel als aktiv zu erkennen; jegliches Netzwerkgerät zwischen Scanner und Ziel überprüfen und entfernen (und die IP-Adresse des Scanners auf die Whitelist setzen); eine passende Portliste erstellen (besonders für UDP-Ports); falls dies nicht hilft, den Greenbone Enterprise Support kontaktieren und weitere Informationen zum Dienst/Produkt bereitstellen (Produktname, konkret laufende Version usw.).
• Das Ziel ist nicht stabil/reagiert während eines Scans langsam. Lösungen: die gleichzeitig ausgeführten VTs reduzieren; den Dienst/das Produkt auf eine neuere Version aktualisieren (z. B. um ausgelöste Bugs zu beheben); dem Ziel mehr Ressourcen (CPU, RAM usw.) zuweisen, um es während Scans stabiler zu machen.

Warum wird eine Schwachstelle nicht erkannt?

Es gelten die folgenden Ursachen und Lösungen (Handbuchabschnitt 20.4):

• Der betroffene Dienst/das betroffene Produkt wird überhaupt nicht erkannt. Lösung: siehe die Antwort zu "Warum wird ein Dienst/Produkt nicht erkannt?".
• Der Dienst/das Produkt wurde erkannt, aber eine Versionsextraktion war nicht möglich. Lösungen: einen authentifizierten Scan durchführen; falls dies nicht hilft, den Greenbone Enterprise Support mit weiteren Informationen zum Dienst/Produkt kontaktieren.
• Es gibt nur eine Versionsprüfung mit einer niedrigeren Quality of Detection (QoD), und die Schwachstelle wird standardmäßig nicht angezeigt. Lösungen: den QoD-Wert im Ergebnisfilter ändern; einen authentifizierten Scan durchführen.
• Wenn ein authentifizierter Scan durchgeführt wurde, ist die Anmeldung fehlgeschlagen. Lösungen: die Korrektheit der verwendeten Zugangsdaten prüfen; verifizieren, dass der Benutzer nicht gesperrt ist; verifizieren, dass der Benutzer sich am Ziel anmelden darf; falls dies nicht hilft, den Greenbone Enterprise Support mit weiteren Informationen kontaktieren.
• Der Dienst/das Produkt selbst ist während des Scans abgestürzt oder hat aufgehört zu reagieren. Lösungen: die gleichzeitig ausgeführten VTs reduzieren; den Dienst/das Produkt auf eine neuere Version aktualisieren; dem Ziel mehr Ressourcen (CPU, RAM usw.) zuweisen.
• Die Schwachstelle wurde erst kürzlich entdeckt und es gibt noch keinen VT dafür. Lösung: den Greenbone Enterprise Support kontaktieren und nach einem neuen VT fragen oder ob bereits einer geplant ist.
• Die spezifische Erkennung ist veraltet. Lösung: den Greenbone Enterprise Support kontaktieren.

Warum unterscheiden sich die Ergebnisse für dasselbe Ziel über mehrere aufeinanderfolgende Scans?

Die Ergebnisse aufeinanderfolgender Scans können aus den folgenden Gründen abweichen (Handbuchabschnitt 20.5):

• Es gab einen Verbindungsverlust über unzuverlässige Netzwerkverbindungen (zwischen dem Scanner-Host und dem Ziel).
• Die Netzwerkverbindung oder -ausrüstung (zwischen dem Scanner-Host und dem Ziel) war überlastet.
• Ein überlasteter Ziel-Host und/oder -Dienst hat aufgehört zu reagieren.
• "Fragile" Protokolle (z. B. Remote Desktop Protocol) reagieren nicht immer wie erwartet.
• Eine vorherige Probe-/Angriffsanfrage führte dazu, dass der Dienst für eine kurze Zeit nicht reagierte.

Obwohl der Scanner versucht, das Auftreten solcher Situationen durch interne Wiederholungsroutinen zu reduzieren, können sie nicht vollständig ausgeschlossen werden.

Warum ist es nicht möglich, Scan-Konfigurationen, Portlisten, Compliance-Policies oder Berichtsformate zu bearbeiten?

Scan-Konfigurationen, Portlisten, Compliance-Policies und Berichtsformate von Greenbone (die "Objekte") werden über den Feed verteilt. Diese Objekte müssen einem Benutzer gehören, dem Feed Import Owner. Die Objekte werden während eines Feed-Updates heruntergeladen und aktualisiert, sofern ein Feed Import Owner festgelegt wurde. Die Objekte können nicht bearbeitet werden. Dies ist beabsichtigt, um sicherzustellen, dass die Objekte so funktionieren, wie von Greenbone vorgesehen (Handbuchabschnitt 20.6).

Warum ist es nicht möglich, Scan-Konfigurationen, Portlisten, Compliance-Policies oder Berichtsformate zu löschen?

Dieselben Greenbone-Objekte werden über den Feed verteilt und müssen dem Feed Import Owner gehören. Nur der Feed Import Owner, ein Super-Administrator und Benutzer, die entsprechende Rechte erhalten haben, können Objekte löschen. Wenn Objekte gelöscht werden, werden sie beim nächsten Feed-Update erneut heruntergeladen. Wenn keine Objekte heruntergeladen werden sollen, muss der Feed Import Owner zurückgesetzt werden (Handbuchabschnitt 20.7).

Warum erscheint ein VNC-Dialog auf dem gescannten Zielsystem?

Beim Testen von Port 5900 oder beim Konfigurieren eines VNC-Ports erscheint auf dem gescannten Zielsystem ein Fenster, das den Benutzer auffordert, die Verbindung zuzulassen. Dies wurde bei UltraVNC Version 1.0.2 beobachtet. Lösung: Port 5900 oder andere konfigurierte VNC-Ports aus der Zielspezifikation ausschließen. Alternativ würde ein Upgrade auf eine neuere Version von UltraVNC helfen (UltraVNC 1.0.9.6.1 nutzt nur Balloons, um Benutzer zu informieren) (Handbuchabschnitt 20.8).

Warum löst der Scan Alarme bei anderen Sicherheitstools aus?

Bei vielen Schwachstellentests wird das Verhalten echter Angriffe angewandt. Auch wenn kein echter Angriff stattfindet, geben einige Sicherheitstools einen Alarm aus. Ein bekanntes Beispiel: Symantec meldet Angriffe bezüglich CVE-2009-3103, wenn der VT Microsoft Windows SMB2 '_Smb2ValidateProviderCallback()' Remote Code Execution Vulnerability (1.3.6.1.4.1.25623.1.0.100283) ausgeführt wird. Dieser VT wird nur ausgeführt, wenn der Radio-Button No für safe_checks in den Scanner-Einstellungen ausgewählt ist; andernfalls kann das Zielsystem beeinträchtigt werden (Handbuchabschnitt 20.9).

Wie kann ein Factory Reset der Appliance durchgeführt werden?

Ein Factory Reset kann durchgeführt werden, um Benutzerdaten sicher von der Appliance zu löschen. Kontaktiere den Greenbone Enterprise Support, um eine detaillierte Anleitung zur Durchführung eines Factory Reset zu erhalten (Handbuchabschnitt 20.10).

Warum funktioniert nach einem Factory Reset weder das Feed-Update noch das GOS-Upgrade?

Ein Factory Reset löscht das gesamte System, einschließlich des Subscription-Keys des Greenbone Enterprise Feed. Der Subscription-Key ist für Feed-Updates und das GOS-Upgrade obligatorisch (Handbuchabschnitt 20.11):

1. Den Subscription-Key reaktivieren. Mit jeder Appliance wird ein Backup-Key geliefert. Verwende diesen Key, um die Appliance zu reaktivieren. Die Aktivierung ist im Setup-Guide des jeweiligen Appliance-Modells beschrieben.
2. Das System auf die aktuelle Version aktualisieren. Je nach GOS-Version muss die jeweilige Upgrade-Prozedur ausgeführt werden.

Wie kann ein älteres Backup oder Beaming-Image wiederhergestellt werden?

Nur Backups und Beaming-Images, die mit der aktuell verwendeten GOS-Version oder der vorherigen GOS-Version erstellt wurden, können wiederhergestellt werden. Für GOS 22.04 können nur Backups und Beaming-Images von GOS 21.04 oder GOS 22.04 importiert werden. Falls ein älteres Backup oder Beaming-Image (z. B. von GOS 6 oder GOS 20.08) importiert werden soll, muss eine Appliance mit einer passenden GOS-Version verwendet werden. Backups und Beaming-Images von GOS-Versionen, die neuer als die aktuell verwendete GOS-Version sind, werden ebenfalls nicht unterstützt; falls ein neueres Backup oder Beaming-Image importiert werden soll, muss eine Appliance mit einer passenden GOS-Version verwendet werden. Bei Fragen kontaktiere den Greenbone Enterprise Support (Handbuchabschnitt 20.12).

Was kann getan werden, wenn das GOS-Administrationsmenü in PuTTY nicht korrekt angezeigt wird?

Überprüfe die Einstellungen in PuTTY, indem du im linken Bereich Window > Translation auswählst. In der Drop-down-Liste Remote character set muss UTF-8 ausgewählt sein (Handbuchabschnitt 20.13).

Wie kann der GMP-Status ohne Verwendung von Zugangsdaten geprüft werden?

Die Vorgehensweise ist (Handbuchabschnitt 20.14):

1. Baue über die Kommandozeile eine SSH-Verbindung zur Appliance auf, indem du den GMP-Benutzer verwendest. Ersetze den Platzhalter durch die IP-Adresse oder den DNS-Namen der Appliance.

   ssh gmp@<appliance>

   Es wird kein Eingabeprompt angezeigt, der Befehl kann dennoch eingegeben werden.

2. Gib den Befehl für die Versionsanfrage ein:

   <get_version/>

   Wenn GMP aktiviert ist, sollte die Ausgabe so aussehen:

   <get_version_response status="200" status_text="OK"><version>8.0</version></get_version_response>

Was sollte getan werden, wenn der Selbsttest "RAID Array degraded" anzeigt?

Die Appliance-Modelle Greenbone Enterprise 6500/6400/5400/5300 verwenden RAID (Redundant Array of Independent Disks) 6 als Software-RAID. RAID ist eine Datenspeicher-Virtualisierungstechnologie, die mehrere Festplattenlaufwerk-Komponenten (HDD) zu einer oder mehreren logischen Einheiten zum Zweck der Datenredundanz kombiniert. Für RAID 6 sind mindestens 4 HDDs erforderlich, damit das RAID — und damit die Datenredundanz — funktioniert. Die Appliance selbst funktioniert weiterhin, wenn bis zu 2 HDDs ausfallen (Handbuchabschnitt 20.15).

Wenn eine oder mehrere HDDs ausfallen, zeigt GOS die Selbsttest-Warnungen RAID Array degraded (mit dem Hinweis Replace the failed disk) und Check for system integrity status (mit dem Hinweis The system integrity may be endangered. Please contact the support.) an. Die Integritätsprüfung schlägt aufgrund der ausgefallenen HDD(s) fehl. Ausgefallene HDDs müssen ersetzt und das RAID muss repariert werden. Kontaktiere den Greenbone Enterprise Support für Unterstützung.

3. Glossar

Dieses Glossar definiert die relevante Terminologie, die durchgängig im gesamten System verwendet wird (Handbuchkapitel 21).

Begriff	Definition
Alert	Eine Aktion, die durch bestimmte Ereignisse ausgelöst werden kann. In den meisten Fällen bedeutet das die Ausgabe einer Benachrichtigung, z. B. einer E-Mail bei neu gefundenen Schwachstellen.
Asset	Elemente, die während eines Schwachstellen-Scans im Netzwerk entdeckt oder vom Benutzer manuell eingetragen wurden. Derzeit umfassen Assets Hosts und Betriebssysteme.
CERT-Bund Advisory	Ein vom CERT-Bund veröffentlichtes Advisory.
Compliance Audit	Ein Scan-Task mit dem Flag audit, der zur Prüfung der Erfüllung von Compliances verwendet wird.
Compliance Policy	Eine Scan-Konfiguration mit dem Flag policy, die zur Prüfung der Erfüllung von Compliances verwendet wird.
CPE	Common Platform Enumeration: ein strukturiertes Benennungsschema für IT-Systeme, -Plattformen und -Pakete. Basierend auf der generischen Syntax für Uniform Resource Identifiers (URI) umfasst CPE ein formales Namensformat, eine Sprache zur Beschreibung komplexer Plattformen, eine Methode zum Abgleich von Namen gegen ein System und ein Beschreibungsformat zur Bindung von Text und Tests an einen Namen. Ein CPE-Name beginnt mit cpe:/, gefolgt von bis zu sieben durch Doppelpunkte getrennten Komponenten: Part (h, o oder a), Vendor, Product, Version, Update, Edition und Language. Beispiel: cpe:/o:linux:kernel:2.6.0.
CVE	Common Vulnerabilities and Exposures: ein Verzeichnis öffentlich bekannter Schwachstellen und Exposures der Informationssicherheit.
CVSS	Das Common Vulnerability Scoring System: ein offenes Framework zur Charakterisierung von Schwachstellen.
DFN-CERT Advisory	Ein vom DFN-CERT veröffentlichtes Advisory.
Filter	Eine Beschreibung, wie eine bestimmte Teilmenge aus einer Gruppe von Ressourcen ausgewählt wird.
Group	Eine Sammlung von Benutzern.
Host	Ein einzelnes System, das mit einem Computernetzwerk verbunden ist und gescannt werden kann. Ein oder viele Hosts bilden die Grundlage eines Scan-Ziels. Ein Host ist auch ein Asset-Typ; jeder gescannte oder entdeckte Host kann in der Asset-Datenbank erfasst werden. Hosts in Scan-Zielen und Berichten werden über ihre Netzwerkadresse (IP-Adresse oder Hostname) identifiziert. In der Asset-Datenbank ist die Identifikation unabhängig von der tatsächlichen Netzwerkadresse, die jedoch als Standard-Identifikation verwendet wird.
Note	Ein textueller Kommentar, der mit einem VT verknüpft ist. Notes erscheinen in Berichten, unterhalb der vom VT erzeugten Ergebnisse. Eine Note kann auf ein bestimmtes Ergebnis, einen Task, eine Schwere, einen Port und/oder einen Host angewendet werden, sodass die Note nur in bestimmten Berichten erscheint.
Vulnerability Test (VT)	Eine Routine, die ein Zielsystem auf das Vorhandensein eines bestimmten bekannten oder potenziellen Sicherheitsproblems prüft. VTs sind in Familien ähnlicher VTs gruppiert; die Auswahl von Familien und/oder einzelnen VTs ist Teil einer Scan-Konfiguration.
Override	Eine Regel zur Änderung der Schwere von Elementen innerhalb eines oder mehrerer Berichte. Overrides sind besonders nützlich, um Berichtselemente als False Positives zu kennzeichnen (z. B. einen fehlerhaften oder erwarteten Befund) oder um Elemente hervorzuheben, die im beobachteten Szenario eine höhere Schwere haben.
Permission	Eine Gewährung, die einem Benutzer, einer Rolle oder einer Gruppe das Recht gibt, eine bestimmte Aktion durchzuführen.
Port List	Eine Liste von Ports. Jedes Target ist mit einer Portliste verknüpft, die bestimmt, welche Ports während eines Scans des Targets gescannt werden.
Quality of Detection (QoD)	Ein Wert zwischen 0 % und 100 %, der die Zuverlässigkeit der durchgeführten Schwachstellen- oder Produkterkennung beschreibt. Der Wert von 70 % ist das Standard-Minimum, das zum Filtern der angezeigten Ergebnisse in Berichten verwendet wird.
Remediation Ticket	Ein Ticket zur Behebung der Befunde von Schwachstellen. Tickets können dem aktuellen Benutzer oder anderen Benutzern zugewiesen werden, wobei alle wertvollen Informationen quervernetzt und für den zugewiesenen Benutzer verfügbar sind. Alle Tickets haben einen bestimmten Status (z. B. offen, behoben), um den Fortschritt zu verfolgen. Alerts können für bestimmte Ticket-Ereignisse zugewiesen werden (z. B. eine Statusänderung). Das Ticket-Management-System kann die Wiederholung von Scans automatisch berücksichtigen, um zu verifizieren, dass das Problem gelöst wurde.
Report	Das Ergebnis eines Scans, das eine Zusammenfassung dessen enthält, was die ausgewählten VTs für jeden der Ziel-Hosts erkannt haben. Ein Report ist immer mit einem Task verknüpft. Die Scan-Konfiguration, die den Umfang des Reports bestimmt, ist Teil des zugehörigen Tasks und kann nicht geändert werden, was sicherstellt, dass die Ausführungskonfiguration erhalten bleibt und verfügbar ist.
Report Format	Ein Format, in dem ein Report heruntergeladen werden kann. Ein Beispiel ist TXT, das den Content Type "text/plain" hat, was bedeutet, dass der Report ein reines Textdokument ist.
Result	Ein einzelnes vom Scanner als Teil eines Reports erzeugtes Ergebnis, zum Beispiel eine Schwachstellenwarnung oder eine Log-Meldung.
Role	Eine Definition einer Reihe von Berechtigungen, die auf einen Benutzer oder eine Gruppe angewendet werden können.
Scan	Ein Task in Ausführung. Für jeden Task kann nur ein Scan aktiv sein, und das Ergebnis eines Scans ist ein Report. Der Status aller aktiven Scans ist auf der Seite Tasks zu sehen, wo der Fortschritt als Prozentsatz der Gesamtzahl der auszuführenden Tests angezeigt wird. Die Scan-Dauer hängt von der Anzahl der Targets und der Komplexität der Scan-Konfiguration ab und reicht von Minuten bis zu vielen Stunden oder sogar Tagen. Die Seite Tasks bietet eine Option, einen Scan zu stoppen; wenn ein gestoppter oder unterbrochener Scan fortgesetzt wird, werden alle nicht abgeschlossenen Hosts vollständig neu gescannt, während die Daten bereits vollständig gescannter Hosts erhalten bleiben.
Scanner	Ein OpenVAS-Scanner-Daemon oder ein kompatibler OSP-Daemon, auf dem der Scan ausgeführt wird.
Scan Configuration	Die Auswahl von VTs sowie allgemeine und sehr spezifische (Experten-)Parameter für den Scan-Server und für einige der VTs. Nicht von einer Scan-Konfiguration abgedeckt ist die Auswahl der Targets.
Schedule	Eine Einstellung der Zeit, zu der ein Task automatisch gestartet werden soll, eines Zeitraums, nach dem der Task erneut laufen soll, und einer maximalen Dauer, die der Task in Anspruch nehmen darf.
Severity	Ein Wert zwischen 0.0 (keine Schwere) und 10.0 (höchste Schwere), der auch eine Schwereklasse (Log, Low, Medium oder High) ausdrückt. Das Konzept basiert auf CVSS, wird aber auch angewendet, wenn kein vollständiger CVSS-Base-Vector verfügbar ist. Die Klassen werden durch Teilbereiche des Hauptbereichs 0.0–10.0 definiert; Benutzer können verschiedene Klassifizierungen auswählen, wobei der Standard die NVD-Klassifizierung ist. Scan-Ergebnissen wird beim Erreichen eine Schwere zugewiesen; wenn in den Benutzereinstellungen Dynamic Severity ausgewählt ist, verwendet das System für die Ergebnisse stets die aktuellsten Schweren der VTs.
Solution Type	Information, die mögliche Lösungen zur Behebung der Schwachstelle aufzeigt. Typen sind: Workaround (ein Konfigurations- oder Deployment-Szenario zur Vermeidung der Exposition, üblicherweise die "erste Verteidigungslinie"); Mitigation (ein Konfigurations- oder Deployment-Szenario, das das Risiko reduziert, aber die Schwachstelle nicht behebt); Vendor fix (ein offizieller Fix des ursprünglichen Autors, der die Schwachstelle vollständig behebt, sofern nicht anders vermerkt); No fix available (derzeit kein Fix verfügbar); und Will not fix (kein Fix existiert und wird je existieren, oft bei verwaisten, nicht gepflegten oder abgekündigten Produkten).
Tag	Ein kurzes Datenpaket aus einem Namen und einem Wert, das an eine Ressource beliebiger Art angehängt wird und benutzerdefinierte Informationen zu dieser Ressource enthält.
Target	Eine Definition einer Reihe von Systemen (Hosts), die gescannt werden. Die Systeme werden über ihre IP-Adressen, ihre Hostnamen oder mit CIDR-Netzwerknotation identifiziert.
Task	Eine Entität, die zunächst aus einem Target und einer Scan-Konfiguration gebildet wird. Die Ausführung eines Tasks initiiert einen Scan, und jeder Scan erzeugt einen Report, sodass ein Task eine Reihe von Reports sammelt. Target und Scan-Konfiguration eines Tasks sind statisch, sodass die resultierende Abfolge von Reports die Veränderung des Sicherheitsstatus über die Zeit beschreibt. Ein Task kann als alterable markiert werden, wenn keine Reports vorhanden sind, was es erlaubt, sein Target und seine Scan-Konfiguration jederzeit zu ändern. Ein Container-Task ist ein Task, dessen Funktion das Halten importierter Reports ist; das Ausführen eines Container-Tasks ist nicht möglich.
TLS Certificate	Ein TLS-Zertifikat (Transport Layer Security), das zur Authentifizierung beim Aufbau einer durch TLS gesicherten Verbindung verwendet wird. Der Scan-Report enthält alle während eines Schwachstellen-Scans gesammelten TLS-Zertifikate.

Verwandt

• Greenbone-/OpenVAS-Guide
• Appliance Setup
• GOS Administration