Securing Amazon EC2 Instances

Amazon EC2 can be interpreted as the fully managed virtual machines in the cloud. Once your resource leaves the internal secured premise of your company, it gets automatically vulnerable to external threads and virus. To secure this environment and keep them running safely, it is a great challenge and responsibility for any IT admin. We will discuss here some best practices and some specific recommendations to keep your AWS secure.

Network Access

Each EC2 instances has one or more Elastic Network Interfaces ( ENIs) that provide networking to an Amazon Virtual Cloud (Amazon VPC). Each ENI is protected by one or more security groups that act as virtual firewalls, stateless network access control list (ACL) and subnet route tables. Lets discuss in more details :

• Configure security groups to permit only required network traffic for the EC2 Instance. For example, for a normal web browser, only HTTP and HTTPS ports are enough. The security groups should be configured to allow only inbound HTTP/HTTPS and a minimal outbound connection. If the networking is needed between two internal instances, limit the networking only between them using group-id.
• Configure VPC subnet route tables with the minimal required network routes. For example, for instance, that doesn't require an internet connection, provide subnet with internal access only.

For example, a set of security policies applied to Database servers should be separate from the load balancer and other applications. This will prevent any unwelcomed guest to move freely throughout the network.

“You need to consider whether you really need to allow 0.0.0.0/0 network traffic or only accept specific connections,”

Liviu Arsene, senior e-threat analyst at BitDefender

User Access to EC2 Instances / follow Identity & Access Management (IAM) practices

Control and monitor interactive access in all the EC2 instances. Provide only required access to the users. When creating IAM roles, specify least-privileges IAM policies. Also, try to avoid user accounts - instead use APIs to handle provisioning and scaling. If an application needs to make access to the system, use low privileges service accounts rather than going with a normal user account. These service accounts are restricted in what they are supposed to do.

• When creating IAM policies, ensure that they are attached to groups or roles rather than individual users.
• Only minimal access to AWS resources, keeping in mind that they can fulfill their responsibilities.
• Enable multifactor authentication to all IAM users
• Enforce a strong password policy and enable password expiration functions. Apply also a password reset policy that prevents users from using their last 24 passwords.

Elastic Load Balancer & Reverse Proxies

Native AWS tools such as ELBs can be used to mitigate DoS or DDoS attacks. Reverse proxies such as NGINX, Apache, and Haproxy can be used to isolate EC2 instances with the rest of the world. This is a good practice. You can let your only reverse proxy access from the outer world and all other systems will be in a private network.

Automatic Snapshot

Create snapshots on a regular basis. This can be done manually or you can setup cronjobs using cloud watch. More information here. It can also be a good idea to move backup data out of s3 into Amazon glacier for data archiving. More information regarding Amazon Glacier can be found here.

AWS’s shared responsibility model for security

Tighten CloudTrail security configurations

CloudTrail is an AWS Service that generates log files of all API calls made within AWS, including the AWS management console, SDKs, command line tools, etc. The generated log files are located in an S3 bucket.

• Enable CloudTrail across all geographic regions and AWS services
• Turn on CloudTrail log file validation so that changes made to the log file itself after it has been delivered to the s3 bucket is trackable to ensure log file integrity
• Turn on multifactor authentication (MFA) to delete CloudTrail s3 buckets.