Architecture, FAQ & Glossary

What this covers

This page is reference material drawn from chapters 19–21 of the Greenbone Enterprise Appliance manual: the architecture of the Greenbone Operating System (GOS), the network protocols used by the appliance, security gateway considerations, a faithful reproduction of the frequently asked questions, and a glossary of the terminology used consistently across the system.

Source scope

Based on the Greenbone Enterprise Appliance manual (GOS 22.04 / OPENVAS SCAN 22.04), chapters 19–21. Verified June 2026. Chapter references in parentheses point back to the relevant manual sections.

1. Architecture

GOS architecture

The Greenbone Operating System (GOS) is the operating system of the Greenbone Enterprise Appliance (manual section 19.1).

The GOS control layer provides access to the administration of GOS. Only a single system administrator account is supported. The system administrator cannot modify system files directly but can instruct the system to change configurations.

GOS is managed using a menu-based graphical interface (the GOS administration menu). The system administrator is not required to use the command line (shell) for configuration or maintenance tasks. Shell access is provided for support and troubleshooting purposes only.

Accessing the system level requires either console access (serial, hypervisor or monitor/keyboard) or a connection via SSH.

GOS allows users to configure, start, and stop all services of the Greenbone Community Edition.

Greenbone Community Edition

The Greenbone Community Edition consists of a framework with several services. It is developed as part of the Greenbone Enterprise products. It was originally built as a community project named "OpenVAS" and is primarily developed and forwarded by Greenbone. It consists of the Greenbone Vulnerability Management Daemon (gvmd), the Greenbone Security Assistant (GSA) with the Greenbone Security Assistant Daemon (gsad), and the executable scan application that runs vulnerability tests (VTs) against target systems.

The Greenbone Community Edition is released under open-source licenses. By using it, Linux distributions can create and provide the software components in the form of installation packages.

Greenbone Vulnerability Management Daemon (gvmd)

The Greenbone Vulnerability Management Daemon (gvmd) — also called Greenbone Vulnerability Manager — is the central service that consolidates plain vulnerability scanning into a full vulnerability management solution.

• gvmd controls the OpenVAS Scanner via the Open Scanner Protocol (OSP). OSP is XML-based, stateless, and does not require a permanent connection for communication.
• The service itself offers the XML-based Greenbone Management Protocol (GMP).
• gvmd controls an SQL database (PostgreSQL) where all configuration and scan result data is centrally stored.
• gvmd handles user management, including permissions control with groups and roles.
• The service has an internal runtime system for scheduled tasks and other events.

Greenbone Security Assistant (GSA)

The Greenbone Security Assistant (GSA) is the web interface with which a user controls scans and accesses vulnerability information. It is the main contact point for a user with the appliance. It connects to gvmd via the web server Greenbone Security Assistant Daemon (gsad) to provide a full-featured web application for vulnerability management. The communication occurs using the Greenbone Management Protocol (GMP), with which the user can also communicate directly by using different tools.

OpenVAS Scanner

The main scanner, the OpenVAS Scanner, is a full-featured scan engine that executes vulnerability tests (VTs) against target systems. For this, it uses the daily updated and comprehensive feeds: the full-featured, extensive, commercial Greenbone Enterprise Feed, or the freely available Greenbone Community Feed.

The scanner consists of the components ospd-openvas and openvas-scanner. The OpenVAS Scanner is controlled via OSP. The OSP Daemon for the OpenVAS Scanner (ospd-openvas) communicates with gvmd via OSP: VT data is collected, scans are started and stopped, and scan results are transferred to gvmd via ospd.

Notus Scanner

The Notus scanner scans during every regular scan, so no user interaction is necessary. It offers better performance due to less system resource consumption and thus faster scanning.

The Notus scanner replaces the logic of potentially all NASL-based local security checks (LSCs). A comparison of installed software on a host against a list of known vulnerable software is done instead of running a VT script for each LSC.

The regular OpenVAS Scanner loads each NASL LSC individually and executes it one by one for every host; a single known vulnerability is then compared with the installed software, repeated for all LSCs. With the Notus scanner, the list of installed software is loaded in the same way but is directly compared with all known vulnerable software for the operating system of the scanned host. This eliminates the need to run the LSCs because the information about the known vulnerable software is collected in one single list and not distributed in individual NASL scripts.

