18 Architektur

18.1 GOS-Architektur

Das Greenbone OS (GOS) ist das Betriebssystem der OPENVAS-SCAN-Appliance. Hier ist eine Architekturübersicht für GOS 24.10.

_images/GOS_architecture-de.png

Abb. 18.1 GOS-24.10-Architektur

Die GOS-Steuerungsebene ermöglicht den Zugriff auf die Administration des Greenbone OS (GOS). Nur ein einziger Systemadministrator wird unterstützt. Der Systemadministrator kann Systemdateien nicht direkt verändern, aber das System anweisen, Konfigurationen zu ändern.

GOS wird über eine menübasierte, grafische Oberfläche (GOS-Administrationsmenü) verwaltet. Der Systemadministrator muss nicht zwingend die Befehlszeile (Shell) für Konfigurations- oder Wartungsaufgaben nutzen. Zugriff auf die Shell ist nur für den Support und für die Fehlerbehebung vorgesehen.

Für den Zugriff auf die Systemebene wird entweder ein Konsolenzugriff (seriell, Hypervisor oder Monitor/Tastatur) oder eine SSH-Verbindung benötigt.

Mit GOS können Nutzer alle Dienste der OPENVAS COMMUNITY EDITION konfigurieren, starten und stoppen.

OPENVAS COMMUNITY EDITION

Die OPENVAS COMMUNITY EDITION besteht aus einem Framework mit verschiedenen Diensten. Sie wird als Teil der OPENVAS-Produkte von Greenbone entwickelt.

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 (VT) gegen Zielsysteme ausführt.

Die OPENVAS COMMUNITY EDITION wird unter Open-Source-Lizenzen veröffentlicht. Mit ihrer Hilfe 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 einfache Schwachstellenscans zu einer vollständigen Schwachstellenmanagement-Lösung zusammenführt. gvmd steuert den OpenVAS-Scanner über das Open Scanner Protocol (OSP). Es ist XML-basiert, zustandslos und benötigt keine dauerhafte Kommunikationsverbindung.

Der Dienst selbst stellt das XML-basierte Greenbone Management Protocol (GMP) (siehe Kapitel 14) zur Verfügung. gvmd steuert außerdem eine SQL-Datenbank (PostgreSQL), in der alle Konfigurations- und Scanergebnisdaten zentral gespeichert werden. Darüber hinaus übernimmt gvmd auch die Benutzerverwaltung inklusive der Berechtigungssteuerung mit Gruppen und Rollen. Außerdem verfügt der Dienst über ein internes Laufzeitsystem für geplante Aufgaben und andere Ereignisse.

Greenbone Security Assistant (GSA)

Der Greenbone Security Assistant (GSA) ist die Web-Oberfläche, mit der ein Nutzer Scans steuert und auf Schwachstelleninformationen zugreift. Es ist der Hauptkontaktpunkt für einen Nutzer mit der Appliance. Er verbindet sich über den Webserver Greenbone Security Assistant Daemon (gsad) mit gvmd, um eine voll funktionsfähige Webanwendung für das Schwachstellenmanagement bereitzustellen. Die Kommunikation erfolgt über das Greenbone Management Protocol (GMP), mit dem der Nutzer auch direkt über verschiedene Tools kommunizieren kann.

OpenVAS Scanner

Der Hauptscanner OpenVAS-Scanner ist eine voll funktionsfähige Scan-Maschine, die Schwachstellentests (VTs) gegen Zielsysteme ausführt. Dazu nutzt er die täglich aktualisierten und umfangreichen Feeds: den vollumfänglichen, ausführlichen, kommerziellen OPENVAS ENTERPRISE FEED oder den frei verfügbaren OPENVAS 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.

openvasd

Um lokale Sicherheitskontrollen (engl. local security checks, LSCs) zu beschleunigen, sendet openvas-scanner die gesammelten Pakete an openvasd. Die Übertragung erfolgt über HTTP und der openvasd-Listener ist an localhost gebunden.

openvasd ersetzt die Logik potenziell aller NASL-basierten LSCs. Anstatt für jeden LSC ein VT-Skript auszuführen, wird die auf einem Host installierte Software mit einer Liste bekannter anfälliger Software verglichen.

Der reguläre OpenVAS-Scanner lädt jeden NASL-LSC einzeln und führt ihn nacheinander für jeden Host aus. Eine einzelne bekannte Schwachstelle wird dann mit der installierten Software abgeglichen. Dies wird für alle LSCs wiederholt. Mit openvasd wird die Liste der installierten Software auf die gleiche Weise geladen, aber direkt mit der gesamten bekannten anfälligen Software für das Betriebssystem des gescannten Hosts abgeglichen. Dadurch entfällt die Notwendigkeit, die LSCs auszuführen, da die Informationen über die bekannte anfällige Software in einer einzigen Liste gesammelt und nicht in einzelnen NASL-Skripten verteilt sind.

