Responsibility for cybersecurity on the Nectar infrastructure at the University of Auckland is a partnership between you and the University.
To reduce cybersecurity risk, and to protect the University and you from data breaches and reputational harm, we are periodically scanning all virtual machines (VMs) with public IP addresses for known vulnerabilities.

Why known security vulnerabilities are a problem:

Insecure VMs, if hacked, can be used to attack other systems. This has happened in the past and can get the University blacklisted, stopping access to other external services.

We have also had internal servers attacked from compromised machines, bypassing their firewall protection, as the attack from another VM looks like internal University traffic. This is what happened to Waikato DHB hospital systems in March 2021. One compromised machine led to successful attacks on other internal systems that would otherwise have been inaccessible.

Vulnerability detection

The University uses the services of

Vulnerability classification

Tenable classifies your vulnerabilities on the Common Vulnerability Scoring System (*) indicating the severity of, or risk associated with, a vulnerability, and its score. These ratings and scores are (**):

  • Low (0 - 3.9)
  • Medium (4 - 6.9)
  • High (7 - 9.9)
  • Critical (10)

(*) The Common Vulnerability Scoring System (CVSS) is a free and open industry standard for assessing the severity of computer system security vulnerabilities. CVSS attempts to assign severity scores to vulnerabilities, allowing responders to prioritize responses and resources according to threat. Scores range from 0 to 10, with 10 being the most severe.

(**) Taken from tenable documentation. Sometimes a vulnerability is associated with a higher risk level even though its CVSS score is lower than the bracket indicates (e.g. rating High with a score of 2.6). This is the case when the University's security team considers a vulnerability more critical than rated by CVSS.

Vulnerability notification

If vulnerabilities of level High and Critical risk are detected on one of your virtual machines, a ticket detailing the issues is created in the Nectar help desk, and everybody associated with the project the VM belongs to will be notified.

Remedial action

We ask that you attend to whatever remedial action is needed. The urgency depends on the detected severity. If detected vulnerabilities of an instance are not addressed in time, we may lock the VM and limit access to it. In any event, we will be in touch and support you in addressing the issues.

Expected time-lines to address your vulnerabilities:

Vulnerability RatingDescriptionTarget time to fix
CriticalVMs can be readily compromised with publicly available malware or exploits.48 hours
HighClassification may be based on the risk factor.30 days


The general expectation is that your VMs are kept up-to-date with any security-related patches, and any vulnerabilities detected by our scans are fixed. This will help keep your VMs and data safe.

The remainder of this document provides you with information that will help you address detected known vulnerabilities. If you are unsure what to do, please reply to the email that informed you about the existing vulnerabilities, or get in touch via email with

Recipes and practices to address (and avoid) known vulnerabilities

We recommend the following practices in combination with upgrading / updating / patching:
  • Before you patch/upgrade, create a snapshot of your instancejust in case something goes wrong.
    • For Windows VMs, shut the VM down before you create a snapshot.
    • Alternatively, if auto-patching is configured on the VM, create a snapshot once in a while.
  • Store all your data on volumes and not on the operating system partition. This makes it easier for you to recover important data should the operating system become unstable.
  • Reboot a VM after patching. Quite often updates only have an effect after a reboot.

1. Do not use an OS version beyond its end of life

Every OS version is supported only for a limited period of time. When this time runs out,

  • all security support for your OS distribution version stops
  • no more patches are provided
  • you need to upgrade the OS to a supported version, or replace the VM entirely with a new VM using a supported OS version.

Determine your current OS version with the following command:

$ cat /etc/os-release

Find the date when security support stops for your OS in the table below, or here:

Linux distribution and versionReleaseEnd of life date
Fedora 332020-10-27
Fedora 342021-04-27
CentOS 72014-07-072024-06-30
CentOS 82019-09-242021-12-31
Centos Stream 82019-09-242024-05-31
Debian 92017-06-172022-06-30
Debian 102019-07-062024-06-01
Ubuntu 16.04 LTS2016-04-212021-04-02
Ubuntu 18.04 LTS2018-04-262023-04-02
Ubuntu 20.04 LTS2020-04-232025-04-02
Ubuntu 20.102020-04-222021-07-22
Ubuntu 21.042021-04-222022-01-01

If your VM OS version has reached end-of-life, upgrade to a supported version immediately, or set up a new VM with an up-to-date OS.

