6 Von GOS 6 auf GOS 20.08 upgraden

Bemerkung

GOS 20.08 aktualisiert zahlreiche Komponenten des Schwachstellenscannings und -managements des Greenbone Security Managers (GSM) auf eine grundlegende neue Version.

Das Upgrade auf GOS 20.08 sollte nur durchgeführt werden, wenn die Versionshinweise gelesen wurden und ein Backup der aktuellen Daten, entweder mittels Backup-Funktion von GOS oder mittels VM-Snapshot auf dem Hypervisor, durchgeführt wurde. Weitere Neuigkeiten und Previews für GOS 20.08 finden sich auf https://community.greenbone.net/c/news.

Bevor das Upgrade auf GOS 20.08 durchgeführt werden kann, muss die neueste Version von GOS 6 auf dem GSM installiert sein und ein Reboot des GSMs ist notwendig.

Falls Fragen auftreten, kann der Greenbone Networks Support (support@greenbone.net) per E-Mail kontaktiert werden.

6.1 Den Greenbone Security Manager upgraden

Das Upgrade auf GOS 20.08 kann wie folgt durchgeführt werden:

  1. Maintenance wählen und Enter drücken.

  2. Upgrade wählen und Enter drücken.

  3. Switch Release wählen und Enter drücken.

    → Eine Warnung informiert den Nutzer darüber, dass der GSM auf eine grundlegende neue Version aktualisiert wird (siehe Abb. 6.1).

    _images/gos_menu_upgrade_gos2008.png

    Abb. 6.1 Warnung beim Upgrade auf GOS 20.08

  4. Continue wählen und Enter drücken.

    → Eine Warnung informiert den Nutzer darüber, dass der GSM während des Upgrades auf GOS 20.08 gesperrt ist (siehe Abb. 6.2).

    Bemerkung

    Während des Upgrades können keine Systemoperationen durchgeführt werden. Alle laufenden Systemoperationen müssen vor dem Upgrade beendet werden.

    _images/gos_menu_upgrade_gos5_3.png

    Abb. 6.2 Warnung, dass das System während des Upgrades gesperrt ist

  5. Yes wählen und Enter drücken.

    → Eine Meldung informiert den Nutzer darüber, dass das Upgrade gestartet wurde.

    Bemerkung

    Wenn das Upgrade beendet ist, informiert eine Meldung den Nutzer darüber, dass ein Reboot nötig ist, um alle Änderungen anzuwenden (siehe Abb. 6.3).

    _images/gos_menu_upgrade_gos5_4.png

    Abb. 6.3 Meldung nach dem erfolgreichen Upgrade

  6. Reboot wählen und Enter drücken.

    → Nachdem der Reboot abgeschlossen ist, wird geprüft, ob es offene Einrichtungsschritte gibt. Falls es offene Schritte gibt, wird gefragt, ob diese nun abgeschlossen werden sollen.

6.2 Den Feed nach dem Upgrade auf GOS 20.08 aktualisieren

Mit GOS 20.08 werden Scan-Konfigurationen, Compliance-Richtlinien, Berichtformate und Portlisten über den Feed verfügbar gemacht (siehe Kapitel 6.5).

Um diese Funktionalität nach dem Upgrade auf GOS 20.08 nutzen zu können, muss ein Web-Benutzer als Besitzer dieser Objekte (Feed Import Owner) konfiguriert und anschließend ein Feed-Update durchgeführt werden.

Bemerkung

Nach dem Reboot am Ende des Upgrades auf GOS 20.08 wird gefragt, ob die Einstellungen für die Objekte, die über den Feed verteilt werden, konfiguriert werden sollen.

  1. Yes wählen und Enter drücken.
  2. Import Owner wählen und Enter drücken.
  3. Nutzer, der Feed Import Owner sein soll, wählen und Leertaste drücken.
  4. Enter drücken.
  5. Save wählen und Enter drücken.
  6. Tab drücken, um Ready zu wählen und Enter drücken.
  7. Feed-Update wie in Kapitel 7.3.6 beschrieben durchführen.