GMP clients

The Greenbone Vulnerability Management Tools (gvm-tools) are a collection of tools that help with remote controlling a Greenbone Enterprise Appliance and its underlying Greenbone Vulnerability Management Daemon (gvmd). The tools aid in accessing the communication protocols GMP (Greenbone Management Protocol) and OSP (Open Scanner Protocol).

This module is comprised of interactive and non-interactive clients. The programming language Python is supported directly for interactive scripting, but it is also possible to issue remote GMP/OSP commands without programming in Python.

Protocols

There are mandatory and optional protocols; some protocols are only used in specific setups (manual section 19.2). The appliance requires several protocols to fully function. These protocols provide the feed updates, Domain Name System (DNS) resolution, time, and so on.

Appliance as a client

The following protocols are used by a stand-alone system or a master appliance to initiate connections as a client (manual section 19.2.1):

Protocol	Port(s)	Mandatory	Encryption / authentication
DNS — name resolution	53/udp, 53/tcp	Mandatory	Not encrypted; may use internal DNS server
NTP — time synchronization	123/udp	Mandatory	Not encrypted; may use internal NTP server
Feeds (direct)	24/tcp or 443/tcp	Mandatory on stand-alone and master appliances	SSH; encrypted and bidirectionally authenticated (server: public key; client: public key); direct internet access required
Feeds (via proxy)	internal HTTP proxy supporting the CONNECT method on a configurable port	Mandatory on stand-alone and master appliances	SSH; encrypted and bidirectionally authenticated
DHCP	67/udp, 68/udp	Optional	Not encrypted
LDAPS — user authentication	636/tcp	Optional	Encrypted and authenticated via SSL/TLS (server: certificate; client: user name/password)
Syslog — remote logging and alerts	512/udp or 512/tcp	Optional	Not encrypted
SNMP traps for alerts	162/udp	Optional	Only SNMPv1; not encrypted
SMTP(S) for e-mail alerts	465/tcp (SMTPS), 25/tcp (SMTP), alternatively 587/tcp	Optional	SMTPS can be enforced; otherwise encrypted via STARTTLS, or not encrypted if STARTTLS is not possible
SSH for backup	22/tcp	Optional	Encrypted and bidirectionally authenticated via SSH (server: public key; client: public key)
Cisco Firepower (Sourcefire) for IPS integration	8307/tcp	Optional	Encrypted and bidirectionally authenticated via SSL/TLS (server: certificate; client: certificate)
verinice.PRO	443/tcp	Optional	Encrypted via SSL/TLS (server: optional via certificate; client: user name/password)
TippingPoint SMS	443/tcp	Optional	Encrypted via SSL/TLS (server: certificate; client: certificate, user name/password)

Connections for feeds are made to apt.greenbone.net and feed.greenbone.net.

Appliance as a server

The following connections are supported by an appliance acting as a server (manual section 19.2.2):

Protocol	Port	Mandatory	Encryption / authentication
HTTPS — web interface	443/tcp	Mandatory on stand-alone and master appliances	Encrypted and authenticated via SSL/TLS (server: optional via certificate; client: user name/password)
SSH — CLI access and GMP	22/tcp	Optional	Encrypted and authenticated via SSH (server: public key; client: user name/password)
SNMP	161/udp	Optional	Optionally encrypted when using SNMPv3

Master-sensor setup

In a master-sensor setup, the following additional requirement applies. The master (server) initiates up to three additional connections to the sensor (client) (manual section 19.2.3):

Protocol	Port	Mandatory	Encryption / authentication
SSH for GOS upgrades, feed updates, GMP and OSP	22/tcp	Mandatory	Encrypted and bidirectionally authenticated via SSH (server: public key; client: public key)

Security gateway considerations

Many enterprises deploy security gateways to restrict internet access. These security gateways can operate as packet filters or application layer gateways (manual section 19.3). Some products support deep inspection and try to determine the actual protocol used in the communication channels. They may even try to decrypt and analyze any encrypted communication.

Stand-alone / master appliance

