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.

Details

Submitted By:

aws-security@amazon.com

AWS Products Used:

Amazon EC2

Created On:

June 7, 2011 3:45 AM GMT

Last Updated:

September 7, 2011 12:46 AM GMT

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.

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.

Sharing Public AMIs in A More Secure Manner

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:

Using Public AMIs in A More Secure Manner

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:

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

Security Concerns with A Public AMI

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/