6.3 Die Flash-Partition auf die neuste GOS-Version upgraden

Die interne Flash-Partition des GSM enthält ein Backup von GOS und wird im Falle eines Zurücksetzens auf Werkseinstellungen verwendet.

Es wird empfohlen, die GOS-Version auf der Flash-Partition zu aktualisieren (siehe Kapitel 7.3.8).

6.4 Web-Oberfläche nach einem Upgrade neu laden

Nach einem Upgrade von einer grundlegenden Version auf eine andere muss der Cache des Browsers, der für die Web-Oberfläche genutzt wird, geleert werden. Das Leeren des Browsercaches kann in den Einstellungen des genutzten Browsers vorgenommen werden.

Alternativ kann der Seitencache jeder Seite der Web-Oberfläche geleert werden, indem Strg und F5 gedrückt wird.

Bemerkung

Das Leeren des Seitencaches muss für jede einzelne Seite durchgeführt werden.

Das Leeren des Browsercaches ist global und für alle Seiten gültig.

6.5 Änderungen des Standardverhaltens

Die folgende Liste zeigt die Änderungen des Standardverhaltens zwischen GOS 6 und GOS 20.08. Abhängig von den aktuell genutzten Features, betreffen diese Änderungen möglicherweise das genutzte Setup.

Bemerkung

Die Liste kann überprüft werden, um zu entscheiden, ob Änderungen des aktuell eingesetzten Setups nötig sind. Der Greenbone Networks Support (support@greenbone.net) unterstützt während dieses Prozesses.


gb_video Die Änderungen werden kurz in einem Video erklärt.


6.5.1 Produktportfolio

Der Name GSM 150V wurde mit GOS 20.08 entfernt. Bestehende GSM 150V werden beim Upgrade von GOS 6 auf GOS 20.08 automatisch in GSM CENO umgewandelt.

Da beide GSM-Modelle bis auf den Namen genau identisch sind, sind keine weiteren Änderungen spürbar.

6.5.2 Virtuelle Maschinen

Virtuelle Appliances, die mit GOS 20.08.2 oder neuer ausgeliefert wurden, unterstützen auf allen Hypervisoren nur den EFI/UEFI-Boot-Modus. Das Booten über BIOS/MBR ist auf diesen virtuellen Appliances nicht möglich.

Virtuelle Appliances, die von Versionen älter als GOS 20.08.2 aktualisiert wurden, unterstützen nur das Booten über BIOS/MBR. Jedoch wird diese Funktionalität möglicherweise in Zukunft geändert. Das Booten über EFI/UEFI ist auf diesen Appliances vorerst nicht möglich.

Falls Fragen auftreten, kann der Greenbone Networks Support (support@greenbone.net) per E-Mail kontaktiert werden.

6.5.3 Sensoren

Das Master-Sensor-Konzept des Greenbone Security Managers (GSM) nutzt das Greenbone Management Protocol (GMP), um einen Sensor-GSM durch einen Master-GSM zu steuern.

In GOS 6 wechselten die Sensor-GSMs (GSM-Modelle GSM 35 und GSM 25V) zum Open Scanner Protocol (OSP) als steuerndes Protokoll. Dies führte dazu, dass die Sensoren leichtgewichtig wurden und vermied, dass zusätzliche Anmeldedaten auf dem Sensor benötigt wurden. Alle anderen GSMs, bei denen der Sensor-Modus aktiviert war, nutzten weiterhin GMP.

Mit GOS 20.08 kann jeder GSM optional zu GMP OSP für seinen Sensormodus nutzen. Das Nutzen von OSP verbessert die Leistung sowohl für den Master als auch für den Sensor.

Trotzdem sind die Appliances standardmäßig GMP-Sensoren.

