Thursday, June 26, 2014

AWS AMI hardening

    AWS  AMI hardening procedures and industry standards can be found in this AMI hardening article: https://aws.amazon.com/articles/9001172542712674

The client is responsible for the initial security posture of the machine images distributed. Private AMIs need to be configured in a secure way that does not violate the AWS Acceptable Use Policy. Software referenced should be up to date with relevant security patches, and adherent to the following:
All AMIs
Disable services and protocols that authenticate users in clear text. (e.g. telnet and ftp)
Do not start unnecessary network services on launch. Only administrative services (SSH/RDP) and the services required for your application should be started.
Securely delete (use Sysinternals,  SDelete or Eraser) all AWS 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 software installed on your AMI does not have default internal accounts and passwords (e.g. database servers with a default admin username and password)
Ensure that the system does not violate the Amazon Web Services Acceptable Use Policy. Examples include open SMTP relays or proxy servers.
Windows specific
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 next boot, but you must explicitly enable this before bundling the image.
Ensure that the guest account is disabled.
Clear the windows event log.
Do not join the instance to a windows domain. 
Do not enable any file share points that are accessible by unauthenticated users. It is recommended to completely disable file share

2 comments: