Module 8



This module provides an introduction to key security issues, dangers and consequences when running a virtual machine in the cloud. Practical advice for making your machine secure and preventing it from being hacked. An introduction to data encryption including usage of a variety of tools is also given.

Cloud computing has grown exponentially over the last few years. However security concerns are still quite common amongst those who are reluctant to adopt it. Is cloud computing safe? What are the common security concerns, and how justified are they?

We will talk about security concerns in this Module and describe how NeCTAR addresses security issues, and what you need to do to make your virtual machine safe and protect it.


The following videos go through most of the content in this module and offer a less in-depth description of the subject than the documentation does.


The notation throughout the training documents can be interpreted as follows:

Words in italics are used for names and terminology, e.g. name of a software, or name of a computing concept. It may also just emphasise a word in the traditional way. Quotations are also written in italics and are put in between quotatioin marks.

Words in bold are used to highlight words which identify important concepts of a paragraph, to make it easier for users to skim through the text to find a paragraph which explains a certain idea, concept or technology.


Additional information which is optional to read is displayed in info boxes like this one.


Important information is displayed in boxes like this one.


Definition of terms are displayed in boxes of this style.


Possibly specific prerequisites for reading a particular section are contained in this type of box at the beginning of a section.

The use of command line tools is part of this course. In a Terminal, you will be directed to type in commands. Commands are formatted as follows:

command-name argument1 argument2 ... argumentn

Throughout the exercises, when you see a word in pointed brackets, like <this-word>, it means that you have to replace everything inside the brackets, and including the brackets, with whatever is described within the brackets.

For example, if you are prompted to run a command named the-command which takes two arguments:

the-command -f <yourfile>

Then you have to replace the second argument, <yourfile>, with the file name that is being referenced in the exercise. For example

the-command -f thefile.txt

When editing a file, the contents of it will be displayed in a different font and with background colour as follows:

The content of the file
The next line in this file

Output on the command line terminal is printed in boxes formatted as follows:

NectarInstance:~ Jennifer$ whoami

Security concerns and benefits

The widely spread perception is that cloud computing poses a whole lot of new risks. But in fact, security can improve with cloud computing: Security is often as good as or better than in traditional systems, because the providers infrastructure is maintained by a team of experts which are looking after the data center security around the clock. Cloud providers are able to devote their resources to solving security issues that many of their customers could not afford — and evidently it is the providers top priority to keep their data center safe, or they would lose their reputation and their customers.

More trust is needed in that the administrators of cloud computing infrastructure ensure security with as much competence as any good IT department could do. Unfortunately, 100% security does not exist in IT — a security breach can happen in any organisation, whether it is a cloud provider, a research organization or a business. It is a matter of trust in which IT department can ensure maximum security best.

Perhaps the biggest security concern among cloud computing customers is data loss. Here are some figures from the Databarracks 2014 Data Health report), in which a number of small and large organisations report the causes of data loss:

As the numbers show, human error is still a leading case of data loss! Internal and external security breaches are not far removed from the figures for natural disasters.

Let’s say you can trust your cloud provider in ensuring the best protection against software and hardware failures. This still leaves one very important factor in keeping your virtual machine and data safe: yourself! There are some parts which you are responsible for when ensuring the security of your virtual machine and data. This holds in particular for IaaS services (in SaaS services, the cloud provider is responsible for security control, PaaS services have shared responsibility between provider and customer). Your virtual machine is an IaaS Service, so there will be things you need to observe to make your services secure.

There are a few security issues which are particular to cloud computing, but they are usually not a major security concern, if actions are taken by the cloud provider and yourself to protect against these threats.

It is not difficult to ensure the best possible security for your virtual machine and data, but you have to be aware of which the tasks involved are. We will talk through this in this Module.

Main threats

Main threats to cloud computing are posed by the following (conforming with the Cloud Security Alliance):

VM-specific vulnerabilities

