Public AMI Publishing: Hardening and Clean-up Requirements

Articles & Tutorials>Public AMI Publishing: Hardening and Clean up Requirements
As a publisher of a public AMI, you are responsible for the initial security posture of the machine images that you distribute. In order to protect our customers, certain minimum security standards must be met by all public AMIs.

Details

Submitted By: aws-security@amazon.com
AWS Products Used: Amazon EC2
Created On: September 7, 2011 12:28 AM GMT
Last Updated: September 7, 2011 12:28 AM GMT

Public AMI Publishing: Hardening and Clean-up Requirements

As a publisher of a public AMI, you are responsible for the initial security posture of the machine images that you distribute. You are free to configure your private AMIs in any way that meets your business needs and does not violate our Amazon Web Services Acceptable Use Policy. However, when an AMI is made public, it can be launched by customers who are not security experts, and who are not familiar with the history and details of the AMI. In order to protect our customers, certain minimum security standards must be met by all public AMIs.

This article expands on the following existing resources:

  1. The Sharing AMIs Safely section of the EC2 User Guide, which can be found at http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/AESDG-chapter-sharingamis.html.
  2. How To Share and Use Public AMIs in A Secure Manner, which is available at https://aws.amazon.com/articles/0155828273219400.
These resources and this article cover the most common security concerns with sharing public AMIs, and should not be used as a complete security assessment guide.

In addition to making sure that the software you publish is up to date with relevant security patches, you must also minimally perform the following set of clean-up and hardening tasks before publishing your AMI.

All AMIs:

  1. Disable services and protocols that authenticate users in clear text (e.g. Telnet and FTP).
  2. Do not start unnecessary network services on launch. Only administrative services (SSH/RDP) and the services required for your application should be started.
  3. Securely delete all AWS credentials from disk and configuration files.
  4. Securely delete any third-party credentials from disk and configuration files.
  5. Securely delete any additional certificates or key material from the system.
  6. Ensure that software installed on your AMI does not have default internal accounts and passwords (e.g. database servers with a default admin username and password).
  7. Ensure that the system does not violate the Amazon Web Services Acceptable Use Policy. Examples include open SMTP relays or proxy servers.

Unix/Linux AMIs:

  1. Configure sshd to allow only public key authentication. This can be done by setting
    PubkeyAuthentication yes
    and
    PasswordAuthentication no
    in sshd_config.
  2. Generate a unique SSH host key on instance creation. If you are using cloud-init in your AMI, it can handle this for you automatically.
  3. 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
    passwd -l <USERNAME>
    for each account.
  4. Securely delete all user SSH public and private key pairs.
  5. Securely delete the shell history and system log files that contain sensitive data.

Windows AMIs:

  1. Ensure that all enabled user accounts have new randomly generated passwords on instance creation. The EC2 Config Service can be set to do this for the Administrator account on the next boot, but you must explicitly enable this before bundling the image.
  2. Ensure that the guest account is disabled.
  3. Clear the Windows event log.
  4. Do not join the instance to a Windows domain.
  5. Do not enable any file share points that are accessible by unauthenticated users. It is recommended to completely disable file shares.

The preceding lists are not intended to be comprehensive lists of hardening tasks for published AMIs and AWS will add to the lists over time, so please reference this document before publishing. If an AMI that you have published is discovered to be in violation of one of the above practices, or poses a significant risk to a customer's running of the AMI, then AWS may take measures to remove the AMI from the public catalog and notify you and those running the AMI of the finding(s).

Secure Deletion

To securely delete files, use a tool that writes over the disk space that is used by the files. Use of such a tool greatly reduces the ability of a third party to recover the deleted files. For Linux operating systems, utilities like shred or srm can be used. For Windows operating systems, you can use a utility like Sysinternals SDelete or Eraser.

Security Concerns with a Public AMI

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/




©2014, Amazon Web Services, Inc. or its affiliates. All rights reserved.