While many protocols used by the appliance are only used internally, some require access to the internet and may be filtered by such a security gateway (manual section 19.3.1).

When deploying the appliance as a stand-alone appliance or as a master, the appliance must be able to access the Greenbone Enterprise Feed. The Greenbone Enterprise Feed can be accessed directly via port 24/tcp or 443/tcp, or using a proxy.

note

In all cases the protocol used is SSH, even when using port 443/tcp or an HTTP proxy.

A deep inspection firewall may detect the usage of the SSH protocol running on port 443/tcp and drop or block the traffic. If the security gateway tries to decrypt the traffic using man-in-the-middle techniques, the communication between the appliance and the feed server fails. The SSH protocol, using bidirectional authentication based on public keys, prevents any man-in-the-middle approaches by terminating the communication.

Additional protocols which need internet access are DNS and NTP. Both DNS and NTP can be configured to use internal DNS and NTP servers.

Sensor appliance

If security gateways are deployed between the master and the sensor, the security gateway must permit SSH (22/tcp) connections from the master to the sensor (manual section 19.3.2).

2. Frequently Asked Questions

Why is the scanning process so slow?

The performance of a scan depends on various aspects (manual section 20.1):

• Several port scanners were activated concurrently. If an individual scan configuration is used, select only a single port scanner in the VT family Port scanners. The VT Ping Host can still be activated.
• Unused IP addresses are scanned very time-consuming. As a first step, it is detected whether an active system is present for each IP address. If not, that IP address will not be scanned. Firewalls and other systems can prevent a successful detection. The VT Ping Host (1.3.6.1.4.1.25623.1.0.100315) in the VT family Port scanners offers fine-tuning of the detection.
• The ports to be scanned resulted in port throttling, or UDP port scanning has been chosen.

What influences the scan capacity?

The scan capacity — the scannable number of IP addresses per 24 hours — depends on the appliance model. The provided values for estimated scan capacity can only be understood as guide values, as the scan capacity is influenced by many factors (manual section 20.2):

• Complexity of the used scan configuration. In the same amount of time, many more discovery scans can be performed than vulnerability scans.
• Using the appliance outside its specifications. Starting too many scans or scanning too many targets at once can result in performance problems.
• Performance of the network infrastructure and the target system(s). If systems are slow to respond to network requests, the scanning process will be slower.
• Type of the scanned target system(s). The type determines which and how many vulnerability tests are executed during a scan; more vulnerability tests usually mean slower scans. Some scenarios increase resource usage and can impact performance, e.g., scanning of virtual hosts (vhosts) and scanning of web servers with CGI caching enabled.
• Using the appliance in parallel while scanning. If other resource-intensive operations (e.g., feed updates, generation of large reports) are running, less system resources are available for scans.
• Using sensors. Using sensors can increase the scannable IP addresses per 24 hours.

Why is a service/product not detected?

The following causes and solutions apply (manual section 20.3):

