19 Architecture#

19.1 GOS Architecture#

The Greenbone Operating System (GOS) is the operating system of the Greenbone Enterprise Appliance. Here is an architecture overview for GOS 22.04.

_images/GOS_architecture.png

Fig. 19.1 GOS 22.04 architecture#

The GOS control layer provides access to the administration of the Greenbone Operating System (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 (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.

The Greenbone Community Edition 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 (VT) 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 Open Scanner Protocol (OSP). It 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 also controls an SQL database (PostgreSQL) where all configuration and scan result data is centrally stored. Furthermore, gvmd also handles user management including permissions control with groups and roles. And finally, 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 that a user controls scans and accesses vulnerability information with. 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 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 free 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. This is 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.

19.2 Protocols#

There are mandatory and optional protocols. Some protocols are only used in specific setups.

The appliance requires several protocols to fully function. These protocols provide the feed updates, Domain Name System (DNS) resolution, time, etc.

19.2.1 Appliance as a Client#

_images/appliance_acting_as_client.png

Fig. 19.2 Appliance acting as a client#

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

DNS – Name resolution

  • Connecting to 53/udp and 53/tcp

  • Mandatory

  • Not encrypted

  • May use internal DNS server

NTP – Time synchronization

  • Connecting to 123/udp

  • Mandatory

  • Not encrypted

  • May use internal NTP server

Feeds (see below)

  • Direct

    • Connecting to 24/tcp or 443/tcp

    • Direct internet access required

  • Via proxy

    • Connecting to internal HTTP proxy supporting CONNECT method on configurable port

  • Connecting to apt.greenbone.net and feed.greenbone.net

  • Mandatory on stand-alone and master appliances

  • Used protocol is SSH

  • Encrypted and bidirectionally authenticated via SSH

    • Server: public key

    • Client: public key

DHCP

  • Connecting to 67/udp and 68/udp

  • Optional

  • Not encrypted

LDAPS – User authentication

  • Connecting to 636/tcp

  • Optional

  • Encrypted and authenticated via SSL/TLS

    • Server: certificate

    • Client: user name/password

Syslog – Remote logging and alerts

  • Connecting to 512/udp or 512/tcp

  • Optional

  • Not encrypted

SNMP traps for alerts

  • Connecting to 162/udp

  • Optional

  • Only SNMPv1

  • Not encrypted

SMTP(S) for e-mail alerts

  • Connecting to 465/tcp for SMTPS, 25/tcp for SMTP, alternatively connecting to 587/tcp

  • Optional

  • SMTPS can be enforced to always be used

  • Encrypted via STARTTLS, if SMTPS is not enforced

  • Not encrypted, if encryption via STARTTLS is not possible

SSH for backup

  • Connecting to 22/tcp

  • Optional

  • Encrypted and bidirectionally authenticated via SSH

    • Server: public key

    • Client: public key

Cisco Firepower (Sourcefire) for IPS integration

  • Connecting to 8307/tcp

  • Optional

  • Encrypted and bidirectionally authenticated via SSL/TLS

    • Server: certificate

    • Client: certificate

verinice.PRO

  • Connecting to 443/tcp

  • Optional

  • Encrypted via SSL/TLS

    • Server: optional via certificate

    • Client: user name/password

TippingPoint SMS

  • Connecting to 443/tcp

  • Optional

  • Encrypted via SSL/TLS

    • Server: certificate

    • Client: certificate, user name/password

19.2.2 Appliance as a Server#

_images/appliance_acting_as_a_server.png

Fig. 19.3 Appliance acting as a server#

The following connections are supported by an appliance acting as a server:

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

19.2.3 Master-Sensor Setup#

_images/Master_Sensor_Communication.png

Fig. 19.4 Appliance master and sensor#

In a master-sensor setup the following additional requirements apply. The master (server) initiates up to three additional connections to the sensor (client):

SSH for GOS upgrades, feed updates, GMP and OSP

  • 22/tcp

  • Mandatory

  • Encrypted and bidirectionally authenticated via SSH

    • Server: public key

    • Client: public key

19.3 Security Gateway Considerations#

Many enterprises deploy security gateways to restrict the internet access. These security gateways can operate as packet filters or application layer gateways.

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.

19.3.1 Stand-Alone/Master Appliance#

While many protocols used by the appliance are only used internally, some protocols require access to the internet. These protocols may be filtered by such a security gateway.

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 access directly via port 24/tcp or 443/tcp or using a proxy.

Note

In all cases the used protocol is SSH, even when using the port 443/tcp or a 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 of 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.

19.3.2 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.