DistributionUpgrade commandsFurther reading
UbuntuRun the following commands in a terminal:
sudo apt update
sudo apt upgrade
sudo do-release-upgrade
Then reboot the VM.
DebianRun the following commands in a terminal:
sudo apt update
sudo apt upgrade
sudo apt full-upgrade
Then reboot the VM.
FedoraFollow instructions at
Then reboot the VM.
CentOS 7Upgrade to CentOS 8
CentOS 8Migrate to CentOS Stream 8

2. Maintain your current OS version

The process of installing latest updates in an operating system (OS) is sometimes called patching. Every OS provides fairly straight-forward tooling to apply latest updates. In addition to manual patching most OS also provide mechanisms to apply updates in an automated and scheduled way. This is called auto-patching, or automatic updates. These updates

  • address new security vulnerabilities
  • integrate new features
  • address identified bugs/flaws
  • improve Operating System/software stability
  • install new drivers


We recommend you apply security patches regularly, and upgrade your OS regularly.

All officially-supported Nectar Linux OS images (images whose name starts with "Nectar") except CentOS Stream 8 have been configured from roughly June 2021 to automatically install security-related patches.
If you are using these newer images you are all set with respect to patching.

See here for details, and check if your instance is configured with auto-patching from the Nectar dashboard as follows:

  • Click the link for the "Image Name" value under Metadata.
  • Inspect the "automatic updates" field under Custom Properties. If "security" is listed there, automatic security updates are applied to your VM.



If you use older images you need to either regularly patch your OS manually, or configure auto-patching.

OSBasic procedureFurther reading
UbuntuRun the following commands in a terminal:
sudo apt update
sudo apt upgrade
Then reboot the VM.
DebianRun the following commands in a terminal:
sudo apt update
sudo apt upgrade
Then reboot the VM.
FedoraRun the following commands in a terminal:
sudo dnf upgrade
Then reboot the VM
CentOS 7
CentOS 8
CentOS Stream 8

Windows 2012 Server R2

We recommend to enable automatic updates on Windows 2012 Server VMs (on later versions of the image automatic updates are already configured). Use the following steps to configure automatic updates:

  1. Connect to the Windows server
  2. Click on the Windows icon in the lower-left corner
  3. Click Control Panel > System and Security. The Choose your Windows Update settings page appears
  4. Under the Windows Update section, click Turn automatic updating on or off
  5. Select Install updates automatically (recommended) from the drop-down menu
  6. If you also want to automatically install recommended updates, select the check box under Recommended Updates (optional)
  7. If you want to install updates for other Microsoft® products at the same time that the Windows updates are installed, select the check box under Microsoft Update (optional)
  8. When you are finished making selections, click OK in the lower portion of the window

3. Set up HTTPS for web servers

Protecting your web servers with HTTPS provides important security and data integrity capabilities for your website and your website user's information. Even if your site does not handle sensitive information, HTTPS is quickly becoming a requirement for features in the latest web browsers.

Setting up HTTPS can be intimidating - it takes many steps, requires specific knowledge of encryption and server configuration, and it sounds complicated in general.
There is tooling that can help with it, but even with this, the task is not a straight-forward one for the inexperienced user. In principle, the steps involved in setting up HTTPS are:

  • generate an SSL certificate (and associated private key)
  • configure the SSL certificate and the associated private key in your web server

The Nectar application catalogue offers solutions that handle HTTPS setup for you behind the scenes so you don't have to deal with it. This may be a good choice for you. In other cases you may want to (or have to) configure the server yourself.

The following examples cover options for setting up HTTPS for at least some common use-cases.

Jupyter Notebook Server

By default a Jupyter notebook server runs without HTTPS.

The easiest way to launch a Jupyter notebook server protected by HTTPS is probably by launching it from the Nectar application catalogue. Documentation about this application and how to launch it can be found here.
Note: Only if you choose a DNS zone in the dialogue to create the application will HTTPS be set up and configured for you Jupyter notebook server.

If you want to use this application, but want to configure your Notebook server with HTTPS yourself, you can follow this guide.

RStudio Server

The easiest way to launch an RStudio Server instance protected by HTTPS is probably by launching it from the Nectar application catalogue. Documentation about this application and how to launch it can be found here. This application will set up HTTPS as part of the launch process.

LAMP - Linux + Apache HTTP server + MySQL + PHP

The easiest way to launch a LAMP stack protected by HTTPS might be by launching it from the Nectar application catalogue. Documentation about this application and how to launch it can be found here. This application will set up HTTPS as part of the launch process.

Apache HTTP server

There is not yet a Nectar application for launching a plain Apache HTTP server with HTTPS support (the existing application doesn't include the HTTPS setup). But this guide explains how to set up HTTPS for the Apache HTTP server.