How To Share and Use Public AMIs in A Secure Manner

When using Amazon Machine Images (AMI's) it is important to remember to use proper precautions to ensure that private information is not inadvertently left on AMI's when shared publicly.  This tutorial is provided to help customers share public Amazon Machine Images (AMIs) in a secure manner. 

This tutorial expands upon the basic instructions within the "Sharing AMIs Safely" section of the EC2 User's Guide, which can be found at https://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-sharingamis.html.  The EC2 User's Guide and this tutorial cover the most common security concerns with sharing public AMI. They should not be used as a complete security assessment guide.

For information on hardening and clean-up requirements, go to Public AMI Publishing: Hardening and Clean-up Requirements, which is available at https://aws.amazon.com/articles/9001172542712674.

Additional security guidance is provided for users of public AMIs, as well as instructions for what to do should you discover an AMI that has security concerns.

We recommend against storing sensitive data or software on any AMI that you share. Below, are expanded guidelines to help you to avoid some easily overlooked security risks.

Always delete the shell history before creating your AMI. The shell history may contain your secret access key or other private info that are not intended to be shared with users of your AMI. As an example, the following command can help locate the root user and other users' shell history files on disk and delete them, when run as root:

    find /root/.*history /home/*/.*history -exec rm -f {} \;
  

Bundling a running instance requires your private key and X.509 certificate. Put these and other credentials in a location that is not bundled (such as the instance store). If you are building an AMI from an EBS volume, make sure your private key and certificate are removed from the volume before taking the snapshot.

Exclude SSH authorized keys before creating your AMI. The public key used to launch an instance is commonly stored in the SSH "authorized_keys" file. As an example, the following command can help locate "authorized_keys" files on disk and delete them, when run as root:

    find / -name "authorized_keys" –exec rm –f {} \;
  

Ensure that your private credentials for third-party applications and remote services are deleted, such as the username and password for any remote database you might have stored locally, or perhaps the credentials for a remote source code repository you have used recently. As an example, the following commands can help locate CVS and subversion information you may not wish to share publicly:

    find /root/ /home/*/ -name .cvspass –exec rm –f {} \;
    find /root/.subversion/auth/svn.simple/ /home/*/.subversion/auth/svn.simple/ -exec rm –rf {} \;
  

For users of public AMIs, particular attention should also be paid to ensure that there are no pre-installed credentials, such as public SSH keys or default usernames and passwords, which could allow unwanted third-party access to your running EC2 instances, or preconfigured remote logging hosts which could result in sensitive system and application logging data being transmitted to unauthorized recipients.

At a minimum, we recommend that users of public AMIs identify and disable unauthorized public SSH keys. To do so, you will need to remove any unrecognized keys from your running instance(s). Note that public SSH keys are not guaranteed to be in the '/root/.ssh/authorized_keys' file. As an example, the following command will help locate "authorized_keys" files on disk, when run as root:

    find / -name "authorized_keys" -print -exec cat {} \;
  

This command will generate a list of all known "authorized_keys" files, which you can then individually edit to remove any unrecognized keys from each of the identified files. To ensure that you do not inadvertently remove YOUR authorized keys, we recommend that you initiate two SSH sessions when starting this process for each instance. You should keep the second session open until you have confirmed that all unrecognized / unauthorized keys are removed and that you still have SSH login access to the instance using your authorized key.

If you do not use SSH to connect to your Amazon EC2 instances, we recommend that you check the security groups associated with the above instance(s) to ensure that port 22 inbound is closed to all unknown IPs. This can be done via the AWS Management Console. For detailed instructions, please check the "Using Security Groups" section of the Amazon EC2 User guide:

https://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-network-security.html

You should find and remove any default usernames and passwords that could result in unauthorized access to your instance.As an example, the following command can help find usernames and passwords:

    cat /etc/passwd /etc/shadow | grep -E '^[^:]*:[^:]{3,}' | cut -d: -f1
  

If you see any unrecognized login, we recommend that you change the password by running the following command (where the USERNAME is the unrecognized username),

password USERNAME

To prevent any preconfigured remote logging, you should delete the existing syslog config and restart the syslog service. As an example, you could run the following as root:

    rm /etc/syslog.conf
    service rsyslog restart
  

Finally, if you should discover a public AMI that you feel presents a security risk to any member of the AWS user community, for whatever reason, please e-mail AWS Security directly at aws-security@amazon.com. We take security very seriously, and investigate all reported issues. If you wish to protect your email, you may use PGP; our key can be found at https://aws.amazon.com/security/aws-pgp-public-key/