Virtual machines have a number of their own vulnerabilities. A malicious virtual machine can potentially access other instances through shared memory, network connections, and other shared resources. Fortunately, these security concerns can be addressed effectively in a well-managed cloud. Most intrusions can be prevented by the users applying traditional security measures, as we have discussed in Module 5 (“Mitigating Risks”).

Most VM specific vulnerabilities stem from the hypervisor. There are a number of different types of security breaches on the hypervisor level:

Luckily, hypervisors are generally more secure than regular operating systems; The Hypervisor is a fairly simple program, which helps to limit such vulnerabilities.

The NeCTAR cloud uses the KVM Hypervisor with OpenStack. KVM is a good choice in terms of security. The virtual machines managed by KVM run as unprivileged processes, which makes it safe. Techniques for Hypervisor protection include sVirt, Intel TXT, and AppArmor, cgroups, and MAC Policy. KVM has all these techniques in-built. For more information, refer to the OpenStack security guide.

Regular patching of the Hypervisor is important to refresh security. Also, appropriate security policies have to be applied. The NeCTAR cloud administration team is aware of the high security demands of Australias researchers and regularly updates the systems and applies a strict security policy to ensure maximum safety.

In addition to the efforts the security team at NeCTAR are making, part of the security is also your responsibility, because not only the Hypervisor, but also your VM has to be secure (for example, to help prevent a VM Escape attack).

Security benefits of the cloud and virtual machines

The nice part is that using the cloud and a virtual machine does also comes with some security benefits.

Summary of your responsibilities

In summary, these are the things you need to look after:

Deployment Models

There are several deployment models for a cloud which all imply different levels of security (Source: NIST definition of cloud computing):

The private cloud is owned by a single organization and public clouds are shared on a larger scale.

Private and community clouds are regarded as more secure because they provide more control for the organisation(s). However setting up a private cloud infrastructure comes at a significant expense. A public cloud is instead more flexible and is often a more affordable investment for end users, however control of the cloud infrastructure is in the hands of the cloud provider, which can be seen as a security issue. Therefore, it is of high priority to public cloud providers to build and maintain strong management of secure services. Many small businesses cannot afford such efforts and therefore it is often safer for them to use the cloud services.

The NeCTAR Research Cloud can be characterized as a community cloud.

File and Volume Encryption

For several reasons discussed earlier, you may want to encrypt your file. We can broadly distinguish two types of file encryption: 1) encrypting an entire volume and 2) encrypting individual files.

Object storage (discussed in Module 6) is very useful for ease of access and data integrity. Because several copies of your data is kept, availability is very good: The NeCTAR Object Store is geodistributed across Nodes of the Research Cloud so that availability is not reliant on any one datacentre or network infrastructure. Only you have access to your object store using your OpenStack credentials, so only you can select files to download, or upload files to a container.

While access to your Object Store is secured with your credentials, the transfer of your files via the network is not necessarily secure: When you upload and download files, it happens via an unencrypted connection (unless you explicitly use a secure client, e.g. an SFTP client). At the time when you download or upload your files, somebody could catch the data you are transferring via the Internet. Also, when your files are replicated across NeCTAR nodes, this happens without encryption.

The critical point is the moment of data transfer.


Extensions to OpenStack (the cloud software that NeCTAR is using) for object storage data encryption have been proposed and will probably be available at some point.

For this reason, you may want to encrypt sensitive data before you upload it to the object storage. With the Object Storage, you upload individual files, so you should do a per-file encryption.

If you want to protect your data on a Volume against breaches (someone gaining access to your volume), you may want to do an entire volume encryption on the volume which you have attached to your VM.

There are many tools for data encryption available. Not all of them support both per-file and whole volume encryption. When choosing a tool for encryption, it is also important that the encryption algorithm used by the tool is secure and cannot be hacked easily.

In this section, we will go through a few example tools for file and volume encryption.

File encryption

In the following we will discuss the following tools which support per-file encryption:

