5 Basic Steps to Shield Your AWS Account From Unauthorized Access

How I got hacked

Many years ago, we got to know our AWS bill has gone up. We started digging and realize on 2 days in a month the EC2 cost spiked. Our analysis concluded that somehow my machine was hacked and hackers got my Access Keys.

I was a power user of AWS access keys. I used to love the command-line interface of AWS Client. All the EC2 instances, I was running had the keys. Keys were in the code of a few of the services we were running.

I was traveling and I used various public WiFi access points. Not sure how the hackers got my keys from my machine, but they got it. While I was away from work, they created large EC2 instances in our account and started running their code. They were smart, they used to run the instances in the regions we were not using.

5 Simple Steps We Took To Safeguard Us

As soon as we came to know about the cause of the hack, we decided to defend ourselves against these attacks by doing the following measures

1. Get rid of AWS Access keys (if you can)

Access keys being the primary cause of the hack, we decided to remove all the access keys we have in the account. The decision was binary, so it does not matter if an access key has root access or not.

Follow the following practices to manage AWS Access Keys:

• Don’t create AWS keys (with root-access).
• In case you need an AWS key, restrict access to the required services only.
• Never embed the key in your code or in any configuration file. A friend once uploaded the keys to GitHub when he was making a part of his code open source. Within few minutes unknown EC2 instances came upon his account. Thankfully he came to know early enough and could avoid damage.
• Remove unused keys and rotate the old keys. A cumbersome task.

2. Move to AWS IAM Roles

We had various access keys in the code that were used in the code, it was not easy to move to IAM Roles. Though there was significant work involved in moving to IAM Roles we bit the bullet.

We saw the following advantages after moving to IAM Roles:

• Better security. We created IAM roles for various types of instances we were using. We restricted the permissions to what was required.
• No need for rotation.
• No keys in the code.

3. Raise a request to reduce the number of instances that can be launched in the Regions you don’t use

Well, this task is tedious. You need to raise many requests for all the regions you are not using. You can go to AWS support and raise requests to limit the number the EC2 instances that can be spun up in these regions. I suggest for all the regions that are not used, this limit should be set to zero.

4. Monitor the number of EC2 instances

We ran our own monitor in AWS Lambda to monitor the following:

• the number of EC2 instances that are running. If it crosses the set limit we get a notification or a phone call.
• the number of stopped EC2 instances.
• a number of instances in all the regions.
• Per-day billing. If billing goes beyond the limit we get a phone call.

5. AWS Config & AWS Security Hub

These are two of the many tools provided by AWS to safeguard the customers. I would recommend enabling AWS Foundational Security Best Practices. This gives you a score of the security and also lets you enable and disable specific controls within the standard. AWS config shows various potential loopholes in the infrastructure and suggests a solution as well.

Conclusion

AWS is a vast cloud platform, they offer a lot of tools to secure their customers. We bumped up our security with these 5 steps, but there is a lot more you can do based on the services you are using. Of course, you can always take help from the AWS team.