6 Upgrading from GOS 6 to GOS 20.08

Note

GOS 20.08 updates many vulnerability scanning and management components of the Greenbone Security Manager (GSM) to a major new version.

Only proceed with upgrading to GOS 20.08 after reading the release notes and performing a backup of the current data, either via the backup functionality of GOS or via a VM snapshot on the hypervisor. Further news and previews for GOS 20.08 can be found at https://community.greenbone.net/c/news.

Before upgrading to GOS 20.08, the latest version of GOS 6 must be installed on the GSM and the GSM must be rebooted.

If there are any questions, contact the Greenbone Networks Support via e-mail (support@greenbone.net).

6.1 Upgrading the Greenbone Security Manager

The upgrade to GOS 20.08 can be carried out as follows:

  1. Select Maintenance and press Enter.

  2. Select Upgrade and press Enter.

  3. Select Switch Release and press Enter.

    → A warning informs that the GSM is upgraded to a major new version (see Fig. 6.1).

    _images/gos_menu_upgrade_gos2008.png

    Fig. 6.1 Warning when upgrading to GOS 20.08

  4. Select Continue and press Enter.

    → A warning informs that the GSM is locked during the upgrade to GOS 20.08 (see Fig. 6.2).

    Note

    No system operations can be run during the upgrade and all running system operations must be closed before upgrading.

    _images/gos_menu_upgrade_gos5_3.png

    Fig. 6.2 Warning that system is locked during the upgrade

  5. Select Yes and press Enter.

    → A message informs that the upgrade was started.

    Note

    When the upgrade is finished, a message informs that a reboot is required to apply all changes (see Fig. 6.3).

    _images/gos_menu_upgrade_gos5_4.png

    Fig. 6.3 Message after a successful upgrade

  6. Select Reboot and press Enter.

    → After the reboot is finished, it is checked if there are any unfinished setup steps. If there are unfinished steps, a message asks whether they should be completed now.

6.2 Updating the Feed After Upgrading to GOS 20.08

With GOS 20.08, scan configurations, compliance policies, report formats and port lists are made available via the feed (see Chapter 6.5).

To make use of this feature after upgrading to GOS 20.08, a web user must be configured as the owner of these objects (Feed Import Owner), and a feed update must be carried out afterwards.

Note

After the reboot at the end of the upgrade to GOS 20.08, a message asks whether the settings for the objects that are distributed via the feed should be configured.

  1. Select Yes and press Enter.
  2. Select Import Owner and press Enter.
  3. Select the user that should be Feed Import Owner and press Space.
  4. Press Enter.
  5. Select Save and press Enter.
  6. Press Tab to select Ready and press Enter.
  7. Perform a feed update as described in Chapter 7.3.6.

6.3 Upgrading the Flash Partition to the Latest Version

The internal flash partition of the GSM contains a backup copy of GOS and is used in case of a factory reset.

Upgrading the GOS version stored on the flash partition is recommended (see Chapter 7.3.8).

6.4 Reloading the Web Interface After an Upgrade

After an upgrade from one major version to another, the cache of the browser used for the web interface must be emptied. Clearing the browser cache can be done in the options of the used browser.

Alternatively, the page cache of every page of the web interface can be emptied by pressing Ctrl and F5.

Note

Clearing the page cache must be done for every single page.

Clearing the browser cache is global and applies to all pages.

6.5 Changes of Default Behavior

The following list displays the changes of default behavior from GOS 6 to GOS 20.08. Depending on the current features used, these changes may apply to the currently deployed setup.

Note

Check the following list to decide whether changes to the currently deployed setup are required. The Greenbone Networks Support (support@greenbone.net) may help during this process.

gb_video The changes are briefly explained in a video.

6.5.1 Product Portfolio

The name GSM 150V is retired with GOS 20.08. Existing GSMs 150V are changed to GSM CENO automatically during the upgrade from GOS 6 to GOS 20.08.

Since both GSM models are exactly the same aside from the name, no other changes will be noticeable.

6.5.2 Virtual Machines

Virtual appliances that have been shipped with GOS 20.08.2 or newer only support EFI/UEFI boot mode on all hypervisors. Booting via BIOS/MBR is not possible on those virtual appliances.

Virtual appliances that have been upgraded from versions older than GOS 20.08.2 only support booting via BIOS/MBR, however this functionality may be changed in the future. Booting via EFI/UEFI is not possible on those appliances for now.

If there are any questions, contact the Greenbone Networks Support via e-mail (support@greenbone.net).

6.5.3 Sensors

The master-sensor concept of the Greenbone Security Manager (GSM) uses the Greenbone Management Protocol (GMP) to control a sensor GSM via a master GSM.