Other widely known tools which have recently received bad security audits (e.g. EncFS, OpenSSL, TrueCrypt) are not discussed in this course.

More detailed instructions are given for GnuPG, while the description of the other tools refers to related documentation.


GnuPG is an implementation of Pretty Good Privacy (PGP). PGP has excellent security:

“To the best of publicly available information, there is no known method which will allow a person or group to break PGP encryption by cryptographic or computational means.”
– source: Wikipedia.

GnuPG is open-source and accessible through a variety of different clients and tools. New versions of PGP are released periodically and vulnerabilities are fixed by developers as they come to light. There is a simple command line interface, but there are also many graphical interfaces available which are more popular.

The official releases can encrypt

All GnuPG tools support multiple encryption types and ciphers.

GnuPG works very well on almost all 32 and 64 bit platforms. It has mainly been developed for Unix systems, but binaries available for Windows, OS X, Debian/Ubuntu, Android and more provided (with no guarantee that binary versions provided are current). Mac users may be interested in GPGSuite.

GnuPG is easy to use and if you keep your private key and the passphrase secret, it is a very secure way to encrypt files. GnuPG also has the advantage that no passwords will appear in any script files if you use your private key to encrypt files.

GnuPG Quick HowTo

You will have to generate a key pair before you can use GnuPG. In the process, you need to specify your E-Mail address (because you can use GnuPG for encrypting E-Mails). Choose the one you usually use, but you can also specify any address and change this later.

Two keys will have been generated: A public key which is used for encryption, and a private which is used for decryption.

To encrypt a file, you must have the public key which you want to use for encryption. You have just generated one in the last step.

To decrypt a file, you need to have the private key of the intended recipient (when the file was encrypted). So the encrypted file will have to be encrypted for the name associated with one of your private keys.

You can find more useful information about file encryption on the GnuPG manual pages.


AESCrypt is a free, open-source tool which is available for Mac, Linux and Windows. It provides a secure way to encrypt individual files, using the industry standard Advanced Encryption Standard (AES).

AESCrypt is easy to use: On Windows, you only right-click on a file, select AES Encrypt (or Decrypt) and enter a password. On a Mac, you drag the file into the AESCrypt program and type in the password. On the Linux command line, you may use the command aescrypt along with the name of the file and the password.

The AESCrypt website provides an excellent documentation on how to set up and use AESCrypt.

Encrypted zip file

Zip files can be password-protected, but the standard Zip encryption scheme is extremely weak. If your operating system has a built-in way to encrypt zip files, you probably shouldn’t use it. You should use AES-256 encryption. The tools discussed in the following do support AES-256 encryption.

Zip files are archives containing individual files, so this cannot be used to encrypt entire volumes.


The older zip encryption is not secure! Several tools can create encrypted zip files (the older, insecure version).

For example,

  • On Windows, you can right-click on a file and select Compress… to create a zip archive.

  • On Linux or Mac, this can be done via command line:
    zip -0 -e <yourfile>
    The option -0 means “store only” and don’t compress — this is faster. -e means encrypt archive.
    It will ask for the password.

This is not secure!

Use the more secure methods described in this section.

Windows: 7-zip

7-zip is great for compressing files and is also a strong file encryption tool. It’s free even for commercial use and supports 256-bit AES encryption. The official download is Windows only, but there are also unofficial Linux and OS X versions.

In 7-Zip, you can select files in the Windows Explorer window, right-click and select 7-Zip > Add to archive. You should make sure to select the Add to archive option in order to encrypt the file. You will be given the option to set a password, make sure you select one! Alternatively, you can open the 7-Zip application and create the archive from there.


7-Zip will create a 7z archive by default, but you can also choose Zip. If you do opt to go with Zip, be sure to select the AES-256 encryption method instead of the weaker ZipCrypto method.

Mac: Keka

With Keka, you compress individual files by dragging and dropping them to Keka in the Dock. You may drop multiple files at once, and they will be compressed as one zip file. You can get Keka from the Mac App Store, here is good documentation on the website on how to use it.


