Guidelines for Building OUTSCALE Machine Images

In this topic, we expose the guidelines that 3DS OUTSCALE recommends when you want to build an OUTSCALE machine image (OMI). These guidelines enable you to reduce the attack surface and improve the reliability of your OMIs.

Be careful when you build OMIs you want to share, and consider what kind of data you might expose. This list of security guideline is non-exhaustive.

Guidelines for All OMIs

  • Disable services and protocols that authenticate users in clear text.

  • Do not start unnecessary network services at launch. Only administrative services (SSH/RDP) and the services required for your application should be started.

  • Securely delete all OUTSCALE credentials from disk and configuration files.

  • Securely delete any third-party credentials from disk and configuration files.

  • Securely delete any additional certificates or key material from the system.

  • Ensure that any software you installed do not have default internal accounts and passwords.

Guidelines for Linux OMIs

General Guidelines

  • Configure sshd to allow only public key authentication. This can be done by setting the following in sshd_config:

    PubkeyAuthentication yes
PasswordAuthentication no

  • Generate a unique SSH host key on virtual machine (VM) creation. If you are using cloud-init in your OMI, it can handle this for you automatically (the get-ssh-key script inside the OMI should be able to handle that too).

  • Remove and disable passwords for all user accounts so that passwords cannot be used to log in and user accounts do not have a default password. This can be done by running for each account.

  • Securely delete all user SSH public and private keypairs.

  • Securely delete the shell history and system log files that contain sensitive data.

Remove SSH Host Key Pairs

If you plan to share an OMI derived from a public OMI, remove the existing SSH host key pairs located in /etc/ssh. This forces SSH to generate a new unique SSH keypair when someone creates a VM using your OMI, improving security and reducing the likelihood of "man-in-the-middle" attacks.

Remove all of the following key files that are present on your system:

  • ssh_host_dsa_key

  • ssh_host_dsa_key.pub

  • ssh_host_ecdsa_key

  • ssh_host_ecdsa_key.pub

  • ssh_host_ed25519_key

  • ssh_host_ed25519_key.pub

  • ssh_host_key

  • ssh_host_key.pub

  • ssh_host_rsa_key

  • ssh_host_rsa_key.pub

You can securely remove all of these files with the following command:

$ shred -u /etc/ssh/*_key /etc/ssh/*_key.pub

Install Public Key Credentials

After configuring the OMI to prevent logging in using a password, you must make sure users can log in using another mechanism.

3DS OUTSCALE allows users to specify a public-private keypair name when creating a VM. When a valid keypair name is provided to the RunInstances API call (or through the command line API tools), the public key (the portion of the keypair that 3DS OUTSCALE retains on the server after a call to CreateKeyPair or ImportKeyPair) is made available to the VM through an HTTP query against the VM metadata. For more information, see Accessing the Metadata and User Data of a VM.

To log in through SSH, your OMI must retrieve the key value at boot and append it to /root/.ssh/authorized_keys (or the equivalent for any other user account on the OMI).

Many OUTSCALE OMIs, use the cloud-init package to inject public key credentials for a configured user. If your distribution does not support cloud-init, you can add the following code to a system start-up script (such as /etc/rc.local) to pull in the public key you specified at launch for the root user:

if [ ! -d /root/.ssh ] ; then
        mkdir -p /root/.ssh
        chmod 400 /root/.ssh
fi
# Fetch Outscale public key using HTTP
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/my-key
if [ $? -eq 0 ] ; then
        cat /tmp/my-key > /root/.ssh/authorized_keys
        chmod 400 /root/.ssh/authorized_keys
        rm /tmp/my-key
fi

This can be applied to any user account; you do not need to restrict it to root.

Guidelines for Windows OMIs

  • Ensure that all enabled user accounts have new randomly generated passwords on VM creation.

  • Ensure that the guest account is disabled.

  • Clear the Windows event log.

  • Do not join the VM to a Windows domain.

  • Do not enable any file share points that are accessible by unauthenticated users. It is recommended to completely disable file shares.

  • Develop a repeatable process for building, updating, and republishing OMIs.

  • Build OMIs using the most up-to-date operating systems, packages, and software.

  • Verify that no guest accounts or Remote Desktop user accounts are present.

  • Disable or remove unnecessary services and programs to reduce the attack surface of your OMI.

  • Remove VM credentials, such as your key pair, from the OMI (if you saved them on the OMI). Store the credentials in a safe location.

  • Ensure that the administrator password and passwords on any other accounts are set to an appropriate value for sharing. These passwords are available for anyone who launches your shared OMI.

  • Test your OMI before you share it.

Sharing Publicly Your OMI

Identify Yourself

At the moment, we do not know easily who provided a shared OMI, because each OMI is represented by an account ID. We recommend that you post a detailed description of your OMI.

Security Concerns with a Public OMI

If you should discover a public OMI that you feel presents a security risk to any member of the OUTSCALE user community, for whatever reason, please email 3DS OUTSCALE Security directly at security@outscale.com. We take security very seriously, and investigate all reported issues.

Related Pages

Export to PDF