Die gilt für die folgenden GSM-Modelle:

  • GSM 150
  • GSM 400, 450, 600 und 650
  • GSM 5300, 5400, 6400 und 6500
  • GSM CENO, DECA, TERA, PETA und EXA

Die GSM-Modelle GSM 35 und GSM 25V bleiben ausschließlich OSP-Sensoren.

Bemerkung

Für neue Setups sollte OSP genutzt werden und für bereits vorhandene Setups sollte zu OSP gewechselt werden (siehe Kapitel 16.1.3).

6.5.4 Datenobjekte via Feed

Mit GOS 20.08 werden alle Scan-Konfigurationen, Compliance-Richtlinien, Berichtformate und Portlisten von Greenbone Networks, die zuvor standardmäßig enthalten waren (im Folgenden als „Objekte“ bezeichnet), über den Feed verteilt. Auf diesem Weg können die Objekte viel einfacher durch ein Feed-Update statt durch ein GOS-Upgrade aktualisiert werden. Außerdem können zukünftig Objekte für besondere Anwendungsfälle verteilt werden.

Alle bisherigen Standardobjekte dieser Art sind nicht mehr in GOS enthalten. Ein Feed-Update ist nötig, um sie zu erhalten.

Neue GSMs werden bereits mit einem Feed, der die Objekte enthält, ausgeliefert. Nach einem Factory-Reset ist ein Feed-Update nötig, um die Objekte wieder zu erhalten. Beim Upgrade von GOS 6 werden die alten Objekte genutzt, bis das erste erfolgreiche Feed-Update mit GOS 20.08 durchgeführt wird. Es wird keine Möglichkeit geben, zu den alten Objekten zurückzukehren.

Die Objekte sind keine globalen Objekte mehr, sondern müssen einem Benutzer, dem Feed Import Owner, gehören (siehe Kapitel 7.2.1.9). Die Objekte werden während eines Feed-Updates nur heruntergeladen und aktualisiert, falls ein Feed Import Owner festgelegt wurde.

Der Feed Import Owner, ein Super-Administrator oder Nutzer, die entsprechende Berechtigungen erhalten haben, können Objekte löschen. Wenn die Objekte gelöscht werden, werden sie während des nächsten Feed-Updates erneut heruntergeladen.

Bemerkung

Wenn die Objekte im Papierkorb verbleiben, gelten sie noch nicht als gelöscht und werden beim nächsten Feed-Update nicht neu heruntergeladen. Falls keine Objekte heruntergeladen werden sollen, darf kein Feed Import Owner festgelegt sein.

Der Feed Import Owner und ein Super-Administration können anderen Nutzern auch zusätzliche Berechtigungen für die Objekte erteilen (siehe Kapitel 9.4.1.1 oder 9.4.1.2).

6.5.5 Web-Oberfläche

Die Seite Feed-Status auf der Web-Oberfläche zeigt nun den Status Aktualisierung läuft…, falls gerade ein Feed-Update durchgeführt wird. Dieser Status wird für alle Feeds angezeigt, auch wenn gerade nur ein Feed aktualisiert wird.

Der Status der Objekte, die über den Feed verteilt werden (Scan-Konfigurationen, Compliance-Richtlinien, Portlisten und Berichtformate) (siehe oben), ist nun in der Tabelle enthalten. Durch Klicken auf Compliance Richtlinien, Portlisten, Berichtformate oder Scan-Konfigurationen wird die entsprechende Seite geöffnet. Ein automatischer Filter zeigt nur die Objekte, die vom Feed bezogen werden.

Die Seite Alle Sicherheitsinfos wurde entfernt.

Die Funktionalität des Exportierens von Berichtformaten mit allen zugehörigen Icons wurde entfernt.