Keka creates encrypted 7z files.By default, the 7z *files will be encrypted using *AES-256, which is secure. If the selected format is Zip, Zip 2.0 legacy encryption will be used, so this is not recommended!

Linux: p7zip

The file explorer on your Linux desktop can be used to create encrypted 7z archives. You first need to install the p7zip-full package (it may also simply be called p7zip on some Linux distributions). Installing p7zip-full allows your file explorer encrypt your files or folders in the 7z compression format. You may find it in your package manager, e.g. on Ubuntu

sudo apt-get install p7zip-full

Then, open your file explorer, right click on the file and select Compress…. Be sure to select 7z as a format! In the window that comes up, expand Other Options, tick encrypt the file list too and type in your password.

You may also use p7zip in the command line. The command is simply called 7z. Refer to the man pages for usage.


p7zip does not store the owner and group of a file. So if you want to use it for backup purposes (or for other reasons want to preserve owner/group), you should pack your files in a tar archive first, and then encrypt the tar archive with p7zip.

To create a tar archive:

tar -cf <tar-file-name>.tar <list of your files or folders>

To extract a tar archive:

tar -xf <tar-file-name.tar>

Then, compress the tar archive file with p7zip as described.

Volume encryption on Ubuntu

Because we base our instances in this course on Ubuntu, we shall also include instructions on how to encrypt a volume in your Ubuntu virtual machine.

In Module 7, we have seen how we can use our secondary disk of our ephemeral storage to store our data (the secondary disk is essentially a volume storage which is included with the instance). We have also created a Volume storage and attached it to our instance. In both methods we have mounted the disk so that we can access it from our instance.
Disks which are mounted on the instance are suitable for Volume Encryption. You can encrypt the whole block of storage, and all files which are written on it will automatically be encrypted. Files on it will be unreadable to others which may gain access to it, even after you delete your storage (or discard your instance).

You can think of volume encryption as happening in the background: You unlock it once with the password, and then use the drive as usual: editing, copying and moving files on it. All programs can access the drive as usual—Ubuntu takes care of automatic encryption and decryption in the background.


Before you decide to encrypt your Volume, you should consider carefully whether you want to do this. While encrypting the data adds security in terms of preservation of privacy, it also incurs new risks:

  • If you ever forget your password, access to your data will be lost forever.
  • It may also introduce difficulties with manual data recovery.
  • You can only unlock your drive using the same encryption algorithm/tool.
  • You should also take into account that performance of reading and writing to your Volume will degrade with the encryption.

You may ask yourself whether you will also be able to copy data onto the encrypted drive from remote, for example using the scp command or an sftp client.

You can access the drive from remote as usual. This is because the file server on your instance (e.g. the scp server) takes care of transferring the files to your remote computer after you have requested them. Programs running on Ubuntu (including the file server) can read the files from the drive as usual, because Ubuntu automatically takes care of the encryption/decryption in the background.

For this reason, you can access the files, even though they are encrypted on the actual harddrive.

Note however, that if you can copy and read the files as usual from remote, so can everyone who may gain access to your private ssh key and passphrase! The volume encryption mainly serves as security in case the physical hard-drive gets stolen, or hacked into from outside your VM – then, nobody can ready your data, because they would have to type in your volume encryption password first.

In the following, we will go through the steps required to encrypt your Volume storage on your Ubuntu instance. We will use a standard procedure on Linux to encrypt drives with the Linux Unified Key Setup (LUKS).

Tipp: You can use the same instructions below to encrypt your external USB Drives from a Ubuntu system. However, note that your USB drive will most likely then only be readable from a Linux system!


