forums

Start a new topic

Cloud Security Advice

I've been a Nectar user for a number of years, running a large amount of infrastructure in the research cloud as part of the Data to Decisions CRC. A common theme I've noticed when participating in the community is new (and sometimes experienced) users unsure about how to secure their instances against attacks or exploits.


A bit of background...


By default all instances in Nectar are created with a public IP address, i.e. they're exposed to the Internet. This can be useful if you need to access your instance from anywhere in the world, but it does leave it open to exploit attempts - in particular automated scripts that scan ranges of addresses looking for insecure servers to compromise.


The good news is there's a few basic steps you can take to protect your instance against the majority of the automated attacks. The recommendations below are what I consider the best "bang-for-buck" security controls - low effort controls that provide reasonably good protection against most attacks.


Disclaimer! No system is 100% secure, and the recommended controls are a starting point, not an exhaustive list. Depending on your risk posture you may need to invest in additional layers of security.


Recommendations


The example commands are for Ubuntu, however the recommendations are generic and can be applied to any operating systems. Please consult Google for the specific commands for your OS of choice :)


1. Patch your instances


Most automated attacks look to exploit known security issues in software and operating systems. In most cases the security issues are fixed quickly, and the attacks are only effective if the target system doesn't have the fixes applied.


You can stop a large amount of attacks by applying security patches regularly. This can be done manually e.g. by running: sudo apt-get update && sudo apt-get upgrade, but an easier option is to apply important updates automatically. On Ubuntu automatic security patching can be enabled with a single command: sudo apt-get install unattended-upgrades 


Unattended-upgrades will apply security patches nightly. This might not be appropriate for production systems where patches need to be tested before rolling out, but it's a good approach for most research use cases. If a patch requires a restart you will be notified when you login to the system, or if you have a system monitoring capability you can look for the presence of the /var/run/reboot-required file.


2. Protect your SSH key


SSH keys are used to remotely login to instances. When you create your first instance Nectar will offer to create an SSH key for you as well. By default the key created by Nectar is not protected with a passphrase - if an attacker gets hold of the key (e.g. via malware on your workstation) they can use it to login to your server. You can add a passphrase to an SSH key easily using: ssh-keygen -p -f {keyfile}. An SSH key protected with a good passphrase will be useless to an attacker.


As an aside, it's possible to create new accounts on an instance that can login with just a password, however you should always use SSH key-based login. Many automated exploits will attempt to "brute-force" their way into an instance by guessing passwords, and you can't guess an SSH key. 


3. Use Firewalls


There are two options for firewalls - the Nectar firewall, configured from the web portal, or local firewalls, enabled and configured on the instances.


At a minimum you should use the Nectar firewall to restrict access to just the ports and IP addresses you need - ideally whitelisting specific IP addresses and blocking everything else. If whitelisting individual IPs is impractical, consider allowing ranges of IPs e.g. the range allocated to your university. Whitelisting IP addresses and ports will block the vast majority of attack traffic originating from servers around the world.


The Nectar firewall is great for broad access rules, but impractical for fine-grained access rules across many instances. As an additional layer of security similar rules can be configured for local firewalls. For Ubuntu this could be done by enabling Uncomplicated Firewall using sudo ufw enable, but be careful! - the correct access rules need to be added to the local firewall in advance, otherwise a default "block everything" rule applies and you can be permanently locked out of the instance. When enabled carefully local firewalls can provide effective layered security (also known as "defence-in-depth").


Conclusion


I hope the above recommendations are useful to the community. Please feel free to ask questions or add your own security recommendations to this topic.


6 people like this idea

I would add a couple more things (off the top of my head)


4.  Don't enable password-based SSH access over the network. 


I have come across cases where people have either tweaked the SSHD settings in a NeCTAR image to allow access using a password, or loaded up a non-NeCTAR image that is not hardened properly.


If you allow password-based authentication, you are increasing the chance that someone can get by password guessing.  (Note that password guessers are pretty sophisticated these days, and they can evade "fail2ban" blocking by using a fleet of compromised machines to guess in "stealth" mode.)


5. Don't install / enable network services that you don't really need.  Don't open ports you don't need.


Like HTTP or FTP services.  Or email services.  The more public-facing services you have enabled / ports you have opened, the more potential there is for hackers to compromise your system.


6. Make sure that you secure your web services.


Some web servers / applications are notorious for being insecure when installed "out of the box".  For example, some well-known web products install with a default admin password that is well known to hackers.


Other web-based services (particularly PHP-based content management systems) allow you to add "community" plugins that are often insecure, and inadequately maintained.


In situations like those, applying the security patches from the OS distros is not sufficient to secure your VM.  You also need to:

  • Make sure that you follow the instructions carefully on securing the service initially.
  • Avoid plugins that do not appear to be properly secured / maintained.  Always investigate this >>before<< you decide whether to use the plugin.
  • Monitor the relevant channels for security alerts related to the products you are using.
Looks good, only other obvious one that comes to mind:

7. Beware social engineering attacks.

Software patches aren't much good if an attacker gets access to your university account, desktop computer or Nectar account through deception, e.g. through phising attacks. Take care to make sure that anyone requesting access to your personal details, account or computer is who they say they are.

If you need to share passwords, private SSH keys or other sensitive information with colleagues via email, consider using an encryption tool like PGP so only they can read them.

 

If you realize an instance of yours has been compromised:

  • Turn off the compromised instance, rather than terminating it. Then snapshot both it and attached block storage. This allows for a later analysis, if need be.
  • Contact NeCTAR support and tell them about the compromise.
  • Remember that any replacement instance you bring up might have exactly the same attack vector in it. If so it will just be a matter of time before it also succumbs. You need to know how your original machine was compromised to prevent a re-occurrence.
  • When you have worked out what the attack vector was, either patch the replacement instance, or rebuild it with fixes applied.
  • Once everything is back to normal, ensure that you can't accidentally relaunch the original compromised instance or any of the snapshots you might have made of it.

My 2c worth...

Login to post a comment