...

Restrictive firewall (allow-listing)

Every virtual machine running in EWC comes with two firewalls: the firewall of the virtual machine itself (netfilter/iptables/nftables/firewalld) and the (Openstack) Security Groups.  The machine firewall can be changed by admin users on the machine itself, while security groups must be configured by someone with Morpheus access.  Which is most appropriate depends on whether you want to delegate to machine admins or wish to impose constraints on them.  In any event, both firewalls will apply at all times and network packets must be allowed by both in order to get through.

To be maximally secure, your Your virtual machine instances should be configured so that they allow the minimum required access needed to run your application - i.e. only open the ports that need to be opened and only open them for the least amount of IPs possible.. By default, virtual machines have no external access, this means no single port is opened by default to the public Internet. on EWC run a local firewall (which allows common ports) and no security groups (which means all internal and external connections are blocked).  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.by enabling some security groups and potentially modifying or disabling the local firewall.

Link to one of the many general internet pages describing how to manage firewalls on Ubuntu and Centos/Rocky.

Link to some of the very few and unreadable descriptions of security groups on the internet, or to an EWC page.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. → link to page describing these and what they're for.

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. 

Link to general internet pages on seeing what services are running and security hardening

Use secure protocols

Wherever possible, use encrypted and secure communication protocols to avoid man in the middle attacks; this is when someone get access is able to monitor your communications and can read the data going through like in them, for example if you're using a public WIFI hotspot or have a malicious network administrator. For example: do not use HTTP, use instead HTTPS. Do not use FTP to transfer files, use instead FTPS , SFTP or S3or SFTP.

This one is true but increasingly pointless - anyone choosing to use http or ftp probably knows what they're doing and everything else is encrypted.

Use intrusion detection software

...

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

Link to general internet page on using fail2ban, especially how to see banned IPs and unban

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 user is responsible for what's running on their machine and must plan and implement updates according to the risks and their needs. We can only recommend the following:

• 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. 

...

• The user can disable these or enable updates for all packages.
• Some

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 manually 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 If you're running public services, subscribe to security announcements for your OSany software not covered by automatic updates, if there is a security problem in that requires your operating systemaction, 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
• Do not rely on obscurity ("no one will notice this old bit of software..") - there are malicious people running a large number of automated scanners that continuously search the internet for vulnerable software or weak passwords.  A typical SSH server on the internet will be hit thousands of times a week with automated login attempts.

Only install from reputable sources

...

• 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
  • 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.
  • EUM tenancies typically provide user ids in LDAP that have this capability
• If running services, add a user account and add user-level accounts that run a single service and have no login possible, neither remote nor local access.

Do not enable For general user accounts, consider disabling password login , anduse 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.  If you have to use passwords, be aware:

• Passwords can be, with enough time and compute power, guessed with brute force
• More commonly, people use weak (easily guessable) or previously used / known passwords (https://haveibeenpwned.com/Passwords) - try to ensure passwords are complex and unique.  EWC default setups will warn about weak passwords.
• It's easiest if you use a password manager (e.g. https://keepassxc.org/) to generate and store passwords.

For publicly exposed services, prefer longer/less common usernames (e.g. not "admin") to reduce guessability - to login, the attacker must guess the combination of password and username.  You may not be able to control your users selecting weak passwords, but you can make the usernames more complex when adding them.

Password protect your SSH keys and make sure your key never leaves your control (ideally never leaves the hardware machine where it was created., by using tools such as ssh-agent).

• if a key is somehow accidentally exposed (one common way is unintentionally including it in a github repository!), retire it and generate a new one.  There are brute forcing scanners that use lists of known keys (e.g. https://github.com/HynekPetrak/sshame)Do not store public keys (much less private) on the image used to create the VM. 

Keep logs of your applications

...

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

...

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