Introduction

Users are responsible for the security of the virtualised resources under their control. This includes, but it is not limited to: virtual machines, network configuration, user accounts, disk volumes. 

Here are some security guidelines to help you secure your resources on the European Weather Cloud.

Mike: These are good, and it's great we highlight the defaults, but we should add practical things an unsophisticated user can actually do in the situations where we can't help them with a default.  I'll start adding these..

Network 

It is very important to keep your network configuration as secure as possible, as it is the gate any intruder will use to enter in your system. It is relatively simple to apply some good practices that will give a good extra security layer. Here below few strategies are advised.

Prevent external parties from connecting to your machines

Avoid using public IPs where practical

A VM only needs a public IP if you're expecting someone to connect to it from outside your tenancy.  You can avoid adding the public network or assigning a floating IP when you create a VM, and keep most VMs only on the private/internal network.

To reach VMs with only a private IP from outside, you first connect to a well-secured gateway machine with a public IP, then connect onwards internally to the target VM on the private network.

EWC provides an SSH proxy template to act as such a gateway.  Please see LINK_TO_PAGE_IVE_FORGOTTEN for examples on how to use this to connect to internal VMs and resources.

Also, as IPv4 addresses are in short supply and EWC foolishly doesn't support IPv6, it's good to minimise use of these  

Restrictive firewall (allow-listing)

Your virtual machine instances should be configured so that they allow the minimum required access to run your application. By default, virtual machines have no external access, this means no single port is opened by default to the public Internet. In order to connect to them, or to provide any kind of service, access has to be explicitly added. It is important to only open the ports that need to be opened and only open it for the least amount of IPs possible.

Every virtual machine running in EWC comes with two firewalls: the firewall of the virtual machine itself (netfilter/iptables) and the Openstack Security Groups. 
There are default Security Groups admins which are adequate for many situations and environments, please use those.

Disable unneeded services

Do not run unnecessary services on your VM, especially those that are accessible from the outside. The more services you run, the more potential attack surfaces you have that top intruders might exploit. 

Use secure protocols

Wherever possible, use encrypted and secure communication protocols to avoid man in the middle attacks; this is when someone get access to your communications and can read the data going through like in a public WIFI. For example: do not use HTTP, use instead HTTPS. Do not use FTP to transfer files, use instead FTPS, SFTP or S3.

Use intrusion detection software

Tools such as denyhosts or Fail2ban can be used to analyse log files and ban IP addresses that are attempting to make brute-force attacks to your application. They are very powerful tools, but they have to be used used with care as they can lead to false positives, i.e. Banning IPs that should not be banned. These tools are a best practice to provide 24/7 services, while may not be necessary for single user VMs.

The images provided by EWC come with fail2ban preconfigured and active.

Software

Running secure software is also very important. It is not a trivial task to develop fully secure software, but there are some simple strategies that will help with the task.

Automatic software updates

The images provided by EWC come with automatic updates enabled for the security repositories only. This is made possible by leveraging dnf-automatic  for rpm based distros and unattended-upgrades for deb based ones. 

For additional non security updates, the user is responsible and must plan accordingly. We can only recommend the following:

• Kernel updates: Some updates, such as kernel upgrades, require rebooting the virtual machines. Please schedule this into your regular maintenance.
• If your use case does not support automatic updates, which is common for highly available setups, please make sure to schedule regular maintenance windows where the software upgrade is scheduled.
• Subscribe to security announcements for your OS, if there is a security problem in your operating system, you need to find it out as soon as possible. You can subscribe to an appropriate mailing list, RSS feed, ... to keep an eye out for anything that requires urgent action.

Only install from reputable sources

Be mindful of the sources for the software you install. Only install software from reputable sources. If possible, use the distribution's package manager (yum, dnf, apt, ...). Packages managers make it easy to install software, keep it updated, and uninstall it. If the desired software is not available in the distribution package manager repository, an official source must be used. Follow the instructions on the official website of the software you need. If more than one source is offered, think about using the one that provides an easier life-cycle (install/update/uninstall/...), like conda, snap or flatpak.

Be mindful about the user accounts in the VM

Keep an eye on the user accounts enabled in your system. Some applications create default accounts which are unnecessary or even directly insecure. An ideal scenario might be three accounts:

• root with ssh disabled and no password. This is the default in the images provided on ECMWF Cloud for the different OS (i.e. Ubuntu, Rocky,..).
• A user account for a sysadmin that can only be accessed via ssh keys and has sudo access. ECMWF Cloud images provide this user pre-configured as well as part of cloud-init, the name of the user depends on the distribution (cloud-user, ubuntu), see the documentation for more information.
• and add user-level accounts that run a single service and have no login possible, neither remote nor local access.

Do not enable password login, use SSH keys instead. Passwords can be, with enough time and compute power, guessed with brute force. The average SSH server deals with thousands of such attacks every week. When using SSH keys, challenge-response authentication is used instead. This means that for each login a different challenge is asked and a different response is the correct one. No secret (password or key) ever travels across the network

Password protect your SSH keys and make sure your key never leaves the hardware where it was created.

• Do not store public keys (much less private) on the image used to create the VM. 

Keep logs of your applications

Use the best practices for logging:

• Make sure that the services are logging to a secure location, that is as tamper-proof as possible.
• Keep the logs for a reasonably long amount of time.
• Consider logging to a remote server as well.

More information

If you are interested to learn more about security in cloud application, we advise to read the material provided by NeCTAR. 

Acknowledgements

The EWC Team would like to acknowledge the following source of information for this page: 

• https://wiki.u-gov.it/confluence/display/SCAIUS/General+Security+Guidelines+for+ADA+cloud 
• https://docs.csc.fi/cloud/pouta/security/ .