Following the instructions will erase all data on the volume! If you have any files on it, make sure to back them up first.

  1. Find out the device name of your volume (e.g. /dev/vdc). You may for example use
    sudo lsblk -l and/or
    sudo lsblk -f
    to print information about your drives. You can also see it on the Volumes overview in the Dashboard.
    The following will assume your drive is located at /dev/vdc. If your is at another path, you will have to replace this in the following commands.

  2. Ensure your volume is attached to your instance, but not mounted.
    Find out if your volume is mounted:
    mount | grep vdc
    If it is, unmount it with
    sudo umount /dev/vdc

  3. If you have data on the volume, now is a good time to securely erase it. We will talk about securely erasing all data in Module 9. If in doubt, you should use an empty (newly created) volume for this tutorial. You can skip this step if you don’t have data to securely erase — a process which may take a long time depending on the size of your volume. Erase your data with:
    sudo dd if=/dev/urandom of=/dev/vdc
    Note: Module 9 provides more information about the dd command.

  4. Now, install the file encryption package cryptsetup:
    sudo apt-get install cryptsetup
    sudo modprobe dm-crypt
    From now on, every time you restart your machine, the encryption software should start up automatically.

  5. Now you can encrypt your Volume:
    sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 -y /dev/vdc
    It will ask you to confirm that you really want to do this, as all data will be erased. You should confirm this with typing “YES” (it needs to be uppercase! Or the command will do nothing).
    You should then be prompted for a password – make sure to choose a secure password, otherwise the encryption will not be secure!

    The parameter -c is used to select the algorithm. -y ensures that you are asked to verify the password, which is always a great idea, in case you have a typo in your first try. -s determines the length of the key — 512 actually corresponds to 256 bit encryption. The reason is that the maximum length of 256 bits is used for both AES and XTS encryption. The more bits are used for encryption, the more it will affect performance. If you would like to trade off a bit of security against performance, you can use -s 256 instead, which then corresponds to 128 Bit encryption.

  6. Now you can map your encrypted drive to a virtual drive with the following command (you may replace MySecureDrive with any name you want to assign to the drive):
    sudo cryptsetup luksOpen /dev/vdc MySecureDrive
    This will ask for the volume encryption password which you just chose. After the command has been executed, your drive will be mapped to /dev/mapper/MySecureDrive (or other name instead of MySecureDrive, if you changed this in the command above).

  7. Now it is time to format your drive (again, replace MySecureDrive with your name, if you have chosen another).
    sudo mkfs.ext4 /dev/mapper/MySecureDrive

  8. That’s almost done! Now we can mount the drive to any directory. In this example, we will create a new one /MyMountedDriveedDrive, but you can choose any other directory:
    sudo mkdir /MyMountedDriveedDrive
    sudo mount /dev/mapper/MySecureDrive /MyMountedDriveedDrive

  9. Optional: By default, you do not have write permissions on the secondary drive. We discussed how to change write permissions in Module 7. Here a brief reminder: You can do this either with
    sudo chown ubuntu /data
    to allow access only to yourself, or
    sudo chgrp ubuntu /data
    sudo chmod g+rwx /data
    to allow access to your whole user group.

You are all done!

You can now use this drive as normal without worrying about encryption, and your data is securely encrypted.

To unmount and free up the volume, type the following commands:

sudo umount /MyMountedDrive
sudo cryptsetup luksClose MySecureDrive

After every reboot of your instance, you will have to unlock the drive by typing in your password and mount the drive again:

sudo cryptsetup luksOpen /dev/vdc MySecureDrive
sudo mount /dev/mapper/MySecureDrive /MyMountedDrive



You are now finished with this Module. You should now be aware of general security concerns in the cloud, and know how risks can be mitigated by the cloud provider and by you. Deployment methods of cloud services (SaaS, PaaS, IaaS) and how they affect security have been introduced. Practical advice has been given for hardening a machine: passwords and passphrases, updates/patches, blocking ports, etc. Finally, this module has also provided some hands-on exercises on how to encrypt data (both individual files, and entire volumes on the instance).

In summary, this module has covered:

You are now ready to continue with Module 9.