With GOS 6, the sensor GSMs (GSM models 35 and 25V) switched to Open Scanner Protocol (OSP) as the controlling protocol. This led to the sensors being light-weighted and avoided the need for additional credentials on the sensor. All other GSMs where sensor-mode is enabled still used GMP protocol.

With GOS 20.08, any GSM can use OSP for its sensor mode optional to GMP. Using OSP improves performance for both the master and the sensor.

However, the appliances are GMP sensors by default.

This applies for the following GSM models:

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

The GSM models GSM 35 and 25V remain exclusive OSP sensors.

Note

Use OSP for any new setup and switch to OSP for existing setups (see Chapter 16.1.3).

6.5.4 Data Objects via Feed

With GOS 20.08, all previously default scan configurations, compliance policies, report formats and port lists by Greenbone Networks (hereafter referred to as “objects”) are distributed via the feed. In this way, the objects can be updated much more easily with a feed update instead of a GOS upgrade. Additionally, special use case objects may be distributed in the future.

All current, default objects of these types will no longer be included in GOS. A feed update is necessary to obtain them.

New GSMs are shipped with a feed including the objects already. After a factory reset, a feed update is necessary to obtain the objects again. When upgrading from GOS 6, the old objects are used until the first successful feed update with GOS 20.08 is performed. There will be no way to obtain the old objects again.

The objects are no longer global objects but must be owned by a user, the Feed Import Owner (see Chapter 7.2.1.9). The objects are only downloaded and updated during a feed update, if a Feed Import Owner has been set.

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.

Note

If the objects remain in the trashcan, they do not count as deleted yet and are not downloaded anew during the next feed update. If no objects should be downloaded, the Feed Import Owner must be unset.

The Feed Import Owner and a super administrator may also grant additional permissions for the objects to other users (see Chapter 9.4.1.1 or 9.4.1.2).

6.5.5 Web Interface

The page Feed Status on the web interface now shows the status Update in progress… if a feed update is currently running. This status is displayed for all feeds, even if only one feed is currently being updated.

The status of the objects that are distributed via the feed (scan configurations, compliance policies, port lists and report formats) (see above) is now included in the table. When clicking Compliance Policies, Port Lists, Report Formats or Scan Configs, the respective page is opened. An automatic filter is applied showing only objects coming from the feed.

The page All SecInfo was removed.

The functionality of exporting report formats with all associated icons was removed.

When editing a scan configuration or a compliance policy, it is no longer possible to edit the following VT families:

  • 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

Starting with GOS 20.08, only backups created with the same GSM model can be restored.

The limitation from GOS 6 that only backups created with the currently used GOS version or the previous GOS version can be restored still applies in GOS 20.08.

Before starting the restoration, the GSM checks whether the backup is suitable. If the backup cannot be restored, an appropriate message is displayed.

Additionally, it is checked whether the GSF subscription keys of the backup and of the GSM on which the backup should be restored are identical. If the keys do not match, a warning is displayed and the user must confirm that the key on the GSM should be overwritten.

In GOS 20.08, backups are created with a new internal backup tool. Its repositories are not compatible with backup repositories from GOS 6 or older, so the previous, old tool is still included to restore such backups.

However, after upgrading to GOS 20.08, it is recommended to change the location of remote backups for maintenance reasons.

Note

Old backups will not be available until the location is changed back.

In the next GOS version, the old backup tool will be removed, and only backups from GOS 20.08 or newer will be restorable then.

6.5.7 Scan Queueing

With GOS 20.08, scan queueing is introduced. Scans are only started if sufficient system resources are available. The available resources depend on the GSM model, the GOS version used, and the current workload of the system.

The most relevant resource for scanning is random-access memory (RAM). Each scan requires a certain minimum of RAM to be executed properly because the same scan process cannot handle multiple scans from different users or even from the same user. RAM has physical limits and cannot be shared in a satisfactory way.

If too many scans are started and running at the same time and not enough RAM is available, scans are added to a waiting queue. When the required RAM is available again, scans from the waiting queue are started, following the principle “first in, first out”.

The number of scans in the waiting queue is limited as well, i.e., scans beyond that are not started at all.

The workload management is subject to the scanner. If a master-sensor setup is used, each sensor manages its available resources on its own. Sensor scans affect the scanning capacity of the master only minimally.

6.5.8 Greenbone Management Protocol (GMP)

The Greenbone Management Protocol (GMP) has been updated to version 20.08 and the API has been adjusted slightly. The usage of some commands has changed and several commands, elements and attributes have been deprecated. The complete reference guide and the list of changes are available here.