Dies sorgt für eine bessere Leistung aufgrund des geringeren Systemressourcenverbrauchs und somit für ein schnelleres Scannen.

GMP Clients

Die Greenbone Vulnerability Management Tools (gvm-tools) sind eine Sammlung von Werkzeugen, die bei der Fernsteuerung von OPENVAS SCAN und des zugrundeliegenden Greenbone Vulnerability Management Daemons (gvmd) helfen. Die Tools helfen beim Zugriff auf die Kommunikationsprotokolle GMP (Greenbone Management Protocol) und OSP (Open Scanner Protocol).

Dieses Modul besteht aus interaktiven und nicht interaktiven Clients. Die Programmiersprache Python wird direkt für die interaktive Skripterstellung unterstützt. Es ist aber auch möglich, Remote-GMP-/Remote-OSP-Befehle ohne Programmierung in Python zu erteilen.

18.2 Protokolle

Es gibt obligatorische und optionale Protokolle. Einige Protokolle werden nur in bestimmten Setups genutzt.

Die Appliance benötigt einige Protokolle um voll funktionsfähig zu sein. Diese Protokolle stellen Feed-Updates, die Domain-Name-System-Auflösung (DNS-Auflösung), die Zeit etc. bereit.

18.2.1 Appliance als Client

_images/appliance_acting_as_client-de.png

Abb. 18.2 Appliance handelt als Client

Die folgenden Protokolle werden von eigenständigen Systemen oder einer Master-Appliance genutzt, um Verbindungen als Client zu initiieren:

DNS – Namensauflösung

  • Verbindet zu 53/UDP und 53/TCP

  • Obligatorisch

  • Nicht verschlüsselt

  • Kann interne DNS-Server nutzen

NTP – Zeitsynchronisierung

  • Verbindet zu 123/UDP

  • Optional

  • Nicht verschlüsselt

  • Kann interne NTP-Server nutzen

Feeds (siehe unten)

  • Direkt

    • Verbindet zu 24/TCP oder 443/TCP, kann im GOS-Administrationsmenü gewählt werden

    • Direkter Internetzugang erforderlich

  • Über Proxy

    • Verbindet zu internem HTTP-Proxy, der CONNECT-Methode auf konfigurierbarem Port unterstützt

  • Verbindet zu feed.greenbone.net

  • Obligatorisch auf eigenständigen und Master-Appliances

  • Genutztes Protokoll ist SSH

  • Verschlüsselt und in beide Richtungen authentifiziert über SSH

    • Server: öffentlicher Schlüssel

    • Client: öffentlicher Schlüssel

DHCP

  • Verbindet zu 67/UDP und 68/UDP

  • Optional

  • Nicht verschlüsselt

Airgap (S)FTP

  • Port kann im GOS-Administrationsmenü individuell festgelegt werden

    • Verbindet standardmäßig zu 20/TCP und 21/TCP für FTP und zu 22/TCP für SFTP

  • Optional

  • Unverschlüsselt oder verschlüsselt und in beide Richtungen authentifiziert über SSH

LDAPS – Benutzerauthentifizierung

  • Port kann über die Web-Oberfläche individuell festgelegt werden

    • Verbindet standardmäßig zu 389/TCP für LDSAP mit STARTTLS und 636/TCP für LDAPS

  • Optional

  • Verschlüsselt und authentifiziert über SSL/TLS

    • Server: Zertifikat

    • Client: Benutzername/Passwort

Syslog – Remote-Protokollierung und -Benachrichtigungen

  • Port kann im GOS-Administrationsmenü individuell festgelegt werden

    • Verbindet standardmäßig zu 512/UDP oder 512/TCP

  • Optional

  • Nicht verschlüsselt

SNMP-Traps für Benachrichtigungen

  • Verbindet zu 162/UDP

  • Optional

  • Nur SNMPv1

  • Nicht verschlüsselt

SMTP(S) für E-Mail-Benachrichtigungen

  • Port kann im GOS-Administrationsmenü individuell festgelegt werden

    • Verbindet standardmäßig zu 465/TCP für SMTPS und zu 25/TCP für SMTP, verbindet alternativ zu 587/TCP

  • Optional

  • SMTPS kann erzwungen werden, damit es immer verwendet wird

  • Verschlüsselt über STARTTLS, falls SMTPS nicht erzwungen wird

  • Nicht verschlüsselt, falls Verschlüsselung über STARTTLS nicht möglich ist

SFTP für Backups

  • Port kann im GOS-Administrationsmenü individuell festgelegt werden

    • Verbindet standardmäßig zu 22/TCP

  • Optional

  • Verschlüsselt und in beide Richtungen authentifiziert über SSH

    • Server: öffentlicher Schlüssel

    • Client: öffentlicher Schlüssel

