Security Risks

The Security Risks page is a new feature on the Nectar Dashboard, designed to help you identify and resolve security risks associated with your instances. Please let us know if you have any feedback on this feature or the following support article by submitting a ticket.

You can view a list of security risks associated with your instances by navigating to the Security Risks page, under the Project menu on the Nectar Dashboard.

Note: If you have an instance on the Nectar Research Cloud with one or more security risks, a warning icon () will appear next to the instance name under the Instances or Database Instances page on the Nectar Dashboard. Click the warning icon to open the Security Risks page and learn more about the security risk(s) associated with the instance(s).

The Security Risks page may display the following security risks:

• Accessible DB
• Accessible RDP
• Password SSH
• Password SSH (Nectar image)
• Vulnerable HTTP

This article addresses what each of these security risks mean, how they impact you, and steps you can take to resolve the risks.

For each security risk, we describe the impact to your data using three key information security principles: Confidentiality, Integrity and Availability (CIA).

• Confidentiality ensures sensitive information is accessible only to authorised individuals, protecting it from unauthorised access.
• Integrity guarantees the data remains accurate and unaltered, maintaining its trustworthiness.
• Availability ensures information and resources are accessible to authorised users whenever needed.

These principles are considered the CIA triad of information security strategy and form the cornerstone of security measures and risk management practices.

Accessible DB

What it means

Databases (DBs) provide datasets of information in an accessible way to your users. The most common DBs used in Nectar are MySQL and PostgreSQL. The Accessible DB warning means you are running a database instance that could be accessed from anywhere on the internet.

How it impacts you

Some DBs contain information that should only be accessed by a certain subset of people. If your DB is accessible from anywhere on the internet, then this can be exploited for malicious purposes by exfiltrating data (unauthorised transferring of data — a confidentiality risk) or injecting malicious code to either amend your dataset (an integrity risk) or delete it entirely (an availability risk).

Additionally, if you aren’t regularly updating your MySQL or PostgreSQL servers then there may be a vulnerability announcement that you miss which could result in these risks being exploited.

Why you might be okay with this risk

If your dataset is intended to be accessible to the internet without a restriction on who can access it (i.e. your dataset is classified as Green and is authorised for public access in line with your university’s advice) then you may be okay with the risks of having an openly accessible database. We recommend reviewing your University’s data classification guidelines for advice on data security.

Image source: Figure 1 from Charlesworth, J., Abdel Alim, M., Brown, D., Burton, N., D’Costa, K., Cho, K. L., Healy, N., Lynn, H., Morse, J., Soo, A. L., & Splawa-Neyman, P. (2024). Decoding sensitive data management. Zenodo. https://doi.org/10.5281/zenodo.10403632

For more information on The Data Classification Framework, please read our support article on Guidance for sensitive data and using the Nectar Research Cloud.

Steps to resolve it

In addition to requiring password authentication to the database instance, you can restrict access to specific IP addresses by following these steps:

1. On the Nectar Dashboard, navigate to Project / Database / Instances in the navigation panel on the left hand side.
2. Identify the relevant instance, and in the drop-down menu to the right of the instance, select Update Instance.
   
   A window will open.
3. Enter one or more IP ranges to the Allowed CIDRs field. Multiple IP ranges can be listed with commas between them. Remember to think about the access points you will require. You can ask your university or institution’s IT department, check the IP ranges we have listed, consider adding access from your home computer, or another cloud instance you are using.
   
4. Click Update.

How to avoid it

You can prevent this security vulnerability when creating a database instance by specifying one or more IP addresses that can access your database instance in the Allowed CIDRs field under the Database Access tab.

Accessible RDP

What it means

Remote Desktop Protocol (RDP) provides access to your instances over a network and provides a graphical interface to your system. The most common RDP implementations used in Nectar are on Microsoft Windows, but it can also be configured on Linux using applications such as X2Go. The Accessible RDP warning means an RDP instance could be accessed from anywhere on the internet.

How it impacts you

If your RDP instance is accessible anywhere on the internet, it could potentially be exploited for malicious purposes. Attackers may attempt to gain unauthorised access to your instance (a confidentiality risk), modify data on your system (an integrity risk), or disrupt your services (an availability risk).

Additionally, if you are not regularly updating your RDP software, you may miss critical security patches, leaving your system vulnerable to exploitation.

Steps to resolve it

There are a variety of approaches to restrict network access to RDP. We recommend using Security Groups:

1. If any RDP-related security group has been attached to your instance, then detach it from your instance.

   1. On the Nectar Dashboard, navigate to Project / Compute / Instances in the navigation panel on the left hand side.

   2. Identify the relevant instance, and in the drop-down menu to the right of the instance, select Edit Security Groups.
      A window will open for you to edit the instance.

   3. On the right, use the minus button to remove the current security group(s).
      

      This will prevent access to your instance using any of the existing rules in the security group(s).

   4. Click Save.

2. Create a new security group, following the instructions provided in the Security group tutorial. When adding a rule, use the following key settings:

   Rule: RDP

   CIDR: Enter one or more IP ranges (multiple IP ranges can be listed with commas between them). Remember to think about the access points you will require. You can ask your university or institution’s IT department, check the IP ranges we have listed, and consider adding access from your home computer, or another cloud instance you are using.
   

3. Attach the newly created security group to your instance.

   1. Navigate back to Project / Compute / Instances.
   2. Reidentify the relevant instance, and in the drop-down menu to the right of the instance, select Edit Security Groups.
   3. On the left, use the plus button to add the created RDP security group, then click Save. This will allow access to your instance using the rules in your created security group.
      