Beim Bearbeiten einer Scan-Konfiguration oder einer Compliance-Richtlinie ist es nicht mehr möglich, die folgenden VT-Familien zu bearbeiten:

  • CentOS Local Security Checks
  • Debian Local Security Checks
  • Fedora Local Security Checks
  • Huawei EulerOS Local Security Checks
  • Oracle Linux Local Security Checks
  • Red Hat Local Security Checks
  • SuSE Local Security Checks
  • Ubuntu Local Security Checks

6.5.6 Backups

Seit GOS 20.08 können nur Backups, die mit demselben GSM-Modell erstellt wurden, wiederhergestellt werden.

Die Einschränkung aus GOS 6, dass nur Backups, die mit der aktuell genutzten oder der vorherigen GOS-Version erstellt wurden, wiederhergestellt werden können, gilt auch weiterhin in GOS 20.08.

Bevor die Wiederherstellung gestartet wird, prüft der GSM, ob das Backup passend ist. Falls das Backup nicht wiederhergestellt werden kann, wird eine entsprechende Nachricht angezeigt.

Zusätzlich wird geprüft, ob die GSF-Subscription-Schlüssel des Backups und des GSMs, auf dem das Backup wiederhergestellt werden soll, identisch sind. Falls die Schlüssel nicht übereinstimmen, wird eine Warnung angezeigt und der Nutzer muss bestätigen, dass der Schlüssel auf dem GSM überschrieben werden soll.

In GOS 20.08 werden Backups mit einem neuen internen Backup-Tool erstellt. Dessen Repositories sind nicht kompatibel mit Backup-Repositories von GOS 6 oder älter, weshalb das vorherige, alte Tool zur Wiederherstellung solcher Backups immer noch enthalten ist.

Es wird jedoch empfohlen, nach einem Upgrade auf GOS 20.08 aus Wartungsgründen den Ort von Remote-Backups zu ändern.

Bemerkung

Alte Backups sind nicht verfügbar, bis der Ort zurück geändert wird.

In der nächsten GOS-Version wird das alte Backup-Tool entfernt und nur Backups aus GOS 20.08 oder neuer werden wiederherstellbar sein.

6.5.7 Scan-Warteschlange

Mit GOS 20.08 wird eine Scan-Warteschlange eingeführt. Scans werden nur gestartet, wenn genug Systemressourcen verfügbar sind. Die verfügbaren Ressourcen hängen vom GSM-Model, von der genutzten GOS-Version und von der aktuellen Arbeitslast des Systems ab.

Die wichtigste Ressource ist Random-Access Memory (RAM). Jeder Scan benötigt ein bestimmtes Minimum an RAM, um korrekt ausgeführt zu werden, da derselbe Scanprozess nicht mehrere Scans unterschiedlicher Nutzer oder auch vom gleichen Nutzer bearbeiten kann. Der RAM hat physische Grenzen und kann nicht auf zufriedenstellende Weise geteilt werden.

Falls zu viele Scans zur gleichen Zeit gestartet und ausgeführt werden und nicht genug RAM verfügbar ist, werden Scans zu einer Warteschlange hinzugefügt. Wenn der benötigte RAM wieder verfügbar ist, werden Scans von der Warteschlange gemäß dem Prinzip „first in, first out“ gestartet.

Die Anzahl an Scans in der Warteschlange ist ebenfalls begrenzt, d. h. Scans darüber werden überhaupt nicht gestartet.

Das Auslastungsmangement unterliegt dem Scanner. Falls ein Master-Sensor-Setup genutzt wird, verwaltet jeder Sensor seine Kapazität selbst. Sensorscans beeinflussen die Scankapazität des Masters nur minimal.

6.5.8 Greenbone Management Protocol (GMP)

Das Greenbone Management Protocol (GMP) wurde auf Version 20.08 aktualisiert und die Programmierschnittstelle wurde leicht angepasst. Die Nutzung mancher Kommandos wurde verändert und einige Kommandos, Elemente und Attribute wurden überholt. Das gesamte Referenzhandbuch und die Liste aller Veränderungen ist hier verfügbar.