Cisco Firepower (Sourcefire) für IPS-Integration

  • Port kann über die Web-Oberfläche individuell festgelegt werden

    • Verbindet standardmäßig zu 8307/TCP

  • Optional

  • Verschlüsselt und in beide Richtungen authentifiziert über SSL/TLS

    • Server: Zertifikat

    • Client: Zertifikat

verinice.PRO

  • Verbindet zu 443/TCP

  • Optional

  • Verschlüsselt über SSL/TLS

    • Server: optional über Zertifikat

    • Client: Benutzername/Passwort

TippingPoint SMS

  • Verbindet zu 443/TCP

  • Optional

  • Verschlüsselt über SSL/TLS

    • Server: Zertifikat

    • Client: Zertifikat, Benutzername/Passwort

18.2.2 Appliance als Server

_images/appliance_acting_as_a_server-de.png

Abb. 18.3 Appliance handelt als Server

Die folgenden Verbindungen werden von einer Appliance, die als Server agiert, genutzt:

HTTPS – Web-Oberfläche

  • 443/TCP

  • Obligatorisch auf eigenständigen und Master-Appliances

  • Verschlüsselt und authentifiziert über SSL/TLS

    • Server: optional über Zertifikat

    • Client: Benutzername/Passwort

SSH – CLI-Zugang und GMP

  • 22/TCP

  • Optional

  • Verschlüsselt und authentifiziert über SSH

    • Server: öffentlicher Schlüssel

    • Client: Benutzername/Passwort

SNMP

  • 161/UDP

  • Optional

  • Optional verschlüsselt, falls SNMPv3 genutzt wird

18.2.3 Master-Sensor-Setup

_images/Master_Sensor_Communication-de.png

Abb. 18.4 Appliance-Master und -Sensor

In einem Master-Sensor-Setup gelten die folgenden zusätzlichen Anforderungen. Der Master (Server) veranlasst bis zu drei zusätzliche Verbindungen zum Sensor (Client):

SSH für GOS-Upgrades, Feed-Updates, GMP und OSP

  • Verbindung standardmäßig über 22/TCP

    • Alternativ Verbindung über 9390/TCP für Abwärtskompatibilität

  • Obligatorisch

  • Verschlüsselt und in beide Richtungen authentifiziert über SSH

    • Server: öffentlicher Schlüssel

    • Client: öffentlicher Schlüssel

18.3 Hinweise zur Nutzung eines Sicherheitsgateways

Viele Unternehmen setzen Sicherheitsgateways ein, um den Internetzugang zu beschränken. Diese Sicherheitsgateways können als Paketfilter oder Gateways auf der Anwendungsebene wirken.

Einige Produkte unterstützen tiefgreifende Untersuchungen und versuchen das tatsächlich in den Kommunikationskanälen genutzte Protokoll zu bestimmen. Sie versuchen möglicherweise sogar, jede verschlüsselte Kommunikation zu entschlüsseln und zu analysieren.

18.3.1 Eigenständige oder Master-Appliance

Während viele Kommunikationsprotokolle, die die Appliance unterstützt, nur intern verwendet werden, benötigen manche Protokolle Zugang zum Internet. Diese Protokolle können möglicherweise durch solche Sicherheitsgateways gefiltert werden.

Beim Einsetzen einer Appliance als eigenständige Appliance oder als Master, muss die Appliance in der Lage sein, auf den OPENVAS ENTERPRISE FEED zuzugreifen. Der OPENVAS ENTERPRISE FEED kann direkt über die Ports 24/TCP oder 443/TCP oder durch Nutzung eines Proxys erreicht werden.

Bemerkung

In allen Fällen ist das genutzte Protokoll SSH, auch wenn der Port 443/TCP oder ein HTTP-Proxy genutzt wird.

Eine Deep-Inspection-Firewall könnte die Nutzung des SSH-Protokolls auf Port 443/TCP entdecken und den Verkehrt abbrechen oder blockieren.

Falls das Sicherheitsgateway versucht, den Verkehr mithilfe von Man-in-the-Middle-Techniken zu entschlüsseln, fällt die Kommunikation zwischen der Appliance und dem Feedserver aus. Das SSH-Protokoll, das eine doppeltgerichtete Authentifizierung basierend auf öffentlichen Schlüsseln nutzt, verhindert jeden Man-in-the-Middle-Angriff, indem es die Kommunikation beendet.

Zusätzliche Protokolle, die Internetzugang benötigen, sind DNS und NTP. Sowohl DNS als auch NTP können für die Nutzung von internen DNS- und NTP-Servern konfiguriert werden.

18.3.2 Sensor-Appliance

Falls Sicherheitsgateways zwischen dem Master und dem Sensor eingesetzt werden, muss das Sicherheitsgateway SSH-Verbindungen (22/TCP) vom Master zum Sensor erlauben.