How to avoid it

We do not recommend using the CIDR value 0.0.0.0/0 for RDP. When creating a security group, follow best practice advice for security groups, and limit access to your instance to what is required. 

Resources

• Support article on Using security groups
• Security groups, the absolute basics Tutorial
• Intermediate Security Groups Tutorial

Password SSH

What it means

Secure SHell (SSH) provides secure access to your servers and systems over a network. The most common SSH implementations used in Nectar are OpenSSH on Linux, but it can also be configured on Microsoft Windows. The Password SSH warning means an SSH instance can be accessed using password authentication. Instead, we recommend using key-based authentication for SSH.

How it impacts you

Password-based SSH access can provide a way for users to securely connect to your servers over a network. However, enabling password SSH can pose significant security risks. If your instance uses password-based authentication and is accessible anywhere on the internet, then attackers could attempt to guess the password (brute-force password attack) or use a list of known usernames and passwords (credential stuffing attack). Attackers may attempt to gain unauthorised access to your instance (a confidentiality risk), inject malicious commands to alter your system (an integrity risk), or disrupt your services (an availability risk).

Additionally, if you are not regularly updating your SSH software, you may miss critical security patches, leaving your system vulnerable to exploitation.

Steps to resolve it

Ensure you have access to your SSH key. If you do not, please follow our tutorial on Creating a keypair for use in Nectar.

1. Disable password authentication for the SSH service.
   1. Open the SSH Daemon (SSHD) configuration file if it exists, or create one using the command:
      sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf

   2. Either add the following line:

      PasswordAuthentication no

      or, if a “PasswordAuthentication yes” line already exists, then change yes to no.

   3. Save and exit the SSHD configuration file using the keyboard shortcuts: 

      Ctrl+O, Enter, Ctrl+X

2. Restart the SSHD service:

   sudo systemctl restart sshd

3. Check whether password authentication has been correctly disabled using the command:

   sudo sshd -T | grep passwordauthentication

   If it has been correctly disabled, you will see:

   passwordauthentication no

How to avoid it

We recommend using one of the publically available official Nectar images when creating a new instance. The official Nectar Linux images created by ARDC are now configured (by default) to only have key-based authentication enabled.

Password SSH (Nectar image)

What it means

Similar to the Password SSH warning, the Password SSH (Nectar image) warning means an instance could potentially be accessed using password authentication. This is the result of an SSH misconfiguration in specific older Nectar images. If you created an instance between 2024-08-27 and 2024-11-27, you may have used such an image.

These images were replaced as soon as we were aware of this misconfiguration. We have also added new tests to make sure this does not happen again.

How it impacts you

This misconfiguration in Nectar images by itself does not cause a security vulnerability. The affected Nectar images still include security measures that protect your instances. These include:

• no default passwords, and 
• the use of fail2ban to limit brute force attempts.

However, you may be vulnerable if you have done one or more of the following:

• set a password for default users,
• created new users with passwords, or
• disabled fail2ban.

As the automatic enabling of password SSH on specific Nectar images is not considered good practice, it has been flagged as a security risk similar to the above Password SSH warning.

Steps to resolve it

We recommend you recreate your instance using one of the new, publically available, official Nectar images containing the fix. The listed Nectar images with an SSH misconfiguration have been replaced to prevent future issues, so any new instances will not be affected. Recreating your instance is the best way to resolve this issue, as it ensures you are starting off with a clean image.

As a workaround, you may choose to edit the SSH configuration, following the steps provided above to resolve the Password SSH warning. This will fix the vulnerability; however, you must remember to reapply this fix every time you rebuild your instance.

How to avoid it

The old Nectar images with an SSH misconfiguration have been replaced to prevent future issues, so any new instances will not be affected.

We recommend using one of the new, publically available, official Nectar images when creating a new instance. The official Nectar Linux images created by ARDC are configured (by default) to only have key-based authentication enabled.

Vulnerable HTTP

What it means

A HyperText Transfer Protocol (HTTP) or HyperText Transfer Protocol Secure (HTTPS) instance, sometimes known as a webserver, is commonly used as a front user-facing service. It is there to provide information, data or services to your users. A Vulnerable HTTP instance has weaknesses in its software or configuration which can compromise its confidentiality, integrity or availability.

Note: If you are running HTTPS, the security risk will still state Vulnerable HTTP.

How it impacts you

Vulnerabilities in HTTP can vary in their severity which can compromise your data or instance’s confidentiality, integrity or availability. Some vulnerabilities can be exploited to exfiltrate data (a confidentiality risk), gain privileged access (a confidentiality risk), amend or delete data (integrity and availability risks), or execute and inject malicious code into your webserver (integrity and availability risks).

Steps to resolve it

Update and upgrade as soon as you notice a security risk identified on your HTTP instance by following your operating system’s guide on how to update packages.

• For Ubuntu, use this command to first update the package list and then upgrade the installed packages.
  sudo apt update && sudo apt upgrade -y
  Note: The -y flag automatically answers "yes" to any prompts, making the process non-interactive.
• For CentOS and Red Hat, use this command:
  sudo yum update

More detailed information is available in our tutorial on Installing and Updating software.

How to avoid it

We recommend you use a Nectar image with automatic security updates enabled. If you are not using a Nectar image, you should enable automatic security updates by following the documentation for your operating system.

HTTPS is preferred if possible; however this does not eliminate common vulnerabilities that exist in HTTP.

The Security Risks page is a new feature on the Nectar Dashboard, designed to help you identify and resolve security risks associated with your instances. Please let us know if you have any feedback on this feature or the above support article by submitting a ticket.