The purpose of securing AWS services is to protect resources, detect breach, respond and remediate.

Configure the resources for minimal attack possibilities (so-called attack surface), and also in such a way that a breach of one service does not compromise other services in your environment.

Based on your system architecture and use cases, one or more of below-mentioned procedures could be applied.

1. Use private subnets

• Create EC2 in a private subnet of a VPC, which makes the EC2 not visible (and not reachable) directly over the public internet. Use a Bastion host (also called jump server) in public subnet, to reach the EC2 in private subnet.
• Don’t allow any SSH traffic except from the bastion host security group.
• Using this procedure (of bastion host) requires sharing private keys to connect with EC2.

2. EC2 SSH connectivity options

It is also possible to connect to EC2 using below methods.

• EC2 Instance Connect is available on the AWS console. This procedure does not require sharing a private key. However, the EC2 must have a public IPv4 address. Also, you need to open an SSH port to allow inbound traffic from the AWS IP address, for the specific region.
• Using EC2 Connect Endpoint which works for private and public IPv4 addresses of EC2.
• AWS Systems Manager Session Manager – This method does not require opening any inbound SSH port nor private key files and works for EC2 in private and public subnets. SSM agent must be running on the EC2, for this procedure.

3. Harden the EC2

• Configure a cron job to regularly apply OS security patches.
• Install anti-virus and anti-malware tools such as ClamAV and regularly update the virus definition files.

4. Use Host Intrution Detection (HID)

• HID tools such as OSSEC detect brute force attacks and file system changes in EC2 and can take configured actions, such as blocking the attacker’s IP and alerting you through email.
• Configure an EC2 auto-scaled system (with EC2 having OSSEC). In the event your EC2 files are injected with malware, you will get a notification from OSSEC. Detach the infected EC2 from ELB. The AWS auto-scaling service will spin another fresh EC2. You might automate this process as well.
• This way, you have business continuity with minimal downtime. You can do forensic analysis on the infected EC2 to find the root cause.

5. Use EC2 instance profile

Never store AWS access key and secret key on the EC2 or application code. Instead create EC2 instance profile with the least privileges to fulfill the use case and attach it to the EC2. For example, if your application requires access to S3, create an instance profile with access to a specific bucket only and attach to EC2.

6. Use VPC Endpoints (AWS Private link)

Using AWS private link, your traffic flows through AWS private network, bypassing public internet. For example, if your EC2 needs to connect to S3, create a VPC interface endpoint for S3. All traffic between EC2 and S3 will be within AWS network only, thus improving security posture.

7. Control access to AWS resources

Allow access to AWS resources only when users are connected to VPN or from corporate network. This helps in reducing the attack surface. To achieve this, create a managed policy and attach to the user group. Policy is shown below:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "NotIpAddress": {
        "aws:SourceIp": [
          "Allowed IP1",
          "Allowed IP2"
        ]      },
      "Bool": {
        "aws:ViaAWSService": "false"
      }
    }
  }
}

8. NACL & Security groups

Network ACLs (which are stateless) allows/denies traffic at the subnet level. As a result, they don’t control traffic within the same subnet, e.g., traffic between two EC2 in a subnet cannot be controlled by NACL. 

By properly configuring security groups and ACLs, you can significantly improve EC2 instance security. 

• Use customer managed prefix list to update the IP addresses and use them in security groups and route tables, rather than adding the IP directly. This way, there is a single place to refer and easy to modify.
• Refrain from configuring inbound rule with source IP 0.0.0.0/0 which permits all IPs from the internet, which can be very risky.
• Unless your usecase requires connecting external servers from the EC2, don’t configure any outbound security group rule.
• If your use-case requires connecting to external / 3rd party services, configure a DNS firewall, and allow only those 3rd party domains, blocking everything else.
• Configure an AWS Event Bridge rule that monitors for changes to Security Group rules and
  •   Sends a notification  and/or
  •   Schedule to restore to previous values (e.g., after 3 hours)

9. General considerations

• Attach a ‘deny’ policy to all users (except a few) to prevent deletion of EC2, which have a tag (for example ‘production’).
• Choose to encrypt data and boot volumes while creating the EC2. With this, data at rest and in transit between instances and volumes is encrypted.
• Enable CloudTrail to record all AWS console and API operations on EC2 are recorded.
• Automate backing up your EC2 as AMI regularly, useful in disaster recovery.