• The target is not detected as online/reachable. Solutions: fix the network setup/routing to the target; update the criteria/test configuration to detect the target as alive; ensure that the scan configuration includes the VTs Nmap (NASL wrapper) (OID 1.3.6.1.4.1.25623.1.0.14259) and Ping Host (OID 1.3.6.1.4.1.25623.1.0.100315) from the VT family Port scanners; verify and remove any network device (firewall, IDS/IPS, WAF, etc.) between the scanner and the target, or any security mechanisms on the target itself, and whitelist the scanner's IP address.
• The service/product is running on a specific port not included in the port list. Solution: create a suitable port list. This is especially important for UDP ports.
• There is a detection VT for a service/product available, but the service/product is not found during a scan. Solutions: fix the network setup/routing to the target; update the criteria/test configuration to detect the target as alive; verify and remove any network device between the scanner and the target (and whitelist the scanner's IP address); create a suitable port list (especially for UDP ports); if those do not help, contact Greenbone Enterprise Support and provide more information about the service/product (product name, specific version running, etc.).
• The target is not stable/responds slowly during a scan. Solutions: lower the concurrently executed VTs; update the service/product to a newer version (e.g., to fix triggered bugs); assign more resources (CPU, RAM, etc.) to the target to make it more stable during scans.

Why is a vulnerability not detected?

The following causes and solutions apply (manual section 20.4):

• The affected service/product is not detected at all. Solution: see the answer for "Why is a service/product not detected?".
• The service/product was detected but a version extraction was not possible. Solutions: perform an authenticated scan; if that does not help, contact Greenbone Enterprise Support with more information about the service/product.
• There is only a version check with a lower Quality of Detection (QoD) and the vulnerability is not displayed by default. Solutions: change the QoD value in the results filter; perform an authenticated scan.
• If an authenticated scan was carried out, the login has failed. Solutions: check the correctness of the used credentials; verify that the user is not blocked; verify that the user is allowed to log in to the target; if those do not help, contact Greenbone Enterprise Support with more information.
• The service/product itself crashed or stopped responding during the scan. Solutions: lower the concurrently executed VTs; update the service/product to a newer version; assign more resources (CPU, RAM, etc.) to the target.
• The vulnerability was only recently discovered and there is no VT for it yet. Solution: contact Greenbone Enterprise Support and ask for a new VT or whether one is already planned.
• The specific detection became outdated. Solution: contact Greenbone Enterprise Support.

Why do the results for the same target differ across several consecutive scans?

The results of consecutive scans may differ due to the following reasons (manual section 20.5):

• There was a loss of connection over unreliable network connections (between the scanner host and the target).
• The network connection or equipment (between the scanner host and the target) was overloaded.
• An overloaded target host and/or service stopped responding.
• "Fragile" protocols (e.g., Remote Desktop Protocol) do not always respond as expected.
• A previous probe/attacking request caused the service to not respond for a short period of time.

Although the scanner tries to reduce the occurrence of such situations by internal retry routines, they cannot be ruled out completely.

Why is it not possible to edit scan configurations, port lists, compliance policies, or report formats?

Scan configurations, port lists, compliance policies, and report formats by Greenbone (the "objects") are distributed via the feed. These objects must be owned by a user, the Feed Import Owner. The objects are downloaded and updated during a feed update if a Feed Import Owner has been set. The objects cannot be edited. This is by design, to ensure that the objects function as intended by Greenbone (manual section 20.6).

Why is it not possible to delete scan configurations, port lists, compliance policies, or report formats?

These same Greenbone objects are distributed via the feed and must be owned by the Feed Import Owner. Only the Feed Import Owner, a super administrator, and users who obtained respective rights are able to delete objects. If objects are deleted, they will be downloaded again during the next feed update. If no objects should be downloaded, the Feed Import Owner must be unset (manual section 20.7).

Why does a VNC dialog appear on the scanned target system?

When testing port 5900 or configuring a VNC port, a window appears on the scanned target system asking the user to allow the connection. This was observed for UltraVNC version 1.0.2. Solution: exclude port 5900 or other configured VNC ports from the target specification. Alternatively, upgrading to a newer version of UltraVNC would help (UltraVNC 1.0.9.6.1 only uses balloons to inform users) (manual section 20.8).

Why does the scan trigger alarms on other security tools?

For many vulnerability tests, the behavior of real attacks is applied. Even though a real attack does not happen, some security tools will issue an alarm. A known example: Symantec reports attacks regarding CVE-2009-3103 if the VT Microsoft Windows SMB2 '_Smb2ValidateProviderCallback()' Remote Code Execution Vulnerability (1.3.6.1.4.1.25623.1.0.100283) is executed. This VT is only executed if the radio button No is selected for safe_checks in the scanner preferences; otherwise the target system can be affected (manual section 20.9).

How can a factory reset of the appliance be performed?

A factory reset can be performed to erase user data securely from the appliance. Contact Greenbone Enterprise Support to receive detailed instructions on how to perform a factory reset (manual section 20.10).

Why does neither feed update nor GOS upgrade work after a factory reset?

A factory reset deletes the whole system, including the Greenbone Enterprise Feed subscription key. The subscription key is mandatory for feed updates and GOS upgrade (manual section 20.11):

1. Reactivate the subscription key. A backup key is delivered with each appliance. Use this key to reactivate the appliance. The activation is described in the setup guide of the respective appliance model.
2. Update the system to the current version. Depending on the GOS version, the respective upgrade procedure has to be executed.

How can an older backup or beaming image be restored?

Only backups and beaming images created with the currently used GOS version or the previous GOS version can be restored. For GOS 22.04, only backups and beaming images from GOS 21.04 or GOS 22.04 can be imported. If an older backup or beaming image (e.g., from GOS 6 or GOS 20.08) should be imported, an appliance with a matching GOS version has to be used. Backups and beaming images from GOS versions newer than the currently used GOS version are not supported either; if a newer backup or beaming image should be imported, an appliance with a matching GOS version has to be used. For any questions, contact Greenbone Enterprise Support (manual section 20.12).

What can be done if the GOS administration menu is not displayed correctly in PuTTY?

Check the settings in PuTTY by selecting Window > Translation in the left panel. UTF-8 has to be selected in the drop-down list Remote character set (manual section 20.13).

How can the GMP status be checked without using credentials?

The procedure is (manual section 20.14):

1. Build an SSH connection to the appliance via command line using the GMP user. Replace the placeholder with the IP address or DNS name of the appliance.

   ssh gmp@<appliance>

   No input prompt is displayed, but the command can be entered nevertheless.

2. Enter the version request command:

   <get_version/>

   If GMP is activated, the output should look like:

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

What should be done if the self-check shows "RAID Array degraded"?

The appliance models Greenbone Enterprise 6500/6400/5400/5300 use RAID (Redundant Array of Independent Disks) 6 as a software RAID. RAID is a data storage virtualization technology that combines multiple hard disk drive (HDD) components into one or more logical units for the purposes of data redundancy. For RAID 6, at least 4 HDDs are required for the RAID — and thus the data redundancy — to function. The appliance itself will still function if up to 2 HDDs fail (manual section 20.15).

If one or more HDDs fail, GOS will show the self-check warnings RAID Array degraded (with the hint Replace the failed disk) and Check for system integrity status (with the hint The system integrity may be endangered. Please contact the support.). The integrity check fails due to the failed HDD(s). Failed HDDs must be replaced and the RAID must be repaired. Contact Greenbone Enterprise Support for assistance.

3. Glossary

This glossary defines relevant terminology which is used consistently across the entire system (manual chapter 21).

Term	Definition
Alert	An action which can be triggered by certain events. In most cases this means the output of a notification, e.g., an e-mail in case of new found vulnerabilities.
Asset	Items discovered on the network during a vulnerability scan or entered manually by the user. Currently, assets include hosts and operating systems.
CERT-Bund Advisory	An advisory published by CERT-Bund.
Compliance Audit	A scan task with the flag audit, used to check the fulfillment of compliances.
Compliance Policy	A scan configuration with the flag policy, used to check the fulfillment of compliances.
CPE	Common Platform Enumeration: a structured naming scheme for information technology systems, platforms and packages. Based on the generic syntax for Uniform Resource Identifiers (URI), CPE includes a formal name format, a language for describing complex platforms, a method for checking names against a system, and a description format for binding text and tests to a name. A CPE name starts with cpe:/, followed by up to seven colon-separated components: part (h, o or a), vendor, product, version, update, edition and language. Example: cpe:/o:linux:kernel:2.6.0.
CVE	Common Vulnerabilities and Exposures: a dictionary of publicly known information security vulnerabilities and exposures.
CVSS	The Common Vulnerability Scoring System: an open framework to characterize vulnerabilities.
DFN-CERT Advisory	An advisory published by DFN-CERT.
Filter	A description of how to select a certain subset from a group of resources.
Group	A collection of users.
Host	A single system that is connected to a computer network and that can be scanned. One or many hosts form the basis of a scan target. A host is also an asset type; any scanned or discovered host can be recorded in the asset database. Hosts in scan targets and reports are identified by their network address (IP address or host name). In the asset database the identification is independent of the actual network address, which is however used as the default identification.
Note	A textual comment associated with a VT. Notes show up in reports, below the results generated by the VT. A note can be applied to a particular result, task, severity, port and/or host, so that the note appears only in certain reports.
Vulnerability Test (VT)	A routine that checks a target system for the presence of a specific known or potential security problem. VTs are grouped into families of similar VTs; the selection of families and/or single VTs is part of a scan configuration.
Override	A rule to change the severity of items within one or many reports. Overrides are especially useful to mark report items as False Positives (e.g., an incorrect or expected finding) or to emphasize items that are of higher severity in the observed scenario.
Permission	A grant that gives a user, role or group the right to perform a specific action.
Port List	A list of ports. Each target is associated with a port list, which determines which ports are scanned during a scan of the target.
Quality of Detection (QoD)	A value between 0 % and 100 % describing the reliability of the executed vulnerability detection or product detection. The value of 70 % is the default minimum used for filtering the displayed results in reports.
Remediation Ticket	A ticket used to resolve the findings of vulnerabilities. Tickets can be assigned to the current user or other users, with all valuable information cross-linked and available for the assigned user. All tickets have a specific status (e.g., open, fixed) to track progress. Alerts can be assigned for certain ticket events (e.g., a status change). The ticket management system can automatically consider the repetition of scans in order to verify that the problem has been solved.
Report	The result of a scan, containing a summary of what the selected VTs detected for each of the target hosts. A report is always associated with a task. The scan configuration that determines the extent of the report is part of the associated task and cannot be modified, ensuring that the execution configuration is preserved and available.
Report Format	A format in which a report can be downloaded. An example is TXT, which has the content type "text/plain", meaning the report is a plain text document.
Result	A single result generated by the scanner as part of a report, for example a vulnerability warning or a log message.
Role	A definition of a set of permissions that can be applied to a user or a group.
Scan	A task in progress. For each task only one scan can be active, and the result of a scan is a report. The status of all active scans can be seen on the Tasks page, where progress is shown as a percentage of the total number of tests to be executed. Scan duration depends on the number of targets and the complexity of the scan configuration and ranges from minutes to many hours or even days. The Tasks page offers an option to stop a scan; if a stopped or interrupted scan is resumed, all unfinished hosts are scanned completely anew, while the data of hosts already fully scanned is kept.
Scanner	An OpenVAS Scanner daemon or compatible OSP daemon on which the scan will be run.
Scan Configuration	The selection of VTs as well as general and very specific (expert) parameters for the scan server and for some of the VTs. Not covered by a scan configuration is the selection of targets.
Schedule	A setting of the time when a task should be automatically started, a period after which the task should run again, and a maximum duration the task is allowed to take.
Severity	A value between 0.0 (no severity) and 10.0 (highest severity) that also expresses a severity class (Log, Low, Medium or High). The concept is based on CVSS but is also applied when no full CVSS Base Vector is available. The classes are defined by sub-ranges of the main range 0.0–10.0; users can select different classifications, with the default being the NVD classification. Scan results are assigned a severity while achieved; if Dynamic Severity is selected in the user settings, the system always uses the most current severities of VTs for the results.
Solution Type	Information showing possible solutions for the remediation of the vulnerability. Types are: Workaround (a configuration or deployment scenario to avoid exposure, usually the "first line of defense"); Mitigation (a configuration or deployment scenario that reduces risk but does not resolve the vulnerability); Vendor fix (an official fix issued by the original author, assumed to fully resolve the vulnerability unless noted); No fix available (no fix currently available); and Will not fix (no fix exists and none ever will, often for orphaned, unmaintained or deprecated products).
Tag	A short data package consisting of a name and a value that is attached to a resource of any kind and contains user-defined information on that resource.
Target	A definition of a set of systems (hosts) that is scanned. The systems are identified by their IP addresses, by their host names, or with CIDR network notation.
Task	An entity initially formed by a target and a scan configuration. Executing a task initiates a scan, and each scan produces a report, so a task collects a series of reports. A task's target and scan configuration are static, so the resulting sequence of reports describes the change of security status over time. A task can be marked as alterable when there are no reports present, allowing its target and scan configuration to be changed at any time. A container task is a task whose function is to hold imported reports; running a container task is not possible.
TLS Certificate	A TLS (Transport Layer Security) certificate used for authentication when establishing a connection secured by TLS. The scan report contains all TLS certificates collected during a vulnerability scan.

Related

• Greenbone / OpenVAS Guide
• Appliance Setup
• GOS Administration