Security checklist for standard Virtual Machines

Security is a complex topic and it is impossible to cover everything. We have provided a checklist of some of the key things users can do to maintain security on their Nectar Cloud Virtual Machines. Security is important, so please follow these.

The NecTAR team conducts routine and random audits to determine the integrity of machine images and running instances. If you have discovered a critical security flaw, or believe your machine has been compromised, please email [email protected]; or for non-urgent security questions go to NeCTAR support to lodge a ticket.

1. Log into your VM using SSH

You should always access/log into your Virtual Machine using the secure shell method with your Public/Private key pair.  For how to log in via SSH, follow our tutorial here. Additionally, password access is disabled by default on official Nectar Images. If you are not using an official image, it is advised to disable password access as well. You can do this via editing the configuration file on your  virtual machine, in '/etc/ssh/sshd_config'. Ensure the following setting says the following:

PasswordAuthentication no

You should set this to 'no' to disable user login using password

2. Keep your private keys safe

Just like you keep your house keys safe, do the same with your private keys. Keep them in your .ssh folder, and do not share them with anyone. You can also add a password to your keys, when creating them, for an extra layer of protection. If you have existing keys which do not have a password, you can add a passphrase using this command (note: navigate to your .ssh folder first).

ssh-keygen -p -o -f nameofyourkey.pem

3. Using Security Groups and Keeping them organised

Ensure you use security groups to manage who and how someone can access your instance. To keep them organised, you can create them based on access type (for example a group dedicated to SSH), or for the particular project/purpose you are using them for (ie SQLserver). 

Also, You wouldn’t leave all your doors unlocked in your house, this is the same for your Virtual Machine. Only keep the ports you are using/need open, for example, if you are only using Port 22 for SSH, don’t have Port 443 open as well. You can manage this via security groups for your instance. 

4. Keep your virtual machines updated

Keeping your VM’s updated ensures all the latest security updates are applied. 

You can do this by running the following commands in the terminal:

sudo apt-get update 

sudo apt-get dist-upgrade

Be diligent in running these regularly. Also, some upgrades do require a reboot of the instance, be sure to do this often as well. 

5. Install SSH attack banning tools

 Install tools like fail2ban or denyhosts, which check your VM log files for attempted breaches and then block malicious IP addresses. Fail2ban is installed on Nectar Official images by default. If not using an official Nectar Image, you can use the below commands to install fail2ban in Ubuntu. To setup the fail2ban, please follow this instruction.

sudo apt-get update sudo apt-get install fail2ban 

6. Disable/Remove unnecessary accounts 

Keep an eye on the user accounts enabled on your system. Some applications create default accounts which are insecure. You may also open a temporary user account to allow quick login for a task and forget about it. This can lead to vulnerabilities later. Best to ensure any default accounts created are deleted, and you keep any user accounts to the absolute minimum necessary. 

 7. Disable unneeded services

Know what services run on your instance,, and disable ones which you are not using. Uou can enter the command  sudo service --status-all to list all available services. You can examine the output carefully and disable any services not required..

 8. Disable root access from SSH and use sudo if possible

You don’t want someone to be able to login, and have all the administrative superpowers automatically. Thus, make sure you disable root user SSH login. Of course sometimes users will need to complete administrative tasks, so it’s best to setup user accounts with sudo permission to perform administrator tasks, as opposed to giving root access. Root user access via SSH is disabled by default on Nectar Official Images. If not using an official Nectar Image, to change the configuration, you can edit the configuration file on the virtual machine, in '/etc/ssh/sshd_config'.

Here is a a basic description of some important configuration items in that file and how they should be set:

PermitRootLogin no

You need to set this to 'no' to avoid root access via SS

PermitEmptyPasswords no

This should be always 'no', for non-empty password access

AllowUsers

This directive allows only certain users to have access via SSH to this machine.

9. Only grant sufficient permission to user accounts

When creating user account, make sure only permission sufficient for its use is granted. Never grant extra permission if it is not needed.

10. Use Encrypted Communications

Wherever possible, use encrypted communications to avoid attacks which intercept data. You can use free SSL certificates from Let’s Encrypt to do this. We have a support article to help you, view it here.

11. No open recursive name servers

If you are running a DNS server, please ensure you only allow recursion from trusted hosts.

12. Control or disable access to your NTP server

If you run an NTP server, limit which systems can access it. Disable the 'monlist' command as this can be used as a denial of service vector on your system. For info about DDoS by NTP, see this article on Cloudflare

13. Using best practices for logging

Make sure that services are logging to a secure location, that is as tamperproof as possible. If logging remotely, ensure that it is done over a secure channel so that eavesdroppers cannot monitor what is happening on your instance. An example is using RSysLog with SSL. 

14. Mail Servers

If you run a mail server, make sure it only listens on the localhost IP address (127.0.0.1). For many clients, if you don't specify an SMTP server when sending email, it will use the recipients SMTP server automatically. This is may be what you want. 

15. Securing Apache 

If you don't want your Apache web service available to public, you can use the Listen or BindAddress directives in '/etc/apache2/apache2.conf'. Using Listen: Listen 127.0.0.1:80 Using BindAddress: BindAddress 127.0.0.1. Then you can restart your apache service with sudo service apache2 restart . The default Apache installation in Debian permits users to publish content under the '$HOME/public_html'. This content can be retrieved remotely using an URL such as: http://your_apache_server/~user. You can restrict the default configuration by editing '/etc/apache2/mods-enabled/userdir.conf'. You can also make sure the permission of log files can only be read/write by the required user and groups. The default permission for the log files may be readable by anyone. By default, Apache web files are located under /'var/www'. The default file provides some hints on the system like what is the operating system. You should substitute the default web pages with your own. To further strengthen the Apache security, you can run Apache by chroot. See this instruction to set up Apache.

 16. Subscribe to security announcements for your OS

If there is a security problem with your Operating System, you need to find out as soon as possible. Find the appropriate mailing list and keep an eye out for anything that requires urgent action. As soon as new security bugs are detected, you need to execute security upgrade immediately.

17. Read security guide for each service installed

Before and after you install a new service on your virtual machine, you need to check the service security guide to perform any required steps to harden the service security.